[PATCH 4/4] nvme: check that EUI/GUID/UUID are globally unique

Alan Adamson alan.adamson at oracle.com
Mon Jun 6 14:51:55 PDT 2022



> On Jun 6, 2022, at 2:38 PM, Keith Busch <kbusch at kernel.org> wrote:
> 
> On Mon, Jun 06, 2022 at 08:35:39PM +0000, Alan Adamson wrote:
>> 
>> 
>>> On Apr 20, 2022, at 12:36 AM, Christoph Hellwig <hch at lst.de> wrote:
>>> 
>>> On Mon, Apr 18, 2022 at 11:30:33PM +0000, Alan Adamson wrote:
>>>> I ran into an issue with blktests and my qemu setup when passthru is enabled.  The passthru tests
>>>> do not complete.  This was because the UUID for the passthru device is coming from the a device
>>>> from the same system since the fabric was setup as a loop and nvme_global_check_duplicate_ids() fails.
>>>> 
>>>> This is probably not a valid real life configuration, but since blktests try to test fabrics on a single
>>>> system, we have this issue.
>>>> 
>>>> I’ve hacked together a fix to manipulate Namespace Identifier’s to get the test to work.  Is there a
>>>> why for blktests to hardcode the IDs for the passthru devices?
>>> 
>>> Hmm.  I suspect the best thing would be to optionally just clear the
>>> IDS entirely.  Optionally as in maybe a fabrics connect argument,
>>> with it defaulting to true only for loop as that is per definition
>>> local.
>> 
>> Here are the changes to support a clear-ids nvme connect argument.  Want to float these changes prior
>> to sending a formal patch out.
> 
> Shouldn't the nvme-passthrough target just change the cntlid so it looks like
> two controllers in the same subsystem? That would just need to stop overriding
> the subsysnqn, which is what currently happens.

That was my original proposal a while ago, though I wasn’t certain what to change. Should the UUID/GUID just be zeroed out?  Is it ok to do that for all passthru targets?

Alan



More information about the Linux-nvme mailing list