Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

On Wed, 20 Jan 2016, Jason Gerecke wrote: > I've been prompted to resurrect this question after fielding yet another > question from a user encountering a locked-up system. We received a > surprising number of reports of people encountering this issue in the > past several weeks and that's

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

On Wed, 20 Jan 2016, Jason Gerecke wrote: > I've been prompted to resurrect this question after fielding yet another > question from a user encountering a locked-up system. We received a > surprising number of reports of people encountering this issue in the > past several weeks and that's

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Sun, Nov 29, 2015 at 2:29 AM, Ioan-Adrian Ratiu wrote: > On Fri, 20 Nov 2015

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Sun, Nov 29, 2015 at 2:29 AM, Ioan-Adrian Ratiu wrote: > On

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Hi Jiri, On Tue, Dec 1, 2015 at 8:36 AM, Jiri Kosina wrote: > On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote: > >> The critical section protected by usbhid->lock in hid_ctrl() is too >> big and because of this it causes a recursive deadlock. "Too big" means >> the case statement and the call to

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote: > The critical section protected by usbhid->lock in hid_ctrl() is too > big and because of this it causes a recursive deadlock. "Too big" means > the case statement and the call to hid_input_report() do not need to be > protected by the spinlock (no

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Hi Jiri, On Tue, Dec 1, 2015 at 8:36 AM, Jiri Kosina wrote: > On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote: > >> The critical section protected by usbhid->lock in hid_ctrl() is too >> big and because of this it causes a recursive deadlock. "Too big" means >> the case statement

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote: > The critical section protected by usbhid->lock in hid_ctrl() is too > big and because of this it causes a recursive deadlock. "Too big" means > the case statement and the call to hid_input_report() do not need to be > protected by the spinlock (no

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

On Fri, 20 Nov 2015 22:19:02 +0200 Ioan-Adrian Ratiu wrote: > The critical section protected by usbhid->lock in hid_ctrl() is too > big and because of this it causes a recursive deadlock. "Too big" means > the case statement and the call to hid_input_report() do not need to be > protected by the

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

On Fri, 20 Nov 2015 22:19:02 +0200 Ioan-Adrian Ratiu wrote: > The critical section protected by usbhid->lock in hid_ctrl() is too > big and because of this it causes a recursive deadlock. "Too big" means > the case statement and the call to hid_input_report() do not need to be >

[PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

The critical section protected by usbhid->lock in hid_ctrl() is too big and because of this it causes a recursive deadlock. "Too big" means the case statement and the call to hid_input_report() do not need to be protected by the spinlock (no URB operations are done inside them). The deadlock

[PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

The critical section protected by usbhid->lock in hid_ctrl() is too big and because of this it causes a recursive deadlock. "Too big" means the case statement and the call to hid_input_report() do not need to be protected by the spinlock (no URB operations are done inside them). The deadlock