linux-kernel - Re: [PATCH v2 4/4] input: evdev: Make device readable only when it contains a complete packet.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BANLkTinw6poJOkFWaJp6paL6rDpwBG-9zA@mail.gmail.com>
Date:	Mon, 11 Apr 2011 13:15:03 -0700
From:	Jeffrey Brown <jeffbrown@...roid.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	rydberg@...omail.se, djkurtz@...gle.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/4] input: evdev: Make device readable only when it
 contains a complete packet.

Hi Dmitry,

On Tue, Apr 5, 2011 at 9:38 AM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>> Heh, I faced this very same dilemma.  I tried 'last_sync',
>> 'readable_tail', 'read_end', and others before settling on 'end' and a
>> descriptive comment.
>
> 'packet_head' maybe? Similar to the head but for whole event packet?

That sounds good.  It marks the position one past the end of the most
recent packet, or equivalently the beginning of the next packet (if
there is one).  :-)

> Before we started changing tail to advance to SYN_DROPPED position we
> could probably drop the buffer lock and sprinkle memory barriers (to
> ensure, for example, that buffer is written before advancing head).
>
> Now we do need to protect buffer and head/tail but the new field can be
> updated outside the lock.

That sounds kind of complicated.  Memory barriers and volatile
reads/writers aren't free.  Acquiring / releasing the lock already
performs the necessary memory barriers and keeps the code simple since
we can rely on mutual exclusion guarantees to preserve our invariants.
 I doubt the buffer lock is highly contended so although we could
probably do without it, I'm not sure it's worth the necessary
contortions.  *shrug*

Any further progress on this patch?

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/