On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: >> Repeated connect/disconnect cycles under GNOME can trigger an occasional >> OOPS from within e.g. wacom_led_select_store, presumably due to a timing >> issue where userspace begins setting a value immediately before the >> device disconnects and our shared data is whisked away. >> >> Signed-off-by: Jason Gerecke <killertofu@xxxxxxxxx> >> --- >> Changes in v2: >> * Added in missing escape character >> >> drivers/hid/wacom_sys.c | 13 ++++++++++++- >> 1 file changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c >> index 8593047..265429b 100644 >> --- a/drivers/hid/wacom_sys.c >> +++ b/drivers/hid/wacom_sys.c >> @@ -641,6 +641,9 @@ static ssize_t wacom_led_select_store(struct device *dev, int set_id, >> unsigned int id; >> int err; >> >> + if (!wacom) >> + return -ENODEV; >> + > > Strong NAK. If device could disappear before this check it could as well > disappear after your check. > > This patch does not solve anything. > I assume I'll want to either disable interrupts or take a lock depending on if `wacom_remove` is called from within the interrupt context, but I haven't had to deal with concurrency in the kernel before so I'm not entirely sure which option (or which primitive if locking) would be appropriate... 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.... >> err = kstrtouint(buf, 10, &id); >> if (err) >> return err; > > Thanks. > > -- > Dmitry > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
