On 03/19/2015 02:39 PM, Wolfram Sang wrote:
Turns out this is really easy to reproduce. One process reads
the eeprom over and over again, another runs i2cdump in a loop,
and voila ... lots of corruptions. Scary, especially considering
how wide-spread this kind of i2c access is in the kernel.
A coccinelle script should at least be able to find vulnerable code
paths, maybe even fix it. But not today for me... Thanks for testing and
sharing the results!
Wolfram,
just to give you an update: I do have some code, but it is a bit messy,
and it doesn't work well for ds2482 (the chip behind it still hangs up
if I access it in parallel through i2c-dev). On top of that, it causes
pretty significant slow-downs when accessing other devices on the same
bus at the same time. Not surprising, I guess, since it expands the scope
of the bus lock significantly.
I thought about introducing a client lock, but that does not work because
of the way i2c-dev is written (creating its own 'shadow' client structure).
An address lock (ie a client lock based on <bus, address> instead of one
residing in the client structure) seems to be too expensive.
So right now I don't really know how to proceed, or if to proceed at all.
I'll think about it some more, but given how wide-spread the problem is
in the kernel, I might just leave it alone, and keep the at24 changes
out of tree.
Ultimately, the real problem is how i2c-dev accesses a client, not how
i2c client drivers (who assume they have exclusive access to a chip)
handle multi-command sequences. Forcing extensive locking on all drivers
because of i2c-dev just doesn't seem to be the right thing to do.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
