December 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] tracing: Stop current tracer when resizing buffer" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x d78ab792705c7be1b91243b2544d1a79406a2ad7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023120949-giddily-cogwheel-28e8@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: d78ab792705c ("tracing: Stop current tracer when resizing buffer") 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d78ab792705c7be1b91243b2544d1a79406a2ad7 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Tue, 5 Dec 2023 16:52:10 -0500 Subject: [PATCH] tracing: Stop current tracer when resizing buffer When the ring buffer is being resized, it can cause side effects to the running tracer. For instance, there's a race with irqsoff tracer that swaps individual per cpu buffers between the main buffer and the snapshot buffer. The resize operation modifies the main buffer and then the snapshot buffer. If a swap happens in between those two operations it will break the tracer. Simply stop the running tracer before resizing the buffers and enable it again when finished. Link: https://lkml.kernel.org/r/20231205220010.748996423@goodmis.org Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Fixes: 3928a8a2d9808 ("ftrace: make work with new ring buffer") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 231c173ec04f..e978868b1a22 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6387,9 +6387,12 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr, if (!tr->array_buffer.buffer) return 0; + /* Do not allow tracing while resizng ring buffer */ + tracing_stop_tr(tr); + ret = ring_buffer_resize(tr->array_buffer.buffer, size, cpu); if (ret < 0) - return ret; + goto out_start; #ifdef CONFIG_TRACER_MAX_TRACE if (!tr->current_trace->use_max_tr) @@ -6417,7 +6420,7 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr, WARN_ON(1); tracing_disabled = 1; } - return ret; + goto out_start; } update_buffer_entries(&tr->max_buffer, cpu); @@ -6426,7 +6429,8 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr, #endif /* CONFIG_TRACER_MAX_TRACE */ update_buffer_entries(&tr->array_buffer, cpu); - + out_start: + tracing_start_tr(tr); return ret; }

2 years

1
0
0 0

