[ANNOUNCE] autofs 5.1.2 release

Hi all, An update is overdue so here it is. It's mostly a bug fix update. autofs == The package can be found at: ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5 It is autofs-5.1.2.tar.[gz|xz] No source rpm is there as it can be produced by using: rpmbuild -ts autofs-5.1.2.tar.gz and

Re: [PATCH] autofs4: Fix endless loop in autofs4_write

On Sat, 2016-06-11 at 09:09 +0800, Ian Kent wrote: > On Fri, 2016-06-10 at 19:07 +0200, Laurent Dufour wrote: > > The 'commit e9a7c2f1a548 ("autofs4: coding style fixes")' removed the > > check done on the __vfs_write()'s returned value in autofs4_write(). > > This

Re: [PATCH] autofs4: Fix endless loop in autofs4_write

On Sat, 2016-06-11 at 09:09 +0800, Ian Kent wrote: > On Fri, 2016-06-10 at 19:07 +0200, Laurent Dufour wrote: > > The 'commit e9a7c2f1a548 ("autofs4: coding style fixes")' removed the > > check done on the __vfs_write()'s returned value in autofs4_write(). > > This

Re: [PATCH] autofs4: Fix endless loop in autofs4_write

003a76c7dc0] c030d06c do_sys_open+0x1bc/0x2e0 > [c003a76c7e30] c0009260 system_call+0x38/0x108 > --- Exception: c01 (System Call) at 3fffa38a0988 > > Cc: Ian Kent <ra...@themaw.net> > Cc: aut...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: st

Re: [PATCH] autofs4: Fix endless loop in autofs4_write

003a76c7dc0] c030d06c do_sys_open+0x1bc/0x2e0 > [c003a76c7e30] c0009260 system_call+0x38/0x108 > --- Exception: c01 (System Call) at 3fffa38a0988 > > Cc: Ian Kent > Cc: aut...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: sta...@vger.kernel.org >

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Thu, 2016-06-09 at 10:27 -0700, Andrei Vagin wrote: > On Wed, Jun 8, 2016 at 6:23 PM, Ian Kent <ra...@themaw.net> wrote: > > On Mon, 2016-05-30 at 13:52 +0800, Ian Kent wrote: > > > On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote: > > > > On Mon, 2016-05-2

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Thu, 2016-06-09 at 10:27 -0700, Andrei Vagin wrote: > On Wed, Jun 8, 2016 at 6:23 PM, Ian Kent wrote: > > On Mon, 2016-05-30 at 13:52 +0800, Ian Kent wrote: > > > On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote: > > > > On Mon, 2016-05-23 at 14:50 -0700, Andrei

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Mon, 2016-05-30 at 13:52 +0800, Ian Kent wrote: > On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote: > > On Mon, 2016-05-23 at 14:50 -0700, Andrei Vagin wrote: > > > Hi Ian, > > > > > > When are you going to apply this patch? We can't test linux-next withou

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Mon, 2016-05-30 at 13:52 +0800, Ian Kent wrote: > On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote: > > On Mon, 2016-05-23 at 14:50 -0700, Andrei Vagin wrote: > > > Hi Ian, > > > > > > When are you going to apply this patch? We can't test linux-next withou

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote: > On Mon, 2016-05-23 at 14:50 -0700, Andrei Vagin wrote: > > Hi Ian, > > > > When are you going to apply this patch? We can't test linux-next without it. > > I though I sent this with the last series but I can't s

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote: > On Mon, 2016-05-23 at 14:50 -0700, Andrei Vagin wrote: > > Hi Ian, > > > > When are you going to apply this patch? We can't test linux-next without it. > > I though I sent this with the last series but I can't s

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

planning to do after the current merge window closes (which is about now I guess). I'll include it in that series. Sorry for the hold up, ;) Ian > > Thanks, > Andrew > > > On Fri, Apr 1, 2016 at 12:37 AM, Ian Kent <ra...@themaw.net> wrote: > > On Thu, 2016-0

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

planning to do after the current merge window closes (which is about now I guess). I'll include it in that series. Sorry for the hold up, ;) Ian > > Thanks, > Andrew > > > On Fri, Apr 1, 2016 at 12:37 AM, Ian Kent wrote: > > On Thu, 2016-03-31 at 22:12 -0700, Andrey Vagi

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Thu, 2016-03-31 at 22:12 -0700, Andrey Vagin wrote: > From: Andrey Vagin <ava...@openvz.org> > > __vfs_write() returns a negative value in a error case. Ha, right, I'll send this along to Andrew with my next series which should be soon. > > Cc: Ian Kent <ra...@

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

On Thu, 2016-03-31 at 22:12 -0700, Andrey Vagin wrote: > From: Andrey Vagin > > __vfs_write() returns a negative value in a error case. Ha, right, I'll send this along to Andrew with my next series which should be soon. > > Cc: Ian Kent > Signed-off-by: Andrey Vagin &

Re: call_usermodehelper in containers

On Fri, 2016-03-25 at 02:28 +0100, Oleg Nesterov wrote: > Hi Ian, > > I can't really recall this old discussion, so I can be easily wrong... > > On 03/24, Ian Kent wrote: > > > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > > > >

Re: call_usermodehelper in containers

On Fri, 2016-03-25 at 02:28 +0100, Oleg Nesterov wrote: > Hi Ian, > > I can't really recall this old discussion, so I can be easily wrong... > > On 03/24, Ian Kent wrote: > > > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > > > >

Re: call_usermodehelper in containers

On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > On 11/15, Eric W. Biederman wrote: > > > > I don't understand that one. Having a preforked thread with the > > proper > > environment that can act like kthreadd in terms of spawning user > > mode > > helpers works and is simple. > >

Re: call_usermodehelper in containers

On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > On 11/15, Eric W. Biederman wrote: > > > > I don't understand that one. Having a preforked thread with the > > proper > > environment that can act like kthreadd in terms of spawning user > > mode > > helpers works and is simple. > >

Re: fs: NULL deref in atime_needs_update

On Wed, 2016-02-17 at 00:40 +0100, Mickaël Salaün wrote: > Hi, > > Actually I found the same bug (without fuzzing) and I can reproduce it > in a deterministic way (e.g. by creating a LSM that return 1 for the > security_file_open hook). At least, from v4.2.8 I can easily trigger > traces like

Re: fs: NULL deref in atime_needs_update

On Wed, 2016-02-17 at 00:40 +0100, Mickaël Salaün wrote: > Hi, > > Actually I found the same bug (without fuzzing) and I can reproduce it > in a deterministic way (e.g. by creating a LSM that return 1 for the > security_file_open hook). At least, from v4.2.8 I can easily trigger > traces like

Re: call_usermodehelper in containers

On Tue, 2016-02-23 at 09:36 -0500, J. Bruce Fields wrote: > On Tue, Feb 23, 2016 at 10:55:30AM +0800, Ian Kent wrote: > > You know, wrt. the mechanism Oleg suggested, I've been wondering if > > it's > > even necessary to capture process template information for > >

Re: call_usermodehelper in containers

On Tue, 2016-02-23 at 09:36 -0500, J. Bruce Fields wrote: > On Tue, Feb 23, 2016 at 10:55:30AM +0800, Ian Kent wrote: > > You know, wrt. the mechanism Oleg suggested, I've been wondering if > > it's > > even necessary to capture process template information for > >

Re: call_usermodehelper in containers

On Fri, 2016-02-19 at 13:14 +0800, Ian Kent wrote: > On Thu, 2016-02-18 at 14:45 -0600, Eric W. Biederman wrote: > > Ian Kent <ra...@themaw.net> writes: > > > > > On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > > > > On Thu, 2016-02-

Re: call_usermodehelper in containers

On Fri, 2016-02-19 at 13:14 +0800, Ian Kent wrote: > On Thu, 2016-02-18 at 14:45 -0600, Eric W. Biederman wrote: > > Ian Kent writes: > > > > > On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > > > > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki

Re: call_usermodehelper in containers

On Fri, 2016-02-19 at 18:30 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/19 14:37, Ian Kent wrote: > > On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: > > > On 2016/02/19 5:45, Eric W. Biederman wrote: > > > > Personally I am a fan of the don't be cleve

Re: call_usermodehelper in containers

On Fri, 2016-02-19 at 18:30 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/19 14:37, Ian Kent wrote: > > On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: > > > On 2016/02/19 5:45, Eric W. Biederman wrote: > > > > Personally I am a fan of the don't be cleve

Re: call_usermodehelper in containers

On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/19 5:45, Eric W. Biederman wrote: > > Personally I am a fan of the don't be clever and capture a kernel > > thread > > approach as it is very easy to see you what if any exploitation > > opportunities there are. The

Re: call_usermodehelper in containers

On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/19 5:45, Eric W. Biederman wrote: > > Personally I am a fan of the don't be clever and capture a kernel > > thread > > approach as it is very easy to see you what if any exploitation > > opportunities there are. The

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 14:45 -0600, Eric W. Biederman wrote: > Ian Kent <ra...@themaw.net> writes: > > > On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > > > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > > > > On 20

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 14:45 -0600, Eric W. Biederman wrote: > Ian Kent writes: > > > On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > > > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > > > > On 2016/02/18 11:57, Eric W. Biederman

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > > > Ccing The containers list because a related discussion is > > > happening > >

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > > > Ccing The containers list because a related discussion is > > > happening > >

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > Ccing The containers list because a related discussion is happening > > there > > and somehow this thread has never made it there. > > >

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > Ccing The containers list because a related discussion is happening > > there > > and somehow this thread has never made it there. > > > > Ia

Re: call_usermodehelper in containers

On Sat, 2016-02-13 at 17:08 +0100, Stanislav Kinsburskiy wrote: > > 13.02.2016 00:39, Ian Kent пишет: > > On Fri, 2013-11-15 at 15:54 +0400, Stanislav Kinsbursky wrote: > > > 15.11.2013 15:03, Eric W. Biederman пишет: > > > > Stanislav Kinsbursky &

Re: call_usermodehelper in containers

On Sat, 2016-02-13 at 17:08 +0100, Stanislav Kinsburskiy wrote: > > 13.02.2016 00:39, Ian Kent пишет: > > On Fri, 2013-11-15 at 15:54 +0400, Stanislav Kinsbursky wrote: > > > 15.11.2013 15:03, Eric W. Biederman пишет: > > > > Stanislav Kinsbursky writes: > >

Re: call_usermodehelper in containers

On Fri, 2013-11-15 at 15:54 +0400, Stanislav Kinsbursky wrote: > 15.11.2013 15:03, Eric W. Biederman пишет: > > Stanislav Kinsbursky writes: > > > > > 12.11.2013 17:30, Jeff Layton пишет: > > > > On Tue, 12 Nov 2013 17:02:36 +0400 > > > > Stanislav Kinsbursky wrote: > > > > > > > > >

Re: call_usermodehelper in containers

On Fri, 2013-11-15 at 15:54 +0400, Stanislav Kinsbursky wrote: > 15.11.2013 15:03, Eric W. Biederman пишет: > > Stanislav Kinsbursky writes: > > > > > 12.11.2013 17:30, Jeff Layton пишет: > > > > On Tue, 12 Nov 2013 17:02:36 +0400 > > > > Stanislav Kinsbursky

Re: call_usermodehelper in containers

On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > On 11/15, Eric W. Biederman wrote: > > > > I don't understand that one. Having a preforked thread with the > > proper > > environment that can act like kthreadd in terms of spawning user > > mode > > helpers works and is simple. Forgive

Re: call_usermodehelper in containers

On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > On 11/15, Eric W. Biederman wrote: > > > > I don't understand that one. Having a preforked thread with the > > proper > > environment that can act like kthreadd in terms of spawning user > > mode > > helpers works and is simple. Forgive

Re: [PATCH] autofs: show pipe inode in mount options

On Tue, 2016-01-26 at 11:55 +0800, Ian Kent wrote: > On Mon, 2016-01-25 at 15:48 -0800, Andrew Morton wrote: > > On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell < > > s...@canb.auug.org.au> wrote: > > > > > Hi Ian, > > > > > > On

