December 2024 - Linux-stable-mirror

[PATCH v5 1/6] PCI: dwc: ep: iATU registers must be written after the BAR_MASK

by Niklas Cassel

The DWC Databook description for the LWR_TARGET_RW and LWR_TARGET_HW fields in the IATU_LWR_TARGET_ADDR_OFF_INBOUND_i registers state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested size of the first set_bar() call. The reset value of the BAR_MASK is SoC dependent. Thus, if the first set_bar() call requests a size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Cc: stable(a)vger.kernel.org Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index f3ac7d46a855..bad588ef69a4 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,19 +222,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - reg = PCI_BASE_ADDRESS_0 + (4 * bar); - - if (!(flags & PCI_BASE_ADDRESS_SPACE)) - type = PCIE_ATU_TYPE_MEM; - else - type = PCIE_ATU_TYPE_IO; - - ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); - if (ret) - return ret; - if (ep->epf_bar[bar]) - return 0; + goto config_atu; + + reg = PCI_BASE_ADDRESS_0 + (4 * bar); dw_pcie_dbi_ro_wr_en(pci); @@ -246,9 +237,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, dw_pcie_ep_writel_dbi(ep, func_no, reg + 4, 0); } - ep->epf_bar[bar] = epf_bar; dw_pcie_dbi_ro_wr_dis(pci); +config_atu: + if (!(flags & PCI_BASE_ADDRESS_SPACE)) + type = PCIE_ATU_TYPE_MEM; + else + type = PCIE_ATU_TYPE_IO; + + ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); + if (ret) + return ret; + + ep->epf_bar[bar] = epf_bar; + return 0; } -- 2.47.0

10 months, 1 week

3
4
0 0

[PATCH v6 2/6] PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()

by Niklas Cassel

In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured. This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks. If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.) Cc: stable(a)vger.kernel.org Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index bad588ef69a4..44a617d54b15 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,8 +222,28 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - if (ep->epf_bar[bar]) + /* + * Certain EPF drivers dynamically change the physical address of a BAR + * (i.e. they call set_bar() twice, without ever calling clear_bar(), as + * calling clear_bar() would clear the BAR's PCI address assigned by the + * host). + */ + if (ep->epf_bar[bar]) { + /* + * We can only dynamically change a BAR if the new BAR size and + * BAR flags do not differ from the existing configuration. + */ + if (ep->epf_bar[bar]->barno != bar || + ep->epf_bar[bar]->size != size || + ep->epf_bar[bar]->flags != flags) + return -EINVAL; + + /* + * When dynamically changing a BAR, skip writing the BAR reg, as + * that would clear the BAR's PCI address assigned by the host. + */ goto config_atu; + } reg = PCI_BASE_ADDRESS_0 + (4 * bar); -- 2.47.1

10 months, 1 week

1
0
0 0

[PATCH v6 1/6] PCI: dwc: ep: Write BAR_MASK before iATU registers in pci_epc_set_bar()

by Niklas Cassel

The "DesignWare Cores PCI Express Controller Register Descriptions, Version 4.60a", section "1.21.70 IATU_LWR_TARGET_ADDR_OFF_INBOUND_i", fields LWR_TARGET_RW and LWR_TARGET_HW both state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested BAR size (which is supplied in the struct pci_epf_bar which is passed to pci_epc_set_bar()). The reset value of the BAR_MASK is SoC dependent. Thus, if the struct pci_epf_bar requests a BAR size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Cc: stable(a)vger.kernel.org Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index f3ac7d46a855..bad588ef69a4 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,19 +222,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - reg = PCI_BASE_ADDRESS_0 + (4 * bar); - - if (!(flags & PCI_BASE_ADDRESS_SPACE)) - type = PCIE_ATU_TYPE_MEM; - else - type = PCIE_ATU_TYPE_IO; - - ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); - if (ret) - return ret; - if (ep->epf_bar[bar]) - return 0; + goto config_atu; + + reg = PCI_BASE_ADDRESS_0 + (4 * bar); dw_pcie_dbi_ro_wr_en(pci); @@ -246,9 +237,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, dw_pcie_ep_writel_dbi(ep, func_no, reg + 4, 0); } - ep->epf_bar[bar] = epf_bar; dw_pcie_dbi_ro_wr_dis(pci); +config_atu: + if (!(flags & PCI_BASE_ADDRESS_SPACE)) + type = PCIE_ATU_TYPE_MEM; + else + type = PCIE_ATU_TYPE_IO; + + ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); + if (ret) + return ret; + + ep->epf_bar[bar] = epf_bar; + return 0; } -- 2.47.1

