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

Date:	Thu, 28 Jul 2016 08:26:45 -0600
From:	David Ahern <dsahern@...il.com>
To:	Tomoki Sekiyama <tomoki.sekiyama.qu@...achi.com>,
	linux-kernel@...r.kernel.org
Cc:	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 7/27/16 9:10 PM, Tomoki Sekiyama 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.

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.