From: David Disseldorp <ddiss@suse.de>
To: Michael Christie <michael.christie@oracle.com>
Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFC PATCH] scsi: target: detect XCOPY NAA descriptor conflicts
Date: Thu, 3 Sep 2020 00:23:36 +0200 [thread overview]
Message-ID: <20200903002336.083e88a4@suse.de> (raw)
In-Reply-To: <2155E745-0E65-441B-93AF-7B4C0A53F5F4@oracle.com>
Hi Mike,
On Tue, 1 Sep 2020 22:17:51 -0500, Michael Christie wrote:
> > --- a/drivers/target/target_core_xcopy.c
> > +++ b/drivers/target/target_core_xcopy.c
> > @@ -68,8 +68,14 @@ static int target_xcopy_locate_se_dev_e4_iter(struct se_device *se_dev,
> > if (rc != 0)
> > return 0;
> >
> > - info->found_dev = se_dev;
> > pr_debug("XCOPY 0xe4: located se_dev: %p\n", se_dev);
> > + if (info->found_dev) {
> > + pr_warn("XCOPY 0xe4 descriptor conflict for se_dev %p and %p\n",
> > + info->found_dev, se_dev);
> > + target_undepend_item(&info->found_dev->dev_group.cg_item);
> > + return -ENOTUNIQ;
> > + }
> > + info->found_dev = se_dev;
>
> Was it valid to copy to/from the same LUN? You would copy from/to different src/destinations on that LUN. Would your patch break that?
XCOPY allows for copies to occur on the same LUN or between separate
src/destinations. The intention of this patch is that regardless of the
source or destination, if the NAA WWN could refer to multiple LUNs on
the same target (via target_for_each_device()) then the XCOPY should
fail and force the initiator to fallback to initiator driver copy.
Cheers, David
WARNING: multiple messages have this Message-ID (diff)
From: David Disseldorp <ddiss@suse.de>
To: Michael Christie <michael.christie@oracle.com>
Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFC PATCH] scsi: target: detect XCOPY NAA descriptor conflicts
Date: Wed, 02 Sep 2020 22:23:36 +0000 [thread overview]
Message-ID: <20200903002336.083e88a4@suse.de> (raw)
In-Reply-To: <2155E745-0E65-441B-93AF-7B4C0A53F5F4@oracle.com>
Hi Mike,
On Tue, 1 Sep 2020 22:17:51 -0500, Michael Christie wrote:
> > --- a/drivers/target/target_core_xcopy.c
> > +++ b/drivers/target/target_core_xcopy.c
> > @@ -68,8 +68,14 @@ static int target_xcopy_locate_se_dev_e4_iter(struct se_device *se_dev,
> > if (rc != 0)
> > return 0;
> >
> > - info->found_dev = se_dev;
> > pr_debug("XCOPY 0xe4: located se_dev: %p\n", se_dev);
> > + if (info->found_dev) {
> > + pr_warn("XCOPY 0xe4 descriptor conflict for se_dev %p and %p\n",
> > + info->found_dev, se_dev);
> > + target_undepend_item(&info->found_dev->dev_group.cg_item);
> > + return -ENOTUNIQ;
> > + }
> > + info->found_dev = se_dev;
>
> Was it valid to copy to/from the same LUN? You would copy from/to different src/destinations on that LUN. Would your patch break that?
XCOPY allows for copies to occur on the same LUN or between separate
src/destinations. The intention of this patch is that regardless of the
source or destination, if the NAA WWN could refer to multiple LUNs on
the same target (via target_for_each_device()) then the XCOPY should
fail and force the initiator to fallback to initiator driver copy.
Cheers, David
next prev parent reply other threads:[~2020-09-02 22:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 0:21 [RFC PATCH] scsi: target: detect XCOPY NAA descriptor conflicts David Disseldorp
2020-08-13 0:21 ` David Disseldorp
2020-08-13 11:08 ` David Disseldorp
2020-08-13 11:08 ` David Disseldorp
2020-08-24 16:56 ` David Disseldorp
2020-08-24 16:56 ` David Disseldorp
2020-09-02 3:17 ` Michael Christie
2020-09-02 3:17 ` Michael Christie
2020-09-02 22:23 ` David Disseldorp [this message]
2020-09-02 22:23 ` David Disseldorp
2020-09-03 15:36 ` Michael Christie
2020-09-03 15:36 ` Michael Christie
2020-09-03 20:54 ` David Disseldorp
2020-09-03 20:54 ` David Disseldorp
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=20200903002336.083e88a4@suse.de \
--to=ddiss@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=michael.christie@oracle.com \
--cc=target-devel@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 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.