10 months, 1 week

1
0
0 0

[PATCH v2] soc: qcom: llcc: Enable LLCC_WRCACHE at boot on X1

by Konrad Dybcio

From: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Do so in accordance with the internal recommendations. Fixes: b3cf69a43502 ("soc: qcom: llcc: Add configuration data for X1E80100") Cc: stable(a)vger.kernel.org Reviewed-by: Rajendra Nayak <quic_rjendra(a)quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> --- Changes in v2: - Cc stable - Add more context lines - Pick up r-b - Link to v1: https://lore.kernel.org/r/20241207-topic-llcc_x1e_wrcache-v1-1-232e6aff49e4… --- drivers/soc/qcom/llcc-qcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c index 32c3bc887cefb87c296e3ba67a730c87fa2fa346..1560db00a01248197e5c2936e785a5ea77f74ad8 100644 --- a/drivers/soc/qcom/llcc-qcom.c +++ b/drivers/soc/qcom/llcc-qcom.c @@ -2997,20 +2997,21 @@ static const struct llcc_slice_config x1e80100_data[] = { .bonus_ways = 0xfff, .cache_mode = 0, }, { .usecase_id = LLCC_WRCACHE, .slice_id = 31, .max_cap = 1024, .priority = 1, .fixed_size = true, .bonus_ways = 0xfff, .cache_mode = 0, + .activate_on_init = true, }, { .usecase_id = LLCC_CAMEXP0, .slice_id = 4, .max_cap = 256, .priority = 4, .fixed_size = true, .bonus_ways = 0x3, .cache_mode = 0, }, { .usecase_id = LLCC_CAMEXP1, --- base-commit: 3e42dc9229c5950e84b1ed705f94ed75ed208228 change-id: 20241207-topic-llcc_x1e_wrcache-647070e2d130 Best regards, -- Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com>

10 months, 1 week

3
3
0 0

[PATCH v4 0/7] drm: Add DSI/DP support for Renesas r8a779h0 V4M and grey-hawk board

by Tomi Valkeinen

Add everything needed to support the DSI output on Renesas r8a779h0 (V4M) SoC, and the DP output (via sn65dsi86 DSI to DP bridge) on the Renesas grey-hawk board. Overall the DSI and the board design is almost identical to Renesas r8a779g0 and white-hawk board. Note: the v4 no longer has the dts and the clk patches, as those have been merged to renesas-devel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas(a)ideasonboard.com> --- Changes in v4: - Dropped patches merged to renesas-devel - Added new patch "dt-bindings: display: renesas,du: Add missing maxItems" to fix the bindings - Add the missing maxItems to "dt-bindings: display: renesas,du: Add r8a779h0" - Link to v3: https://lore.kernel.org/r/20241206-rcar-gh-dsi-v3-0-d74c2166fa15@ideasonboa… Changes in v3: - Update "Write DPTSR only if there are more than one crtc" patch to "Write DPTSR only if the second source exists" - Add Laurent's Rb - Link to v2: https://lore.kernel.org/r/20241205-rcar-gh-dsi-v2-0-42471851df86@ideasonboa… Changes in v2: - Add the DT binding with a new conditional block, so that we can set only the port@0 as required - Drop port@1 from r8a779h0.dtsi (there's no port@1) - Add a new patch to write DPTSR only if num_crtcs > 1 - Drop RCAR_DU_FEATURE_NO_DPTSR (not needed anymore) - Add Cc: stable to the fix, and move it as first patch - Added the tags from reviews - Link to v1: https://lore.kernel.org/r/20241203-rcar-gh-dsi-v1-0-738ae1a95d2a@ideasonboa… --- Tomi Valkeinen (7): drm/rcar-du: dsi: Fix PHY lock bit check drm/rcar-du: Write DPTSR only if the second source exists dt-bindings: display: renesas,du: Add missing maxItems dt-bindings: display: renesas,du: Add r8a779h0 dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779h0 drm/rcar-du: dsi: Add r8a779h0 support drm/rcar-du: Add support for r8a779h0 .../display/bridge/renesas,dsi-csi2-tx.yaml | 1 + .../devicetree/bindings/display/renesas,du.yaml | 63 ++++++++++++++++++++-- drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 18 +++++++ drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 24 ++++++--- drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 4 +- .../gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 1 - 6 files changed, 99 insertions(+), 12 deletions(-) --- base-commit: adc218676eef25575469234709c2d87185ca223a change-id: 20241008-rcar-gh-dsi-9c01f5deeac8 Best regards, -- Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>

10 months, 1 week

1
1
0 0

[PATCH] fs: fix is_mnt_ns_file()

by Miklos Szeredi

Commit 1fa08aece425 ("nsfs: convert to path_from_stashed() helper") reused nsfs dentry's d_fsdata, which no longer contains a pointer to proc_ns_operations. Fix the remaining use in is_mnt_ns_file(). Fixes: 1fa08aece425 ("nsfs: convert to path_from_stashed() helper") Cc: <stable(a)vger.kernel.org> # v6.9 Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> --- Came across this while getting the mnt_ns in fsnotify_mark(), tested the fix in that context. I don't have a test for mainline, though. fs/namespace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 23e81c2a1e3f..6eec7794f707 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2055,9 +2055,15 @@ SYSCALL_DEFINE1(oldumount, char __user *, name) static bool is_mnt_ns_file(struct dentry *dentry) { + struct ns_common *ns; + /* Is this a proxy for a mount namespace? */ - return dentry->d_op == &ns_dentry_operations && - dentry->d_fsdata == &mntns_operations; + if (dentry->d_op != &ns_dentry_operations) + return false; + + ns = d_inode(dentry)->i_private; + + return ns->ops == &mntns_operations; } struct ns_common *from_mnt_ns(struct mnt_namespace *mnt) -- 2.47.0

10 months, 1 week

4
3
0 0

[PATCH 0/3] scsi: ufs: qcom: Suspend fixes

by Manivannan Sadhasivam via B4 Relay

Hi, This series fixes the several suspend issues on Qcom platforms. Patch 1 fixes the resume failure with spm_lvl=5 suspend on most of the Qcom platforms. For this patch, I couldn't figure out the exact commit that caused the issue. So I used the commit that introduced reinit support as a placeholder. Patch 3 fixes the suspend issue on SM8550 and SM8650 platforms where UFS PHY retention is not supported. Hence the default spm_lvl=3 suspend fails. So this patch configures spm_lvl=5 as the default suspend level to force UFSHC/ device powerdown during suspend. This supersedes the previous series [1] that tried to fix the issue in clock drivers. This series is tested on Qcom SM8550 MTP and Qcom RB5 boards. [1] https://lore.kernel.org/linux-arm-msm/20241107-ufs-clk-fix-v1-0-6032ff22a05… Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> --- Manivannan Sadhasivam (3): scsi: ufs: qcom: Power off the PHY if it was already powered on in ufs_qcom_power_up_sequence() scsi: ufs: qcom: Allow passing platform specific OF data scsi: ufs: qcom: Power down the controller/device during system suspend for SM8550/SM8650 SoCs drivers/ufs/core/ufshcd-priv.h | 6 ------ drivers/ufs/core/ufshcd.c | 1 - drivers/ufs/host/ufs-qcom.c | 31 +++++++++++++++++++------------ drivers/ufs/host/ufs-qcom.h | 5 +++++ include/ufs/ufshcd.h | 2 -- 5 files changed, 24 insertions(+), 21 deletions(-) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241211-ufs-qcom-suspend-fix-5618e9c56d93 Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>

10 months, 1 week

3
4
0 0

Re: [syzbot] [tipc?] kernel BUG in __pskb_pull_tail

by syzbot

syzbot has bisected this issue to: commit de4f5fed3f231a8ff4790bf52975f847b95b85ea Author: Jens Axboe <axboe(a)kernel.dk> Date: Wed Mar 29 14:52:15 2023 +0000 iov_iter: add iter_iovec() helper bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17424730580000 start commit: 96b6fcc0ee41 Merge branch 'net-dsa-cleanup-eee-part-1' git tree: net-next final oops: https://syzkaller.appspot.com/x/report.txt?x=14c24730580000 console output: https://syzkaller.appspot.com/x/log.txt?x=10c24730580000 kernel config: https://syzkaller.appspot.com/x/.config?x=1362a5aee630ff34 dashboard link: https://syzkaller.appspot.com/bug?extid=4f66250f6663c0c1d67e syz repro: https://syzkaller.appspot.com/x/repro.syz?x=166944f8580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1287ecdf980000 Reported-by: syzbot+4f66250f6663c0c1d67e(a)syzkaller.appspotmail.com Fixes: de4f5fed3f23 ("iov_iter: add iter_iovec() helper") For information about bisection process see: https://goo.gl/tpsmEJ#bisection

10 months, 1 week

2
1
0 0

FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 76031d9536a076bf023bedbdb1b4317fc801dd67 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121203-griminess-blah-4e97@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 76031d9536a076bf023bedbdb1b4317fc801dd67 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Tue, 3 Dec 2024 11:16:30 +0100 Subject: [PATCH] clocksource: Make negative motion detection more robust Guenter reported boot stalls on a emulated ARM 32-bit platform, which has a 24-bit wide clocksource. It turns out that the calculated maximal idle time, which limits idle sleeps to prevent clocksource wrap arounds, is close to the point where the negative motion detection triggers. max_idle_ns: 597268854 ns negative motion tripping point: 671088640 ns If the idle wakeup is delayed beyond that point, the clocksource advances far enough to trigger the negative motion detection. This prevents the clock to advance and in the worst case the system stalls completely if the consecutive sleeps based on the stale clock are delayed as well. Cure this by calculating a more robust cut-off value for negative motion, which covers 87.5% of the actual clocksource counter width. Compare the delta against this value to catch negative motion. This is specifically for clock sources with a small counter width as their wrap around time is close to the half counter width. For clock sources with wide counters this is not a problem because the maximum idle time is far from the half counter width due to the math overflow protection constraints. For the case at hand this results in a tripping point of 1174405120ns. Note, that this cannot prevent issues when the delay exceeds the 87.5% margin, but that's not different from the previous unchecked version which allowed arbitrary time jumps. Systems with small counter width are prone to invalid results, but this problem is unlikely to be seen on real hardware. If such a system completely stalls for more than half a second, then there are other more urgent problems than the counter wrapping around. Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Guenter Roeck <linux(a)roeck-us.net> Link: https://lore.kernel.org/all/8734j5ul4x.ffs@tglx Closes: https://lore.kernel.org/all/387b120b-d68a-45e8-b6ab-768cd95d11c2@roeck-us.n… diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h index ef1b16da6ad5..65b7c41471c3 100644 --- a/include/linux/clocksource.h +++ b/include/linux/clocksource.h @@ -49,6 +49,7 @@ struct module; * @archdata: Optional arch-specific data * @max_cycles: Maximum safe cycle value which won't overflow on * multiplication + * @max_raw_delta: Maximum safe delta value for negative motion detection * @name: Pointer to clocksource name * @list: List head for registration (internal) * @freq_khz: Clocksource frequency in khz. @@ -109,6 +110,7 @@ struct clocksource { struct arch_clocksource_data archdata; #endif u64 max_cycles; + u64 max_raw_delta; const char *name; struct list_head list; u32 freq_khz; diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index aab6472853fa..7304d7cf47f2 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -24,7 +24,7 @@ static void clocksource_enqueue(struct clocksource *cs); static noinline u64 cycles_to_nsec_safe(struct clocksource *cs, u64 start, u64 end) { - u64 delta = clocksource_delta(end, start, cs->mask); + u64 delta = clocksource_delta(end, start, cs->mask, cs->max_raw_delta); if (likely(delta < cs->max_cycles)) return clocksource_cyc2ns(delta, cs->mult, cs->shift); @@ -993,6 +993,15 @@ static inline void clocksource_update_max_deferment(struct clocksource *cs) cs->max_idle_ns = clocks_calc_max_nsecs(cs->mult, cs->shift, cs->maxadj, cs->mask, &cs->max_cycles); + + /* + * Threshold for detecting negative motion in clocksource_delta(). + * + * Allow for 0.875 of the counter width so that overly long idle + * sleeps, which go slightly over mask/2, do not trigger the + * negative motion detection. + */ + cs->max_raw_delta = (cs->mask >> 1) + (cs->mask >> 2) + (cs->mask >> 3); } static struct clocksource *clocksource_find_best(bool oneshot, bool skipcur) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 0ca85ff4fbb4..3d128825d343 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -755,7 +755,8 @@ static void timekeeping_forward_now(struct timekeeper *tk) u64 cycle_now, delta; cycle_now = tk_clock_read(&tk->tkr_mono); - delta = clocksource_delta(cycle_now, tk->tkr_mono.cycle_last, tk->tkr_mono.mask); + delta = clocksource_delta(cycle_now, tk->tkr_mono.cycle_last, tk->tkr_mono.mask, + tk->tkr_mono.clock->max_raw_delta); tk->tkr_mono.cycle_last = cycle_now; tk->tkr_raw.cycle_last = cycle_now; @@ -2230,7 +2231,8 @@ static bool timekeeping_advance(enum timekeeping_adv_mode mode) return false; offset = clocksource_delta(tk_clock_read(&tk->tkr_mono), - tk->tkr_mono.cycle_last, tk->tkr_mono.mask); + tk->tkr_mono.cycle_last, tk->tkr_mono.mask, + tk->tkr_mono.clock->max_raw_delta); /* Check if there's really nothing to do */ if (offset < real_tk->cycle_interval && mode == TK_ADV_TICK) diff --git a/kernel/time/timekeeping_internal.h b/kernel/time/timekeeping_internal.h index 63e600e943a7..8c9079108ffb 100644 --- a/kernel/time/timekeeping_internal.h +++ b/kernel/time/timekeeping_internal.h @@ -30,15 +30,15 @@ static inline void timekeeping_inc_mg_floor_swaps(void) #endif -static inline u64 clocksource_delta(u64 now, u64 last, u64 mask) +static inline u64 clocksource_delta(u64 now, u64 last, u64 mask, u64 max_delta) { u64 ret = (now - last) & mask; /* - * Prevent time going backwards by checking the MSB of mask in - * the result. If set, return 0. + * Prevent time going backwards by checking the result against + * @max_delta. If greater, return 0. */ - return ret & ~(mask >> 1) ? 0 : ret; + return ret > max_delta ? 0 : ret; } /* Semi public for serialization of non timekeeper VDSO updates. */

10 months, 1 week

4
9
0 0

Re: [PATCH v5.10.277] wifi: mac80211: Avoid address calculations via out of bounds array indexing

by Greg KH

On Mon, Oct 28, 2024 at 05:00:02PM +0530, Hardik Gohil wrote: > On Mon, Oct 21, 2024 at 3:10 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > > > On Sat, Oct 19, 2024 at 11:06:40AM +0530, Hardik Gohil wrote: > > > From: Kenton Groombridge <concord(a)gentoo.org> > > > > > > [ Upstream commit 2663d0462eb32ae7c9b035300ab6b1523886c718 ] > > > > We can't take patches for 5.10 that are not already in 5.15. Please fix > > up and resend for ALL relevent trees. > > > > thanks, > > > > greg k-h > > I have just confirmed those are applicable to v5.15 and v5.10. > > Request to add those patches. Please send tested backports. thanks, greg k-h

10 months, 1 week

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024