[kvalo-ath:master-pending] BUILD SUCCESS 504fac6c0111460a75d5748c26abea526d8efa1e

2023-01-16 Thread kernel test robot
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

2023-01-16 Thread kernel test robot
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

2023-01-16 Thread Tian, Kevin
> 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()

2023-01-16 Thread Tian, Kevin
> 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()

2023-01-16 Thread Jason Gunthorpe
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