- Linux-stable-mirror - lists.linaro.org

[PATCH v2 1/3] mmc: sdhci: Move the code related to setting the clock from sdhci_set_ios_common() into sdhci_set_ios()

by Ben Chuang

From: Ben Chuang <ben.chuang(a)genesyslogic.com.tw> The sdhci_set_clock() is called in sdhci_set_ios_common() and __sdhci_uhs2_set_ios(). According to Section 3.13.2 "Card Interface Detection Sequence" of the SD Host Controller Standard Specification Version 7.00, the SD clock is supplied after power is supplied, so we only need one in __sdhci_uhs2_set_ios(). Let's move the code related to setting the clock from sdhci_set_ios_common() into sdhci_set_ios(). Fixes: 10c8298a052b ("mmc: sdhci-uhs2: add set_ios()") Cc: stable(a)vger.kernel.org # v6.13+ Signed-off-by: Ben Chuang <ben.chuang(a)genesyslogic.com.tw> --- v2: add this patch v1: None --- drivers/mmc/host/sdhci.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 3a17821efa5c..ac7e11f37af7 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2367,23 +2367,6 @@ void sdhci_set_ios_common(struct mmc_host *mmc, struct mmc_ios *ios) (ios->power_mode == MMC_POWER_UP) && !(host->quirks2 & SDHCI_QUIRK2_PRESET_VALUE_BROKEN)) sdhci_enable_preset_value(host, false); - - if (!ios->clock || ios->clock != host->clock) { - host->ops->set_clock(host, ios->clock); - host->clock = ios->clock; - - if (host->quirks & SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK && - host->clock) { - host->timeout_clk = mmc->actual_clock ? - mmc->actual_clock / 1000 : - host->clock / 1000; - mmc->max_busy_timeout = - host->ops->get_max_timeout_count ? - host->ops->get_max_timeout_count(host) : - 1 << 27; - mmc->max_busy_timeout /= host->timeout_clk; - } - } } EXPORT_SYMBOL_GPL(sdhci_set_ios_common); @@ -2410,6 +2393,23 @@ void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) sdhci_set_ios_common(mmc, ios); + if (!ios->clock || ios->clock != host->clock) { + host->ops->set_clock(host, ios->clock); + host->clock = ios->clock; + + if (host->quirks & SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK && + host->clock) { + host->timeout_clk = mmc->actual_clock ? + mmc->actual_clock / 1000 : + host->clock / 1000; + mmc->max_busy_timeout = + host->ops->get_max_timeout_count ? + host->ops->get_max_timeout_count(host) : + 1 << 27; + mmc->max_busy_timeout /= host->timeout_clk; + } + } + if (host->ops->set_power) host->ops->set_power(host, ios->power_mode, ios->vdd); else -- 2.51.0

1 month, 1 week

2
5
0 0

Past Due Invoice #07182025

by Mike Waldner

1 month, 1 week

1
0
0 0

[PATCH] cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode

by Srinivas Pandruvada

When turbo mode is unavailable on a Skylake-X system, executing the command: "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo" results in an unchecked MSR access error: WRMSR to 0x199 (attempted to write 0x0000000100001300). This issue was reproduced on an OEM (Original Equipment Manufacturer) system and is not a common problem across all Skylake-X systems. This error occurs because the MSR 0x199 Turbo Engage Bit (bit 32) is set when turbo mode is disabled. The issue arises when intel_pstate fails to detect that turbo mode is disabled. Here intel_pstate relies on MSR_IA32_MISC_ENABLE bit 38 to determine the status of turbo mode. However, on this system, bit 38 is not set even when turbo mode is disabled. According to the Intel Software Developer's Manual (SDM), the BIOS sets this bit during platform initialization to enable or disable opportunistic processor performance operations. Logically, this bit should be set in such cases. However, the SDM also specifies that "OS and applications must use CPUID leaf 06H to detect processors with opportunistic processor performance operations enabled." Therefore, in addition to checking MSR_IA32_MISC_ENABLE bit 38, verify that CPUID.06H:EAX[1] is 0 to accurately determine if turbo mode is disabled. Fixes: 4521e1a0ce17 ("cpufreq: intel_pstate: Reflect current no_turbo state correctly") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/cpufreq/intel_pstate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index f41ed0b9e610..ba9bf06f1c77 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -598,6 +598,9 @@ static bool turbo_is_disabled(void) { u64 misc_en; + if (!cpu_feature_enabled(X86_FEATURE_IDA)) + return true; + rdmsrl(MSR_IA32_MISC_ENABLE, misc_en); return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE); -- 2.48.1

1 month, 1 week

4
4
0 0

[PATCH net v3 0/3] net: netpoll: fix a memleak and create a selftest

by Breno Leitao

Fix a memory leak issue on netpoll and create a netconsole test that exposes the problem, when run with kmemleak enabled. This is a merge of two patches I've sent individually and are merged on the same patchset[1][2]. Link: https://lore.kernel.org/all/20250904-netconsole_torture-v2-0-5775ed5dc366@d… [1] Link: https://lore.kernel.org/all/20250902165426.6d6cd172@kernel.org/ [2] Signed-off-by: Breno Leitao <leitao(a)debian.org> --- Changes in v3: - this patchset is a merge of the fix and the selftest together as recommended by Jakub. Changes in v2: - Reuse the netconsole creation from lib_netcons.sh. Thus, refactoring the create_dynamic_target() (Jakub) - Move the "wait" to after all the messages has been sent. - Link to v1: https://lore.kernel.org/r/20250902-netconsole_torture-v1-1-03c6066598e9@deb… --- Breno Leitao (3): netpoll: fix incorrect refcount handling causing incorrect cleanup selftest: netcons: refactor target creation selftest: netcons: create a torture test net/core/netpoll.c | 7 +- tools/testing/selftests/drivers/net/Makefile | 1 + .../selftests/drivers/net/lib/sh/lib_netcons.sh | 30 +++-- .../selftests/drivers/net/netcons_torture.sh | 127 +++++++++++++++++++++ 4 files changed, 152 insertions(+), 13 deletions(-) --- base-commit: d69eb204c255c35abd9e8cb621484e8074c75eaa change-id: 20250902-netconsole_torture-8fc23f0aca99 Best regards, -- Breno Leitao <leitao(a)debian.org>

1 month, 1 week

6
18
0 0

Service update notification

by Email Administrator

1 month, 1 week

1
0
0 0

[PATCH v2] fbdev/simplefb: Fix use after free in simplefb_detach_genpds()

by Janne Grunau

The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ... Reported-by: Daniel Huhardeaux <tech(a)tootai.net> Cc: stable(a)vger.kernel.org Fixes: 92a511a568e44 ("fbdev/simplefb: Add support for generic power-domains") Signed-off-by: Janne Grunau <j(a)jannau.net> --- Changes in v2: - reworked change due to missed use of `par->num_genpds` before setting it. Missed in testing due to FB_SIMPLE vs. SYSFB_SIMPLEFB. - Link to v1: https://lore.kernel.org/r/20250901-simplefb-genpd-uaf-v1-1-0d9f3a34c4dc@jan… --- drivers/video/fbdev/simplefb.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c index 1893815dc67f4c1403eea42c0e10a7ead4d96ba9..2f3e5449509d1824a3d26f73e103af82d56d558a 100644 --- a/drivers/video/fbdev/simplefb.c +++ b/drivers/video/fbdev/simplefb.c @@ -93,6 +93,7 @@ struct simplefb_par { static void simplefb_clocks_destroy(struct simplefb_par *par); static void simplefb_regulators_destroy(struct simplefb_par *par); +static void simplefb_detach_genpds(void *res); /* * fb_ops.fb_destroy is called by the last put_fb_info() call at the end @@ -105,6 +106,7 @@ static void simplefb_destroy(struct fb_info *info) simplefb_regulators_destroy(info->par); simplefb_clocks_destroy(info->par); + simplefb_detach_genpds(info->par); if (info->screen_base) iounmap(info->screen_base); @@ -451,7 +453,7 @@ static int simplefb_attach_genpds(struct simplefb_par *par, struct platform_device *pdev) { struct device *dev = &pdev->dev; - unsigned int i; + unsigned int i, num_genpds; int err; err = of_count_phandle_with_args(dev->of_node, "power-domains", @@ -465,26 +467,33 @@ static int simplefb_attach_genpds(struct simplefb_par *par, return err; } - par->num_genpds = err; + num_genpds = err; /* * Single power-domain devices are handled by the driver core, so * nothing to do here. */ - if (par->num_genpds <= 1) + if (num_genpds <= 1) return 0; - par->genpds = devm_kcalloc(dev, par->num_genpds, sizeof(*par->genpds), + par->genpds = devm_kcalloc(dev, num_genpds, sizeof(*par->genpds), GFP_KERNEL); if (!par->genpds) return -ENOMEM; - par->genpd_links = devm_kcalloc(dev, par->num_genpds, + par->genpd_links = devm_kcalloc(dev, num_genpds, sizeof(*par->genpd_links), GFP_KERNEL); if (!par->genpd_links) return -ENOMEM; + /* + * Set par->num_genpds only after genpds and genpd_links are allocated + * to exit early from simplefb_detach_genpds() without full + * initialisation. + */ + par->num_genpds = num_genpds; + for (i = 0; i < par->num_genpds; i++) { par->genpds[i] = dev_pm_domain_attach_by_id(dev, i); if (IS_ERR(par->genpds[i])) { @@ -506,9 +515,10 @@ static int simplefb_attach_genpds(struct simplefb_par *par, dev_warn(dev, "failed to link power-domain %u\n", i); } - return devm_add_action_or_reset(dev, simplefb_detach_genpds, par); + return 0; } #else +static void simplefb_detach_genpds(void *res) { } static int simplefb_attach_genpds(struct simplefb_par *par, struct platform_device *pdev) { --- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250901-simplefb-genpd-uaf-352704761a29 Best regards, -- Janne Grunau <j(a)jannau.net>

1 month, 1 week

2
1
0 0

[PATCH 5.10] mptcp: pm: kernel: flush: do not reset ADD_ADDR limit

by Heyne, Maximilian

From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> commit 68fc0f4b0d25692940cdc85c68e366cae63e1757 upstream. A flush of the MPTCP endpoints should not affect the MPTCP limits. In other words, 'ip mptcp endpoint flush' should not change 'ip mptcp limits'. But it was the case: the MPTCP_PM_ATTR_RCV_ADD_ADDRS (add_addr_accepted) limit was reset by accident. Removing the reset of this counter during a flush fixes this issue. Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") Cc: stable(a)vger.kernel.org Reported-by: Thomas Dreibholz <dreibh(a)simula.no> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/579 Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-2-521fe9… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> [adjusted patch by removing WRITE_ONCE to take into account the missing commit 72603d207d59 ("mptcp: use WRITE_ONCE for the pernet *_max")] Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> --- For some reason only the corresponding selftest patch was backported and it's now failing on 5.10 kernels. I tested that with this patch the selftest is succeeding again. --- net/mptcp/pm_netlink.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 32379fc706cac..c31a1dc69f835 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -869,7 +869,6 @@ static void __flush_addrs(struct pm_nl_pernet *pernet) static void __reset_counters(struct pm_nl_pernet *pernet) { pernet->add_addr_signal_max = 0; - pernet->add_addr_accept_max = 0; pernet->local_addr_max = 0; pernet->addrs = 0; } -- 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

1 month, 1 week

3
3
0 0

FAILED: patch "[PATCH] kasan: fix GCC mem-intrinsic prefix with sw tags" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 51337a9a3a404fde0f5337662ffc7699793dfeb5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025090600-revenue-discharge-a6c4@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 51337a9a3a404fde0f5337662ffc7699793dfeb5 Mon Sep 17 00:00:00 2001 From: Ada Couprie Diaz <ada.coupriediaz(a)arm.com> Date: Thu, 21 Aug 2025 13:07:35 +0100 Subject: [PATCH] kasan: fix GCC mem-intrinsic prefix with sw tags GCC doesn't support "hwasan-kernel-mem-intrinsic-prefix", only "asan-kernel-mem-intrinsic-prefix"[0], while LLVM supports both. This is already taken into account when checking "CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX", but not in the KASAN Makefile adding those parameters when "CONFIG_KASAN_SW_TAGS" is enabled. Replace the version check with "CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX", which already validates that mem-intrinsic prefix parameter can be used, and choose the correct name depending on compiler. GCC 13 and above trigger "CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX" which prevents `mem{cpy,move,set}()` being redefined in "mm/kasan/shadow.c" since commit 36be5cba99f6 ("kasan: treat meminstrinsic as builtins in uninstrumented files"), as we expect the compiler to prefix those calls with `__(hw)asan_` instead. But as the option passed to GCC has been incorrect, the compiler has not been emitting those prefixes, effectively never calling the instrumented versions of `mem{cpy,move,set}()` with "CONFIG_KASAN_SW_TAGS" enabled. If "CONFIG_FORTIFY_SOURCES" is enabled, this issue would be mitigated as it redefines `mem{cpy,move,set}()` and properly aliases the `__underlying_mem*()` that will be called to the instrumented versions. Link: https://lkml.kernel.org/r/20250821120735.156244-1-ada.coupriediaz@arm.com Link: https://gcc.gnu.org/onlinedocs/gcc-13.4.0/gcc/Optimize-Options.html [0] Signed-off-by: Ada Couprie Diaz <ada.coupriediaz(a)arm.com> Fixes: 36be5cba99f6 ("kasan: treat meminstrinsic as builtins in uninstrumented files") Reviewed-by: Yeoreum Yun <yeoreum.yun(a)arm.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Marco Elver <elver(a)google.com> Cc: Marc Rutland <mark.rutland(a)arm.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan index 693dbbebebba..0ba2aac3b8dc 100644 --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -86,10 +86,14 @@ kasan_params += hwasan-instrument-stack=$(stack_enable) \ hwasan-use-short-granules=0 \ hwasan-inline-all-checks=0 -# Instrument memcpy/memset/memmove calls by using instrumented __hwasan_mem*(). -ifeq ($(call clang-min-version, 150000)$(call gcc-min-version, 130000),y) - kasan_params += hwasan-kernel-mem-intrinsic-prefix=1 -endif +# Instrument memcpy/memset/memmove calls by using instrumented __(hw)asan_mem*(). +ifdef CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX + ifdef CONFIG_CC_IS_GCC + kasan_params += asan-kernel-mem-intrinsic-prefix=1 + else + kasan_params += hwasan-kernel-mem-intrinsic-prefix=1 + endif +endif # CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX endif # CONFIG_KASAN_SW_TAGS

1 month, 1 week

2
1
0 0

Publish Your Research in e-Informatica Soft. Eng. Journal (IF=1.2, Open Access, Free of Charge)

by e-Informatica Software Engineering Journal

