linux-kernel - RE: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

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: <99B09243E1A5DA4898CDD8B70011144810830AB119@EXMB04.eu.tieto.com>
Date:	Thu, 17 Mar 2011 14:58:38 +0200
From:	<Waldemar.Rymarkiewicz@...to.com>
To:	<arnd@...db.de>
CC:	<linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

Hi Arnd,

>> >Note that the microread_is_busy() logic does not protect you from 
>> >having multiple concurrent readers, because multiple threads may 
>> >share a single file descriptor.
>> 
>> It's just used to ensure that only one reader can open the device.
>> It's called only in open callback.
>> The mutex actually secures concurrent read operations. 
>
>So if having multiple readers is safe (though possibly not 
>meaningful), I guess you don't really need the 
>microread_is_busy() logic.
>
>I suppose it doesn't hurt either, it just seems a bit 
>pointless when it does the right thing most of the time, but 
>not always.
>

Could you give me an example when the microread_is_busy() logic does not do what it's intended to do.
I don't really get your point here. 


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