From patchwork Tue Jun 21 03:24:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Torokhov X-Patchwork-Id: 9189223 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0E5C860756 for ; Tue, 21 Jun 2016 03:24:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F0E2327F89 for ; Tue, 21 Jun 2016 03:24:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E257827F8E; Tue, 21 Jun 2016 03:24:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C19A827F89 for ; Tue, 21 Jun 2016 03:24:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752445AbcFUDYP (ORCPT ); Mon, 20 Jun 2016 23:24:15 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34807 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752237AbcFUDYO (ORCPT ); Mon, 20 Jun 2016 23:24:14 -0400 Received: by mail-pf0-f196.google.com with SMTP id 66so318956pfy.1 for ; Mon, 20 Jun 2016 20:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lvqjAUXqEQyu48oStQJnGQtTsCtgDb3G8VtHot4Q6HA=; b=lB8rCc+Vkb3m8r3z4l0STm59LyDZ+a6bRJs3Xx/Zus2bMX8jrygnXvX6xkJp19dc3G MeY2C2z0U9YsfpcIEHFvNI1LJm3oRkCJf4Iyc4YkX+H7Iu2j0BE3qr7rcHRqjsb+l6Xu s8e3AmFxYerkS2ZtYJYnvHSqQZVMCDXeXx/uFb2uIM6WXlHiBeQjjyO+badOEmZRxw/3 LIOqnsa3pBjbE5NP2onyPg9QVPIoWwoxOb3bopItoq3lUY1akFcqtjvV1eAuB4EbtU57 J7GG9gVIw5G0fNcyqWmSWXHS3ifuvUAS/mkz3O6nwx0dmHp3V3Ra1w9bT5H47uHuR+j4 S2nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lvqjAUXqEQyu48oStQJnGQtTsCtgDb3G8VtHot4Q6HA=; b=HbB+DHO+t0/YYowV57Ym5XYuGG9pf3bD9RS/Lhasn8nvXgfkN49LNbeGdRN35WsCVD D/6dpHjx9jR7+On/CnDY6uSEK/Pr20kZKLySZUHbAgWhWj/Y5ZQcn5erp7LkxybzWYxr QeeofpUUSLyIRi9iHXvl9n5SlE0fznkAZTg61U7E41+36ARDt5Jt6F8kYPp8YFVAAsRh sUtOK1kmLv/aW9lvVBSfGu41JG475TF9rtEKaELOmkqQhh2BW+wV2dnadHle0gRvp6X/ QHsypTrGNoOV7jIFpYxF8sB1BQlN4WRVt7cARRWaPvQtvUfOkNbAYBfWoXB/eGWtcbx5 77yg== X-Gm-Message-State: ALyK8tJdWyA3/gV/trHix/3h0GOvfQQZmXZmeA21bnpdCNf8Ev2Wxvwt4rS9+X9C3OWmSQ== X-Received: by 10.98.11.4 with SMTP id t4mr25251572pfi.159.1466479453376; Mon, 20 Jun 2016 20:24:13 -0700 (PDT) Received: from dtor-ws ([2620:0:1000:1311:c9e2:c2f0:108f:d753]) by smtp.gmail.com with ESMTPSA id y70sm91308263pff.25.2016.06.20.20.24.12 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 20 Jun 2016 20:24:12 -0700 (PDT) Date: Mon, 20 Jun 2016 20:24:10 -0700 From: Dmitry Torokhov To: Manuel Reimer Cc: linux-input , Cameron Gutman , jikos@kernel.org Subject: Re: [PATCH] Fix effect aborting in ff-memless Message-ID: <20160621032410.GA35864@dtor-ws> References: <20160620173303.GA22426@dtor-ws> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160620173303.GA22426@dtor-ws> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Jun 20, 2016 at 10:33:03AM -0700, Dmitry Torokhov wrote: > On Sun, Jun 19, 2016 at 02:44:35PM +0200, Manuel Reimer wrote: > > Hello, > > > > while debugging a problem with hid-sony I got stuck with a problem > > actually caused by ff-memless. In some situations effect aborting is > > delayed, so it may be triggered seconds after all devices have been > > destroyed, which causes the kernel to panic. > > > > The aborting request actually gets received here: > > https://github.com/torvalds/linux/blob/master/drivers/input/ff-memless.c#L467 > > This "aborting" flag is then handled here: > > https://github.com/torvalds/linux/blob/master/drivers/input/ff-memless.c#L376 > > But before this line is reached, there is a time check to check if > > the effect actually is due to be started: > > https://github.com/torvalds/linux/blob/master/drivers/input/ff-memless.c#L359 > > > > This time check now causes a problem if the effect, which is meant > > to be *aborted* was scheduled to be *started* some time in future > > and the device is destroyed before this time is reached. > > I am not clear how this can happen. If effect hasn't actually started > playing (i.e. we have FF_EFFECT_STARTED bit set, but FF_EFFECT_PLAYING > is not yet set), then when stopping effect we do not need to do anything > except clear FF_EFFECT_STARTED (since we did not touch the hardware > yet). > > Now, if FF_EFFECT_PLAYING is set, that means that play_at time is in > the past and we won't be skipping this effect in ml_get_combo_effect(). > > Could you please post a stack trace of the crash you observed? Actually, I wonder if the patch below will fix the issue you are seeing. Thanks. diff --git a/drivers/input/input.c b/drivers/input/input.c index d95c34e..220aa17 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -144,7 +144,7 @@ static void input_pass_values(struct input_dev *dev, count = input_to_handler(handle, vals, count); } else { list_for_each_entry_rcu(handle, &dev->h_list, d_node) - if (handle->open) { + if (handle->active) { count = input_to_handler(handle, vals, count); if (!count) break; @@ -552,7 +552,7 @@ static void __input_release_device(struct input_handle *handle) synchronize_rcu(); list_for_each_entry(handle, &dev->h_list, d_node) - if (handle->open && handle->handler->start) + if (handle->active && handle->handler->start) handle->handler->start(handle); } } @@ -613,6 +613,8 @@ int input_open_device(struct input_handle *handle) } } + handle->active = handle->open > 0; + out: mutex_unlock(&dev->mutex); return retval; @@ -663,6 +665,8 @@ void input_close_device(struct input_handle *handle) synchronize_rcu(); } + handle->active = handle->open > 0; + mutex_unlock(&dev->mutex); } EXPORT_SYMBOL(input_close_device); @@ -716,7 +720,7 @@ static void input_disconnect_device(struct input_dev *dev) input_dev_release_keys(dev); list_for_each_entry(handle, &dev->h_list, d_node) - handle->open = 0; + handle->active = false; spin_unlock_irq(&dev->event_lock); } diff --git a/include/linux/input.h b/include/linux/input.h index 1e96769..87ec2f7 100644 --- a/include/linux/input.h +++ b/include/linux/input.h @@ -307,8 +307,10 @@ struct input_handler { /** * struct input_handle - links input device with an input handler * @private: handler-specific data - * @open: counter showing whether the handle is 'open', i.e. should deliver - * events from its device + * @open: counter showing whether the handle is 'open', i.e. there is + * a consumer for the events from input device + * @active: indicates that input events should be delivered from input + * device to input handler through this handle * @name: name given to the handle by handler that created it * @dev: input device the handle is attached to * @handler: handler that works with the device through this handle @@ -321,6 +323,8 @@ struct input_handle { void *private; int open; + bool active; + const char *name; struct input_dev *dev;