mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: David Rientjes <rientjes@google.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range
Date: Mon, 18 Oct 2010 23:23:29 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1010182320440.6815@localhost6.localdomain6> (raw)
In-Reply-To: <alpine.DEB.2.00.1010181340080.10965@chino.kir.corp.google.com>

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


  reply	other threads:[~2010-10-18 21:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-18 20:35 Frederic Weisbecker
2010-10-18 20:35 ` [PATCH 2/2] x86: Remove stale TIF_DEBUG Frederic Weisbecker
2010-10-18 22:12   ` [PATCH v2] " Frederic Weisbecker
2010-10-18 20:47 ` [PATCH 1/2] x86: Cleanup TIF value gaps in shift range David Rientjes
2010-10-18 21:23   ` Thomas Gleixner [this message]
2010-10-18 21:28     ` H. Peter Anvin
2010-10-18 21:36       ` David Rientjes
2010-10-18 21:43         ` H. Peter Anvin
2010-10-18 22:00           ` David Rientjes
2010-10-18 23:23             ` H. Peter Anvin
2010-10-18 21:30     ` David Rientjes
2010-10-18 20:48 ` H. Peter Anvin
2010-10-18 21:10   ` Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1010182320440.6815@localhost6.localdomain6 \
    --to=tglx@linutronix.de \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®