[<prev] [next>] [day] [month] [year] [list]
Message-ID: <Y7WB4cgLvPs2gYX4@alley>
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
Powered by blists - more mailing lists