Re: [PATCH] locking: Document that mutex_unlock() is non-atomic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 1, 2023 at 4:52 PM Waiman Long <longman@xxxxxxxxxx> wrote:
> On 12/1/23 10:01, Jann Horn wrote:
>> I think this pattern anyway only works when you're only trying to wait
>> for the current holder of the lock, not tasks that are queued up on
>> the lock as waiters - so a task initially holds a stable reference to
>> some object, then acquires the object's lock, then drops the original
>> reference, and then later drops the lock.
>> You can see an example of such mutex usage (which is explicitly legal
>> with userspace POSIX mutexes, but is forbidden with kernel mutexes) at
>> the bottom of the POSIX manpage for pthread_mutex_destroy() at
>> <https://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html>,
>> in the section "Destroying Mutexes".
>
> The POSIX mutex is reference-counted.

I don't understand what you mean by that.

Anyway, I guess this thread of discussion is moot - I'm not suggesting
that kernel mutexes should support this behavior.





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux