From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
Peter Hutterer <peter.hutterer@who-t.net>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] input - leds: fix input_led_disconnect path
Date: Fri, 15 Dec 2017 16:48:46 -0800 [thread overview]
Message-ID: <20171216004846.3blocf4u45adwalh@dtor-ws> (raw)
In-Reply-To: <20171214132522.20346-3-benjamin.tissoires@redhat.com>
Hi Benjamin,
On Thu, Dec 14, 2017 at 02:25:22PM +0100, Benjamin Tissoires wrote:
> Before unregistering the led classes, we have to be sure there is no
> more events in the input pipeline.
> Closing the input node before removing the led classes flushes the
> pipeline and this prevents segfaults.
I do not think this actually the issue. input_leds_event() is an empty
stub, it does not really do anything with events it receives form input
core, and it does not reference the led structures. The way input leds
work is that input driver owns the hardware led and is responsible for
communicating with it. The LED subsystem is a secondary interface,
requests coming from /sys/class/led/... are being forwarded to the input
core and then to the input hardware driver by the way of:
input_leds_brightness_set() ->
input_inject_event() ->
input_handle_event()->
disposition & INPUT_PASS_TO_DEVICE
dev->event() (in atkbd or hid-input)
actual control of LED
I do not see how stopping event flow from input core to input-leds would
help here.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2017-12-16 0:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 13:25 [PATCH 0/2] input - leds: fix bugs found by fuzzing Benjamin Tissoires
2017-12-14 13:25 ` [PATCH 1/2] input - leds: do not iterate over non initialized leds Benjamin Tissoires
2017-12-14 13:25 ` [PATCH 2/2] input - leds: fix input_led_disconnect path Benjamin Tissoires
2017-12-15 0:19 ` Samuel Thibault
2017-12-16 0:48 ` Dmitry Torokhov [this message]
2017-12-20 15:11 ` Benjamin Tissoires
2017-12-20 18:20 ` Dmitry Torokhov
2017-12-20 18:42 ` Benjamin Tissoires
2017-12-15 0:16 ` [PATCH 0/2] input - leds: fix bugs found by fuzzing Samuel Thibault
2017-12-15 8:04 ` Benjamin Tissoires
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171216004846.3blocf4u45adwalh@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.hutterer@who-t.net \
--cc=samuel.thibault@ens-lyon.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).