On Tue, Nov 02, 2021 at 11:21:16AM +0800, Walter Wu wrote:
> Our platform is arch64. We need a dynamic allocated buffer from CMA is
> not to read by CPU peculative execution, so we need to remove its
> kernel mapping.
If your CPU speculates into unused kernel direct mappings your have
a worse prob
As others pointed out, DMA_ATTR_NO_KERNEL_MAPPING just means the
caller can't rely on a kernel mapping. So the "fix" here is
wrong. That being said for cases where we can easily remove a page
from the kernel mapping it would be nice to do to:
a) improve security
b) as a debug check to see that
On Mon, 2021-11-01 at 15:17 +0100, Ard Biesheuvel wrote:
> On Mon, 1 Nov 2021 at 13:21, Walter Wu
> wrote:
> >
> > Hi Ard,
> >
> > On Mon, 2021-11-01 at 09:34 +0100, Ard Biesheuvel wrote:
> > > On Mon, 1 Nov 2021 at 04:17, Walter Wu > > >
> > > wrote:
> > > >
> > > > DMA_ATTR_NO_KERNEL_MAPPING
On Mon, 1 Nov 2021 at 13:21, Walter Wu wrote:
>
> Hi Ard,
>
> On Mon, 2021-11-01 at 09:34 +0100, Ard Biesheuvel wrote:
> > On Mon, 1 Nov 2021 at 04:17, Walter Wu
> > wrote:
> > >
> > > DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
> > > for the allocated buffer, but current imp
On Fri, Oct 29, 2021 at 09:47:27AM +, Liu, Yi L wrote:
> Hi Jason,
>
> > From: Jason Gunthorpe
> > Sent: Monday, October 25, 2021 8:53 PM
> >
> > On Mon, Oct 25, 2021 at 06:28:09AM +, Liu, Yi L wrote:
> > >thanks for the guiding. will also refer to your vfio_group_cdev series.
> > >
Hi Ard,
On Mon, 2021-11-01 at 09:34 +0100, Ard Biesheuvel wrote:
> On Mon, 1 Nov 2021 at 04:17, Walter Wu
> wrote:
> >
> > DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
> > for the allocated buffer, but current implementation is that
> > PTE of allocated buffer in kernel page
Hi Robin,
On Mon, 2021-11-01 at 10:29 +, Robin Murphy wrote:
> On 2021-11-01 03:15, Walter Wu wrote:
> > DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
> > for the allocated buffer, but current implementation is that
> > PTE of allocated buffer in kernel page table is valid.
On Mon, 2021-11-01 at 09:45 +0100, Krzysztof Kozlowski wrote:
> On 01/11/2021 07:09, Yong Wu wrote:
> > On Fri, 2021-10-29 at 19:35 +0200, Krzysztof Kozlowski wrote:
> > > On 28/10/2021 07:50, Yong Wu wrote:
> > > > We add the ostd setting for mt8195. It introduces a abort for
> > > > the
> > > > p
On 2021-11-01 03:15, Walter Wu wrote:
DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
for the allocated buffer, but current implementation is that
PTE of allocated buffer in kernel page table is valid. So we
should set invalid for PTE of allocate buffer so that there are
no kerne
On 27/10/2021 18:47, Logan Gunthorpe wrote:
scsi_dma_map() was reporting a failure during boot on an AMD machine
with the IOMMU enabled.
scsi_dma_map failed: request for 36 bytes!
The issue was tracked down to a mistake in logic: should not return
an error if iommu_deferred_attach() returns
On 01/11/2021 07:09, Yong Wu wrote:
> On Fri, 2021-10-29 at 19:35 +0200, Krzysztof Kozlowski wrote:
>> On 28/10/2021 07:50, Yong Wu wrote:
>>> We add the ostd setting for mt8195. It introduces a abort for the
>>> previous SoC which doesn't have ostd setting. This is the log:
>>>
>>> Unable to handl
On Mon, 1 Nov 2021 at 04:17, Walter Wu wrote:
>
> DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
> for the allocated buffer, but current implementation is that
> PTE of allocated buffer in kernel page table is valid. So we
> should set invalid for PTE of allocate buffer so that t
DMA_ATTR_NO_KERNEL_MAPPING is to avoid creating a kernel mapping
for the allocated buffer, but current implementation is that
PTE of allocated buffer in kernel page table is valid. So we
should set invalid for PTE of allocate buffer so that there are
no kernel mapping for the allocated buffer.
In
13 matches
Mail list logo