FAILED: patch "[PATCH] ring-buffer: Force absolute timestamp on discard of event" 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 b2dd797543cfa6580eac8408dd67fa02164d9e56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023120940-capitol-parade-09df@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: b2dd797543cf ("ring-buffer: Force absolute timestamp on discard of event") 6f6be606e763 ("ring-buffer: Force before_stamp and write_stamp to be different on discard") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b2dd797543cfa6580eac8408dd67fa02164d9e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Wed, 6 Dec 2023 10:02:44 -0500 Subject: [PATCH] ring-buffer: Force absolute timestamp on discard of event There's a race where if an event is discarded from the ring buffer and an interrupt were to happen at that time and insert an event, the time stamp is still used from the discarded event as an offset. This can screw up the timings. If the event is going to be discarded, set the "before_stamp" to zero. When a new event comes in, it compares the "before_stamp" with the "write_stamp" and if they are not equal, it will insert an absolute timestamp. This will prevent the timings from getting out of sync due to the discarded event. Link: https://lore.kernel.org/linux-trace-kernel/20231206100244.5130f9b3@gandalf.… Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Fixes: 6f6be606e763f ("ring-buffer: Force before_stamp and write_stamp to be different on discard") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 43cc47d7faaf..a6da2d765c78 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3030,22 +3030,19 @@ rb_try_to_discard(struct ring_buffer_per_cpu *cpu_buffer, local_read(&bpage->write) & ~RB_WRITE_MASK; unsigned long event_length = rb_event_length(event); + /* + * For the before_stamp to be different than the write_stamp + * to make sure that the next event adds an absolute + * value and does not rely on the saved write stamp, which + * is now going to be bogus. + */ + rb_time_set(&cpu_buffer->before_stamp, 0); + /* Something came in, can't discard */ if (!rb_time_cmpxchg(&cpu_buffer->write_stamp, write_stamp, write_stamp - delta)) return false; - /* - * It's possible that the event time delta is zero - * (has the same time stamp as the previous event) - * in which case write_stamp and before_stamp could - * be the same. In such a case, force before_stamp - * to be different than write_stamp. It doesn't - * matter what it is, as long as its different. - */ - if (!delta) - rb_time_set(&cpu_buffer->before_stamp, 0); - /* * If an event were to come in now, it would see that the * write_stamp and the before_stamp are different, and assume

2 years

1
0
0 0

FAILED: patch "[PATCH] ring-buffer: Force absolute timestamp on discard of event" 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 b2dd797543cfa6580eac8408dd67fa02164d9e56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023120939-gladly-chef-ae61@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: b2dd797543cf ("ring-buffer: Force absolute timestamp on discard of event") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b2dd797543cfa6580eac8408dd67fa02164d9e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Wed, 6 Dec 2023 10:02:44 -0500 Subject: [PATCH] ring-buffer: Force absolute timestamp on discard of event There's a race where if an event is discarded from the ring buffer and an interrupt were to happen at that time and insert an event, the time stamp is still used from the discarded event as an offset. This can screw up the timings. If the event is going to be discarded, set the "before_stamp" to zero. When a new event comes in, it compares the "before_stamp" with the "write_stamp" and if they are not equal, it will insert an absolute timestamp. This will prevent the timings from getting out of sync due to the discarded event. Link: https://lore.kernel.org/linux-trace-kernel/20231206100244.5130f9b3@gandalf.… Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Fixes: 6f6be606e763f ("ring-buffer: Force before_stamp and write_stamp to be different on discard") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 43cc47d7faaf..a6da2d765c78 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3030,22 +3030,19 @@ rb_try_to_discard(struct ring_buffer_per_cpu *cpu_buffer, local_read(&bpage->write) & ~RB_WRITE_MASK; unsigned long event_length = rb_event_length(event); + /* + * For the before_stamp to be different than the write_stamp + * to make sure that the next event adds an absolute + * value and does not rely on the saved write stamp, which + * is now going to be bogus. + */ + rb_time_set(&cpu_buffer->before_stamp, 0); + /* Something came in, can't discard */ if (!rb_time_cmpxchg(&cpu_buffer->write_stamp, write_stamp, write_stamp - delta)) return false; - /* - * It's possible that the event time delta is zero - * (has the same time stamp as the previous event) - * in which case write_stamp and before_stamp could - * be the same. In such a case, force before_stamp - * to be different than write_stamp. It doesn't - * matter what it is, as long as its different. - */ - if (!delta) - rb_time_set(&cpu_buffer->before_stamp, 0); - /* * If an event were to come in now, it would see that the * write_stamp and the before_stamp are different, and assume

2 years

1
0
0 0

FAILED: patch "[PATCH] ring-buffer: Force absolute timestamp on discard of event" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x b2dd797543cfa6580eac8408dd67fa02164d9e56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023120938-unclamped-fleshy-688e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: b2dd797543cf ("ring-buffer: Force absolute timestamp on discard of event") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b2dd797543cfa6580eac8408dd67fa02164d9e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Wed, 6 Dec 2023 10:02:44 -0500 Subject: [PATCH] ring-buffer: Force absolute timestamp on discard of event There's a race where if an event is discarded from the ring buffer and an interrupt were to happen at that time and insert an event, the time stamp is still used from the discarded event as an offset. This can screw up the timings. If the event is going to be discarded, set the "before_stamp" to zero. When a new event comes in, it compares the "before_stamp" with the "write_stamp" and if they are not equal, it will insert an absolute timestamp. This will prevent the timings from getting out of sync due to the discarded event. Link: https://lore.kernel.org/linux-trace-kernel/20231206100244.5130f9b3@gandalf.… Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Fixes: 6f6be606e763f ("ring-buffer: Force before_stamp and write_stamp to be different on discard") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 43cc47d7faaf..a6da2d765c78 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3030,22 +3030,19 @@ rb_try_to_discard(struct ring_buffer_per_cpu *cpu_buffer, local_read(&bpage->write) & ~RB_WRITE_MASK; unsigned long event_length = rb_event_length(event); + /* + * For the before_stamp to be different than the write_stamp + * to make sure that the next event adds an absolute + * value and does not rely on the saved write stamp, which + * is now going to be bogus. + */ + rb_time_set(&cpu_buffer->before_stamp, 0); + /* Something came in, can't discard */ if (!rb_time_cmpxchg(&cpu_buffer->write_stamp, write_stamp, write_stamp - delta)) return false; - /* - * It's possible that the event time delta is zero - * (has the same time stamp as the previous event) - * in which case write_stamp and before_stamp could - * be the same. In such a case, force before_stamp - * to be different than write_stamp. It doesn't - * matter what it is, as long as its different. - */ - if (!delta) - rb_time_set(&cpu_buffer->before_stamp, 0); - /* * If an event were to come in now, it would see that the * write_stamp and the before_stamp are different, and assume

2 years

1
0
0 0

FAILED: patch "[PATCH] io_uring/af_unix: disable sending io_uring over sockets" 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 705318a99a138c29a512a72c3e0043b3cd7f55f4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023120912-cabana-cartridge-5e80@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 705318a99a13 ("io_uring/af_unix: disable sending io_uring over sockets") 38eddb2c75fb ("io_uring: remove FFS_SCM") 735729844819 ("io_uring: move rsrc related data, core, and commands") 3b77495a9723 ("io_uring: split provided buffers handling into its own file") 7aaff708a768 ("io_uring: move cancelation into its own file") 329061d3e2f9 ("io_uring: move poll handling into its own file") cfd22e6b3319 ("io_uring: add opcode name to io_op_defs") 92ac8beaea1f ("io_uring: include and forward-declaration sanitation") c9f06aa7de15 ("io_uring: move io_uring_task (tctx) helpers into its own file") a4ad4f748ea9 ("io_uring: move fdinfo helpers to its own file") e5550a1447bf ("io_uring: use io_is_uring_fops() consistently") 17437f311490 ("io_uring: move SQPOLL related handling into its own file") 59915143e89f ("io_uring: move timeout opcodes and handling into its own file") e418bbc97bff ("io_uring: move our reference counting into a header") 36404b09aa60 ("io_uring: move msg_ring into its own file") f9ead18c1058 ("io_uring: split network related opcodes into its own file") e0da14def1ee ("io_uring: move statx handling to its own file") a9c210cebe13 ("io_uring: move epoll handler to its own file") 4cf90495281b ("io_uring: add a dummy -EOPNOTSUPP prep handler") 99f15d8d6136 ("io_uring: move uring_cmd handling to its own file") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 705318a99a138c29a512a72c3e0043b3cd7f55f4 Mon Sep 17 00:00:00 2001 From: Pavel Begunkov <asml.silence(a)gmail.com> Date: Wed, 6 Dec 2023 13:26:47 +0000 Subject: [PATCH] io_uring/af_unix: disable sending io_uring over sockets File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary. Cc: <stable(a)vger.kernel.org> Fixes: 0091bfc81741b ("io_uring/af_unix: defer registered files gc to io_uring release") Reported-and-suggested-by: Jann Horn <jannh(a)google.com> Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/c716c88321939156909cfa1bd8b0faaf1c804103.17018687… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/rsrc.h b/io_uring/rsrc.h index 8625181fb87a..08ac0d8e07ef 100644 --- a/io_uring/rsrc.h +++ b/io_uring/rsrc.h @@ -77,17 +77,10 @@ int io_sqe_files_register(struct io_ring_ctx *ctx, void __user *arg, int __io_scm_file_account(struct io_ring_ctx *ctx, struct file *file); -#if defined(CONFIG_UNIX) -static inline bool io_file_need_scm(struct file *filp) -{ - return !!unix_get_socket(filp); -} -#else static inline bool io_file_need_scm(struct file *filp) { return false; } -#endif static inline int io_scm_file_account(struct io_ring_ctx *ctx, struct file *file) diff --git a/net/core/scm.c b/net/core/scm.c index 880027ecf516..7dc47c17d863 100644 --- a/net/core/scm.c +++ b/net/core/scm.c @@ -26,6 +26,7 @@ #include <linux/nsproxy.h> #include <linux/slab.h> #include <linux/errqueue.h> +#include <linux/io_uring.h> #include <linux/uaccess.h> @@ -103,6 +104,11 @@ static int scm_fp_copy(struct cmsghdr *cmsg, struct scm_fp_list **fplp) if (fd < 0 || !(file = fget_raw(fd))) return -EBADF; + /* don't allow io_uring files */ + if (io_uring_get_socket(file)) { + fput(file); + return -EINVAL; + } *fpp++ = file; fpl->count++; }

2 years

1
0
0 0

[PATCH 1/1] Revert "drm/edid: Fix csync detailed mode parsing"

by kovalev＠altlinux.org

From: Vasiliy Kovalev <kovalev(a)altlinux.org> This reverts commit 5a46dc8e4a064769e916d87bf9bccae75afc7289. Commit 50b6f2c8297793f7f3315623db78dcff85158e96 upstream. Commit 5a46dc8e4a0647 ("drm/edid: Fix csync detailed mode parsing") fixed EDID detailed mode sync parsing. Unfortunately, there are quite a few displays out there that have bogus (zero) sync field that are broken by the change. Zero means analog composite sync, which is not right for digital displays, and the modes get rejected. Regardless, it used to work, and it needs to continue to work. Revert the change. Rejecting modes with analog composite sync was the part that fixed the gitlab issue 8146 [1]. We'll need to get back to the drawing board with that. [1] https://gitlab.freedesktop.org/drm/intel/-/issues/8146 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8789 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8930 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9044 Fixes: 5a46dc8e4a0647 ("drm/edid: Fix csync detailed mode parsing") Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v6.4+ Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Acked-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230815101907.2900768-1-jani… Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- drivers/gpu/drm/drm_edid.c | 26 +++++++------------------- include/drm/drm_edid.h | 12 +++--------- 2 files changed, 10 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a26c6c57a627c0..5ed77e3361fd72 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3307,6 +3307,9 @@ static struct drm_display_mode *drm_mode_detailed(struct drm_device *dev, DRM_DEBUG_KMS("stereo mode not supported\n"); return NULL; } + if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) { + DRM_DEBUG_KMS("composite sync not supported\n"); + } /* it is incorrect if hsync/vsync width is zero */ if (!hsync_pulse_width || !vsync_pulse_width) { @@ -3353,25 +3356,10 @@ static struct drm_display_mode *drm_mode_detailed(struct drm_device *dev, if (quirks & EDID_QUIRK_DETAILED_SYNC_PP) { mode->flags |= DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC; } else { - switch (pt->misc & DRM_EDID_PT_SYNC_MASK) { - case DRM_EDID_PT_ANALOG_CSYNC: - case DRM_EDID_PT_BIPOLAR_ANALOG_CSYNC: - drm_dbg_kms(dev, "Analog composite sync!\n"); - mode->flags |= DRM_MODE_FLAG_CSYNC | DRM_MODE_FLAG_NCSYNC; - break; - case DRM_EDID_PT_DIGITAL_CSYNC: - drm_dbg_kms(dev, "Digital composite sync!\n"); - mode->flags |= DRM_MODE_FLAG_CSYNC; - mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ? - DRM_MODE_FLAG_PCSYNC : DRM_MODE_FLAG_NCSYNC; - break; - case DRM_EDID_PT_DIGITAL_SEPARATE_SYNC: - mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ? - DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC; - mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ? - DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC; - break; - } + mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ? + DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC; + mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ? + DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC; } set_size: diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 008d2ed39822ec..1ed61e2b30a41c 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -61,15 +61,9 @@ struct std_timing { u8 vfreq_aspect; } __attribute__((packed)); -#define DRM_EDID_PT_SYNC_MASK (3 << 3) -# define DRM_EDID_PT_ANALOG_CSYNC (0 << 3) -# define DRM_EDID_PT_BIPOLAR_ANALOG_CSYNC (1 << 3) -# define DRM_EDID_PT_DIGITAL_CSYNC (2 << 3) -# define DRM_EDID_PT_CSYNC_ON_RGB (1 << 1) /* analog csync only */ -# define DRM_EDID_PT_CSYNC_SERRATE (1 << 2) -# define DRM_EDID_PT_DIGITAL_SEPARATE_SYNC (3 << 3) -# define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1) /* also digital csync */ -# define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2) +#define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1) +#define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2) +#define DRM_EDID_PT_SEPARATE_SYNC (3 << 3) #define DRM_EDID_PT_STEREO (1 << 5) #define DRM_EDID_PT_INTERLACED (1 << 7) -- 2.33.8

2 years

2
1
0 0

FAILED: patch "[PATCH] kprobes: consistent rcu api usage for kretprobe holder" 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 d839a656d0f3caca9f96e9bf912fd394ac6a11bc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023120319-failing-aviator-303a@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: d839a656d0f3 ("kprobes: consistent rcu api usage for kretprobe holder") 4bbd93455659 ("kprobes: kretprobe scalability improvement") 8865aea0471c ("kernel: kprobes: Use struct_size()") 195b9cb5b288 ("fprobe: Ensure running fprobe_exit_handler() finished before calling rethook_free()") 5f81018753df ("fprobe: Release rethook after the ftrace_ops is unregistered") 76d0de5729c0 ("fprobe: Pass entry_data to handlers") 0a1ebe35cb3b ("rethook: fix a potential memleak in rethook_alloc()") d05ea35e7eea ("fprobe: Check rethook_alloc() return in rethook initialization") c09eb2e578eb ("bpf: Adjust kprobe_multi entry_ip for CONFIG_X86_KERNEL_IBT") c0f3bb4054ef ("rethook: Reject getting a rethook if RCU is not watching") 439940491807 ("kprobes: Fix build errors with CONFIG_KRETPROBES=n") 73f9b911faa7 ("kprobes: Use rethook for kretprobe if possible") 9052e4e83762 ("fprobe: Fix smatch type mismatch warning") f70986902c86 ("bpf: Fix kprobe_multi return probe backtrace") f705ec764b34 ("Revert "bpf: Add support to inline bpf_get_func_ip helper on x86"") 2c6401c966ae ("selftests/bpf: Add kprobe_multi bpf_cookie test") f7a11eeccb11 ("selftests/bpf: Add kprobe_multi attach test") ca74823c6e16 ("bpf: Add cookie support to programs attached with kprobe multi link") 97ee4d20ee67 ("bpf: Add support to inline bpf_get_func_ip helper on x86") 42a5712094e8 ("bpf: Add bpf_get_func_ip kprobe helper for multi kprobe link") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d839a656d0f3caca9f96e9bf912fd394ac6a11bc Mon Sep 17 00:00:00 2001 From: JP Kobryn <inwardvessel(a)gmail.com> Date: Fri, 1 Dec 2023 14:53:55 +0900 Subject: [PATCH] kprobes: consistent rcu api usage for kretprobe holder It seems that the pointer-to-kretprobe "rp" within the kretprobe_holder is RCU-managed, based on the (non-rethook) implementation of get_kretprobe(). The thought behind this patch is to make use of the RCU API where possible when accessing this pointer so that the needed barriers are always in place and to self-document the code. The __rcu annotation to "rp" allows for sparse RCU checking. Plain writes done to the "rp" pointer are changed to make use of the RCU macro for assignment. For the single read, the implementation of get_kretprobe() is simplified by making use of an RCU macro which accomplishes the same, but note that the log warning text will be more generic. I did find that there is a difference in assembly generated between the usage of the RCU macros vs without. For example, on arm64, when using rcu_assign_pointer(), the corresponding store instruction is a store-release (STLR) which has an implicit barrier. When normal assignment is done, a regular store (STR) is found. In the macro case, this seems to be a result of rcu_assign_pointer() using smp_store_release() when the value to write is not NULL. Link: https://lore.kernel.org/all/20231122132058.3359-1-inwardvessel@gmail.com/ Fixes: d741bf41d7c7 ("kprobes: Remove kretprobe hash") Cc: stable(a)vger.kernel.org Signed-off-by: JP Kobryn <inwardvessel(a)gmail.com> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h index ab1da3142b06..64672bace560 100644 --- a/include/linux/kprobes.h +++ b/include/linux/kprobes.h @@ -139,7 +139,7 @@ static inline bool kprobe_ftrace(struct kprobe *p) * */ struct kretprobe_holder { - struct kretprobe *rp; + struct kretprobe __rcu *rp; struct objpool_head pool; }; @@ -245,10 +245,7 @@ unsigned long kretprobe_trampoline_handler(struct pt_regs *regs, static nokprobe_inline struct kretprobe *get_kretprobe(struct kretprobe_instance *ri) { - RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(), - "Kretprobe is accessed from instance under preemptive context"); - - return READ_ONCE(ri->rph->rp); + return rcu_dereference_check(ri->rph->rp, rcu_read_lock_any_held()); } static nokprobe_inline unsigned long get_kretprobe_retaddr(struct kretprobe_instance *ri) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 075a632e6c7c..d5a0ee40bf66 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2252,7 +2252,7 @@ int register_kretprobe(struct kretprobe *rp) rp->rph = NULL; return -ENOMEM; } - rp->rph->rp = rp; + rcu_assign_pointer(rp->rph->rp, rp); rp->nmissed = 0; /* Establish function entry probe point */ ret = register_kprobe(&rp->kp); @@ -2300,7 +2300,7 @@ void unregister_kretprobes(struct kretprobe **rps, int num) #ifdef CONFIG_KRETPROBE_ON_RETHOOK rethook_free(rps[i]->rh); #else - rps[i]->rph->rp = NULL; + rcu_assign_pointer(rps[i]->rph->rp, NULL); #endif } mutex_unlock(&kprobe_mutex);

