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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.00.1010181451030.18444@chino.kir.corp.google.com>
Date:	Mon, 18 Oct 2010 15:00:36 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range

On Mon, 18 Oct 2010, H. Peter Anvin wrote:

> > It's not insane if there is no other way to ascertain that information.  
> > If it's available through sysfs or debugfs (and, even better, documented 
> > as part of the API in Documentation/ABI), then I don't think anyone would 
> > object to changing a log message.  But I don't think all log messages 
> > should be fair game under some general principle if they are being changed 
> > (instead of just extending it) without a compelling reason, such as 
> > technically being incorrect in its present form.
> 
> YES IT IS.  In fact, it is completely and totally bananas bonkers.
> 
> By not pushing for a proper maintainable ABI, you will have an
> indefinite forward compatibility problem, and when predictably it
> breaks, you'll complain.  This is, however, backwards -- the right thing
> would have been to say "I need this, this isn't available, I should add
> a maintainable API and push it upstream", and perhaps add log parsing as
> a backwards-compatibility solution.
> 

The problem is deciding what should be an ABI and what shouldn't an ABI 
when it isn't clear.  It would be great if everything that is logged or 
shown to userspace would be part of an ABI and would be available no 
matter how much information is emitted to the log.  That's not scalable, 
so we have to decide what userspace may depend on and design ABIs that 
provide that information in an extendable way that won't break or become 
obsoleted in the foreseeable future.

Since we can't do that for everything and we have no idea what users will 
find to parse from the dmesg, I'm advocating that if a change is proposed, 
like was in this case with ti->flags, and someone has a usecase where the 
information isn't available in any other way, that they speak up and come 
up with a maintainable solution so that we've identified the parties 
involved and can change that log message if necessary.  I only think that 
should be done, though, when there is a compelling reason for the change.

I think that was done in this case by suggesting an alternative (printing, 
at minimum, "M" when a thread has TIF_MEMDIE set instead of the raw flag 
bits), but I don't think the change itself was compelling enough that it 
has to be done.  That doesn't mean doing the change I suggested wasn't 
still appropriate, but at least it was known as a prerequisite before 
something like this should be merged.
--
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/