From: emilne@redhat.com (Ewan D. Milne)
Subject: [PATCH v2] nvmet_fc: support target port removal with nvmet layer
Date: Wed, 05 Sep 2018 16:24:01 -0400 [thread overview]
Message-ID: <1536179041.8172.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20180905195652.GA2560@infradead.org>
On Wed, 2018-09-05@12:56 -0700, Christoph Hellwig wrote:
> Ewan, James: what is the conclusion on this patch? The discussion
> seems to have faded.
I think where we left it was that I found a case where the patch
exposed a problem that James thought needed a fix in the lpfc driver.
The basic problem with the tree right now is that "nvmetcli clear"
frees the nvmet_port object but nvmet_fc_tgtport still points to the
freed memory. So, if a subsequent connect request comes in, we
reference the freed memory. I normally run with slub_debug=FZPU, so I
get a crash right away. Otherwise you might never notice (but our
QE people have seen odd behavior, which sent me looking...)
With James' v2 patch, he addresses the problem, however now there is
a different one, which is that if the target is not configured, and
a connect request comes in, we hang on the initiator side.
This is all with the NVMe/FC soft target.
-Ewan
next prev parent reply other threads:[~2018-09-05 20:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-09 23:48 [PATCH v2] nvmet_fc: support target port removal with nvmet layer James Smart
2018-08-10 17:53 ` Ewan D. Milne
2018-08-10 23:21 ` James Smart
2018-08-13 16:38 ` Ewan D. Milne
2018-08-10 20:50 ` Ewan D. Milne
2018-08-10 23:04 ` James Smart
2018-09-05 19:56 ` Christoph Hellwig
2018-09-05 20:12 ` James Smart
2018-09-11 7:17 ` Christoph Hellwig
2018-09-05 20:24 ` Ewan D. Milne [this message]
2018-09-05 20:40 ` James Smart
2018-09-11 7:35 ` Christoph Hellwig
2018-09-11 17:01 ` James Smart
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=1536179041.8172.49.camel@localhost.localdomain \
--to=emilne@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.