- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] soc: hisilicon: hisi_hbmdev: Add hbm acls repair and query methods
by Zhang Zekun 03 Nov '23

03 Nov '23

Offering: HULK hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I8CCP5 ---------------------------------- Hbm memory device add support for acls hot repair. The patch add two methods for userpace: - query a paddr if it support acls repair - repair a paddr in hbm memory device The feature of ACLS hot repair can help to fix a memory error from userspace by passing through the error physical address to HBM hardware. Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/soc/hisilicon/Kconfig | 10 +++ drivers/soc/hisilicon/hisi_hbmdev.c | 134 ++++++++++++++++++++++++++++ 2 files changed, 144 insertions(+) diff --git a/drivers/soc/hisilicon/Kconfig b/drivers/soc/hisilicon/Kconfig index 383375f20cac..45754528873e 100644 --- a/drivers/soc/hisilicon/Kconfig +++ b/drivers/soc/hisilicon/Kconfig @@ -44,4 +44,14 @@ config HISI_HBMCACHE To compile the driver as a module, choose M here: the module will be called hisi_hbmcache. +config HISI_HBMDEV_ACLS + bool "Add support for HISI ACLS repair" + depends on HISI_HBMDEV + help + Add ACLS support for hbm device, which can be used to query and + repair hardware error in HBM devices. This feature need to work with + hardware firmwares. + + If not sure say no. + endmenu diff --git a/drivers/soc/hisilicon/hisi_hbmdev.c b/drivers/soc/hisilicon/hisi_hbmdev.c index 5b6b1618148c..5cde7a123033 100644 --- a/drivers/soc/hisilicon/hisi_hbmdev.c +++ b/drivers/soc/hisilicon/hisi_hbmdev.c @@ -26,6 +26,9 @@ struct memory_dev { struct kobject *memdev_kobj; struct kobject *topo_kobj; struct cdev_node cdev_list; +#ifdef CONFIG_HISI_HBMDEV_ACLS + struct kobject *acls_kobj; +#endif nodemask_t cluster_cpumask[MAX_NUMNODES]; }; @@ -85,6 +88,131 @@ static void memory_topo_init(void) kobject_put(mdev->topo_kobj); } +#ifdef CONFIG_HISI_HBMDEV_ACLS +static struct acpi_device* paddr_to_acpi_device(u64 paddr) +{ + int nid; + u64 pfn; + + pfn = __phys_to_pfn(paddr); + if (!pfn_valid(pfn)) + return NULL; + + nid = pfn_to_nid(pfn); + if (nid < 0 && nid >= MAX_NUMNODES) + return NULL; + + return hotplug_mdev[nid]; +} + +static ssize_t acls_query_store(struct kobject *kobj, + struct kobj_attribute *attr, + const char *buf, size_t count) +{ + struct acpi_object_list arg_list; + struct acpi_device *adev; + union acpi_object obj; + acpi_status status; + u64 paddr, res; + + if (kstrtoull(buf, 16, &paddr)) + return -EINVAL; + + adev = paddr_to_acpi_device(paddr); + if (!adev) + return -EINVAL; + + obj.type = ACPI_TYPE_INTEGER; + obj.integer.value = paddr; + arg_list.count = 1; + arg_list.pointer = &obj; + + status = acpi_evaluate_integer(adev->handle, "AQRY", &arg_list, &res); + if (ACPI_FAILURE(status)) + return -ENODEV; + + if (IS_ERR_VALUE(-res)) + return -res; + else if (res) + return -ENODEV; + + return count; +} + +static struct kobj_attribute acls_query_store_attribute = + __ATTR(acls_query, 0200, NULL, acls_query_store); + +static ssize_t acls_repair_store(struct kobject *kobj, + struct kobj_attribute *attr, + const char *buf, size_t count) +{ + struct acpi_object_list arg_list; + struct acpi_device *adev; + union acpi_object obj; + acpi_status status; + u64 paddr, res; + + if (kstrtoull(buf, 16, &paddr)) + return -EINVAL; + + adev = paddr_to_acpi_device(paddr); + if (!adev) + return -EINVAL; + + obj.type = ACPI_TYPE_INTEGER; + obj.integer.value = paddr; + arg_list.count = 1; + arg_list.pointer = &obj; + + status = acpi_evaluate_integer(adev->handle, "AREP", &arg_list, &res); + if (ACPI_FAILURE(status)) + return -ENODEV; + + if (IS_ERR_VALUE(-res)) + return -res; + else if (res) + return -ENODEV; + + return count; +} +static struct kobj_attribute acls_repair_store_attribute = + __ATTR(acls_repair, 0200, NULL, acls_repair_store); + +static struct attribute *acls_attrs[] = { + &acls_query_store_attribute.attr, + &acls_repair_store_attribute.attr, + NULL, +}; + +static struct attribute_group acls_attr_group = { + .attrs = acls_attrs, +}; + +static void acls_init(void) +{ + int ret = -ENOMEM; + + mdev->acls_kobj = kobject_create_and_add("acls", mdev->memdev_kobj); + if (!mdev->acls_kobj) + goto out; + + ret = sysfs_create_group(mdev->acls_kobj, &acls_attr_group); + if (ret) + kobject_put(mdev->acls_kobj); + +out: + if (ret) + pr_err("ACLS hot repair is not enabled\n"); + + return; +} + +static void acls_remove(void) +{ + kobject_put(mdev->acls_kobj); +} +#endif + static int get_pxm(struct acpi_device *acpi_device, void *arg) { acpi_handle handle = acpi_device->handle; @@ -284,6 +412,9 @@ static int __init mdev_init(void) } memory_topo_init(); +#ifdef CONFIG_HISI_HBMDEV_ACLS + acls_init(); +#endif return ret; } module_init(mdev_init); @@ -293,6 +424,9 @@ static void __exit mdev_exit(void) container_remove(); kobject_put(mdev->memdev_kobj); kobject_put(mdev->topo_kobj); +#ifdef CONFIG_HISI_HBMDEV_ACLS + acls_remove(); +#endif kfree(mdev); } module_exit(mdev_exit); -- 2.17.1

2 1

[PATCH OLK-5.10 v2] perf auxtrace ptt: Record whether an auxtrace mmap is needed
by Junhao He 03 Nov '23

03 Nov '23

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7HI80 CVE: NA ---------------------------------------------------------------------- Add a flag needs_auxtrace_mmap to record whether an auxtrace mmap is needed, in preparation for correctly determining whether or not an auxtrace mmap is needed. The change was added in the mainline [1], but it was deleted when upstream openEuler for fixes build error. openEuler OLK-5.10 now has merge evsel->needs_auxtrace_mmap. Therefore, backport this modification to OpenEuler OLK-5.10. [1] commit 057381a7ece1 ("perf auxtrace arm64: Add support for HiSilicon PCIe Tune and Trace device driver") Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- tools/perf/arch/arm64/util/hisi-ptt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/arch/arm64/util/hisi-ptt.c b/tools/perf/arch/arm64/util/hisi-ptt.c index 110b2edf3e6b..97696b6e1dd5 100644 --- a/tools/perf/arch/arm64/util/hisi-ptt.c +++ b/tools/perf/arch/arm64/util/hisi-ptt.c @@ -113,6 +113,7 @@ static int hisi_ptt_recording_options(struct auxtrace_record *itr, } evsel->core.attr.freq = 0; evsel->core.attr.sample_period = 1; + evsel->needs_auxtrace_mmap = true; hisi_ptt_evsel = evsel; opts->full_auxtrace = true; } -- 2.33.0

2 1

[PATCH OLK-5.10 00/13] arm64: Add sysreg header generation scripting
by Junhao He 03 Nov '23

03 Nov '23

The arm64 kernel requires some metadata for each system register it may need to access. Currently we have: * A SYS_<regname> definition which sorresponds to a sys_reg() macro. This is used both to look up a sysreg by encoding (e.g. in KVM), and also to generate code to access a sysreg where the assembler is unaware of the specific sysreg encoding. Where assemblers support the S3_<op1>_C<crn>_C<crm>_<op2> syntax for system registers, we could use this rather than manually assembling the instructions. However, we don't have consistent definitions for these and we currently still need to handle toolchains that lack this feature. * A set of <regname>_<fieldname>_SHIFT and <regname>_<fieldname>_MASK definitions, which can be used to extract fields from the register, or to construct a register from a set of fields. These do not follow the convention used by <linux/bitfield.h>, and the masks are not shifted into place, preventing their use in FIELD_PREP() and FIELD_GET(). We require the SHIFT definitions for inline assembly (and WIDTH definitions would be helpful for UBFX/SBFX), so we cannot only define a shifted MASK. Defining a SHIFT, WIDTH, shifted MASK and unshifted MASK is tedious and error-prone and life is much easier when they can be relied up to exist when writing code. * A set of <regname>_<fieldname>_<valname> definitions for each enumerated value a field may hold. These are used when identifying the presence of features. Atop of this, other code has to build up metadata at runtime (e.g. the sets of RES0/RES1 bits in a register). Alejandro Tafalla (1): arm64/sysreg: Fix typo in Enum element regex James Morse (1): arm64/sysreg: Extend the maximum width of a register and symbol name Marc Zyngier (1): arm64: Allow the definition of UNKNOWN system register fields Mark Brown (6): arm64/sysreg: Enable automatic generation of system register definitions arm64/sysreg: Introduce helpers for access to sysreg fields arm64/sysreg: Add SYS_FIELD_GET() helper arm64/sysreg: Support generation of RAZ fields arm64/sysreg: Allow leading blanks on comments in sysreg file arm64/sysreg: Allow enumerations to be declared as signed or unsigned Mark Rutland (4): arm64: Add sysreg header generation scripting arm64/sysreg: improve comment for regs without fields arm64/sysreg: fix odd line spacing arm64/sysreg: allow *Enum blocks in SysregFields blocks arch/arm64/Makefile | 3 + arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/sysreg.h | 17 ++ arch/arm64/tools/Makefile | 18 ++ arch/arm64/tools/gen-sysreg.awk | 336 ++++++++++++++++++++++++++++++++ arch/arm64/tools/sysreg | 50 +++++ 6 files changed, 426 insertions(+) create mode 100644 arch/arm64/tools/Makefile create mode 100755 arch/arm64/tools/gen-sysreg.awk create mode 100644 arch/arm64/tools/sysreg -- 2.33.0

2 14

[PATCH OLK-5.10] PCI/IOV: Add pci_sriov_numvfs_lock to support enable pci sriov concurrently
by Jialin Zhang 02 Nov '23

02 Nov '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8BLQX CVE: NA -------------------------------- "echo sriov_totalvfs > /sys/bus/pci/devices/$PF_BDF/sriov_numvfs" concurrently may cause the following warnings: Warning 1: sysfs: cannot create duplicate filename '/devices/pci0000:95/0000:95:00.0/pci_bus/0000:97' Call trace: dump_backtrace+0x0/0x200 show_stack+0x20/0x30 dump_stack+0xf0/0x138 sysfs_warn_dup+0x6c/0x90 sysfs_create_dir_ns+0xf8/0x11c create_dir+0x30/0x18c kobject_add_internal+0x5c/0x190 kobject_add+0x98/0x110 device_add+0x100/0x4a0 device_register+0x28/0x40 pci_alloc_child_bus+0x184/0x24c pci_add_new_bus+0x20/0xa4 pci_iov_add_virtfn+0x2a8/0x31c sriov_enable+0x20c/0x4d0 pci_enable_sriov+0x38/0x50 virtio_pci_sriov_configure+0x3c/0xf4 [virtio_pci] sriov_numvfs_store+0xb0/0x1b0 dev_attr_store+0x20/0x34 sysfs_kf_write+0x4c/0x5c kernfs_fop_write_iter+0x130/0x1c0 new_sync_write+0xf0/0x194 vfs_write+0x224/0x2c0 ksys_write+0x74/0x104 __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 The reason is that different VFs may create the same pci bus number and try to add new bus concurrently in virtfn_add_bus. Warning 2: proc_dir_entry 'pci/0000:97' already registered Call trace: proc_register+0x100/0x190 proc_mkdir+0x6c/0xa0 pci_proc_attach_device+0xfc/0x120 pci_bus_add_device+0x40/0xd0 pci_iov_add_virtfn+0x2c8/0x31c sriov_enable+0x20c/0x4d0 pci_enable_sriov+0x38/0x50 virtio_pci_sriov_configure+0x3c/0xf4 [virtio_pci] sriov_numvfs_store+0xb0/0x1b0 dev_attr_store+0x20/0x34 sysfs_kf_write+0x4c/0x5c kernfs_fop_write_iter+0x130/0x1c0 new_sync_write+0xf0/0x194 vfs_write+0x224/0x2c0 ksys_write+0x74/0x104 __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 The reason is that different VFs may create '/proc/bus/pci/bus_number' directory using the same bus number in pci_proc_attach_device concurrently. Mutex lock can avoid potential conflict. With the patch below the warnings above are no longer appear. Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- drivers/pci/iov.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index 4afd4ee4f7f0..958f349345ca 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -16,6 +16,8 @@ #define VIRTFN_ID_LEN 16 +static DEFINE_MUTEX(pci_sriov_numvfs_lock); + int pci_iov_virtfn_bus(struct pci_dev *dev, int vf_id) { if (!dev->is_physfn) @@ -299,6 +301,7 @@ static ssize_t sriov_numvfs_store(struct device *dev, if (num_vfs > pci_sriov_get_totalvfs(pdev)) return -ERANGE; + mutex_lock(&pci_sriov_numvfs_lock); device_lock(&pdev->dev); if (num_vfs == pdev->sriov->num_VFs) @@ -335,6 +338,7 @@ static ssize_t sriov_numvfs_store(struct device *dev, exit: device_unlock(&pdev->dev); + mutex_unlock(&pci_sriov_numvfs_lock); if (ret < 0) return ret; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] PCI/IOV: Add pci_sriov_numvfs_lock to support enable pci sriov concurrently
by Jialin Zhang 02 Nov '23

02 Nov '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8BLQX CVE: NA -------------------------------- "echo sriov_totalvfs > /sys/bus/pci/devices/$PF_BDF/sriov_numvfs" concurrently may cause the following warnings: Warning 1: sysfs: cannot create duplicate filename '/devices/pci0000:95/0000:95:00.0/pci_bus/0000:97' Call trace: dump_backtrace+0x0/0x200 show_stack+0x20/0x30 dump_stack+0xf0/0x138 sysfs_warn_dup+0x6c/0x90 sysfs_create_dir_ns+0xf8/0x11c create_dir+0x30/0x18c kobject_add_internal+0x5c/0x190 kobject_add+0x98/0x110 device_add+0x100/0x4a0 device_register+0x28/0x40 pci_alloc_child_bus+0x184/0x24c pci_add_new_bus+0x20/0xa4 pci_iov_add_virtfn+0x2a8/0x31c sriov_enable+0x20c/0x4d0 pci_enable_sriov+0x38/0x50 virtio_pci_sriov_configure+0x3c/0xf4 [virtio_pci] sriov_numvfs_store+0xb0/0x1b0 dev_attr_store+0x20/0x34 sysfs_kf_write+0x4c/0x5c kernfs_fop_write_iter+0x130/0x1c0 new_sync_write+0xf0/0x194 vfs_write+0x224/0x2c0 ksys_write+0x74/0x104 __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 The reason is that different VFs may create the same pci bus number and try to add new bus concurrently in virtfn_add_bus. Warning 2: proc_dir_entry 'pci/0000:97' already registered Call trace: proc_register+0x100/0x190 proc_mkdir+0x6c/0xa0 pci_proc_attach_device+0xfc/0x120 pci_bus_add_device+0x40/0xd0 pci_iov_add_virtfn+0x2c8/0x31c sriov_enable+0x20c/0x4d0 pci_enable_sriov+0x38/0x50 virtio_pci_sriov_configure+0x3c/0xf4 [virtio_pci] sriov_numvfs_store+0xb0/0x1b0 dev_attr_store+0x20/0x34 sysfs_kf_write+0x4c/0x5c kernfs_fop_write_iter+0x130/0x1c0 new_sync_write+0xf0/0x194 vfs_write+0x224/0x2c0 ksys_write+0x74/0x104 __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 The reason is that different VFs may create '/proc/bus/pci/bus_number' directory using the same bus number in pci_proc_attach_device concurrently. Mutex lock can avoid potential conflict. With the patch below the warnings above are no longer appear. Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- drivers/pci/pci-sysfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 48c56cb08652..e35c2f0ee28c 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -31,6 +31,8 @@ static int sysfs_initialized; /* = 0 */ +static DEFINE_MUTEX(pci_sriov_numvfs_lock); + /* show configuration fields */ #define pci_config_attr(field, format_string) \ static ssize_t \ @@ -604,6 +606,7 @@ static ssize_t sriov_numvfs_store(struct device *dev, if (num_vfs > pci_sriov_get_totalvfs(pdev)) return -ERANGE; + mutex_lock(&pci_sriov_numvfs_lock); device_lock(&pdev->dev); if (num_vfs == pdev->sriov->num_VFs) @@ -640,6 +643,7 @@ static ssize_t sriov_numvfs_store(struct device *dev, exit: device_unlock(&pdev->dev); + mutex_unlock(&pci_sriov_numvfs_lock); if (ret < 0) return ret; -- 2.25.1

