From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com ([66.111.4.27]:60494 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753512AbbIRMio (ORCPT ); Fri, 18 Sep 2015 08:38:44 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9257F20701 for ; Fri, 18 Sep 2015 08:38:43 -0400 (EDT) Subject: Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset To: Peter Hurley References: <350624fa32cb152bfec51f236b0b62b8d480a05a.1442326825.git.jslaby@suse.cz> <4a187391f4c7d54b9c07eed08de48ffd6e0a3f20.1442326825.git.jslaby@suse.cz> <55F8B9D9.5060201@imap.cc> <55F951EA.1060001@imap.cc> Cc: Jiri Slaby , "stable@vger.kernel.org" , Linux kernel mailing list , "David S. Miller" From: Tilman Schmidt Message-ID: <55FC05C7.1000207@imap.cc> Date: Fri, 18 Sep 2015 14:38:31 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JD3F57PC4Rpn7AReTHsVpOOxAdu04t5jk" Sender: stable-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JD3F57PC4Rpn7AReTHsVpOOxAdu04t5jk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 17.09.2015 um 20:13 schrieb Peter Hurley: > On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt wrote:= >> Am 16.09.2015 um 03:18 schrieb Peter Hurley: >>> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt wrot= e: >>>> Am 16.09.2015 um 01:08 schrieb Peter Hurley: >>>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby wrote= : >>>>> >>>>> From: Tilman Schmidt >>>>> >>>>> 3.12-stable review patch. If anyone has any objections, please= let >>>>> me know. >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ] >>>>> >>>>> Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ld= isc"), >>>>> first merged in kernel release 3.10, caused the following regre= ssion >>>>> 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 t= he >>>>> 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= =2E >>>> >>>> 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 ab= ove >>>> in any way, to state that commit introduced the described regression= =2E >>> >>> 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 version= s? >> >> Reasonably certain, yes, for three reasons: >> - There where no reports of that problem before 3.10. >=20 >=20 >=20 >> - My own tests did never encounter that condition, and even after bein= g >> 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. >=20 > Do any of your tests switch to this line discipline from any other than= N_TTY? Of course not. That wouldn't make any sense. > So for example, if you manually set N_PPP (as if by user error) User error wouldn't suffice, as the LD would get reset to N_TTY when the serial device is closed. You would have to write a program that deliberately switched the LD first to N_PPP and then to N_GIGASET_M101 without closing the device in between. > and then set this line discipline, tty->receive_room will be 64K, not 4= K. That wouldn't affect the operation of ser_gigaset, so even if I had set up such a contrived test scenario it wouldn't have exposed any problem. Only setting tty->receive_room to 0 causes the problem, and N_TTY with commit 79901317ce80 is the only LD which does that. >> - The requirement for line disciplines to set receive_room wasn't (and= >> btw still isn't) documented anywhere, so it's unlikely anything active= ly >> relied on it. >=20 > Nevertheless, that is the requirement, and what every other in-tree lin= e > discipline does. Your word for it. Still I don't understand the curious resistance to documenting it. If it is the requirement, why keep it secret? Regards, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Unge=C3=B6ffnet mindestens haltbar bis: (siehe R=C3=BCckseite) --JD3F57PC4Rpn7AReTHsVpOOxAdu04t5jk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV/AXQAAoJEFPuqx0v+F+q5K8IAL1mOVnG9MzhgtjKCWZ5GPll mnAucAty6WHx4z0teKVwEEvTBdydKKTQ3PGHI9K67aH0J8232InA9p6LG9cqe5Av niuuwm/GWfL6jieuk/DH0HW7JisJUr+zYFM6vSk5K43xRs1Xyg9Rrl4NgmqPLqz7 v+d06yQHpgDTJ/swseohs773KEmyU9VB482oKqMsbjSyS5ScsG33BZcjh156+QAG xJ8fspVY56BLRsva7oaDEbnKCyBwOADbrLQyvQFbljQTOBl4tb8408XBjOp05ggl dnHkzwaCU5Cexj/0hz5xenEb3uISLvNWOKk07Jhf4z0hZOxr9fFa1usf6f8xuaE= =yzPT -----END PGP SIGNATURE----- --JD3F57PC4Rpn7AReTHsVpOOxAdu04t5jk--