From: Konrad Rzeszutek Wilk <konrad@darnok.org> To: 'Dominique MARTINET' <dominique.martinet@atmark-techno.com> Cc: "Chanho Park" <chanho61.park@samsung.com>, "'Jianxiong Gao'" <jxgao@google.com>, "'Christoph Hellwig'" <hch@lst.de>, "'Konrad Rzeszutek Wilk'" <konrad.wilk@oracle.com>, "'Linus Torvalds'" <torvalds@linux-foundation.org>, "'Horia Geantă'" <horia.geanta@nxp.com>, linux-kernel@vger.kernel.org, "'Lukas Hartmann'" <lukas@mntmn.com>, "'Aymen Sghaier'" <aymen.sghaier@nxp.com>, "'Herbert Xu'" <herbert@gondor.apana.org.au>, "'David S. Miller'" <davem@davemloft.net>, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, "'Marc Orr'" <marcorr@google.com>, "'Erdem Aktas'" <erdemaktas@google.com>, "'Peter Gonda'" <pgonda@google.com>, "'Bumyong Lee'" <bumyong.lee@samsung.com> Subject: Re: swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb) stable/for-linus-5.12) Date: Tue, 22 Jun 2021 17:58:14 -0400 [thread overview] Message-ID: <YNJc9qxeIjy6VuLt@fedora> (raw) In-Reply-To: <YNGVyOyD+CAMmPos@atmark-techno.com> On Tue, Jun 22, 2021 at 04:48:24PM +0900, 'Dominique MARTINET' wrote: > Konrad Rzeszutek Wilk wrote on Mon, Jun 21, 2021 at 09:16:43AM -0400: > > The beaty of 'devel' and 'linux-next' is that they can be reshuffled and > > mangled. I pushed them original patch from Bumyong there and will let > > it sit for a day and then create a stable branch and give it to Linus. > > Thanks, that should be good. > > Do you want me to send a follow-up patch with the two extra checks > (tlb_addr & (IO_TLB_SIZE -1)) > swiotlb_align_offset(dev, orig_addr) > tlb_offset < alloc_size > > or are we certain this can't ever happen? I would love more patches and I saw the previous one you posted. But we only got two (or one) weeks before the next merge window opens so I am sending to Linus the one that was tested with NVMe and crypto (see above). That is the https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/commit/?h=stable/for-linus-5.14 And then after Linus releases the 5.14 - I would love to take your cleanup on top of that and test it? > (I didn't see any hit in dmesg when I ran with these, but my opinion is > better safe than sorry...) > > > > Then I need to expand the test-regression bucket so that this does not > > happen again. Dominique, how easy would it be to purchase one of those > > devices? > > My company is making such a device, but it's not on the market yet > (was planned for august, with some delay in approvisionning it'll > probably be a bit late), and would mean buying from Japan so I'm not > sure how convenient that would be... > > These are originally NXP devices so I assume Horia would have better > suggestions, if you would? > > > > I was originally thinking to create a crypto device in QEMU to simulate > > this but that may take longer to write than just getting the real thing. > > > > Or I could create some fake devices with weird offsets and write a driver > > for it to exercise this.. like this one I had done some time ago that > > needs some brushing off. > > Just a fake device with fake offsets as a test is probably good enough, > ideally would need to exerce both failures we've seen (offset in > dma_sync_single_for_device like caam does and in the original mapping (I > assume?) like the NVMe driver does), but that sounds possible :) Yup. Working on that now. > > > Thanks again! > -- > Dominique
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad@darnok.org> To: 'Dominique MARTINET' <dominique.martinet@atmark-techno.com> Cc: "'Aymen Sghaier'" <aymen.sghaier@nxp.com>, "'Herbert Xu'" <herbert@gondor.apana.org.au>, "'Horia Geantă'" <horia.geanta@nxp.com>, "'Konrad Rzeszutek Wilk'" <konrad.wilk@oracle.com>, "'Marc Orr'" <marcorr@google.com>, "'Lukas Hartmann'" <lukas@mntmn.com>, linux-kernel@vger.kernel.org, "'David S. Miller'" <davem@davemloft.net>, iommu@lists.linux-foundation.org, linux-crypto@vger.kernel.org, "'Peter Gonda'" <pgonda@google.com>, "Chanho Park" <chanho61.park@samsung.com>, "'Bumyong Lee'" <bumyong.lee@samsung.com>, "'Linus Torvalds'" <torvalds@linux-foundation.org>, "'Christoph Hellwig'" <hch@lst.de>, "'Jianxiong Gao'" <jxgao@google.com> Subject: Re: swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb) stable/for-linus-5.12) Date: Tue, 22 Jun 2021 17:58:14 -0400 [thread overview] Message-ID: <YNJc9qxeIjy6VuLt@fedora> (raw) In-Reply-To: <YNGVyOyD+CAMmPos@atmark-techno.com> On Tue, Jun 22, 2021 at 04:48:24PM +0900, 'Dominique MARTINET' wrote: > Konrad Rzeszutek Wilk wrote on Mon, Jun 21, 2021 at 09:16:43AM -0400: > > The beaty of 'devel' and 'linux-next' is that they can be reshuffled and > > mangled. I pushed them original patch from Bumyong there and will let > > it sit for a day and then create a stable branch and give it to Linus. > > Thanks, that should be good. > > Do you want me to send a follow-up patch with the two extra checks > (tlb_addr & (IO_TLB_SIZE -1)) > swiotlb_align_offset(dev, orig_addr) > tlb_offset < alloc_size > > or are we certain this can't ever happen? I would love more patches and I saw the previous one you posted. But we only got two (or one) weeks before the next merge window opens so I am sending to Linus the one that was tested with NVMe and crypto (see above). That is the https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/commit/?h=stable/for-linus-5.14 And then after Linus releases the 5.14 - I would love to take your cleanup on top of that and test it? > (I didn't see any hit in dmesg when I ran with these, but my opinion is > better safe than sorry...) > > > > Then I need to expand the test-regression bucket so that this does not > > happen again. Dominique, how easy would it be to purchase one of those > > devices? > > My company is making such a device, but it's not on the market yet > (was planned for august, with some delay in approvisionning it'll > probably be a bit late), and would mean buying from Japan so I'm not > sure how convenient that would be... > > These are originally NXP devices so I assume Horia would have better > suggestions, if you would? > > > > I was originally thinking to create a crypto device in QEMU to simulate > > this but that may take longer to write than just getting the real thing. > > > > Or I could create some fake devices with weird offsets and write a driver > > for it to exercise this.. like this one I had done some time ago that > > needs some brushing off. > > Just a fake device with fake offsets as a test is probably good enough, > ideally would need to exerce both failures we've seen (offset in > dma_sync_single_for_device like caam does and in the original mapping (I > assume?) like the NVMe driver does), but that sounds possible :) Yup. Working on that now. > > > Thanks again! > -- > Dominique _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-06-22 21:58 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-26 16:00 [GIT PULL] (swiotlb) stable/for-linus-5.12 Konrad Rzeszutek Wilk 2021-02-26 22:24 ` pr-tracker-bot 2021-06-08 2:35 ` swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb) stable/for-linus-5.12) Dominique MARTINET 2021-06-10 14:52 ` Horia Geantă 2021-06-10 14:52 ` Horia Geantă 2021-06-10 19:41 ` Linus Torvalds 2021-06-10 19:41 ` Linus Torvalds 2021-06-10 23:20 ` Horia Geantă 2021-06-10 23:20 ` Horia Geantă 2021-06-11 6:21 ` Christoph Hellwig 2021-06-11 6:21 ` Christoph Hellwig 2021-06-11 10:34 ` Konrad Rzeszutek Wilk 2021-06-11 10:34 ` Konrad Rzeszutek Wilk 2021-06-11 10:59 ` Horia Geantă 2021-06-11 10:59 ` Horia Geantă 2021-06-11 16:21 ` Linus Torvalds 2021-06-11 16:21 ` Linus Torvalds 2021-06-16 20:49 ` Jianxiong Gao 2021-06-16 20:49 ` Jianxiong Gao via iommu 2021-06-17 0:27 ` Konrad Rzeszutek Wilk 2021-06-17 0:27 ` Konrad Rzeszutek Wilk 2021-06-17 0:39 ` Dominique MARTINET 2021-06-17 0:39 ` Dominique MARTINET 2021-06-17 5:12 ` Christoph Hellwig 2021-06-17 5:12 ` Christoph Hellwig 2021-06-17 5:36 ` Dominique MARTINET 2021-06-17 5:36 ` Dominique MARTINET 2021-06-18 18:01 ` Jianxiong Gao 2021-06-18 18:01 ` Jianxiong Gao via iommu 2021-06-21 2:03 ` Dominique MARTINET 2021-06-21 2:03 ` Dominique MARTINET 2021-06-21 2:55 ` Chanho Park 2021-06-21 2:55 ` Chanho Park 2021-06-21 4:14 ` 'Dominique MARTINET' 2021-06-21 4:14 ` 'Dominique MARTINET' 2021-06-21 13:16 ` Konrad Rzeszutek Wilk 2021-06-21 13:16 ` Konrad Rzeszutek Wilk 2021-06-22 7:48 ` 'Dominique MARTINET' 2021-06-22 7:48 ` 'Dominique MARTINET' 2021-06-22 21:58 ` Konrad Rzeszutek Wilk [this message] 2021-06-22 21:58 ` Konrad Rzeszutek Wilk 2021-06-22 23:04 ` 'Dominique MARTINET' 2021-06-22 23:04 ` 'Dominique MARTINET' 2021-06-17 11:33 ` Christoph Hellwig 2021-06-17 11:33 ` Christoph Hellwig 2021-06-11 16:01 ` Linus Torvalds 2021-06-11 16:01 ` Linus Torvalds
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=YNJc9qxeIjy6VuLt@fedora \ --to=konrad@darnok.org \ --cc=aymen.sghaier@nxp.com \ --cc=bumyong.lee@samsung.com \ --cc=chanho61.park@samsung.com \ --cc=davem@davemloft.net \ --cc=dominique.martinet@atmark-techno.com \ --cc=erdemaktas@google.com \ --cc=hch@lst.de \ --cc=herbert@gondor.apana.org.au \ --cc=horia.geanta@nxp.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jxgao@google.com \ --cc=konrad.wilk@oracle.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lukas@mntmn.com \ --cc=marcorr@google.com \ --cc=pgonda@google.com \ --cc=torvalds@linux-foundation.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: linkBe 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.