linux-kernel - Re: iio: dht11 Updates

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]

Date:	Sun, 04 Jan 2015 11:01:53 +0000
From:	Jonathan Cameron <jic23@...nel.org>
To:	Richard Weinberger <richard@....at>, harald@...ib.org
CC:	knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
	sanjeev_sharma@...tor.com, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: iio: dht11 Updates

On 02/01/15 11:28, Richard Weinberger wrote:
> Am 01.01.2015 um 22:18 schrieb harald@...ib.org:
>> Hi!
>>
>> On Thu, 01 Jan 2015 12:38:23 +0000, Jonathan Cameron <jic23@...nel.org>
>> wrote:
>>> On 02/12/14 23:32, Richard Weinberger wrote:
>>>> Please see my current patches for your driver.
>>>> As discussed in an earlier mail I'm testing with the DHT22 sensor only.
>>>> With the IRQ changes I see 84 edges.
>>>>
>>>>
>>>> [PATCH 1/4] iio: dht11: Add locking
>>>> [PATCH 2/4] iio: dht11: IRQ fixes
>>>> [PATCH 3/4] iio: dht11: Logging updates
>>>> [PATCH 4/4] iio: dht11: Fix out-of-bounds read
>>>>
>>  
>>> I've lost track of where we are with this patch series.
>>> Does this cause trouble on any of the parts supported?
>>
>> Yes, 2/4 needs an update. 
> 
> Correct.
> 
>> 1/4 is fine by me, however it was noted that there is already
>> locking in the iio core for the in-kernel interface but not
>> for the sysfs interface. I think we need locking in the case of
>> the sysfs interace as well, but the final decision is yours...
> 
> We definitely need it.
> I have more than one sensor attached and collectd queries them.
> Without locking collectd manages to hit this race window.
> So the issue is real.
Locking is needed.  Convention has normally been to do this in the
driver rather than a subsystem core.
That gives more fine grained control and avoids locking
when not necessary (some devices will need a lock on data read,
others will not).
Clearly in this case, the need should have been picked up in review
(oops).  Sorry about that.
> 
>> 4/4 is obviously right.
>>
>> 3/4 is cleanup. I'd rather defer this to later and do it right,
>> because right now this patch is cosmetic and doesn't get rid of
>> the deeper issues. I'll start to work on a cleanup series once
>> the fixes are merged.
> 
> Agreed.
> 
>> Richard, what's your timeframe to send an updated series?
>> I can send an update if you don't have time.
> 
> It would be great if you can send an updated version of 2/4.
> I don't have a DHT11 sensor (only DHT22) and I'm still recovering
> from a cold.
> 
> Thanks
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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/