[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190814124551.hnt363g3blhuf2pv@wittgenstein>
Date: Wed, 14 Aug 2019 14:45:51 +0200
From: Christian Brauner <christian.brauner@...ntu.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org, libc-alpha@...rceware.org,
alistair23@...il.com, ebiederm@...ssion.com, arnd@...db.de,
dalias@...c.org, torvalds@...ux-foundation.org,
adhemerval.zanella@...aro.org, fweimer@...hat.com,
palmer@...ive.com, macro@....com, zongbox@...il.com,
akpm@...ux-foundation.org, viro@...iv.linux.org.uk, hpa@...or.com
Subject: Re: [PATCH v1 1/1] waitid: Add support for waiting for the current
process group
On Wed, Aug 14, 2019 at 02:29:10PM +0200, Oleg Nesterov wrote:
> On 08/14, christian.brauner@...ntu.com wrote:
> >
> > case P_PGID:
> > type = PIDTYPE_PGID;
> > - if (upid <= 0)
> > + if (upid < 0)
> > return -EINVAL;
> > +
> > + if (upid == 0)
> > + pid = get_pid(task_pgrp(current));
>
> this needs rcu lock or tasklist_lock, this can race with another thread
> doing sys_setpgid/setsid (see change_pid(PIDTYPE_PGID)).
Oh, I naively assumed task_pgrp() would take an rcu lock...
kernel/sys.c takes both, i.e.
rcu_read_lock();
write_lock_irq(&tasklist_lock);
though I think we should be fine with just rcu_read_lock(). setpgid()
indicates that it wants to check real_parent and needs the
write_lock_irq() because it might change behind its back which we don't
care about since we're not changing the pgrp.
Christian
Powered by blists - more mailing lists