[PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL_MAPPING buf

Hillf Danton hdanton at sina.com
Sat Sep 5 21:09:54 EDT 2020


On Sat, 05 Sep 2020 08:50:42 -0700 James Bottomley wrote:
> [resend with correct linux-arch address]
> On Sat, 2020-09-05 at 15:35 +0800, Hillf Danton wrote:
> > On Fri, 04 Sep 2020 08:34:39 -0700 James Bottomley wrote:
[...]
> > Hi James
> > > 
> > > This is massively expensive on PARISC and likely other VIPT/VIVT
> > > architectures.
> > 
> > Correct.
> > 
> > > What's the reason for clearing it?  This could also be
> > 
> > 	/* we always manually zero the memory once we are done: */
> > 	gfp &= ~__GFP_ZERO;
> > 	gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
> > 					   &phys_limit);
> 
> That's not a reason ... that comment was put in for coherent mappings. 

It's quite likely that I misread it.

> What is the reason we should incur all this expense for clearing pages
> which aren't unmapped in the kernel, because we can update the comment?

A tough question.

> The usual rationale for kernel mapped pages is security, because they
> may leak information but unmapped pages shouldn't have this problem.

We can turn to Marek for some more light on the concerns you have
about security, particularly linked to DMA_ATTR_NO_KERNEL_MAPPING,
after the patch [1] fails to answer your question.

[1] Subject: [PATCH 1/3] common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute
https://lore.kernel.org/lkml/1337273586-11089-2-git-send-email-m.szyprowski@samsung.com/

> 
> > > really inefficient even on PIPT architectures if the memory is
> > > device remote.
> > > 
> > > If we really have to do this, it should likely be done in the arch
> > > or driver hooks because there are potentially more efficient ways
> > > we can do this knowing how the architecture behaves.
> > 
> > I'm open to any vintage ideas in your mind wrt clearing dma buf e.g
> > on platforms like PARISC. Or feel free to offload me the work if it
> > makes sense to you who are rich of PARISC knowledge.
> 
> OK, I've cc'd linux-arch because this is a problem for more than just
> parisc.  However, not having to do it is the best solution ... sort of
> the doctor, doctor it hurts when I do this answer.
> 
> James




More information about the Linux-nvme mailing list