From: Sagi Grimberg <sagi@grimberg.me>
To: James Smart <james.smart@broadcom.com>, linux-nvme@lists.infradead.org
Cc: Keith Busch <kbusch@kernel.org>,
Israel Rukshin <israelr@mellanox.com>,
Christoph Hellwig <hch@lst.de>,
stable@vger.kernel.org, Max Gurtovoy <maxg@mellanox.com>
Subject: Re: [PATCH] nvme: Revert: Fix controller creation races with teardown flow
Date: Fri, 28 Aug 2020 16:59:45 -0700 [thread overview]
Message-ID: <741ec2a7-7a38-9432-33fb-58227bf1f1f1@grimberg.me> (raw)
In-Reply-To: <a73cd06b-b319-d55f-1465-4263e08900ae@broadcom.com>
>> This is indeed a regression.
>>
>> Perhaps we should also revert:
>> 12a0b6622107 ("nvme: don't hold nvmf_transports_rwsem for more than
>> transport lookups")
>>
>> Which inherently caused this by removing the serialization of
>> .create_ctrl()...
>
> no, I believe the patch on the semaphore is correct. Otherwise - things
> can be blocked a long time.. a minute (1 cmd timeout) or even multiple
> minutes in the case where a command failure in core layers effectively
> gets ignored and thus doesn't cause the error path in the transport.
> There can be multiple /dev/nvme-fabrics commands stacked up that can
> make the delays look much longer to the last guy.
>
> as far as creation vs teardown... yeah, not fun, but there are other
> ways to deal with it. FC: I got rid of the separate create/reconnect
> threads a while ago thus the return-control-while-reconnecting behavior,
> so I've had to deal with it. It's one area it'd be nice to see some
> convergence in implementation again between transports.
Doesn't fc have a bug there? in create_ctrl after flushing the
connect_work, what is telling it if delete is running in with it
(or that it already ran...)
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-08-29 0:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 19:01 [PATCH] nvme: Revert: Fix controller creation races with teardown flow James Smart
2020-08-28 19:08 ` Sagi Grimberg
2020-08-28 20:24 ` James Smart
2020-08-28 23:59 ` Sagi Grimberg [this message]
2020-08-31 22:26 ` James Smart
2020-08-31 23:15 ` Sagi Grimberg
2020-09-01 15:39 ` James Smart
2020-09-01 22:01 ` Sagi Grimberg
2020-09-02 0:01 ` James Smart
2020-09-08 17:47 ` Christoph Hellwig
2020-09-08 17:47 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=741ec2a7-7a38-9432-33fb-58227bf1f1f1@grimberg.me \
--to=sagi@grimberg.me \
--cc=hch@lst.de \
--cc=israelr@mellanox.com \
--cc=james.smart@broadcom.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=maxg@mellanox.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).