linux-kernel - Re: [PATCH] locking/mutex: fix the MUTEX_FLAG

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] [day] [month] [year] [list]

Message-ID: <945cc291-7057-389c-faf8-a30bde605654@windriver.com>
Date:   Wed, 30 Jun 2021 18:06:05 +0800
From:   "Xu, Yanfei" <yanfei.xu@...driver.com>
To:     Waiman Long <llong@...hat.com>, peterz@...radead.org,
        mingo@...hat.com, boqun.feng@...il.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] locking/mutex: fix the MUTEX_FLAG_HANDOFF bit is cleared
 unexpected



On 6/30/21 2:20 PM, Xu, Yanfei wrote:
>> Oh, you are right. The current code doesn't actually prevent lock
>> stealer from actually stealing the lock in the special case that the
>> lock is in the unlock state when the HANDOFF bit is set. In this case,
> 
> How about setting the HANDOFF bit before the top-waiter first give up
> cpu and fall asleep. Then It must can get the lock after being woken up,
> and there is no chance happen stealing lock.  And I sent a v2 with this.

Please ignore this, It is incorrect. Lock stealing is a performance
optimization.

Yanfei

> 
>> it is free for all and whoever gets the lock will also clear the the
>> HANDOFF bit. The comment in __mutex_trylock_or_owner() about "We set the
>> HANDOFF bit" isn't quite right.