[PATCH 1/1] nvmet: allow setting model_number once

Max Gurtovoy mgurtovoy at nvidia.com
Thu Feb 18 04:51:36 EST 2021


On 2/18/2021 5:17 AM, Chaitanya Kulkarni wrote:
> Max,
>
> On 2/17/21 10:12, Max Gurtovoy wrote:
>> In case we have already established connection to nvmf target, it
>> shouldn't be allowed to change the model_number. E.g. if someone will
>> identify ctrl and get model_number of "my_model" later on will change
>> the model_numbel via configfs to "my_new_model" this will break the NVM
>> specification for "Get Log Page – Persistent Event Log" that refers to
>> Model Number as: "This field contains the same value as reported in the
>> Model Number field of the Identify Controller data structure, bytes
>> 63:24."
> We don't support persistent event log page since there is no use
> case for target to have human readable format with timestamps,
> instead we do maintain the error log page which has information
> about the errors if user wants.
>
> I'll let Christoph/Sagi decide if we really need to implement
> Persistent Event (PE) log and so does this behavior.
>
> Regarding preventing from changing the model_number when subsys is
> connected to the host, that needs a fix and I sent a patch for that.
>
> We can ignore that patch if we decide to go with this patch with
> PR log page.

what is wrong with this patch ?

why you need the rcu logic in the driver and why do you want to preserve 
a case that initiator A connect to subsystem "my_sub" and see MN == 
Linux and after disconnect and re-connect it might see MN = New_Linux ?


>
>> Although it doesn't mentioned explicitly that this field can't be
>> changed, we can assume it.
>>
>> So allow setting this field only once: using configfs or in the first
>> identify ctrl operation.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme



More information about the Linux-nvme mailing list