All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: akpm@linux-foundation.org, zi.li@linux.dev,
	anna.schumaker@oracle.com, boqun.feng@gmail.com,
	joel.granados@kernel.org, jstultz@google.com,
	kent.overstreet@linux.dev, leonylgao@tencent.com,
	linux-kernel@vger.kernel.org, longman@redhat.com,
	mingo@redhat.com, mingzhe.yang@ly.com, peterz@infradead.org,
	rostedt@goodmis.org, senozhatsky@chromium.org,
	tfiga@chromium.org, will@kernel.org,
	Lance Yang <ioworker0@gmail.com>
Subject: Re: [PATCH RFC 2/3] locking/rwsem: clear reader-owner on unlock to reduce false positives
Date: Tue, 24 Jun 2025 09:44:55 +0800	[thread overview]
Message-ID: <21ef5892-afdf-491e-937f-7821cac63d16@linux.dev> (raw)
In-Reply-To: <20250624092620.3346ac39e882434aafb0b93d@kernel.org>



On 2025/6/24 08:26, Masami Hiramatsu (Google) wrote:
> On Thu, 12 Jun 2025 12:19:25 +0800
> Lance Yang <ioworker0@gmail.com> wrote:
> 
>> From: Lance Yang <lance.yang@linux.dev>
>>
>> When CONFIG_DETECT_HUNG_TASK_BLOCKER is enabled, a stale owner pointer in a
>> reader-owned rwsem can lead to false positives in blocker tracking.
>>
>> To mitigate this, let’s try to clear the owner field on unlock, as a NULL
>> owner is better than a stale one for diagnostics.
> 
> Can we merge this to [PATCH 1/3]? It seems that you removed #ifdef and
> remove it. This means in anyway we need the feature enabled by DEBUG_RWSEMS.

Thanks for the feedback! I see your point about the dependency ;)

Personlly, I'd perfer to keep them separate. The reasoning is that
they addreess two distinct things, and I think splitting them makes
this series clearer and easier to review ;)

Patch #1 focuses on "ownership tracking": Its only job is to make
the existing owner-related helpers (rwsem_owner(), is_rwsem_reader_owned())
globally available when blocker tracking is enabled.

Patch #2, on the other hand, is about "reader-owner cleanup": It
introduces a functional change to the unlock path, trying to clear
the owner field for reader-owned rwsems.

Does this reasoning make sense to you?

Thanks,
Lance

> 
> Thanks,
> 
>>
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>> ---
>>   kernel/locking/rwsem.c | 10 ++++------
>>   1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
>> index 6cb29442d4fc..a310eb9896de 100644
>> --- a/kernel/locking/rwsem.c
>> +++ b/kernel/locking/rwsem.c
>> @@ -205,14 +205,12 @@ bool is_rwsem_reader_owned(struct rw_semaphore *sem)
>>   		return false;
>>   	return rwsem_test_oflags(sem, RWSEM_READER_OWNED);
>>   }
>> -#endif
>>   
>> -#ifdef CONFIG_DEBUG_RWSEMS
>>   /*
>> - * With CONFIG_DEBUG_RWSEMS configured, it will make sure that if there
>> - * is a task pointer in owner of a reader-owned rwsem, it will be the
>> - * real owner or one of the real owners. The only exception is when the
>> - * unlock is done by up_read_non_owner().
>> + * With CONFIG_DEBUG_RWSEMS or CONFIG_DETECT_HUNG_TASK_BLOCKER configured,
>> + * it will make sure that the owner field of a reader-owned rwsem either
>> + * points to a real reader-owner(s) or gets cleared. The only exception is
>> + * when the unlock is done by up_read_non_owner().
>>    */
>>   static inline void rwsem_clear_reader_owned(struct rw_semaphore *sem)
>>   {
>> -- 
>> 2.49.0
>>
> 
> 


  reply	other threads:[~2025-06-24  1:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12  4:19 [PATCH RFC 0/3] extend hung task blocker tracking to rwsems Lance Yang
2025-06-12  4:19 ` [PATCH RFC 1/3] locking/rwsem: make owner helpers globally available Lance Yang
2025-06-24  0:17   ` Masami Hiramatsu
2025-06-24  1:35     ` Lance Yang
2025-06-12  4:19 ` [PATCH RFC 2/3] locking/rwsem: clear reader-owner on unlock to reduce false positives Lance Yang
2025-06-24  0:26   ` Masami Hiramatsu
2025-06-24  1:44     ` Lance Yang [this message]
2025-06-24  3:53       ` Masami Hiramatsu
2025-06-24  5:02         ` Lance Yang
2025-06-24  6:13           ` Masami Hiramatsu
2025-06-24  7:38             ` Lance Yang
2025-06-12  4:19 ` [PATCH RFC 3/3] hung_task: extend hung task blocker tracking to rwsems Lance Yang
2025-06-24  3:57   ` Masami Hiramatsu
2025-06-24  4:25     ` Lance Yang
2025-06-23 12:33 ` [PATCH RFC 0/3] " Lance Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21ef5892-afdf-491e-937f-7821cac63d16@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=anna.schumaker@oracle.com \
    --cc=boqun.feng@gmail.com \
    --cc=ioworker0@gmail.com \
    --cc=joel.granados@kernel.org \
    --cc=jstultz@google.com \
    --cc=kent.overstreet@linux.dev \
    --cc=leonylgao@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mingzhe.yang@ly.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=will@kernel.org \
    --cc=zi.li@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.