On Tue, Sep 13, 2022 at 10:57:44AM +0000, Shinichiro Kawasaki wrote: > > Possible unsafe locking scenario: > > > > CPU0 CPU1 > > ---- ---- > > lock((work_completion)(&queue->release_work)); > > lock((wq_completion)nvmet-wq); > > lock((work_completion)(&queue->release_work)); > > lock(&id_priv->handler_mutex); > > I also observe this WARNING on my test machine with nvme_trtype=rdma. It looks a > hidden rdma issue for me... Yes, that problem is not new, just uncovered by this test. > > The grep error is something I can fix in the test but I don't know how > > to handle the 'eth0 speed is unknown' kernel message which will make > > the test always fail. Is it possible to ignore them when parsing the > > kernel log for errors? > > FYI, each blktests test case can define DMESG_FILTER not to fail with specific > keywords in dmesg. Test cases meta/011 and block/028 are reference use > cases. Ah okay, let me look into it. > Having said that, I don't think 'eth0 speed is unknown' in dmesg makes the test > case fail. See _check_dmesg() in "check" script, which lists keywords that > blktests handles as errors. I guess the WARNING above is the failure cause, > probably. Makes sense. On second thought, the fc transport seems to behave differently than tcp and rdma if you look at the grep error. Will look into it, it might be another existing bug... Daniel
