From: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com>
Ensure TX descriptor type fields are written in a safe order so the DMA
engine does not begin processing a chain before all descriptors are
fully initialised.
For multi-descriptor transmissions the driver writes DT_FEND into the
last descriptor and DT_FSTART into the first. The DMA engine starts
processing when it sees DT_FSTART. If the compiler or CPU reorders the
writes and publishes DT_FSTART before DT_FEND, the DMA can start early
and process an incomplete chain, leading to corrupted transmissions or
DMA errors.
Fix this by writing DT_FEND before the dma_wmb() barrier, executing
dma_wmb() immediately before DT_FSTART (or DT_FSINGLE in the single
descriptor case), and then adding a wmb() after the type updates to
ensure CPU-side ordering before ringing the hardware doorbell.
On an RZ/G2L platform running an RT kernel, this reordering hazard was
observed as TX stalls and timeouts:
[ 372.968431] NETDEV WATCHDOG: end0 (ravb): transmit queue 0 timed out
[ 372.968494] WARNING: CPU: 0 PID: 10 at net/sched/sch_generic.c:467 dev_watchdog+0x4a4/0x4ac
[ 373.969291] ravb 11c20000.ethernet end0: transmit timed out, status 00000000, resetting...
This change enforces the required ordering and prevents the DMA engine
from observing DT_FSTART before the rest of the descriptor chain is
valid.
Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
Cc: stable(a)vger.kernel.org
Co-developed-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com>
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com>
---
drivers/net/ethernet/renesas/ravb_main.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index a200e205825a..2a995fa9bfff 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2211,15 +2211,19 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
skb_tx_timestamp(skb);
}
- /* Descriptor type must be set after all the above writes */
- dma_wmb();
+
+ /* For multi-descriptors set DT_FEND before calling dma_wmb() */
if (num_tx_desc > 1) {
desc->die_dt = DT_FEND;
desc--;
- desc->die_dt = DT_FSTART;
- } else {
- desc->die_dt = DT_FSINGLE;
}
+
+ /* Descriptor type must be set after all the above writes */
+ dma_wmb();
+ desc->die_dt = (num_tx_desc > 1) ? DT_FSTART : DT_FSINGLE;
+
+ /* Ensure data is written to RAM before initiating DMA transfer */
+ wmb();
ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);
priv->cur_tx[q] += num_tx_desc;
--
2.43.0
Some NTFS volumes failed to mount because sparse data runs were not
handled correctly during runlist unpacking. The code performed arithmetic
on the special SPARSE_LCN64 marker, leading to invalid LCN values and
mount errors.
Add an explicit check for the case described above, marking the run as
sparse without applying arithmetic.
Fixes: 736fc7bf5f68 ("fs: ntfs3: Fix integer overflow in run_unpack()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com>
---
fs/ntfs3/run.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/ntfs3/run.c b/fs/ntfs3/run.c
index 88550085f745..5df55e4adbb1 100644
--- a/fs/ntfs3/run.c
+++ b/fs/ntfs3/run.c
@@ -984,8 +984,12 @@ int run_unpack(struct runs_tree *run, struct ntfs_sb_info *sbi, CLST ino,
if (!dlcn)
return -EINVAL;
- if (check_add_overflow(prev_lcn, dlcn, &lcn))
+ /* Check special combination: 0 + SPARSE_LCN64. */
+ if (!prev_lcn && dlcn == SPARSE_LCN64) {
+ lcn = SPARSE_LCN64;
+ } else if (check_add_overflow(prev_lcn, dlcn, &lcn)) {
return -EINVAL;
+ }
prev_lcn = lcn;
} else {
/* The size of 'dlcn' can't be > 8. */
--
2.43.0
Hi Greg,
On 16/10/2025 15:25, gregkh(a)linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> selftests: mptcp: join: validate C-flag + def limit
>
> to the 5.10-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:
> selftests-mptcp-join-validate-c-flag-def-limit.patch
> and it can be found in the queue-5.10 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.
I do! :)
> From 008385efd05e04d8dff299382df2e8be0f91d8a0 Mon Sep 17 00:00:00 2001
> From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org>
> Date: Thu, 25 Sep 2025 12:32:37 +0200
> Subject: selftests: mptcp: join: validate C-flag + def limit
>
> From: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
>
> commit 008385efd05e04d8dff299382df2e8be0f91d8a0 upstream.
>
> The previous commit adds an exception for the C-flag case. The
> 'mptcp_join.sh' selftest is extended to validate this case.
>
> In this subtest, there is a typical CDN deployment with a client where
> MPTCP endpoints have been 'automatically' configured:
>
> - the server set net.mptcp.allow_join_initial_addr_port=0
>
> - the client has multiple 'subflow' endpoints, and the default limits:
> not accepting ADD_ADDRs.
>
> Without the parent patch, the client is not able to establish new
> subflows using its 'subflow' endpoints. The parent commit fixes that.
>
> The 'Fixes' tag here below is the same as the one from the previous
> commit: this patch here is not fixing anything wrong in the selftests,
> but it validates the previous fix for an issue introduced by this commit
> ID.
>
> Fixes: df377be38725 ("mptcp: add deny_join_id0 in mptcp_options_received")
This commit has been introduced in v5.14, and not backported before. Do
you mind dropping it from v5.10 please? :)
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
This series fixes a regression introduced in commit 0af46fbc333d
("media: i2c: imx219: Calculate crop rectangle dynamically") that
started using vertical binning for 1920x1080 without binning
horizontally, causing the captured images to be stretched in one
dimension.
In a subsequent patch, simplify the binning mode calculation logic as
well. This is done separately, without a fixes tag, as it is cleaning up
code that was introduced much later to the regression commit, and
doesn't strictly require backporting.
Once Sakari's metadata series with binning controls [1] is merged, this
and other existing sensor drivers may be extended to support free
configuration of resolution, and give the userspace freedom to bin
pixels in only one dimension if required, of course, as long as it
doesn't cause regressions with exsiting userspace applications.
[1]: https://lore.kernel.org/all/20250825095107.1332313-44-sakari.ailus@linux.in…
Signed-off-by: Jai Luthra <jai.luthra(a)ideasonboard.com>
---
Dave Stevenson (1):
media: i2c: imx219: Fix 1920x1080 mode to use 1:1 pixel aspect ratio
Jai Luthra (1):
media: i2c: imx219: Simplify imx219_get_binning() function
drivers/media/i2c/imx219.c | 25 +++++++++----------------
1 file changed, 9 insertions(+), 16 deletions(-)
---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251016-imx219-1080p-ad3fbdce70d1
Best regards,
--
Jai Luthra <jai.luthra(a)ideasonboard.com>
Hi,
As discussed in [1], here are the backports of the s390 BPF tail
counter fixes. Commits 1-2 are NFC prerequisites, commits 3-4 are
fixes themselves.
[1] https://lore.kernel.org/stable/CA+G9fYsdErtgqKuyPfFhMS9haGKavBVCHQnipv2EeXM…
Best regards,
Ilya
Ilya Leoshkevich (4):
s390/bpf: Centralize frame offset calculations
s390/bpf: Describe the frame using a struct instead of constants
s390/bpf: Write back tail call counter for BPF_PSEUDO_CALL
s390/bpf: Write back tail call counter for BPF_TRAMP_F_CALL_ORIG
arch/s390/net/bpf_jit.h | 55 --------------
arch/s390/net/bpf_jit_comp.c | 139 ++++++++++++++++++++++-------------
2 files changed, 86 insertions(+), 108 deletions(-)
delete mode 100644 arch/s390/net/bpf_jit.h
--
2.51.0
The VMA count limit check in do_mmap() and do_brk_flags() uses a
strict inequality (>), which allows a process's VMA count to exceed
the configured sysctl_max_map_count limit by one.
A process with mm->map_count == sysctl_max_map_count will incorrectly
pass this check and then exceed the limit upon allocation of a new VMA
when its map_count is incremented.
Other VMA allocation paths, such as split_vma(), already use the
correct, inclusive (>=) comparison.
Fix this bug by changing the comparison to be inclusive in do_mmap()
and do_brk_flags(), bringing them in line with the correct behavior
of other allocation paths.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: <stable(a)vger.kernel.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: "Liam R. Howlett" <Liam.Howlett(a)oracle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Pedro Falcato <pfalcato(a)suse.de>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com>
Reviewed-by: Pedro Falcato <pfalcato(a)suse.de>
Acked-by: SeongJae Park <sj(a)kernel.org>
Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com>
---
Changes in v3:
- Collect Reviewed-by and Acked-by tags.
Changes in v2:
- Fix mmap check, per Pedro
mm/mmap.c | 2 +-
mm/vma.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 644f02071a41..da2cbdc0f87b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -374,7 +374,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
return -EOVERFLOW;
/* Too many mappings? */
- if (mm->map_count > sysctl_max_map_count)
+ if (mm->map_count >= sysctl_max_map_count)
return -ENOMEM;
/*
diff --git a/mm/vma.c b/mm/vma.c
index a2e1ae954662..fba68f13e628 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -2797,7 +2797,7 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma,
if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT))
return -ENOMEM;
- if (mm->map_count > sysctl_max_map_count)
+ if (mm->map_count >= sysctl_max_map_count)
return -ENOMEM;
if (security_vm_enough_memory_mm(mm, len >> PAGE_SHIFT))
--
2.51.0.760.g7b8bcc2412-goog
In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to
the dma_buf for comparison purposes. However, this reference is never
released when the function returns, leading to a dma_buf memory leak.
Fix this by adding dma_buf_put before returning from the function,
ensuring that the temporarily acquired reference is properly released
regardless of whether a matching map is found.
Fixes: 9031626ade38 ("misc: fastrpc: Fix fastrpc_map_lookup operation")
Cc: stable(a)kernel.org
Signed-off-by: Junhao Xie <bigfoot(a)radxa.com>
Tested-by: Xilin Wu <sophon(a)radxa.com>
---
drivers/misc/fastrpc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 621bce7e101c1..ee652ef01534a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -381,6 +381,8 @@ static int fastrpc_map_lookup(struct fastrpc_user *fl, int fd,
}
spin_unlock(&fl->lock);
+ dma_buf_put(buf);
+
return ret;
}
--
2.50.1