On Wed, Jan 18, 2023 at 01:18:18AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, January 17, 2023 9:30 PM
> >
> > On Tue, Jan 17, 2023 at 03:35:08AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Saturday, January 7, 2023 12:43 AM
> > > >
> > > >
> +++ b/include/net/cfg80211.h
> @@ -5386,6 +5386,8 @@ struct wiphy {
> void (*reg_notifier)(struct wiphy *wiphy,
>struct regulatory_request *request);
>
> + void (*beacon_hint_notifier)(struct wiphy *wiphy);
missing documentation, for sure
Also this
There is only one call site and it can now just pass the GFP_ATOMIC to the
normal iommu_map().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/iommu.c | 7 ---
include/linux/iommu.h | 9 -
3 files changed, 1 insertion(+), 17 deletions(-)
Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
allocation here, based on the provided gfp flags.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 5 +++--
drivers/iommu/iommu.c | 26
Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
__domain_mapping().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c
titan_defconfig
powerpc mpc837x_mds_defconfig
mips maltasmvp_defconfig
riscvrandconfig-r042-20230118
s390 randconfig-r044-20230118
arc randconfig-r043-20230118
powerpc eiger_defconfig
arc
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the
maltasmvp_defconfig
riscvrandconfig-r042-20230118
s390 randconfig-r044-20230118
arc randconfig-r043-20230118
powerpc eiger_defconfig
arc nsimosci_hs_defconfig
i386 randconfig-c001
i386
This is eventually called by iommufd through intel_iommu_map_pages() and
it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 14 +++---
drivers/iommu/intel/iommu.h | 2 +-
drivers/iommu/intel/pasid.c |
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe
---
arch/arm/mm/dma-mapping.c | 11
dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by
iommufd through s390_iommu_map_pages() and it should not be forced to
atomic. Thread the gfp parameter through the call chain starting from
s390_iommu_map_pages().
Reviewed-by: Niklas Schnelle
Signed-off-by: Jason
randconfig-r043-20230118
m68kq40_defconfig
powerpc taishan_defconfig
shtitan_defconfig
powerpc mpc837x_mds_defconfig
mips maltasmvp_defconfig
riscvrandconfig-r042-20230118
s390
-20230118
s390 randconfig-r044-20230118
arc randconfig-r043-20230118
i386 randconfig-a012
i386 randconfig-a014
i386 randconfig-a016
clang tested configs:
x86_64 randconfig-a001
These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
was added mechanically in the prior patches.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c
These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC
was added mechanically in the prior patches.
Reviewed-by: Niklas Schnelle
Signed-off-by: Jason Gunthorpe
---
arch/s390/pci/pci_dma.c| 2 +-
drivers/iommu/s390-iommu.c | 2 +-
2 files changed, 2 insertions(+), 2
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Signed-off-by: Jason Gunthorpe
---
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> The internal mechanisms support this, but instead of exposting the gfp to
> the caller it wrappers it into iommu_map() and iommu_map_atomic()
>
> Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
>
>
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
>
> This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
> allocation here, based on the provided gfp flags.
>
> Signed-off-by: Jason
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> There is only one call site and it can now just pass the GFP_ATOMIC to the
> normal iommu_map().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
___
ath10k mailing
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
> __domain_mapping().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
___
ath10k mailing list
On 12/22/2022 8:42 PM, Youghandhar Chintala wrote:
...
+static void ath10k_mac_beacon_notifier(struct wiphy *wiphy)
+{
+ struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+ struct ath10k *ar = hw->priv;
+
+ if (ath10k_update_channel_list(ar))
+
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Change the sg_alloc_table_from_pages() allocation that was hardwired to
> GFP_KERNEL to use the gfp parameter like the other allocations in this
> function.
>
> Auditing says this is never called from an atomic context, so
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> This is eventually called by iommufd through intel_iommu_map_pages() and
> it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> iommufd follows the same design as KVM and uses memory cgroups to limit
> the amount of kernel memory a iommufd file descriptor can pin down. The
> various internal data structures already use GFP_KERNEL_ACCOUNT.
>
>
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> These contexts are sleepable, so use the proper annotation. The
> GFP_ATOMIC
> was added mechanically in the prior patches.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
On 1/19/2023 7:56 AM, Wen Gong wrote:
On 12/22/2022 8:42 PM, Youghandhar Chintala wrote:
...
+static void ath10k_mac_beacon_notifier(struct wiphy *wiphy)
+{
+ struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+ struct ath10k *ar = hw->priv;
+
+ if
27 matches
Mail list logo
