From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Benjamin Tissoires <benjamin.tissoires@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] HID: debugfs rework
Date: Thu, 18 Apr 2013 09:52:40 +0200 [thread overview]
Message-ID: <516FA648.20207@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1304171041070.31201@pobox.suse.cz>
On 04/17/2013 07:44 PM, Jiri Kosina wrote:
> On Wed, 17 Apr 2013, Benjamin Tissoires wrote:
>
>> Hi Jiri,
>>
>> This is a small rework of the HID debugfs.
>> I encountered a problem with multitouch devices: they have too much usages to
>> fit into the fixed size output buffer of 512.
>> So I digg a little, and end up with those 4 patches.
>
> Hi Benjamin,
>
> thanks, I will look into it and see whether I would be able to apply it
> still for 3.10 merge window.
Thanks. I think patches 1 and 2 of this series are pretty straightforward.
Patches 3 and 4 will maybe require a little bit more attention.
I don't mind if it's postponed to 3.11 (given the long time this has
been broken for devices with big reports).
I just need to access HID debugfs for hid-replay when hidraw does not
send anything. But as I'm also willing to use hid-replay with current
kernels, I still need a way to use the best option (hidraw or hid
debugfs) for current kernels.
>
> I also have a locking fix for HID-debugfs which I am going to apply
> shortly, but I am travelling this week, so I am in a bit degraded mode.
>
> For reference, locking fix below.
>
>
>
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: [PATCH] HID: protect hid_debug_list
>
> Accesses to hid_device->hid_debug_list are not serialized properly, which
> could result in SMP concurrency issues when HID debugfs events are accessesed
s/accessesed/accessed ?
> by multiple userspace processess.
s/processess/processes ?
>
> Serialize all the list operations by a mutex.
>
> Reported-by: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
I also have a patch regarding forcing hidraw output even if raw_event
returns > 0, but I'll send it over a new thread. This thread will start
to be quite complicate to follow otherwise... :)
Cheers,
Benjamin
prev parent reply other threads:[~2013-04-18 7:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 17:38 [PATCH 0/4] HID: debugfs rework Benjamin Tissoires
2013-04-17 17:38 ` [PATCH 1/4] HID: debug: break out hid_dump_report() into hid-debug Benjamin Tissoires
2013-04-19 2:01 ` Jiri Kosina
2013-04-17 17:38 ` [PATCH 2/4] HID: core: break out hid_find_max_report() in hid-core Benjamin Tissoires
2013-04-17 17:38 ` [PATCH 3/4] HID: debug: empty output queue on read Benjamin Tissoires
2013-04-19 1:55 ` Jiri Kosina
2013-04-17 17:38 ` [PATCH 4/4] HID: debug: allocate the output buffer with an estimate Benjamin Tissoires
2013-04-17 17:44 ` [PATCH 0/4] HID: debugfs rework Jiri Kosina
2013-04-18 7:52 ` Benjamin Tissoires [this message]
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=516FA648.20207@redhat.com \
--to=benjamin.tissoires@redhat.com \
--cc=benjamin.tissoires@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.