[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