Re: [PATCH v4 6/9] iommu/dma-iommu.c: Convert to use vm_insert_range

2018-12-18 Thread Souptick Joarder
On Tue, Dec 18, 2018 at 1:50 AM Souptick Joarder wrote: > > Convert to use vm_insert_range() to map range of kernel > memory to user vma. > > Signed-off-by: Souptick Joarder > Reviewed-by: Matthew Wilcox Cc'd: Robin Murphy > --- > drivers/iommu/dma-iommu.c | 13 +++-- > 1 file changed,

Re: [15/15] dma-mapping: bypass indirect calls for dma-direct

2018-12-18 Thread Christoph Hellwig
On Tue, Dec 18, 2018 at 08:42:46PM +, Robin Murphy wrote: >> [ 16.046084] rk_iommu ff8f3f00.iommu: DMA map error for DT > > Yup, with this patch as-is, anything which isn't behind an IOMMU will be > erroneously banned from DMA entirely - see here: > > https://lore.kernel.org/lkml/20181214142

Re: [15/15] dma-mapping: bypass indirect calls for dma-direct

2018-12-18 Thread Guillaume Tucker
On 07/12/2018 19:07, Christoph Hellwig wrote: > Avoid expensive indirect calls in the fast path DMA mapping > operations by directly calling the dma_direct_* ops if we are using > the directly mapped DMA operations. > > Signed-off-by: Christoph Hellwig > Signed-off-by: Christoph Hellwig > Report

Re: [15/15] dma-mapping: bypass indirect calls for dma-direct

2018-12-18 Thread Robin Murphy
On 2018-12-18 8:34 pm, Guillaume Tucker wrote: On 07/12/2018 19:07, Christoph Hellwig wrote: Avoid expensive indirect calls in the fast path DMA mapping operations by directly calling the dma_direct_* ops if we are using the directly mapped DMA operations. Signed-off-by: Christoph Hellwig Sign

[PATCH 2/2] iommu/dma: Handle potential overflow in iommu_dma_init_domain

2018-12-18 Thread Andrew Jones
The sum of base and size may overflow, particularly considering there are cases where size will be U64_MAX. Also, end_pfn is unused, so we remove it. Finally, as size doesn't actually need to be IOMMU page aligned we remove it from the comment stating both it and base should be. I wonder if we shou

[PATCH 1/2] ACPI/IORT: Handle potential overflow in iort_dma_setup

2018-12-18 Thread Andrew Jones
The sum of dmaaddr and size may overflow, particularly considering there are cases where size will be U64_MAX. Signed-off-by: Andrew Jones --- drivers/acpi/arm64/iort.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c

[PATCH 0/2] ACPI/IORT: handle potential overflows

2018-12-18 Thread Andrew Jones
I saw a couple places where overflows could potentially occur. I've only compile tested these changes. Thanks, drew Andrew Jones (2): ACPI/IORT: Handle potential overflow in iort_dma_setup iommu/dma: Handle potential overflow in iommu_dma_init_domain drivers/acpi/arm64/iort.c | 7 ++-

[PATCH V3 1/2] mm: Replace all open encodings for NUMA_NO_NODE

2018-12-18 Thread Anshuman Khandual
At present there are multiple places where invalid node number is encoded as -1. Even though implicitly understood it is always better to have macros in there. Replace these open encodings for an invalid node number with the global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like

[PATCH V3 0/2] Replace all open encodings for NUMA_NO_NODE

2018-12-18 Thread Anshuman Khandual
Changes in V3: - Dropped all references to NUMA_NO_NODE as per Lubomir Rinetl - Split the patch into two creating a new one specifically for tools - Folded Stephen's linux-next build fix into the second patch Changes in V2: (https://patchwork.kernel.org/patch/10698089/) - Added inclusion of 'num

[PATCH V3 2/2] Tools: Replace open encodings for NUMA_NO_NODE

2018-12-18 Thread Anshuman Khandual
From: Stephen Rothwell This replaces all open encodings in tools with NUMA_NO_NODE. Also linux/numa.h is now needed for the perf build. Signed-off-by: Anshuman Khandual Signed-off-by: Stephen Rothwell --- tools/include/linux/numa.h | 16 tools/perf/bench/numa.c| 6 +++---