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]
Date:	Tue, 06 Oct 2015 23:00:47 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Tilman Schmidt <tilman@...p.cc>,
	Peter Hurley <peter@...leysoftware.com>
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 ma, 2015-09-21 at 18:07 +0200, Tilman Schmidt wrote:
> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
> > ???
> > 
> > The tool you authored will do it from the command line
> > 
> > $ ldattach PPP /dev/ttyS1
> > $ ldattach GIGASET_M101 /dev/ttyS1
> > 
> > Note that nothing here closes the serial device 'in between', and
> > the tty core has switched directly from PPP to GIGASET_M101.
> > n_tty->receive_room is now 64K.
> 
> Indeed it does. I stand corrected. The possibility of running ldattach a
> second time without terminating the first instance didn't occur to me.

Naive question: when would running ldattach a second time make sense?

> > Please add switching from line disciplines other than N_TTY to your
> > regression testing.
> 
> I don't do regression tests for the driver anymore since I stepped down
> as a maintainer, so that would be up to the present maintainer of
> ser_gigaset. But I see no reason for that. As I already explained, N_TTY
> is the only problematic case.

I'm the current maintainer. (By virtue of having a stash of gigaset
hardware _and_ an ISDN capable line _and_ an ISP that still answers when
I do ISDN dial up. That ISP also does ADSL, which I actually use on a
day to day basis.) I try to test whether ISDN still has a pulse, every
RC, but I can't promise much.

(Off topic: does anyone actually _care_ about ISDN? It seems the other
two ISDN maintainers all have effectively left mainline. Now I'm happy
to (lightly!) test mainline ISDN support as long as that's feasible, but
I'd _really_ like to hear from people using ISDN on machines running
currently supported kernels. Are there any left?)

> Again, I won't oppose applying this patch to stable releases before
> 3.10. I just don't see the need, so it would be up to you to advocate
> such a request.

That would be fixing a theoretical problem, as apparently no one managed
to hit this problem before v3.10 _in practice_, so that's not something
I see a need for either.

Thanks,


Paul Bolle
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