Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH -next] locking/percpu-rwsem: fix a task_struct refcount
Date:   Fri, 27 Mar 2020 06:19:37 -0400
Message-Id: <BB30C711-B54C-4D61-8BEE-A55F410C4178@lca.pw>
References: <20200327093754.GS20713@hirez.programming.kicks-ass.net>
Cc:     mingo@redhat.com, will@kernel.org, dbueso@suse.de,
        juri.lelli@redhat.com, longman@redhat.com,
        linux-kernel@vger.kernel.org
In-Reply-To: <20200327093754.GS20713@hirez.programming.kicks-ass.net>
To:     Peter Zijlstra <peterz@infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Mar 27, 2020, at 5:37 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> 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 wr=
ong 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. H=
owever, 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?=