From: Luis Chamberlain <mcgrof@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: keescook@chromium.org, yzaikin@google.com, nixiaoming@huawei.com,
ebiederm@xmission.com, axboe@kernel.dk, clemens@ladisch.de,
arnd@arndb.de, gregkh@linuxfoundation.org,
joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
airlied@linux.ie, daniel@ffwll.ch, benh@kernel.crashing.org,
rdna@fb.com, viro@zeniv.linux.org.uk, mark@fasheh.com,
jlbec@evilplan.org, joseph.qi@linux.alibaba.com, vbabka@suse.cz,
sfr@canb.auug.org.au, jack@suse.cz, amir73il@gmail.com,
rafael@kernel.org, tytso@mit.edu, julia.lawall@lip6.fr,
akpm@linux-foundation.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
Date: Fri, 29 May 2020 12:16:40 +0000 [thread overview]
Message-ID: <20200529121640.GE11244@42.do-not-panic.com> (raw)
In-Reply-To: <87d06n17mm.fsf@intel.com>
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Luis Chamberlain <mcgrof@kernel.org> wrote:
> > Often enough all we need to do is create a subdirectory so that
> > we can stuff sysctls underneath it. However, *if* that directory
> > was already created early on the boot sequence we really have no
> > need to use the full boiler plate code for it, we can just use
> > local variables to help us guide sysctl to place the new leaf files.
>
> I find it hard to figure out the lifetime requirements for the tables
> passed in; when it's okay to use local variables and when you need
> longer lifetimes. It's not documented, everyone appears to be using
> static tables for this. It's far from obvious.
I agree 2000% that it is not obvious. What made me consider it was that
I *knew* that the base directory would already exist, so it wouldn't
make sense for the code to rely on earlier parts of a table if part
of the hierarchy already existed.
In fact, a *huge* part of the due dilligence on this and futre series
on this cleanup will be to be 100% sure that the base path is already
created. And so this use is obviously dangerous, you just *need* to
know that the base path is created before.
Non-posted changes also deal with link order to help address this
in other places, given that link order controls how *initcalls()
(early_initcall(), late_initcall(), etc) are ordered if you have
multiple of these.
I had a link order series long ago which augmented our ability to make
things clearer at a link order. Eventually I believe this will become
more important, specially as we end up wanting to async more code.
For now, we can only rely on manual code inspection for ensuring
proper ordering. Part of the implicit aspects of this cleanup is
to slowly make these things clearer for each base path.
So... the "fs" base path will actually end up being created in
fs/sysctl.c after we are *fully* done with the fs sysctl cleanups.
Luis
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: jack@suse.cz, rafael@kernel.org, airlied@linux.ie,
amir73il@gmail.com, clemens@ladisch.de,
dri-devel@lists.freedesktop.org, joseph.qi@linux.alibaba.com,
sfr@canb.auug.org.au, mark@fasheh.com, rdna@fb.com,
yzaikin@google.com, keescook@chromium.org, arnd@arndb.de,
intel-gfx@lists.freedesktop.org, julia.lawall@lip6.fr,
jlbec@evilplan.org, rodrigo.vivi@intel.com,
nixiaoming@huawei.com, vbabka@suse.cz, axboe@kernel.dk,
tytso@mit.edu, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk
Subject: [Ocfs2-devel] [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
Date: Fri, 29 May 2020 12:16:40 +0000 [thread overview]
Message-ID: <20200529121640.GE11244@42.do-not-panic.com> (raw)
In-Reply-To: <87d06n17mm.fsf@intel.com>
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Luis Chamberlain <mcgrof@kernel.org> wrote:
> > Often enough all we need to do is create a subdirectory so that
> > we can stuff sysctls underneath it. However, *if* that directory
> > was already created early on the boot sequence we really have no
> > need to use the full boiler plate code for it, we can just use
> > local variables to help us guide sysctl to place the new leaf files.
>
> I find it hard to figure out the lifetime requirements for the tables
> passed in; when it's okay to use local variables and when you need
> longer lifetimes. It's not documented, everyone appears to be using
> static tables for this. It's far from obvious.
I agree 2000% that it is not obvious. What made me consider it was that
I *knew* that the base directory would already exist, so it wouldn't
make sense for the code to rely on earlier parts of a table if part
of the hierarchy already existed.
In fact, a *huge* part of the due dilligence on this and futre series
on this cleanup will be to be 100% sure that the base path is already
created. And so this use is obviously dangerous, you just *need* to
know that the base path is created before.
Non-posted changes also deal with link order to help address this
in other places, given that link order controls how *initcalls()
(early_initcall(), late_initcall(), etc) are ordered if you have
multiple of these.
I had a link order series long ago which augmented our ability to make
things clearer at a link order. Eventually I believe this will become
more important, specially as we end up wanting to async more code.
For now, we can only rely on manual code inspection for ensuring
proper ordering. Part of the implicit aspects of this cleanup is
to slowly make these things clearer for each base path.
So... the "fs" base path will actually end up being created in
fs/sysctl.c after we are *fully* done with the fs sysctl cleanups.
Luis
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: jack@suse.cz, rafael@kernel.org, airlied@linux.ie,
amir73il@gmail.com, clemens@ladisch.de,
dri-devel@lists.freedesktop.org, joseph.qi@linux.alibaba.com,
sfr@canb.auug.org.au, mark@fasheh.com, rdna@fb.com,
yzaikin@google.com, joonas.lahtinen@linux.intel.com,
keescook@chromium.org, arnd@arndb.de,
intel-gfx@lists.freedesktop.org, julia.lawall@lip6.fr,
jlbec@evilplan.org, rodrigo.vivi@intel.com,
nixiaoming@huawei.com, vbabka@suse.cz, axboe@kernel.dk,
tytso@mit.edu, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
daniel@ffwll.ch, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, ocfs2-devel@oss.oracle.com,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
Date: Fri, 29 May 2020 12:16:40 +0000 [thread overview]
Message-ID: <20200529121640.GE11244@42.do-not-panic.com> (raw)
In-Reply-To: <87d06n17mm.fsf@intel.com>
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Luis Chamberlain <mcgrof@kernel.org> wrote:
> > Often enough all we need to do is create a subdirectory so that
> > we can stuff sysctls underneath it. However, *if* that directory
> > was already created early on the boot sequence we really have no
> > need to use the full boiler plate code for it, we can just use
> > local variables to help us guide sysctl to place the new leaf files.
>
> I find it hard to figure out the lifetime requirements for the tables
> passed in; when it's okay to use local variables and when you need
> longer lifetimes. It's not documented, everyone appears to be using
> static tables for this. It's far from obvious.
I agree 2000% that it is not obvious. What made me consider it was that
I *knew* that the base directory would already exist, so it wouldn't
make sense for the code to rely on earlier parts of a table if part
of the hierarchy already existed.
In fact, a *huge* part of the due dilligence on this and futre series
on this cleanup will be to be 100% sure that the base path is already
created. And so this use is obviously dangerous, you just *need* to
know that the base path is created before.
Non-posted changes also deal with link order to help address this
in other places, given that link order controls how *initcalls()
(early_initcall(), late_initcall(), etc) are ordered if you have
multiple of these.
I had a link order series long ago which augmented our ability to make
things clearer at a link order. Eventually I believe this will become
more important, specially as we end up wanting to async more code.
For now, we can only rely on manual code inspection for ensuring
proper ordering. Part of the implicit aspects of this cleanup is
to slowly make these things clearer for each base path.
So... the "fs" base path will actually end up being created in
fs/sysctl.c after we are *fully* done with the fs sysctl cleanups.
Luis
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: jack@suse.cz, rafael@kernel.org, airlied@linux.ie,
amir73il@gmail.com, clemens@ladisch.de,
dri-devel@lists.freedesktop.org, joseph.qi@linux.alibaba.com,
sfr@canb.auug.org.au, mark@fasheh.com, rdna@fb.com,
yzaikin@google.com, keescook@chromium.org, arnd@arndb.de,
intel-gfx@lists.freedesktop.org, julia.lawall@lip6.fr,
jlbec@evilplan.org, rodrigo.vivi@intel.com,
nixiaoming@huawei.com, vbabka@suse.cz, axboe@kernel.dk,
tytso@mit.edu, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk
Subject: Re: [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
Date: Fri, 29 May 2020 12:16:40 +0000 [thread overview]
Message-ID: <20200529121640.GE11244@42.do-not-panic.com> (raw)
In-Reply-To: <87d06n17mm.fsf@intel.com>
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Luis Chamberlain <mcgrof@kernel.org> wrote:
> > Often enough all we need to do is create a subdirectory so that
> > we can stuff sysctls underneath it. However, *if* that directory
> > was already created early on the boot sequence we really have no
> > need to use the full boiler plate code for it, we can just use
> > local variables to help us guide sysctl to place the new leaf files.
>
> I find it hard to figure out the lifetime requirements for the tables
> passed in; when it's okay to use local variables and when you need
> longer lifetimes. It's not documented, everyone appears to be using
> static tables for this. It's far from obvious.
I agree 2000% that it is not obvious. What made me consider it was that
I *knew* that the base directory would already exist, so it wouldn't
make sense for the code to rely on earlier parts of a table if part
of the hierarchy already existed.
In fact, a *huge* part of the due dilligence on this and futre series
on this cleanup will be to be 100% sure that the base path is already
created. And so this use is obviously dangerous, you just *need* to
know that the base path is created before.
Non-posted changes also deal with link order to help address this
in other places, given that link order controls how *initcalls()
(early_initcall(), late_initcall(), etc) are ordered if you have
multiple of these.
I had a link order series long ago which augmented our ability to make
things clearer at a link order. Eventually I believe this will become
more important, specially as we end up wanting to async more code.
For now, we can only rely on manual code inspection for ensuring
proper ordering. Part of the implicit aspects of this cleanup is
to slowly make these things clearer for each base path.
So... the "fs" base path will actually end up being created in
fs/sysctl.c after we are *fully* done with the fs sysctl cleanups.
Luis
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: jack@suse.cz, rafael@kernel.org, airlied@linux.ie,
benh@kernel.crashing.org, amir73il@gmail.com, clemens@ladisch.de,
dri-devel@lists.freedesktop.org, joseph.qi@linux.alibaba.com,
sfr@canb.auug.org.au, mark@fasheh.com, rdna@fb.com,
yzaikin@google.com, keescook@chromium.org, arnd@arndb.de,
intel-gfx@lists.freedesktop.org, julia.lawall@lip6.fr,
jlbec@evilplan.org, nixiaoming@huawei.com, vbabka@suse.cz,
axboe@kernel.dk, tytso@mit.edu, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk
Subject: Re: [Intel-gfx] [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
Date: Fri, 29 May 2020 12:16:40 +0000 [thread overview]
Message-ID: <20200529121640.GE11244@42.do-not-panic.com> (raw)
In-Reply-To: <87d06n17mm.fsf@intel.com>
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Luis Chamberlain <mcgrof@kernel.org> wrote:
> > Often enough all we need to do is create a subdirectory so that
> > we can stuff sysctls underneath it. However, *if* that directory
> > was already created early on the boot sequence we really have no
> > need to use the full boiler plate code for it, we can just use
> > local variables to help us guide sysctl to place the new leaf files.
>
> I find it hard to figure out the lifetime requirements for the tables
> passed in; when it's okay to use local variables and when you need
> longer lifetimes. It's not documented, everyone appears to be using
> static tables for this. It's far from obvious.
I agree 2000% that it is not obvious. What made me consider it was that
I *knew* that the base directory would already exist, so it wouldn't
make sense for the code to rely on earlier parts of a table if part
of the hierarchy already existed.
In fact, a *huge* part of the due dilligence on this and futre series
on this cleanup will be to be 100% sure that the base path is already
created. And so this use is obviously dangerous, you just *need* to
know that the base path is created before.
Non-posted changes also deal with link order to help address this
in other places, given that link order controls how *initcalls()
(early_initcall(), late_initcall(), etc) are ordered if you have
multiple of these.
I had a link order series long ago which augmented our ability to make
things clearer at a link order. Eventually I believe this will become
more important, specially as we end up wanting to async more code.
For now, we can only rely on manual code inspection for ensuring
proper ordering. Part of the implicit aspects of this cleanup is
to slowly make these things clearer for each base path.
So... the "fs" base path will actually end up being created in
fs/sysctl.c after we are *fully* done with the fs sysctl cleanups.
Luis
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-05-29 12:16 UTC|newest]
Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 7:40 [PATCH 00/13] sysctl: spring cleaning Luis Chamberlain
2020-05-29 7:40 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:40 ` [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper Luis Chamberlain
2020-05-29 7:40 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 8:13 ` Jani Nikula
2020-05-29 8:13 ` [Intel-gfx] " Jani Nikula
2020-05-29 8:13 ` Jani Nikula
2020-05-29 8:13 ` Jani Nikula
2020-05-29 8:13 ` [Ocfs2-devel] " Jani Nikula
2020-05-29 12:16 ` Luis Chamberlain [this message]
2020-05-29 12:16 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 12:16 ` Luis Chamberlain
2020-05-29 12:16 ` Luis Chamberlain
2020-05-29 12:16 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 12:40 ` Eric W. Biederman
2020-05-29 12:40 ` [Intel-gfx] " Eric W. Biederman
2020-05-29 12:40 ` Eric W. Biederman
2020-05-29 12:40 ` [Ocfs2-devel] " Eric W. Biederman
2020-05-29 12:42 ` Eric W. Biederman
2020-05-29 12:42 ` [Intel-gfx] " Eric W. Biederman
2020-05-29 12:42 ` Eric W. Biederman
2020-05-29 12:42 ` [Ocfs2-devel] " Eric W. Biederman
2020-05-29 7:40 ` [PATCH 02/13] cdrom: use new sysctl subdir helper register_sysctl_subdir() Luis Chamberlain
2020-05-29 7:40 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 12:46 ` Eric W. Biederman
2020-05-29 12:46 ` [Intel-gfx] " Eric W. Biederman
2020-05-29 12:46 ` Eric W. Biederman
2020-05-29 12:46 ` [Ocfs2-devel] " Eric W. Biederman
2020-05-29 7:40 ` [PATCH 03/13] hpet: " Luis Chamberlain
2020-05-29 7:40 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:40 ` [PATCH 04/13] i915: " Luis Chamberlain
2020-05-29 7:40 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` Luis Chamberlain
2020-05-29 7:40 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:41 ` [PATCH 05/13] macintosh/mac_hid.c: " Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:41 ` [PATCH 06/13] ocfs2: " Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 8:23 ` Kees Cook
2020-05-29 8:23 ` [Intel-gfx] " Kees Cook
2020-05-29 8:23 ` Kees Cook
2020-05-29 8:23 ` Kees Cook
2020-05-29 8:23 ` [Ocfs2-devel] " Kees Cook
2020-05-29 11:49 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 11:49 ` Luis Chamberlain
2020-05-29 11:49 ` Luis Chamberlain
2020-05-29 11:49 ` Luis Chamberlain
2020-05-29 11:49 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 14:49 ` Kees Cook
2020-05-29 14:49 ` Kees Cook
2020-05-29 14:49 ` Kees Cook
2020-05-29 14:49 ` Kees Cook
2020-05-29 14:49 ` [Ocfs2-devel] " Kees Cook
2020-05-29 7:41 ` [PATCH 07/13] test_sysctl: " Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:41 ` [PATCH 08/13] inotify: simplify sysctl declaration with register_sysctl_subdir() Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:41 ` [PATCH 09/13] firmware_loader: " Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 10:26 ` Greg KH
2020-05-29 10:26 ` [Intel-gfx] " Greg KH
2020-05-29 10:26 ` Greg KH
2020-05-29 10:26 ` Greg KH
2020-05-29 10:26 ` [Ocfs2-devel] " Greg KH
2020-05-29 11:59 ` Xiaoming Ni
2020-05-29 11:59 ` [Intel-gfx] " Xiaoming Ni
2020-05-29 11:59 ` Xiaoming Ni
2020-05-29 11:59 ` [Ocfs2-devel] " Xiaoming Ni
2020-05-29 12:09 ` Luis Chamberlain
2020-05-29 12:09 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 12:09 ` Luis Chamberlain
2020-05-29 12:09 ` Luis Chamberlain
2020-05-29 12:09 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:41 ` [PATCH 10/13] eventpoll: " Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 7:41 ` [PATCH 11/13] random: " Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 10:26 ` Greg KH
2020-05-29 10:26 ` [Intel-gfx] " Greg KH
2020-05-29 10:26 ` Greg KH
2020-05-29 10:26 ` Greg KH
2020-05-29 10:26 ` [Ocfs2-devel] " Greg KH
2020-05-29 12:09 ` Xiaoming Ni
2020-05-29 12:09 ` [Intel-gfx] " Xiaoming Ni
2020-05-29 12:09 ` Xiaoming Ni
2020-05-29 12:09 ` [Ocfs2-devel] " Xiaoming Ni
2020-05-29 7:41 ` [PATCH 12/13] sysctl: add helper to register empty subdir Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 8:15 ` Kees Cook
2020-05-29 8:15 ` [Intel-gfx] " Kees Cook
2020-05-29 8:15 ` Kees Cook
2020-05-29 8:15 ` Kees Cook
2020-05-29 8:15 ` [Ocfs2-devel] " Kees Cook
2020-05-29 13:03 ` Eric W. Biederman
2020-05-29 13:03 ` [Intel-gfx] " Eric W. Biederman
2020-05-29 13:03 ` Eric W. Biederman
2020-05-29 13:03 ` [Ocfs2-devel] " Eric W. Biederman
2021-11-17 3:30 ` Luis Chamberlain
2021-11-17 3:30 ` Luis Chamberlain
2021-11-17 3:30 ` [Intel-gfx] " Luis Chamberlain
2021-11-17 3:30 ` Luis Chamberlain
2020-05-29 7:41 ` [PATCH 13/13] fs: move binfmt_misc sysctl to its own file Luis Chamberlain
2020-05-29 7:41 ` [Intel-gfx] " Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` Luis Chamberlain
2020-05-29 7:41 ` [Ocfs2-devel] " Luis Chamberlain
2020-05-29 8:14 ` Kees Cook
2020-05-29 8:14 ` [Intel-gfx] " Kees Cook
2020-05-29 8:14 ` Kees Cook
2020-05-29 8:14 ` Kees Cook
2020-05-29 8:14 ` [Ocfs2-devel] " Kees Cook
2020-06-04 8:45 ` Xiaoming Ni
2020-06-04 8:45 ` [Intel-gfx] " Xiaoming Ni
2020-06-04 8:45 ` Xiaoming Ni
2020-06-04 8:45 ` Xiaoming Ni
2020-06-04 8:45 ` [Ocfs2-devel] " Xiaoming Ni
2020-05-29 7:42 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for sysctl: spring cleaning Patchwork
2020-06-04 13:16 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for sysctl: spring cleaning (rev2) Patchwork
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=20200529121640.GE11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=benh@kernel.crashing.org \
--cc=clemens@ladisch.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jack@suse.cz \
--cc=jani.nikula@linux.intel.com \
--cc=jlbec@evilplan.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=julia.lawall@lip6.fr \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark@fasheh.com \
--cc=nixiaoming@huawei.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=rafael@kernel.org \
--cc=rdna@fb.com \
--cc=rodrigo.vivi@intel.com \
--cc=sfr@canb.auug.org.au \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=yzaikin@google.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.