Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.
> > The logical question is why? > > 1. See that's another platform with ARC core so maybe in case of ARM >DMA allocator already zeroes pages regardless provided flags - >personally I didn't check that. Yes, most architectures always clear memory returned by dma_alloc*. Looks like a few don't and my commit got them in trouble. As usual I'd prefer to match x86 semantics for now to avoid problems. I'll send patches for arc and s390 which seem to be actually used holdouts, and will look if anyone else is also affected. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/22] arc: use generic dma_noncoherent_ops
On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote:
> Which is actually strange as I would expect ARC code to be built by bots.
I don't think I got any notification. Thank for the fixes!
I think I found the bug, based on the fact that so far all tests for
architectures that also need a cache op for device to cpu transitions
failed. I did a stupid typo when changing kconfig symbols, so please
try the patch below.
>
> static int l2_line_sz;
> static int ioc_exists;
> -int slc_enable = 1, ioc_enable = 1;
> +int slc_enable = 1, ioc_enable = 0;
Hmm. It seems if ioc_enable is 0 we should simply be using
dma_direct_ops on arc, but that is a different discussion.
---
diff --git a/lib/dma-noncoherent.c b/lib/dma-noncoherent.c
index f4b8532c20ac..a2c192b3508d 100644
--- a/lib/dma-noncoherent.c
+++ b/lib/dma-noncoherent.c
@@ -48,7 +48,7 @@ static int dma_noncoherent_map_sg(struct device *dev, struct
scatterlist *sgl,
return nents;
}
-#ifdef CONFIG_DMA_NONCOHERENT_SYNC_FOR_CPU
+#ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU
static void dma_noncoherent_sync_single_for_cpu(struct device *dev,
dma_addr_t addr, size_t size, enum dma_data_direction dir)
{
@@ -88,7 +88,7 @@ const struct dma_map_ops dma_noncoherent_ops = {
.sync_sg_for_device = dma_noncoherent_sync_sg_for_device,
.map_page = dma_noncoherent_map_page,
.map_sg = dma_noncoherent_map_sg,
-#ifdef CONFIG_DMA_NONCOHERENT_SYNC_FOR_CPU
+#ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU
.sync_single_for_cpu= dma_noncoherent_sync_single_for_cpu,
.sync_sg_for_cpu= dma_noncoherent_sync_sg_for_cpu,
.unmap_page = dma_noncoherent_unmap_page,
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/22] arc: use generic dma_noncoherent_ops
On Thu, Apr 26, 2018 at 08:45:00AM +0200, h...@lst.de wrote: > On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote: > > Which is actually strange as I would expect ARC code to be built by bots. > > I don't think I got any notification. Thank for the fixes! > > I think I found the bug, based on the fact that so far all tests for > architectures that also need a cache op for device to cpu transitions > failed. I did a stupid typo when changing kconfig symbols, so please > try the patch below. Confirmed to work for nds32, so here is a git tree with the core, arc and nds32 fixes folded in, feel free to test that one: git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
On Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote: > Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE > : DMA_FROM_DEVICE". > I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have > DMA_TO_DEVICE which > is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case > of reading we'll have > DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in > dma_noncoherent_map_sg(). > > I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is > supposed to only be used > in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of > DMA_TO_DEVICE. arc overrides the dir paramter of the dma_sync_single_for_device/ dma_sync_single_for_cpu calls. My patches dropped that, and I have restored that, and audit for the other architectures is pending. That being said the existing arc code still looks rather odd as it didn't do the same thing for the scatterlist versions of the calls. I've thrown in a few patches into my new tree to make the sg versions make the normal calls, and to clean up the area a bit. > You seem to lost an offset in the page so if we happen to have a buffer not > aligned to > a page boundary then we were obviously corrupting data outside our data :) Oops! Thank you for all the debugging! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: arc dma mapping cleanups/fixes and generic noncohernt dma code
On Fri, May 18, 2018 at 02:49:36PM +, Alexey Brodkin wrote:
> So if we set aside my complaints about direction in
> arch_sync_dma_for_{device|cpu}()...
Many other architectures use the argument. Various of those look bogus,
but for now I want to be able to do straight forward conversions. If
we end up not needing the argument in the end we can still remove it
eventually.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
On Fri, May 18, 2018 at 10:05:51PM +0200, Helge Deller wrote: > This patch seems to fix the dma issues I faced on my 32bit B160L parisc box. > > So it leaves only one open issue on parisc: > Now every 32 bit parisc system is unnecessarily non-coherent. I diagree with those comments, let me resend the refactored patch to make it more clear. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
Btw, given that I assume this is 4.20 material now, any chance we could merge it through the dma-mapping tree? I have some major changes pending that would clash if done in a different tree, so I'd rather get it all together. > We check this flag in arch_dma_alloc (which are used in non-coherent case) to > skip MMU mapping if we are advertised that consistency is not required. > > So, actually we can get rid of this flag checking in arch_dma_alloc and > simply always do MMU mapping to enforce non-cachability and return > non-cacheable memory even if DMA_ATTR_NON_CONSISTENT is passed. > But I don't sure we want to do that. I plan to kill this flag for 4.20 (or 4.20 at latest) in favor of a better interface. But your implementation looks ok, so I'm fine with keeping it for now. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
On Fri, Dec 14, 2018 at 12:12:00PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > do you have any public git repository with all your dma changes? Most of the tree show up in my misc.git repo for testing. This series is here: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-alloc-always-zero There current version of the DMA_ATTR_NON_CONSISTENT series is here: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-noncoherent-allocator.2 > I want to test them for ARC. Thanks a lot! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > I test kernel from your 'dma-alloc-always-zero' branch, and as > I can see we have DMA peripherals (like USB) broken. I would be really surprised if that is caused by the patch to add the zeroing. Can you check which commit caused the issue by bisecting from a known good baseline? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote: > > I would be really surprised if that is caused by the patch to add > > the zeroing. > Me too :) > > > Can you check which commit caused the issue by bisecting > > from a known good baseline? > > Yep. At least kernel build from v4.20-rc4 (which is base for your branch) > seems to work fine. Well, the branch has quite a few commits. Can you check the commit just before the zeroing to start, and if that is already broken (which I suspect) bisect the offending commit? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ensure dma_alloc_coherent always returns zeroed memory
Btw, can you try wit the very latests dma-mapping-for-next tree which has a new fix from Thierry Reding that might be related. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA allocations
On Fri, Jun 14, 2019 at 06:05:01PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > Regular question - do you have any public git repository with all this dma > changes? > I want to test it for ARC. > > Pretty sure the > [PATCH 2/7] arc: remove the partial DMA_ATTR_NON_CONSISTENT support > is fine. > > Not so sure about > [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA > allocations > :) git://git.infradead.org/users/hch/misc.git dma-not-consistent-cleanup Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-not-consistent-cleanup ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA allocations
On Mon, Jun 24, 2019 at 07:13:17PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > Yep I've reviewed and tested it for both cases: > - coherent/noncoherent dma > - allocation from atomic_pool/regular allocation > > everything works fine for ARC. Thanks. I've applied the whole series to the dma-mapping for-next branch. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
On Tue, Apr 20, 2021 at 11:20:19PM +0200, Arnd Bergmann wrote:
> In that case, there should be no problem for you.
>
> The main issue is with system calls and ioctls that contain a misaligned
> struct member like
>
> struct s {
>u32 a;
>u64 b;
> };
>
> Passing this structure by reference from a 32-bit user space application
> to a 64-bit kernel with different alignment constraints means that the
> kernel has to convert the structure layout. See
> compat_ioctl_preallocate() in fs/ioctl.c for one such example.
We've also had this problem with some on-disk structures in the past,
but hopefully people desining those have learnt the lesson by now.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
