Re: [PATCH v2] pids: introduce find_get_task_by_vpid helper

From: Mike Rapoport
Date: Mon Oct 30 2017 - 05:44:51 EST


On Mon, Oct 30, 2017 at 07:51:42PM +1100, Balbir Singh wrote:
> On Sat, Oct 28, 2017 at 4:52 AM, Mike Rapoport <rppt@xxxxxxxxxxxxxxxxxx> wrote:
> > There are several functions that do find_task_by_vpid() followed by
> > get_task_struct(). We can use a helper function instead.
> >
> > Signed-off-by: Mike Rapoport <rppt@xxxxxxxxxxxxxxxxxx>
> > ---
>
> I did a quick grep and found other similar patterns in

(reordered the file list a bit)

> kernel/events/core.c,
> arch/x86/kernel/cpu/intel_rdt_rdtgroup.c,
> mm/mempolicy.c,

Those and mm/migrate.c indeed have a similar pattern, but they all do

task = pid ? find_task_by_vpid(pid) : current;

And I don't see an elegant way to use find_get_task_by_vpid() in this case.

> kernel/kcmp.c,

kcmp gets both tasks between rcu_read_lock/unlock and I think it's better
to keep it this way.

> kernel/sys.c,

There is no get_task_struct() after find_task_by_vpid(), unless I've missed
something

> kernel/time/posix-cpu-timers.c,

Here the task is selected with more complex logic than just
find_task_by_vpid()

> mm/process_vm_access.c,

Converted in the patch

> security/yama/yama_lsm.c,
> arch/ia64/kernel/perfmon.c

I've missed these two, indeed.

The arch/ia64/kernel/perfmon.c even still uses read_lock(&tasklist) rather
than rcu_read_lock()...

> Balbir Singh.
>

--
Sincerely yours,
Mike.