Re: [PATCH 1/2] isdn/gigaset: reset tty-receive_room when attaching ser_gigaset

discipline open because they are declaring that every input they can accept that much data. Regards, Peter Hurley The present patch fixes that regression by setting receive_room to an appropriate value in the ldisc open method. Fixes: 79901317ce80 (n_tty: Don't flush buffer when closing ldisc

Re: [PATCH] ixgbe: Wait for 1ms, not 1us, after RST

* or write) any other device register. > + */ > + mdelay(1); Since ixgbe_reset_hw_x540() goes on to msleep(100) immediately after this busy-wait loop, this should instead be: msleep(1); Regards, Peter Hurley > ctrl = IXGBE_R

Re: [Intel-wired-lan] [PATCHv2] ixgbe: Wait for 1ms, not 1us, after RST

ting reset delay of 100ms) are not harmful. Use of usleep_range() would be unnecessary overkill for the purpose. Regards, Peter Hurley > --- > > I have tested your changes > > [Intel-wired-lan] [PATCHv2] ixgbe: Wait for 1ms, not 1us, after RST > > Project: net (ne

[PATCH v2 0/4] Replace tty->closing

found by Johannes Stezenbach <j...@sig21.net> Regards, Peter Hurley (4): tty: rocket: Remove private close_wait n_tty: Ignore all read data when closing tty: Abstract and encapsulate tty->closing behavior tty: Remove drivers' extra tty_ldisc_flush() drivers/char/pcmcia/synclink_

[PATCH v2 4/4] tty: Remove drivers' extra tty_ldisc_flush()

The tty_port_close_start() helper already flushes the tty and ldisc buffers on final close; tty drivers which use this helper need not repeat tty_ldisc_flush(). Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/char/pcmcia/synclink_cs.c | 3 --- drivers/tty/amise

[PATCH v2 2/4] n_tty: Ignore all read data when closing

On final port close (and thus final tty close), only output flow control requests in the input data should be processed. Ignore all other input data, including parity errors, overruns and breaks. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/tty/n_tty.c | 2 --

[PATCH v2 3/4] tty: Abstract and encapsulate tty->closing behavior

ductive. NB: ipwireless_tty_free() is completely bogus; freeing the tty (?!) with open, in-use file descriptors is laughable. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- v2: Fixed tty_ldisc_closing() ld use found by Johannes Stezenbach <j...@sig21.net> drivers/isdn/

[PATCH v2 1/4] tty: rocket: Remove private close_wait

This driver's private completion variable, close_wait, is no longer used for wait since "tty: Remove ASYNC_CLOSING checks in open()/hangup"; remove. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/tty/rocket.c | 2 -- drivers/tty/rocket_int.h | 1 - 2

[PATCH 1/4] tty: rocket: Remove private close_wait

This driver's private completion variable, close_wait, is no longer used for wait since "tty: Remove ASYNC_CLOSING checks in open()/hangup"; remove. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/tty/rocket.c | 2 -- drivers/tty/rocket_int.h | 1 - 2

[PATCH 4/4] tty: Remove drivers' extra tty_ldisc_flush()

The tty_port_close_start() helper already flushes the tty and ldisc buffers on final close; tty drivers which use this helper need not repeat tty_ldisc_flush(). Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/char/pcmcia/synclink_cs.c | 3 --- drivers/tty/amise

[PATCH 0/4] Replace tty->closing

tty drivers which open-code the close() method drivers/staging/dgnc/dgnc_tty.c drivers/staging/dgap/dgap.c drivers/tty/hvc/hvsi.c drivers/tty/serial/68328serial.c drivers/tty/serial/crisv10.c drivers/isdn/i4l/isdn_tty.c drivers/s390/char/con3215.c Regards, Peter Hurley (4): tty: rocket: Remove

[PATCH 2/4] n_tty: Ignore all read data when closing

On final port close (and thus final tty close), only output flow control requests in the input data should be processed. Ignore all other input data, including parity errors, overruns and breaks. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/tty/n_tty.c | 2 --

[PATCH 3/4] tty: Abstract and encapsulate tty->closing behavior

ductive. NB: ipwireless_tty_free() is completely bogus; freeing the tty (?!) with open, in-use file descriptors is laughable. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/isdn/i4l/isdn_tty.c | 2 +- drivers/s390/char/con3215.c | 3 +-- drivers/staging/dga

Re: [PATCH 3/4] tty: Abstract and encapsulate tty->closing behavior

On 11/09/2015 04:12 AM, Johannes Stezenbach wrote: > On Sun, Nov 08, 2015 at 05:02:52PM -0500, Peter Hurley wrote: >> +void tty_ldisc_closing(struct tty_struct *tty) >> +{ >> +struct tty_ldisc *ld = tty_ldisc_ref(tty); >> + >> +if (ld->ops->closin

[PATCH 7/7] tty: Remove wait_event_interruptible_tty()

In-tree users of wait_event_interruptible_tty() have been removed; remove. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- include/linux/tty.h | 26 -- 1 file changed, 26 deletions(-) diff --git a/include/linux/tty.h b/include/linux/tty.h index 0

[PATCH 4/7] tty: Remove tty_port::close_wait

. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/tty/rocket.c | 1 - drivers/tty/serial/68328serial.c | 1 - drivers/tty/serial/crisv10.c | 1 - drivers/tty/serial/serial_core.c | 1 - drivers/tty/tty_port.c | 2 -- include/linux/tty.h |

[PATCH 1/7] tty: Remove tty_wait_until_sent_from_close()

ux.intel.com> Cc: David Laight <david.lai...@aculab.com> CC: Arnd Bergmann <a...@arndb.de> CC: Karsten Keil <i...@linux-pingi.de> CC: linuxppc-...@lists.ozlabs.org Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/isdn/i4l/isdn_tty.c | 2 +- drivers/tty

[PATCH 5/7] tty: r3964: Use tty->read_wait waitqueue

will be using the closing instance of the line discipline. Completely remove that wakeup. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/tty/n_r3964.c | 10 -- include/linux/n_r3964.h | 3 --- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/drive

[PATCH 2/7] tty: Remove ASYNC_CLOSING checks in open()/hangup() methods

., in *_block_til_ready()). Note: The ASYNC_CLOSING flag state is still maintained since several bitrotting drivers use it for (dubious) other purposes. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/char/pcmcia/synclink_cs.c | 9 - drivers/tty/cyclades.c

[PATCH 6/7] tty: r3964: Replace/remove bogus tty lock use

tty_lock() is unnecessary and counter-productive; remove tty lock use. However, the line discipline is responsible for serializing reads (if required by the line discipline); add read_lock mutex to serialize calls of r3964_read(). Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drive

[PATCH 0/7] tty close cleanup

dget changes, and David Miller for the ISDN/IRDA changes. Regards, Peter Hurley (7): tty: Remove tty_wait_until_sent_from_close() tty: Remove ASYNC_CLOSING checks in open()/hangup() methods usb: gadget: gserial: Privatize close_wait tty: Remove tty_port::close_wait tty: r3964: Use tty->read_wai

[PATCH 3/7] usb: gadget: gserial: Privatize close_wait

close_wait is no longer needed or provided by the tty core. Move close_wait to struct gs_port. Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> --- drivers/usb/gadget/function/u_serial.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/fu

Re: [PATCH 3/7] usb: gadget: gserial: Privatize close_wait

[ forgot to addr Felipe here, sorry ] On 10/10/2015 04:00 PM, Peter Hurley wrote: > close_wait is no longer needed or provided by the tty core. > Move close_wait to struct gs_port. > > Signed-off-by: Peter Hurley <pe...@hurleysoftware.com> > --- > drivers/usb/gadget

Re: [PATCH v2] Documentation: improve line discipline method descriptions

On 09/29/2015 07:45 PM, Tilman Schmidt wrote: > Mention that the ldisc open method must set tty->receive_room, and > that many methods are optional. Add description of receive_buf2 method. Thanks, Tilman! Reviewed-by: Peter Hurley <pe...@hurleysoftware.com> -- To unsubscribe

[PATCH] wan/x25: Fix use-after-free in x25_asy_open_tty()

fs/ioctl.c:607) [ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613) [ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188) Reported-and-tested-by: Sasha Levin <sasha.le...@oracle.com> Cc: <sta...@vger.kernel.org> Signed-off-by: Peter Hurley <pe...@

Re: gigaset: freeing an active object

[] gigaset_freecshw+0xe1/0x120 > > There are functions by this name in all three Gigaset hardware dependent > modules (bas_gigaset, ser_gigaset and usb_gigaset), but ... > >> [ 413.562723] [] gigaset_freecs+0x2ad/0x600 >> [ 413.564240] [] gigaset_tty_close+0x210/0x280 >

Re: gigaset: freeing an active object

espondence and lifetime for the embedded platform device and it's containing memory? I ask because the typical approach for device teardown is to put the kfree() in the release method; naturally, that won't work if there is some other lifetime issue. Regards, Peter Hurley > cs->hw.ser

Re: [PATCH v2 0/4] Replace tty->closing

Greg, Would you drop these 4 patches from tty-testing please? On 11/09/2015 04:15 AM, Peter Hurley wrote: > Hi Greg, > > This series cleans up a messy and poorly documented mechanism required > at tty final close to prevent drivers from crashing after h/w shutdown. > &g

Re: [PATCH 2/3] ser_gigaset: fix deallocation of platform device structure

; + kfree(cs->hw.ser); >>> + cs->hw.ser = NULL; This pattern is common, and defends against much more common driver bugs. Unfortunately, much of the good this pattern is intended to do in finding use-after-free bugs is undone by explicit tests for null everywhere else. Not saying that's t

Re: gigaset: freeing an active object

ated applet with the bug reports; state previously established by the applet can be crucial in understanding why the call stack looks the way it does. Also, every generated applet that triggers a report should become a future regression test; I'm collecting the ones pertinent to tty/serial/ ldisc

Re: tty,net: use-after-free in x25_asy_open_tty

oc-512 (Not tainted): kasan: bad access detected Thanks for the report, Sasha. Would you please test the patch below? The ldisc api should really prevent these kinds of errors. I'll prepare a patch to the tty core which should address the api weakness. Regards, Peter Hurley --->% --- Su

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/27/2016 12:13 PM, Eric Dumazet wrote: > On sam., 2016-02-27 at 10:19 -0800, Peter Hurley wrote: >> Hi Eric, >> >> For a while now, we've been struggling to understand why we've been >> observing missed uart rx DMA. >> >> Because both the uart dri

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/27/2016 05:59 PM, Eric Dumazet wrote: > On sam., 2016-02-27 at 15:33 -0800, Peter Hurley wrote: >> On 02/27/2016 03:04 PM, David Miller wrote: >>> From: Peter Hurley <pe...@hurleysoftware.com> >>> Date: Sat, 27 Feb 2016 12:29:39 -0800 >>> >

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/27/2016 03:04 PM, David Miller wrote: > From: Peter Hurley <pe...@hurleysoftware.com> > Date: Sat, 27 Feb 2016 12:29:39 -0800 > >> Not really. softirq raised from interrupt context will always execute >> on this cpu and not in ksoftirqd, unless loa

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 07:40 AM, Mike Galbraith wrote: > On Mon, 2016-02-29 at 07:03 -0800, Peter Hurley wrote: > >>> If I'm listening properly, the root cause is that there is a timing >>> constraint involved, which is being exposed because one softirq raises >>>

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 07:19 AM, Eric Dumazet wrote: > On lun., 2016-02-29 at 07:03 -0800, Peter Hurley wrote: > >> Not the case. The softirq is raised from interrupt. >> >> Before Eric's change, when an interrupt raises a new softirq >> while processing another softirq,

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/28/2016 08:58 PM, Mike Galbraith wrote: > On Sun, 2016-02-28 at 18:01 +0100, Francois Romieu wrote: >> Mike Galbraith : >> [...] >>> Hrm, relatively new + tasklet woes rings a bell. Ah, that.. >>> >>> >>> What's worse is that at the point where this code was

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 08:21 AM, Eric Dumazet wrote: > On lun., 2016-02-29 at 07:54 -0800, Peter Hurley wrote: > >> The current kernel is HZ=250 but this would occur on HZ=1000 as well. > > Right. But the problem with HZ=100 and HZ=250 is that the detection can > happens because jif

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 07:27 AM, Eric Dumazet wrote: > On lun., 2016-02-29 at 07:03 -0800, Peter Hurley wrote: > >> The reason why Eric's change is so effective for Eric's workload is >> that it fixes the problem where NET_RX keeps getting new network packets >> so it keeps loopin

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 10:24 AM, Eric Dumazet wrote: > On lun., 2016-02-29 at 10:05 -0800, Peter Hurley wrote: > >> While I appreciate the attempt, that's not the problem. >> >> Just to be clear >> >> if (time_before(jiffies, end) && !need_re

Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 11:14 AM, Thomas Gleixner wrote: > On Mon, 29 Feb 2016, Peter Hurley wrote: >> On 02/29/2016 10:24 AM, Eric Dumazet wrote: >>>> Just to be clear >>>> >>>>if (time_before(jiffies, end) && !need_resched() && &g

Softirq priority inversion from "softirq: reduce latencies"

commit, is it just NET_TX/NET_RX softirqs that are causing scheduling latencies? It just doesn't make sense to special case for a workload that isn't even running. Regards, Peter Hurley [1] softirq tasklet latency trace (apologies that it's only events - full function trace introduces to

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

;> >>>>> Thanks, Jacob >>>> >>>> Definitely these details are useful ;) >>>> >>>> Could you try : >>>> >>>> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c >>>> index 6e3af8b42cdd..0c99a74fb895 100644 >>>> --- a/drivers/misc/ti-st/st_core.c >>>> +++ b/drivers/misc/ti-st/st_core.c >>>> @@ -912,7 +912,9 @@ void st_core_exit(struct st_data_s *st_gdata) >>>> skb_queue_purge(_gdata->txq); >>>> skb_queue_purge(_gdata->tx_waitq); >>>> kfree_skb(st_gdata->rx_skb); >>>> + st_gdata->rx_skb = NULL; >>>> kfree_skb(st_gdata->tx_skb); >>>> + st_gdata->tx_skb = NULL; >>>> /* TTY ldisc cleanup */ >>>> err = tty_unregister_ldisc(N_TI_WL); >>>> if (err) FWIW, You don't need that ti-st junk to get the WL1837 working; the WL1837 only has BT channels. Unfortunately, that's really all I can say about it; sorry. Regards, Peter Hurley