[PATCH net 0/2] r8152: fix rx issues

[Hayes Wang]

The two patched are used to fix rx issues.

Hayes Wang (2):
  r8152: fix wrong checksum status for received IPv4 packets
  r8152: set rx mode early when linking on

 drivers/net/usb/r8152.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

-- 
2.13.6

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net 1/2] r8152: fix wrong checksum status for received IPv4 packets

[Hayes Wang]

The device could only check the checksum of TCP and UDP packets. Therefore,
for the IPv4 packets excluding TCP and UDP, the check of checksum is necessary,
even though the IP checksum is correct.

Take ICMP for example, The IP checksum may be correct, but the ICMP checksum
may be wrong.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0657203ffb91..756de9ea8d2e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1848,11 +1848,9 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc 
*rx_desc)
if (opts2 & RD_IPV4_CS) {
if (opts3 & IPF)
checksum = CHECKSUM_NONE;
-   else if ((opts2 & RD_UDP_CS) && (opts3 & UDPF))
-   checksum = CHECKSUM_NONE;
-   else if ((opts2 & RD_TCP_CS) && (opts3 & TCPF))
-   checksum = CHECKSUM_NONE;
-   else
+   else if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
+   checksum = CHECKSUM_UNNECESSARY;
+   else if ((opts2 & RD_TCP_CS) && !(opts3 & TCPF))
checksum = CHECKSUM_UNNECESSARY;
} else if (opts2 & RD_IPV6_CS) {
if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
-- 
2.13.6

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net 2/2] r8152: set rx mode early when linking on

[Hayes Wang]

Set rx mode before calling netif_wake_queue() when linking on to avoid
the device missing the receiving packets.

The transmission may start after calling netif_wake_queue(), and the
packets of resopnse may reach before calling rtl8152_set_rx_mode()
which let the device could receive packets. Then, the packets of
response would be missed.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 756de9ea8d2e..958b2e8b90f6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3795,11 +3795,12 @@ static void set_carrier(struct r8152 *tp)
if (speed & LINK_STATUS) {
if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
-   set_bit(RTL8152_SET_RX_MODE, &tp->flags);
netif_stop_queue(netdev);
napi_disable(napi);
netif_carrier_on(netdev);
rtl_start_rx(tp);
+   clear_bit(RTL8152_SET_RX_MODE, &tp->flags);
+   _rtl8152_set_rx_mode(netdev);
napi_enable(&tp->napi);
netif_wake_queue(netdev);
netif_info(tp, link, netdev, "carrier on\n");
@@ -4259,7 +4260,7 @@ static int rtl8152_post_reset(struct usb_interface *intf)
mutex_lock(&tp->control);
tp->rtl_ops.enable(tp);
rtl_start_rx(tp);
-   rtl8152_set_rx_mode(netdev);
+   _rtl8152_set_rx_mode(netdev);
mutex_unlock(&tp->control);
}
 
-- 
2.13.6

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.9] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit

[Greg KH]

