Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'Peter Zijlstra' <peterz@infradead.org>,
        Hernan Ponce de Leon <hernan.poncedeleon@huaweicloud.com>
CC:     "mingo@redhat.com" <mingo@redhat.com>,
        "will@kernel.org" <will@kernel.org>,
        "longman@redhat.com" <longman@redhat.com>,
        "boqun.feng@gmail.com" <boqun.feng@gmail.com>,
        "akpm@osdl.org" <akpm@osdl.org>,
        "arjan@linux.intel.com" <arjan@linux.intel.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "joel@joelfernandes.org" <joel@joelfernandes.org>,
        "paulmck@kernel.org" <paulmck@kernel.org>,
        "stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
        "diogo.behrens@huawei.com" <diogo.behrens@huawei.com>,
        "jonas.oberhauser@huawei.com" <jonas.oberhauser@huawei.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Hernan Ponce de Leon" <hernanl.leon@huawei.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] Fix data race in mark_rt_mutex_waiters
Thread-Topic: [PATCH] Fix data race in mark_rt_mutex_waiters
Thread-Index: AQHZLOuXmFFanV4GpkyO0ZW7VUnI7K6nhS4Q
Date:   Fri, 20 Jan 2023 16:58:20 +0000
Message-ID: <dc361d8a262b4872acf750f7c8935a28@AcuMS.aculab.com>
References: <20230120135525.25561-1-hernan.poncedeleon@huaweicloud.com>
 <Y8q/5hgXrvOp6vku@hirez.programming.kicks-ass.net>
In-Reply-To: <Y8q/5hgXrvOp6vku@hirez.programming.kicks-ass.net>
Accept-Language: en-GB, en-US
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

From: Peter Zijlstra
> Sent: 20 January 2023 16:23
...
> >  	do {
> > -		owner = *p;
> > +		owner = READ_ONCE(*p);
> >  	} while (cmpxchg_relaxed(p, owner,
> >  				 owner | RT_MUTEX_HAS_WAITERS) != owner);
> >
> 
> Can't we replace the whole of that function with:
> 
> 	set_bit(0, (unsigned long *)&lock->owner);
> 
> ?

If you need the cast then probably not...

There really ought to be a compile-time test (somehow)
that set_bit() is only used on large bit arrays.

OTOH atomic_or32/64() and atomic_and32/64() might use
usable in many places.

On x86 I doubt it makes much difference whether you use
'bis' or 'lock or'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)