linux-kernel - Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range

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:	Mon, 18 Oct 2010 23:23:29 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	David Rientjes <rientjes@...gle.com>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range

On Mon, 18 Oct 2010, David Rientjes wrote:

> On Mon, 18 Oct 2010, Frederic Weisbecker wrote:
> 
> > 9, 19 and 26 values are missing from the TIF shift range, probably
> > due to flags that were removed by the past. Now repack the range
> > so that we can quickly retrieve the remaining free shift slots.
> > 
> > But take care of keeping the seperation between high and low bits
> > as some masks are created on top of this boundary.
> > 
> 
> What's the benefit of doing this?
> 
> These flags are exported to userspace through SysRq-T, SysRq+W, the hung 
> task detector, and the rcu stall detector, so there may be external 
> dependencies testing for these bits.
> 
> We use this to look for TIF_MEMDIE to determine whether an oom killed task 
> has failed to exit and becomes hung after having access to memory 
> reserves, and that's one of the bits you've changed here.

I agree in general, but this is stupid as hell. No fcking interface
should exposed kernel internal flag bits just as hex values and no
fcking luser space should rely on it to be a subject of no change.

Seriously, if we can't even change TIF_* bits anymore then we are
doing something wrong. That's a pure kernel internal affair and
subject to change.

Thanks,

	tglx

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