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

Date:	Wed, 4 Nov 2015 15:09:45 +0100
From:	Tilman Schmidt <tilman@...p.cc>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Peter Hurley <peter@...leysoftware.com>,
	Jiri Slaby <jslaby@...e.cz>, 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

Hi Paul,

Am 19.10.2015 um 11:09 schrieb Paul Bolle:
> On ma, 2015-10-12 at 11:18 +0200, Tilman Schmidt wrote:
>> While it doesn't make any sense indeed to run two instances of
>> ldattach
>> in parallel on one and the same serial port, it is entirely conceivable
>> that someone might do so inadvertently, by not being aware that one is
>> running already.
> 
> I'm wandering off topic a bit, but doesn't that imply that ldattach
> should bail out with an error if someone tries to do that?

I'm of two minds about this. On the pro side, it might prevent some
surprises. But on the other hand, nothing actually breaks if someone
does, and I'm not 100% sure there are really no legitimate scenarios.
Add to this that I don't have a clear idea how to actually implement
such a bailout, and that I'm really short of time. So I'm reluctant to
tackle this topic.

Perhaps the best way forward would be someone (not me) submitting a
patch to ldattach, thereby triggering a discussion of the pros and cons
that would ideally include all (or most) ldattach users and consider all
line disciplines it is used with.

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

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)