[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