[kvalo-ath:master-pending] BUILD SUCCESS 504fac6c0111460a75d5748c26abea526d8efa1e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master-pending branch HEAD: 504fac6c0111460a75d5748c26abea526d8efa1e Merge branch 'pending' into master-pending elapsed time: 721m configs tested: 74 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: x86_64allnoconfig powerpc allnoconfig arc defconfig s390 allmodconfig alpha defconfig um x86_64_defconfig um i386_defconfig s390defconfig i386defconfig x86_64 defconfig s390 allyesconfig sh allmodconfig mips allyesconfig powerpc allmodconfig x86_64rhel-8.3-kselftests x86_64 rhel-8.3-func x86_64 rhel-8.3 ia64 allmodconfig i386 randconfig-a014-20230116 i386 randconfig-a013-20230116 arm defconfig i386 randconfig-a012-20230116 i386 randconfig-a011-20230116 i386 randconfig-a016-20230116 i386 randconfig-a015-20230116 x86_64 allyesconfig i386 allyesconfig x86_64 rhel-8.3-syz x86_64 rhel-8.3-kunit x86_64 rhel-8.3-kvm arc randconfig-r043-20230115 s390 randconfig-r044-20230116 x86_64 rhel-8.3-bpf riscvrandconfig-r042-20230116 arc randconfig-r043-20230116 arm randconfig-r046-20230115 arm allyesconfig x86_64 randconfig-a011-20230116 arm randconfig-r046-20230117 x86_64 randconfig-a013-20230116 arc randconfig-r043-20230117 x86_64 randconfig-a012-20230116 x86_64 randconfig-a016-20230116 x86_64 randconfig-a014-20230116 arm64allyesconfig x86_64 randconfig-a015-20230116 m68k allmodconfig m68k allyesconfig alphaallyesconfig arc allyesconfig clang tested configs: x86_64 rhel-8.3-rust x86_64 randconfig-a001-20230116 x86_64 randconfig-a003-20230116 x86_64 randconfig-a002-20230116 hexagon randconfig-r041-20230116 x86_64 randconfig-a004-20230116 riscvrandconfig-r042-20230117 x86_64 randconfig-a005-20230116 x86_64 randconfig-a006-20230116 hexagon randconfig-r045-20230117 s390 randconfig-r044-20230117 hexagon randconfig-r045-20230115 hexagon randconfig-r041-20230117 riscvrandconfig-r042-20230115 arm randconfig-r046-20230116 s390 randconfig-r044-20230115 hexagon randconfig-r045-20230116 hexagon randconfig-r041-20230115 i386 randconfig-a002-20230116 i386 randconfig-a004-20230116 i386 randconfig-a003-20230116 i386 randconfig-a006-20230116 i386 randconfig-a005-20230116 i386 randconfig-a001-20230116 -- 0-DAY CI Kernel Test Service https://01.org/lkp ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[kvalo-ath:pending] BUILD SUCCESS b9dbf85f778b04e820769f775ae8ded64df5f91d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending branch HEAD: b9dbf85f778b04e820769f775ae8ded64df5f91d wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback() elapsed time: 720m configs tested: 114 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arc defconfig alpha defconfig powerpc allnoconfig x86_64allnoconfig um x86_64_defconfig um i386_defconfig i386defconfig s390defconfig arm defconfig i386 allyesconfig s390 allmodconfig x86_64 defconfig i386 randconfig-a014-20230116 x86_64 rhel-8.3-bpf i386 randconfig-a013-20230116 s390 allyesconfig x86_64 rhel-8.3-syz i386 randconfig-a012-20230116 x86_64 rhel-8.3-kunit x86_64 rhel-8.3 i386 randconfig-a015-20230116 x86_64 rhel-8.3-kvm m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig arm64allyesconfig mips allyesconfig powerpc allmodconfig sh allmodconfig i386 randconfig-a011-20230116 arm allyesconfig i386 randconfig-a016-20230116 x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests x86_64 allyesconfig ia64 allmodconfig x86_64 randconfig-a011-20230116 x86_64 randconfig-a013-20230116 x86_64 randconfig-a012-20230116 x86_64 randconfig-a014-20230116 x86_64 randconfig-a016-20230116 x86_64 randconfig-a015-20230116 m68k apollo_defconfig um alldefconfig mips db1xxx_defconfig powerpc mpc837x_rdb_defconfig sh kfr2r09-romimage_defconfig riscvrandconfig-r042-20230116 arm randconfig-r046-20230117 s390 randconfig-r044-20230116 arc randconfig-r043-20230117 arc randconfig-r043-20230116 arc randconfig-r043-20230115 shsh7763rdp_defconfig sh ap325rxa_defconfig alphaalldefconfig arc haps_hs_defconfig arm randconfig-r046-20230115 riscvnommu_virt_defconfig riscv rv32_defconfig riscvnommu_k210_defconfig riscv allnoconfig i386 debian-10.3-kselftests i386 debian-10.3 arm s3c6400_defconfig armlart_defconfig shsh7757lcr_defconfig i386 debian-10.3-kvm i386debian-10.3-kunit i386 debian-10.3-func x86_64 randconfig-k001-20230116 i386 randconfig-c001 sparc defconfig xtensa allyesconfig cskydefconfig sparcallyesconfig x86_64 kexec arm64 defconfig shdreamcast_defconfig arm multi_v4t_defconfig s390 debug_defconfig clang tested configs: i386 randconfig-a002-20230116 i386 randconfig-a004-20230116 i386 randconfig-a001-20230116 i386 randconfig-a003-20230116 i386 randconfig-a005-20230116 i386 randconfig-a006-20230116 arm am200epdkit_defconfig mips mtx1_defconfig powerpc pseries_defconfig x86_64 randconfig-a003-20230116 x86_64 randconfig-a004-20230116 x86_64 randconfig-a006-20230116 x86_64 randconfig-a005-20230116 x86_64 randconfig-a001-20230116 x86_64 randconfig-a002-20230116 riscvrandconfig-r042-20230115 arm randconfig-r046-20230116 s390
RE: [PATCH 7/8] iommu/intel: Support the gfp argument to the map_pages op
> From: Jason Gunthorpe > Sent: Saturday, January 7, 2023 12:43 AM > > @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct > dmar_domain *domain, > > return __domain_mapping(domain, first_vpfn, > first_vpfn, last_vpfn - first_vpfn + 1, > - DMA_PTE_READ|DMA_PTE_WRITE); > + DMA_PTE_READ|DMA_PTE_WRITE, > GFP_KERNEL); > } Baolu, can you help confirm whether switching from GFP_ATOMIC to GFP_KERNEL is OK in this path? it looks fine to me in a quick glance but want to be conservative here. > @@ -4333,7 +4337,8 @@ static size_t intel_iommu_unmap(struct > iommu_domain *domain, > > /* Cope with horrid API which requires us to unmap more than the > size argument if it happens to be a large-page mapping. */ > - BUG_ON(!pfn_to_dma_pte(dmar_domain, iova >> VTD_PAGE_SHIFT, > &level)); > + BUG_ON(!pfn_to_dma_pte(dmar_domain, iova >> VTD_PAGE_SHIFT, > &level, > +GFP_ATOMIC)); with level==0 it implies it's only lookup w/o pgtable allocation. From this angle it reads better to use a more relaxed gfp e.g. GFP_KERNEL here. > @@ -4392,7 +4397,8 @@ static phys_addr_t > intel_iommu_iova_to_phys(struct iommu_domain *domain, > int level = 0; > u64 phys = 0; > > - pte = pfn_to_dma_pte(dmar_domain, iova >> VTD_PAGE_SHIFT, > &level); > + pte = pfn_to_dma_pte(dmar_domain, iova >> VTD_PAGE_SHIFT, > &level, > + GFP_ATOMIC); ditto ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
RE: [PATCH 6/8] iommu/intel: Add a gfp parameter to alloc_pgtable_page()
> From: Jason Gunthorpe > Sent: Saturday, January 7, 2023 12:43 AM > > @@ -2676,7 +2676,7 @@ static int copy_context_table(struct intel_iommu > *iommu, > if (!old_ce) > goto out; > > - new_ce = alloc_pgtable_page(iommu->node); > + new_ce = alloc_pgtable_page(iommu->node, > GFP_KERNEL); GFP_ATOMIC ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
On Fri, Jan 06, 2023 at 05:15:28PM +, Robin Murphy wrote: > However, echoing the recent activity over on the DMA API side of things, I > think it's still worth proactively constraining the set of permissible > flags, lest we end up with more weird problems if stuff that doesn't really > make sense, like GFP_COMP or zone flags, manages to leak through (that may > have been part of the reason for having the current wrappers rather than a > bare gfp argument in the first place, I forget now). I did it like this: --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -2368,6 +2368,11 @@ int iommu_map(struct iommu_domain *domain, unsigned long iova, might_sleep_if(gfpflags_allow_blocking(gfp)); + /* Discourage passing strange GFP flags */ + if (WARN_ON_ONCE(gfp & (__GFP_COMP | __GFP_DMA | __GFP_DMA32 | + __GFP_HIGHMEM))) + return -EINVAL; + ret = __iommu_map(domain, iova, paddr, size, prot, gfp); if (ret == 0 && ops->iotlb_sync_map) ops->iotlb_sync_map(domain, iova, size); @@ -2477,6 +2482,11 @@ ssize_t iommu_map_sg(struct iommu_domain *domain, unsigned long iova, might_sleep_if(gfpflags_allow_blocking(gfp)); + /* Discourage passing strange GFP flags */ + if (WARN_ON_ONCE(gfp & (__GFP_COMP | __GFP_DMA | __GFP_DMA32 | + __GFP_HIGHMEM))) + return -EINVAL; + while (i <= nents) { phys_addr_t s_phys = sg_phys(sg); Will post a v2 when the driver people take a look Thanks, Jason ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k