Hi Yong,
>On Mon, 2022-04-25 at 11:03 +0100, Robin Murphy wrote:
>> On 2022-04-25 09:24, Miles Chen via iommu wrote:
>> > When larbdev is NULL (in the case I hit, the node is incorrectly
>> > set
>> > iommus = < NUM>), it will cause device_link_add() fail and
>>
>> Until the MT8195 infra MMU
hi Robin,
>> -link = device_link_add(dev, larbdev,
>> - DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
>> -if (!link)
>> -dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
>> +if (larbdev) {
>
>Until the MT8195 infra MMU support lands, is there
On 4/26/22 09:48, Jean-Philippe Brucker wrote:
> On Tue, Apr 26, 2022 at 08:27:00AM -0700, Dave Hansen wrote:
>> On 4/25/22 09:40, Jean-Philippe Brucker wrote:
>>> The problem is that we'd have to request the device driver to stop DMA
>>> before we can destroy the context and free the PASID. We
On Sat, 23 Apr 2022, Christoph Hellwig wrote:
> swiotlb-xen uses very different ways to allocate coherent memory on x86
> vs arm. On the former it allocates memory from the page allocator, while
> on the later it reuses the dma-direct allocator the handles the
> complexities of non-coherent DMA
> On 25. Apr 2022, at 10:56, Yang Yingliang wrote:
>
> It will cause null-ptr-deref in resource_size(), if platform_get_resource()
> returns NULL, move calling resource_size() after devm_ioremap_resource() that
> will check 'res' to avoid null-ptr-deref.
> And use
Rename the field to make it more clear, that the device can execute DMA
attacks on the system, and thus the system may need protection from
such attacks from this device.
No functional change intended.
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
Reviewed-by: Lu Baolu
Acked-by:
The "DmaProperty" is supported and currently documented and used by
Microsoft [link 1 below], to flag internal PCIe root ports that need
DMA protection [link 2 below]. We have discussed with them and reached
a common understanding that they shall change their MSDN documentation
to say that the
On Tue, Apr 26, 2022 at 4:15 AM Robin Murphy wrote:
>
> On 2022-04-26 01:06, Rajat Jain via iommu wrote:
> > The "DmaProperty" is supported and currently documented and used by
> > Microsoft [link 1 below], to flag internal PCIe root ports that need
> > DMA protection [link 2 below]. We have
On Tue, Apr 26, 2022 at 08:27:00AM -0700, Dave Hansen wrote:
> On 4/25/22 09:40, Jean-Philippe Brucker wrote:
> > The problem is that we'd have to request the device driver to stop DMA
> > before we can destroy the context and free the PASID. We did consider
> > doing this in the release() MMU
Hi Alex,
Thanks for doing this, really helps to catch up the current state. Please
see my comments inline.
On Fri, 22 Apr 2022 16:06:07 -0400, Alex Deucher
wrote:
> Add preliminary documentation for AMD IOMMU and combine
> with the existing Intel IOMMU documentation and clean
> up and
On Fri, Apr 22, 2022 at 05:29:02PM +0100, Shameer Kolothum wrote:
> Parse through the IORT RMR nodes and populate the reserve region list
> corresponding to a given IOMMU and device(optional). Also, go through
> the ID mappings of the RMR node and retrieve all the SIDs associated
> with it.
>
>
On 4/25/22 09:40, Jean-Philippe Brucker wrote:
> The problem is that we'd have to request the device driver to stop DMA
> before we can destroy the context and free the PASID. We did consider
> doing this in the release() MMU notifier, but there were concerns about
> blocking mmput() for too long
On 2022/4/26 下午9:04, Jean-Philippe Brucker wrote:
We currently call arm64_mm_context_put() without holding a reference to
the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
ensure the mm only gets freed after we unpinned the ASID.
Fixes: 32784a9562fb ("iommu/arm-smmu-v3:
Hi Christoph,
> On 23 Apr 2022, at 6:14 pm, Christoph Hellwig wrote:
>
> swiotlb-xen uses very different ways to allocate coherent memory on x86
> vs arm. On the former it allocates memory from the page allocator, while
> on the later it reuses the dma-direct allocator the handles the
>
We currently call arm64_mm_context_put() without holding a reference to
the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
ensure the mm only gets freed after we unpinned the ASID.
Fixes: 32784a9562fb ("iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()")
Signed-off-by:
On Tue, Apr 26, 2022 at 08:20:52PM +0800, zhangfei@foxmail.com wrote:
> Hi, Jean
>
> On 2022/4/26 下午6:04, Jean-Philippe Brucker wrote:
> > We currently call arm64_mm_context_put() without holding a reference to
> > the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
> >
Hi, Jean
On 2022/4/26 下午6:04, Jean-Philippe Brucker wrote:
We currently call arm64_mm_context_put() without holding a reference to
the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
ensure the mm only gets freed after we unpinned the ASID.
Fixes: 32784a9562fb
> -Original Message-
> From: kernel test robot [mailto:l...@intel.com]
> Sent: 23 April 2022 10:51
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: l...@lists.linux.dev;
On 2022-04-26 01:06, Rajat Jain via iommu wrote:
The "DmaProperty" is supported and currently documented and used by
Microsoft [link 1 below], to flag internal PCIe root ports that need
DMA protection [link 2 below]. We have discussed with them and reached
a common understanding that they shall
We currently call arm64_mm_context_put() without holding a reference to
the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to
ensure the mm only gets freed after we unpinned the ASID.
Fixes: 32784a9562fb ("iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()")
Signed-off-by:
On 2022/4/26 08:06, Rajat Jain wrote:
Rename the field to make it more clear, that the device can execute DMA
attacks on the system, and thus the system may need protection from
such attacks from this device.
No functional change intended.
Signed-off-by: Rajat Jain
Reviewed-by: Mika
Hi Will,
On 22/04/2022 11:55, Will Deacon wrote:
On Thu, 21 Apr 2022 13:45:04 +0530, Ashish Mhetre wrote:
Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
entries to not be invalidated correctly. The problem is that the walk
cache index generated for IOVA is not same across
22 matches
Mail list logo
