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

[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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

1
0
0 0

[for-linus][PATCH 3/6] ftrace: Mark get_lock_parent_ip() __always_inline

by Steven Rostedt

From: John Keeping <john(a)metanate.com> If the compiler decides not to inline this function then preemption tracing will always show an IP inside the preemption disabling path and never the function actually calling preempt_{enable,disable}. Link: https://lore.kernel.org/linux-trace-kernel/20230327173647.1690849-1-john@me… Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: stable(a)vger.kernel.org Fixes: f904f58263e1d ("sched/debug: Fix preempt_disable_ip recording for preempt_disable()") Signed-off-by: John Keeping <john(a)metanate.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- include/linux/ftrace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index 366c730beaa3..402fc061de75 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -980,7 +980,7 @@ static inline void __ftrace_enabled_restore(int enabled) #define CALLER_ADDR5 ((unsigned long)ftrace_return_address(5)) #define CALLER_ADDR6 ((unsigned long)ftrace_return_address(6)) -static inline unsigned long get_lock_parent_ip(void) +static __always_inline unsigned long get_lock_parent_ip(void) { unsigned long addr = CALLER_ADDR0; -- 2.39.2

2 years, 5 months

1
0
0 0

[for-linus][PATCH 2/6] ring-buffer: Fix race while reader and writer are on the same page

by Steven Rostedt

From: Zheng Yejian <zhengyejian1(a)huawei.com> When user reads file 'trace_pipe', kernel keeps printing following logs that warn at "cpu_buffer->reader_page->read > rb_page_size(reader)" in rb_get_reader_page(). It just looks like there's an infinite loop in tracing_read_pipe(). This problem occurs several times on arm64 platform when testing v5.10 and below. Call trace: rb_get_reader_page+0x248/0x1300 rb_buffer_peek+0x34/0x160 ring_buffer_peek+0xbc/0x224 peek_next_entry+0x98/0xbc __find_next_entry+0xc4/0x1c0 trace_find_next_entry_inc+0x30/0x94 tracing_read_pipe+0x198/0x304 vfs_read+0xb4/0x1e0 ksys_read+0x74/0x100 __arm64_sys_read+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0x94 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Then I dump the vmcore and look into the problematic per_cpu ring_buffer, I found that tail_page/commit_page/reader_page are on the same page while reader_page->read is obviously abnormal: tail_page == commit_page == reader_page == { .write = 0x100d20, .read = 0x8f9f4805, // Far greater than 0xd20, obviously abnormal!!! .entries = 0x10004c, .real_end = 0x0, .page = { .time_stamp = 0x857257416af0, .commit = 0xd20, // This page hasn't been full filled. // .data[0...0xd20] seems normal. } } The root cause is most likely the race that reader and writer are on the same page while reader saw an event that not fully committed by writer. To fix this, add memory barriers to make sure the reader can see the content of what is committed. Since commit a0fcaaed0c46 ("ring-buffer: Fix race between reset page and reading page") has added the read barrier in rb_get_reader_page(), here we just need to add the write barrier. Link: https://lore.kernel.org/linux-trace-kernel/20230325021247.2923907-1-zhengye… Cc: stable(a)vger.kernel.org Fixes: 77ae365eca89 ("ring-buffer: make lockless") Suggested-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index c6f47b6cfd5f..76a2d91eecad 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3098,6 +3098,10 @@ rb_set_commit_to_write(struct ring_buffer_per_cpu *cpu_buffer) if (RB_WARN_ON(cpu_buffer, rb_is_reader_page(cpu_buffer->tail_page))) return; + /* + * No need for a memory barrier here, as the update + * of the tail_page did it for this page. + */ local_set(&cpu_buffer->commit_page->page->commit, rb_page_write(cpu_buffer->commit_page)); rb_inc_page(&cpu_buffer->commit_page); @@ -3107,6 +3111,8 @@ rb_set_commit_to_write(struct ring_buffer_per_cpu *cpu_buffer) while (rb_commit_index(cpu_buffer) != rb_page_write(cpu_buffer->commit_page)) { + /* Make sure the readers see the content of what is committed. */ + smp_wmb(); local_set(&cpu_buffer->commit_page->page->commit, rb_page_write(cpu_buffer->commit_page)); RB_WARN_ON(cpu_buffer, @@ -4684,7 +4690,12 @@ rb_get_reader_page(struct ring_buffer_per_cpu *cpu_buffer) /* * Make sure we see any padding after the write update - * (see rb_reset_tail()) + * (see rb_reset_tail()). + * + * In addition, a writer may be writing on the reader page + * if the page has not been fully filled, so the read barrier + * is also needed to make sure we see the content of what is + * committed by the writer (see rb_set_commit_to_write()). */ smp_rmb(); -- 2.39.2

2 years, 5 months

1
0
0 0

[for-linus][PATCH 1/6] tracing/synthetic: Fix races on freeing last_cmd

by Steven Rostedt

From: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> Currently, the "last_cmd" variable can be accessed by multiple processes asynchronously when multiple users manipulate synthetic_events node at the same time, it could lead to use-after-free or double-free. This patch add "lastcmd_mutex" to prevent "last_cmd" from being accessed asynchronously. ================================================================ It's easy to reproduce in the KASAN environment by running the two scripts below in different shells. script 1: while : do echo -n -e '\x88' > /sys/kernel/tracing/synthetic_events done script 2: while : do echo -n -e '\xb0' > /sys/kernel/tracing/synthetic_events done ================================================================ double-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.free last_cmd(double-free) ================================================================ use-after-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.tracing_log_err(use-after-free) ================================================================ Appendix 1. KASAN report double-free: BUG: KASAN: double-free in kfree+0xdc/0x1d4 Free of addr ***** by task sh/4879 Call trace: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 4879: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x6c/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5464: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... ================================================================ Appendix 2. KASAN report use-after-free: BUG: KASAN: use-after-free in strlen+0x5c/0x7c Read of size 1 at addr ***** by task sh/5483 sh: CPU: 7 PID: 5483 Comm: sh ... __asan_report_load1_noabort+0x34/0x44 strlen+0x5c/0x7c tracing_log_err+0x60/0x444 create_or_delete_synth_event+0xc4/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 5483: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x80/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5480: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x74/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Link: https://lore.kernel.org/linux-trace-kernel/20230321110444.1587-1-Tze-nan.Wu… Fixes: 27c888da9867 ("tracing: Remove size restriction on synthetic event cmd error logging") Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Cc: "Tom Zanussi" <zanussi(a)kernel.org> Signed-off-by: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace_events_synth.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c index 46d0abb32d0f..f0ff730125bf 100644 --- a/kernel/trace/trace_events_synth.c +++ b/kernel/trace/trace_events_synth.c @@ -44,14 +44,21 @@ enum { ERRORS }; static const char *err_text[] = { ERRORS }; +DEFINE_MUTEX(lastcmd_mutex); static char *last_cmd; static int errpos(const char *str) { + int ret = 0; + + mutex_lock(&lastcmd_mutex); if (!str || !last_cmd) - return 0; + goto out; - return err_pos(last_cmd, str); + ret = err_pos(last_cmd, str); + out: + mutex_unlock(&lastcmd_mutex); + return ret; } static void last_cmd_set(const char *str) @@ -59,18 +66,22 @@ static void last_cmd_set(const char *str) if (!str) return; + mutex_lock(&lastcmd_mutex); kfree(last_cmd); - last_cmd = kstrdup(str, GFP_KERNEL); + mutex_unlock(&lastcmd_mutex); } static void synth_err(u8 err_type, u16 err_pos) { + mutex_lock(&lastcmd_mutex); if (!last_cmd) - return; + goto out; tracing_log_err(NULL, "synthetic_events", last_cmd, err_text, err_type, err_pos); + out: + mutex_unlock(&lastcmd_mutex); } static int create_synth_event(const char *raw_command); -- 2.39.2

2 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror