linux-kernel - Re: [PATCH] driver: ip27-rtc - convert ioctl to unlocked

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jan 2008 19:07:45 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Paul Gortmaker <p_gortmaker@...oo.com>,
	LKML <linux-kernel@...r.kernel.org>, Andi Kleen <ak@...e.de>,
	Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH] driver: ip27-rtc - convert ioctl to unlocked_ioctl

[Jiri Slaby - Mon, Jan 14, 2008 at 04:59:22PM +0100]
> On 01/14/2008 04:38 PM, Cyrill Gorcunov wrote:
>> Jiri, I mean rtc_open() is protected by spinlock+status from being
>> opened simultaneously by a few processes. *But* lets imagine the
>> following situation - this fd (file descriptor) is opened by one
>> multithreaded application so all threads have an access to this
>> fd. Then one thread reads rtc periodically thru unlocked_ioctl
>> and another thread set new time from time to time. So the question
>> I have - is it possible to get second thread stopped at attemption to
>> get rtc spinlock while another thread is setting the new time? Or
>> this situation never-ever could be? i'm not really familiar with
>> process management in Linux and as result could be wrong.
>
> Access to global variable 'rtc' (the rtc itself) is serialized through the 
> spinlock, I see no problem there. If you call read-read-write-read from 4 
> tasks in userspace, it might be _still_ (no change) reordered to e.g. 
> write-read-read-read by the scheduler.
>
> In fact, the reading process is stopped while the another one is writing 
> the time (due to spinlock).
>

Yes, process would be stopped, and not *just* stopped but could spend
all his cpu time-slice in attempt to get spinlock (espec if set time is
much longer than read), but if we use mutex here the process could just
sleep instead of trying to get spinlock granted. Am I wrong? Or this is
not worth to do it?

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