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

Message-ID: <CA+55aFyLYxQgdevFwjwzVrU_B87n5a6P_=9pcWzjKZ0C6RtU5g@mail.gmail.com>
Date:	Thu, 12 Apr 2012 15:46:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
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, 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).

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