Hello Christian,
It will cause problems for real applications if the specific event happens, but that happens with a very low probability. It's more an issue that can be resolved at the author's convenience, but I would be comfortable if the issue I discovered is acknowledged at least, if not addressed.
Thanks
Shehab
________________________________________
From: Ahmed, Shehab Sarar <shehaba2(a)illinois.edu>
Sent: Sunday, February 2, 2025 6:10 PM
To: Christian Heusel
Cc: stable(a)vger.kernel.org; regressions(a)lists.linux.dev
Subject: Re: TCP Fast Retransmission Issue
Hello Christian,
It will cause problems for real applications if the specific event happens, but that happens with a very low probability. It's more an issue that can be resolved at the author's convenience, but I would be comfortable if the issue I discovered is acknowledged at least, if not addressed.
Thanks
Shehab
________________________________
From: Christian Heusel
Sent: Sunday, February 2, 2025 3:26 AM
To: Ahmed, Shehab Sarar
Cc: stable(a)vger.kernel.org; regressions(a)lists.linux.dev
Subject: Re: TCP Fast Retransmission Issue
On 25/02/02 10:26AM, Christian Heusel wrote:
> On 25/02/01 07:09PM, Ahmed, Shehab Sarar wrote:
> > Hello,
>
> Hello,
>
> > While experimenting with bbr protocol, I manipulated the network conditions by maintaining a high RTT for about one second before abruptly reducing it. Some packets sent during the high RTT phase experienced long delays in reaching the destination, while later packets, benefiting from the lower RTT, arrived earlier. This out-of-order arrival triggered the receiver to generate duplicate acknowledgments (dup ACKs). Due to the low RTT, these dup ACKs quickly reached the sender. Upon receiving three dup ACKs, the sender initiated a fast retransmission for an earlier packet that was not lost but was simply taking longer to arrive. Interestingly, despite the fast-retransmitted packet experienced a lower RTT, the original delayed packet still arrived first. When the receiver received this packet, it sent an ACK for the next packet in sequence. However, upon later receiving the fast-retransmitted packet, an issue arose in its logic for updating the acknowledgment number. As a result, even after the next expected packet was received, the acknowledgment number was not updated correctly. The receiver continued sending dup ACKs, ultimately forcing bbr into the retransmission timeout (RTO) phase.
> >
> > I generated this issue in linux kernel version 5.15.0-117-generic with Ubuntu 20.04. I attempted to confirm whether the issue persists with the latest Linux kernel. However, I discovered that the behavior of bbr has changed in the most recent kernel version, where it now sends chunks of packets instead of sending them one by one over time. As a result, I was unable to reproduce the specific sequence of events that triggered the bug we identified. Consequently, I could not confirm whether the bug still exists in the latest kernel.
> >
> > I believe that the issue (if still exists) will have to be resolved in the location net/ipv4/tcp_input.c or something like that. There are so many authors here that I do not know who to CC here. So, sending this email to you. Sorry if this is not the best way to report this issue.
>
> does this cause problems for real applications? To me it sounds a bit
> like a constructed issue, but I'm also not really proficient about the
> stack mentioned about :p
>
> I'm asking because this is important for how we treat this report, see
> the "Reporting Regression"[0] document for more details on what we
> consider to be an regression.
>
> > Thanks
> > Shehab
>
> Cheers,
> Christian
(forgot the link)
[0]: https://docs.kernel.org/admin-guide/reporting-regressions.html#what-is-a-re…
While by default max_autoclose equals to INT_MAX / HZ, one may set
net.sctp.max_autoclose to UINT_MAX. There is code in
sctp_association_init() that can consequently trigger overflow.
Cc: stable(a)vger.kernel.org
Fixes: 9f70f46bd4c7 ("sctp: properly latch and use autoclose value from sock to association")
Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru>
---
net/sctp/associola.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index c45c192b7878..0b0794f164cf 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -137,7 +137,8 @@ static struct sctp_association *sctp_association_init(
= 5 * asoc->rto_max;
asoc->timeouts[SCTP_EVENT_TIMEOUT_SACK] = asoc->sackdelay;
- asoc->timeouts[SCTP_EVENT_TIMEOUT_AUTOCLOSE] = sp->autoclose * HZ;
+ asoc->timeouts[SCTP_EVENT_TIMEOUT_AUTOCLOSE] =
+ (unsigned long)sp->autoclose * HZ;
/* Initializes the timers */
for (i = SCTP_EVENT_TIMEOUT_NONE; i < SCTP_NUM_TIMEOUT_TYPES; ++i)
--
2.34.1
On 02/02/2025 05:23, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> ARM: dts: aspeed: yosemite4: correct the compatible string for max31790
>
> to the 6.13-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:
> arm-dts-aspeed-yosemite4-correct-the-compatible-stri.patch
> and it can be found in the queue-6.13 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 64b29da76fb21bbb955e262461996d37865d4ae9
> Author: Ricky CX Wu <ricky.cx.wu.wiwynn(a)gmail.com>
> Date: Thu Oct 3 15:42:46 2024 +0800
>
> ARM: dts: aspeed: yosemite4: correct the compatible string for max31790
>
> [ Upstream commit b1a1ecb669bfa763ee5e86a038d7c9363eee7548 ]
>
> Fix the compatible string for max31790 to match the binding document.
>
> Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC")
> Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn(a)gmail.com>
> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu(a)wiwynn.com>
> Link: https://patch.msgid.link/20241003074251.3818101-6-Delphine_CC_Chiu@wiwynn.c…
> Signed-off-by: Andrew Jeffery <andrew(a)codeconstruct.com.au>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Sasha, something got broken in your scripts.
I received today huge flood (100? 200?) of such stable confirmations,
but I am not listed above at all. No tags came here from me, so why I am
Cc-ed on all this?
Best regards,
Krzysztof
When attaching uretprobes to processes running inside docker, the attached
process is segfaulted when encountering the retprobe.
The reason is that now that uretprobe is a system call the default seccomp
filters in docker block it as they only allow a specific set of known
syscalls. This is true for other userspace applications which use seccomp
to control their syscall surface.
Since uretprobe is a "kernel implementation detail" system call which is
not used by userspace application code directly, it is impractical and
there's very little point in forcing all userspace applications to
explicitly allow it in order to avoid crashing tracked processes.
Pass this systemcall through seccomp without depending on configuration.
Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo
uses the same number as __NR_uretprobe so the syscall isn't forced in the
compat bitmap.
Fixes: ff474a78cef5 ("uprobe: Add uretprobe syscall to speed up return probe")
Reported-by: Rafael Buchbinder <rafi(a)rbk.io>
Link: https://lore.kernel.org/lkml/CAHsH6Gs3Eh8DFU0wq58c_LF8A4_+o6z456J7BidmcVY2A…
Link: https://lore.kernel.org/lkml/20250121182939.33d05470@gandalf.local.home/T/#…
Cc: stable(a)vger.kernel.org
Signed-off-by: Eyal Birger <eyal.birger(a)gmail.com>
---
v2: use action_cache bitmap and mode1 array to check the syscall
The following reproduction script synthetically demonstrates the problem
for seccomp filters:
cat > /tmp/x.c << EOF
char *syscalls[] = {
"write",
"exit_group",
"fstat",
};
__attribute__((noinline)) int probed(void)
{
printf("Probed\n");
return 1;
}
void apply_seccomp_filter(char **syscalls, int num_syscalls)
{
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_KILL);
for (int i = 0; i < num_syscalls; i++) {
seccomp_rule_add(ctx, SCMP_ACT_ALLOW,
seccomp_syscall_resolve_name(syscalls[i]), 0);
}
seccomp_load(ctx);
seccomp_release(ctx);
}
int main(int argc, char *argv[])
{
int num_syscalls = sizeof(syscalls) / sizeof(syscalls[0]);
apply_seccomp_filter(syscalls, num_syscalls);
probed();
return 0;
}
EOF
cat > /tmp/trace.bt << EOF
uretprobe:/tmp/x:probed
{
printf("ret=%d\n", retval);
}
EOF
gcc -o /tmp/x /tmp/x.c -lseccomp
/usr/bin/bpftrace /tmp/trace.bt &
sleep 5 # wait for uretprobe attach
/tmp/x
pkill bpftrace
rm /tmp/x /tmp/x.c /tmp/trace.bt
---
kernel/seccomp.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 385d48293a5f..23b594a68bc0 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter)
#ifdef SECCOMP_ARCH_NATIVE
/**
- * seccomp_is_const_allow - check if filter is constant allow with given data
+ * seccomp_is_filter_const_allow - check if filter is constant allow with given data
* @fprog: The BPF programs
* @sd: The seccomp data to check against, only syscall number and arch
* number are considered constant.
*/
-static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
- struct seccomp_data *sd)
+static bool seccomp_is_filter_const_allow(struct sock_fprog_kern *fprog,
+ struct seccomp_data *sd)
{
unsigned int reg_value = 0;
unsigned int pc;
@@ -812,6 +812,21 @@ static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
return false;
}
+static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog,
+ struct seccomp_data *sd)
+{
+#ifdef __NR_uretprobe
+ if (sd->nr == __NR_uretprobe
+#ifdef SECCOMP_ARCH_COMPAT
+ && sd->arch != SECCOMP_ARCH_COMPAT
+#endif
+ )
+ return true;
+#endif
+
+ return seccomp_is_filter_const_allow(fprog, sd);
+}
+
static void seccomp_cache_prepare_bitmap(struct seccomp_filter *sfilter,
void *bitmap, const void *bitmap_prev,
size_t bitmap_size, int arch)
@@ -1023,6 +1038,9 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
*/
static const int mode1_syscalls[] = {
__NR_seccomp_read, __NR_seccomp_write, __NR_seccomp_exit, __NR_seccomp_sigreturn,
+#ifdef __NR_uretprobe
+ __NR_uretprobe,
+#endif
-1, /* negative terminated */
};
--
2.43.0
This is the start of the stable review cycle for the 6.6.75 release.
There are 43 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 01 Feb 2025 13:34:42 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.75-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.6.75-rc1
Jack Greiner <jack(a)emoss.org>
Input: xpad - add support for wooting two he (arm)
Matheos Mattsson <matheos.mattsson(a)gmail.com>
Input: xpad - add support for Nacon Evol-X Xbox One Controller
Leonardo Brondani Schenkel <leonardo(a)schenkel.net>
Input: xpad - improve name of 8BitDo controller 2dc8:3106
Pierre-Loup A. Griffais <pgriffais(a)valvesoftware.com>
Input: xpad - add QH Electronics VID/PID
Nilton Perim Neto <niltonperimneto(a)gmail.com>
Input: xpad - add unofficial Xbox 360 wireless receiver clone
Mark Pearson <mpearson-lenovo(a)squebb.ca>
Input: atkbd - map F23 key to support default copilot shortcut
Nicolas Nobelis <nicolas(a)nobelis.eu>
Input: xpad - add support for Nacon Pro Compact
Lianqin Hu <hulianqin(a)vivo.com>
ALSA: usb-audio: Add delay quirk for USB Audio Device
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null"
Qasim Ijaz <qasdev00(a)gmail.com>
USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()
Easwar Hariharan <eahariha(a)linux.microsoft.com>
scsi: storvsc: Ratelimit warning logs to prevent VM denial of service
Ido Schimmel <idosch(a)nvidia.com>
ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()
Luis Henriques (SUSE) <luis.henriques(a)linux.dev>
ext4: fix access to uninitialised lock in fc replay path
Alex Williamson <alex.williamson(a)redhat.com>
vfio/platform: check the bounds of read/write syscalls
Linus Torvalds <torvalds(a)linux-foundation.org>
cachestat: fix page cache statistics permission checking
Jiri Kosina <jkosina(a)suse.com>
Revert "HID: multitouch: Add support for lenovo Y9000P Touchpad"
Alexey Dobriyan <adobriyan(a)gmail.com>
block: fix integer overflow in BLKSECDISCARD
Jamal Hadi Salim <jhs(a)mojatatu.com>
net: sched: fix ets qdisc OOB Indexing
Paulo Alcantara <pc(a)manguebit.com>
smb: client: handle lack of EA support in smb2_query_path_info()
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Use d_children list to iterate simple_offset directories
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Replace simple_offset end-of-directory detection
Chuck Lever <chuck.lever(a)oracle.com>
Revert "libfs: Add simple_offset_empty()"
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Return ENOSPC when the directory offset range is exhausted
Chuck Lever <chuck.lever(a)oracle.com>
shmem: Fix shmem_rename2()
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Add simple_offset_rename() API
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Fix simple_offset_rename_exchange()
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Add simple_offset_empty()
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Define a minimum directory offset
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Re-arrange locking in offset_iterate_dir()
Andreas Gruenbacher <agruenba(a)redhat.com>
gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
Selvin Xavier <selvin.xavier(a)broadcom.com>
RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop
Omid Ehtemam-Haghighi <omid.ehtemamhaghighi(a)menlosecurity.com>
ipv6: Fix soft lockups in fib6_select_path under high next hop churn
Anastasia Belova <abelova(a)astralinux.ru>
cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value
Igor Pylypiv <ipylypiv(a)google.com>
ata: libata-core: Set ATA_QCFLAG_RTF_FILLED in fill_result_tf()
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: samsung: Add missing depends on I2C
Russell Harmon <russ(a)har.mn>
hwmon: (drivetemp) Set scsi command timeout to 10s
Philippe Simons <simons.philippe(a)gmail.com>
irqchip/sunxi-nmi: Add missing SKIP_WAKE flag
Rob Herring (Arm) <robh(a)kernel.org>
of/unittest: Add test that of_address_to_resource() fails on non-translatable address
Tom Chung <chiahsuan.chung(a)amd.com>
drm/amd/display: Use HW lock mgr for PSR1
Xiang Zhang <hawkxiang.cpp(a)gmail.com>
scsi: iscsi: Fix redundant response for ISCSI_UEVENT_GET_HOST_STATS request
Linus Walleij <linus.walleij(a)linaro.org>
seccomp: Stub for !CONFIG_SECCOMP
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: samsung: Add missing selects for MFD_WM8994
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: wm8994: Add depends on MFD core
-------------
Diffstat:
Makefile | 4 +-
block/ioctl.c | 9 +-
drivers/ata/libahci.c | 12 +-
drivers/ata/libata-core.c | 8 +
drivers/cpufreq/amd-pstate.c | 7 +-
.../gpu/drm/amd/display/dc/dce/dmub_hw_lock_mgr.c | 3 +-
drivers/hid/hid-ids.h | 1 -
drivers/hid/hid-multitouch.c | 8 +-
drivers/hwmon/drivetemp.c | 2 +-
drivers/infiniband/hw/bnxt_re/main.c | 10 +
drivers/input/joystick/xpad.c | 9 +-
drivers/input/keyboard/atkbd.c | 2 +-
drivers/irqchip/irq-sunxi-nmi.c | 3 +-
drivers/of/unittest-data/tests-platform.dtsi | 13 +
drivers/of/unittest.c | 14 ++
drivers/scsi/scsi_transport_iscsi.c | 4 +-
drivers/scsi/storvsc_drv.c | 8 +-
drivers/usb/gadget/function/u_serial.c | 8 +-
drivers/usb/serial/quatech2.c | 2 +-
drivers/vfio/platform/vfio_platform_common.c | 10 +
fs/ext4/super.c | 3 +-
fs/gfs2/file.c | 1 +
fs/libfs.c | 177 ++++++++++----
fs/smb/client/smb2inode.c | 104 +++++---
include/linux/fs.h | 2 +
include/linux/seccomp.h | 2 +-
mm/filemap.c | 19 ++
mm/shmem.c | 3 +-
net/ipv4/ip_tunnel.c | 2 +-
net/ipv6/ip6_fib.c | 8 +-
net/ipv6/route.c | 45 ++--
net/sched/sch_ets.c | 2 +
sound/soc/codecs/Kconfig | 1 +
sound/soc/samsung/Kconfig | 6 +-
sound/usb/quirks.c | 2 +
tools/testing/selftests/net/Makefile | 1 +
.../selftests/net/ipv6_route_update_soft_lockup.sh | 262 +++++++++++++++++++++
37 files changed, 640 insertions(+), 137 deletions(-)
This is the start of the stable review cycle for the 6.12.12 release.
There are 41 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 01 Feb 2025 14:41:19 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.12-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.12.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.12.12-rc2
Jann Horn <jannh(a)google.com>
io_uring/rsrc: require cloned buffers to share accounting contexts
Jack Greiner <jack(a)emoss.org>
Input: xpad - add support for wooting two he (arm)
Matheos Mattsson <matheos.mattsson(a)gmail.com>
Input: xpad - add support for Nacon Evol-X Xbox One Controller
Leonardo Brondani Schenkel <leonardo(a)schenkel.net>
Input: xpad - improve name of 8BitDo controller 2dc8:3106
Pierre-Loup A. Griffais <pgriffais(a)valvesoftware.com>
Input: xpad - add QH Electronics VID/PID
Nilton Perim Neto <niltonperimneto(a)gmail.com>
Input: xpad - add unofficial Xbox 360 wireless receiver clone
Mark Pearson <mpearson-lenovo(a)squebb.ca>
Input: atkbd - map F23 key to support default copilot shortcut
Nicolas Nobelis <nicolas(a)nobelis.eu>
Input: xpad - add support for Nacon Pro Compact
Jason Gerecke <jason.gerecke(a)wacom.com>
HID: wacom: Initialize brightness of LED trigger
Hans de Goede <hdegoede(a)redhat.com>
wifi: rtl8xxxu: add more missing rtl8192cu USB IDs
Lianqin Hu <hulianqin(a)vivo.com>
ALSA: usb-audio: Add delay quirk for USB Audio Device
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null"
Qasim Ijaz <qasdev00(a)gmail.com>
USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()
Easwar Hariharan <eahariha(a)linux.microsoft.com>
scsi: storvsc: Ratelimit warning logs to prevent VM denial of service
Alex Williamson <alex.williamson(a)redhat.com>
vfio/platform: check the bounds of read/write syscalls
Linus Torvalds <torvalds(a)linux-foundation.org>
cachestat: fix page cache statistics permission checking
Jiri Kosina <jikos(a)kernel.org>
Revert "HID: multitouch: Add support for lenovo Y9000P Touchpad"
Jamal Hadi Salim <jhs(a)mojatatu.com>
net: sched: fix ets qdisc OOB Indexing
Paulo Alcantara <pc(a)manguebit.com>
smb: client: handle lack of EA support in smb2_query_path_info()
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Use d_children list to iterate simple_offset directories
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Replace simple_offset end-of-directory detection
Chuck Lever <chuck.lever(a)oracle.com>
Revert "libfs: fix infinite directory reads for offset dir"
Chuck Lever <chuck.lever(a)oracle.com>
Revert "libfs: Add simple_offset_empty()"
Chuck Lever <chuck.lever(a)oracle.com>
libfs: Return ENOSPC when the directory offset range is exhausted
Andreas Gruenbacher <agruenba(a)redhat.com>
gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
Yosry Ahmed <yosryahmed(a)google.com>
mm: zswap: move allocations during CPU init outside the lock
Yosry Ahmed <yosryahmed(a)google.com>
mm: zswap: properly synchronize freeing resources during CPU hotunplug
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: samsung: Add missing depends on I2C
Russell Harmon <russ(a)har.mn>
hwmon: (drivetemp) Set scsi command timeout to 10s
Philippe Simons <simons.philippe(a)gmail.com>
irqchip/sunxi-nmi: Add missing SKIP_WAKE flag
Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com>
drm/connector: hdmi: Validate supported_formats matches ycbcr_420_allowed
Yage Geng <icoderdev(a)gmail.com>
ALSA: hda/realtek: Fix volume adjustment issue on Lenovo ThinkBook 16P Gen5
Rob Herring (Arm) <robh(a)kernel.org>
of/unittest: Add test that of_address_to_resource() fails on non-translatable address
Alex Hung <alex.hung(a)amd.com>
drm/amd/display: Initialize denominator defaults to 1
Tom Chung <chiahsuan.chung(a)amd.com>
drm/amd/display: Use HW lock mgr for PSR1
Xiang Zhang <hawkxiang.cpp(a)gmail.com>
scsi: iscsi: Fix redundant response for ISCSI_UEVENT_GET_HOST_STATS request
Maciej Strozek <mstrozek(a)opensource.cirrus.com>
ASoC: cs42l43: Add codec force suspend/resume ops
Linus Walleij <linus.walleij(a)linaro.org>
seccomp: Stub for !CONFIG_SECCOMP
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: samsung: Add missing selects for MFD_WM8994
Marian Postevca <posteuca(a)mutex.one>
ASoC: codecs: es8316: Fix HW rate calculation for 48Mhz MCLK
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: wm8994: Add depends on MFD core
-------------
Diffstat:
Makefile | 4 +-
.../gpu/drm/amd/display/dc/dce/dmub_hw_lock_mgr.c | 3 +-
.../dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 4 +-
drivers/gpu/drm/drm_connector.c | 3 +
drivers/hid/hid-ids.h | 1 -
drivers/hid/hid-multitouch.c | 8 +-
drivers/hid/wacom_sys.c | 24 +--
drivers/hwmon/drivetemp.c | 2 +-
drivers/input/joystick/xpad.c | 9 +-
drivers/input/keyboard/atkbd.c | 2 +-
drivers/irqchip/irq-sunxi-nmi.c | 3 +-
drivers/net/wireless/realtek/rtl8xxxu/core.c | 20 +++
drivers/of/unittest-data/tests-platform.dtsi | 13 ++
drivers/of/unittest.c | 14 ++
drivers/scsi/scsi_transport_iscsi.c | 4 +-
drivers/scsi/storvsc_drv.c | 8 +-
drivers/usb/gadget/function/u_serial.c | 8 +-
drivers/usb/serial/quatech2.c | 2 +-
drivers/vfio/platform/vfio_platform_common.c | 10 ++
fs/gfs2/file.c | 1 +
fs/libfs.c | 162 ++++++++++-----------
fs/smb/client/smb2inode.c | 104 +++++++++----
include/linux/fs.h | 1 -
include/linux/seccomp.h | 2 +-
io_uring/rsrc.c | 7 +
mm/filemap.c | 19 +++
mm/shmem.c | 4 +-
mm/zswap.c | 90 ++++++++----
net/sched/sch_ets.c | 2 +
sound/pci/hda/patch_realtek.c | 4 +-
sound/soc/codecs/Kconfig | 1 +
sound/soc/codecs/cs42l43.c | 1 +
sound/soc/codecs/es8316.c | 10 +-
sound/soc/samsung/Kconfig | 6 +-
sound/usb/quirks.c | 2 +
35 files changed, 374 insertions(+), 184 deletions(-)
Hello,
While experimenting with bbr protocol, I manipulated the network conditions by maintaining a high RTT for about one second before abruptly reducing it. Some packets sent during the high RTT phase experienced long delays in reaching the destination, while later packets, benefiting from the lower RTT, arrived earlier. This out-of-order arrival triggered the receiver to generate duplicate acknowledgments (dup ACKs). Due to the low RTT, these dup ACKs quickly reached the sender. Upon receiving three dup ACKs, the sender initiated a fast retransmission for an earlier packet that was not lost but was simply taking longer to arrive. Interestingly, despite the fast-retransmitted packet experienced a lower RTT, the original delayed packet still arrived first. When the receiver received this packet, it sent an ACK for the next packet in sequence. However, upon later receiving the fast-retransmitted packet, an issue arose in its logic for updating the acknowledgment number. As a result, even after the next expected packet was received, the acknowledgment number was not updated correctly. The receiver continued sending dup ACKs, ultimately forcing bbr into the retransmission timeout (RTO) phase.
I generated this issue in linux kernel version 5.15.0-117-generic with Ubuntu 20.04. I attempted to confirm whether the issue persists with the latest Linux kernel. However, I discovered that the behavior of bbr has changed in the most recent kernel version, where it now sends chunks of packets instead of sending them one by one over time. As a result, I was unable to reproduce the specific sequence of events that triggered the bug we identified. Consequently, I could not confirm whether the bug still exists in the latest kernel.
I believe that the issue (if still exists) will have to be resolved in the location net/ipv4/tcp_input.c or something like that. There are so many authors here that I do not know who to CC here. So, sending this email to you. Sorry if this is not the best way to report this issue.
Thanks
Shehab
________________________________________
From: Ahmed, Shehab Sarar
Sent: Saturday, February 1, 2025 1:01 PM
To: stable(a)vger.kernel.org
Cc: regressions(a)lists.linux.dev
Subject: TCP Fast Retransmission Issue
Hello,
While experimenting with bbr protocol, I manipulated the network conditions by maintaining a high RTT for about one second before abruptly reducing it. Some packets sent during the high RTT phase experienced long delays in reaching the destination, while later packets, benefiting from the lower RTT, arrived earlier. This out-of-order arrival triggered the receiver to generate duplicate acknowledgments (dup ACKs). Due to the low RTT, these dup ACKs quickly reached the sender. Upon receiving three dup ACKs, the sender initiated a fast retransmission for an earlier packet that was not lost but was simply taking longer to arrive. Interestingly, despite the fast-retransmitted packet experienced a lower RTT, the original delayed packet still arrived first. When the receiver received this packet, it sent an ACK for the next packet in sequence. However, upon later receiving the fast-retransmitted packet, an issue arose in its logic for updating the acknowledgment number. As a result, even after the next expected packet was received, the acknowledgment number was not updated correctly. The receiver continued sending dup ACKs, ultimately forcing bbr into the retransmission timeout (RTO) phase.
I generated this issue in linux kernel version 5.15.0-117-generic with Ubuntu 20.04. I attempted to confirm whether the issue persists with the latest Linux kernel. However, I discovered that the behavior of bbr has changed in the most recent kernel version, where it now sends chunks of packets instead of sending them one by one over time. As a result, I was unable to reproduce the specific sequence of events that triggered the bug we identified. Consequently, I could not confirm whether the bug still exists in the latest kernel.
I believe that the issue (if still exists) will have to be resolved in the location net/ipv4/tcp_input.c or something like that. There are so many authors here that I do not know who to CC here. So, sending this email to you. Sorry if this is not the best way to report this issue.
Thanks
Shehab