[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <BB30C711-B54C-4D61-8BEE-A55F410C4178@lca.pw>
Date: Fri, 27 Mar 2020 06:19:37 -0400
From: Qian Cai <cai@....pw>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, will@...nel.org, dbueso@...e.de,
juri.lelli@...hat.com, longman@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] locking/percpu-rwsem: fix a task_struct refcount
> On Mar 27, 2020, at 5:37 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> If the trylock fails, someone else got the lock and we remain on the
> waitqueue. It seems like a very bad idea to put the task while it
> remains on the waitqueue, no?
Interesting, I thought this was more straightforward to see, but I may be wrong as always. At the beginning of percpu_rwsem_wake_function() it calls get_task_struct(), but if the trylock failed, it will remain in the waitqueue. However, it will run percpu_rwsem_wake_function() again with get_task_struct() to increase the refcount. Can you enlighten me where it will call put_task_struct() in waitqueue or elsewhere to balance the refcount in this case?
Powered by blists - more mailing lists