On Wed, Aug 14, 2019 at 05:27:12PM +0200, Oleg Nesterov wrote:
> On 08/14, Christian Brauner wrote:
> >
> > On Wed, Aug 14, 2019 at 04:19:57PM +0200, Oleg Nesterov wrote:
> > > On 08/14, Christian Brauner wrote:
> > > >
> > > > +static struct pid *find_get_pgrp(pid_t nr)
> > > > +{
> > > > + struct pid *pid;
> > > > +
> > > > + if (nr)
> > > > + return find_get_pid(nr);
> > > > +
> > > > + rcu_read_lock();
> > > > + pid = get_pid(task_pgrp(current));
> > > > + rcu_read_unlock();
> > > > +
> > > > + return pid;
> > > > +}
> > >
> > > I can't say I like this helper... even its name doesn't look good to me.
> >
> > Well, naming scheme obviously stolen from find_get_pid(). Not sure if
> > that doesn't look good as well. ;)
>
> find_get_pid() actually tries to find a pid. The helper above does "find"
> or "use current" depending on nr != 0.
>
> > > I forgot that we already have get_task_pid() when I replied to the
> > > previous
> > > version... How about
> > >
> > > case P_PGID:
> > >
> > > if (upid)
> > > pid = find_get_pid(upid);
> > > else
> > > pid = get_task_pid(current, PIDTYPE_PGID);
> > >
> > > ?
> >
> > Hmyeah, that works but wouldn't it still be nicer to simply have:
> >
> > static struct pid *get_pgrp(pid_t nr)
> > {
> > if (nr)
> > return find_get_pid(nr);
> >
> > return get_task_pid(current, PIDTYPE_PGID);
> > }
>
> Who else can ever use it?
>
> It saves 4 lines in kernel_waitid() but adds 7 lines outside, and you
> need another ^] to see these lines if you try to understand what
> PIDTYPE_PGID actually does. IOW, I think this helper will make waitid
> less readable for no reason.
>
>
> Christian, I try to never argue when it comes to cosmetic issues, and
> in this case I won't insist too.
Yeah, I know. I'm not insisisting either. We can do your thing since you
do after all seem to care at least a tiny bit. ;)
Christian
