April 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] random: handle creditable entropy from atomic process context" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x e871abcda3b67d0820b4182ebe93435624e9c6a4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024041903-pentagon-deceiver-fe1d@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: e871abcda3b6 ("random: handle creditable entropy from atomic process context") bbc7e1bed1f5 ("random: add back async readiness notifier") 9148de3196ed ("random: reseed in delayed work rather than on-demand") f62384995e4c ("random: split initialization into early step and later step") 745558f95885 ("random: use hwgenerator randomness more frequently at early boot") 228dfe98a313 ("Merge tag 'char-misc-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e871abcda3b67d0820b4182ebe93435624e9c6a4 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Wed, 17 Apr 2024 13:38:29 +0200 Subject: [PATCH] random: handle creditable entropy from atomic process context The entropy accounting changes a static key when the RNG has initialized, since it only ever initializes once. Static key changes, however, cannot be made from atomic context, so depending on where the last creditable entropy comes from, the static key change might need to be deferred to a worker. Previously the code used the execute_in_process_context() helper function, which accounts for whether or not the caller is in_interrupt(). However, that doesn't account for the case where the caller is actually in process context but is holding a spinlock. This turned out to be the case with input_handle_event() in drivers/input/input.c contributing entropy: [<ffffffd613025ba0>] die+0xa8/0x2fc [<ffffffd613027428>] bug_handler+0x44/0xec [<ffffffd613016964>] brk_handler+0x90/0x144 [<ffffffd613041e58>] do_debug_exception+0xa0/0x148 [<ffffffd61400c208>] el1_dbg+0x60/0x7c [<ffffffd61400c000>] el1h_64_sync_handler+0x38/0x90 [<ffffffd613011294>] el1h_64_sync+0x64/0x6c [<ffffffd613102d88>] __might_resched+0x1fc/0x2e8 [<ffffffd613102b54>] __might_sleep+0x44/0x7c [<ffffffd6130b6eac>] cpus_read_lock+0x1c/0xec [<ffffffd6132c2820>] static_key_enable+0x14/0x38 [<ffffffd61400ac08>] crng_set_ready+0x14/0x28 [<ffffffd6130df4dc>] execute_in_process_context+0xb8/0xf8 [<ffffffd61400ab30>] _credit_init_bits+0x118/0x1dc [<ffffffd6138580c8>] add_timer_randomness+0x264/0x270 [<ffffffd613857e54>] add_input_randomness+0x38/0x48 [<ffffffd613a80f94>] input_handle_event+0x2b8/0x490 [<ffffffd613a81310>] input_event+0x6c/0x98 According to Guoyong, it's not really possible to refactor the various drivers to never hold a spinlock there. And in_atomic() isn't reliable. So, rather than trying to be too fancy, just punt the change in the static key to a workqueue always. There's basically no drawback of doing this, as the code already needed to account for the static key not changing immediately, and given that it's just an optimization, there's not exactly a hurry to change the static key right away, so deferal is fine. Reported-by: Guoyong Wang <guoyong.wang(a)mediatek.com> Cc: stable(a)vger.kernel.org Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> diff --git a/drivers/char/random.c b/drivers/char/random.c index 456be28ba67c..2597cb43f438 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -702,7 +702,7 @@ static void extract_entropy(void *buf, size_t len) static void __cold _credit_init_bits(size_t bits) { - static struct execute_work set_ready; + static DECLARE_WORK(set_ready, crng_set_ready); unsigned int new, orig, add; unsigned long flags; @@ -718,8 +718,8 @@ static void __cold _credit_init_bits(size_t bits) if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { crng_reseed(NULL); /* Sets crng_init to CRNG_READY under base_crng.lock. */ - if (static_key_initialized) - execute_in_process_context(crng_set_ready, &set_ready); + if (static_key_initialized && system_unbound_wq) + queue_work(system_unbound_wq, &set_ready); atomic_notifier_call_chain(&random_ready_notifier, 0, NULL); wake_up_interruptible(&crng_init_wait); kill_fasync(&fasync, SIGIO, POLL_IN); @@ -890,8 +890,8 @@ void __init random_init(void) /* * If we were initialized by the cpu or bootloader before jump labels - * are initialized, then we should enable the static branch here, where - * it's guaranteed that jump labels have been initialized. + * or workqueues are initialized, then we should enable the static + * branch here, where it's guaranteed that these have been initialized. */ if (!static_branch_likely(&crng_is_ready) && crng_init >= CRNG_READY) crng_set_ready(NULL);

