From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Jakub Kicinski <kuba@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Joel Granados <j.granados@samsung.com>
Cc: Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-xfs@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
kexec@lists.infradead.org, linux-hardening@vger.kernel.org,
bridge@lists.linux.dev, lvs-devel@vger.kernel.org,
linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com,
linux-sctp@vger.kernel.org, linux-nfs@vger.kernel.org,
apparmor@lists.ubuntu.com
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Sat, 27 Apr 2024 09:40:43 +0200 [thread overview]
Message-ID: <38a87a0f-02c7-4072-9342-8f6697ea1a17@t-8ch.de> (raw)
In-Reply-To: <9e657181-866a-4626-82d0-e0030051b003@t-8ch.de>
On 2024-04-25 09:10:27+0000, Thomas Weißschuh wrote:
> On 2024-04-24 20:12:34+0000, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> >
> > Split this per subsystem, please.
>
> Unfortunately this would introduce an enormous amount of code churn.
>
> The function prototypes for each callback have to stay consistent.
> So a another callback member ("proc_handler_new") is needed and users
> would be migrated to it gradually.
>
> But then *all* definitions of "struct ctl_table" throughout the tree need to
> be touched.
> In contrast, the proposed series only needs to change the handler
> implementations, not their usage sites.
>
> There are many, many more usage sites than handler implementations.
>
> Especially, as the majority of sysctl tables use the standard handlers
> (proc_dostring, proc_dobool, ...) and are not affected by the proposed
> aproach at all.
>
> And then we would have introduced a new handler name "proc_handler_new"
> and maybe have to do the whole thing again to rename it back to
> the original and well-known "proc_handler".
This aproach could be optimized by only migrating the usages of the
custom handler implementations to "proc_handler_new".
After this we could move over the core handlers and "proc_handler" in
one small patch that does not need to touch the usages sites.
Afterwards all non-core usages would be migrated back from
"proc_handler_new" to "proc_handler" and the _new variant could be
dropped again.
It would still be more than twice the churn of my current patch.
And these patches would be more complex than the current
"just add a bunch of consts, nothing else".
Personally I still prefer the original aproach.
Thomas
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Jakub Kicinski <kuba@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Joel Granados <j.granados@samsung.com>
Cc: Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-xfs@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
kexec@lists.infradead.org, linux-hardening@vger.kernel.org,
bridge@lists.linux.dev, lvs-devel@vger.kernel.org,
linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com,
linux-sctp@vger.kernel.org, linux-nfs@vger.kernel.org,
apparmor@lists.ubuntu.com
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Sat, 27 Apr 2024 09:40:43 +0200 [thread overview]
Message-ID: <38a87a0f-02c7-4072-9342-8f6697ea1a17@t-8ch.de> (raw)
In-Reply-To: <9e657181-866a-4626-82d0-e0030051b003@t-8ch.de>
On 2024-04-25 09:10:27+0000, Thomas Weißschuh wrote:
> On 2024-04-24 20:12:34+0000, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> >
> > Split this per subsystem, please.
>
> Unfortunately this would introduce an enormous amount of code churn.
>
> The function prototypes for each callback have to stay consistent.
> So a another callback member ("proc_handler_new") is needed and users
> would be migrated to it gradually.
>
> But then *all* definitions of "struct ctl_table" throughout the tree need to
> be touched.
> In contrast, the proposed series only needs to change the handler
> implementations, not their usage sites.
>
> There are many, many more usage sites than handler implementations.
>
> Especially, as the majority of sysctl tables use the standard handlers
> (proc_dostring, proc_dobool, ...) and are not affected by the proposed
> aproach at all.
>
> And then we would have introduced a new handler name "proc_handler_new"
> and maybe have to do the whole thing again to rename it back to
> the original and well-known "proc_handler".
This aproach could be optimized by only migrating the usages of the
custom handler implementations to "proc_handler_new".
After this we could move over the core handlers and "proc_handler" in
one small patch that does not need to touch the usages sites.
Afterwards all non-core usages would be migrated back from
"proc_handler_new" to "proc_handler" and the _new variant could be
dropped again.
It would still be more than twice the churn of my current patch.
And these patches would be more complex than the current
"just add a bunch of consts, nothing else".
Personally I still prefer the original aproach.
Thomas
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Jakub Kicinski <kuba@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Joel Granados <j.granados@samsung.com>
Cc: Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-xfs@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
kexec@lists.infradead.org, linux-hardening@vger.kernel.org,
bridge@lists.linux.dev, lvs-devel@vger.kernel.org,
linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com,
linux-sctp@vger.kernel.org, linux-nfs@vger.kernel.org,
apparmor@lists.ubuntu.com
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Sat, 27 Apr 2024 09:40:43 +0200 [thread overview]
Message-ID: <38a87a0f-02c7-4072-9342-8f6697ea1a17@t-8ch.de> (raw)
In-Reply-To: <9e657181-866a-4626-82d0-e0030051b003@t-8ch.de>
On 2024-04-25 09:10:27+0000, Thomas Weißschuh wrote:
> On 2024-04-24 20:12:34+0000, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> >
> > Split this per subsystem, please.
>
> Unfortunately this would introduce an enormous amount of code churn.
>
> The function prototypes for each callback have to stay consistent.
> So a another callback member ("proc_handler_new") is needed and users
> would be migrated to it gradually.
>
> But then *all* definitions of "struct ctl_table" throughout the tree need to
> be touched.
> In contrast, the proposed series only needs to change the handler
> implementations, not their usage sites.
>
> There are many, many more usage sites than handler implementations.
>
> Especially, as the majority of sysctl tables use the standard handlers
> (proc_dostring, proc_dobool, ...) and are not affected by the proposed
> aproach at all.
>
> And then we would have introduced a new handler name "proc_handler_new"
> and maybe have to do the whole thing again to rename it back to
> the original and well-known "proc_handler".
This aproach could be optimized by only migrating the usages of the
custom handler implementations to "proc_handler_new".
After this we could move over the core handlers and "proc_handler" in
one small patch that does not need to touch the usages sites.
Afterwards all non-core usages would be migrated back from
"proc_handler_new" to "proc_handler" and the _new variant could be
dropped again.
It would still be more than twice the churn of my current patch.
And these patches would be more complex than the current
"just add a bunch of consts, nothing else".
Personally I still prefer the original aproach.
Thomas
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Jakub Kicinski <kuba@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Joel Granados <j.granados@samsung.com>
Cc: Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-xfs@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
kexec@lists.infradead.org, linux-hardening@vger.kernel.org,
bridge@lists.linux.dev, lvs-devel@vger.kernel.org,
linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com,
linux-sctp@vger.kernel.org, linux-nfs@vger.kernel.org,
apparmor@lists.ubuntu.com
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Sat, 27 Apr 2024 09:40:43 +0200 [thread overview]
Message-ID: <38a87a0f-02c7-4072-9342-8f6697ea1a17@t-8ch.de> (raw)
In-Reply-To: <9e657181-866a-4626-82d0-e0030051b003@t-8ch.de>
On 2024-04-25 09:10:27+0000, Thomas Weißschuh wrote:
> On 2024-04-24 20:12:34+0000, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> >
> > Split this per subsystem, please.
>
> Unfortunately this would introduce an enormous amount of code churn.
>
> The function prototypes for each callback have to stay consistent.
> So a another callback member ("proc_handler_new") is needed and users
> would be migrated to it gradually.
>
> But then *all* definitions of "struct ctl_table" throughout the tree need to
> be touched.
> In contrast, the proposed series only needs to change the handler
> implementations, not their usage sites.
>
> There are many, many more usage sites than handler implementations.
>
> Especially, as the majority of sysctl tables use the standard handlers
> (proc_dostring, proc_dobool, ...) and are not affected by the proposed
> aproach at all.
>
> And then we would have introduced a new handler name "proc_handler_new"
> and maybe have to do the whole thing again to rename it back to
> the original and well-known "proc_handler".
This aproach could be optimized by only migrating the usages of the
custom handler implementations to "proc_handler_new".
After this we could move over the core handlers and "proc_handler" in
one small patch that does not need to touch the usages sites.
Afterwards all non-core usages would be migrated back from
"proc_handler_new" to "proc_handler" and the _new variant could be
dropped again.
It would still be more than twice the churn of my current patch.
And these patches would be more complex than the current
"just add a bunch of consts, nothing else".
Personally I still prefer the original aproach.
Thomas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Jakub Kicinski <kuba@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Joel Granados <j.granados@samsung.com>
Cc: Dave Chinner <david@fromorbit.com>,
linux-mm@kvack.org, Eric Dumazet <edumazet@google.com>,
linux-hardening@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, rds-devel@oss.oracle.com,
linux-rdma@vger.kernel.org, linux-sctp@vger.kernel.org,
lvs-devel@vger.kernel.org, coreteam@netfilter.org,
linux-trace-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
bridge@lists.linux.dev, apparmor@lists.ubuntu.com,
linux-xfs@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
linux-security-module@vger.kernel.org,
netfilter-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Sat, 27 Apr 2024 09:40:43 +0200 [thread overview]
Message-ID: <38a87a0f-02c7-4072-9342-8f6697ea1a17@t-8ch.de> (raw)
In-Reply-To: <9e657181-866a-4626-82d0-e0030051b003@t-8ch.de>
On 2024-04-25 09:10:27+0000, Thomas Weißschuh wrote:
> On 2024-04-24 20:12:34+0000, Jakub Kicinski wrote:
> > On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> > > The series was split from my larger series sysctl-const series [0].
> > > It only focusses on the proc_handlers but is an important step to be
> > > able to move all static definitions of ctl_table into .rodata.
> >
> > Split this per subsystem, please.
>
> Unfortunately this would introduce an enormous amount of code churn.
>
> The function prototypes for each callback have to stay consistent.
> So a another callback member ("proc_handler_new") is needed and users
> would be migrated to it gradually.
>
> But then *all* definitions of "struct ctl_table" throughout the tree need to
> be touched.
> In contrast, the proposed series only needs to change the handler
> implementations, not their usage sites.
>
> There are many, many more usage sites than handler implementations.
>
> Especially, as the majority of sysctl tables use the standard handlers
> (proc_dostring, proc_dobool, ...) and are not affected by the proposed
> aproach at all.
>
> And then we would have introduced a new handler name "proc_handler_new"
> and maybe have to do the whole thing again to rename it back to
> the original and well-known "proc_handler".
This aproach could be optimized by only migrating the usages of the
custom handler implementations to "proc_handler_new".
After this we could move over the core handlers and "proc_handler" in
one small patch that does not need to touch the usages sites.
Afterwards all non-core usages would be migrated back from
"proc_handler_new" to "proc_handler" and the _new variant could be
dropped again.
It would still be more than twice the churn of my current patch.
And these patches would be more complex than the current
"just add a bunch of consts, nothing else".
Personally I still prefer the original aproach.
Thomas
next prev parent reply other threads:[~2024-04-27 7:40 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240423075608eucas1p265e7c90f3efd6995cb240b3d2688b803@eucas1p2.samsung.com>
2024-04-23 7:54 ` [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 01/11] stackleak: don't modify ctl_table argument Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 02/11] cgroup: bpf: constify ctl_table arguments and fields Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 03/11] hugetlb: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 04/11] utsname: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 05/11] neighbour: " Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 06/11] ipv4/sysctl: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 07/11] ipv6/addrconf: " Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 08/11] ipv6/ndisc: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 09/11] ipvs: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 10/11] sysctl: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 11/11] sysctl: treewide: constify the ctl_table argument of handlers Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-23 7:54 ` Thomas Weißschuh
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-29 9:47 ` Heiko Carstens
2024-04-23 18:31 ` [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-23 18:31 ` Luis Chamberlain
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh [this message]
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 11:04 ` Joel Granados
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-04-25 20:34 ` Thomas Weißschuh
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 11:37 ` Joel Granados
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-08 17:11 ` Kees Cook
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-09 1:00 ` Jakub Kicinski
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
2024-05-08 11:40 ` Joel Granados
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38a87a0f-02c7-4072-9342-8f6697ea1a17@t-8ch.de \
--to=linux@weissschuh.net \
--cc=apparmor@lists.ubuntu.com \
--cc=bpf@vger.kernel.org \
--cc=bridge@lists.linux.dev \
--cc=coreteam@netfilter.org \
--cc=david@fromorbit.com \
--cc=edumazet@google.com \
--cc=j.granados@samsung.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lvs-devel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=rds-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.