linux-kernel - Re: [PATCH 1/2] TTY: ldisc, do not close until there are readers

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

Message-ID: <BANLkTik5QP7e=+FWSa1kLVpCjZpWEtF1PQ@mail.gmail.com>
Date:	Sat, 4 Jun 2011 06:52:57 +0900
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	gregkh@...e.de, jirislaby@...il.com, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>, stable@...nel.org
Subject: Re: [PATCH 1/2] TTY: ldisc, do not close until there are readers

On Fri, Jun 3, 2011 at 10:01 PM, Jiri Slaby <jslaby@...e.cz> wrote:
>
> There is a difference, we need uninterruptible sleep as there is
> obviously HUP signal pending. So tty_ldisc_wait_idle now takes
> interruptible parameter to decide. I'm not sure whether it's worth the
> complexity. Instead uninterruptible waiting may fit even for the ldisc
> change code. It wouldn't be possible to interrupted the change, but
> there is 5s timeout anyway.

Ugh. I'd much rather not see these kinds of random flags.

> This is nicely reproducible after constify the timing as follows:
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c

And PLEASE don't do things like this: you just introduced a patch
inside the email that shows the bug, and now any sane email
application tool will just assume that THIS patch is the one you want
to apply. So rather than applying the fix, it will apply the
"descriptive" patch to intentionally introduce the timing delays to
show the bug!

So don't include actual real patches like this without indenting them
or doing something to make it really really obvious that the patch is
not the one to be applied, but just a description of the problem!

                     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/