Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Niels Dossche <dossche.niels@gmail.com>, 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 14:27:46 -0800	[thread overview]
Message-ID: <dd679ebd-dba9-219b-20c4-21f0270138da@acm.org> (raw)
In-Reply-To: <20220309203449.63125-1-dossche.niels@gmail.com>

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?).

Thanks,

Bart.


  reply	other threads:[~2022-03-09 22:27 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 [this message]
2022-03-09 22:30   ` Niels Dossche
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=dd679ebd-dba9-219b-20c4-21f0270138da@acm.org \
    --to=bvanassche@acm.org \
    --cc=dossche.niels@gmail.com \
    --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