lkml.org 
[lkml]   [2015]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
From
Date
Am 16.09.2015 um 03:18 schrieb Peter Hurley:
> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@imap.cc> wrote:
>> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>
>>> From: Tilman Schmidt <tilman@imap.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

Correct.

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

Reasonably certain, yes, for three reasons:
- There where no reports of that problem before 3.10.
- My own tests did never encounter that condition, and even after being
made aware of it I was not able to come up with a test that would
provoke it with a kernel version before 3.10.
- The requirement for line disciplines to set receive_room wasn't (and
btw still isn't) documented anywhere, so it's unlikely anything actively
relied on it.

But if you want to propose that patch for inclusion in earlier stable
releases I won't oppose it.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2015-09-16 13:41    [W:0.076 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site