linux-kernel - Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

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: <20150318132707.GD3580@katana>
Date:	Wed, 18 Mar 2015 14:27:07 +0100
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to
 SMBus adapters

On Mon, Mar 16, 2015 at 09:20:49PM -0700, Guenter Roeck wrote:
> On Mon, Feb 16, 2015 at 01:09:51PM +0100, Wolfram Sang wrote:
> > Hi Guenter,
> > 
> > > I wonder where we are with thisp patch; I don't recall a reply to my previous
> > > e-mail.
> > 
> > Sorry for the late reply. I needed to recover from a HDD headcrash :(
> > 
> > > Do you need some more time to think about it ? Otherwise I'll publish an
> > > out-of-tree version of the at24 driver with the patch applied on github,
> > > for those who might need the functionality provided by this patch.
> > 
> > Your last mail made me aware of why we were missing each other before. I
> > see your point now, but yes, still need to think about it. My plan is to
> > have a decision until the 3.21 merge window.
> > 
> Hi Wolfram,
> 
> any news ?

Yes :)

The main misunderstanding we had before was: You were talking about
multi-master safety between transfers, while I was thinking about
multi-master safety between messages. While we need to guarantee this
for the latter, you are right about the former, sadly. True multi-master
safety between transfers is probably like a can of worms currently.

Still, I think we have a race with your patch when having two read
processes. If b) kicks in after a) has just set the eeprom pointer, a)
will not read the data it wants. For that to prevent, we should take the
adapter_lock during those two transfers needed for the read you
implemented. My preferred solution would be to have __smbus_transfer
like we have __i2c_transfer and then using that. Some mux code could
also make use out of that. But if you are going to use
adapter->algo->smbus_xfer() directly, well, then be it.

Thanks,

   Wolfram

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)