2 years

3
2
0 0

[PATCH 6.1] binder: fix memory leaks of spam and pending work

by Carlos Llamas

commit 1aa3aaf8953c84bad398adf6c3cabc9d6685bf7d upstream A transaction complete work is allocated and queued for each transaction. Under certain conditions the work->type might be marked as BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT to notify userspace about potential spamming threads or as BINDER_WORK_TRANSACTION_PENDING when the target is currently frozen. However, these work types are not being handled in binder_release_work() so they will leak during a cleanup. This was reported by syzkaller with the following kmemleak dump: BUG: memory leak unreferenced object 0xffff88810e2d6de0 (size 32): comm "syz-executor338", pid 5046, jiffies 4294968230 (age 13.590s) hex dump (first 32 bytes): e0 6d 2d 0e 81 88 ff ff e0 6d 2d 0e 81 88 ff ff .m-......m-..... 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81573b75>] kmalloc_trace+0x25/0x90 mm/slab_common.c:1114 [<ffffffff83d41873>] kmalloc include/linux/slab.h:599 [inline] [<ffffffff83d41873>] kzalloc include/linux/slab.h:720 [inline] [<ffffffff83d41873>] binder_transaction+0x573/0x4050 drivers/android/binder.c:3152 [<ffffffff83d45a05>] binder_thread_write+0x6b5/0x1860 drivers/android/binder.c:4010 [<ffffffff83d486dc>] binder_ioctl_write_read drivers/android/binder.c:5066 [inline] [<ffffffff83d486dc>] binder_ioctl+0x1b2c/0x3cf0 drivers/android/binder.c:5352 [<ffffffff816b25f2>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff816b25f2>] __do_sys_ioctl fs/ioctl.c:871 [inline] [<ffffffff816b25f2>] __se_sys_ioctl fs/ioctl.c:857 [inline] [<ffffffff816b25f2>] __x64_sys_ioctl+0xf2/0x140 fs/ioctl.c:857 [<ffffffff84b30008>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84b30008>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fix the leaks by kfreeing these work types in binder_release_work() and handle them as a BINDER_WORK_TRANSACTION_COMPLETE cleanup. Cc: stable(a)vger.kernel.org Fixes: a7dc1e6f99df ("binder: tell userspace to dump current backtrace when detected oneway spamming") Reported-by: syzbot+7f10c1653e35933c0f1e(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f10c1653e35933c0f1e Suggested-by: Alice Ryhl <aliceryhl(a)google.com> Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Acked-by: Todd Kjos <tkjos(a)google.com> Link: https://lore.kernel.org/r/20230922175138.230331-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [cmllamas: backport to v6.1 by dropping BINDER_WORK_TRANSACTION_PENDING as commit 0567461a7a6e is not present. Remove fixes tag accordingly.] Signed-off-by: Carlos Llamas <cmllamas(a)google.com> --- drivers/android/binder.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index e4a6da81cd4b..9cc3a2b1b4fc 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -4788,6 +4788,7 @@ static void binder_release_work(struct binder_proc *proc, "undelivered TRANSACTION_ERROR: %u\n", e->cmd); } break; + case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: case BINDER_WORK_TRANSACTION_COMPLETE: { binder_debug(BINDER_DEBUG_DEAD_TRANSACTION, "undelivered TRANSACTION_COMPLETE\n"); base-commit: c6114c845984144944f1abc07c61de219367a4da -- 2.43.0.472.g3155946c3a-goog

2 years

3
2
0 0

stable-rc/queue/6.1 baseline: 108 runs, 5 regressions (v6.1.66-98-g1985fd91c0333)

by kernelci.org bot

stable-rc/queue/6.1 baseline: 108 runs, 5 regressions (v6.1.66-98-g1985fd91c0333) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------------+-------+---------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-10 | omap2plus_defconfig | 1 meson-gxm-khadas-vim2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 sun50i-h6-pine-h64 | arm64 | lab-clabbe | gcc-10 | defconfig | 1 sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F6.1/kernel/v6.1.66-9… Test: baseline Tree: stable-rc Branch: queue/6.1 Describe: v6.1.66-98-g1985fd91c0333 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 1985fd91c0333212253b0bf5d3d970dbd267553c Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------------+-------+---------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/65741ccdce8eec5095e1352b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: omap2plus_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/65741ccdce8eec5095e1352c failing since 232 days (last pass: v6.1.22-477-g2128d4458cbc, first fail: v6.1.22-474-gecc61872327e) platform | arch | lab | compiler | defconfig | regressions ----------------------+-------+---------------+----------+---------------------+------------ meson-gxm-khadas-vim2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/65741c62913df64471e134a3 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/65741c62913df64471e134a4 new failure (last pass: v6.1.66-63-gdd66d04a6991a) platform | arch | lab | compiler | defconfig | regressions ----------------------+-------+---------------+----------+---------------------+------------ r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/657421f0ba97ebb79de13559 Results: 4 PASS, 2 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/657421f0ba97ebb79de13562 failing since 16 days (last pass: v6.1.31-26-gef50524405c2, first fail: v6.1.63-176-gecc0fed1ffa4) 2023-12-09T08:21:57.741550 / # # 2023-12-09T08:21:57.843667 export SHELL=/bin/sh 2023-12-09T08:21:57.844421 # 2023-12-09T08:21:57.945727 / # export SHELL=/bin/sh. /lava-12228494/environment 2023-12-09T08:21:57.946464 2023-12-09T08:21:58.047863 / # . /lava-12228494/environment/lava-12228494/bin/lava-test-runner /lava-12228494/1 2023-12-09T08:21:58.049005 2023-12-09T08:21:58.092823 / # /lava-12228494/bin/lava-test-runner /lava-12228494/1 2023-12-09T08:21:58.114645 + export 'TESTRUN_ID=1_bootrr' 2023-12-09T08:21:58.115150 + cd /lava-122284<8>[ 19.133096] <LAVA_SIGNAL_STARTRUN 1_bootrr 12228494_1.5.2.4.5> ... (28 line(s) more) platform | arch | lab | compiler | defconfig | regressions ----------------------+-------+---------------+----------+---------------------+------------ sun50i-h6-pine-h64 | arm64 | lab-clabbe | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/65741b44ee38f6a81de13475 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/65741b44ee38f6a81de1347e failing since 16 days (last pass: v6.1.22-372-g971903477e72, first fail: v6.1.63-176-gecc0fed1ffa4) 2023-12-09T07:46:06.401407 <8>[ 18.109988] <LAVA_SIGNAL_ENDRUN 0_dmesg 447261_1.5.2.4.1> 2023-12-09T07:46:06.506399 / # # 2023-12-09T07:46:06.608072 export SHELL=/bin/sh 2023-12-09T07:46:06.608727 # 2023-12-09T07:46:06.709728 / # export SHELL=/bin/sh. /lava-447261/environment 2023-12-09T07:46:06.710329 2023-12-09T07:46:06.811353 / # . /lava-447261/environment/lava-447261/bin/lava-test-runner /lava-447261/1 2023-12-09T07:46:06.812245 2023-12-09T07:46:06.816595 / # /lava-447261/bin/lava-test-runner /lava-447261/1 2023-12-09T07:46:06.895582 + export 'TESTRUN_ID=1_bootrr' ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions ----------------------+-------+---------------+----------+---------------------+------------ sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/65741b7377bcdf99e5e13488 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.66-98-g1985fd91c0333… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/65741b7377bcdf99e5e13491 failing since 16 days (last pass: v6.1.22-372-g971903477e72, first fail: v6.1.63-176-gecc0fed1ffa4) 2023-12-09T07:54:15.258770 / # # 2023-12-09T07:54:15.359482 export SHELL=/bin/sh 2023-12-09T07:54:15.359745 # 2023-12-09T07:54:15.460307 / # export SHELL=/bin/sh. /lava-12228479/environment 2023-12-09T07:54:15.460437 2023-12-09T07:54:15.560900 / # . /lava-12228479/environment/lava-12228479/bin/lava-test-runner /lava-12228479/1 2023-12-09T07:54:15.561107 2023-12-09T07:54:15.572436 / # /lava-12228479/bin/lava-test-runner /lava-12228479/1 2023-12-09T07:54:15.643224 + export 'TESTRUN_ID=1_bootrr' 2023-12-09T07:54:15.643324 + cd /lava-1222847<8>[ 19.108683] <LAVA_SIGNAL_STARTRUN 1_bootrr 12228479_1.5.2.4.5> ... (11 line(s) more)

2 years

1
0
0 0

Re: Patch "spi: imx: add a device specific prepare_message callback" has been added to the 4.19-stable tree

by Uwe Kleine-König

Hello, On Fri, Dec 08, 2023 at 05:08:32AM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > spi: imx: add a device specific prepare_message callback > > to the 4.19-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > spi-imx-add-a-device-specific-prepare_message-callba.patch > and it can be found in the queue-4.19 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit b19a3770ce84da3c16acc7142e754cd8ff80ad3d > Author: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > Date: Fri Nov 30 07:47:05 2018 +0100 > > spi: imx: add a device specific prepare_message callback > > [ Upstream commit e697271c4e2987b333148e16a2eb8b5b924fd40a ] > > This is just preparatory work which allows to move some initialisation > that currently is done in the per transfer hook .config to an earlier > point in time in the next few patches. There is no change in behaviour > introduced by this patch. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > Signed-off-by: Mark Brown <broonie(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> The patch alone shouldn't be needed for stable and there is no indication that it's a dependency for another patch. Is this an oversight? Other than that: IMHO the subject for this type of report could be improved. Currently it's: Subject: Patch "spi: imx: add a device specific prepare_message callback" has been added to the 4.19-stable tree The most important part of it is "4.19-stable", but that only appears after character column 90 and so my MUA doesn't show it unless the window is wider than my default setting. Maybe make this: Subject: for-stable-4.19: "spi: imx: add a device specific prepare_message callback" ? Another thing I wonder about is: The mail contains If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. but it wasn't sent to stable(a)vger.kernel.org. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |

2 years

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023