linux-kernel - Re: [PATCH 1/4] module: implement module_inhibit

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: <46F996AD.2070107@gmail.com>
Date:	Wed, 26 Sep 2007 08:15:57 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Jonathan Corbet <corbet@....net>, ebiederm@...ssion.com,
	cornelia.huck@...ibm.com, greg@...ah.com, kay.sievers@...y.org,
	linux-kernel@...r.kernel.org, rusty@...tcorp.com.au
Subject: Re: [PATCH 1/4] module: implement module_inhibit_unload()

Alan Stern wrote:
> On Tue, 25 Sep 2007, Tejun Heo wrote:
> 
>> Alan Stern wrote:
>>>> The unloading can proceed once module_unload_inhibit_cnt reaches zero.
>>>> An unloading thread only has to care about inhibition put in effect
>>>> before unloading has started, so there's no need to check again.
>>> You haven't fully answered Jon's question.  Suppose
>>> module_unload_inhibit_cnt is nonzero, so the task adds itself to the
>>> module_unload_wait queue, changes to TASK_UNINTERRUPTIBLE, and calls
>>> schedule.  There's nothing to prevent somebody else from waking the
>>> task back up before the original inhibition has been lifted.
>> Hmmm... I might be missing something here.  Who else can wake up a
>> thread in uninterruptible sleep?
> 
> In principle, anything can.  There has never been any guarantee in the 
> kernel that a task sleeping on a waitqueue will remain asleep until 
> the waitqueue is signalled.  That's part of the reason why things like 
> __wait_event() are coded as loops.

Hmmm... I always thought the queue was because the condition can change
inbetween waking up and actually running.  For example, if the condition
is !(queue empty), another task can enter the critical section and
consume the element which triggered wake up before the woken up task do.

I have no problem with changing the condition check to loop but it would
be great if someone can point me to a code where this unexpected wake up
is used.

Thanks.

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