linux-kernel - Re: [PATCH] sched: print parent comm in sched_show

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 4 Jan 2023 14:40:49 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     张元瀚 <zyhtheonly@...il.com>
Cc:     Chen Yu <yu.c.chen@...el.com>, mingo@...hat.com,
        peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, linux-kernel@...r.kernel.org,
        zyhtheonly@...h.net, zwp10758@...il.com
Subject: Re: [PATCH] sched: print parent comm in sched_show_task()

On Wed 2023-01-04 01:51:30, 张元瀚 wrote:
> Hi Chen,
> Thanks for your advice!
> 
> > Maybe struct task_struct *parent = rcu_dereference(p->real_parent);
> > and use parent directly to get its pid and comm?
> 
> Yes! It is good to write this way.
> 
> > Maybe off-topic, what if the parent is a kernel thread/worker? It might
> have extra
> > name information such as kthread->full_name or worker->desc according to
> proc_task_name().
> 
> I'm not quite sure if it is necessary to fetch that extra information since
> our sched_show_task() prints p->comm ourselves.
> But, assuming we get the parent's name in the same way we get
> proc_task_name(), there are some new issues I'd like to discuss.

I suggest to keep it simple and just print "parent->comm".

Especially, we should avoid taking any lock. shed_show_task() might
be called when there already is a deadlock on the system. I guess
that it even can be called from NMI.

For example, see print_worker_info(). It uses
copy_from_kernel_nofault() to be safe without taking any lock.

Best Regards,
Petr