All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	linux-kernel@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH-tip 0/5] locking/locktorture: Fix locktorture ww_mutex test problems
Date: Fri, 19 Mar 2021 11:29:40 -0400	[thread overview]
Message-ID: <2e195484-e011-faab-f6b0-1cfeecc5f3bf@redhat.com> (raw)
In-Reply-To: <20210319111629.GB4029764@gmail.com>

On 3/19/21 7:16 AM, Ingo Molnar wrote:
> * Waiman Long <longman@redhat.com> wrote:
>
>> This is a follow-up patch series for the previous patchset on fixing
>> locktorture ww_mutex test problem [1]. The first 3 patches of that
>> series were merged into tip. It turns out that the last one of the
>> three wasn't quite right. So this patch series revert the last patch.
>>
>> The rests of the patch series fix the ww_mutex testing problem in
>> locktorture as well as removing the DEFINE_WW_MUTEX() macro from
>> include/linux/ww_mutex.h.
>>
>> [1] https://lore.kernel.org/lkml/20210316153119.13802-1-longman@redhat.com/
>>
>> Waiman Long (5):
>>    locking/ww_mutex: Revert "Treat ww_mutex_lock() like a trylock"
>>    locking/locktorture: Fix false positive circular locking splat in
>>      ww_mutex test
>>    locking/ww_mutex: Remove DEFINE_WW_MUTEX() macro
>>    locking/locktorture: Pass thread id to lock/unlock functions
>>    locking/locktorture: locking/locktorture: Fix incorrect use of
>>      ww_acquire_ctx in ww_mutex test
> Applied, thanks Waiman.
>
> I kept these two fixes in locking/urgent, for a v5.12 merge:
>
>    bee645788e07: ("locking/ww_mutex: Fix acquire/release imbalance in ww_acquire_init()/ww_acquire_fini()")
>    5de2055d31ea: ("locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling")
>
> As this bug could affect actual ww_mutex users.
>
> And queued up these four in locking/core, for a v5.13 merge:
>
>    8c52cca04f97: ("locking/locktorture: Fix incorrect use of ww_acquire_ctx in ww_mutex test")
>    aa3a5f31877e: ("locking/locktorture: Pass thread id to lock/unlock functions")
>    5261ced47f8e: ("locking/ww_mutex: Remove DEFINE_WW_MUTEX() macro")
>    2ea55bbba23e: ("locking/locktorture: Fix false positive circular locking splat in ww_mutex test")
>
> As these bugs are basically limited to a debugging facility.
>
> ( But we could also merge them into v5.12, if you think it's
>    justified. No strong opinions either way. )

I think v5.13 merge is fine. This problem exists for quite a while and 
no one notices it. So it is not really that urgent.

Thank a lot for the quick action.

Cheers,
Longman


      reply	other threads:[~2021-03-19 15:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 17:28 [PATCH-tip 0/5] locking/locktorture: Fix locktorture ww_mutex test problems Waiman Long
2021-03-18 17:28 ` [PATCH-tip 1/5] locking/ww_mutex: Revert "Treat ww_mutex_lock() like a trylock" Waiman Long
2021-03-18 17:28 ` [PATCH-tip 2/5] locking/locktorture: Fix false positive circular locking splat in ww_mutex test Waiman Long
2021-03-19 12:54   ` [tip: locking/core] " tip-bot2 for Waiman Long
2021-03-18 17:28 ` [PATCH-tip 3/5] locking/ww_mutex: Remove DEFINE_WW_MUTEX() macro Waiman Long
2021-03-19 12:54   ` [tip: locking/core] " tip-bot2 for Waiman Long
2021-03-18 17:28 ` [PATCH-tip 4/5] locking/locktorture: Pass thread id to lock/unlock functions Waiman Long
2021-03-19 12:54   ` [tip: locking/core] " tip-bot2 for Waiman Long
2021-03-18 17:28 ` [PATCH-tip 5/5] locking/locktorture: locking/locktorture: Fix incorrect use of ww_acquire_ctx in ww_mutex test Waiman Long
2021-03-19 12:54   ` [tip: locking/core] " tip-bot2 for Waiman Long
2021-03-19 11:10 ` [PATCH-tip 0/5] locking/locktorture: Fix locktorture ww_mutex test problems Ingo Molnar
2021-03-19 11:16 ` Ingo Molnar
2021-03-19 15:29   ` Waiman Long [this message]

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=2e195484-e011-faab-f6b0-1cfeecc5f3bf@redhat.com \
    --to=longman@redhat.com \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    /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.