All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Christoph Hellwig <hch@lst.de>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, John Garry <john.garry@linux.dev>
Subject: Re: [PATCH v5 7/8] scsi: scsi_debug: Improve lock context annotations
Date: Mon, 12 Oct 2026 08:31:01 -0700	[thread overview]
Message-ID: <89e3bb6c-4e8a-4480-a6d4-e7f6a2ddbef1@acm.org> (raw)
In-Reply-To: <20261012122457.GB31394@lst.de>

On 10/12/26 5:24 AM, Christoph Hellwig wrote:
> On Thu, Oct 08, 2026 at 03:42:18PM -0700, Bart Van Assche wrote:
>>   static inline void
>>   sdeb_meta_read_lock(struct sdeb_store_info *sip)
>> +	__acquires_shared(&sip->macc_meta_lck)
>> +	__context_unsafe(/*conditional locking*/)
>>   {
>> -	if (sdebug_no_rwlock) {
>> -		if (sip)
>> -			__acquire(&sip->macc_meta_lck);
>> -		else
>> -			__acquire(&sdeb_fake_rw_lck);
>> -	} else {
>> +	if (!sdebug_no_rwlock) {
> 
> Why can't this be modelled using a __acquire variant?  And if you
> add __context_unsafe(/*conditional locking*/) please add a detailed
> comment why that is needed, otherwise no one is going to understand
> this in the future.

Hi Christoph,

I will change the comment into "can't be annotated with
__{acquire,release}(,_shared}() without triggering undefined behavior".

What Sashiko reported on a Google-internal server for an
earlier attempt to annotate this and similar functions with
__{acquire,release}(,_shared}() has been included below. I think that
Sashiko is right:
=======================================================================
 >  static inline void
 >  sdeb_meta_read_lock(struct sdeb_store_info *sip)
 > +	__acquires_shared(&sip->macc_meta_lck)
 >  {
 >  	if (sdebug_no_rwlock) {
 > -		if (sip)
 > -			__acquire(&sip->macc_meta_lck);
 > -		else
 > -			__acquire(&sdeb_fake_rw_lck);
 > +		__acquire_shared(&sip->macc_meta_lck);
 >  	} else {
 > -		if (sip)
 > +		if (sip) {
 >  			read_lock(&sip->macc_meta_lck);
 > -		else
 > +		} else {
 >  			read_lock(&sdeb_fake_rw_lck);
 > +			__release_shared(&sdeb_fake_rw_lck);
 > +			__acquire_shared(&sip->macc_meta_lck);
                                          ^^^^^^^^^^^^^^^^^^^
Can this regression trigger an undefined behavior splat when sip is NULL?
When the scsi_debug driver is used with the module parameter fake_rw=1,
devip2sip() returns NULL. In this else branch, sip is explicitly NULL,
so evaluating &sip->macc_meta_lck means taking the address of a member
from a NULL pointer.
When compiled with Context Analysis and UBSAN (-fsanitize=null or
-fsanitize=pointer-overflow), the inline function call evaluates the
argument before the call and will trigger a runtime splat. Without UBSAN,
it calculates an invalid offset from a NULL pointer.
=======================================================================

Bart.



  reply	other threads:[~2026-10-12 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 22:42 [PATCH v5 0/8] scsi_debug: Enable lock context analysis Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 1/8] scsi: scsi_debug: Fix a locking bug in resp_write_same() Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 2/8] scsi: scsi_debug: Split resp_write_same() Bart Van Assche
2026-10-08 22:52   ` sashiko-bot
2026-10-08 23:27     ` Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 3/8] scsi: scsi_debug: Split corrupt_lbas() Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 4/8] scsi: scsi_debug: Split resp_read_dt0() Bart Van Assche
2026-10-12 12:23   ` Christoph Hellwig
2026-10-12 17:18   ` John Garry
2026-10-13 20:46     ` Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 5/8] scsi: scsi_debug: Split resp_write_dt0() Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 6/8] scsi: scsi_debug: Split resp_atomic_write() Bart Van Assche
2026-10-08 22:42 ` [PATCH v5 7/8] scsi: scsi_debug: Improve lock context annotations Bart Van Assche
2026-10-12 12:24   ` Christoph Hellwig
2026-10-12 15:31     ` Bart Van Assche [this message]
2026-10-08 22:42 ` [PATCH v5 8/8] scsi: core: Enable lock context analysis for the scsi_debug driver Bart Van Assche

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=89e3bb6c-4e8a-4480-a6d4-e7f6a2ddbef1@acm.org \
    --to=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=john.garry@linux.dev \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /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.