On Mon, Jan 29, 2018 at 01:13:32PM -0700, Shuah Khan wrote:
> On 01/28/2018 05:14 AM, Greg KH wrote:
> > On Fri, Jan 26, 2018 at 11:54:35AM -0700, Shuah Khan wrote:
> >> Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
> >> support")
> > 
> > Hm, I think you have the wrong commit id here.
> > 
> > I don't see any commit upstream with the Subject you have here, what are
> > you referring to?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> That is odd. Th commit went in a while back. Here are the details:
> 
> This is the commit from upstream:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/usbip/vhci_hcd.c?id=1c9de5bf428612458427943b724bea51abde520a
> 
> commit 1c9de5bf428612458427943b724bea51abde520a
> Author: Yuyang Du 
> Date:   Thu Jun 8 13:04:10 2017 +0800
> 
> usbip: vhci-hcd: Add USB3 SuperSpeed support
> 
> This patch adds a USB3 HCD to an existing USB2 HCD and provides
> the support of SuperSpeed, in case the device can only be enumerated
> with SuperSpeed.
> 
> The bulk of the added code in usb3_bos_desc and hub_control to support
> SuperSpeed is borrowed from the commit 1cd8fd2887e162ad ("usb: gadget:
> dummy_hcd: add SuperSpeed support").
> 
> With this patch, each vhci will have VHCI_HC_PORTS HighSpeed ports
> and VHCI_HC_PORTS SuperSpeed ports.
> 
> Suggested-by: Krzysztof Opasiak 
> Signed-off-by: Yuyang Du 
> Acked-by: Shuah Khan 
> Signed-off-by: Greg Kroah-Hartman 
> 
> 
> I isolated and backported a one line fix to the problem I saw in 4.9
> and 4.4 stables.

Ah, the "isolation" part is what I missed here, sorry about that.  You
are right, I'll go queue this up now, sorry for the noise.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: host: ehci: always enable interrupt for qtd completion at test mode

[Alan Stern]

On Fri, 2 Feb 2018, Peter Chen wrote:

> On Thu, Feb 01, 2018 at 02:24:29PM -0500, Alan Stern wrote:
> > On Thu, 1 Feb 2018, Peter Chen wrote:
> > 
> > > At former code, the SETUP stage does not enable interrupt
> > > for qtd completion, it relies on IAA watchdog to complete
> > > interrupt, then the transcation would be considered timeout
> > > if the flag need_io_watchdog is cleared by platform code.
> > > 
> > > In this commit, we always add enable interrupt for qtd completion,
> > > then the qtd completion can be notified by hardware interrupt.
> > > 
> > > Signed-off-by: Peter Chen 
> > > ---
> > >  drivers/usb/host/ehci-q.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> > > index 8815832..4cc2609 100644
> > > --- a/drivers/usb/host/ehci-q.c
> > > +++ b/drivers/usb/host/ehci-q.c
> > > @@ -1192,6 +1192,8 @@ static int submit_single_step_set_feature(
> > >   qtd_fill(ehci, qtd, urb->setup_dma,
> > >   sizeof(struct usb_ctrlrequest),
> > >   token | (2 /* "setup" */ << 8), 8);
> > > + /* Always enable interrupt on qtd completion */
> > > + qtd->hw_token |= cpu_to_hc32(ehci, QTD_IOC);
> > 
> > This would be cleaner if you didn't make it a separate statement.  
> > Before the call to qtd_fill(), you can do:
> > 
> > token |= QTD_IOC;   /* Interrupt after SETUP completion */
> 
> Since the variable "token" is used for every qtd, but I do not want
> interrupt for DATA stage, how about adding QTD_IOC directly at
> qtd_fill for both SETUP and STATUS stage?
> 
>   qtd_fill(ehci, qtd, urb->setup_dma,
>   sizeof(struct usb_ctrlrequest),
>   QTD_IOC | token | (2 /* "setup" */ << 8), 8);

That would be okay.  You might want to include a comment line as well.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V2][PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

[Alan Stern]

On Fri, 2 Feb 2018, Haiqing Bai wrote:

> From: Shigeru Yoshida 
> 
> Running io_watchdog_func() while ohci_urb_enqueue() is running can
> cause a race condition where ohci->prev_frame_no is corrupted and the
> watchdog can mis-detect following error:
> 
>   ohci-platform 664a0800.usb: frame counter not updating; disabled
>   ohci-platform 664a0800.usb: HC died; cleaning up
> 
> Specifically, following scenario causes a race condition:
> 
>   1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
>  and enters the critical section
>   2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
>  returns false
>   3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
>  read by ohci_frame_no(ohci)
>   4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
>   5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
>  flags) and exits the critical section
>   6. Later, ohci_urb_enqueue() is called
>   7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
>  and enters the critical section
>   8. The timer scheduled on step 4 expires and io_watchdog_func() runs
>   9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
>  and waits on it because ohci_urb_enqueue() is already in the
>  critical section on step 7
>  10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
>  returns false
>  11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
>  read by ohci_frame_no(ohci) because the frame number proceeded
>  between step 3 and 6
>  12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
>  13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
>  flags) and exits the critical section, then wake up
>  io_watchdog_func() which is waiting on step 9
>  14. io_watchdog_func() enters the critical section
>  15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
>  variable to the frame number
>  16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
> 
> On step 16, because this calling of io_watchdog_func() is scheduled on
> step 4, the frame number set in ohci->prev_frame_no is expected to the
> number set on step 3.  However, ohci->prev_frame_no is overwritten on
> step 11.  Because step 16 is executed soon after step 11, the frame
> number might not proceed, so ohci->prev_frame_no must equals to
> frame_no.
> 
> To address above scenario, this patch introduces a special sentinel
> value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when
> the watchdog is not pending or running.  When ohci_urb_enqueue()
> schedules the watchdog (step 4 and 12 above), it compares
> ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is
> not overwritten while io_watchdog_func() is running.
> 
> v2: Instead of adding an extra flag variable, defining IO_WATCHDOG_OFF
> as a special sentinel value for prev_frame_no.
> 
> Signed-off-by: Shigeru Yoshida 
> Signed-off-by: Haiqing Bai 

