linux-kernel - Re: [GIT pull] timer fixes for 3.4

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

Message-ID: <alpine.LFD.2.02.1204130058370.2542@ionos>
Date:	Fri, 13 Apr 2012 01:01:46 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Sasikantha Babu <sasikanth.v19@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [GIT pull] timer fixes for 3.4

On Thu, 12 Apr 2012, Linus Torvalds wrote:

> On Thu, Apr 12, 2012 at 3:39 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> >>
> >> That said, would people actually *report* those messages?
> >>
> >> In general, for things like this, it's probably better to just make
> >> the change (especially if you have several distros you can test), and
> >> then add a printk_once() for the case that changed. Then, if people
> >
> > I changed it to a printk_once() already.
> 
> No, I meant that the whole message should probably have been added
> when actually changing the semantics.
> 
> If you have good reason to believe that some ABI change (a) does not
> actually have any reason to break anything and (b) worth doing, then I
> think it should just have been done (but during the merge window only,
> of course).
> 
> And if (a) or (b) aren't true, then we're not going to change the ABI
> at all, so the whole point is moot.
> 
> The printk_once (or, for that case WARN_ON_ONCE() may even be
> worthwhile) would then just be a "oops, we were wrong" kind of
> message, and would just mean that the commit would be reverted.
> 
> I think the whole "let's deprecate this six months into the future" is
> unnecessary. Yes, it may well be worth doing for something with bigger
> consequences, but I think that for something like this, it's just
> overthinking the issue.
> 
> If it really is something we want to fix, I think it's much better to
> just say "let's fix it, and if somebody notices, we'll have to go
> back". The printk_once or WARN_ON is then just a polite way to avoid
> having people have to bisect to it etc if it's subtle (and then we
> would plan to remove *that* later).

Fair enough.

Though last time I tried to do that (IIRC, it was a sanity check on a
timespec) I was forced to go the deprecation way ....

Times are changing :)

      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/