April 2023 - Linux-stable-mirror

[PATCH] powercap: intel_rapl: Optimize rp->domains memory allocation

by xiongxin

In the memory allocation of rp->domains in rapl_detect_domains(), there is an additional memory of struct rapl_domain allocated to prevent the pointer out of bounds called later. Optimize the code here to save sizeof(struct rapl_domain) bytes of memory. Test in Intel NUC (i5-1135G7). Cc: stable(a)vger.kernel.org Signed-off-by: xiongxin <xiongxin(a)kylinos.cn> Tested-by: xiongxin <xiongxin(a)kylinos.cn> --- drivers/powercap/intel_rapl_common.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/powercap/intel_rapl_common.c b/drivers/powercap/intel_rapl_common.c index 8970c7b80884..f8971282498a 100644 --- a/drivers/powercap/intel_rapl_common.c +++ b/drivers/powercap/intel_rapl_common.c @@ -1171,13 +1171,14 @@ static int rapl_package_register_powercap(struct rapl_package *rp) { struct rapl_domain *rd; struct powercap_zone *power_zone = NULL; - int nr_pl, ret; + int nr_pl, ret, i; /* Update the domain data of the new package */ rapl_update_domain_data(rp); /* first we register package domain as the parent zone */ - for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) { + for (i = 0; i < rp->nr_domains; i++) { + rd = &rp->domains[i]; if (rd->id == RAPL_DOMAIN_PACKAGE) { nr_pl = find_nr_power_limit(rd); pr_debug("register package domain %s\n", rp->name); @@ -1201,8 +1202,9 @@ static int rapl_package_register_powercap(struct rapl_package *rp) return -ENODEV; } /* now register domains as children of the socket/package */ - for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) { + for (i = 0; i < rp->nr_domains; i++) { struct powercap_zone *parent = rp->power_zone; + rd = &rp->domains[i]; if (rd->id == RAPL_DOMAIN_PACKAGE) continue; @@ -1302,7 +1304,6 @@ static void rapl_detect_powerlimit(struct rapl_domain *rd) */ static int rapl_detect_domains(struct rapl_package *rp, int cpu) { - struct rapl_domain *rd; int i; for (i = 0; i < RAPL_DOMAIN_MAX; i++) { @@ -1319,15 +1320,15 @@ static int rapl_detect_domains(struct rapl_package *rp, int cpu) } pr_debug("found %d domains on %s\n", rp->nr_domains, rp->name); - rp->domains = kcalloc(rp->nr_domains + 1, sizeof(struct rapl_domain), + rp->domains = kcalloc(rp->nr_domains, sizeof(struct rapl_domain), GFP_KERNEL); if (!rp->domains) return -ENOMEM; rapl_init_domains(rp); - for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) - rapl_detect_powerlimit(rd); + for (i = 0; i < rp->nr_domains; i++) + rapl_detect_powerlimit(&rp->domains[i]); return 0; } -- 2.34.1

2 years, 2 months

2
1
0 0

Pozycjonowanie- informacja

by "Przemysław Polak"

Dzień dobry, jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google. Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów. Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę? Pozdrawiam Przemysław Polak

2 years, 2 months

1
0
0 0

[PATCH 0/2] RTW88 USB bug fixes

by Sascha Hauer

This series fixes two bugs in the RTW88 USB driver I was reported from several people and that I also encountered myself. The first one resulted in "timed out to flush queue 3" messages from the driver and sometimes a complete stall of the TX queues. The second one is specific to the RTW8821CU chipset. Here 2GHz networks were hardly seen and impossible to connect to. This goes down to misinterpreting the rfe_option field in the efuse. Sascha Hauer (2): wifi: rtw88: usb: fix priority queue to endpoint mapping wifi: rtw88: rtw8821c: Fix rfe_option field width drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +- drivers/net/wireless/realtek/rtw88/usb.c | 70 +++++++++++++------ 2 files changed, 48 insertions(+), 25 deletions(-) -- 2.39.2

2 years, 2 months

7
9
0 0

[PATCH v7] tty: fix hang on tty device with no_room set

by juanfengpy＠gmail.com

From: Hui Li <caelli(a)tencent.com> We have met a hang on pty device, the reader was blocking at epoll on master side, the writer was sleeping at wait_woken inside n_tty_write on slave side, and the write buffer on tty_port was full, we found that the reader and writer would never be woken again and blocked forever. The problem was caused by a race between reader and kworker: n_tty_read(reader): n_tty_receive_buf_common(kworker): copy_from_read_buf()| |room = N_TTY_BUF_SIZE - (ldata->read_head - tail) |room <= 0 n_tty_kick_worker() | |ldata->no_room = true After writing to slave device, writer wakes up kworker to flush data on tty_port to reader, and the kworker finds that reader has no room to store data so room <= 0 is met. At this moment, reader consumes all the data on reader buffer and calls n_tty_kick_worker to check ldata->no_room which is false and reader quits reading. Then kworker sets ldata->no_room=true and quits too. If write buffer is not full, writer will wake kworker to flush data again after following writes, but if write buffer is full and writer goes to sleep, kworker will never be woken again and tty device is blocked. This problem can be solved with a check for read buffer size inside n_tty_receive_buf_common, if read buffer is empty and ldata->no_room is true, a call to n_tty_kick_worker is necessary to keep flushing data to reader. Cc: <stable(a)vger.kernel.org> Fixes: 42458f41d08f ("n_tty: Ensure reader restarts worker for next reader") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Hui Li <caelli(a)tencent.com> --- Patch changelogs between v1 and v2: -add barrier inside n_tty_read and n_tty_receive_buf_common; -comment why barrier is needed; -access to ldata->no_room is changed with READ_ONCE and WRITE_ONCE; Patch changelogs between v2 and v3: -in function n_tty_receive_buf_common, add unlikely to check ldata->no_room, eg: if (unlikely(ldata->no_room)), and READ_ONCE is removed here to get locality; -change comment for barrier to show the race condition to make comment easier to understand; Patch changelogs between v3 and v4: -change subject from 'tty: fix a possible hang on tty device' to 'tty: fix hang on tty device with no_room set' to make subject more obvious; Patch changelogs between v4 and v5: -name is changed from cael to caelli, li is added as the family name and caelli is the fullname. Patch changelogs between v5 and v6: -change from and Signed-off-by, from 'caelli <juanfengpy(a)gmail.com>' to 'caelli <caelli(a)tencent.com>', later one is my corporate address. Patch changelogs between v6 and v7: -change name from caelli to 'Hui Li', which is my name in chinese. -the comment for barrier is improved, and a Fixes and Reviewed-by tags is added. drivers/tty/n_tty.c | 41 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index c8f56c9b1a1c..8c17304fffcf 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -204,8 +204,8 @@ static void n_tty_kick_worker(struct tty_struct *tty) struct n_tty_data *ldata = tty->disc_data; /* Did the input worker stop? Restart it */ - if (unlikely(ldata->no_room)) { - ldata->no_room = 0; + if (unlikely(READ_ONCE(ldata->no_room))) { + WRITE_ONCE(ldata->no_room, 0); WARN_RATELIMIT(tty->port->itty == NULL, "scheduling with invalid itty\n"); @@ -1698,7 +1698,7 @@ n_tty_receive_buf_common(struct tty_struct *tty, const unsigned char *cp, if (overflow && room < 0) ldata->read_head--; room = overflow; - ldata->no_room = flow && !room; + WRITE_ONCE(ldata->no_room, flow && !room); } else overflow = 0; @@ -1729,6 +1729,27 @@ n_tty_receive_buf_common(struct tty_struct *tty, const unsigned char *cp, } else n_tty_check_throttle(tty); + if (unlikely(ldata->no_room)) { + /* + * Barrier here is to ensure to read the latest read_tail in + * chars_in_buffer() and to make sure that read_tail is not loaded + * before ldata->no_room is set, otherwise, following race may occur: + * n_tty_receive_buf_common() + * n_tty_read() + * if (!chars_in_buffer(tty))->false + * copy_from_read_buf() + * read_tail=commit_head + * n_tty_kick_worker() + * if (ldata->no_room)->false + * ldata->no_room = 1 + * Then both kworker and reader will fail to kick n_tty_kick_worker(), + * smp_mb is paired with smp_mb() in n_tty_read(). + */ + smp_mb(); + if (!chars_in_buffer(tty)) + n_tty_kick_worker(tty); + } + up_read(&tty->termios_rwsem); return rcvd; @@ -2282,8 +2303,25 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct file *file, if (time) timeout = time; } - if (old_tail != ldata->read_tail) + if (old_tail != ldata->read_tail) { + /* + * Make sure no_room is not read in n_tty_kick_worker() + * before setting ldata->read_tail in copy_from_read_buf(), + * otherwise, following race may occur: + * n_tty_read() + * n_tty_receive_buf_common() + * n_tty_kick_worker() + * if(ldata->no_room)->false + * ldata->no_room = 1 + * if (!chars_in_buffer(tty))->false + * copy_from_read_buf() + * read_tail=commit_head + * Both reader and kworker will fail to kick tty_buffer_restart_work(), + * smp_mb is paired with smp_mb() in n_tty_receive_buf_common(). + */ + smp_mb(); n_tty_kick_worker(tty); + } up_read(&tty->termios_rwsem); remove_wait_queue(&tty->read_wait, &wait); -- 2.27.0

2 years, 2 months

3
3
0 0

[RESEND PATCH stable 4.14 4.19 0/2] Backport "KVM: arm64: Filter out invalid core registers IDs in KVM_GET_REG_LIST"

by Takahiro Itazuri

Hi stable maintainers, This is a backport patch for commit df205b5c6328 ("KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST") to 4.14 and 4.19. This commit was not applied to the 4.14-stable tree due to merge conflict [1]. To backport this, commit be25bbb392fa ("KVM: arm64: Factor out core register ID enumeration") that has no functional changes is cherry-picked. I'd appreciate if if you could consider backporting this to 4.14 and 4.19. Best regards, Takahiro [1] https://lore.kernel.org/all/1560343489-22906-1-git-send-email-Dave.Martin@a… Dave Martin (2): KVM: arm64: Factor out core register ID enumeration KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST arch/arm64/kvm/guest.c | 79 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 65 insertions(+), 14 deletions(-) -- 2.39.2

2 years, 2 months

1
2
0 0

Re: [PATCH 5.10] media: ti: cal: revert "media: ti: cal: fix possible memory leak in cal_ctx_create()"

by Greg KH

On Mon, Apr 03, 2023 at 09:11:43PM +0800, cuigaosheng wrote: > On 2023/4/3 20:53, Greg KH wrote: > > On Mon, Apr 03, 2023 at 08:17:04PM +0800, Gaosheng Cui wrote: > > > This reverts commit c7a218cbf67fffcd99b76ae3b5e9c2e8bef17c8c. > > > > > > The memory of ctx is allocated by devm_kzalloc in cal_ctx_create, > > > it should not be freed by kfree when cal_ctx_v4l2_init() fails, > > > otherwise kfree() will cause double free, so revert this patch. > > > > > > Fixes: c7a218cbf67f ("media: ti: cal: fix possible memory leak in cal_ctx_create()") > > > Signed-off-by: Gaosheng Cui <cuigaosheng1(a)huawei.com> > > > --- > > > drivers/media/platform/ti-vpe/cal.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c > > > index 93121c90d76a..2eef245c31a1 100644 > > > --- a/drivers/media/platform/ti-vpe/cal.c > > > +++ b/drivers/media/platform/ti-vpe/cal.c > > > @@ -624,10 +624,8 @@ static struct cal_ctx *cal_ctx_create(struct cal_dev *cal, int inst) > > > ctx->cport = inst; > > > ret = cal_ctx_v4l2_init(ctx); > > > - if (ret) { > > > - kfree(ctx); > > > + if (ret) > > > return NULL; > > > - } > > > return ctx; > > > } > > > -- > > > 2.25.1 > > > > > Why is this not needed to be reverted in Linus's tree first? > > > > thanks, > > > > greg k-h > > . > > Thanks for taking time to review this patch. > > The memory of ctx is allocated by kzalloc since commit 9e67f24e4d90 > ("media: ti-vpe: cal: fix ctx uninitialization"), so the fixes tag > of patch c7a218cbf67fis not entirely accurate, mainline should merge this > patch, but it should not be merged into 5.10, my apologies for > notdiscovering this bug earlier. Gaosheng. > Great, can you please put all of this information in the changelog explaining why this is only needed for this one branch and resend it? thanks, greg k-h

2 years, 2 months

2
1
0 0

[PATCH 5.10,v2] media: ti: cal: revert "media: ti: cal: fix possible memory leak in cal_ctx_create()"

by Gaosheng Cui

This reverts commit c7a218cbf67fffcd99b76ae3b5e9c2e8bef17c8c. The memory of ctx is allocated by devm_kzalloc in cal_ctx_create, it should not be freed by kfree when cal_ctx_v4l2_init() fails, otherwise kfree() will cause double free, so revert this patch. The memory of ctx is allocated by kzalloc since commit 9e67f24e4d9 ("media: ti-vpe: cal: fix ctx uninitialization"), so the fixes tag of patch c7a218cbf67fis not entirely accurate, mainline should merge this patch, but it should not be merged into 5.10, so we just revert this patch for this branch. Fixes: c7a218cbf67f ("media: ti: cal: fix possible memory leak in cal_ctx_create()") Signed-off-by: Gaosheng Cui <cuigaosheng1(a)huawei.com> --- v2: - Update the commit message and explain why this is needed for 5.10 branch, thanks! drivers/media/platform/ti-vpe/cal.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c index 93121c90d76a..2eef245c31a1 100644 --- a/drivers/media/platform/ti-vpe/cal.c +++ b/drivers/media/platform/ti-vpe/cal.c @@ -624,10 +624,8 @@ static struct cal_ctx *cal_ctx_create(struct cal_dev *cal, int inst) ctx->cport = inst; ret = cal_ctx_v4l2_init(ctx); - if (ret) { - kfree(ctx); + if (ret) return NULL; - } return ctx; } -- 2.25.1

2 years, 2 months

1
0
0 0

[PATCH stable 4.14 4.19 0/2] Backport "KVM: arm64: Filter out"

by Takahiro Itazuri

Hi stable maintainers, This is a backport patch for commit df205b5c6328 ("KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST") to 4.14 and 4.19. This commit was not applied to the 4.14-stable tree due to merge conflict [1]. To backport this, commit be25bbb392fa ("KVM: arm64: Factor out core register ID enumeration") that has no functional changes is cherry-picked. I'd appreciate if if you could consider backporting this to 4.14 and 4.19. Best regards, Takahiro [1] https://lore.kernel.org/all/1560343489-22906-1-git-send-email-Dave.Martin@a… Dave Martin (2): KVM: arm64: Factor out core register ID enumeration KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST arch/arm64/kvm/guest.c | 79 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 65 insertions(+), 14 deletions(-) -- 2.39.2

2 years, 2 months

1
2
0 0

[for-linus][PATCH 5/6] tracing/osnoise: Fix notify new tracing_max_latency

by Steven Rostedt

From: Daniel Bristot de Oliveira <bristot(a)kernel.org> osnoise/timerlat tracers are reporting new max latency on instances where the tracing is off, creating inconsistencies between the max reported values in the trace and in the tracing_max_latency. Thus only report new tracing_max_latency on active tracing instances. Link: https://lkml.kernel.org/r/ecd109fde4a0c24ab0f00ba1e9a144ac19a91322.16801041… Cc: stable(a)vger.kernel.org Fixes: dae181349f1e ("tracing/osnoise: Support a list of trace_array *tr") Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace_osnoise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index e8116094bed8..4496975f2029 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -1296,7 +1296,7 @@ static void notify_new_max_latency(u64 latency) rcu_read_lock(); list_for_each_entry_rcu(inst, &osnoise_instances, list) { tr = inst->tr; - if (tr->max_latency < latency) { + if (tracer_tracing_is_on(tr) && tr->max_latency < latency) { tr->max_latency = latency; latency_fsnotify(tr); } -- 2.39.2

2 years, 2 months

1
0
0 0

[for-linus][PATCH 4/6] tracing/timerlat: Notify new max thread latency

by Steven Rostedt

From: Daniel Bristot de Oliveira <bristot(a)kernel.org> timerlat is not reporting a new tracing_max_latency for the thread latency. The reason is that it is not calling notify_new_max_latency() function after the new thread latency is sampled. Call notify_new_max_latency() after computing the thread latency. Link: https://lkml.kernel.org/r/16e18d61d69073d0192ace07bf61e405cca96e9c.16801041… Cc: stable(a)vger.kernel.org Fixes: dae181349f1e ("tracing/osnoise: Support a list of trace_array *tr") Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace_osnoise.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index 9176bb7a9bb4..e8116094bed8 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -1738,6 +1738,8 @@ static int timerlat_main(void *data) trace_timerlat_sample(&s); + notify_new_max_latency(diff); + timerlat_dump_stack(time_to_us(diff)); tlat->tracing_thread = false; -- 2.39.2

2 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2023