linux-kernel - Re: ye olde task_ctx_sched

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140521151655.GG2485@laptop.programming.kicks-ass.net>
Date:	Wed, 21 May 2014 17:16:55 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: ye olde task_ctx_sched_out trace.

On Wed, May 21, 2014 at 11:06:13AM -0400, Dave Jones wrote:
> I thought we had this nailed down a while ago, but it still keeps
> popping up...
> 
> WARNING: CPU: 3 PID: 32310 at kernel/events/core.c:2384 task_ctx_sched_out+0x6b/0x80()
> CPU: 3 PID: 32310 Comm: trinity-c185 Not tainted 3.15.0-rc5+ #214
>  0000000000000009 000000003d7dfb5c ffff880019671df8 ffffffff9371a1fd
>  0000000000000000 ffff880019671e30 ffffffff9306d5dd ffff88024d0d6d48
>  ffff88010c4944e8 0000000000000286 ffff880243b82d00 ffff88010c4944e8
> Call Trace:
>  [<ffffffff9371a1fd>] dump_stack+0x4e/0x7a
>  [<ffffffff9306d5dd>] warn_slowpath_common+0x7d/0xa0
>  [<ffffffff9306d70a>] warn_slowpath_null+0x1a/0x20
>  [<ffffffff931430bb>] task_ctx_sched_out+0x6b/0x80
>  [<ffffffff93146138>] perf_event_comm+0xc8/0x220
>  [<ffffffff930a19cd>] ? get_parent_ip+0xd/0x50
>  [<ffffffff931c025f>] set_task_comm+0x4f/0xc0
>  [<ffffffff93085b23>] SyS_prctl+0x1d3/0x480
>  [<ffffffff9372cf9f>] tracesys+0xdd/0xe2
> 
> There was on perf activity at all going on at the time.
> I had told trinity to do -g vm which excludes all non-VM related syscalls.
> 
> What is perf_event_comm doing ? Is that storing some state in case
> I later decide to run perf ?

So we use perf_event_comm() to trigger start_on_exec, which in turn
pretty much assumes .tsk=current.

Now some people have advanced set_task_comm() usage far beyond this
point and we can now pretty much call it on random tasks at random times
in order to make 'top' look pretty or similar useless things.

So I think I should separate this and add perf_event_exec() and leave
perf_event_comm() for just reporting task->comm changes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/