All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: sagig@mellanox.com, linux-rdma@vger.kernel.org,
	target-devel@vger.kernel.org
Subject: Re: T10 PI offloading seems to be broken in iser/isert in 4.5/4.6-rc
Date: Fri, 8 Apr 2016 21:58:46 -0700	[thread overview]
Message-ID: <20160409045846.GA9269@infradead.org> (raw)
In-Reply-To: <1460169374.5010.4.camel@haakon3.risingtidesystems.com>

On Fri, Apr 08, 2016 at 07:36:14PM -0700, Nicholas A. Bellinger wrote:
> Ah, yes.  However, TARGET_PROT_DIN_INSERT / TARGET_PROT_DOUT_STRIP
> will only be happening in sbc_set_prot_op_checks() if fabric_prot = true
> for a backend that does not support PI.
> 
> Eg: fabric_prot is for the special case where the fabric supports PI,
> but the backend does not, and the normal feature bits a device would
> expose for PI are emulated based upon the fabric protection features.
> 
> Since your backend does support PI, cmd->prot_op should always be
> TARGET_PROT_*_PASS regardless.
> 
> The other thing to check is that isert_get_sup_prot_ops() is returning
> TARGET_PROT_ALL when tpg->tpg_attrib.t10_pi = true.

Ok, it turns out this problem was a second LUN that doesn't support
PI.  So the reported bug is for a this fabrics_prot case, the scsi_debug
LUN was actually doing fine.

The root cause seems to be that transport_generic_new_cmd allocates
a prot_sg for all protection cases, which causes isert_reg_sig_mr
to assign a value to sig_wr.prot even for the strip/insert case,
which will then cause mlx5 to blow up.  But even when fixing that
I run into data compare errors, so there's defintively something deeper
hiding here.

  reply	other threads:[~2016-04-09  4:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-08 22:15 T10 PI offloading seems to be broken in iser/isert in 4.5/4.6-rc Christoph Hellwig
2016-04-08 23:48 ` Nicholas A. Bellinger
2016-04-09  0:14   ` Christoph Hellwig
2016-04-09  2:36     ` Nicholas A. Bellinger
2016-04-09  4:58       ` Christoph Hellwig [this message]
     [not found]         ` <20160409045846.GA9269-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-04-10  8:53           ` Sagi Grimberg
2016-04-10 14:37             ` Christoph Hellwig
2016-04-10 15:30               ` Sagi Grimberg
     [not found]       ` <1460169374.5010.4.camel-XoQW25Eq2zviZyQQd+hFbcojREIfoBdhmpATvIKMPHk@public.gmane.org>
2016-04-10  8:42         ` sagig

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=20160409045846.GA9269@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=sagig@mellanox.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.