Overall, we encountered a warning [1] that can be triggered by running the
selftest I provided.
sockmap works by replacing sk_data_ready, recvmsg, sendmsg operations and
implementing fast socket-level forwarding logic:
1. Users can obtain file descriptors through userspace socket()/accept()
interfaces, then call BPF syscall to perform these replacements.
2. Users can also use the bpf_sock_hash_update helper (in sockops programs)
to replace handlers when TCP connections enter ESTABLISHED state
(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB/BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB)
However, when combined with MPTCP, an issue arises: MPTCP creates subflow
sk's and performs TCP handshakes, so the BPF program obtains subflow sk's
and may incorrectly replace their sk_prot. We need to reject such
operations. In patch 1, we set psock_update_sk_prot to NULL in the
subflow's custom sk_prot.
Additionally, if the server's listening socket has MPTCP enabled and the
client's TCP also uses MPTCP, we should allow the combination of subflow
and sockmap. This is because the latest Golang programs have enabled MPTCP
for listening sockets by default [2]. For programs already using sockmap,
upgrading Golang should not cause sockmap functionality to fail.
Patch 2 prevents the panic from occurring.
Despite these patches fixing stream corruption, users of sockmap must set
GODEBUG=multipathtcp=0 to disable MPTCP until sockmap fully supports it.
[1] truncated warning:
------------[ cut here ]------------
BUG: kernel NULL pointer dereference, address: 00000000000004bb
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 400 Comm: test_progs Not tainted 6.1.0+ #16
RIP: 0010:mptcp_stream_accept (./include/linux/list.h:88 net/mptcp/protocol.c:3719)
RSP: 0018:ffffc90000ef3cf0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880089dcc58
RDX: 0000000000000003 RSI: 0000002c000000b0 RDI: 0000000000000000
RBP: ffffc90000ef3d38 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880089dc600
R13: ffff88800b859e00 R14: ffff88800638c680 R15: 0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000004bb CR3: 000000000b8e8006 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? apparmor_socket_accept (security/apparmor/lsm.c:966)
do_accept (net/socket.c:1856)
__sys_accept4 (net/socket.c:1897 net/socket.c:1927)
__x64_sys_accept (net/socket.c:1941)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[2]: https://go-review.googlesource.com/c/go/+/607715
Jiayuan Chen (2):
mptcp: disallow MPTCP subflows from sockmap
net,mptcp: fix proto fallback detection with BPF
net/mptcp/protocol.c | 5 +++--
net/mptcp/subflow.c | 8 ++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
--
2.43.0
From: Alex Deucher <alexander.deucher(a)amd.com>
[ Upstream commit 3126c9ccb4373d8758733c6699ba5ab93dbe5c9d ]
This reverts commit 2681bf4ae8d24df950138b8c9ea9c271cd62e414.
This results in a blank screen on the HDMI port on some systems.
Revert for now so as not to regress 6.18, can be addressed
in 6.19 once the issue is root caused.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4652
Cc: Sunpeng.Li(a)amd.com
Cc: ivan.lipski(a)amd.com
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
(cherry picked from commit d0e9de7a81503cdde37fb2d37f1d102f9e0f38fb)
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have a complete understanding of the issue. Let me summarize my
analysis:
## Comprehensive Analysis
### 1. Commit Message Analysis
This is a **revert** of commit
`2681bf4ae8d24df950138b8c9ea9c271cd62e414` that moved
`setup_stream_attribute()` from `link_set_dpms_on()` to individual
`enable_stream()` functions. The commit clearly states:
- The change "results in a blank screen on the HDMI port on some
systems"
- Includes a bug report link:
https://gitlab.freedesktop.org/drm/amd/-/issues/4652
- Explicitly intended to "not regress 6.18"
- Cherry-picked from upstream with maintainer sign-off
### 2. Critical Finding: Buggy Commit Already Backported
**The original problematic commit (`7965cb360655`) was already
backported to stable trees** (as shown by `[ Upstream commit ... ]` and
Sasha Levin's signature). This means **stable users are currently
affected by this regression** and need the fix.
### 3. Technical Root Cause
The original commit attempted to fix a symclk RCO clock gating issue by
moving `setup_stream_attribute()` later in the sequence, after clock
ungating in `enable_stream()`. However:
- **For DP (DisplayPort)**: This ordering works because DP needs symclk
ungated first
- **For HDMI/TMDS**: The stream attributes must be set earlier,
specifically before VPG power-on and infoframe construction in
`link_set_dpms_on()`
The code at line 3055 in `dcn20_hwseq.c` shows where the call was moved:
```c
link_hwss->setup_stream_attribute(pipe_ctx);
```
This call happens too late for HDMI paths, causing blank screens because
the HDMI signal initialization sequence depends on attributes being
programmed before the display pipe is fully enabled.
### 4. Code Change Assessment
The revert is small and surgical:
- **5 files changed**
- Removes `link_hwss->setup_stream_attribute()` from 3 hwseq files
(dce110, dcn20, dcn401)
- Restores the call in `link_dpms.c` at the correct position (after
`set_out_mux()`, before VPG power-on)
- Removes unused LVDS stub from virtual_stream_encoder.c
### 5. Stable Kernel Rules Compliance
| Criteria | Assessment |
|----------|------------|
| Fixes a real bug affecting users | ✅ Blank HDMI screen - severe user-
visible regression |
| Obviously correct | ✅ Simple revert to known-working code |
| Small and contained | ✅ ~20 lines removed, ~5 lines added |
| No new features | ✅ Pure regression fix |
| Bug exists in stable | ✅ Original buggy commit was backported |
### 6. Risk Assessment
- **Regression risk: LOW** - This reverts to previously known-working
behavior that was stable for years
- **Trade-off**: The original symclk RCO issue will remain unfixed, but:
- RCO issue affects a narrow DP corner case
- Blank HDMI affects common consumer hardware
- A blank screen is a far worse failure than the clock gating issue
- **Testing**: Upstream maintainer sign-off (Alex Deucher) and cherry-
picked from mainline
### 7. User Impact
- **Severity: CRITICAL** - Complete display failure on HDMI
- **Scope: HIGH** - HDMI is ubiquitous; affects multiple hardware
generations (dce110, dcn20, dcn401)
- **Real users affected**: Bug report confirms actual user impact
### Conclusion
This commit is an **ideal stable backport candidate**:
1. The regression-causing commit was already backported to stable trees,
so stable users are currently broken
2. It fixes a critical user-visible bug (blank HDMI displays)
3. The fix is a simple, safe revert to known-good code
4. It has proper upstream maintainer approval
5. The risk of the revert causing problems is minimal (returning to
proven behavior)
The revert is **mandatory** for any stable tree that includes commit
`7965cb360655` to restore working HDMI functionality.
**YES**
drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 1 -
drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 2 --
drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 2 --
drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 3 +++
.../drm/amd/display/dc/virtual/virtual_stream_encoder.c | 7 -------
5 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
index 537f53811460..39de51cbbde9 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
@@ -671,7 +671,6 @@ void dce110_enable_stream(struct pipe_ctx *pipe_ctx)
uint32_t early_control = 0;
struct timing_generator *tg = pipe_ctx->stream_res.tg;
- link_hwss->setup_stream_attribute(pipe_ctx);
link_hwss->setup_stream_encoder(pipe_ctx);
dc->hwss.update_info_frame(pipe_ctx);
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
index f7b72b24b750..921023500bec 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
@@ -3052,8 +3052,6 @@ void dcn20_enable_stream(struct pipe_ctx *pipe_ctx)
link_enc->transmitter - TRANSMITTER_UNIPHY_A);
}
- link_hwss->setup_stream_attribute(pipe_ctx);
-
if (dc->res_pool->dccg->funcs->set_pixel_rate_div)
dc->res_pool->dccg->funcs->set_pixel_rate_div(
dc->res_pool->dccg,
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
index 0fe763704945..b95b98cc2553 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
@@ -968,8 +968,6 @@ void dcn401_enable_stream(struct pipe_ctx *pipe_ctx)
}
}
- link_hwss->setup_stream_attribute(pipe_ctx);
-
if (dc->res_pool->dccg->funcs->set_pixel_rate_div) {
dc->res_pool->dccg->funcs->set_pixel_rate_div(
dc->res_pool->dccg,
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
index cb80b4599936..8c8682f743d6 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
@@ -2458,6 +2458,7 @@ void link_set_dpms_on(
struct link_encoder *link_enc = pipe_ctx->link_res.dio_link_enc;
enum otg_out_mux_dest otg_out_dest = OUT_MUX_DIO;
struct vpg *vpg = pipe_ctx->stream_res.stream_enc->vpg;
+ const struct link_hwss *link_hwss = get_link_hwss(link, &pipe_ctx->link_res);
bool apply_edp_fast_boot_optimization =
pipe_ctx->stream->apply_edp_fast_boot_optimization;
@@ -2501,6 +2502,8 @@ void link_set_dpms_on(
pipe_ctx->stream_res.tg->funcs->set_out_mux(pipe_ctx->stream_res.tg, otg_out_dest);
}
+ link_hwss->setup_stream_attribute(pipe_ctx);
+
pipe_ctx->stream->apply_edp_fast_boot_optimization = false;
// Enable VPG before building infoframe
diff --git a/drivers/gpu/drm/amd/display/dc/virtual/virtual_stream_encoder.c b/drivers/gpu/drm/amd/display/dc/virtual/virtual_stream_encoder.c
index 6ffc74fc9dcd..ad088d70e189 100644
--- a/drivers/gpu/drm/amd/display/dc/virtual/virtual_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/virtual/virtual_stream_encoder.c
@@ -44,11 +44,6 @@ static void virtual_stream_encoder_dvi_set_stream_attribute(
struct dc_crtc_timing *crtc_timing,
bool is_dual_link) {}
-static void virtual_stream_encoder_lvds_set_stream_attribute(
- struct stream_encoder *enc,
- struct dc_crtc_timing *crtc_timing)
-{}
-
static void virtual_stream_encoder_set_throttled_vcp_size(
struct stream_encoder *enc,
struct fixed31_32 avg_time_slots_per_mtp)
@@ -120,8 +115,6 @@ static const struct stream_encoder_funcs virtual_str_enc_funcs = {
virtual_stream_encoder_hdmi_set_stream_attribute,
.dvi_set_stream_attribute =
virtual_stream_encoder_dvi_set_stream_attribute,
- .lvds_set_stream_attribute =
- virtual_stream_encoder_lvds_set_stream_attribute,
.set_throttled_vcp_size =
virtual_stream_encoder_set_throttled_vcp_size,
.update_hdmi_info_packets =
--
2.51.0
The mmio regmap allocated during probe is never freed.
Switch to using the device managed allocator so that the regmap is
released on probe failures (e.g. probe deferral) and on driver unbind.
Fixes: a250cd4c1901 ("clk: keystone: syscon-clk: Do not use syscon helper to build regmap")
Cc: stable(a)vger.kernel.org # 6.15
Cc: Andrew Davis <afd(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/clk/keystone/syscon-clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/keystone/syscon-clk.c b/drivers/clk/keystone/syscon-clk.c
index c509929da854..ecf180a7949c 100644
--- a/drivers/clk/keystone/syscon-clk.c
+++ b/drivers/clk/keystone/syscon-clk.c
@@ -129,7 +129,7 @@ static int ti_syscon_gate_clk_probe(struct platform_device *pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- regmap = regmap_init_mmio(dev, base, &ti_syscon_regmap_cfg);
+ regmap = devm_regmap_init_mmio(dev, base, &ti_syscon_regmap_cfg);
if (IS_ERR(regmap))
return dev_err_probe(dev, PTR_ERR(regmap),
"failed to get regmap\n");
--
2.51.2
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS)
about the number of elements in .hws[], so that it can warn when .hws[]
is accessed out of bounds. As noted in that change, the __counted_by
member must be initialized with the number of elements before the first
array access happens, otherwise there will be a warning from each access
prior to the initialization because the number of elements is zero. This
occurs in exynos_clkout_probe() due to .num being assigned after .hws[]
has been accessed:
UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18
index 0 is out of range for type 'clk_hw *[*]'
Move the .num initialization to before the first access of .hws[],
clearing up the warning.
Cc: stable(a)vger.kernel.org
Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by")
Reported-by: Jochen Sprickerhof <jochen(a)sprickerhof.de>
Closes: https://lore.kernel.org/aSIYDN5eyKFKoXKL@eldamar.lan/
Tested-by: Jochen Sprickerhof <jochen(a)sprickerhof.de>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
---
drivers/clk/samsung/clk-exynos-clkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos-clkout.c b/drivers/clk/samsung/clk-exynos-clkout.c
index 5f1a4f5e2e59..5b21025338bd 100644
--- a/drivers/clk/samsung/clk-exynos-clkout.c
+++ b/drivers/clk/samsung/clk-exynos-clkout.c
@@ -175,6 +175,7 @@ static int exynos_clkout_probe(struct platform_device *pdev)
clkout->mux.shift = EXYNOS_CLKOUT_MUX_SHIFT;
clkout->mux.lock = &clkout->slock;
+ clkout->data.num = EXYNOS_CLKOUT_NR_CLKS;
clkout->data.hws[0] = clk_hw_register_composite(NULL, "clkout",
parent_names, parent_count, &clkout->mux.hw,
&clk_mux_ops, NULL, NULL, &clkout->gate.hw,
@@ -185,7 +186,6 @@ static int exynos_clkout_probe(struct platform_device *pdev)
goto err_unmap;
}
- clkout->data.num = EXYNOS_CLKOUT_NR_CLKS;
ret = of_clk_add_hw_provider(clkout->np, of_clk_hw_onecell_get, &clkout->data);
if (ret)
goto err_clk_unreg;
---
base-commit: b6430552c8cd95e90bb842ce2f421e7a5381859f
change-id: 20251124-exynos-clkout-fix-ubsan-bounds-error-93071375ec78
Best regards,
--
Nathan Chancellor <nathan(a)kernel.org>