linux-kernel - Re: Wait for mutex to become 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 5 May 2022 05:12:42 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Waiman Long <longman@...hat.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Wait for mutex to become unlocked

On Thu, May 05, 2022 at 09:52:23AM +0800, Hillf Danton wrote:
> +++ x/kernel/locking/rwsem.c
> @@ -1464,6 +1464,35 @@ void __sched down_read(struct rw_semapho
>  }
>  EXPORT_SYMBOL(down_read);
>  
> +static void __rwsem_wait(struct rw_semaphore *sem, int read, int state)
> +{
> +	DEFINE_WAIT(wait);
> +	int locked;
> +
> +	prepare_to_wait(&sem->willy_wq, &wait, state);
> +	if (read)
> +		locked = down_read_trylock(sem);

... but then we just acquired the lock.  And the point was to never
acquire the lock.

Also, what's the 'willy_wq' thing?  Do you mean wait_list?
Oh, no, I see, you're pretending that we should add an extra waitq
to the rwsem.  That's very silly.

The point was not to ask "how can we do this", the question was "should we
do this?"  And Thomas, at least for now, is saying "No".

If you want to figure out how to do it properly, see rwsem_add_waiter()
and how it's used.