linux-kernel - Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer

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+55aFxUaNC4SGEodrdddkDN6t=Sbx=P4XyaHkj7eTQBQOeLeA@mail.gmail.com>
Date:	Thu, 10 May 2012 09:47:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kay Sievers <kay@...y.org>
Cc:	Ingo Molnar <mingo@...nel.org>, Jonathan Corbet <corbet@....net>,
	Sasha Levin <levinsasha928@...il.com>,
	Greg Kroah-Hartmann <greg@...ah.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length
 record buffer

On Thu, May 10, 2012 at 9:39 AM, Kay Sievers <kay@...y.org> wrote:
>
> All the special rules are gone. KERN_CONT is the same as KERN_DEFAULT
> now.

That's wrong.

Key, KERN_CONT and KERN_DEFAULT really are different and have
fundamentally different semantics. The fact that you think they aren't
shows that you don't understand it.

Your "current" check doesn't change anything.

There are two main and important differences:

 - people can avoid using '\n' if they know the next printk will have
a KERN_xxx marker (xxx != CONT).

   This is often useful for having loops that print out individual
entries all on the same line - print all of them without the '\n'.

   The printk afterwards will automatically start a new line if it has
KERN_DEFAULT.

   If you make KERN_CONT and KERN_DEFAULT the same, it is a BUG. Don't do it.

 - You don't seem to realize that interrupts are threaded events too,
but they will happen with the same task-struct.

   An interrupt that prints out with KERN_DEFAULT had better not act
the same way as KERN_CONT.

So dammit, just stop trying to get rid of KERN_CONT or KERN_DEFAULT.
They are both real, and they are both *different*. If you think they
are the same, you are WRONG.

Don't try to change the rules because you think you are "clever".
You're only making things worse.

                       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/