Re: [PATCH] autofs: show pipe inode in mount options

On Tue, 2016-01-26 at 11:55 +0800, Ian Kent wrote: > On Mon, 2016-01-25 at 15:48 -0800, Andrew Morton wrote: > > On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell < > > s...@canb.auug.org.au> wrote: > > > > > Hi Ian, > > > > > > On Sat,

Re: [PATCH] autofs: show pipe inode in mount options

On Mon, 2016-01-25 at 15:48 -0800, Andrew Morton wrote: > On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell < > s...@canb.auug.org.au> wrote: > > > Hi Ian, > > > > On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent > > wrote: > > > > >

Re: [PATCH] autofs: show pipe inode in mount options

On Mon, 2016-01-25 at 15:48 -0800, Andrew Morton wrote: > On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell < > s...@canb.auug.org.au> wrote: > > > Hi Ian, > > > > On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent <ra...@themaw.net> > > wrote: > >

Re: [PATCH] autofs: show pipe inode in mount options

On Sat, 2016-01-23 at 08:30 +0800, Ian Kent wrote: > On Fri, 2016-01-22 at 12:34 +0100, Stanislav Kinsburskiy wrote: > > Hi again, > > > > I would like to ask about any progress with this patch? > > Any other requirements to make it able to merge? > >

Re: [PATCH] autofs: show pipe inode in mount options

On Fri, 2016-01-22 at 12:34 +0100, Stanislav Kinsburskiy wrote: > Hi again, > > I would like to ask about any progress with this patch? > Any other requirements to make it able to merge? Sorry for the delay. Since there haven't been any comments from Al or Stephen I'm think I should include it

Re: [PATCH] autofs: show pipe inode in mount options

On Fri, 2016-01-22 at 12:34 +0100, Stanislav Kinsburskiy wrote: > Hi again, > > I would like to ask about any progress with this patch? > Any other requirements to make it able to merge? Sorry for the delay. Since there haven't been any comments from Al or Stephen I'm think I should include it

Re: [PATCH] autofs: show pipe inode in mount options

On Sat, 2016-01-23 at 08:30 +0800, Ian Kent wrote: > On Fri, 2016-01-22 at 12:34 +0100, Stanislav Kinsburskiy wrote: > > Hi again, > > > > I would like to ask about any progress with this patch? > > Any other requirements to make it able to merge? > >

Re: [RFC] A couple of questions about the paged I/O sub system

On Thu, 2015-10-22 at 18:54 -0700, Hugh Dickins wrote: > On Thu, 22 Oct 2015, Ian Kent wrote: > > On Wed, 2015-10-21 at 12:56 -0700, Hugh Dickins wrote: > > > On Wed, 21 Oct 2015, Ian Kent wrote: > > > > Thanks for taking the time to reply Hugh. > > > >

Re: [RFC] A couple of questions about the paged I/O sub system

On Thu, 2015-10-22 at 18:54 -0700, Hugh Dickins wrote: > On Thu, 22 Oct 2015, Ian Kent wrote: > > On Wed, 2015-10-21 at 12:56 -0700, Hugh Dickins wrote: > > > On Wed, 21 Oct 2015, Ian Kent wrote: > > > > Thanks for taking the time to reply Hugh. > > > >

Re: [RFC] A couple of questions about the paged I/O sub system

On Wed, 2015-10-21 at 12:56 -0700, Hugh Dickins wrote: > On Wed, 21 Oct 2015, Ian Kent wrote: Thanks for taking the time to reply Hugh. > > > Hi all, > > > > I've been looking through some of the page reclaim code and at > > truncate_inode_pages(). > >

[RFC] A couple of questions about the paged I/O sub system

Hi all, I've been looking through some of the page reclaim code and at truncate_inode_pages(). I'm not familiar with the code and I'm struggling to understand it. One thing that is puzzling me right now is, if a file has pages that have been modified and are swapped out when

Re: [RFC] A couple of questions about the paged I/O sub system

