linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Andre Tomt <andre@tomt.net>, Tom Murphy <tmurphy@arista.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Joerg Roedel <jroedel@suse.de>,
	iommu@lists.linux-foundation.org
Subject: Re: AMD IOMMU stops RDMA NFS from working since kernel 5.5 (bisected)
Date: Tue, 11 Feb 2020 11:42:27 -0500	[thread overview]
Message-ID: <ACDC4DF0-6B82-4487-A794-582113F10A4B@oracle.com> (raw)
In-Reply-To: <35961bac-2f1e-3fbc-9661-031b9d5acee3@arm.com>



> On Feb 11, 2020, at 11:36 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> 
> On 11/02/2020 4:03 pm, Chuck Lever wrote:
>>> On Feb 11, 2020, at 10:32 AM, Robin Murphy <robin.murphy@arm.com> wrote:
>>> 
>>> On 11/02/2020 3:24 pm, Chuck Lever wrote:
>>>>> On Feb 11, 2020, at 10:12 AM, Robin Murphy <robin.murphy@arm.com> wrote:
>>>>> 
>>>>> On 11/02/2020 1:48 pm, Chuck Lever wrote:
>>>>>> Andre-
>>>>>> Thank you for the detailed report!
>>>>>> Tom-
>>>>>> There is a rich set of trace points available in the RPC/RDMA implementation in 5.4/5.5, fwiw.
>>>>>> Please keep me in the loop, let me know if there is anything I can do to help.
>>>>> 
>>>>> One aspect that may be worth checking is whether there's anywhere that assumes a successful return value from dma_map_sg() is always the same as the number of entries passed in - that's the most obvious way the iommu-dma code differs (legitimately) from the previous amd-iommu implementation.
>>>> net/sunrpc/xprtrdma/frwr_ops.c: frwr_map()
>>>> 317         mr->mr_nents =
>>>> 318                 ib_dma_map_sg(ia->ri_id->device, mr->mr_sg, i, mr->mr_dir);
>>>> 319         if (!mr->mr_nents)
>>>> 320                 goto out_dmamap_err;
>>>> Should that rather be "if (mr->mr_nents != i)" ?
>>> 
>>> No, that much is OK - the point is that dma_map_sg() may pack the DMA addresses such that sg_dma_len(sg) > sg->length - however, subsequently passing that mr->nents to dma_unmap_sg() in frwr_mr_recycle() (rather than the original value of i) looks at a glance like an example of how things may start to get out-of-whack.
>> Robin, your explanation makes sense to me. I can post a fix for this imbalance later today for Andre to try.
> 
> FWIW here's a quick hack which *should* suppress the concatenation behaviour - if it makes Andre's system any happier then that would indeed point towards dma_map_sg() handling being the culprit.

Even so, 1f541895dae9 ("xprtrdma: Don't defer MR recovery if ro_map fails")
looks like it introduced this problem.


> Robin.
> 
> ----->8-----
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index a2e96a5fd9a7..a6b71bad518e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -779,7 +779,7 @@ static int __finalise_sg(struct device *dev, struct scatterlist *sg, int nents,
> 		 * - but doesn't fall at a segment boundary
> 		 * - and wouldn't make the resulting output segment too long
> 		 */
> -		if (cur_len && !s_iova_off && (dma_addr & seg_mask) &&
> +		if (0 && cur_len && !s_iova_off && (dma_addr & seg_mask) &&
> 		    (max_len - cur_len >= s_length)) {
> 			/* ...then concatenate it with the previous one */
> 			cur_len += s_length;
> @@ -799,6 +799,7 @@ static int __finalise_sg(struct device *dev, struct scatterlist *sg, int nents,
> 		if (s_length + s_iova_off < s_iova_len)
> 			cur_len = 0;
> 	}
> +	WARN_ON(count < nents);
> 	return count;
> }

--
Chuck Lever




  reply	other threads:[~2020-02-11 16:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11  5:06 AMD IOMMU stops RDMA NFS from working since kernel 5.5 (bisected) Andre Tomt
2020-02-11  7:25 ` Joerg Roedel
2020-02-11 13:48   ` Chuck Lever
2020-02-11 15:12     ` Robin Murphy
2020-02-11 15:24       ` Chuck Lever
2020-02-11 15:32         ` Robin Murphy
2020-02-11 16:03           ` Chuck Lever
2020-02-11 16:36             ` Robin Murphy
2020-02-11 16:42               ` Chuck Lever [this message]
2020-02-11 17:53               ` Andre Tomt

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=ACDC4DF0-6B82-4487-A794-582113F10A4B@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=andre@tomt.net \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jroedel@suse.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tmurphy@arista.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 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).