Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Niels Dossche <dossche.niels@gmail.com>
To: Bart Van Assche <bvanassche@acm.org>, linux-nvme@lists.infradead.org
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Chaitanya Kulkarni <kch@nvidia.com>
Subject: Re: [PATCH] nvmet: add missing locks around nvmet_ns_revalidate
Date: Wed, 9 Mar 2022 23:30:14 +0100	[thread overview]
Message-ID: <09c807d0-1aaa-b5c0-65cb-05700059e5d0@gmail.com> (raw)
In-Reply-To: <dd679ebd-dba9-219b-20c4-21f0270138da@acm.org>

Hi,

On 09/03/2022 23:27, Bart Van Assche wrote:
> On 3/9/22 12:34, Niels Dossche wrote:
>> nvmet_ns_changed states via lockdep that the ns->subsys->lock must be
>> held. The only caller of nvmet_ns_changed which does not acquire that
>> lock is nvmet_ns_revalidate. The only 2 callers of nvmet_ns_revalidate
>> which do not acquire that lock are nvmet_execute_identify_cns_cs_ns and
>> nvmet_execute_identify_ns. Add a lock for around the call to
>> nvmet_ns_revalidate in those 2 functions.
>>
>> Both of those identify functions are called from a common function
>> nvmet_execute_identify, which itself is called indirectly via the
>> req->execute function pointer.
> 
> Please mention in the patch description whether this has been discovered by studying the source code or by software (static source code analyzer? runtime data race detector?).

This was discovered by first using a static analyzer and then verifying it by manual inspection of the source code.

> 
> Thanks,
> 
> Bart.

Thanks,
Niels


  reply	other threads:[~2022-03-09 22:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 20:34 [PATCH] nvmet: add missing locks around nvmet_ns_revalidate Niels Dossche
2022-03-09 22:27 ` Bart Van Assche
2022-03-09 22:30   ` Niels Dossche [this message]
2022-03-09 23:12     ` Bart Van Assche
2022-03-10  0:24       ` Niels Dossche
2022-03-10  5:10         ` Bart Van Assche
2022-03-10 12:56           ` Niels Dossche
2022-03-13 12:43 ` Sagi Grimberg
2022-03-13 12:49   ` Niels Dossche
2022-03-13 13:02     ` Sagi Grimberg

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=09c807d0-1aaa-b5c0-65cb-05700059e5d0@gmail.com \
    --to=dossche.niels@gmail.com \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=kch@nvidia.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox