- Linuxarm - mailweb.openeuler.org

[PATCH v6] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 10 Jun '21

10 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Changes since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) use err_info->length instead of err_info++' 3) some coding style advice. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 81 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..0c8330e 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,56 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + bool queued = false; + int sec_sev, i; + char *p; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + p = (char *)(err + 1); + for (i = 0; i < err->err_info_num; i++) { + struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + p += err_info->length; + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + p += err_info->length; + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +654,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

2 2

Re: [PATCH RESEND iproute2-next] devlink: Add optional controller user input
by Yunsheng Lin 09 Jun '21

09 Jun '21

On 2021/6/7 14:10, Parav Pandit wrote: >> From: Yunsheng Lin <linyunsheng(a)huawei.com> >> Sent: Monday, June 7, 2021 9:01 AM >> >> On 2021/6/6 15:10, Parav Pandit wrote: >>> Hi Yunsheng, >>> >>>> From: Yunsheng Lin <linyunsheng(a)huawei.com> >>>> Sent: Friday, June 4, 2021 7:05 AM >>>> >>>> On 2021/6/3 19:19, Parav Pandit wrote: >>>>> A user optionally provides the external controller number when user >>>>> wants to create devlink port for the external controller. >>>> >>>> Hi, Parav >>>> I was planing to use controller id to solve the devlink instance >>>> representing problem for multi-function which shares common resource >>>> in the same ASIC, see [1]. >>>> >>>> It seems the controller id used here is to differentiate the function >>>> used in different host? >>>> >>> That’s correct. Controller holds one or more PCI functions (PF,VF,SF). >> >> I am not sure I understand the exact usage of controller and why controller id >> is in "devlink_port_*_attrs". >> >> Let's consider a simplified case where there is two PF(supposing both have >> VF enabled), and each PF has different controller and each PF corresponds to >> a different physical port(Or it is about multi-host case multi PF may sharing >> the same physical port?): > Typically single host with two PFs have their own physical ports. > Multi-host with two PFs, on each host they share respective physical ports. > > Single host: > Pf0.physical_port = p0 > Pf1.physical_port = p1. > > Multi-host (two) host setup > H1.pf0.phyical_port = p0. > H1.pf1.phyical_port = p1. > H2.pf0.phyical_port = p0. > H2.pf1.phyical_port = p1. Multi-host (two) host setup with separate physical port for each host: H1.pf0.phyical_port = p0 H2.pf0.phyical_port = p1 Does above use case make sense for mlx, it seems a common case for our internal use. > >> 1. I suppose each PF has it's devlink instance for mlx case(I suppose each >> VF can not have it's own devlink instance for VF shares the same physical >> port with PF, right?). > VF and SF ports are of flavour VIRTUAL. Which devlink instance does the flavour VIRTUAL port instance for VF and SF is registered to? Does it mean VF has it's own devlink instance in VM when it is passed a VM, and flavour VIRTUAL port instance for that VF is registered to that devlink instance in the VM too？ Even in the same host as PF, the VF also has it's own devlink instance? > >> 2. each PF's devlink instance has three types of port, which is >> FLAVOUR_PHYSICAL, FLAVOUR_PCI_PF and FLAVOUR_PCI_VF(supposing I >> understand >> port flavour correctly). >> > FLAVOUR_PCI_{PF,VF,SF} belongs to eswitch (representor) side on switchdev device. If devlink instance or eswitch is in DEVLINK_ESWITCH_MODE_LEGACY mode, the FLAVOUR_PCI_{PF,VF,SF} port instance does not need to created? > >> If I understand above correctly, all ports in the same devlink instance should >> have the same controller id, right? If yes, why not put the controller id in the >> devlink instance? > Need not be. All PCI_{PF,VF,SF} can have controller id different for different controllers. The point is that two VF from different PF may be in the different host, all VF of a specific PF need to be in the same host, right? otherwise it may break PCI enumeration process? If yes, as PCI_{PF,VF,SF} belongs to eswitch (representor) side on switchdev device(which means PCI_{PF,VF,SF} port instance is in the same host, as the host corresponding to "controller_num=0" in diagram [1]), so it seems all the PCI_{PF,VF,SF} of a specific PF should have the same controller id, and using a controller id of the devlink instance in "controller_num=0" in diagram [1] seems enough? > Usually each multi-host is a different controller. > Refer to this diagram [1] and detailed description. devlink instance does not exist in the host corresponding to "controller_num=1" in diagram [1]? Or devlink instance does exist in the host corresponding to "controller_num=1", but the mode of that devlink instance is DEVLINK_ESWITCH_MODE_LEGACY in diagram [1]? Also, eswitch mode can only be set on the devlink instance corresponding to PF, but not for VF/SF(supposing that VF/SF could have it's own devlink instance too), right? > >> >>> In your case if there is single devlink instance representing ASIC, it is better >> to have health reporters under this single instance. >>> >>> Devlink parameters do not span multiple devlink instance. >> >> Yes, that is what I try to do: shared status/parameters in devlink instance, >> physical port specific status/parameters in devlink port instance. >> >>> So if you need to control devlink instance parameters of each function >> byitself, you likely need devlink instance for each. >>> And still continue to have ASIC wide health reporters under single instance >> that represents whole ASIC. >> >> I do not think each function need a devlink instance if there is a devlink >> instance representing a whole ASIC, using the devlink port instance to >> represent the function seems enough? > 'devlink port function's is equivalent of hypervisor/nicvisor entity controlled by the network/sysadmin. > While devlink instance of a given PF,VF,SF is managed by the user of such function itself. 'devlink port function' means "struct devlink_port", right? It seems 'devlink port function' in the host is representing a VF when devlink instance of that VF is in the VM? > For example when a VF is mapped to a VM, devlink instance of this VF resides in the VM managed by the guest VM. Does the user in VM really care about devlink info or configuration when network/sysadmin has configured the VF through 'devlink port function' in the host? which devlink info or configuration does user need to query or configure in a VM? > > Before this VF is given to VM, usually hypervisor/nicvisor admin programs this function (such as mac address) explained in [3]. > So that a given VM always gets the same mac address regardless of which VF {a or b). > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > >> >>> >>>> 1. https://lkml.org/lkml/2021/5/31/296 >

2 9

[PATCH 0/4] Free cached iovas when rmmod the driver of the last device in group
by chenxiang 08 Jun '21

08 Jun '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> When rmmod the driver of the last device in the group, cached iovas are not used, and it is better to free them to save memories. And also export function free_rcache_cached_iovas() and iommu_domain_to_iova(). Xiang Chen (4): iommu/iova: add a function to free all rcached iovas and export it iommu/iova: use function free_rcache_cached_iovas() to free all rcached iovas dma-iommu: add a interface to get iova_domain from iommu domain iommu: free cached iovas when rmmod the driver of the last device in the group drivers/iommu/dma-iommu.c | 7 +++++++ drivers/iommu/iommu.c | 7 +++++++ drivers/iommu/iova.c | 17 ++++++++++++----- include/linux/dma-iommu.h | 6 ++++++ include/linux/iova.h | 5 +++++ 5 files changed, 37 insertions(+), 5 deletions(-) -- 2.8.1

3 7

[PATCH v6] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 08 Jun '21

08 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Changes since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) use err_info->length instead of err_info++' 3) some coding style advice. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 81 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..0c8330e 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,56 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + bool queued = false; + int sec_sev, i; + char *p; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + p = (char *)(err + 1); + for (i = 0; i < err->err_info_num; i++) { + struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + p += err_info->length; + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + p += err_info->length; + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +654,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

1 0

[PATCH v6 1/1] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 08 Jun '21

08 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Chnages since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) check error info length 3) some coding style advices. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 85 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 68 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..da25870 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,60 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + struct cper_arm_err_info *err_info; + bool queued = false; + int sec_sev, i; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + err_info = (struct cper_arm_err_info *)(err + 1); + for (i = 0; i < err->err_info_num; i++, err_info++) { + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + if (err_info->length != sizeof(struct cper_arm_err_info)) { + pr_warn_ratelimited(FW_WARN GHES_PFX + "Error info length %d is invalid\n", + err_info->length); + break; + } + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +658,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

2 2

[RESEND PATCH v3] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by chenxiang 04 Jun '21

04 Jun '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> It is not necessary to put free_iova_mem() inside of spinlock/unlock iova_rbtree_lock which only leads to more completion for the spinlock. It has a small promote on the performance after the change. And also rename private_free_iova() as remove_iova() because the function will not free iova after that change. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> Reviewed-by: John Garry <john.garry(a)huawei.com> --- drivers/iommu/iova.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index b7ecd5b..b6cf5f1 100644 --- a/drivers/iommu/iova.c +++ b/drivers/iommu/iova.c @@ -412,12 +412,11 @@ private_find_iova(struct iova_domain *iovad, unsigned long pfn) return NULL; } -static void private_free_iova(struct iova_domain *iovad, struct iova *iova) +static void remove_iova(struct iova_domain *iovad, struct iova *iova) { assert_spin_locked(&iovad->iova_rbtree_lock); __cached_rbnode_delete_update(iovad, iova); rb_erase(&iova->node, &iovad->rbroot); - free_iova_mem(iova); } /** @@ -452,8 +451,9 @@ __free_iova(struct iova_domain *iovad, struct iova *iova) unsigned long flags; spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); - private_free_iova(iovad, iova); + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(__free_iova); @@ -472,10 +472,13 @@ free_iova(struct iova_domain *iovad, unsigned long pfn) spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); iova = private_find_iova(iovad, pfn); - if (iova) - private_free_iova(iovad, iova); + if (!iova) { + spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); + return; + } + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); - + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(free_iova); @@ -825,7 +828,8 @@ iova_magazine_free_pfns(struct iova_magazine *mag, struct iova_domain *iovad) if (WARN_ON(!iova)) continue; - private_free_iova(iovad, iova); + remove_iova(iovad, iova); + free_iova_mem(iova); } spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); -- 2.8.1

3 2

[PATCH net-next 0/3] Some optimization for lockless qdisc
by Yunsheng Lin 03 Jun '21

03 Jun '21

Patch 1: remove unnecessary seqcount operation. Patch 2: implement TCQ_F_CAN_BYPASS. Patch 3: remove qdisc->empty. Performance data for pktgen in queue_xmit mode + dummy netdev with pfifo_fast: threads unpatched patched delta 1 2.60Mpps 3.21Mpps +23% 2 3.84Mpps 5.56Mpps +44% 4 5.52Mpps 5.58Mpps +1% 8 2.77Mpps 2.76Mpps -0.3% 16 2.24Mpps 2.23Mpps +0.4% Performance for IP forward testing: 1.05Mpps increases to 1.16Mpps, about 10% improvement. V1: Drop RFC tag, Add nolock_qdisc_is_empty() and do the qdisc empty checking without the protection of qdisc->seqlock to aviod doing unnecessary spin_trylock() for contention case. RFC v4: Use STATE_MISSED and STATE_DRAINING to indicate non-empty qdisc, and add patch 1 and 3. Yunsheng Lin (3): net: sched: avoid unnecessary seqcount operation for lockless qdisc net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc net: sched: remove qdisc->empty for lockless qdisc include/net/sch_generic.h | 31 ++++++++++++++++++------------- net/core/dev.c | 26 ++++++++++++++++++++++++-- net/sched/sch_generic.c | 23 ++++++++++++++++------- 3 files changed, 58 insertions(+), 22 deletions(-) -- 2.7.4

3 18

[PATCH v2 0/3] use bin_attribute to avoid buff overflow
by Tian Tao 02 Jun '21

02 Jun '21

patch #1 adds a new function cpumap_print_to_buf and patch #2 uses this function in drivers/base/topology.c, and patch #3 uses this new function in drivers/base/node.c. v2: split the original patch #1 into two patches and use kasprintf() in patch #1 to simplify the code. do some minor formatting adjustments Tian Tao (3): lib: bitmap: introduce bitmap_print_to_buf topology: use bin_attribute to avoid buff overflow drivers/base/node.c: use bin_attribute to avoid buff overflow drivers/base/node.c | 52 ++++++++++++++-------- drivers/base/topology.c | 115 ++++++++++++++++++++++++++---------------------- include/linux/bitmap.h | 3 ++ include/linux/cpumask.h | 21 +++++++++ lib/bitmap.c | 38 +++++++++++++++- 5 files changed, 157 insertions(+), 72 deletions(-) -- 2.7.4

2 4

[RFC v2 plinth/topic-sas-5.12 0/6] Add support for IOMMU debugfs related to
by chenxiang 02 Jun '21

02 Jun '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> The first patch is to release those rcache when rmmod the driver of the last device to save memory. And patch2~6 is add support for IOMMU debugfs related to IOVA as follows: /sys/kernel/debug/iommu/iovad/iommu_domainx Under iommu_domainx dir, add debugfs file iova_rcache and drop_rcache. From debugfs file iova_rcache, we can get how many cpu_rcache / share rcache / iovas are used, and also we can drop those rcache by debugfs file drop_rcache: For cpu_rcache, [i]=x|y indicates that there are x iova in load iova_magazine and y iova in prev iova_magazine (128 at most). For share rcache, [i]=x indicates that there are x iova_magazines in use. estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ cat iova_rcache [ 272.814457] cpu0 [0]=60|0 [1]=7|0 [2]=32|0 [3]=0|0 [4]=97|0 [5]=104|0 [ 272.820982] cpu1 [0]=0|0 [1]=3|0 [2]=14|0 [3]=76|0 [4]=15|0 [5]=64|0 [ 272.827399] cpu2 [0]=85|128 [1]=84|128 [2]=83|128 [3]=112|128 [4]=22|128 [5]=116|128 [ 272.835197] cpu3 [0]=0|0 [1]=91|0 [2]=101|0 [3]=29|0 [4]=0|0 [5]=36|0 [ 272.841699] cpu4 [0]=0|0 [1]=39|0 [2]=113|0 [3]=75|0 [4]=95|0 [5]=0|0 [ 272.848201] cpu5 [0]=27|0 [1]=48|0 [2]=82|0 [3]=0|0 [4]=19|0 [5]=36|0 [ 272.854702] cpu6 [0]=30|0 [1]=0|0 [2]=48|0 [3]=2|0 [4]=18|0 [5]=56|0 [ 272.861117] cpu7 [0]=27|0 [1]=89|0 [2]=101|0 [3]=59|0 [4]=28|0 [5]=0|0 [ 272.867706] cpu8 [0]=66|0 [1]=114|0 [2]=42|0 [3]=123|0 [4]=96|0 [5]=68|0 [ 272.874466] cpu9 [0]=71|0 [1]=61|0 [2]=28|0 [3]=118|0 [4]=116|0 [5]=41|0 [ 272.881227] cpu10 [0]=83|128 [1]=63|128 [2]=109|128 [3]=79|128 [4]=7|128 [5]=54|128 [ 272.888938] cpu11 [0]=90|0 [1]=34|0 [2]=88|0 [3]=58|0 [4]=20|0 [5]=35|0 [ 272.895611] cpu12 [0]=64|0 [1]=20|0 [2]=18|0 [3]=33|0 [4]=42|0 [5]=22|0 [ 272.902285] cpu13 [0]=17|0 [1]=70|0 [2]=115|0 [3]=59|0 [4]=108|0 [5]=58|0 [ 272.909132] cpu14 [0]=28|0 [1]=18|0 [2]=27|0 [3]=105|0 [4]=65|0 [5]=81|0 [ 272.915892] cpu15 [0]=75|0 [1]=3|0 [2]=73|0 [3]=104|0 [4]=127|0 [5]=102|0 [ 272.922738] cpu16 [0]=54|0 [1]=116|0 [2]=90|0 [3]=31|0 [4]=108|0 [5]=41|0 [ 272.929590] cpu17 [0]=47|0 [1]=82|0 [2]=3|0 [3]=66|0 [4]=68|0 [5]=66|0 [ 272.936179] cpu18 [0]=126|128 [1]=110|128 [2]=48|128 [3]=118|128 [4]=54|128 [5]=73|128 [ 272.944156] cpu19 [0]=31|0 [1]=13|0 [2]=104|0 [3]=45|0 [4]=108|0 [5]=96|0 [ 272.951006] cpu20 [0]=58|0 [1]=113|0 [2]=14|0 [3]=123|0 [4]=52|0 [5]=54|0 [ 272.957856] cpu21 [0]=116|0 [1]=47|0 [2]=96|0 [3]=60|0 [4]=47|0 [5]=126|0 [ 272.964701] cpu22 [0]=84|0 [1]=87|0 [2]=88|0 [3]=68|0 [4]=37|0 [5]=119|0 [ 272.971462] cpu23 [0]=13|0 [1]=63|0 [2]=124|0 [3]=3|0 [4]=7|0 [5]=38|0 [ 272.978051] cpu24 [0]=15|0 [1]=64|0 [2]=65|0 [3]=53|0 [4]=102|0 [5]=69|0 [ 272.984812] cpu25 [0]=94|0 [1]=108|0 [2]=67|0 [3]=125|0 [4]=107|0 [5]=8|0 [ 272.991663] cpu26 [0]=84|128 [1]=86|128 [2]=91|128 [3]=121|128 [4]=77|128 [5]=25|128 [ 272.999464] cpu27 [0]=60|0 [1]=105|0 [2]=61|0 [3]=91|0 [4]=79|0 [5]=6|0 [ 273.006141] cpu28 [0]=39|0 [1]=91|0 [2]=11|0 [3]=87|0 [4]=112|0 [5]=10|0 [ 273.012904] cpu29 [0]=88|0 [1]=43|0 [2]=0|0 [3]=77|0 [4]=10|0 [5]=79|0 [ 273.019492] cpu30 [0]=65|0 [1]=24|0 [2]=125|0 [3]=24|0 [4]=54|0 [5]=21|0 [ 273.026254] cpu31 [0]=26|0 [1]=90|0 [2]=42|0 [3]=17|0 [4]=73|0 [5]=35|0 [ 273.032929] cpu32 [0]=1|0 [1]=83|0 [2]=76|0 [3]=62|0 [4]=117|0 [5]=96|0 [ 273.039612] cpu33 [0]=50|0 [1]=55|0 [2]=63|0 [3]=79|0 [4]=86|0 [5]=15|0 [ 273.046293] cpu34 [0]=122|128 [1]=36|128 [2]=36|128 [3]=79|128 [4]=113|128 [5]=80|128 [ 273.054179] cpu35 [0]=101|0 [1]=18|0 [2]=7|0 [3]=10|0 [4]=7|0 [5]=112|0 [ 273.060854] cpu36 [0]=12|0 [1]=107|0 [2]=43|0 [3]=60|0 [4]=19|0 [5]=110|0 [ 273.067703] cpu37 [0]=90|0 [1]=34|0 [2]=66|0 [3]=91|0 [4]=85|0 [5]=31|0 [ 273.074378] cpu38 [0]=0|0 [1]=22|0 [2]=18|0 [3]=73|0 [4]=54|0 [5]=96|0 [ 273.080968] cpu39 [0]=109|0 [1]=54|0 [2]=124|0 [3]=21|0 [4]=88|0 [5]=61|0 [ 273.087816] cpu40 [0]=95|0 [1]=50|0 [2]=45|0 [3]=66|0 [4]=30|0 [5]=84|0 [ 273.094490] cpu41 [0]=99|0 [1]=47|0 [2]=8|0 [3]=81|0 [4]=0|0 [5]=95|0 [ 273.100992] cpu42 [0]=25|128 [1]=92|128 [2]=53|128 [3]=49|128 [4]=43|128 [5]=78|128 [ 273.108704] cpu43 [0]=88|0 [1]=42|0 [2]=10|0 [3]=124|0 [4]=4|0 [5]=105|0 [ 273.115464] cpu44 [0]=80|0 [1]=63|0 [2]=1|0 [3]=123|0 [4]=35|0 [5]=17|0 [ 273.122139] cpu45 [0]=31|0 [1]=92|0 [2]=8|0 [3]=60|0 [4]=74|0 [5]=92|0 [ 273.128727] cpu46 [0]=78|0 [1]=40|0 [2]=95|0 [3]=33|0 [4]=67|0 [5]=63|0 [ 273.135401] cpu47 [0]=112|0 [1]=93|0 [2]=96|0 [3]=24|0 [4]=93|0 [5]=15|0 [ 273.142162] cpu48 [0]=92|0 [1]=120|0 [2]=49|0 [3]=118|0 [4]=1|0 [5]=83|0 [ 273.148923] cpu49 [0]=101|0 [1]=7|0 [2]=108|0 [3]=15|0 [4]=69|0 [5]=116|0 [ 273.155771] cpu50 [0]=111|128 [1]=98|128 [2]=21|128 [3]=27|128 [4]=109|128 [5]=21|128 [ 273.163655] cpu51 [0]=31|0 [1]=33|0 [2]=82|0 [3]=117|0 [4]=98|0 [5]=1|0 [ 273.170329] cpu52 [0]=113|0 [1]=64|0 [2]=16|0 [3]=48|0 [4]=97|0 [5]=80|0 [ 273.177090] cpu53 [0]=95|0 [1]=39|0 [2]=26|0 [3]=107|0 [4]=2|0 [5]=18|0 [ 273.183764] cpu54 [0]=114|0 [1]=94|0 [2]=110|0 [3]=85|0 [4]=66|0 [5]=45|0 [ 273.190611] cpu55 [0]=52|0 [1]=89|0 [2]=43|0 [3]=117|0 [4]=115|0 [5]=91|0 [ 273.197460] cpu56 [0]=0|0 [1]=51|0 [2]=81|0 [3]=60|0 [4]=20|0 [5]=27|0 [ 273.204048] cpu57 [0]=124|0 [1]=121|0 [2]=56|0 [3]=0|0 [4]=77|0 [5]=59|0 [ 273.210807] cpu58 [0]=109|128 [1]=98|128 [2]=6|128 [3]=39|128 [4]=64|128 [5]=24|128 [ 273.218518] cpu59 [0]=57|0 [1]=62|0 [2]=66|0 [3]=55|0 [4]=95|0 [5]=47|0 [ 273.225192] cpu60 [0]=29|0 [1]=12|0 [2]=112|0 [3]=23|0 [4]=65|0 [5]=34|0 [ 273.231955] cpu61 [0]=92|0 [1]=5|0 [2]=19|0 [3]=91|0 [4]=101|0 [5]=97|0 [ 273.238629] cpu62 [0]=97|0 [1]=42|0 [2]=30|0 [3]=111|0 [4]=99|0 [5]=2|0 [ 273.245304] cpu63 [0]=77|0 [1]=79|0 [2]=62|0 [3]=56|0 [4]=17|0 [5]=76|0 [ 273.251982] cpu64 [0]=0|0 [1]=108|0 [2]=87|0 [3]=58|0 [4]=26|0 [5]=0|0 [ 273.258582] cpu65 [0]=0|0 [1]=114|0 [2]=99|0 [3]=73|0 [4]=33|0 [5]=0|0 [ 273.265174] cpu66 [0]=39|128 [1]=52|128 [2]=82|128 [3]=107|128 [4]=73|128 [5]=13|128 [ 273.272974] cpu67 [0]=0|0 [1]=123|0 [2]=87|0 [3]=49|0 [4]=27|0 [5]=98|0 [ 273.279651] cpu68 [0]=108|0 [1]=0|0 [2]=123|0 [3]=47|0 [4]=30|0 [5]=109|0 [ 273.286500] cpu69 [0]=92|0 [1]=110|0 [2]=92|0 [3]=59|0 [4]=42|0 [5]=104|0 [ 273.293351] cpu70 [0]=105|0 [1]=106|0 [2]=99|0 [3]=57|0 [4]=15|0 [5]=111|0 [ 273.300287] cpu71 [0]=106|0 [1]=108|0 [2]=108|0 [3]=58|0 [4]=35|0 [5]=98|0 [ 273.307222] cpu72 [0]=0|0 [1]=0|0 [2]=114|0 [3]=118|0 [4]=95|0 [5]=0|0 [ 273.313813] cpu73 [0]=0|0 [1]=0|0 [2]=0|0 [3]=98|0 [4]=95|0 [5]=124|0 [ 273.320318] cpu74 [0]=65|0 [1]=76|0 [2]=109|0 [3]=58|128 [4]=115|128 [5]=105|0 [ 273.327603] cpu75 [0]=0|0 [1]=0|0 [2]=123|0 [3]=102|0 [4]=109|0 [5]=0|0 [ 273.334279] cpu76 [0]=125|0 [1]=0|0 [2]=0|0 [3]=101|0 [4]=112|0 [5]=0|0 [ 273.340954] cpu77 [0]=124|0 [1]=124|0 [2]=0|0 [3]=103|0 [4]=100|0 [5]=0|0 [ 273.347803] cpu78 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=118|0 [5]=0|0 [ 273.354134] cpu79 [0]=124|0 [1]=0|0 [2]=116|0 [3]=104|0 [4]=120|0 [5]=0|0 [ 273.360981] cpu80 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.367138] cpu81 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.373292] cpu82 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.379447] cpu83 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.385601] cpu84 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.391755] cpu85 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.397910] cpu86 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.404065] cpu87 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.410220] cpu88 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.416376] cpu89 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.422532] cpu90 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.428687] cpu91 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.434841] cpu92 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.440997] cpu93 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.447152] cpu94 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.453311] cpu95 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.459468] cpu96 [0]=78|0 [1]=95|0 [2]=117|0 [3]=120|0 [4]=37|0 [5]=31|0 [ 273.466317] cpu97 [0]=105|0 [1]=99|0 [2]=37|0 [3]=24|0 [4]=86|0 [5]=39|0 [ 273.473080] cpu98 [0]=37|128 [1]=13|128 [2]=102|128 [3]=124|128 [4]=60|128 [5]=36|128 [ 273.480967] cpu99 [0]=69|0 [1]=12|0 [2]=84|0 [3]=49|0 [4]=108|0 [5]=127|0 [ 273.487818] cpu100 [0]=92|0 [1]=104|0 [2]=22|0 [3]=31|0 [4]=2|0 [5]=72|0 [ 273.494581] cpu101 [0]=0|0 [1]=31|0 [2]=44|0 [3]=8|0 [4]=13|0 [5]=50|0 [ 273.501170] cpu102 [0]=79|0 [1]=14|0 [2]=88|0 [3]=53|0 [4]=7|0 [5]=44|0 [ 273.507846] cpu103 [0]=10|0 [1]=117|0 [2]=53|0 [3]=112|0 [4]=11|0 [5]=71|0 [ 273.514781] cpu104 [0]=123|0 [1]=30|0 [2]=9|0 [3]=2|0 [4]=30|0 [5]=24|0 [ 273.521462] cpu105 [0]=116|0 [1]=44|0 [2]=29|0 [3]=104|0 [4]=71|0 [5]=3|0 [ 273.528309] cpu106 [0]=38|128 [1]=127|128 [2]=21|128 [3]=83|128 [4]=59|128 [5]=81|128 [ 273.536195] cpu107 [0]=127|0 [1]=126|0 [2]=125|0 [3]=79|0 [4]=12|0 [5]=115|0 [ 273.543303] cpu108 [0]=0|0 [1]=43|0 [2]=111|0 [3]=10|0 [4]=51|0 [5]=68|0 [ 273.550065] cpu109 [0]=37|0 [1]=63|0 [2]=11|0 [3]=10|0 [4]=58|0 [5]=9|0 [ 273.556742] cpu110 [0]=86|0 [1]=44|0 [2]=83|0 [3]=85|0 [4]=82|0 [5]=119|0 [ 273.563590] cpu111 [0]=114|0 [1]=27|0 [2]=111|0 [3]=11|0 [4]=45|0 [5]=56|0 [ 273.570524] cpu112 [0]=74|0 [1]=86|0 [2]=93|0 [3]=122|0 [4]=126|0 [5]=31|0 [ 273.577458] cpu113 [0]=51|0 [1]=81|0 [2]=7|0 [3]=124|0 [4]=71|0 [5]=5|0 [ 273.584133] cpu114 [0]=58|128 [1]=95|128 [2]=14|128 [3]=119|128 [4]=85|128 [5]=23|128 [ 273.592018] cpu115 [0]=59|0 [1]=66|0 [2]=1|0 [3]=50|0 [4]=77|0 [5]=6|0 [ 273.598607] cpu116 [0]=65|0 [1]=81|0 [2]=22|0 [3]=18|0 [4]=96|0 [5]=2|0 [ 273.605282] cpu117 [0]=23|0 [1]=41|0 [2]=19|0 [3]=69|0 [4]=108|0 [5]=126|0 [ 273.612216] cpu118 [0]=74|0 [1]=40|0 [2]=0|0 [3]=100|0 [4]=109|0 [5]=7|0 [ 273.618979] cpu119 [0]=47|0 [1]=31|0 [2]=103|0 [3]=65|0 [4]=84|0 [5]=124|0 [ 273.625914] cpu120 [0]=74|0 [1]=18|0 [2]=87|0 [3]=117|0 [4]=17|0 [5]=62|0 [ 273.632762] cpu121 [0]=64|0 [1]=73|0 [2]=3|0 [3]=127|0 [4]=120|0 [5]=105|0 [ 273.639698] cpu122 [0]=46|128 [1]=89|128 [2]=22|128 [3]=78|128 [4]=100|128 [5]=106|128 [ 273.647671] cpu123 [0]=36|0 [1]=71|0 [2]=25|0 [3]=23|0 [4]=126|0 [5]=86|0 [ 273.654521] cpu124 [0]=26|0 [1]=93|0 [2]=101|0 [3]=103|0 [4]=54|0 [5]=100|0 [ 273.661542] cpu125 [0]=58|0 [1]=57|0 [2]=116|0 [3]=35|0 [4]=73|0 [5]=12|0 [ 273.668392] cpu126 [0]=11|0 [1]=54|0 [2]=41|0 [3]=0|0 [4]=27|0 [5]=54|0 [ 273.675067] cpu127 [0]=70|0 [1]=38|0 [2]=58|0 [3]=123|0 [4]=47|0 [5]=21|0 [ 273.681913] share cache: [0]=0 [1]=4 [2]=9 [3]=3 [4]=6 [5]=5 [ 273.687633] rb_total: 59443 estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ echo 1 > drop_rca che estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ cat iova_rcache [ 295.489690] cpu0 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.495786] cpu1 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.501861] cpu2 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.507929] cpu3 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.514004] cpu4 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.520074] cpu5 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.526142] cpu6 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.532212] cpu7 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.538287] cpu8 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.544355] cpu9 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.550423] cpu10 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.556581] cpu11 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.562739] cpu12 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.568897] cpu13 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.575054] cpu14 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.581209] cpu15 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.587368] cpu16 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.593525] cpu17 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.599680] cpu18 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.605837] cpu19 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.611999] cpu20 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.618159] cpu21 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.624313] cpu22 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.630467] cpu23 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.636624] cpu24 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.642779] cpu25 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.648933] cpu26 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.655088] cpu27 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.661241] cpu28 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.667396] cpu29 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.673549] cpu30 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.679703] cpu31 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.685857] cpu32 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.692010] cpu33 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.698165] cpu34 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.704319] cpu35 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.710474] cpu36 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.716628] cpu37 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.722782] cpu38 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.728936] cpu39 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.735091] cpu40 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.741246] cpu41 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.747400] cpu42 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.753553] cpu43 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.759707] cpu44 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.765860] cpu45 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.772014] cpu46 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.778168] cpu47 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.784322] cpu48 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.790476] cpu49 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.796632] cpu50 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.802786] cpu51 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.808941] cpu52 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.815095] cpu53 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.821250] cpu54 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.827405] cpu55 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.833561] cpu56 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.839716] cpu57 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.845870] cpu58 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.852024] cpu59 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.858181] cpu60 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.864336] cpu61 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.870492] cpu62 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.876646] cpu63 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.882801] cpu64 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.888956] cpu65 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.895109] cpu66 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.901265] cpu67 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.907419] cpu68 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.913574] cpu69 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.919729] cpu70 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.925882] cpu71 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.932037] cpu72 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.938191] cpu73 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.944345] cpu74 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.950499] cpu75 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.956653] cpu76 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.962807] cpu77 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.968961] cpu78 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.975115] cpu79 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.981269] cpu80 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.987423] cpu81 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.993578] cpu82 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.999731] cpu83 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.005885] cpu84 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.012040] cpu85 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.018196] cpu86 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.024350] cpu87 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.030504] cpu88 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.036659] cpu89 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.042814] cpu90 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.048968] cpu91 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.055122] cpu92 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.061275] cpu93 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.067429] cpu94 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.073582] cpu95 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.079736] cpu96 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.085890] cpu97 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.092043] cpu98 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.098198] cpu99 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.104352] cpu100 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.110593] cpu101 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.116834] cpu102 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.123076] cpu103 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.129315] cpu104 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.135555] cpu105 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.141795] cpu106 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.148035] cpu107 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.154275] cpu108 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.160515] cpu109 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.166757] cpu110 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.172997] cpu111 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.179237] cpu112 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.185477] cpu113 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.191717] cpu114 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.197958] cpu115 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.204198] cpu116 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.210438] cpu117 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.216677] cpu118 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.222917] cpu119 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.229157] cpu120 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.235398] cpu121 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.241638] cpu122 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.247879] cpu123 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.254121] cpu124 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.260361] cpu125 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.266601] cpu126 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.272843] cpu127 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.279083] share cache: [0]=0 [1]=0 [2]=0 [3]=0 [4]=0 [5]=0 [ 296.284804] rb_total: 4134 estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ We can add more debugfs interfaces if we want to. c00284940 (6): {topost} iommu: free rcache iovas when rmmod the driver of the last device {topost} iommu/iova: create iovad debugfs dir under iommu debugfs dir {topost} iommu/iova: create iommu domain debugfs dir under iovad debugfs dir {topost} iommu/iova: create debugfs file related to iova {topost} iommu/iova: trace how many iovas are in use {topost} iommu/iova: add a debugfs file drop_rcache to drop rcache drivers/iommu/dma-iommu.c | 9 +++++ drivers/iommu/iommu-debugfs.c | 93 +++++++++++++++++++++++++++++++++++++++++++ drivers/iommu/iommu.c | 26 +++++------- drivers/iommu/iova.c | 43 ++++++++------------ include/linux/dma-iommu.h | 6 ++- include/linux/iommu.h | 32 ++++++++++++++- include/linux/iova.h | 29 +++++++++++++- 7 files changed, 193 insertions(+), 45 deletions(-) -- 2.8.1

3 10

[PATCH] libata: configure max sectors properly
by chenxiang 31 May '21

31 May '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Max sectors of limitations for scsi host can be set through scsi_host_template->max_sectors in scsi driver. But we find that max sectors may exceed scsi_host_template->max_sectors for SATA disk even if we set it. We find that it may be overwrote in some scsi drivers (which calls the callback slave_configure and also calls function ata_scsi_dev_config in it). The invoking relationship is as follows: scsi_probe_and_add_lun ... scsi_alloc_sdev scsi_mq_alloc_queue ... __scsi_init_queue blk_queue_max_hw_sectors(q, shost->max_sectors) //max_sectors coming from sht->max_sectors scsi_change_queue_depth scsi_sysfs_device_initialize shost->hostt->slave_alloc() xxx_salve_configure ... ata_scsi_dev_config blk_queue_max_hw_sectors(q, dev->max_sectors) //max_sectors is overwrote by dev->max_sectors To avoid the issue, set q->limits.max_sectors with the minimum value between dev->max_sectors and q->limits.max_sectors. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/ata/libata-scsi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 48b8934..fb7b243 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1026,12 +1026,15 @@ EXPORT_SYMBOL_GPL(ata_scsi_dma_need_drain); int ata_scsi_dev_config(struct scsi_device *sdev, struct ata_device *dev) { struct request_queue *q = sdev->request_queue; + unsigned int max_sectors; if (!ata_id_has_unload(dev->id)) dev->flags |= ATA_DFLAG_NO_UNLOAD; /* configure max sectors */ - blk_queue_max_hw_sectors(q, dev->max_sectors); + max_sectors = min_t(unsigned int, dev->max_sectors, + q->limits.max_sectors); + blk_queue_max_hw_sectors(q, max_sectors); if (dev->class == ATA_DEV_ATAPI) { sdev->sector_size = ATA_SECT_SIZE; -- 2.8.1

3 2