[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ouked4rirrquxur3zzkzm2tsnjtdyfme4hqzetd7hyudtneuhl@feetyajbpqcq>
Date: Wed, 21 Jun 2023 11:02:24 +0200
From: Daniel Wagner <dwagner@...e.de>
To: Sagi Grimberg <sagi@...mberg.me>
Cc: linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org, Chaitanya Kulkarni <kch@...dia.com>,
Shin'ichiro Kawasaki <shinichiro@...tmail.com>,
Hannes Reinecke <hare@...e.de>,
James Smart <jsmart2021@...il.com>,
Martin Belanger <Martin.Belanger@...l.com>
Subject: Re: [PATCH blktests v1 2/3] nvme/rc: Avoid triggering host nvme-cli
autoconnect
On Tue, Jun 20, 2023 at 07:43:35PM +0200, Daniel Wagner wrote:
> On Tue, Jun 20, 2023 at 05:07:43PM +0300, Sagi Grimberg wrote:
> > Hmm... is this hapenning with non-fc as well?
>
> I haven't seen a problem for TCP or RDMA yet but in principle it should also
> exists. I can do some tracing to see if we have also problem thern. Two of the
> udev rule match on the subsystem and the event type.
The only udev rule which gets triggered during blktests execution is this one:
# nvme-fc transport generated events (old-style for compatibility)
ACTION=="change", SUBSYSTEM=="fc", ENV{FC_EVENT}=="nvmediscovery", \
ENV{NVMEFC_HOST_TRADDR}=="*", ENV{NVMEFC_TRADDR}=="*", \
RUN+="@SYSTEMCTL@ --no-block restart nvmf-connect@...evice=none\t--transport=fc\t--traddr=$env{NVMEFC_TRADDR}\t--trsvcid=none\t--host-traddr=$env{NVMEFC_HOST_TRADDR}.service"
That explain why blktests didn't get disturbed by the autoconnect rule as this
rule has a match on the fc subsystem.
Powered by blists - more mailing lists