Re: [PATCH] tcp: ensure non-empty connection request queue

2016-05-04 Thread Peter Wu
On Tue, May 03, 2016 at 05:25:44PM -0700, Eric Dumazet wrote: > On Tue, 2016-05-03 at 23:54 +0200, Peter Wu wrote: > > When applications use listen() with a backlog of 0, the kernel would > > set the maximum connection request queue to zero. This causes false > > re

[PATCH] tcp: ensure non-empty connection request queue

2016-05-03 Thread Peter Wu
: ef547f2ac16b ("tcp: remove max_qlen_log") Signed-off-by: Peter Wu <pe...@lekensteyn.nl> --- Hi, This patch fixes a regression from Linux 4.4. Use of "qemu-arm -g 1234" would trigger the following warning in dmesg: TCP: request_sock_TCP: Possible SYN flooding on port 1234

[PATCH v2] r8152: fix lockup when runtime PM is enabled

2015-12-08 Thread Peter Wu
is up, rtl8152_open is not called. - When link is down during system/auto suspend/resume, it is not set. Fixes: 41cec84cf285 ("r8152: don't enable napi before rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@al Signed-off-by: Peter Wu <pe...@lekensteyn.nl>

Re: [PATCH] r8152: fix lockup when runtime PM is enabled

2015-12-08 Thread Peter Wu
On Tue, Dec 08, 2015 at 03:18:59AM +, Hayes Wang wrote: > Peter Wu > > Sent: Tuesday, December 08, 2015 12:59 AM > [...] > > + if (tp->netdev->flags & IFF_UP) { > > Maybe you could just replace the checking of netif_running(tp->n

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

2015-12-08 Thread Peter Wu
On Tue, Dec 08, 2015 at 12:39:12PM +, Hayes Wang wrote: > Peter Wu [mailto:pe...@lekensteyn.nl] > > Sent: Tuesday, December 08, 2015 7:18 PM > > > > When an interface is brought up which was previously suspended (via > > runtime PM), it would hang. This happens bec

[PATCH] r8152: fix lockup when runtime PM is enabled

2015-12-07 Thread Peter Wu
efore rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@al Signed-off-by: Peter Wu <pe...@lekensteyn.nl> --- drivers/net/usb/r8152.c | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152

Re: (4.3.0) r8152: deadlock related to runtime suspend?

2015-12-07 Thread Peter Wu
ning (when trying to bring an interface down if I remember correctly). Its trace can be found on the bottom of this mail. I'll keep testing. For the lockdep warning, my initial guess is that calling schedule_delayed_work_sync under tp->lock is a bad idea because scheduled work can execute an

Re: (4.3.0) r8152: deadlock related to runtime suspend?

2015-12-07 Thread Peter Wu
On Mon, Dec 07, 2015 at 07:08:50PM +0800, Lu Baolu wrote: > > > On 12/07/2015 05:37 PM, Peter Wu wrote: > > On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote: > >> Hi Peter, > >> > >> Have you ever tried disabling auto-pm? Did things go smoothly

[PATCH] rtlwifi: fix gigantic memleak in rtl_usb

2015-12-06 Thread Peter Wu
iw wlan1 set channel 11 Then stream a video on a smartphone on channel 11. Without this patch the memory usage grows linearly with the number of received packets: grep MemAvailable /proc/meminfo ip -s link show dev wlan1 Signed-off-by: Peter Wu <pe...@lekensteyn.nl> --- Hi, This

[PATCH v2] rtlwifi: fix memory leak for USB device

2015-12-06 Thread Peter Wu
-off-by: Peter Wu <pe...@lekensteyn.nl> --- v2: updated commit message based on Larry's feedback v1: https://lkml.kernel.org/r/1449424677-3140-1-git-send-email-pe...@lekensteyn.nl Tested with v4.3, rebased on v4.4-rc3 (changed paths). The bug goes back to its introduction in the v2.6.x

Re: [PATCH] rtlwifi: fix gigantic memleak in rtl_usb

2015-12-06 Thread Peter Wu
On Sun, Dec 06, 2015 at 02:18:36PM -0600, Larry Finger wrote: > On 12/06/2015 11:57 AM, Peter Wu wrote: > >Free skb for received frames with a wrong checksum. > > > >While using the rtl8192cu driver in monitor mode, somehow 5G of memory > >was permanently lost (observab

(4.3.0) r8152: deadlock related to runtime suspend?

2015-12-05 Thread Peter Wu
or all devices). This is the USB 3.0 port: 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03) -- Kind regards, Peter Wu https://lekensteyn.nl Dec 05 00:32:58 al kernel: usb 3-1: USB disconnect, device number 4 Dec 05 00:34:43 al NetworkManag