2 1

[PATCH OLK-5.10] coresight: core: fix memory leak in dict->fwnode_list
by Junhao He 02 Nov '23

02 Nov '23

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8DBW8 CVE: NA ---------------------------------------------------------------------- There are memory leaks reported by kmemleak: ... unreferenced object 0xffff2020103c3200 (size 256): comm "insmod", pid 4476, jiffies 4294978252 (age 50072.536s) hex dump (first 32 bytes): 10 60 40 06 28 20 ff ff 10 c0 59 06 20 20 ff ff .`@.( ....Y. .. 10 e0 47 06 28 20 ff ff 10 00 49 06 28 20 ff ff ..G.( ....I.( .. backtrace: [<0000000034ec4724>] __kmem_cache_alloc_node+0x2f8/0x348 [<0000000057fbc15d>] __kmalloc_node_track_caller+0x5c/0x110 [<00000055d5e34b>] krealloc+0x8c/0x178 [<00000000a4635beb>] coresight_alloc_device_name+0x128/0x188 [coresight] [<00000000a92ddfee>] funnel_cs_ops+0x10/0xfffffffffffedaa0 [coresight_funnel] [<00000000449e20f8>] dynamic_funnel_ids+0x80/0xfffffffffffed840 [coresight_funnel] ... when remove driver, the golab variables defined by the macro DEFINE_CORESIGHT_DEVLIST will be released, dict->nr_idx and dict->fwnode_list are cleared to 0. The lifetime of the golab variable has ended. So the buffer pointer is lost. Use the callback of devm_add_action_or_reset() to free memory. Fixes: 0f5f9b6ba9e1 ("coresight: Use platform agnostic names") Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- drivers/hwtracing/coresight/coresight-core.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c index 9696f402a328..55ec00876989 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -1739,6 +1739,20 @@ bool coresight_loses_context_with_cpu(struct device *dev) } EXPORT_SYMBOL_GPL(coresight_loses_context_with_cpu); +void coresight_release_dev_list(void *data) +{ + struct coresight_dev_list *dict = data; + + mutex_lock(&coresight_mutex); + + if (dict->nr_idx) { + kfree(dict->fwnode_list); + dict->nr_idx = 0; + } + + mutex_unlock(&coresight_mutex); +} + /* * coresight_alloc_device_name - Get an index for a given device in the * device index list specific to a driver. An index is allocated for a @@ -1749,12 +1763,16 @@ EXPORT_SYMBOL_GPL(coresight_loses_context_with_cpu); char *coresight_alloc_device_name(struct coresight_dev_list *dict, struct device *dev) { - int idx; + int idx, ret; char *name = NULL; struct fwnode_handle **list; mutex_lock(&coresight_mutex); + ret = devm_add_action_or_reset(dev, coresight_release_dev_list, dict); + if (ret) + goto done; + idx = coresight_search_device_idx(dict, dev_fwnode(dev)); if (idx < 0) { /* Make space for the new entry */ -- 2.33.0

2 1

[PATCH OLK-5.10 v2] perf auxtrace ptt: Record whether an auxtrace mmap is needed
by Junhao He 02 Nov '23

02 Nov '23

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7HI80 CVE: NA ---------------------------------------------------------------------- Add a flag needs_auxtrace_mmap to record whether an auxtrace mmap is needed, in preparation for correctly determining whether or not an auxtrace mmap is needed. The change was added in the mainline patch [1], but it was deleted when upstream openEuler for fixes build error. openEuler OLK-5.10 now has merge evsel->needs_auxtrace_mmap. Therefore, backport this modification to OpenEuler OLK-5.10. [1] 057381a7ece1 "perf auxtrace arm64: Add support for HiSilicon PCIe Tune and Trace device driver" Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- tools/perf/arch/arm64/util/hisi-ptt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/arch/arm64/util/hisi-ptt.c b/tools/perf/arch/arm64/util/hisi-ptt.c index 110b2edf3e6b..97696b6e1dd5 100644 --- a/tools/perf/arch/arm64/util/hisi-ptt.c +++ b/tools/perf/arch/arm64/util/hisi-ptt.c @@ -113,6 +113,7 @@ static int hisi_ptt_recording_options(struct auxtrace_record *itr, } evsel->core.attr.freq = 0; evsel->core.attr.sample_period = 1; + evsel->needs_auxtrace_mmap = true; hisi_ptt_evsel = evsel; opts->full_auxtrace = true; } -- 2.33.0

2 1

[PATCH] perf auxtrace ptt: Record whether an auxtrace mmap is needed
by Junhao He 02 Nov '23

02 Nov '23

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7HI80 CVE: NA ---------------------------------------------------------------------- Add a flag needs_auxtrace_mmap to record whether an auxtrace mmap is needed, in preparation for correctly determining whether or not an auxtrace mmap is needed. The change was added in the mainline patch [1], but it was deleted when upstream openEuler for fixes build error. openEuler OLK-5.10 now has merge evsel->needs_auxtrace_mmap. Therefore, backport this modification to OpenEuler OLK-5.10. [1] 057381a7ece1 "perf auxtrace arm64: Add support for HiSilicon PCIe Tune and Trace device driver" Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- tools/perf/arch/arm64/util/hisi-ptt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/arch/arm64/util/hisi-ptt.c b/tools/perf/arch/arm64/util/hisi-ptt.c index 110b2edf3e6b..97696b6e1dd5 100644 --- a/tools/perf/arch/arm64/util/hisi-ptt.c +++ b/tools/perf/arch/arm64/util/hisi-ptt.c @@ -113,6 +113,7 @@ static int hisi_ptt_recording_options(struct auxtrace_record *itr, } evsel->core.attr.freq = 0; evsel->core.attr.sample_period = 1; + evsel->needs_auxtrace_mmap = true; hisi_ptt_evsel = evsel; opts->full_auxtrace = true; } -- 2.33.0

1 0

[PATCH v3 openEuler-1.0-LTS] kernel/trace: Fix do not unregister tracepoints when register sched_migrate_task fail
by Wenyu Huang 02 Nov '23

02 Nov '23

From: Kaitao Cheng <pilgrimtao(a)gmail.com> stable inclusion from stable-v4.19.297 commit 50f9ad607ea891a9308e67b81f774c71736d1098 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8BAW8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- In the function, if register_trace_sched_migrate_task() returns error, sched_switch/sched_wakeup_new/sched_wakeup won't unregister. That is why fail_deprobe_sched_switch was added. Link: http://lkml.kernel.org/r/20191231133530.2794-1-pilgrimtao@gmail.com Cc: stable(a)vger.kernel.org Fixes: 478142c39c8c2 ("tracing: do not grab lock in wakeup latency function tracing") Signed-off-by: Kaitao Cheng <pilgrimtao(a)gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Wenyu Huang <huangwenyu4(a)huawei.com> --- kernel/trace/trace_sched_wakeup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace_sched_wakeup.c b/kernel/trace/trace_sched_wakeup.c index 0db1b024e786..8041bd5e4262 100644 --- a/kernel/trace/trace_sched_wakeup.c +++ b/kernel/trace/trace_sched_wakeup.c @@ -642,7 +642,7 @@ static void start_wakeup_tracer(struct trace_array *tr) if (ret) { pr_info("wakeup trace: Couldn't activate tracepoint" " probe to kernel_sched_migrate_task\n"); - return; + goto fail_deprobe_sched_switch; } wakeup_reset(tr); @@ -660,6 +660,8 @@ static void start_wakeup_tracer(struct trace_array *tr) printk(KERN_ERR "failed to start wakeup tracer\n"); return; +fail_deprobe_sched_switch: + unregister_trace_sched_switch(probe_wakeup_sched_switch, NULL); fail_deprobe_wake_new: unregister_trace_sched_wakeup_new(probe_wakeup, NULL); fail_deprobe: -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] net: sched: sch_qfq: Use non-work-conserving warning handler
by Liu Jian 02 Nov '23

02 Nov '23

mainline inclusion from mainline-v6.7-rc1 commit 6d25d1dc76bf5943a5c1f4bb74d66d5eac58eb77 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8D8S8 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- A helper function for printing non-work-conserving alarms is added in commit b00355db3f88 ("pkt_sched: sch_hfsc: sch_htb: Add non-work-conserving warning handler."). In this commit, use qdisc_warn_nonwc() instead of WARN_ONCE() to handle the non-work-conserving warning in qfq Qdisc. Signed-off-by: Liu Jian <liujian56(a)huawei.com> Link: https://lore.kernel.org/r/20231023064729.370649-1-liujian56@huawei.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/sched/sch_qfq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c index 5b7b149a2b9f..14d009151a5b 100644 --- a/net/sched/sch_qfq.c +++ b/net/sched/sch_qfq.c @@ -1018,7 +1018,7 @@ static inline struct sk_buff *qfq_peek_skb(struct qfq_aggregate *agg, *cl = list_first_entry(&agg->active, struct qfq_class, alist); skb = (*cl)->qdisc->ops->peek((*cl)->qdisc); if (skb == NULL) - WARN_ONCE(1, "qfq_dequeue: non-workconserving leaf\n"); + qdisc_warn_nonwc("qfq_dequeue", (*cl)->qdisc); else *len = qdisc_pkt_len(skb); -- 2.34.1

2 1