linux-kernel - Re: [PATCH] perf sched: fix wrong conversion of task state

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 29 Jul 2016 02:30:12 +0000
From:	関山友輝 / SEKIYAMA，TOMOKI 
	<tomoki.sekiyama.qu@...achi.com>
To:	David Ahern <dsahern@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ltc-kernel@...ml.intra.hitachi.co.jp" 
	<ltc-kernel@...ml.intra.hitachi.co.jp>,
	森谷真寿美 / MORITANI，MASUMI 
	<masumi.moritani.ju@...achi.com>, Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Masami Hiramatsu" <mhiramat@...nel.org>
Subject: Re: [PATCH] perf sched: fix wrong conversion of task state

On 2016/07/28 23:26、David Ahern wrote:
>> But that means we cannot handle preemption correctly as far as
>> sched:sched_switch
>> event uses TASK_STATE_MAX to mark preempted tasks.
>> 
>> Should we stop using TASK_STATE_MAX for preempted tasks in ftrace and
>> use (1 << 63) or something that doesn't change on kernel version instead?
> 
> ftrace printing is within the kernel so it has consistency.
Agreed.

> It is the save data and analyze later use case that can not assume TASK_STATE_MAX means preemption since the value of TASK_STATE_MAX is kernel version dependent.

That means we cannot measure delay by preemption using perf sched latency. :(
It might be helpful if the preemption mark becomes kernel-version-independent at least for future kernel version..

Anyway, this time I will post the patch to fix only invalid conversion issue of task state with this patch.

Thanks,
Tomoki Sekiyama