On 2021/11/15 21:22, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 10:05:46AM +0800, Lu Baolu wrote:
+ /*
+* The UNMANAGED domain should be detached before all
USER
+* owners have been released.
+*/
Hi Bjorn,
On 2021/11/16 4:44, Bjorn Helgaas wrote:
On Mon, Nov 15, 2021 at 10:05:45AM +0800, Lu Baolu wrote:
IOMMU grouping on PCI necessitates that if we lack isolation on a bridge
then all of the downstream devices will be part of the same IOMMU group
as the bridge.
I think this means somet
Hi Bjorn,
On 11/16/21 6:17 AM, Bjorn Helgaas wrote:
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
pci_stub allows the admin to block driver binding on a device and make
it permanently shared with userspace. Since pci_stub does not do DMA,
it is safe. However the admin must understan
Hi Christoph,
On 11/15/21 9:14 PM, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote:
+enum iommu_dma_owner {
+ DMA_OWNER_NONE,
+ DMA_OWNER_KERNEL,
+ DMA_OWNER_USER,
+};
+
+ enum iommu_dma_owner dma_owner;
+ refcount_t owner_cnt;
Hi Bjorn,
On 11/16/21 4:38 AM, Bjorn Helgaas wrote:
On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote:
From the perspective of who is initiating the device to do DMA, device
DMA could be divided into the following types:
DMA_OWNER_KERNEL: kernel device driver intiates the DMA
From: "Matthew Wilcox (Oracle)"
page->freelist is for the use of slab. We already have the ability
to free a list of pages in the core mm, but it requires the use of a
list_head and for the pages to be chained together through page->lru.
Switch the iommu code over to using free_pages_list().
Si
Folks from non-slab subsystems are Cc'd only to patches affecting them, and
this cover letter.
Series also available in git, based on 5.16-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v1r13
Side note: as my SLUB PREEMPT_RT series in 5.15, I would p
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
> pci_stub allows the admin to block driver binding on a device and make
> it permanently shared with userspace. Since pci_stub does not do DMA,
> it is safe. However the admin must understand that using pci_stub allows
> userspace to attack
On Mon, Nov 15, 2021 at 08:58:19PM +, Robin Murphy wrote:
> > The above scenarios are already blocked by the kernel with
> > LOCKDOWN_DEV_MEM - yes there are historical ways to violate kernel
> > integrity, and these days they almost all have mitigation. I would
> > consider any kernel integrit
On 2021-11-15 19:22, Jason Gunthorpe wrote:
On Mon, Nov 15, 2021 at 05:54:42PM +, Robin Murphy wrote:
On 2021-11-15 16:17, Jason Gunthorpe wrote:
On Mon, Nov 15, 2021 at 03:14:49PM +, Robin Murphy wrote:
If userspace has control of device A and can cause A to issue DMA to
arbitary DMA
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
> pci_stub allows the admin to block driver binding on a device and make
> it permanently shared with userspace. Since pci_stub does not do DMA,
> it is safe.
Can you elaborate on what "permanently shared with userspace" means
here? I ass
On Mon, Nov 15, 2021 at 10:05:45AM +0800, Lu Baolu wrote:
> IOMMU grouping on PCI necessitates that if we lack isolation on a bridge
> then all of the downstream devices will be part of the same IOMMU group
> as the bridge.
I think this means something like: "If a PCIe Switch Downstream Port
lacks
On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote:
> From the perspective of who is initiating the device to do DMA, device
> DMA could be divided into the following types:
>
> DMA_OWNER_KERNEL: kernel device driver intiates the DMA
> DMA_OWNER_USER: userspace device driver
From: Zi Yan
Pages are grouped in unit of pageblock_order for mobility. cma and
alloc_contig_range() uses pageblock for isolation and migration, so
aligning PFNs to pageblock_order is necessary. But the PFNs used in cma
and alloc_contig_range() were aligned to max(pageblock_order, MAX_ORDER-1).
T
From: Zi Yan
alloc_contig_range() now only needs to be aligned to pageblock_order,
drop virtio_mem size requirement that it needs to be the max of
pageblock_order and MAX_ORDER.
Signed-off-by: Zi Yan
---
drivers/virtio/virtio_mem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
d
From: Zi Yan
CMA only requires pageblock alignment now. Change CMA alignment in
fadump too.
Signed-off-by: Zi Yan
---
arch/powerpc/include/asm/fadump-internal.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/inc
From: Zi Yan
Hi David,
You suggested to make alloc_contig_range() deal with pageblock_order instead of
MAX_ORDER - 1 and get rid of MAX_ORDER - 1 dependency in virtio_mem[1]. This
patchset is my attempt to achieve that. Please take a look and let me know if
I am doing it correctly or not.
>From
From: Zi Yan
CMA only requires pageblock alignment. Change fadump too.
Signed-off-by: Zi Yan
---
arch/powerpc/include/asm/fadump-internal.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fadump-inter
On Mon, Nov 15, 2021 at 06:35:37PM +, Robin Murphy wrote:
> On 2021-11-15 15:56, Jason Gunthorpe via iommu wrote:
> > On Mon, Nov 15, 2021 at 03:37:18PM +, Robin Murphy wrote:
> >
> > > IOMMUs, and possibly even fewer of them support VFIO, so I'm in full
> > > agreement with Greg and Chris
On Mon, Nov 15, 2021 at 05:54:42PM +, Robin Murphy wrote:
> On 2021-11-15 16:17, Jason Gunthorpe wrote:
> > On Mon, Nov 15, 2021 at 03:14:49PM +, Robin Murphy wrote:
> >
> > > > If userspace has control of device A and can cause A to issue DMA to
> > > > arbitary DMA addresses then there a
On 2021-11-15 18:19, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 05:54:42PM +, Robin Murphy wrote:
s/PIO/MMIO, but yes basically. And not just data trasnfer but
userspace can interfere with the device state as well.
Sure, but unexpected changes in device state could happen for any num
On 2021-11-15 15:56, Jason Gunthorpe via iommu wrote:
On Mon, Nov 15, 2021 at 03:37:18PM +, Robin Murphy wrote:
IOMMUs, and possibly even fewer of them support VFIO, so I'm in full
agreement with Greg and Christoph that this absolutely warrants being scoped
per-bus. I mean, we literally alr
On Mon, Nov 15, 2021 at 05:54:42PM +, Robin Murphy wrote:
> > s/PIO/MMIO, but yes basically. And not just data trasnfer but
> > userspace can interfere with the device state as well.
>
> Sure, but unexpected changes in device state could happen for any number of
> reasons - uncorrected ECC err
On Mon, Nov 15, 2021 at 11:56:13AM -0400, Jason Gunthorpe wrote:
> drivers/base/platform.c:.dma_configure = platform_dma_configure,
> drivers/bus/fsl-mc/fsl-mc-bus.c:.dma_configure =
> fsl_mc_dma_configure,
> drivers/pci/pci-driver.c: .dma_configure = pci_dma_configure,
>
On 2021-11-15 16:17, Jason Gunthorpe wrote:
On Mon, Nov 15, 2021 at 03:14:49PM +, Robin Murphy wrote:
If userspace has control of device A and can cause A to issue DMA to
arbitary DMA addresses then there are certain PCI topologies where A
can now issue peer to peer DMA and manipulate the M
On Mon, Nov 15, 2021 at 03:14:49PM +, Robin Murphy wrote:
> > If userspace has control of device A and can cause A to issue DMA to
> > arbitary DMA addresses then there are certain PCI topologies where A
> > can now issue peer to peer DMA and manipulate the MMMIO registers in
> > device B.
> >
On Mon, Nov 15, 2021 at 03:37:18PM +, Robin Murphy wrote:
> IOMMUs, and possibly even fewer of them support VFIO, so I'm in full
> agreement with Greg and Christoph that this absolutely warrants being scoped
> per-bus. I mean, we literally already have infrastructure to prevent drivers
> bindi
On 2021-11-15 13:24, Jason Gunthorpe via iommu wrote:
On Mon, Nov 15, 2021 at 05:19:02AM -0800, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 10:05:43AM +0800, Lu Baolu wrote:
@@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto do
Dear IOMMU Subsystem Maintainers,
I have been debugging an issue with Nathan Langford, CC here, for some months
now, along with Alex Williamson on the linux-pci mailing list, and I just wanted
to check that we aren't also running into an IOMMU bug when enabling IRQ
remapping in the crashkernel.
N
On 2021-11-15 13:31, Jason Gunthorpe via iommu wrote:
On Mon, Nov 15, 2021 at 05:21:26AM -0800, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
pci_stub allows the admin to block driver binding on a device and make
it permanently shared with userspace. Since p
On Mon, 8 Nov 2021 16:24:29 +0800, Yong Wu wrote:
> We add the ostd setting for mt8195. It introduces a KE for the
> previous SoC which doesn't have ostd setting. This is the log:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0080
> ...
> pc : mtk_smi_larb_c
On Mon, Nov 15, 2021 at 07:59:10AM +0100, Greg Kroah-Hartman wrote:
> > @@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct
> > device_driver *drv)
> > goto done;
> > }
> >
> > + if (!drv->suppress_auto_claim_dma_owner) {
> > + ret = iommu_device_s
On Mon, Nov 15, 2021 at 05:21:26AM -0800, Christoph Hellwig wrote:
> On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
> > pci_stub allows the admin to block driver binding on a device and make
> > it permanently shared with userspace. Since pci_stub does not do DMA,
> > it is safe.
>
> If
On Mon, Nov 15, 2021 at 10:05:47AM +0800, Lu Baolu wrote:
> The vfio needs to set DMA_OWNER_USER for the entire group when attaching
The vfio subsystem? driver?
> it to a vfio container. So expose group variants of setting/releasing dma
> ownership for this purpose.
>
> This also exposes the he
On Mon, Nov 15, 2021 at 05:19:02AM -0800, Christoph Hellwig wrote:
> On Mon, Nov 15, 2021 at 10:05:43AM +0800, Lu Baolu wrote:
> > @@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct
> > device_driver *drv)
> > goto done;
> > }
> >
> > + if (!drv->suppress_a
On Mon, Nov 15, 2021 at 10:05:46AM +0800, Lu Baolu wrote:
> + /*
> + * The UNMANAGED domain should be detached before all
> USER
> + * owners have been released.
> + */
Please avoid comments spilling over 80 charac
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
> pci_stub allows the admin to block driver binding on a device and make
> it permanently shared with userspace. Since pci_stub does not do DMA,
> it is safe.
If an IOMMU is setup and dma-iommu or friends are not used nothing is
unsafe anyw
On Mon, Nov 15, 2021 at 07:59:10AM +0100, Greg Kroah-Hartman wrote:
> This feels wrong to be doing it in the driver core, why doesn't the bus
> that cares about this handle it instead?
>
> You just caused all drivers in the kernel today to set and release this
> ownership, as none set this flag.
On Mon, Nov 15, 2021 at 10:05:43AM +0800, Lu Baolu wrote:
> @@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct
> device_driver *drv)
> goto done;
> }
>
> + if (!drv->suppress_auto_claim_dma_owner) {
> + ret = iommu_device_set_dma_owner(dev
On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote:
> +enum iommu_dma_owner {
> + DMA_OWNER_NONE,
> + DMA_OWNER_KERNEL,
> + DMA_OWNER_USER,
> +};
> +
> + enum iommu_dma_owner dma_owner;
> + refcount_t owner_cnt;
> + struct file *owner_user_file;
I'd just overload the
40 matches
Mail list logo
