linux-kernel - Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser

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: <CAKU3ayVBUODUtiZS77gdzMg0R7kD8pgGu60Sdk=CRDBGt4iBQw@mail.gmail.com>
Date:	Tue, 15 Sep 2015 21:18:20 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	Jiri Slaby <jslaby@...e.cz>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when
 attaching ser_gigaset

On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@...p.cc> wrote:
> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@...e.cz
>> <mailto:jslaby@...e.cz>> wrote:
>>
>>     From: Tilman Schmidt <tilman@...p.cc>
>>
>>     3.12-stable review patch.  If anyone has any objections, please let
>>     me know.
>>
>>     ===============
>>
>>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>
>>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>>     first merged in kernel release 3.10, caused the following regression
>>     in the Gigaset M101 driver:
>>
>>
>> Again, I'll just note my objection to this commit log.
>>
>> This driver was always broken because it never initialized
>> tty->receive_room,
>> but rather relied on common but not guaranteed circumstances to
>> function.
>>
>> The commit noted simply made the underlying bug more evident, but the
>> root cause was from the original merge commit of this driver.
>
> I must admit I still don't understand that objection. The meaning of the
> term "regression" is simply that something which previously worked
> stopped working. It doesn't imply any statement about the root cause.
>
> The ser-gigaset driver worked before the introduction of commit
> 79901317ce80. It didn't work anymore after the introduction of that
> commit. So it is correct, and does not contradict your statements above
> in any way, to state that commit introduced the described regression.

By asserting that commit 79901317ce80 caused the regression, you're
claiming that this fix is unnecessary for kernel versions prior to 3.10

Are you certain that no other sequence of state leads to the same
condition (and thus requiring the same fix) in earlier kernel versions?

Regards,
Peter Hurley
--
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/