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]
Message-ID: <563A11A9.40601@imap.cc>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