1 year

2
1
0 0

FAILED: patch "[PATCH] random: handle creditable entropy from atomic process context" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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-5.4.y git checkout FETCH_HEAD git cherry-pick -x e871abcda3b67d0820b4182ebe93435624e9c6a4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024041905-obvious-blush-10d8@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: e871abcda3b6 ("random: handle creditable entropy from atomic process context") bbc7e1bed1f5 ("random: add back async readiness notifier") 9148de3196ed ("random: reseed in delayed work rather than on-demand") f62384995e4c ("random: split initialization into early step and later step") 745558f95885 ("random: use hwgenerator randomness more frequently at early boot") 228dfe98a313 ("Merge tag 'char-misc-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e871abcda3b67d0820b4182ebe93435624e9c6a4 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Wed, 17 Apr 2024 13:38:29 +0200 Subject: [PATCH] random: handle creditable entropy from atomic process context The entropy accounting changes a static key when the RNG has initialized, since it only ever initializes once. Static key changes, however, cannot be made from atomic context, so depending on where the last creditable entropy comes from, the static key change might need to be deferred to a worker. Previously the code used the execute_in_process_context() helper function, which accounts for whether or not the caller is in_interrupt(). However, that doesn't account for the case where the caller is actually in process context but is holding a spinlock. This turned out to be the case with input_handle_event() in drivers/input/input.c contributing entropy: [<ffffffd613025ba0>] die+0xa8/0x2fc [<ffffffd613027428>] bug_handler+0x44/0xec [<ffffffd613016964>] brk_handler+0x90/0x144 [<ffffffd613041e58>] do_debug_exception+0xa0/0x148 [<ffffffd61400c208>] el1_dbg+0x60/0x7c [<ffffffd61400c000>] el1h_64_sync_handler+0x38/0x90 [<ffffffd613011294>] el1h_64_sync+0x64/0x6c [<ffffffd613102d88>] __might_resched+0x1fc/0x2e8 [<ffffffd613102b54>] __might_sleep+0x44/0x7c [<ffffffd6130b6eac>] cpus_read_lock+0x1c/0xec [<ffffffd6132c2820>] static_key_enable+0x14/0x38 [<ffffffd61400ac08>] crng_set_ready+0x14/0x28 [<ffffffd6130df4dc>] execute_in_process_context+0xb8/0xf8 [<ffffffd61400ab30>] _credit_init_bits+0x118/0x1dc [<ffffffd6138580c8>] add_timer_randomness+0x264/0x270 [<ffffffd613857e54>] add_input_randomness+0x38/0x48 [<ffffffd613a80f94>] input_handle_event+0x2b8/0x490 [<ffffffd613a81310>] input_event+0x6c/0x98 According to Guoyong, it's not really possible to refactor the various drivers to never hold a spinlock there. And in_atomic() isn't reliable. So, rather than trying to be too fancy, just punt the change in the static key to a workqueue always. There's basically no drawback of doing this, as the code already needed to account for the static key not changing immediately, and given that it's just an optimization, there's not exactly a hurry to change the static key right away, so deferal is fine. Reported-by: Guoyong Wang <guoyong.wang(a)mediatek.com> Cc: stable(a)vger.kernel.org Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> diff --git a/drivers/char/random.c b/drivers/char/random.c index 456be28ba67c..2597cb43f438 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -702,7 +702,7 @@ static void extract_entropy(void *buf, size_t len) static void __cold _credit_init_bits(size_t bits) { - static struct execute_work set_ready; + static DECLARE_WORK(set_ready, crng_set_ready); unsigned int new, orig, add; unsigned long flags; @@ -718,8 +718,8 @@ static void __cold _credit_init_bits(size_t bits) if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { crng_reseed(NULL); /* Sets crng_init to CRNG_READY under base_crng.lock. */ - if (static_key_initialized) - execute_in_process_context(crng_set_ready, &set_ready); + if (static_key_initialized && system_unbound_wq) + queue_work(system_unbound_wq, &set_ready); atomic_notifier_call_chain(&random_ready_notifier, 0, NULL); wake_up_interruptible(&crng_init_wait); kill_fasync(&fasync, SIGIO, POLL_IN); @@ -890,8 +890,8 @@ void __init random_init(void) /* * If we were initialized by the cpu or bootloader before jump labels - * are initialized, then we should enable the static branch here, where - * it's guaranteed that jump labels have been initialized. + * or workqueues are initialized, then we should enable the static + * branch here, where it's guaranteed that these have been initialized. */ if (!static_branch_likely(&crng_is_ready) && crng_init >= CRNG_READY) crng_set_ready(NULL);

1 year

2
1
0 0

[PATCH 4.19.y v6 2/2] tracing: Use var_refs[] for hist trigger reference checking

by George Guo

From: Tom Zanussi <tzanussi(a)gmail.com> commit e4f6d245031e04bdd12db390298acec0474a1a46 upstream. Since all the variable reference hist_fields are collected into hist_data->var_refs[] array, there's no need to go through all the fields looking for them, or in separate arrays like synth_var_refs[], which will be going away soon anyway. This also allows us to get rid of some unnecessary code and functions currently used for the same purpose. Link: http://lkml.kernel.org/r/1545246556.4239.7.camel@gmail.com Acked-by: Namhyung Kim <namhyung(a)kernel.org> Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Tom Zanussi <tom.zanussi(a)linux.intel.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: George Guo <guodongtai(a)kylinos.cn> --- kernel/trace/trace_events_hist.c | 68 ++++++-------------------------- 1 file changed, 11 insertions(+), 57 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index e4f5b6894cf2..ede370225245 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -1289,49 +1289,13 @@ check_field_for_var_ref(struct hist_field *hist_field, struct hist_trigger_data *var_data, unsigned int var_idx) { - struct hist_field *found = NULL; - - if (hist_field && hist_field->flags & HIST_FIELD_FL_VAR_REF) { - if (hist_field->var.idx == var_idx && - hist_field->var.hist_data == var_data) { - found = hist_field; - } - } - - return found; -} - -static struct hist_field * -check_field_for_var_refs(struct hist_trigger_data *hist_data, - struct hist_field *hist_field, - struct hist_trigger_data *var_data, - unsigned int var_idx, - unsigned int level) -{ - struct hist_field *found = NULL; - unsigned int i; - - if (level > 3) - return found; - - if (!hist_field) - return found; - - found = check_field_for_var_ref(hist_field, var_data, var_idx); - if (found) - return found; - - for (i = 0; i < HIST_FIELD_OPERANDS_MAX; i++) { - struct hist_field *operand; + WARN_ON(!(hist_field && hist_field->flags & HIST_FIELD_FL_VAR_REF)); - operand = hist_field->operands[i]; - found = check_field_for_var_refs(hist_data, operand, var_data, - var_idx, level + 1); - if (found) - return found; - } + if (hist_field && hist_field->var.idx == var_idx && + hist_field->var.hist_data == var_data) + return hist_field; - return found; + return NULL; } /** @@ -1350,26 +1314,16 @@ static struct hist_field *find_var_ref(struct hist_trigger_data *hist_data, struct hist_trigger_data *var_data, unsigned int var_idx) { - struct hist_field *hist_field, *found = NULL; + struct hist_field *hist_field; unsigned int i; - for_each_hist_field(i, hist_data) { - hist_field = hist_data->fields[i]; - found = check_field_for_var_refs(hist_data, hist_field, - var_data, var_idx, 0); - if (found) - return found; - } - - for (i = 0; i < hist_data->n_synth_var_refs; i++) { - hist_field = hist_data->synth_var_refs[i]; - found = check_field_for_var_refs(hist_data, hist_field, - var_data, var_idx, 0); - if (found) - return found; + for (i = 0; i < hist_data->n_var_refs; i++) { + hist_field = hist_data->var_refs[i]; + if (check_field_for_var_ref(hist_field, var_data, var_idx)) + return hist_field; } - return found; + return NULL; } /** -- 2.34.1

1 year

1
0
0 0

[PATCH 4.19.y v6 1/2] tracing: Remove hist trigger synth_var_refs

by George Guo

From: Tom Zanussi <tom.zanussi(a)linux.intel.com> commit 912201345f7c39e6b0ac283207be2b6641fa47b9 upstream. All var_refs are now handled uniformly and there's no reason to treat the synth_refs in a special way now, so remove them and associated functions. Link: http://lkml.kernel.org/r/b4d3470526b8f0426dcec125399dad9ad9b8589d.154516108… Acked-by: Namhyung Kim <namhyung(a)kernel.org> Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Tom Zanussi <tom.zanussi(a)linux.intel.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: George Guo <guodongtai(a)kylinos.cn> --- kernel/trace/trace_events_hist.c | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index e004daf8cad5..e4f5b6894cf2 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -280,8 +280,6 @@ struct hist_trigger_data { struct action_data *actions[HIST_ACTIONS_MAX]; unsigned int n_actions; - struct hist_field *synth_var_refs[SYNTH_FIELDS_MAX]; - unsigned int n_synth_var_refs; struct field_var *field_vars[SYNTH_FIELDS_MAX]; unsigned int n_field_vars; unsigned int n_field_var_str; @@ -3708,20 +3706,6 @@ static void save_field_var(struct hist_trigger_data *hist_data, } -static void destroy_synth_var_refs(struct hist_trigger_data *hist_data) -{ - unsigned int i; - - for (i = 0; i < hist_data->n_synth_var_refs; i++) - destroy_hist_field(hist_data->synth_var_refs[i], 0); -} - -static void save_synth_var_ref(struct hist_trigger_data *hist_data, - struct hist_field *var_ref) -{ - hist_data->synth_var_refs[hist_data->n_synth_var_refs++] = var_ref; -} - static int check_synth_field(struct synth_event *event, struct hist_field *hist_field, unsigned int field_pos) @@ -3884,7 +3868,6 @@ static int onmatch_create(struct hist_trigger_data *hist_data, goto err; } - save_synth_var_ref(hist_data, var_ref); field_pos++; kfree(p); continue; @@ -4631,7 +4614,6 @@ static void destroy_hist_data(struct hist_trigger_data *hist_data) destroy_actions(hist_data); destroy_field_vars(hist_data); destroy_field_var_hists(hist_data); - destroy_synth_var_refs(hist_data); kfree(hist_data); } -- 2.34.1

1 year

1
0
0 0

[PATCH v3 2/2] ALSA: hda/realtek: Fix internal speakers for Legion Y9000X 2022 IAH7

by ArcticLampyrid

This fixes the sound not working from internal speakers on Lenovo Legion Y9000X 2022 IAH7 models. Signed-off-by: ArcticLampyrid <ArcticLampyrid(a)outlook.com> Cc: <stable(a)vger.kernel.org> --- sound/pci/hda/cs35l41_hda_property.c | 2 ++ sound/pci/hda/patch_realtek.c | 1 + 2 files changed, 3 insertions(+) diff --git a/sound/pci/hda/cs35l41_hda_property.c b/sound/pci/hda/cs35l41_hda_property.c index 8fb688e41414..ee195737d388 100644 --- a/sound/pci/hda/cs35l41_hda_property.c +++ b/sound/pci/hda/cs35l41_hda_property.c @@ -109,6 +109,7 @@ static const struct cs35l41_config cs35l41_config_table[] = { { "10431F1F", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 1, -1, 0, 0, 0, 0 }, { "10431F62", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 1, 2, 0, 0, 0, 0 }, { "10433A60", 2, INTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 1, 2, 0, 1000, 4500, 24 }, + { "17AA386E", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 2, -1, 0, 0, 0 }, { "17AA386F", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, -1, -1, 0, 0, 0 }, { "17AA3877", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, -1, 0, 0, 0 }, { "17AA3878", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, -1, 0, 0, 0 }, @@ -500,6 +501,7 @@ static const struct cs35l41_prop_model cs35l41_prop_model_table[] = { { "CSC3551", "10431F1F", generic_dsd_config }, { "CSC3551", "10431F62", generic_dsd_config }, { "CSC3551", "10433A60", generic_dsd_config }, + { "CSC3551", "17AA386E", generic_dsd_config }, { "CSC3551", "17AA386F", generic_dsd_config }, { "CSC3551", "17AA3877", generic_dsd_config }, { "CSC3551", "17AA3878", generic_dsd_config }, diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index cdcb28aa9d7b..ac729187f6a7 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10382,6 +10382,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x3853, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3855, "Legion 7 16ITHG6", ALC287_FIXUP_LEGION_16ITHG6), SND_PCI_QUIRK(0x17aa, 0x3869, "Lenovo Yoga7 14IAL7", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), + SND_PCI_QUIRK(0x17aa, 0x386e, "Legion Y9000X 2022 IAH7", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x17aa, 0x386f, "Legion 7i 16IAX7", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x17aa, 0x3870, "Lenovo Yoga 7 14ARB7", ALC287_FIXUP_YOGA7_14ARB7_I2C), SND_PCI_QUIRK(0x17aa, 0x3877, "Lenovo Legion 7 Slim 16ARHA7", ALC287_FIXUP_CS35L41_I2C_2), -- 2.44.0

1 year

4
4
0 0

[PATCH 2/3] mm/hugetlb: Fix missing hugetlb_lock for resv uncharge

by Peter Xu

There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held. Looks like a stable material, so have it copied. Reported-by: syzbot+4b8077a5fccc61c385a1(a)syzkaller.appspotmail.com Cc: Mina Almasry <almasrymina(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: linux-stable <stable(a)vger.kernel.org> Fixes: 79aa925bf239 ("hugetlb_cgroup: fix reservation accounting") Signed-off-by: Peter Xu <peterx(a)redhat.com> --- mm/hugetlb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 26ab9dfc7d63..3158a55ce567 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3247,9 +3247,12 @@ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, rsv_adjust = hugepage_subpool_put_pages(spool, 1); hugetlb_acct_memory(h, -rsv_adjust); - if (deferred_reserve) + if (deferred_reserve) { + spin_lock_irq(&hugetlb_lock); hugetlb_cgroup_uncharge_folio_rsvd(hstate_index(h), pages_per_huge_page(h), folio); + spin_unlock_irq(&hugetlb_lock); + } } if (!memcg_charge_ret) -- 2.44.0

1 year

2
1
0 0

[PATCH 4.19.y v5 0/2] Double-free bug discovery on testing trigger-field-variable-support.tc

by George Guo

1) About v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch: The reason I am backporting this patch is that no one found the double-free bug at that time, then later the code was removed on upstream, but 4.19-stable has the bug. This is tested via "./ftracetest test.d/trigger/inter-event/ trigger-field-variable-support.tc" ================================================================== BUG: KASAN: use-after-free in destroy_hist_field+0x115/0x140 Read of size 4 at addr ffff888012e95318 by task ftracetest/1858 CPU: 1 PID: 1858 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #24 Source Version: Unknown Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0 Call Trace: dump_stack+0xcb/0x10b print_address_description.cold+0x54/0x249 kasan_report_error.cold+0x63/0xab ? destroy_hist_field+0x115/0x140 __asan_report_load4_noabort+0x8d/0xa0 ? destroy_hist_field+0x115/0x140 destroy_hist_field+0x115/0x140 destroy_hist_data+0x4e4/0x9a0 event_hist_trigger_free+0x212/0x2f0 ? update_cond_flag+0x128/0x170 ? event_hist_trigger_func+0x2880/0x2880 hist_unregister_trigger+0x2f2/0x4f0 event_hist_trigger_func+0x168c/0x2880 ? tracing_map_read_var_once+0xd0/0xd0 ? create_key_field+0x520/0x520 ? __mutex_lock_slowpath+0x10/0x10 event_trigger_write+0x2f4/0x490 ? trigger_start+0x180/0x180 ? __fget_light+0x369/0x5d0 ? count_memcg_event_mm+0x104/0x2b0 ? trigger_start+0x180/0x180 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x540 ksys_write+0x12a/0x290 ? __ia32_sys_read+0xb0/0xb0 ? __close_fd+0x1d3/0x280 do_syscall_64+0xe3/0x2d0 entry_SYSCALL_64_after_hwframe+0x5c/0xc1 RIP: 0033:0x7efdd342ee04 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 RSP: 002b:00007ffda01f5e08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000000000b4 RCX: 00007efdd342ee04 RDX: 00000000000000b4 RSI: 000055c5b41b1e90 RDI: 0000000000000001 RBP: 000055c5b41b1e90 R08: 000000000000000a R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000246 R12: 00007efdd34ed5c0 R13: 00000000000000b4 R14: 00007efdd34ed7c0 R15: 00000000000000b4 ================================================================== 2) About v4-0002-tracing-Use-var_refs-for-hist-trigger-reference-c.patch: Only v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch will lead to compilation errors: ../kernel/trace/trace_events_hist.c: In function ��find_var_ref��: ../kernel/trace/trace_events_hist.c:1364:36: error: ��struct hist_trigger_data�� has no member named ��n_synth_var_refs��; did you mean ��n_var_refs��? 1364 | for (i = 0; i < hist_data->n_synth_var_refs; i++) { | ^~~~~~~~~~~~~~~~ | n_var_refs ../kernel/trace/trace_events_hist.c:1365:41: error: ��struct hist_trigger_data�� has no member named ��synth_var_refs��; did you mean ��n_var_refs��? 1365 | hist_field = hist_data->synth_var_refs[i]; | ^~~~~~~~~~~~~~ | n_var_refs 3) Singing off my name on the V5. Tom Zanussi (2): tracing: Remove hist trigger synth_var_refs tracing: Use var_refs[] for hist trigger reference checking kernel/trace/trace_events_hist.c | 86 ++++---------------------------- 1 file changed, 11 insertions(+), 75 deletions(-) -- 2.34.1

1 year

2
3
0 0

[PATCH] r8169: add missing conditional compiling for call to r8169_remove_leds

by Heiner Kallweit

[ Upstream commit 97e176fcbbf3c0f2bd410c9b241177c051f57176 ] Add missing dependency on CONFIG_R8169_LEDS. As-is a link error occurs if config option CONFIG_R8169_LEDS isn't enabled. Fixes: 19fa4f2a85d7 ("r8169: fix LED-related deadlock on module removal") Cc: <stable(a)vger.kernel.org> # 6.8.x Reported-by: Venkat Rao Bagalkote <venkat88(a)linux.vnet.ibm.com> Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com> --- This for v6.8 only. --- drivers/net/ethernet/realtek/r8169_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index 2cc1c36ab..32b73f398 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -4932,7 +4932,8 @@ static void rtl_remove_one(struct pci_dev *pdev) cancel_work_sync(&tp->wk.work); - r8169_remove_leds(tp->leds); + if (IS_ENABLED(CONFIG_R8169_LEDS)) + r8169_remove_leds(tp->leds); unregister_netdev(tp->dev); -- 2.44.0

1 year

2
1
0 0

[Regression] USB ethernet AX88179 broken usb ethernet names

by Salvatore Bonaccorso

Hi, Roland Rosenfeld reported in Debian a regression after the update to the 6.1.85 based kernel, with his USB ethernet device not anymore able to use the usb ethernet names. https://bugs.debian.org/1069082 it is somehow linked to the already reported regression https://lore.kernel.org/regressions/ZhFl6xueHnuVHKdp@nuc/ but has another aspect. I'm quoting his original report: > Dear Maintainer, > > when upgrading from 6.1.76-1 to 6.1.85-1 my USB ethernet device > ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet > is no longer named enx00249bXXXXXX but eth0. > > I see the following in dmsg: > > [ 1.484345] usb 4-5: Manufacturer: ASIX Elec. Corp. > [ 1.484661] usb 4-5: SerialNumber: 0000249BXXXXXX > [ 1.496312] ax88179_178a 4-5:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, d2:60:4c:YY:YY:YY > [ 1.497746] usbcore: registered new interface driver ax88179_178a > > Unplugging and plugging again does not solve the issue, but the > interface still is named eth0. > > Maybe it has to do with the following commit from > https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85 > > commit fc77240f6316d17fc58a8881927c3732b1d75d51 > Author: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> > Date: Wed Apr 3 15:21:58 2024 +0200 > > net: usb: ax88179_178a: avoid the interface always configured as random address > > commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream. > > After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two > consecutive device resets"), reset is not executed from bind operation and > mac address is not read from the device registers or the devicetree at that > moment. Since the check to configure if the assigned mac address is random > or not for the interface, happens after the bind operation from > usbnet_probe, the interface keeps configured as random address, although the > address is correctly read and set during open operation (the only reset > now). > > In order to keep only one reset for the device and to avoid the interface > always configured as random address, after reset, configure correctly the > suitable field from the driver, if the mac address is read successfully from > the device registers or the devicetree. Take into account if a locally > administered address (random) was previously stored. > > cc: stable(a)vger.kernel.org # 6.6+ > Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets") > Reported-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com> > Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> > Reviewed-by: Simon Horman <horms(a)kernel.org> > Link: https://lore.kernel.org/r/20240403132158.344838-1-jtornosm@redhat.com > Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > Seems, that I'm not alone with this issue, there are also reports in > https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_… > and https://infosec.space/@topher/112276500329020316 > > > All other (pci based) network interfaces still use there static names > (enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with > the new kernel. > > Greetings > Roland Roland confirmed that reverting both fc77240f6316 ("net: usb: ax88179_178a: avoid the interface always configured as random address") and 5c4cbec5106d ("net: usb: ax88179_178a: avoid two consecutive device resets") fixes the problem. Confirmation: https://bugs.debian.org/1069082#27 Regards, Salvatore

1 year

2
2
0 0

FAILED: patch "[PATCH] kprobes: Fix possible use-after-free issue on kprobe" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024041524-monoxide-kilobyte-1c44@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 325f3fb551f8 ("kprobes: Fix possible use-after-free issue on kprobe registration") 1efda38d6f9b ("kprobes: Prohibit probes in gate area") 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") 223a76b268c9 ("kprobes: Fix coding style issues") 9c89bb8e3272 ("kprobes: treewide: Cleanup the error messages for kprobes") 02afb8d6048d ("kprobe: Simplify prepare_kprobe() by dropping redundant version") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 Mon Sep 17 00:00:00 2001 From: Zheng Yejian <zhengyejian1(a)huawei.com> Date: Wed, 10 Apr 2024 09:58:02 +0800 Subject: [PATCH] kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/ Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") Cc: stable(a)vger.kernel.org Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 9d9095e81792..65adc815fc6e 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1567,10 +1567,17 @@ static int check_kprobe_address_safe(struct kprobe *p, jump_label_lock(); preempt_disable(); - /* Ensure it is not in reserved area nor out of text */ - if (!(core_kernel_text((unsigned long) p->addr) || - is_module_text_address((unsigned long) p->addr)) || - in_gate_area_no_mm((unsigned long) p->addr) || + /* Ensure the address is in a text area, and find a module if exists. */ + *probed_mod = NULL; + if (!core_kernel_text((unsigned long) p->addr)) { + *probed_mod = __module_text_address((unsigned long) p->addr); + if (!(*probed_mod)) { + ret = -EINVAL; + goto out; + } + } + /* Ensure it is not in reserved area. */ + if (in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || static_call_text_reserved(p->addr, p->addr) || @@ -1580,8 +1587,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } - /* Check if 'p' is probing a module. */ - *probed_mod = __module_text_address((unsigned long) p->addr); + /* Get module refcount and reject __init functions for loaded modules. */ if (*probed_mod) { /* * We must hold a refcount of the probed module while updating

1 year

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024