* Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: walter harms @ 2019-08-01 10:06 UTC (permalink / raw)
To: Christophe JAILLET
Cc: jikos, benjamin.tissoires, linux-usb, linux-input, linux-kernel,
kernel-janitors
In-Reply-To: <20190801074759.32738-1-christophe.jaillet@wanadoo.fr>
Am 01.08.2019 09:47, schrieb Christophe JAILLET:
> There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
> here. These calls are done from probe functions and using GFP_KERNEL should
> be safe.
> The memory itself is used within some interrupts, but it is not a
> problem, once it has been allocated.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/hid/usbhid/usbkbd.c | 4 ++--
> drivers/hid/usbhid/usbmouse.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> index d5b7a696a68c..63e8ef8beb45 100644
> --- a/drivers/hid/usbhid/usbkbd.c
> +++ b/drivers/hid/usbhid/usbkbd.c
> @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
> return -1;
> if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
> return -1;
> - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
> + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
> return -1;
> if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
> return -1;
> - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
> + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
> return -1;
>
the kernel style is usually:
kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma);
if (!kbd->new)
return -1;
in usbmouse.c this is done, any reason for the change here ?
re,
wh
> return 0;
> diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
> index 073127e65ac1..c89332017d5d 100644
> --- a/drivers/hid/usbhid/usbmouse.c
> +++ b/drivers/hid/usbhid/usbmouse.c
> @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
> if (!mouse || !input_dev)
> goto fail1;
>
> - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
> + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
> if (!mouse->data)
> goto fail1;
>
^ permalink raw reply
* Re: [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Nicolas Saenz Julienne @ 2019-08-01 10:56 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: dmitry.torokhov, wbauer, linux-input, linux-kernel
In-Reply-To: <20190611121320.30267-1-nsaenzjulienne@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Tue, 2019-06-11 at 14:13 +0200, Nicolas Saenz Julienne wrote:
> Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage was being mapped to 'Relative.Misc'. After the patch it's simply
> ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
> hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
> usage->type.
>
> We shouldn't rely on a mapping for that usage as it's nonstandard and
> doesn't really map to an input event. So we bypass the mapping and make
> sure the custom event handling properly handles both reports.
>
> Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
It would be nice for this patch not to get lost. It fixes issues both repoted
on opensuse and fedora.
I can resubmit it if needed.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: Greg KH @ 2019-08-01 13:47 UTC (permalink / raw)
To: walter harms
Cc: Christophe JAILLET, jikos, benjamin.tissoires, linux-usb,
linux-input, linux-kernel, kernel-janitors
In-Reply-To: <5D42B98B.40900@bfs.de>
On Thu, Aug 01, 2019 at 12:06:03PM +0200, walter harms wrote:
>
>
> Am 01.08.2019 09:47, schrieb Christophe JAILLET:
> > There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
> > here. These calls are done from probe functions and using GFP_KERNEL should
> > be safe.
> > The memory itself is used within some interrupts, but it is not a
> > problem, once it has been allocated.
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > ---
> > drivers/hid/usbhid/usbkbd.c | 4 ++--
> > drivers/hid/usbhid/usbmouse.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> > index d5b7a696a68c..63e8ef8beb45 100644
> > --- a/drivers/hid/usbhid/usbkbd.c
> > +++ b/drivers/hid/usbhid/usbkbd.c
> > @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
> > return -1;
> > if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
> > return -1;
> > - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
> > + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
> > return -1;
> > if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
> > return -1;
> > - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
> > + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
> > return -1;
> >
>
> the kernel style is usually:
> kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma);
> if (!kbd->new)
> return -1;
>
>
> in usbmouse.c this is done, any reason for the change here ?
If you want to be extra-correct, don't return -1, return -ENOMEM.
thanks,
greg k-h
^ permalink raw reply
* KASAN: use-after-free Read in hiddev_release
From: syzbot @ 2019-08-01 15:28 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=147ac20c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50
kernel/locking/lockdep.c:3753
Read of size 8 at addr ffff8881cf591a08 by task syz-executor.1/26260
CPU: 1 PID: 26260 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
__lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753
lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221
__fput+0x2d7/0x840 fs/file_table.c:280
task_work_run+0x13f/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x8ef/0x2c50 kernel/exit.c:878
do_group_exit+0x125/0x340 kernel/exit.c:982
get_signal+0x466/0x23d0 kernel/signal.c:2728
do_signal+0x88/0x14e0 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x1a2/0x200 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f75b2a6ccf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000075c078 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000075c078
RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000075c07c
R13: 00007ffcdfe1023f R14: 00007f75b2a6d9c0 R15: 000000000075c07c
Allocated by task 104:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900
hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
hid_hw_start drivers/hid/hid-core.c:1981 [inline]
hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 104:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
hiddev_connect.cold+0x45/0x5c drivers/hid/usbhid/hiddev.c:914
hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
hid_hw_start drivers/hid/hid-core.c:1981 [inline]
hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff8881cf591900
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 264 bytes inside of
512-byte region [ffff8881cf591900, ffff8881cf591b00)
The buggy address belongs to the page:
page:ffffea00073d6400 refcount:1 mapcount:0 mapping:ffff8881da002500
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da002500
raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881cf591900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881cf591980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881cf591a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881cf591a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881cf591b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Dmitry Torokhov @ 2019-08-01 23:49 UTC (permalink / raw)
To: Michal Vokáč
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <f06a913e-09aa-3225-a495-bb290ee2bb6f@ysoft.com>
On Tue, Jul 30, 2019 at 11:25:49AM +0200, Michal Vokáč wrote:
> On 27. 07. 19 9:31, Dmitry Torokhov wrote:
> > On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
> > > On 25. 07. 19 16:40, Dmitry Torokhov wrote:
> > > > On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
> > > > > On 25. 07. 19 10:57, Dmitry Torokhov wrote:
> > > > > > Hi Michal,
> > > > > >
> > > > > > On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
> > > > > > > On 21. 05. 19 7:37, Dmitry Torokhov wrote:
> > > > > > > > Hi Michal,
> > > > > > > >
> > > > > > > > On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I have to deal with a situation where we have a custom i.MX6 based
> > > > > > > > > platform in production that uses the MPR121 touchkey controller.
> > > > > > > > > Unfortunately the chip is connected using only the I2C interface.
> > > > > > > > > The interrupt line is not used. Back in 2015 (Linux v3.14), my
> > > > > > > > > colleague modded the existing mpr121_touchkey.c driver to use polling
> > > > > > > > > instead of interrupt.
> > > > > > > > >
> > > > > > > > > For quite some time yet I am in a process of updating the product from
> > > > > > > > > the ancient Freescale v3.14 kernel to the latest mainline and pushing
> > > > > > > > > any needed changes upstream. The DT files for our imx6dl-yapp4 platform
> > > > > > > > > already made it into v5.1-rc.
> > > > > > > > >
> > > > > > > > > I rebased and updated our mpr121 patch to the latest mainline.
> > > > > > > > > It is created as a separate driver, similarly to gpio_keys_polled.
> > > > > > > > >
> > > > > > > > > The I2C device is quite susceptible to ESD. An ESD test quite often
> > > > > > > > > causes reset of the chip or some register randomly changes its value.
> > > > > > > > > The [PATCH 3/4] adds a write-through register cache. With the cache
> > > > > > > > > this state can be detected and the device can be re-initialied.
> > > > > > > > >
> > > > > > > > > The main question is: Is there any chance that such a polled driver
> > > > > > > > > could be accepted? Is it correct to implement it as a separate driver
> > > > > > > > > or should it be done as an option in the existing driver? I can not
> > > > > > > > > really imagine how I would do that though..
> > > > > > > > >
> > > > > > > > > There are also certain worries that the MPR121 chip may no longer be
> > > > > > > > > available in nonspecifically distant future. In case of EOL I will need
> > > > > > > > > to add a polled driver for an other touchkey chip. May it be already
> > > > > > > > > in mainline or a completely new one.
> > > > > > > >
> > > > > > > > I think that my addition of input_polled_dev was ultimately a wrong
> > > > > > > > thing to do. I am looking into enabling polling mode for regular input
> > > > > > > > devices as we then can enable polling mode in existing drivers.
> > > > > > >
> > > > > > > OK, that sounds good. Especially when one needs to switch from one chip
> > > > > > > to another that is already in tree, the need for a whole new polling
> > > > > > > driver is eliminated.
> > > > > >
> > > > > > Could you please try the patch below and see if it works for your use
> > > > > > case? Note that I have not tried running it, but it compiles so it must
> > > > > > be good ;)
> > > > >
> > > > > Hi Dmitry,
> > > > > Thank you very much for the patch!
> > > > > I gave it a shot and it seems you forgot to add the input-poller.h file
> > > > > to the patch.. it does not compile on my side :(
> > > >
> > > > Oops ;) Please see the updated patch below.
> > >
> > > Thank you, now it is (almost) good as you said :D
> > >
> > > > >
> > > > > > Input: add support for polling to input devices
> > > > > >
> > > > > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > >
> > > > > > Separating "normal" and "polled" input devices was a mistake, as often we want
> > > > > > to allow the very same device work on both interrupt-driven and polled mode,
> > > > > > depending on the board on which the device is used.
> > > > > >
> > > > > > This introduces new APIs:
> > > > > >
> > > > > > - input_setup_polling
> > > > > > - input_set_poll_interval
> > > > > > - input_set_min_poll_interval
> > > > > > - input_set_max_poll_interval
> > > > > >
> > > > > > These new APIs allow switching an input device into polled mode with sysfs
> > > > > > attributes matching drivers using input_polled_dev APIs that will be eventually
> > > > > > removed.
> > > > >
> > > > > After reading this I am not really sure what else needs to be done
> > > > > to test/use the poller. I suspect I need to modify the input device
> > > > > driver (mpr121_touchkey.c in my case) like this:
> > > > >
> > > > > If the interrupt gpio is not provided in DT, the device driver probe
> > > > > function should:
> > > > > - not request the threaded interrupt
> > > > > - call input_setup_polling and provide it with poll_fn
> > > > > Can the mpr_touchkey_interrupt function be used as is for this
> > > > > purpose? The only problem I see is it returns IRQ_HANDLED.
> > > >
> > > > I'd factor out code suitable for polling from mpr_touchkey_interrupt()
> > > > and then do
> > > >
> > > > static irqreturn_t mpr_touchkey_interrupt(...)
> > > > {
> > > > mpr_touchkey_report(...);
> > > > return IRQ_HANDLED;
> > > > }
> > > >
> > >
> > > Probably a trivial problem for experienced kernel hacker but I can not
> > > wrap my head around this - the interrupt handler takes the mpr121
> > > device id as an argument while the poller poll_fn takes struct input_dev.
> > >
> > > I fail to figure out how to get the device id from the input device.
> > >
> Thanks for the hints Dmitry. I am trying my best but still have some
> issues with the input_set/get_drvdata.
>
> The kernel Oopses on NULL pointer dereference in mpr_touchkey_report.
> Here is the backtrace:
>
> [ 2.916960] 8<--- cut here ---
> [ 2.920022] Unable to handle kernel NULL pointer dereference at virtual address 000001d0
> [ 2.928138] pgd = (ptrval)
Ah, that's my fault I believe. Can you please try sticking
poller->input = dev;
into input_setup_polling()?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: Christophe JAILLET @ 2019-08-02 7:51 UTC (permalink / raw)
To: wharms
Cc: jikos, benjamin.tissoires, linux-usb, linux-input, linux-kernel,
kernel-janitors
In-Reply-To: <5D42B98B.40900@bfs.de>
Hi, (and sorry if you receive this email twice. I've used a web mail
which sends HTML by default and it was rejected by ML)
Le 01/08/2019 à 12:06, walter harms a écrit :
>
>
> Am 01.08.2019 09:47, schrieb Christophe JAILLET:
>> There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
>> here. These calls are done from probe functions and using GFP_KERNEL should
>> be safe.
>> The memory itself is used within some interrupts, but it is not a
>> problem, once it has been allocated.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> drivers/hid/usbhid/usbkbd.c | 4 ++--
>> drivers/hid/usbhid/usbmouse.c | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
>> index d5b7a696a68c..63e8ef8beb45 100644
>> --- a/drivers/hid/usbhid/usbkbd.c
>> +++ b/drivers/hid/usbhid/usbkbd.c
>> @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
>> return -1;
>> if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
>> return -1;
>> - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
>> + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
>> return -1;
>> if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
>> return -1;
>> - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
>> + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
>> return -1;
>>
>
> the kernel style is usually:
> kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma);
> if (!kbd->new)
> return -1;
>
Searching with coccinelle with:
* x = usb_alloc_coherent(..., <+... GFP_KERNEL ...+>, ...);
finds 67 files,
whereas:
* x = usb_alloc_coherent(..., <+... GFP_ATOMIC ...+>, ...);
only finds 11 files.
>
> in usbmouse.c this is done, any reason for the change here ?
>
No real reason in fact, just to be consistent with surrounding code.
Unless some allocations are done within a spin_lock/spin_unlock, using
both GFP_KERNEL and GFP_ATOMIC in the same function looks spurious to me.
Either there is a bug (GFP_KERNEL should be GFP_ATOMIC), or a useless
constraint is given to the memory allocator.
CJ
> re,
> wh
>
>> return 0;
>> diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
>> index 073127e65ac1..c89332017d5d 100644
>> --- a/drivers/hid/usbhid/usbmouse.c
>> +++ b/drivers/hid/usbhid/usbmouse.c
>> @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
>> if (!mouse || !input_dev)
>> goto fail1;
>>
>> - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
>> + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
>> if (!mouse->data)
>> goto fail1;
>>
>
^ permalink raw reply
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Greg Kroah-Hartman @ 2019-08-02 10:46 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: x86, linux-input, linux-fbdev, Andy Shevchenko,
Bartlomiej Zolnierkiewicz, Sudeep Holla, linux-kernel, dri-devel,
platform-driver-x86, Tony Prisk, Andy Shevchenko,
Florian Fainelli, Borislav Petkov, H. Peter Anvin, Darren Hart,
Thomas Gleixner, Richard Gong, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20190731131045.GB147138@dtor-ws>
On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> >
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> >
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> >
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound. To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> >
> > All of these patches depend on the first patch. I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
>
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?
I have now done this with patch 1/10. Here's the pull info if any
subsystem maintainer wants to suck this into their tree to provide the
ability for drivers to add/remove attribute groups easily.
This is part of my driver-core tree now, and will go to Linus for
5.4-rc1, along with a few platform drivers that have been acked by their
various subsystem maintainers that convert them to use this new
functionality.
If anyone has any questions about this, please let me know.
thanks,
greg k-h
-------------------
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers
for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:
driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)
----------------------------------------------------------------
dev_groups added to struct driver
Persistent tag for others to pull this branch from
This is the first patch in a longer series that adds the ability for the
driver core to create and remove a list of attribute groups
automatically when the device is bound/unbound from a specific driver.
See:
https://lore.kernel.org/r/20190731124349.4474-2-gregkh@linuxfoundation.org
for details on this patch, and examples of how to use it in other
drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Dmitry Torokhov (1):
driver core: add dev_groups to all drivers
drivers/base/dd.c | 14 ++++++++++++++
include/linux/device.h | 3 +++
2 files changed, 17 insertions(+)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Michal Vokáč @ 2019-08-02 12:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <20190801234954.GA178933@dtor-ws>
On 02. 08. 19 1:49, Dmitry Torokhov wrote:
> On Tue, Jul 30, 2019 at 11:25:49AM +0200, Michal Vokáč wrote:
>> On 27. 07. 19 9:31, Dmitry Torokhov wrote:
>>> On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
>>>> On 25. 07. 19 16:40, Dmitry Torokhov wrote:
>>>>> On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
>>>>>> On 25. 07. 19 10:57, Dmitry Torokhov wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
>>>>>>>> On 21. 05. 19 7:37, Dmitry Torokhov wrote:
>>>>>>>>> Hi Michal,
>>>>>>>>>
>>>>>>>>> On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have to deal with a situation where we have a custom i.MX6 based
>>>>>>>>>> platform in production that uses the MPR121 touchkey controller.
>>>>>>>>>> Unfortunately the chip is connected using only the I2C interface.
>>>>>>>>>> The interrupt line is not used. Back in 2015 (Linux v3.14), my
>>>>>>>>>> colleague modded the existing mpr121_touchkey.c driver to use polling
>>>>>>>>>> instead of interrupt.
>>>>>>>>>>
>>>>>>>>>> For quite some time yet I am in a process of updating the product from
>>>>>>>>>> the ancient Freescale v3.14 kernel to the latest mainline and pushing
>>>>>>>>>> any needed changes upstream. The DT files for our imx6dl-yapp4 platform
>>>>>>>>>> already made it into v5.1-rc.
>>>>>>>>>>
>>>>>>>>>> I rebased and updated our mpr121 patch to the latest mainline.
>>>>>>>>>> It is created as a separate driver, similarly to gpio_keys_polled.
>>>>>>>>>>
>>>>>>>>>> The I2C device is quite susceptible to ESD. An ESD test quite often
>>>>>>>>>> causes reset of the chip or some register randomly changes its value.
>>>>>>>>>> The [PATCH 3/4] adds a write-through register cache. With the cache
>>>>>>>>>> this state can be detected and the device can be re-initialied.
>>>>>>>>>>
>>>>>>>>>> The main question is: Is there any chance that such a polled driver
>>>>>>>>>> could be accepted? Is it correct to implement it as a separate driver
>>>>>>>>>> or should it be done as an option in the existing driver? I can not
>>>>>>>>>> really imagine how I would do that though..
>>>>>>>>>>
>>>>>>>>>> There are also certain worries that the MPR121 chip may no longer be
>>>>>>>>>> available in nonspecifically distant future. In case of EOL I will need
>>>>>>>>>> to add a polled driver for an other touchkey chip. May it be already
>>>>>>>>>> in mainline or a completely new one.
>>>>>>>>>
>>>>>>>>> I think that my addition of input_polled_dev was ultimately a wrong
>>>>>>>>> thing to do. I am looking into enabling polling mode for regular input
>>>>>>>>> devices as we then can enable polling mode in existing drivers.
>>>>>>>>
>>>>>>>> OK, that sounds good. Especially when one needs to switch from one chip
>>>>>>>> to another that is already in tree, the need for a whole new polling
>>>>>>>> driver is eliminated.
>>>>>>>
>>>>>>> Could you please try the patch below and see if it works for your use
>>>>>>> case? Note that I have not tried running it, but it compiles so it must
>>>>>>> be good ;)
>>>>>>
>>>>>> Hi Dmitry,
>>>>>> Thank you very much for the patch!
>>>>>> I gave it a shot and it seems you forgot to add the input-poller.h file
>>>>>> to the patch.. it does not compile on my side :(
>>>>>
>>>>> Oops ;) Please see the updated patch below.
>>>>
>>>> Thank you, now it is (almost) good as you said :D
>>>>
>>>>>>
>>>>>>> Input: add support for polling to input devices
>>>>>>>
>>>>>>> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>>>>>
>>>>>>> Separating "normal" and "polled" input devices was a mistake, as often we want
>>>>>>> to allow the very same device work on both interrupt-driven and polled mode,
>>>>>>> depending on the board on which the device is used.
>>>>>>>
>>>>>>> This introduces new APIs:
>>>>>>>
>>>>>>> - input_setup_polling
>>>>>>> - input_set_poll_interval
>>>>>>> - input_set_min_poll_interval
>>>>>>> - input_set_max_poll_interval
>>>>>>>
>>>>>>> These new APIs allow switching an input device into polled mode with sysfs
>>>>>>> attributes matching drivers using input_polled_dev APIs that will be eventually
>>>>>>> removed.
>>>>>>
>>>>>> After reading this I am not really sure what else needs to be done
>>>>>> to test/use the poller. I suspect I need to modify the input device
>>>>>> driver (mpr121_touchkey.c in my case) like this:
>>>>>>
>>>>>> If the interrupt gpio is not provided in DT, the device driver probe
>>>>>> function should:
>>>>>> - not request the threaded interrupt
>>>>>> - call input_setup_polling and provide it with poll_fn
>>>>>> Can the mpr_touchkey_interrupt function be used as is for this
>>>>>> purpose? The only problem I see is it returns IRQ_HANDLED.
>>>>>
>>>>> I'd factor out code suitable for polling from mpr_touchkey_interrupt()
>>>>> and then do
>>>>>
>>>>> static irqreturn_t mpr_touchkey_interrupt(...)
>>>>> {
>>>>> mpr_touchkey_report(...);
>>>>> return IRQ_HANDLED;
>>>>> }
>>>>>
>>>>
>>>> Probably a trivial problem for experienced kernel hacker but I can not
>>>> wrap my head around this - the interrupt handler takes the mpr121
>>>> device id as an argument while the poller poll_fn takes struct input_dev.
>>>>
>>>> I fail to figure out how to get the device id from the input device.
>>>>
>> Thanks for the hints Dmitry. I am trying my best but still have some
>> issues with the input_set/get_drvdata.
>>
>> The kernel Oopses on NULL pointer dereference in mpr_touchkey_report.
>> Here is the backtrace:
>>
>> [ 2.916960] 8<--- cut here ---
>> [ 2.920022] Unable to handle kernel NULL pointer dereference at virtual address 000001d0
>> [ 2.928138] pgd = (ptrval)
>
> Ah, that's my fault I believe. Can you please try sticking
>
> poller->input = dev;
>
> into input_setup_polling()?
>
Nice, that solved the problem and I confirm the poller mechanism works
as expected. The sysfs poll/min/max interface also works just fine.
Please Cc me when you submit your patch. I think you can already add
my "Tested-by: Michal Vokáč <michal.vokac@ysoft.com>".
I will send mine series when the poller is in your tree. I will include
the proposed DT binding change, adding the "linux,poll-interrupt"
property, though Rob did not respond to this yet.
What about the min/max poll interval limits? Was your idea those should
also be configurable from DT? Currently I defined some limits that are
reasonable for our use case but may not be suitable for someone else.
In the meantime I also need to improve reliability of the reading.
Sometimes the keys get stuck or an electrostatic discharge causes
reset of the chip. I will extract changes that deal with these problems
from the RFC series and from some downstream patches and submit those
later.
Thank you!
Michal
^ permalink raw reply
* Re: [PATCH v4 1/3] mfd: mc13xxx: Add mc34708 adc support
From: Lukasz Majewski @ 2019-08-02 13:19 UTC (permalink / raw)
To: Lee Jones
Cc: linux-kernel, Dmitry Torokhov, Sascha Hauer, Enrico Weigelt,
Thomas Gleixner, Kate Stewart, linux-input
In-Reply-To: <20190725182020.3948c8d9@jawa>
[-- Attachment #1: Type: text/plain, Size: 4752 bytes --]
Hi Lee,
> Hi Lee,
>
> > On Thu, 18 Jul 2019, Lukasz Majewski wrote:
> >
> > > From: Sascha Hauer <s.hauer@pengutronix.de>
> > >
> > > The mc34708 has an improved adc. The older variants will always
> > > convert a fixed order of channels. The mc34708 can do up to eight
> > > conversions in arbitrary channel order. Currently this extended
> > > feature is not supported. We only support touchscreen conversions
> > > now, which will be sampled in a data format compatible to the
> > > older chips in order to keep the API between the mfd and the
> > > touchscreen driver.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > >
> > > ---
> > > Changes for v4:
> > > - None
> > >
> > > Changes for v3:
> > > - None
> > >
> > > Changes for v2:
> > > - Change the return code patch when the mc13xxx ADC is performing
> > > conversion
> > > - Introduce new include/linux/mfd/mc34708.h header file for
> > > mc34708 specific defines
> > >
> > > Changes from the original patches:
> > > - ADC conversion functions prototypes added to fix build error
> > > - Adjustments to make checkpatch clean (-ENOSYS, line over 80
> > > char)
> > >
> > > This patch applies on top of v5.2 - SHA1:
> > > 0ecfebd2b52404ae0c54a878c872bb93363ada36 ---
> > > drivers/mfd/mc13xxx-core.c | 102
> > > +++++++++++++++++++++++++++++++++++++++++++-
> > > drivers/mfd/mc13xxx.h | 3 ++ include/linux/mfd/mc34708.h |
> > > 37 ++++++++++++++++ 3 files changed, 141 insertions(+), 1
> > > deletion(-) create mode 100644 include/linux/mfd/mc34708.h
> > >
> > > diff --git a/drivers/mfd/mc13xxx-core.c
> > > b/drivers/mfd/mc13xxx-core.c index 1abe7432aad8..01473d6fda21
> > > 100644 --- a/drivers/mfd/mc13xxx-core.c
> > > +++ b/drivers/mfd/mc13xxx-core.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/of_device.h>
> > > #include <linux/platform_device.h>
> > > #include <linux/mfd/core.h>
> > > +#include <linux/mfd/mc34708.h>
> > >
> > > #include "mc13xxx.h"
> > >
> > > @@ -45,6 +46,8 @@
> > >
> > > #define MC13XXX_ADC2 45
> > >
> > > +#define MC13XXX_ADC_WORKING (1 << 0)
> >
> > BIT(0) ?
>
> The same convention - i.e. (1 << 0) is used in the rest of the file.
>
> >
> > > void mc13xxx_lock(struct mc13xxx *mc13xxx)
> > > {
> > > if (!mutex_trylock(&mc13xxx->lock)) {
> > > @@ -198,22 +201,30 @@ static void mc34708_print_revision(struct
> > > mc13xxx *mc13xxx, u32 revision) maskval(revision,
> > > MC34708_REVISION_FAB)); }
> > >
> > > +static int mc13xxx_adc_conversion(struct mc13xxx *, unsigned int,
> > > + unsigned int, u8, bool,
> > > unsigned int *); +static int mc34708_adc_conversion(struct
> > > mc13xxx *, unsigned int,
> > > + unsigned int, u8, bool,
> > > unsigned int *); +
> > > /* These are only exported for mc13xxx-i2c and mc13xxx-spi */
> > > struct mc13xxx_variant mc13xxx_variant_mc13783 = {
> > > .name = "mc13783",
> > > .print_revision = mc13xxx_print_revision,
> > > + .adc_do_conversion = mc13xxx_adc_conversion,
> > > };
> > > EXPORT_SYMBOL_GPL(mc13xxx_variant_mc13783);
> >
> > I'd prefer to keep the call-back functions as close to zero as
> > possible.
>
> If I may ask - what is wrong with having per device callback(s) ?
>
> >
> > It would be better to turn mc13xxx_adc_conversion() in to the catch
> > function
>
> Could you share any example?
>
> > choose an execution route based on some platform matching.
> >
>
> Could you help me with giving a hint of how shall I do the "platform
> matching" in this particular driver ?
>
> The mc13xxx driver seems rather complex with SPI and I2C support and
> in which the subdevices are added (e.g. rtc, adc, etc).
>
> This particular patch just follows current driver design and fixes its
> usability for mc13708 drvice.
>
> > If you could do the same for print_revision too, that would be even
> > better.
> >
>
> I would prefer to fix the driver (for mc13708) without the need to
> change the working code.
>
Lee, would you find time to reply to this message?
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] HID: sony: Fix race condition between rumble and device remove.
From: Roderick Colenbrander @ 2019-08-02 22:50 UTC (permalink / raw)
To: linux-input, jikos, benjamin.tissoires
Cc: svv, pgriffais, Roderick Colenbrander, Roderick Colenbrander,
stable
Valve reported a kernel crash on Ubuntu 18.04 when disconnecting a DS4
gamepad while rumble is enabled. This issue is reproducible with a
frequency of 1 in 3 times in the game Borderlands 2 when using an
automatic weapon, which triggers many rumble operations.
We found the issue to be a race condition between sony_remove and the
final device destruction by the HID / input system. The problem was
that sony_remove didn't clean some of its work_item state in
"struct sony_sc". After sony_remove work, the corresponding evdev
node was around for sufficient time for applications to still queue
rumble work after "sony_remove".
On pre-4.19 kernels the race condition caused a kernel crash due to a
NULL-pointer dereference as "sc->output_report_dmabuf" got freed during
sony_remove. On newer kernels this crash doesn't happen due the buffer
now being allocated using devm_kzalloc. However we can still queue work,
while the driver is an undefined state.
This patch fixes the described problem, by guarding the work_item
"state_worker" with an initialized variable, which we are setting back
to 0 on cleanup.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
CC: stable@vger.kernel.org
---
drivers/hid/hid-sony.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 9671a4bad643..31f1023214d3 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -587,10 +587,14 @@ static void sony_set_leds(struct sony_sc *sc);
static inline void sony_schedule_work(struct sony_sc *sc,
enum sony_worker which)
{
+ unsigned long flags;
+
switch (which) {
case SONY_WORKER_STATE:
- if (!sc->defer_initialization)
+ spin_lock_irqsave(&sc->lock, flags);
+ if (!sc->defer_initialization && sc->state_worker_initialized)
schedule_work(&sc->state_worker);
+ spin_unlock_irqrestore(&sc->lock, flags);
break;
case SONY_WORKER_HOTPLUG:
if (sc->hotplug_worker_initialized)
@@ -2553,13 +2557,18 @@ static inline void sony_init_output_report(struct sony_sc *sc,
static inline void sony_cancel_work_sync(struct sony_sc *sc)
{
+ unsigned long flags;
+
if (sc->hotplug_worker_initialized)
cancel_work_sync(&sc->hotplug_worker);
- if (sc->state_worker_initialized)
+ if (sc->state_worker_initialized) {
+ spin_lock_irqsave(&sc->lock, flags);
+ sc->state_worker_initialized = 0;
+ spin_unlock_irqrestore(&sc->lock, flags);
cancel_work_sync(&sc->state_worker);
+ }
}
-
static int sony_input_configured(struct hid_device *hdev,
struct hid_input *hidinput)
{
--
2.21.0
^ permalink raw reply related
* [PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet
From: ohaibuzzle @ 2019-08-03 1:22 UTC (permalink / raw)
To: hdegoede
Cc: dvhart, andy, linux-input, platform-driver-x86, linux-kernel,
Buzzle
From: Buzzle <ohaibuzzle@gmail.com>
---
drivers/platform/x86/touchscreen_dmi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 4370e4add83a..72535b0268eb 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
.properties = chuwi_vi10_props,
};
+static const struct property_entry chuwi_surbook_mini_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_surbook_mini_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = chuwi_surbook_mini_props,
+};
+
static const struct property_entry connect_tablet9_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
@@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
},
},
+ {
+ /* Chuwi Surbook Mini (CWI540) */
+ .driver_data = (void *)&chuwi_surbook_mini_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
+ },
+ },
{
/* Connect Tablet 9 */
.driver_data = (void *)&connect_tablet9_data,
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet
From: Hans de Goede @ 2019-08-03 9:17 UTC (permalink / raw)
To: ohaibuzzle; +Cc: dvhart, andy, linux-input, platform-driver-x86, linux-kernel
In-Reply-To: <20190803012238.4099-1-ohaibuzzle@gmail.com>
Hi "Buzzle",
To submit patches to the Linux kernel you need to use your real-name and
provide a Signed-off-by: line with your real name, see:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Regards,
Hans
On 03-08-19 03:22, ohaibuzzle@gmail.com wrote:
> From: Buzzle <ohaibuzzle@gmail.com>
>
> ---
> drivers/platform/x86/touchscreen_dmi.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
> index 4370e4add83a..72535b0268eb 100644
> --- a/drivers/platform/x86/touchscreen_dmi.c
> +++ b/drivers/platform/x86/touchscreen_dmi.c
> @@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
> .properties = chuwi_vi10_props,
> };
>
> +static const struct property_entry chuwi_surbook_mini_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
> + PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
> + PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
> + PROPERTY_ENTRY_U32("silead,max-fingers", 10),
> + PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
> + { }
> +};
> +
> +static const struct ts_dmi_data chuwi_surbook_mini_data = {
> + .acpi_name = "MSSL1680:00",
> + .properties = chuwi_surbook_mini_props,
> +};
> +
> static const struct property_entry connect_tablet9_props[] = {
> PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
> PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
> @@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
> },
> },
> + {
> + /* Chuwi Surbook Mini (CWI540) */
> + .driver_data = (void *)&chuwi_surbook_mini_data,
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
> + },
> + },
> {
> /* Connect Tablet 9 */
> .driver_data = (void *)&connect_tablet9_data,
>
^ permalink raw reply
* [PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet.
From: Giang Le @ 2019-08-03 14:12 UTC (permalink / raw)
To: hdegoede
Cc: dvhart, andy, linux-input, platform-driver-x86, linux-kernel,
Giang Le
Signed-off-by: Giang Le <ohaibuzzle@gmail.com>
---
drivers/platform/x86/touchscreen_dmi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 4370e4add83a..72535b0268eb 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
.properties = chuwi_vi10_props,
};
+static const struct property_entry chuwi_surbook_mini_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_surbook_mini_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = chuwi_surbook_mini_props,
+};
+
static const struct property_entry connect_tablet9_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
@@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
},
},
+ {
+ /* Chuwi Surbook Mini (CWI540) */
+ .driver_data = (void *)&chuwi_surbook_mini_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
+ },
+ },
{
/* Connect Tablet 9 */
.driver_data = (void *)&connect_tablet9_data,
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Surbook Mini tablet.
From: Hans de Goede @ 2019-08-03 14:16 UTC (permalink / raw)
To: Giang Le; +Cc: dvhart, andy, linux-input, platform-driver-x86, linux-kernel
In-Reply-To: <20190803141222.9460-1-ohaibuzzle@gmail.com>
Hi,
On 03-08-19 16:12, Giang Le wrote:
Hmm, could have used a somewhat more verbose commit message above
the Signed-off-by line, but I guess there is not that much to write
about this patch.
> Signed-off-by: Giang Le <ohaibuzzle@gmail.com>
Patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> drivers/platform/x86/touchscreen_dmi.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
> index 4370e4add83a..72535b0268eb 100644
> --- a/drivers/platform/x86/touchscreen_dmi.c
> +++ b/drivers/platform/x86/touchscreen_dmi.c
> @@ -136,6 +136,22 @@ static const struct ts_dmi_data chuwi_vi10_data = {
> .properties = chuwi_vi10_props,
> };
>
> +static const struct property_entry chuwi_surbook_mini_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-min-x", 88),
> + PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 2040),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 1524),
> + PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-surbook-mini.fw"),
> + PROPERTY_ENTRY_U32("silead,max-fingers", 10),
> + PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
> + { }
> +};
> +
> +static const struct ts_dmi_data chuwi_surbook_mini_data = {
> + .acpi_name = "MSSL1680:00",
> + .properties = chuwi_surbook_mini_props,
> +};
> +
> static const struct property_entry connect_tablet9_props[] = {
> PROPERTY_ENTRY_U32("touchscreen-min-x", 9),
> PROPERTY_ENTRY_U32("touchscreen-min-y", 10),
> @@ -646,6 +662,14 @@ static const struct dmi_system_id touchscreen_dmi_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "S165"),
> },
> },
> + {
> + /* Chuwi Surbook Mini (CWI540) */
> + .driver_data = (void *)&chuwi_surbook_mini_data,
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "C3W6_AP108_4G"),
> + },
> + },
> {
> /* Connect Tablet 9 */
> .driver_data = (void *)&connect_tablet9_data,
>
^ permalink raw reply
* Re: KASAN: use-after-free Read in hiddev_release
From: syzbot @ 2019-08-04 19:22 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
In-Reply-To: <00000000000091efa6058f0fe3d9@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=16f6f53a600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15394cfc600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f0da8a600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50
kernel/locking/lockdep.c:3753
Read of size 8 at addr ffff8881d60d1c88 by task syz-executor289/2034
CPU: 0 PID: 2034 Comm: syz-executor289 Not tainted 5.3.0-rc2+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
__lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753
lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221
__fput+0x2d7/0x840 fs/file_table.c:280
task_work_run+0x13f/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x8ef/0x2c50 kernel/exit.c:878
do_group_exit+0x125/0x340 kernel/exit.c:982
__do_sys_exit_group kernel/exit.c:993 [inline]
__se_sys_exit_group kernel/exit.c:991 [inline]
__x64_sys_exit_group+0x3a/0x50 kernel/exit.c:991
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x444618
Code: Bad RIP value.
RSP: 002b:00007ffd1e60a0d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000444618
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00000000004c4270 R08: 00000000000000e7 R09: ffffffffffffffd0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00000000006d6180 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 21:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900
hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
hid_hw_start drivers/hid/hid-core.c:1981 [inline]
hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
process_scheduled_works kernel/workqueue.c:2331 [inline]
worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 21:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
hiddev_connect.cold+0x45/0x5c drivers/hid/usbhid/hiddev.c:914
hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
hid_hw_start drivers/hid/hid-core.c:1981 [inline]
hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
process_scheduled_works kernel/workqueue.c:2331 [inline]
worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff8881d60d1b80
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 264 bytes inside of
512-byte region [ffff8881d60d1b80, ffff8881d60d1d80)
The buggy address belongs to the page:
page:ffffea0007583400 refcount:1 mapcount:0 mapping:ffff8881da002500
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 ffffea000765a980 0000000800000008 ffff8881da002500
raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881d60d1b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881d60d1c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881d60d1c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881d60d1d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881d60d1d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Jiri Kosina @ 2019-08-05 8:51 UTC (permalink / raw)
To: Hans de Goede
Cc: Petr Vorel, YueHaibing, benjamin.tissoires, linux-kernel,
linux-input
In-Reply-To: <3e9bda5b-68dc-15b9-ca79-2e73567ea0a5@redhat.com>
On Wed, 31 Jul 2019, Hans de Goede wrote:
> >>> In delayedwork_callback(), logi_dj_recv_query_paired_devices
> >>> may return positive value while success now, so check it
> >>> correctly.
> >
> >>> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of
> >>> Fixes: logi_dj_recv_query_hidpp_devices")
> >>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> > OK, not only it didn't fix problems with logitech mouse (see below),
> > but removing mouses USB dongle effectively crashes kernel, so this one
> > probably
> > shouldn't be applied :).
> >
> > [ 330.721629] logitech-djreceiver: probe of 0003:046D:C52F.0013 failed with
> > error 7
> > [ 331.462335] hid 0003:046D:C52F.0013: delayedwork_callback:
> > logi_dj_recv_query_paired_devices error: 7
>
> Please test my patch titled: "HID: logitech-dj: Really fix return value of
> logi_dj_recv_query_hidpp_devices"
> which should fix this.
Hans, have I been CCed on that patch? I don't seem to see it in in inbox.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Hans de Goede @ 2019-08-05 8:55 UTC (permalink / raw)
To: Jiri Kosina
Cc: Petr Vorel, YueHaibing, benjamin.tissoires, linux-kernel,
linux-input
In-Reply-To: <nycvar.YFH.7.76.1908051051080.5899@cbobk.fhfr.pm>
Hi Jiri,
On 05-08-19 10:51, Jiri Kosina wrote:
> On Wed, 31 Jul 2019, Hans de Goede wrote:
>
>>>>> In delayedwork_callback(), logi_dj_recv_query_paired_devices
>>>>> may return positive value while success now, so check it
>>>>> correctly.
>>>
>>>>> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of
>>>>> Fixes: logi_dj_recv_query_hidpp_devices")
>>>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>>> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>>> OK, not only it didn't fix problems with logitech mouse (see below),
>>> but removing mouses USB dongle effectively crashes kernel, so this one
>>> probably
>>> shouldn't be applied :).
>>>
>>> [ 330.721629] logitech-djreceiver: probe of 0003:046D:C52F.0013 failed with
>>> error 7
>>> [ 331.462335] hid 0003:046D:C52F.0013: delayedwork_callback:
>>> logi_dj_recv_query_paired_devices error: 7
>>
>> Please test my patch titled: "HID: logitech-dj: Really fix return value of
>> logi_dj_recv_query_hidpp_devices"
>> which should fix this.
>
> Hans, have I been CCed on that patch? I don't seem to see it in in inbox.
I have "Jiri Kosina <jikos@kernel.org>" in the To: for the patch in the
copy in my Inbox (I always Cc myself).
Anyways, you can grab it here:
https://patchwork.kernel.org/patch/11064087/
It has gathered 2 Tested-by-s and 2 Reviewed-by-s since posting, so
assuming you like it too, this is ready for merging.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Benjamin Tissoires @ 2019-08-05 9:27 UTC (permalink / raw)
To: Hans de Goede
Cc: Jiri Kosina, Petr Vorel, YueHaibing, lkml,
open list:HID CORE LAYER
In-Reply-To: <7988688e-8020-3d03-63cd-d844c01e5bf6@redhat.com>
Hi all,
On Mon, Aug 5, 2019 at 10:55 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Jiri,
>
> On 05-08-19 10:51, Jiri Kosina wrote:
> > On Wed, 31 Jul 2019, Hans de Goede wrote:
> >
> >>>>> In delayedwork_callback(), logi_dj_recv_query_paired_devices
> >>>>> may return positive value while success now, so check it
> >>>>> correctly.
> >>>
> >>>>> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of
> >>>>> Fixes: logi_dj_recv_query_hidpp_devices")
> >>>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >>>> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> >>> OK, not only it didn't fix problems with logitech mouse (see below),
> >>> but removing mouses USB dongle effectively crashes kernel, so this one
> >>> probably
> >>> shouldn't be applied :).
> >>>
> >>> [ 330.721629] logitech-djreceiver: probe of 0003:046D:C52F.0013 failed with
> >>> error 7
> >>> [ 331.462335] hid 0003:046D:C52F.0013: delayedwork_callback:
> >>> logi_dj_recv_query_paired_devices error: 7
> >>
> >> Please test my patch titled: "HID: logitech-dj: Really fix return value of
> >> logi_dj_recv_query_hidpp_devices"
> >> which should fix this.
> >
> > Hans, have I been CCed on that patch? I don't seem to see it in in inbox.
>
> I have "Jiri Kosina <jikos@kernel.org>" in the To: for the patch in the
> copy in my Inbox (I always Cc myself).
>
> Anyways, you can grab it here:
>
> https://patchwork.kernel.org/patch/11064087/
>
> It has gathered 2 Tested-by-s and 2 Reviewed-by-s since posting, so
> assuming you like it too, this is ready for merging.
>
Sorry for being silent on the mailing list.
I have been 2 weeks on PTO, and when I came back, my server that shown
a few corruptions here and there was completely broken.
I spent the last week trying to revive it until I realized that I have
a bad memory chip on it, which introduced random errors.
Anyway, I think Hans' patch should go in, but I am not fully
operational given that my test box is still recovering :(
Cheers,
Benjamin
^ permalink raw reply
* [PATCH] Input: docs: fix spelling mistake "potocol" -> "protocol"
From: Colin King @ 2019-08-05 10:49 UTC (permalink / raw)
To: Henrik Rydberg, Dmitry Torokhov, Jonathan Corbet, linux-input,
linux-doc
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a minor spelling mistake in the documentation, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
Documentation/input/multi-touch-protocol.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/input/multi-touch-protocol.rst b/Documentation/input/multi-touch-protocol.rst
index 6be70342e709..307fe22d9668 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -23,7 +23,7 @@ devices capable of tracking identifiable contacts (type B), the protocol
describes how to send updates for individual contacts via event slots.
.. note::
- MT potocol type A is obsolete, all kernel drivers have been
+ MT protocol type A is obsolete, all kernel drivers have been
converted to use type B.
Protocol Usage
--
2.20.1
^ permalink raw reply related
* WARNING in usbtouch_reset_resume
From: syzbot @ 2019-08-05 11:58 UTC (permalink / raw)
To: allison, andreyknvl, dmitry.torokhov, gregkh, kstewart,
linux-input, linux-kernel, linux-usb, mpe, rfontana, rydberg,
syzkaller-bugs, tglx
Hello,
syzbot found the following crash on:
HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1104baf8600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
dashboard link: https://syzkaller.appspot.com/bug?extid=91f7bbcce580376d784e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14199a62600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17d94aaa600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+91f7bbcce580376d784e@syzkaller.appspotmail.com
input: USB Touchscreen 0eef:0002 as
/devices/platform/dummy_hcd.0/usb1/1-1/1-1:0.180/input/input5
usb 1-1: reset high-speed USB device number 2 using dummy_hcd
usb 1-1: Using ep0 maxpacket: 32
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 0 PID: 12 at kernel/locking/mutex.c:912 __mutex_lock_common
kernel/locking/mutex.c:912 [inline]
WARNING: CPU: 0 PID: 12 at kernel/locking/mutex.c:912
__mutex_lock+0xd31/0x1360 kernel/locking/mutex.c:1077
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc2+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
panic+0x2a3/0x6da kernel/panic.c:219
__warn.cold+0x20/0x4a kernel/panic.c:576
report_bug+0x262/0x2a0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272
do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1026
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:912 [inline]
RIP: 0010:__mutex_lock+0xd31/0x1360 kernel/locking/mutex.c:1077
Code: d2 0f 85 f6 05 00 00 44 8b 05 7b de 1c 02 45 85 c0 0f 85 0a f4 ff ff
48 c7 c6 c0 92 c6 85 48 c7 c7 60 90 c6 85 e8 f4 c4 a6 fb <0f> 0b e9 f0 f3
ff ff 65 48 8b 1c 25 00 ef 01 00 be 08 00 00 00 48
RSP: 0018:ffff8881da20f6b0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8128a0fd RDI: ffffed103b441ec8
RBP: ffff8881da20f820 R08: ffff8881da1f9800 R09: fffffbfff0d9ee35
R10: fffffbfff0d9ee34 R11: ffffffff86cf71a3 R12: 0000000000000000
R13: dffffc0000000000 R14: ffff8881d2e291c8 R15: ffff8881d2fba228
usbtouch_reset_resume+0xb1/0x170
drivers/input/touchscreen/usbtouchscreen.c:1611
usb_resume_interface drivers/usb/core/driver.c:1242 [inline]
usb_resume_interface.isra.0+0x184/0x390 drivers/usb/core/driver.c:1210
usb_resume_both+0x26a/0x7b0 drivers/usb/core/driver.c:1412
__rpm_callback+0x27e/0x3c0 drivers/base/power/runtime.c:355
rpm_callback+0x18f/0x230 drivers/base/power/runtime.c:485
rpm_resume+0x10f7/0x1870 drivers/base/power/runtime.c:849
__pm_runtime_resume+0x103/0x180 drivers/base/power/runtime.c:1076
pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline]
usb_autoresume_device+0x1e/0x60 drivers/usb/core/driver.c:1599
usb_remote_wakeup+0x7b/0xb0 drivers/usb/core/hub.c:3603
hub_port_connect_change drivers/usb/core/hub.c:5199 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x246c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: use-after-free Read in usbhid_wait_io
From: syzbot @ 2019-08-05 11:58 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=136bed1a600000
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=cff772ea5b2812d504a9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cff772ea5b2812d504a9@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in test_bit
include/asm-generic/bitops-instrumented.h:237 [inline]
BUG: KASAN: use-after-free in usbhid_wait_io+0xc9/0x3a0
drivers/hid/usbhid/hid-core.c:646
Read of size 8 at addr ffff8881c84068c0 by task syz-executor.2/3548
CPU: 1 PID: 3548 Comm: syz-executor.2 Not tainted 5.3.0-rc2+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x128/0x190 mm/kasan/generic.c:192
test_bit include/asm-generic/bitops-instrumented.h:237 [inline]
usbhid_wait_io+0xc9/0x3a0 drivers/hid/usbhid/hid-core.c:646
usbhid_init_reports+0x119/0x320 drivers/hid/usbhid/hid-core.c:774
hiddev_ioctl+0x10ed/0x1550 drivers/hid/usbhid/hiddev.c:792
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fb23788ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000020005700 RSI: 0000000040184810 RDI: 0000000000000008
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb23788f6d4
R13: 00000000004c2104 R14: 00000000004d5490 R15: 00000000ffffffff
Allocated by task 12:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
slab_post_alloc_hook mm/slab.h:520 [inline]
slab_alloc_node mm/slub.c:2766 [inline]
__kmalloc_node_track_caller+0xd0/0x230 mm/slub.c:4361
__kmalloc_reserve.isra.0+0x39/0xe0 net/core/skbuff.c:141
__alloc_skb+0xef/0x5a0 net/core/skbuff.c:209
alloc_skb include/linux/skbuff.h:1055 [inline]
alloc_uevent_skb+0x7b/0x210 lib/kobject_uevent.c:289
uevent_net_broadcast_untagged lib/kobject_uevent.c:325 [inline]
kobject_uevent_net_broadcast lib/kobject_uevent.c:408 [inline]
kobject_uevent_env+0x8ee/0x1160 lib/kobject_uevent.c:592
__device_release_driver drivers/base/dd.c:1140 [inline]
device_release_driver_internal+0x3c4/0x4c0 drivers/base/dd.c:1151
bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:556
device_del+0x420/0xb10 drivers/base/core.c:2288
usb_disconnect+0x4c3/0x8d0 drivers/usb/core/hub.c:2225
hub_port_connect drivers/usb/core/hub.c:4949 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 240:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
skb_free_head+0x8b/0xa0 net/core/skbuff.c:591
skb_release_data+0x41f/0x7c0 net/core/skbuff.c:611
skb_release_all+0x46/0x60 net/core/skbuff.c:665
__kfree_skb net/core/skbuff.c:679 [inline]
consume_skb net/core/skbuff.c:838 [inline]
consume_skb+0xd9/0x320 net/core/skbuff.c:832
skb_free_datagram+0x16/0xf0 net/core/datagram.c:328
netlink_recvmsg+0x65e/0xee0 net/netlink/af_netlink.c:1996
sock_recvmsg_nosec net/socket.c:871 [inline]
sock_recvmsg net/socket.c:889 [inline]
sock_recvmsg+0xca/0x110 net/socket.c:885
___sys_recvmsg+0x271/0x5a0 net/socket.c:2480
__sys_recvmsg+0xe9/0x1b0 net/socket.c:2537
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881c8406880
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 64 bytes inside of
1024-byte region [ffff8881c8406880, ffff8881c8406c80)
The buggy address belongs to the page:
page:ffffea0007210100 refcount:1 mapcount:0 mapping:ffff8881da002280
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da002280
raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881c8406780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881c8406800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c8406880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881c8406900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881c8406980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH 1/2] HID: Add Saitek X52 to the HID IDs
From: Jiri Kosina @ 2019-08-05 12:12 UTC (permalink / raw)
To: István Váradi; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20190724180806.5745-1-ivaradi@varadiistvan.hu>
On Wed, 24 Jul 2019, István Váradi wrote:
> The USB device ID of the Saitek X52 joystick is added as a
> define to hid-ids.h.
>
> Signed-off-by: István Váradi <ivaradi@varadiistvan.hu>
> ---
> drivers/hid/hid-ids.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 0d695f8e1b2c..3a90962614ef 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -989,6 +989,7 @@
> #define USB_DEVICE_ID_SAITEK_RAT7 0x0cd7
> #define USB_DEVICE_ID_SAITEK_RAT9 0x0cfa
> #define USB_DEVICE_ID_SAITEK_MMO7 0x0cd0
> +#define USB_DEVICE_ID_SAITEK_X52 0x075c
>
> #define USB_VENDOR_ID_SAMSUNG 0x0419
> #define USB_DEVICE_ID_SAMSUNG_IR_REMOTE 0x0001
István,
thanks for the fix. I don't think it's necessary to have this as a
split-out change from the quirk addition. I've squashed the two patches
into one, and applied to for-5.3/upstream-fixes.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: fix bit shift for Cintiq Companion 2
From: Jiri Kosina @ 2019-08-05 12:15 UTC (permalink / raw)
To: Aaron Armstrong Skomra
Cc: linux-input, benjamin.tissoires, pinglinux, jason.gerecke,
Aaron Armstrong Skomra, # v4 . 5+
In-Reply-To: <1563905355-20921-1-git-send-email-aaron.skomra@wacom.com>
On Tue, 23 Jul 2019, Aaron Armstrong Skomra wrote:
> The bit indicating BTN_6 on this device is overshifted
> by 2 bits, resulting in the incorrect button being
> reported.
>
> Also fix copy-paste mistake in comments.
>
> Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
> Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
> Link: https://github.com/linuxwacom/xf86-input-wacom/issues/71
> Fixes: c7f0522a1ad1 ("HID: wacom: Slim down wacom_intuos_pad processing")
> Cc: <stable@vger.kernel.org> # v4.5+
Applied to for-5.3/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: KASAN: use-after-free Read in hiddev_release
From: Jiri Kosina @ 2019-08-05 12:24 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, andreyknvl, benjamin.tissoires, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
In-Reply-To: <20190805081212.3144-1-hdanton@sina.com>
On Mon, 5 Aug 2019, Hillf Danton wrote:
> 1, no dev no open.
>
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
> @@ -284,6 +284,10 @@ static int hiddev_open(struct inode *ino
> spin_unlock_irq(&list->hiddev->list_lock);
>
> mutex_lock(&hiddev->existancelock);
> + if (!list->hiddev->exist) {
> + res = -ENODEV;
> + goto bail_unlock;
> + }
> if (!list->hiddev->open++)
> if (list->hiddev->exist) {
> struct hid_device *hid = hiddev->hid;
> --
>
> 2, list_del before vfree.
>
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
> @@ -300,6 +304,9 @@ bail_normal_power:
> hid_hw_power(hid, PM_HINT_NORMAL);
> bail_unlock:
> mutex_unlock(&hiddev->existancelock);
> + spin_lock_irq(&list->hiddev->list_lock);
> + list_del(&list->node);
> + spin_unlock_irq(&list->hiddev->list_lock);
> bail:
> file->private_data = NULL;
> vfree(list);
Hilf,
both patches look good to me. Could you please resend them properly so
that I could apply them? Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: Add quirk for HP X1200 PIXART OEM mouse
From: Jiri Kosina @ 2019-08-05 12:25 UTC (permalink / raw)
To: Sebastian Parschauer; +Cc: Benjamin Tissoires, linux-input, stable
In-Reply-To: <20190724184003.12402-1-s.parschauer@gmx.de>
On Wed, 24 Jul 2019, Sebastian Parschauer wrote:
> The PixArt OEM mice are known for disconnecting every minute in
> runlevel 1 or 3 if they are not always polled. So add quirk
> ALWAYS_POLL for this one as well.
>
> Jonathan Teh (@jonathan-teh) reported and tested the quirk.
> Reference: https://github.com/sriemer/fix-linux-mouse/issues/15
>
> Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de>
> CC: stable@vger.kernel.org
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox