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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