linux-kernel - Re: [PATCH v2 6/6] hid: add experimental access to PicoLCD device's EEPROM and FLASH

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100321112922.53bb8c6e@neptune.home>
Date:	Sun, 21 Mar 2010 11:29:22 +0100
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Rick L. Vinyard Jr." <rvinyard@...nmsu.edu>,
	Nicu Pavel <npavel@...ner.com>,
	Oliver Neukum <oliver@...kum.org>,
	Jaya Kumar <jayakumar.lkml@...il.com>
Subject: Re: [PATCH v2 6/6] hid: add experimental access to PicoLCD device's
 EEPROM and FLASH

On Sat, 20 March 2010 Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> On Sat, Mar 20, 2010 at 05:11:19PM +0100, Bruno Prémont wrote:
> > The PicoLCD device has a small amount of EEPROM and also provides
> > access to its FLASH where firmware and splash image are saved.
> > In flasher mode FLASH access is the only active feature.
> > 
> > Give read/write access to both via debugfs files.
> > 
> 
> It looks you are allowing multiple users access to these files. What
> will happen if 2 processes try to write EEPROM at the same time?

Writes will be serialized by the wait for response from device with
picolcd_send_and_wait() and it's up to userspace to repeat the
reads/writes in order to get all the data they need if they requested
more that the 20 bytes that can be transferred in a single HID report.

For flash access a concurrent write to same area can cause one of the
writers to conflict with the other one as a write there is a sequence
of operations which can interleave (e.g. A erases, A writes 1/2,
B erases, B writes 1/2, A writes 2nd 1/2, B writes 2nd 1/2 which would
fail).
A single-user open would be a nice work-around for this.
I would prefer to make erase operation explicitly visible to user so
I don't have to do the erase behind the scenes.
I've not yet looked in the area of mtd/nand support if I can use their
interface.

This is the big reason I did put both to debugfs, they (especially
flash access) need to be made visible in a better way.

> > +
> > +static inline int picolcd_init_devfs(struct picolcd_data *data,
> > +		struct hid_report *eeprom_r, struct hid_report *eeprom_w,
> > +		struct hid_report *flash_r, struct hid_report *flash_w,
> > +		struct hid_report *reset)
> > +{
> 
> I don't think this should be forced inline.

Ok, will drop most of the 'inline' keywords as you suggested already
on one of the other patches.

Thanks for the review,
Bruno
--
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/