The "v2" explanation is supposed to go below the "---" tear line, but 
that doesn't matter much.  In any case,

Acked-by: Alan Stern 

You know, this could have been fixed a lot more easily if the core
kernel had a timer_pending_or_executing() routine.  I bet there are
other places in the kernel that suffer from the same bug and need the
same fix.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Add delay-init quirk for Corsair K70 RGB keyboards

[JackStocker]

From: Jack Stocker 

Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.

Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard 

Signed-off-by: Jack Stocker 
---
 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index a6aaf2f..9eb92dc 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -221,6 +221,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
 
+   /* Corsair K70 RGB */
+   { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* MIDI keyboard WORLDE MINI */
{ USB_DEVICE(0x1c75, 0x0204), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add delay-init quirk for Corsair K70 RGB keyboards

[Dmitry Fleytman]

> On 2 Feb 2018, at 17:51, JackStocker  wrote:
> 
> From: Jack Stocker 
> 
> Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
> Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
> start correctly at boot.
> 
> Device ids found here:
> usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
> usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-3: Product: Corsair K70 RGB Gaming Keyboard 

Reviewed-by: Dmitry Fleytman 

> 
> Signed-off-by: Jack Stocker 
> ---
> drivers/usb/core/quirks.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index a6aaf2f..9eb92dc 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -221,6 +221,9 @@ static const struct usb_device_id usb_quirk_list[] = {
>   /* Corsair Strafe RGB */
>   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
> 
> + /* Corsair K70 RGB */
> + { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
> +
>   /* MIDI keyboard WORLDE MINI */
>   { USB_DEVICE(0x1c75, 0x0204), .driver_info =
>   USB_QUIRK_CONFIG_INTF_STRINGS },
> -- 
> 2.7.4
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: dwc3: Fix GDBGFIFOSPACE_TYPE values

[Thinh Nguyen]

The FIFO/Queue type values are incorrect. Correct them according to
DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25).

Additionally, this patch includes ProtocolStatusQ and AuxEventQ types.

Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper")
Signed-off-by: Thinh Nguyen 
---
 drivers/usb/dwc3/core.h | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 03c7c926..185b9603fd98 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -158,13 +158,15 @@
 #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
 #define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0x)
 
-#define DWC3_TXFIFOQ   1
-#define DWC3_RXFIFOQ   3
-#define DWC3_TXREQQ5
-#define DWC3_RXREQQ7
-#define DWC3_RXINFOQ   9
-#define DWC3_DESCFETCHQ13
-#define DWC3_EVENTQ15
+#define DWC3_TXFIFOQ   0
+#define DWC3_RXFIFOQ   1
+#define DWC3_TXREQQ2
+#define DWC3_RXREQQ3
+#define DWC3_RXINFOQ   4
+#define DWC3_PSTATQ5
+#define DWC3_DESCFETCHQ6
+#define DWC3_EVENTQ7
+#define DWC3_AUXEVENTQ 8
 
 /* Global RX Threshold Configuration Register */
 #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19)
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KASAN: use-after-free Read in mon_bin_vma_fault

[Eric Biggers]

On Thu, Dec 28, 2017 at 12:15:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> beacbc68ac3e23821a681adb30b45dc55b17488d
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9cd6f6d80e1a5205f...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> ==
> BUG: KASAN: use-after-free in mon_bin_vma_fault+0x378/0x400
> drivers/usb/mon/mon_bin.c:1238
> Read of size 8 at addr 8801cd040080 by task syz-executor1/5424
> 
> CPU: 1 PID: 5424 Comm: syz-executor1 Not tainted 4.15.0-rc5+ #238
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  mon_bin_vma_fault+0x378/0x400 drivers/usb/mon/mon_bin.c:1238
>  __do_fault+0xeb/0x30f mm/memory.c:3196
>  do_read_fault mm/memory.c:3606 [inline]
>  do_fault mm/memory.c:3706 [inline]
>  handle_pte_fault mm/memory.c:3937 [inline]
>  __handle_mm_fault+0x1d8f/0x3ce0 mm/memory.c:4061
>  handle_mm_fault+0x334/0x8d0 mm/memory.c:4098
>  faultin_page mm/gup.c:502 [inline]
>  __get_user_pages+0x50c/0x15f0 mm/gup.c:699
>  populate_vma_page_range+0x20e/0x2f0 mm/gup.c:1216
>  __mm_populate+0x23a/0x450 mm/gup.c:1266
>  mm_populate include/linux/mm.h:2226 [inline]
>  vm_mmap_pgoff+0x241/0x280 mm/util.c:338
>  SYSC_mmap_pgoff mm/mmap.c:1533 [inline]
>  SyS_mmap_pgoff+0x462/0x5f0 mm/mmap.c:1491
>  SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>  SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452ac9
> RSP: 002b:7f7721b03c58 EFLAGS: 0212 ORIG_RAX: 0009
> RAX: ffda RBX: 0071bea0 RCX: 00452ac9
> RDX: 0104 RSI: 4000 RDI: 20ac6000
> RBP: 039b R08: 0014 R09: 
> R10: 8011 R11: 0212 R12: 006f2728
> R13:  R14: 7f7721b046d4 R15: 
> 
> Allocated by task 5424:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3610
>  kmalloc include/linux/slab.h:499 [inline]
>  kzalloc include/linux/slab.h:688 [inline]
>  mon_bin_open+0x1ae/0x4a0 drivers/usb/mon/mon_bin.c:703
>  chrdev_open+0x257/0x730 fs/char_dev.c:417
>  do_dentry_open+0x667/0xd40 fs/open.c:752
>  vfs_open+0x107/0x220 fs/open.c:866
>  do_last fs/namei.c:3379 [inline]
>  path_openat+0x1151/0x3530 fs/namei.c:3519
>  do_filp_open+0x25b/0x3b0 fs/namei.c:3554
>  do_sys_open+0x502/0x6d0 fs/open.c:1059
>  SYSC_open fs/open.c:1077 [inline]
>  SyS_open+0x2d/0x40 fs/open.c:1072
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 5433:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kfree+0xd6/0x260 mm/slab.c:3803
>  mon_bin_ioctl+0x68d/0xd40 drivers/usb/mon/mon_bin.c:1040
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> The buggy address belongs to the object at 8801cd040080
>  which belongs to the cache kmalloc-2048 of size 2048
> The buggy address is located 0 bytes inside of
>  2048-byte region [8801cd040080, 8801cd040880)
> The buggy address belongs to the page:
> page:3d43a99d count:1 mapcount:0 mapping:83654cb9 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc008100(slab|head)
> raw: 02fffc008100 8801cd040080  00010003
> raw: ea00072a2e20 ea00071e6920 8801db000c40 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  8801cd03ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  8801cd04: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > 8801cd040080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>^
>  8801cd040100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8801cd040180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==

Re: [PATCH net 0/2] r8152: fix rx issues

[David Miller]

From: Hayes Wang 
Date: Fri, 2 Feb 2018 16:43:34 +0800

> The two patched are used to fix rx issues.

Series applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html