[PATCH v3] nvmet: add missing lock around nvmet_ns_changed in nvmet_ns_revalidate
Sagi Grimberg
sagi at grimberg.me
Sun Mar 13 06:31:42 PDT 2022
On 3/13/22 15:14, Niels Dossche wrote:
> On 3/13/22 14:03, Sagi Grimberg wrote:
>>
>>
>> On 3/10/22 14:51, 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. nvmet_ns_revalidate has 3 callers, of which
>>> 2 do not acquire that lock: nvmet_execute_identify_cns_cs_ns and
>>> nvmet_execute_identify_ns. The other caller
>>> nvmet_ns_revalidate_size_store does acquire the lock. Add a parameter to
>>> nvmet_ns_revalidate to indicate whether the lock was already taken or
>>> not, and thus whether the function still needs to take a lock when
>>> calling nvmet_ns_changed.
>>>
>>> The alternative solution is to let nvmet_ns_revalidate return a bool
>>> which indicates whether nvmet_ns_changed needs to be called and let the
>>> callers handle the locking responsibility. This however places the
>>> responsibility with its callers and causes more duplicate code and
>>> potential to forget to check the return value.
>>>
>>> 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.
>>>
>>> This issue was found using a static type-based analyser and manually
>>> verified.
>>>
>>> Signed-off-by: Niels Dossche <dossche.niels at gmail.com>
>>> ---
>>>
>>> Changes in v3:
>>> - improve commit description
>>> - do the locking locally
>>>
>>> Changes in v2:
>>> - added sentence about how the issue was found.
>>> - added missing &
>>>
>>> drivers/nvme/target/admin-cmd.c | 2 +-
>>> drivers/nvme/target/configfs.c | 2 +-
>>> drivers/nvme/target/core.c | 9 +++++++--
>>> drivers/nvme/target/nvmet.h | 2 +-
>>> drivers/nvme/target/zns.c | 3 ++-
>>> 5 files changed, 12 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c
>>> index 6fb24746de06..efa462374783 100644
>>> --- a/drivers/nvme/target/admin-cmd.c
>>> +++ b/drivers/nvme/target/admin-cmd.c
>>> @@ -511,7 +511,7 @@ static void nvmet_execute_identify_ns(struct nvmet_req *req)
>>> goto done;
>>> }
>>>
>>> - nvmet_ns_revalidate(req->ns);
>>> + nvmet_ns_revalidate(req->ns, true);
>>>
>>> /*
>>> * nuse = ncap = nsze isn't always true, but we have no way to find
>>> diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
>>> index 091a0ca16361..a803cd66dc4b 100644
>>> --- a/drivers/nvme/target/configfs.c
>>> +++ b/drivers/nvme/target/configfs.c
>>> @@ -586,7 +586,7 @@ static ssize_t nvmet_ns_revalidate_size_store(struct config_item *item,
>>> mutex_unlock(&ns->subsys->lock);
>>> return -EINVAL;
>>> }
>>> - nvmet_ns_revalidate(ns);
>>> + nvmet_ns_revalidate(ns, false);
>>> mutex_unlock(&ns->subsys->lock);
>>> return count;
>>> }
>>> diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
>>> index 5119c687de68..0ceef97e4093 100644
>>> --- a/drivers/nvme/target/core.c
>>> +++ b/drivers/nvme/target/core.c
>>> @@ -531,7 +531,7 @@ static void nvmet_p2pmem_ns_add_p2p(struct nvmet_ctrl *ctrl,
>>> ns->nsid);
>>> }
>>>
>>> -void nvmet_ns_revalidate(struct nvmet_ns *ns)
>>> +void nvmet_ns_revalidate(struct nvmet_ns *ns, bool should_acquire_lock)
>>> {
>>> loff_t oldsize = ns->size;
>>>
>>> @@ -540,8 +540,13 @@ void nvmet_ns_revalidate(struct nvmet_ns *ns)
>>> else
>>> nvmet_file_ns_revalidate(ns);
>>>
>>> - if (oldsize != ns->size)
>>> + if (oldsize != ns->size) {
>>> + if (should_acquire_lock)
>>> + mutex_lock(&ns->subsys->lock);
>>> nvmet_ns_changed(ns->subsys, ns->nsid);
>>> + if (should_acquire_lock)
>>> + mutex_unlock(&ns->subsys->lock);
>>> + }
>>
>> What is the harm locking it always and avoid the conditional?
>
> In my patch v2 submission I wrote the following text in my commit message:
>> 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.
> on which Christoph Hellwig replied:
>> So acquire it in nvmet_ns_revalidate only when we actually call
>> nvmet_ns_changed. Otherwise we take a subsystem-wide lock for every
>> Identify Namespace all.
Yea, only wrap nvmet_ns_changed, but always.
>
> Therefore, I changed it to a conditional lock in this patch submission.
>
> My commit message in v2 did not clearly state that nvmet_ns_revalidate has 3 callers, of which
> 2 do not acquire that lock: nvmet_execute_identify_cns_cs_ns and nvmet_execute_identify_ns. The other caller
> nvmet_ns_revalidate_size_store does acquire the lock. Maybe I caused some confusion because of the unclear wording.
It is simpler to just move that call-site outside of the lock imo.
More information about the Linux-nvme
mailing list