On Wed, 2015-10-21 at 12:56 -0700, Hugh Dickins wrote: > On Wed, 21 Oct 2015, Ian Kent wrote: Thanks for taking the time to reply Hugh. > > > Hi all, > > > > I've been looking through some of the page reclaim code and at > > truncate_inode_pages(). > >

[RFC] A couple of questions about the paged I/O sub system

Hi all, I've been looking through some of the page reclaim code and at truncate_inode_pages(). I'm not familiar with the code and I'm struggling to understand it. One thing that is puzzling me right now is, if a file has pages that have been modified and are swapped out when

Re: [RFC] freeing unlinked file indefinitely delayed

On Sun, 2015-07-12 at 16:17 +0100, Al Viro wrote: > On Thu, Jul 09, 2015 at 07:26:44PM +0800, Ian Kent wrote: > > > But the dentrys that will most likely face summary execution will be > > > hashed, such as was the case on that 2.6.32 kernel at dput(). > > > > >

Re: [RFC] freeing unlinked file indefinitely delayed

On Sun, 2015-07-12 at 16:17 +0100, Al Viro wrote: On Thu, Jul 09, 2015 at 07:26:44PM +0800, Ian Kent wrote: But the dentrys that will most likely face summary execution will be hashed, such as was the case on that 2.6.32 kernel at dput(). Doesn't that mean that something dropped

Re: [RFC] freeing unliked file indefinitely delayed

On Thu, 2015-07-09 at 19:17 +0800, Ian Kent wrote: > On Wed, 2015-07-08 at 02:42 +0100, Al Viro wrote: > > Normally opening a file, unlinking it and then closing will have > > the inode freed upon close() (provided that it's not otherwise busy and > > has no remai

Re: [RFC] freeing unliked file indefinitely delayed

On Wed, 2015-07-08 at 02:42 +0100, Al Viro wrote: > Normally opening a file, unlinking it and then closing will have > the inode freed upon close() (provided that it's not otherwise busy and > has no remaining links, of course). However, there's one case where that > does *not* happen.

Re: [RFC] freeing unliked file indefinitely delayed

On Wed, 2015-07-08 at 02:42 +0100, Al Viro wrote: Normally opening a file, unlinking it and then closing will have the inode freed upon close() (provided that it's not otherwise busy and has no remaining links, of course). However, there's one case where that does *not* happen. Namely,

Re: [RFC] freeing unliked file indefinitely delayed

On Thu, 2015-07-09 at 19:17 +0800, Ian Kent wrote: On Wed, 2015-07-08 at 02:42 +0100, Al Viro wrote: Normally opening a file, unlinking it and then closing will have the inode freed upon close() (provided that it's not otherwise busy and has no remaining links, of course). However

Re: [PATCH 3.2 059/221] autofs4: check dev ioctl size before allocating

in > > commit e53d77eb8bb616e903e34cc7a918401bee3b5149 upstream. > > There wasn't any check of the size passed from userspace before trying > to allocate the memory required. > > This meant that userspace might request more space than allowed, > triggering an OOM. > > Signed-off-by: Sas

Re: [PATCH 3.2 059/221] autofs4: check dev ioctl size before allocating

-off-by: Ian Kent ra...@themaw.net Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Ben Hutchings b...@decadent.org.uk --- fs/autofs4/dev-ioctl.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/autofs4/dev

[ANNOUNCE] autofs 5.0.10 release

Hi all, The thing to watch out for in this release is a change made to program map execution environments. The standard environment added at program map execution introduced a security problem when interpreted languages like python were used. By default, a prefix is now added to these names to

[ANNOUNCE] autofs 5.1.1 release

Hi all, The thing to watch out for in this release is a change made to program map execution environments. The standard environment added at program map execution introduced a security problem when interpreted languages like python were used. By default, a prefix is now added to these names to

[ANNOUNCE] autofs 5.0.10 release

Hi all, The thing to watch out for in this release is a change made to program map execution environments. The standard environment added at program map execution introduced a security problem when interpreted languages like python were used. By default, a prefix is now added to these names to

[ANNOUNCE] autofs 5.1.1 release

Hi all, The thing to watch out for in this release is a change made to program map execution environments. The standard environment added at program map execution introduced a security problem when interpreted languages like python were used. By default, a prefix is now added to these names to

Re: [RFC PATCH 5 7/7] KEYS: exec request key within service thread of key creator

On Thu, 2015-04-02 at 13:58 +0100, David Howells wrote: > Ian Kent wrote: > > > + > > + /* Namespace token */ > > + int umh_token; > > If you could put it after data_len so that all the smaller-than-wordsize > fields are together for better packing. OK. &g

Re: [RFC PATCH 5 1/7] kmod - add workqueue service thread store

On Thu, 2015-04-02 at 13:43 +0100, David Howells wrote: > Ian Kent wrote: > > > +static struct umh_wq_entry *umh_wq_find_entry(int token) > > +{ > > + struct umh_wq_entry *this, *entry; > > + struct hlist_head *bucket; > > + unsigned int hash; > &g

Re: [RFC PATCH 5 7/7] KEYS: exec request key within service thread of key creator

On Thu, 2015-04-02 at 13:58 +0100, David Howells wrote: Ian Kent ra...@themaw.net wrote: + + /* Namespace token */ + int umh_token; If you could put it after data_len so that all the smaller-than-wordsize fields are together for better packing. OK

Re: [RFC PATCH 5 1/7] kmod - add workqueue service thread store

On Thu, 2015-04-02 at 13:43 +0100, David Howells wrote: Ian Kent ra...@themaw.net wrote: +static struct umh_wq_entry *umh_wq_find_entry(int token) +{ + struct umh_wq_entry *this, *entry; + struct hlist_head *bucket; + unsigned int hash; + + hash = hash_32((unsigned long

Re: [RFC PATCH 5 3/7] nfsd - use service thread if not executing in init namespace

On Tue, 2015-03-31 at 09:14 -0400, J. Bruce Fields wrote: > On Tue, Mar 31, 2015 at 11:14:58AM +0800, Ian Kent wrote: > > From: Ian Kent > > > > If nfsd is running within a container the client tracking operations > > should run within their originating container also.

Re: [RFC PATCH 5 1/7] kmod - add workqueue service thread store

On Tue, 2015-03-31 at 07:21 -0400, Jeff Layton wrote: > On Tue, 31 Mar 2015 11:14:42 +0800 > Ian Kent wrote: > > > From: Ian Kent > > > > Persistent use of process information is needed for contained > > execution in a namespace other than the root init namesp

Re: [RFC PATCH 5 1/7] kmod - add workqueue service thread store

On Tue, 2015-03-31 at 07:21 -0400, Jeff Layton wrote: On Tue, 31 Mar 2015 11:14:42 +0800 Ian Kent ra...@themaw.net wrote: From: Ian Kent ik...@redhat.com Persistent use of process information is needed for contained execution in a namespace other than the root init namespace. Use

Re: [RFC PATCH 5 3/7] nfsd - use service thread if not executing in init namespace

On Tue, 2015-03-31 at 09:14 -0400, J. Bruce Fields wrote: On Tue, Mar 31, 2015 at 11:14:58AM +0800, Ian Kent wrote: From: Ian Kent ik...@redhat.com If nfsd is running within a container the client tracking operations should run within their originating container also. To do that get

[RFC PATCH 5 4/7] nfs - cache_lib use service thread if not executing in init namespace

From: Ian Kent If pipefs is registered within a container pipefs requests should be run within their originating container also. To do that get a token to a service thread created within the container environment for usermode helper calls. Signed-off-by: Ian Kent Cc: Benjamin Coddington Cc

[RFC PATCH 5 6/7] KEYS - use correct memory allocation flag in call_usermodehelper_keys()

From: Ian Kent When call_usermodehelper_keys() is called it assumes it won't be called with the flag UMH_NO_WAIT. Currently that's always the case. Change this to check the flag and use the correct kernel memory allocation flag to guard against future changes. Signed-off-by: Ian Kent Cc

[RFC PATCH 5 7/7] KEYS: exec request key within service thread of key creator

From: Ian Kent Containerized request key helper callbacks need the ability to execute a binary in a container's context. To do that get a token to a service thread created within the container environment for usermode helper calls. Signed-off-by: Ian Kent Cc: Benjamin Coddington Cc: Al Viro

[RFC PATCH 5 5/7] nfs - objlayout use service thread if not executing in init namespace

From: Ian Kent If the caller is running within a container then execute the usermode helper callback within the container also. Signed-off-by: Ian Kent Cc: Benjamin Coddington Cc: Al Viro Cc: J. Bruce Fields Cc: David Howells Cc: Trond Myklebust Cc: Oleg Nesterov Cc: Eric W. Biederman

[RFC PATCH 5 3/7] nfsd - use service thread if not executing in init namespace

From: Ian Kent If nfsd is running within a container the client tracking operations should run within their originating container also. To do that get a token to a service thread created within the container environment for usermode helper calls. Signed-off-by: Ian Kent Cc: Benjamin Coddington

[RFC PATCH 5 1/7] kmod - add workqueue service thread store

From: Ian Kent Persistent use of process information is needed for contained execution in a namespace other than the root init namespace. Use a simple random token as a key to create and store thread information in a hashed list for use by the usermode helper thread runner. Signed-off-by: Ian

[RFC PATCH v5 0/7] Another attempt at contained helper execution

like to get feedback as to whether I'm on the right track and what I might be missing before spending more time on it. --- Ian Kent (7): kmod - add workqueue service thread store kmod - teach usermodehelper to use service workqueues nfsd - use service thread if not executing

[RFC PATCH 5 2/7] kmod - teach usermodehelper to use service workqueues

nvironment. This can be done by creating a service thread, identified by issuing a token identifier, used when executing the helper with a function that takes the token as a parameter. Signed-off-by: Ian Kent Cc: Benjamin Coddington Cc: Al Viro Cc: J. Bruce Fields Cc: David Howells Cc: Trond

[RFC PATCH 5 3/7] nfsd - use service thread if not executing in init namespace

From: Ian Kent ik...@redhat.com If nfsd is running within a container the client tracking operations should run within their originating container also. To do that get a token to a service thread created within the container environment for usermode helper calls. Signed-off-by: Ian Kent ik

[RFC PATCH 5 1/7] kmod - add workqueue service thread store

From: Ian Kent ik...@redhat.com Persistent use of process information is needed for contained execution in a namespace other than the root init namespace. Use a simple random token as a key to create and store thread information in a hashed list for use by the usermode helper thread runner

[RFC PATCH v5 0/7] Another attempt at contained helper execution

like to get feedback as to whether I'm on the right track and what I might be missing before spending more time on it. --- Ian Kent (7): kmod - add workqueue service thread store kmod - teach usermodehelper to use service workqueues nfsd - use service thread if not executing

[RFC PATCH 5 2/7] kmod - teach usermodehelper to use service workqueues

. This can be done by creating a service thread, identified by issuing a token identifier, used when executing the helper with a function that takes the token as a parameter. Signed-off-by: Ian Kent ik...@redhat.com Cc: Benjamin Coddington bcodd...@redhat.com Cc: Al Viro v...@zeniv.linux.org.uk Cc

[RFC PATCH 5 5/7] nfs - objlayout use service thread if not executing in init namespace

From: Ian Kent ik...@redhat.com If the caller is running within a container then execute the usermode helper callback within the container also. Signed-off-by: Ian Kent ik...@redhat.com Cc: Benjamin Coddington bcodd...@redhat.com Cc: Al Viro v...@zeniv.linux.org.uk Cc: J. Bruce Fields bfie

[RFC PATCH 5 7/7] KEYS: exec request key within service thread of key creator

From: Ian Kent ik...@redhat.com Containerized request key helper callbacks need the ability to execute a binary in a container's context. To do that get a token to a service thread created within the container environment for usermode helper calls. Signed-off-by: Ian Kent ik...@redhat.com Cc

[RFC PATCH 5 4/7] nfs - cache_lib use service thread if not executing in init namespace

From: Ian Kent ik...@redhat.com If pipefs is registered within a container pipefs requests should be run within their originating container also. To do that get a token to a service thread created within the container environment for usermode helper calls. Signed-off-by: Ian Kent ik

[RFC PATCH 5 6/7] KEYS - use correct memory allocation flag in call_usermodehelper_keys()

From: Ian Kent ik...@redhat.com When call_usermodehelper_keys() is called it assumes it won't be called with the flag UMH_NO_WAIT. Currently that's always the case. Change this to check the flag and use the correct kernel memory allocation flag to guard against future changes. Signed-off

Re: [RFC PATCH v4 03/12] vfs - move mnt_namespace definition to linux/mount.h

On Thu, 2015-03-19 at 20:14 -0500, Eric W. Biederman wrote: > Ian Kent writes: > > 2> On Thu, 2015-03-19 at 19:47 +, Al Viro wrote: > >> On Tue, Mar 17, 2015 at 10:45:09AM +0800, Ian Kent wrote: > >> > From: Ian Kent > >> > > >> > Th

Re: [RFC PATCH v4 00/12] Second attempt at contained helper execution

On Thu, 2015-03-19 at 16:38 -0500, Eric W. Biederman wrote: > Ian Kent writes: > > > Here is another update to the attempt at contained helper execution. > > > > The main change is I've tried to incorporate Oleg's suggestions > > of directly constructing th

Re: [RFC PATCH v4 03/12] vfs - move mnt_namespace definition to linux/mount.h

On Thu, 2015-03-19 at 19:47 +, Al Viro wrote: > On Tue, Mar 17, 2015 at 10:45:09AM +0800, Ian Kent wrote: > > From: Ian Kent > > > > The mnt_namespace definition will be needed by the usermode helper > > contained execution implementation, move it to include/l

Re: [RFC PATCH v4 03/12] vfs - move mnt_namespace definition to linux/mount.h

On Thu, 2015-03-19 at 19:47 +, Al Viro wrote: On Tue, Mar 17, 2015 at 10:45:09AM +0800, Ian Kent wrote: From: Ian Kent ik...@redhat.com The mnt_namespace definition will be needed by the usermode helper contained execution implementation, move it to include/linux/mount.h. I really

Re: [RFC PATCH v4 00/12] Second attempt at contained helper execution

On Thu, 2015-03-19 at 16:38 -0500, Eric W. Biederman wrote: Ian Kent ra...@themaw.net writes: Here is another update to the attempt at contained helper execution. The main change is I've tried to incorporate Oleg's suggestions of directly constructing the namespaces rather than using

Re: [RFC PATCH v4 03/12] vfs - move mnt_namespace definition to linux/mount.h

On Thu, 2015-03-19 at 20:14 -0500, Eric W. Biederman wrote: Ian Kent ra...@themaw.net writes: 2 On Thu, 2015-03-19 at 19:47 +, Al Viro wrote: On Tue, Mar 17, 2015 at 10:45:09AM +0800, Ian Kent wrote: From: Ian Kent ik...@redhat.com The mnt_namespace definition will be needed

[RFC PATCH v4 02/12] kmod - rename call_usermodehelper() flags parameter

From: Ian Kent The wait parameter of call_usermodehelper() is not quite a parameter that describes the wait behaviour alone and will later be used to request execution within the current namespaces. This flag is tied to the wait field of the subprocess_info structure which is also a field

[RFC PATCH v4 05/12] kmod - teach call_usermodehelper() to use a namespace

From: Ian Kent The call_usermodehelper() function executes all binaries in the global "init" root context. This doesn't allow a binary to be run within a namespace (eg. the namespaces of a container). The init process of the callers environment is used to setup the namespaces in almos

[RFC PATCH v4 04/12] kmod - add namespace aware thread runner

From: Ian Kent Make usermode helper thread runner namespace aware. Signed-off-by: Ian Kent Cc: Benjamin Coddington Cc: Al Viro Cc: J. Bruce Fields Cc: David Howells Cc: Trond Myklebust Cc: Oleg Nesterov Cc: Eric W. Biederman Cc: Jeff Layton --- include/linux/kmod.h | 12

<    2   3   4   5   6   7   8   9   10   11   >