<!doctype html> <html> <head> <title>Publish Your Research in e-Informatica Soft. Eng. Journal (IF=1.2, Open Access, Free of Charge)</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1"> <base target="_blank"> <style> body { background-color: #F0F1F3; font-family: 'Helvetica Neue', 'Segoe UI', Helvetica, sans-serif; font-size: 15px; line-height: 26px; margin: 0; color: #444; } pre { background: #f4f4f4f4; padding: 2px; } table { width: 100%; border: 1px solid #ddd; } table td { border-color: #ddd; padding: 5px; } .wrap { background-color: #fff; padding: 30px; max-width: 525px; margin: 0 auto; border-radius: 5px; } .button { background: #0055d4; border-radius: 3px; text-decoration: none !important; color: #fff !important; font-weight: bold; padding: 10px 30px; display: inline-block; } .button:hover { background: #111; } .footer { text-align: center; font-size: 12px; color: #888; } .footer a { color: #888; margin-right: 5px; } .gutter { padding: 30px; } img { max-width: 100%; height: auto; } a { color: #0055d4; } a:hover { color: #111; } @media screen and (max-width: 600px) { .wrap { max-width: auto; } .gutter { padding: 10px; } } </style> </head> <body style="background-color: #F0F1F3;font-family: 'Helvetica Neue', 'Segoe UI', Helvetica, sans-serif;font-size: 15px;line-height: 26px;margin: 0;color: #444;"> <div class="gutter" style="padding: 30px;"> </div> <div class="wrap" style="background-color: #fff;padding: 30px;max-width: 525px;margin: 0 auto;border-radius: 5px;"> Dear colleague, We would like to invite you to submit your papers to the e-Informatica Software Engineering Journal (EISEJ). We particularly invite papers focused on: - software engineering or - the intersection of data science (AI/ML) and software engineering. Our strengths: - excellent, international Editorial Board (https://www.e-informatyka.pl/index.php/einformatica/editorial-board/) - *open access without any authorship fees*, - no paper length limit, - fast, continuous publishing model with papers edited and published immediately after acceptance, - rigorous, blind peer-review process. Our achievements: - ISI WoS with Impact Factor (IF=1.2, 5 Year IF=1.3) calculated by Clarivate (https://jcr.clarivate.com/jcr-jp/journal-profile?journal=E-INFORMATICA&year…), - Scopus (https://www.scopus.com/sourceid/21100259509) with CiteScore=3.5, - DBLP (https://dblp.uni-trier.de/db/journals/eInformatica/index.html), - Directory of Open Access Journals (https://doaj.org/toc/2084-4840), - Google Scholar (https://scholar.google.pl/citations?user=8-uDLDoAAAAJ&hl) etc. Apart from classic research papers, we invite you to submit: - systematic reviews (incl. systematic mapping/scoping studies), - surveys, - research agendas, - vision papers. We not only invite you to submit papers (https://mc.manuscriptcentral.com/e-InformaticaSEJ), but also to organise special sections (please get in touch with us at e-informatica(a)pwr.edu.pl). We would be grateful for your feedback as well. Please let us know what we lack, what we did not think about, or what we should do to become an even more attractive venue from your point of view! Let us collaborate on any excellent idea within the scope of the journal! With very best wishes, e-Informatica Software Engineering Journal (EISEJ) Editors-in-Chief Lech Madeyski and Miroslaw Ochodek EISEJ website: https://www.e-informatyka.pl/ EISEJ submission site: https://mc.manuscriptcentral.com/e-InformaticaSEJ </div> <div class="footer" style="text-align: center;font-size: 12px;color: #888;"> <p> <a href="https://listmonk.e-informatyka.pl/subscription/f884ba71-56f3-4ced-80ef-0b7a…" style="color: #888;">Unsubscribe</a>    <a href="https://listmonk.e-informatyka.pl/campaign/f884ba71-56f3-4ced-80ef-0b7a3ade…" style="color: #888;">View in browser</a> </p> </div> <div class="gutter" style="padding: 30px;"> <img src="https://listmonk.e-informatyka.pl/campaign/f884ba71-56f3-4ced-80ef-0b7a3ade…" alt="" /></div> </body> </html>

1 month, 1 week

1
0
0 0

[PATCH] ACPI: battery: prevent sysfs_add_battery re-entry on rapid events

by GuangFei Luo

When removing and reinserting the laptop battery, ACPI can trigger two notifications in quick succession: - ACPI_BATTERY_NOTIFY_STATUS (0x80) - ACPI_BATTERY_NOTIFY_INFO (0x81) Both notifications call acpi_battery_update(). Because the events happen very close in time, sysfs_add_battery() can be re-entered before battery->bat is set, causing a duplicate sysfs entry error. This patch ensures that sysfs_add_battery() is not re-entered when battery->bat is already non-NULL, preventing the duplicate sysfs creation and stabilizing battery hotplug handling. [ 476.117945] sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1' [ 476.118896] CPU: 1 UID: 0 PID: 185 Comm: kworker/1:4 Kdump: loaded Not tainted 6.12.38+deb13-amd64 #1 Debian 6.12.38-1 [ 476.118903] Hardware name: Gateway NV44 /SJV40-MV , BIOS V1.3121 04/08/2009 [ 476.118906] Workqueue: kacpi_notify acpi_os_execute_deferred [ 476.118917] Call Trace: [ 476.118922] <TASK> [ 476.118929] dump_stack_lvl+0x5d/0x80 [ 476.118938] sysfs_warn_dup.cold+0x17/0x23 [ 476.118943] sysfs_create_dir_ns+0xce/0xe0 [ 476.118952] kobject_add_internal+0xba/0x250 [ 476.118959] kobject_add+0x96/0xc0 [ 476.118964] ? get_device_parent+0xde/0x1e0 [ 476.118970] device_add+0xe2/0x870 [ 476.118975] __power_supply_register.part.0+0x20f/0x3f0 [ 476.118981] ? wake_up_q+0x4e/0x90 [ 476.118990] sysfs_add_battery+0xa4/0x1d0 [battery] [ 476.118998] acpi_battery_update+0x19e/0x290 [battery] [ 476.119002] acpi_battery_notify+0x50/0x120 [battery] [ 476.119006] acpi_ev_notify_dispatch+0x49/0x70 [ 476.119012] acpi_os_execute_deferred+0x1a/0x30 [ 476.119015] process_one_work+0x177/0x330 [ 476.119022] worker_thread+0x251/0x390 [ 476.119026] ? __pfx_worker_thread+0x10/0x10 [ 476.119030] kthread+0xd2/0x100 [ 476.119033] ? __pfx_kthread+0x10/0x10 [ 476.119035] ret_from_fork+0x34/0x50 [ 476.119040] ? __pfx_kthread+0x10/0x10 [ 476.119042] ret_from_fork_asm+0x1a/0x30 [ 476.119049] </TASK> [ 476.142552] kobject: kobject_add_internal failed for BAT1 with -EEXIST, don't try to register things with the same name in the same directory. [ 476.415022] ata1.00: unexpected _GTF length (8) [ 476.428076] sd 0:0:0:0: [sda] Starting disk [ 476.835035] ata1.00: unexpected _GTF length (8) [ 476.839720] ata1.00: configured for UDMA/133 [ 491.328831] sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1' [ 491.329720] CPU: 1 UID: 0 PID: 185 Comm: kworker/1:4 Kdump: loaded Not tainted 6.12.38+deb13-amd64 #1 Debian 6.12.38-1 [ 491.329727] Hardware name: Gateway NV44 /SJV40-MV , BIOS V1.3121 04/08/2009 [ 491.329731] Workqueue: kacpi_notify acpi_os_execute_deferred [ 491.329741] Call Trace: [ 491.329745] <TASK> [ 491.329751] dump_stack_lvl+0x5d/0x80 [ 491.329758] sysfs_warn_dup.cold+0x17/0x23 [ 491.329762] sysfs_create_dir_ns+0xce/0xe0 [ 491.329770] kobject_add_internal+0xba/0x250 [ 491.329775] kobject_add+0x96/0xc0 [ 491.329779] ? get_device_parent+0xde/0x1e0 [ 491.329784] device_add+0xe2/0x870 [ 491.329790] __power_supply_register.part.0+0x20f/0x3f0 [ 491.329797] sysfs_add_battery+0xa4/0x1d0 [battery] [ 491.329805] acpi_battery_update+0x19e/0x290 [battery] [ 491.329809] acpi_battery_notify+0x50/0x120 [battery] [ 491.329812] acpi_ev_notify_dispatch+0x49/0x70 [ 491.329817] acpi_os_execute_deferred+0x1a/0x30 [ 491.329820] process_one_work+0x177/0x330 [ 491.329826] worker_thread+0x251/0x390 [ 491.329830] ? __pfx_worker_thread+0x10/0x10 [ 491.329833] kthread+0xd2/0x100 [ 491.329836] ? __pfx_kthread+0x10/0x10 [ 491.329838] ret_from_fork+0x34/0x50 [ 491.329842] ? __pfx_kthread+0x10/0x10 [ 491.329844] ret_from_fork_asm+0x1a/0x30 [ 491.329850] </TASK> [ 491.329855] kobject: kobject_add_internal failed for BAT1 with -EEXIST, don't try to register things with the same name in the same directory. Fixes: 508df92d1f8d ("ACPI: battery: register power_supply subdevice only when battery is present") Signed-off-by: GuangFei Luo <luogf2025(a)163.com> Cc: stable(a)vger.kernel.org --- drivers/acpi/battery.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 6905b56bf3e4..3801fd34c969 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -1026,11 +1026,13 @@ static int acpi_battery_update(struct acpi_battery *battery, bool resume) return result; acpi_battery_quirks(battery); + mutex_lock(&battery->sysfs_lock); if (!battery->bat) { result = sysfs_add_battery(battery); if (result) return result; } + mutex_unlock(&battery->sysfs_lock); /* * Wakeup the system if battery is critical low -- 2.43.0

1 month, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror