November 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] mm/damon/core: handle zero {aggregation,ops_update} intervals" 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 3488af0970445ff5532c7e8dc5e6456b877aee5e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024111132-portal-crowbar-256b@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3488af0970445ff5532c7e8dc5e6456b877aee5e Mon Sep 17 00:00:00 2001 From: SeongJae Park <sj(a)kernel.org> Date: Thu, 31 Oct 2024 11:37:56 -0700 Subject: [PATCH] mm/damon/core: handle zero {aggregation,ops_update} intervals Patch series "mm/damon/core: fix handling of zero non-sampling intervals". DAMON's internal intervals accounting logic is not correctly handling non-sampling intervals of zero values for a wrong assumption. This could cause unexpected monitoring behavior, and even result in infinite hang of DAMON sysfs interface user threads in case of zero aggregation interval. Fix those by updating the intervals accounting logic. For details of the root case and solutions, please refer to commit messages of fixes. This patch (of 2): DAMON's logics to determine if this is the time to do aggregation and ops update assumes next_{aggregation,ops_update}_sis are always set larger than current passed_sample_intervals. And therefore it further assumes continuously incrementing passed_sample_intervals every sampling interval will make it reaches to the next_{aggregation,ops_update}_sis in future. The logic therefore make the action and update next_{aggregation,ops_updaste}_sis only if passed_sample_intervals is same to the counts, respectively. If Aggregation interval or Ops update interval are zero, however, next_aggregation_sis or next_ops_update_sis are set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_{aggregation,ops_update}_sis check. Hence, passed_sample_intervals becomes larger than next_{aggregation,ops_update}_sis, and the logic says it is not the time to do the action and update next_{aggregation,ops_update}_sis forever, until an overflow happens. In other words, DAMON stops doing aggregations or ops updates effectively forever, and users cannot get monitoring results. Based on the documents and the common sense, a reasonable behavior for such inputs is doing an aggregation and an ops update for every sampling interval. Handle the case by removing the assumption. Note that this could incur particular real issue for DAMON sysfs interface users, in case of zero Aggregation interval. When user starts DAMON with zero Aggregation interval and asks online DAMON parameter tuning via DAMON sysfs interface, the request is handled by the aggregation callback. Until the callback finishes the work, the user who requested the online tuning just waits. Hence, the user will be stuck until the passed_sample_intervals overflows. Link: https://lkml.kernel.org/r/20241031183757.49610-1-sj@kernel.org Link: https://lkml.kernel.org/r/20241031183757.49610-2-sj@kernel.org Fixes: 4472edf63d66 ("mm/damon/core: use number of passed access sampling as a timer") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.7.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/damon/core.c b/mm/damon/core.c index a83f3b736d51..3131a07569e4 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2000,7 +2000,7 @@ static int kdamond_fn(void *data) if (ctx->ops.check_accesses) max_nr_accesses = ctx->ops.check_accesses(ctx); - if (ctx->passed_sample_intervals == next_aggregation_sis) { + if (ctx->passed_sample_intervals >= next_aggregation_sis) { kdamond_merge_regions(ctx, max_nr_accesses / 10, sz_limit); @@ -2018,7 +2018,7 @@ static int kdamond_fn(void *data) sample_interval = ctx->attrs.sample_interval ? ctx->attrs.sample_interval : 1; - if (ctx->passed_sample_intervals == next_aggregation_sis) { + if (ctx->passed_sample_intervals >= next_aggregation_sis) { ctx->next_aggregation_sis = next_aggregation_sis + ctx->attrs.aggr_interval / sample_interval; @@ -2028,7 +2028,7 @@ static int kdamond_fn(void *data) ctx->ops.reset_aggregated(ctx); } - if (ctx->passed_sample_intervals == next_ops_update_sis) { + if (ctx->passed_sample_intervals >= next_ops_update_sis) { ctx->next_ops_update_sis = next_ops_update_sis + ctx->attrs.ops_update_interval / sample_interval;

1 month, 4 weeks

2
1
0 0

Re: [merged mm-stable] zram-clear-idle-flag-after-recompression.patch removed from -mm tree

by Brian Geffon

On Mon, Nov 11, 2024 at 8:42 AM Brian Geffon <bgeffon(a)google.com> wrote: > > On Mon, Nov 11, 2024 at 3:28 AM Andrew Morton <akpm(a)linux-foundation.org> wrote: > > > > > > The quilt patch titled > > Subject: zram: clear IDLE flag after recompression > > has been removed from the -mm tree. Its filename was > > zram-clear-idle-flag-after-recompression.patch > > > > This patch was dropped because it was merged into the mm-stable branch > > of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > > > ------------------------------------------------------ > > From: Sergey Senozhatsky <senozhatsky(a)chromium.org> > > Subject: zram: clear IDLE flag after recompression > > Date: Tue, 29 Oct 2024 00:36:14 +0900 > > > > Patch series "zram: IDLE flag handling fixes", v2. > > > > zram can wrongly preserve ZRAM_IDLE flag on its entries which can result > > in premature post-processing (writeback and recompression) of such > > entries. > > > > > > This patch (of 2) > > > > Recompression should clear ZRAM_IDLE flag on the entries it has accessed, > > because otherwise some entries, specifically those for which recompression > > has failed, become immediate candidate entries for another post-processing > > (e.g. writeback). > > > > Consider the following case: > > - recompression marks entries IDLE every 4 hours and attempts > > to recompress them > > - some entries are incompressible, so we keep them intact and > > hence preserve IDLE flag > > - writeback marks entries IDLE every 8 hours and writebacks > > IDLE entries, however we have IDLE entries left from > > recompression, so writeback prematurely writebacks those > > entries. > > > > The bug was reported by Shin Kawamura. > > > > Link: https://lkml.kernel.org/r/20241028153629.1479791-1-senozhatsky@chromium.org > > Link: https://lkml.kernel.org/r/20241028153629.1479791-2-senozhatsky@chromium.org > > Fixes: 84b33bf78889 ("zram: introduce recompress sysfs knob") > > Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> > > Reported-by: Shin Kawamura <kawasin(a)google.com> > > Acked-by: Brian Geffon <bgeffon(a)google.com> > > Cc: Minchan Kim <minchan(a)kernel.org> Cc: stable(a)vger.kernel.org > > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > > --- > > > > drivers/block/zram/zram_drv.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > --- a/drivers/block/zram/zram_drv.c~zram-clear-idle-flag-after-recompression > > +++ a/drivers/block/zram/zram_drv.c > > @@ -1864,6 +1864,13 @@ static int recompress_slot(struct zram * > > if (ret) > > return ret; > > > > + /* > > + * We touched this entry so mark it as non-IDLE. This makes sure that > > + * we don't preserve IDLE flag and don't incorrectly pick this entry > > + * for different post-processing type (e.g. writeback). > > + */ > > + zram_clear_flag(zram, index, ZRAM_IDLE); > > + > > class_index_old = zs_lookup_class_index(zram->mem_pool, comp_len_old); > > /* > > * Iterate the secondary comp algorithms list (in order of priority) > > _ > > > > Patches currently in -mm which might be from senozhatsky(a)chromium.org are > > > >

1 month, 4 weeks

2
1
0 0

Passenger traffic Expo 2024

by Camille Batiste

Hey, Would you be interested in acquiring the attendees list of Passenger traffic Expo 2024? List contains: Names, Titles, Phone Numbers, Company Details, and more… Interested? Let me know so that I’ll send you the pricing for the same. Kind Regards, Camille Batiste Marketing Executive If you do not wish to receive our emails, please reply with "Not Interested."

1 month, 4 weeks

1
0
0 0

[PATCH] ftrace: Fix possible use-after-free issue in ftrace_location()

by Hagar Hemdan

From: Zheng Yejian <zhengyejian1(a)huawei.com> commit e60b613df8b6253def41215402f72986fee3fc8d upstream. KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in ftrace_location_range(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). Link: https://lore.kernel.org/linux-trace-kernel/20240509192859.1273558-1-zhengye… Cc: stable(a)vger.kernel.org Cc: <mhiramat(a)kernel.org> Cc: <mark.rutland(a)arm.com> Cc: <mathieu.desnoyers(a)efficios.com> Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization") Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> [Hagar: Modified to apply on v5.4.y] Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> --- only compile tested. --- kernel/trace/ftrace.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 412505d94865..60bf8a6d55ce 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1552,7 +1552,9 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) struct ftrace_page *pg; struct dyn_ftrace *rec; struct dyn_ftrace key; + unsigned long ip = 0; + rcu_read_lock(); key.ip = start; key.flags = end; /* overload flags, as it is unsigned long */ @@ -1565,10 +1567,13 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) sizeof(struct dyn_ftrace), ftrace_cmp_recs); if (rec) - return rec->ip; + { + ip = rec->ip; + break; + } } - - return 0; + rcu_read_unlock(); + return ip; } /** @@ -5736,6 +5741,8 @@ static int ftrace_process_locs(struct module *mod, /* We should have used all pages unless we skipped some */ if (pg_unuse) { WARN_ON(!skipped); + /* Need to synchronize with ftrace_location_range() */ + synchronize_rcu(); ftrace_free_pages(pg_unuse); } return ret; @@ -5889,6 +5896,9 @@ void ftrace_release_mod(struct module *mod) out_unlock: mutex_unlock(&ftrace_lock); + /* Need to synchronize with ftrace_location_range() */ + if (tmp_page) + synchronize_rcu(); for (pg = tmp_page; pg; pg = tmp_page) { /* Needs to be called outside of ftrace_lock */ @@ -6196,6 +6206,7 @@ void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) unsigned long start = (unsigned long)(start_ptr); unsigned long end = (unsigned long)(end_ptr); struct ftrace_page **last_pg = &ftrace_pages_start; + struct ftrace_page *tmp_page = NULL; struct ftrace_page *pg; struct dyn_ftrace *rec; struct dyn_ftrace key; @@ -6239,12 +6250,8 @@ void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) ftrace_update_tot_cnt--; if (!pg->index) { *last_pg = pg->next; - if (pg->records) { - free_pages((unsigned long)pg->records, pg->order); - ftrace_number_of_pages -= 1 << pg->order; - } - ftrace_number_of_groups--; - kfree(pg); + pg->next = tmp_page; + tmp_page = pg; pg = container_of(last_pg, struct ftrace_page, next); if (!(*last_pg)) ftrace_pages = pg; @@ -6261,6 +6268,11 @@ void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) clear_func_from_hashes(func); kfree(func); } + /* Need to synchronize with ftrace_location_range() */ + if (tmp_page) { + synchronize_rcu(); + ftrace_free_pages(tmp_page); + } } void __init ftrace_free_init_mem(void) -- 2.40.1

1 month, 4 weeks

1
0
0 0

[PATCH] usb: dwc3: gadget: Add TxFIFO resizing supports for single port RAM

by Selvarasu Ganesan

This commit adds support for resizing the TxFIFO in USB2.0-only mode where using single port RAM, and limit the use of extra FIFOs for bulk transfers in non-SS mode. It prevents the issue of limited RAM size usage. Fixes: fad16c823e66 ("usb: dwc3: gadget: Refine the logic for resizing Tx FIFOs") Cc: stable(a)vger.kernel.org # 6.12.x: fad16c82: usb: dwc3: gadget: Refine the logic for resizing Tx FIFOs Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- drivers/usb/dwc3/core.h | 4 +++ drivers/usb/dwc3/gadget.c | 56 ++++++++++++++++++++++++++++++--------- 2 files changed, 48 insertions(+), 12 deletions(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index eaa55c0cf62f..8306b39e5c64 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -915,6 +915,7 @@ struct dwc3_hwparams { #define DWC3_MODE(n) ((n) & 0x7) /* HWPARAMS1 */ +#define DWC3_SPRAM_TYPE(n) (((n) >> 23) & 1) #define DWC3_NUM_INT(n) (((n) & (0x3f << 15)) >> 15) /* HWPARAMS3 */ @@ -925,6 +926,9 @@ struct dwc3_hwparams { #define DWC3_NUM_IN_EPS(p) (((p)->hwparams3 & \ (DWC3_NUM_IN_EPS_MASK)) >> 18) +/* HWPARAMS6 */ +#define DWC3_RAM0_DEPTH(n) (((n) & (0xffff0000)) >> 16) + /* HWPARAMS7 */ #define DWC3_RAM1_DEPTH(n) ((n) & 0xffff) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 2fed2aa01407..d3e25f7d7cd0 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -687,6 +687,42 @@ static int dwc3_gadget_calc_tx_fifo_size(struct dwc3 *dwc, int mult) return fifo_size; } +/** + * dwc3_gadget_calc_ram_depth - calculates the ram depth for txfifo + * @dwc: pointer to the DWC3 context + */ +static int dwc3_gadget_calc_ram_depth(struct dwc3 *dwc) +{ + int ram_depth; + int fifo_0_start; + bool spram_type; + int tmp; + + /* Check supporting RAM type by HW */ + spram_type = DWC3_SPRAM_TYPE(dwc->hwparams.hwparams1); + + /* If a single port RAM is utilized, then allocate TxFIFOs from + * RAM0. otherwise, allocate them from RAM1. + */ + ram_depth = spram_type ? DWC3_RAM0_DEPTH(dwc->hwparams.hwparams6) : + DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7); + + + /* In a single port RAM configuration, the available RAM is shared + * between the RX and TX FIFOs. This means that the txfifo can begin + * at a non-zero address. + */ + if (spram_type) { + /* Check if TXFIFOs start at non-zero addr */ + tmp = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0)); + fifo_0_start = DWC3_GTXFIFOSIZ_TXFSTADDR(tmp); + + ram_depth -= (fifo_0_start >> 16); + } + + return ram_depth; +} + /** * dwc3_gadget_clear_tx_fifos - Clears txfifo allocation * @dwc: pointer to the DWC3 context @@ -753,7 +789,7 @@ static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep) { struct dwc3 *dwc = dep->dwc; int fifo_0_start; - int ram1_depth; + int ram_depth; int fifo_size; int min_depth; int num_in_ep; @@ -773,7 +809,7 @@ static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep) if (dep->flags & DWC3_EP_TXFIFO_RESIZED) return 0; - ram1_depth = DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7); + ram_depth = dwc3_gadget_calc_ram_depth(dwc); switch (dwc->gadget->speed) { case USB_SPEED_SUPER_PLUS: @@ -792,10 +828,6 @@ static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep) break; } fallthrough; - case USB_SPEED_FULL: - if (usb_endpoint_xfer_bulk(dep->endpoint.desc)) - num_fifos = 2; - break; default: break; } @@ -809,7 +841,7 @@ static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep) /* Reserve at least one FIFO for the number of IN EPs */ min_depth = num_in_ep * (fifo + 1); - remaining = ram1_depth - min_depth - dwc->last_fifo_depth; + remaining = ram_depth - min_depth - dwc->last_fifo_depth; remaining = max_t(int, 0, remaining); /* * We've already reserved 1 FIFO per EP, so check what we can fit in @@ -835,9 +867,9 @@ static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep) dwc->last_fifo_depth += DWC31_GTXFIFOSIZ_TXFDEP(fifo_size); /* Check fifo size allocation doesn't exceed available RAM size. */ - if (dwc->last_fifo_depth >= ram1_depth) { + if (dwc->last_fifo_depth >= ram_depth) { dev_err(dwc->dev, "Fifosize(%d) > RAM size(%d) %s depth:%d\n", - dwc->last_fifo_depth, ram1_depth, + dwc->last_fifo_depth, ram_depth, dep->endpoint.name, fifo_size); if (DWC3_IP_IS(DWC3)) fifo_size = DWC3_GTXFIFOSIZ_TXFDEP(fifo_size); @@ -3090,7 +3122,7 @@ static int dwc3_gadget_check_config(struct usb_gadget *g) struct dwc3 *dwc = gadget_to_dwc(g); struct usb_ep *ep; int fifo_size = 0; - int ram1_depth; + int ram_depth; int ep_num = 0; if (!dwc->do_fifo_resize) @@ -3113,8 +3145,8 @@ static int dwc3_gadget_check_config(struct usb_gadget *g) fifo_size += dwc->max_cfg_eps; /* Check if we can fit a single fifo per endpoint */ - ram1_depth = DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7); - if (fifo_size > ram1_depth) + ram_depth = dwc3_gadget_calc_ram_depth(dwc); + if (fifo_size > ram_depth) return -ENOMEM; return 0; -- 2.17.1

1 month, 4 weeks

2
4
0 0

Re: [merged mm-stable] zram-clear-idle-flag-in-mark_idle.patch removed from -mm tree

by Brian Geffon

On Mon, Nov 11, 2024 at 3:28 AM Andrew Morton <akpm(a)linux-foundation.org> wrote: > > > The quilt patch titled > Subject: zram: clear IDLE flag in mark_idle() > has been removed from the -mm tree. Its filename was > zram-clear-idle-flag-in-mark_idle.patch > > This patch was dropped because it was merged into the mm-stable branch > of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm I think this also needs to be Cc'd to stable. > > ------------------------------------------------------ > From: Sergey Senozhatsky <senozhatsky(a)chromium.org> > Subject: zram: clear IDLE flag in mark_idle() > Date: Tue, 29 Oct 2024 00:36:15 +0900 > > If entry does not fulfill current mark_idle() parameters, e.g. cutoff > time, then we should clear its ZRAM_IDLE from previous mark_idle() > invocations. > > Consider the following case: > - mark_idle() cutoff time 8h > - mark_idle() cutoff time 4h > - writeback() idle - will writeback entries with cutoff time 8h, > while it should only pick entries with cutoff time 4h > > The bug was reported by Shin Kawamura. > > Link: https://lkml.kernel.org/r/20241028153629.1479791-3-senozhatsky@chromium.org > Fixes: 755804d16965 ("zram: introduce an aged idle interface") > Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> > Reported-by: Shin Kawamura <kawasin(a)google.com> > Acked-by: Brian Geffon <bgeffon(a)google.com> > Cc: Minchan Kim <minchan(a)kernel.org> Cc: stable(a)vger.kernel.org > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > --- > > drivers/block/zram/zram_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > --- a/drivers/block/zram/zram_drv.c~zram-clear-idle-flag-in-mark_idle > +++ a/drivers/block/zram/zram_drv.c > @@ -410,6 +410,8 @@ static void mark_idle(struct zram *zram, > #endif > if (is_idle) > zram_set_flag(zram, index, ZRAM_IDLE); > + else > + zram_clear_flag(zram, index, ZRAM_IDLE); > zram_slot_unlock(zram, index); > } > } > _ > > Patches currently in -mm which might be from senozhatsky(a)chromium.org are > >

1 month, 4 weeks

1
0
0 0

[PATCH net] wifi: brcmfmac: release 'root' node in all execution paths

by Javier Carrasco

The fixed patch introduced an additional condition to enter the scope where the 'root' device_node is released (!settings->board_type, currently 'err'), which avoid decrementing the refcount with a call to of_node_put() if that second condition is not satisfied. Move the call to of_node_put() to the point where 'root' is no longer required to avoid leaking the resource if err is not zero. Cc: stable(a)vger.kernel.org Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Note that a call to of_node_put() on a NULL device_node has no effect, which simplifies this patch as there is no need to refactor the or add more conditions. --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c index fe4f65756105..af930e34c21f 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c @@ -110,9 +110,8 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type, } strreplace(board_type, '/', '-'); settings->board_type = board_type; - - of_node_put(root); } + of_node_put(root); if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac")) return; --- base-commit: c05c62850a8f035a267151dd86ea3daf887e28b8 change-id: 20241030-brcmfmac-of-cleanup-000fe98821df Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

1 month, 4 weeks

2
3
0 0

FAILED: patch "[PATCH] staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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-4.19.y git checkout FETCH_HEAD git cherry-pick -x 404b739e895522838f1abdc340c554654d671dde # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024111133-accuracy-doozy-8ba2@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 404b739e895522838f1abdc340c554654d671dde Mon Sep 17 00:00:00 2001 From: Umang Jain <umang.jain(a)ideasonboard.com> Date: Wed, 16 Oct 2024 18:32:24 +0530 Subject: [PATCH] staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation The struct vchiq_arm_state 'platform_state' is currently allocated dynamically using kzalloc(). Unfortunately, it is never freed and is subjected to memory leaks in the error handling paths of the probe() function. To address the issue, use device resource management helper devm_kzalloc(), to ensure cleanup after its allocation. Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver") Cc: stable(a)vger.kernel.org Signed-off-by: Umang Jain <umang.jain(a)ideasonboard.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c index 3dbeffc650d3..0d8d5555e8af 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c @@ -593,7 +593,7 @@ vchiq_platform_init_state(struct vchiq_state *state) { struct vchiq_arm_state *platform_state; - platform_state = kzalloc(sizeof(*platform_state), GFP_KERNEL); + platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL); if (!platform_state) return -ENOMEM;

1 month, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state" 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 404b739e895522838f1abdc340c554654d671dde # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024111130-spearman-gratified-fd88@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 404b739e895522838f1abdc340c554654d671dde Mon Sep 17 00:00:00 2001 From: Umang Jain <umang.jain(a)ideasonboard.com> Date: Wed, 16 Oct 2024 18:32:24 +0530 Subject: [PATCH] staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation The struct vchiq_arm_state 'platform_state' is currently allocated dynamically using kzalloc(). Unfortunately, it is never freed and is subjected to memory leaks in the error handling paths of the probe() function. To address the issue, use device resource management helper devm_kzalloc(), to ensure cleanup after its allocation. Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver") Cc: stable(a)vger.kernel.org Signed-off-by: Umang Jain <umang.jain(a)ideasonboard.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c index 3dbeffc650d3..0d8d5555e8af 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c @@ -593,7 +593,7 @@ vchiq_platform_init_state(struct vchiq_state *state) { struct vchiq_arm_state *platform_state; - platform_state = kzalloc(sizeof(*platform_state), GFP_KERNEL); + platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL); if (!platform_state) return -ENOMEM;

1 month, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state" 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 404b739e895522838f1abdc340c554654d671dde # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024111127-rectal-glandular-3e3c@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 404b739e895522838f1abdc340c554654d671dde Mon Sep 17 00:00:00 2001 From: Umang Jain <umang.jain(a)ideasonboard.com> Date: Wed, 16 Oct 2024 18:32:24 +0530 Subject: [PATCH] staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation The struct vchiq_arm_state 'platform_state' is currently allocated dynamically using kzalloc(). Unfortunately, it is never freed and is subjected to memory leaks in the error handling paths of the probe() function. To address the issue, use device resource management helper devm_kzalloc(), to ensure cleanup after its allocation. Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver") Cc: stable(a)vger.kernel.org Signed-off-by: Umang Jain <umang.jain(a)ideasonboard.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c index 3dbeffc650d3..0d8d5555e8af 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c @@ -593,7 +593,7 @@ vchiq_platform_init_state(struct vchiq_state *state) { struct vchiq_arm_state *platform_state; - platform_state = kzalloc(sizeof(*platform_state), GFP_KERNEL); + platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL); if (!platform_state) return -ENOMEM;

1 month, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024