linux-kernel - Re: [GIT PATCH] TTY patches for 2.6.36

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]

Date:	Fri, 6 Aug 2010 11:40:15 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <gregkh@...e.de>, Arnd Bergmann <arnd@...db.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] TTY patches for 2.6.36

On Thu, Aug 5, 2010 at 2:35 PM, Greg KH <gregkh@...e.de> wrote:
>
> This contains the big BKL removal of the tty layer, which has been
> worked on now for a long time by Alan and Arnd.

Umm. No it doesn't.

It contains some crazy "BKL or mutex" choice layer, and the MUTEX
choice is disabled unless you have EXPERIMENTAL set (and not the
default even if it is set - but quite frankly, that doesn't matter,
because asking about it is so fundamentally wrong in the first place
that the whole default choice is totally meaningless).

That's just total and utter crud. Having a conditional BKL is _worse_
than just having the BKL. It's crazy. It's stupid, it limits testing,
and it's pure idiocy. Whoever thought that was a good idea was not
thinking at all.

Either the locking fixes are improvements, or they aren't. If they are
improvements, they should be unconditionally enabled, and the old
locking should have been removed. And if they aren't, it shouldn't
have been merged at all. The timid kind of "let the user choose"
choice is STUPID.

Dammit, if the developer doesn't know which one is better, how the
hell is a user supposed to know? Answer: he isn't. Making it a config
option is fundamentally wrong.  Config options that ask questions that
users cannot answer are WRONG. Really.

I'm not pulling crazy sh*t like this. The _only_ thing that kconfig
option does is basically mean that it doesn't get the kind of coverage
in testing that it needs to get, and it confuses everybody. Not to
mention having two totally different code-paths where there should be
only one.

Do do the highlander thing on that crud. Cut it off at the head, and
make sure it never ever comes back to life.

                  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/