- Linux-stable-mirror - lists.linaro.org

[PATCH v2] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it being hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitetly waiting in an unkillable state. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 32 +++++++------------------------- 1 file changed, 7 insertions(+), 25 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..3fbfa9751931 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,19 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { - mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ + if (wait_for_completion_killable(&req->c)) { + if (!mutex_lock_killable(&supp->mutex)) { if (req->in_queue) { list_del(&req->link); req->in_queue = false; } + mutex_unlock(&supp->mutex); } - mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

3 weeks, 4 days

3
5
0 0

[PATCH 6.13 00/25] 6.13.1-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.13.1 release. There are 25 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.13.1-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.13.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.13.1-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 Jann Horn <jannh(a)google.com> io_uring/rsrc: require cloned buffers to share accounting contexts 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 ------------- Diffstat: Makefile | 4 +- drivers/hid/hid-ids.h | 1 - drivers/hid/hid-multitouch.c | 8 +- drivers/hid/wacom_sys.c | 24 ++-- drivers/input/joystick/xpad.c | 9 +- drivers/input/keyboard/atkbd.c | 2 +- drivers/net/wireless/realtek/rtl8xxxu/core.c | 20 ++++ 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 - io_uring/rsrc.c | 7 ++ mm/filemap.c | 17 +++ mm/shmem.c | 4 +- net/sched/sch_ets.c | 2 + sound/usb/quirks.c | 2 + 20 files changed, 251 insertions(+), 145 deletions(-)

3 weeks, 4 days

13
39
0 0

Re: Patch "drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed" has been added to the 6.12-stable tree

by Thomas Hellström

Hi On Sat, 2025-02-01 at 23:33 -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed > > to the 6.12-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: > drm-xe-use-ttm_bo_access-in-xe_vm_snapshot_capture_d.patch > and it can be found in the queue-6.12 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. Please avoid including this patch for now. It turned out it needs more dependencies and we will attempt a manual backport later. Thanks, Thomas > > > > commit 7aad4e92ca3782686571792d117b3ffcfe05c65c > Author: Matthew Brost <matthew.brost(a)intel.com> > Date: Tue Nov 26 09:46:13 2024 -0800 > > drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed > > [ Upstream commit 5f7bec831f1f17c354e4307a12cf79b018296975 ] > > Non-contiguous mapping of BO in VRAM doesn't work, use > ttm_bo_access > instead. > > v2: > - Fix error handling > > Fixes: 0eb2a18a8fad ("drm/xe: Implement VM snapshot support for > BO's and userptr") > Suggested-by: Matthew Auld <matthew.auld(a)intel.com> > Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> > Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> > Link: > https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-7-matt… > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c > index c99380271de62..c8782da3a5c38 100644 > --- a/drivers/gpu/drm/xe/xe_vm.c > +++ b/drivers/gpu/drm/xe/xe_vm.c > @@ -3303,7 +3303,6 @@ void xe_vm_snapshot_capture_delayed(struct > xe_vm_snapshot *snap) > > for (int i = 0; i < snap->num_snaps; i++) { > struct xe_bo *bo = snap->snap[i].bo; > - struct iosys_map src; > int err; > > if (IS_ERR(snap->snap[i].data)) > @@ -3316,16 +3315,12 @@ void xe_vm_snapshot_capture_delayed(struct > xe_vm_snapshot *snap) > } > > if (bo) { > - xe_bo_lock(bo, false); > - err = ttm_bo_vmap(&bo->ttm, &src); > - if (!err) { > - xe_map_memcpy_from(xe_bo_device(bo), > - snap- > >snap[i].data, > - &src, snap- > >snap[i].bo_ofs, > - snap- > >snap[i].len); > - ttm_bo_vunmap(&bo->ttm, &src); > - } > - xe_bo_unlock(bo); > + err = ttm_bo_access(&bo->ttm, snap- > >snap[i].bo_ofs, > + snap->snap[i].data, > snap->snap[i].len, 0); > + if (!(err < 0) && err != snap->snap[i].len) > + err = -EIO; > + else if (!(err < 0)) > + err = 0; > } else { > void __user *userptr = (void __user > *)(size_t)snap->snap[i].bo_ofs; >

3 weeks, 4 days

1
0
0 0

[PATCH] ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockopt

by Murad Masimov

If an AX25 device is bound to a socket by setting the SO_BINDTODEVICE socket option, a refcount leak will occur in ax25_release(). Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") added decrement of device refcounts in ax25_release(). In order for that to work correctly the refcounts must already be incremented when the device is bound to the socket. An AX25 device can be bound to a socket by either calling ax25_bind() or setting SO_BINDTODEVICE socket option. In both cases the refcounts should be incremented, but in fact it is done only in ax25_bind(). This bug leads to the following issue reported by Syzkaller: ================================================================ refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31 Modules linked in: CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31 Call Trace: <TASK> __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ... do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> ================================================================ Fix the implementation of ax25_setsockopt() by adding increment of refcounts for the new device bound, and decrement of refcounts for the old unbound device. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Cc: stable(a)vger.kernel.org Reported-by: syzbot+33841dc6aa3e1d86b78a(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=33841dc6aa3e1d86b78a Signed-off-by: Murad Masimov <m.masimov(a)mt-integration.ru> --- net/ax25/af_ax25.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index aa6c714892ec..9f3b8b682adb 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -685,6 +685,15 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname, break; } + if (ax25->ax25_dev) { + if (dev == ax25->ax25_dev->dev) { + rcu_read_unlock(); + break; + } + netdev_put(ax25->ax25_dev->dev, &ax25->dev_tracker); + ax25_dev_put(ax25->ax25_dev); + } + ax25->ax25_dev = ax25_dev_ax25dev(dev); if (!ax25->ax25_dev) { rcu_read_unlock(); @@ -692,6 +701,8 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname, break; } ax25_fillin_cb(ax25, ax25->ax25_dev); + netdev_hold(dev, &ax25->dev_tracker, GFP_ATOMIC); + ax25_dev_hold(ax25->ax25_dev); rcu_read_unlock(); break; -- 2.39.2

3 weeks, 4 days

1
0
0 0

[PATCH v2] arm64: dts: rockchip: Fix broken tsadc pinctrl names for rk3588

by Alexander Shiyan

The tsadc driver does not handle pinctrl "gpio" and "otpout". Let's use the correct pinctrl names "default" and "sleep". Additionally, Alexey Charkov's testing [1] has established that it is necessary for pinctrl state to reference the &tsadc_shut_org configuration rather than &tsadc_shut for the driver to function correctly. [1] https://lkml.org/lkml/2025/1/24/966 Fixes: 32641b8ab1a5 ("arm64: dts: rockchip: add rk3588 thermal sensor") Cc: stable(a)vger.kernel.org Reviewed-by: Dragan Simic <dsimic(a)manjaro.org> Signed-off-by: Alexander Shiyan <eagle.alexander923(a)gmail.com> --- arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi index 8cfa30837ce7..978de506d434 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi @@ -2668,9 +2668,9 @@ tsadc: tsadc@fec00000 { rockchip,hw-tshut-temp = <120000>; rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */ rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */ - pinctrl-0 = <&tsadc_gpio_func>; - pinctrl-1 = <&tsadc_shut>; - pinctrl-names = "gpio", "otpout"; + pinctrl-0 = <&tsadc_shut_org>; + pinctrl-1 = <&tsadc_gpio_func>; + pinctrl-names = "default", "sleep"; #thermal-sensor-cells = <1>; status = "disabled"; }; -- 2.39.1

3 weeks, 4 days

2
1
0 0

[PATCH] arm64: dts: rockchip: change eth phy mode to rgmii-id for orangepi r1 plus lts

by Tianling Shen

In general the delay should be added by the PHY instead of the MAC, and this improves network stability on some boards which seem to need different delay. Fixes: 387b3bbac5ea ("arm64: dts: rockchip: Add Xunlong OrangePi R1 Plus LTS") Cc: stable(a)vger.kernel.org # 6.6+ Signed-off-by: Tianling Shen <cnsztl(a)gmail.com> --- arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts | 3 +-- arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts | 1 + arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dtsi | 1 - 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts index 67c246ad8b8c..ec2ce894da1f 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts @@ -17,8 +17,7 @@ / { &gmac2io { phy-handle = <&yt8531c>; - tx_delay = <0x19>; - rx_delay = <0x05>; + phy-mode = "rgmii-id"; status = "okay"; mdio { diff --git a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts index 324a8e951f7e..846b931e16d2 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts @@ -15,6 +15,7 @@ / { &gmac2io { phy-handle = <&rtl8211e>; + phy-mode = "rgmii"; tx_delay = <0x24>; rx_delay = <0x18>; status = "okay"; diff --git a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dtsi b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dtsi index 4f193704e5dc..09508e324a28 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dtsi @@ -109,7 +109,6 @@ &gmac2io { assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>; assigned-clock-parents = <&gmac_clk>, <&gmac_clk>; clock_in_out = "input"; - phy-mode = "rgmii"; phy-supply = <&vcc_io>; pinctrl-0 = <&rgmiim1_pins>; pinctrl-names = "default"; -- 2.48.1

3 weeks, 4 days

4
10
0 0

[PATCH v2 3/3] misc: pci_endpoint_test: Fix irq_type to convey the correct type

by Kunihiko Hayashi

There are two variables that indicate the interrupt type to be used in the next test execution, "irq_type" as global and test->irq_type. The global is referenced from pci_endpoint_test_get_irq() to preserve the current type for ioctl(PCITEST_GET_IRQTYPE). The type set in this function isn't reflected in the global "irq_type", so ioctl(PCITEST_GET_IRQTYPE) returns the previous type. As a result, the wrong type will be displayed in "pcitest" as follows: # pcitest -i 0 SET IRQ TYPE TO LEGACY: OKAY # pcitest -I GET IRQ TYPE: MSI Fix this issue by propagating the current type to the global "irq_type". Cc: stable(a)vger.kernel.org Fixes: b2ba9225e031 ("misc: pci_endpoint_test: Avoid using module parameter to determine irqtype") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com> --- drivers/misc/pci_endpoint_test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c index a342587fc78a..33058630cd50 100644 --- a/drivers/misc/pci_endpoint_test.c +++ b/drivers/misc/pci_endpoint_test.c @@ -742,6 +742,7 @@ static bool pci_endpoint_test_set_irq(struct pci_endpoint_test *test, if (!pci_endpoint_test_request_irq(test)) goto err; + irq_type = test->irq_type; return true; err: -- 2.25.1

3 weeks, 4 days

3
8
0 0

[PATCH] mm,madvise,hugetlb: check for 0-length range after end address adjustment

by Ricardo Cañuelo Navarro

Add a sanity check to madvise_dontneed_free() to address a corner case in madvise where a race condition causes the current vma being processed to be backed by a different page size. During a madvise(MADV_DONTNEED) call on a memory region registered with a userfaultfd, there's a period of time where the process mm lock is temporarily released in order to send a UFFD_EVENT_REMOVE and let userspace handle the event. During this time, the vma covering the current address range may change due to an explicit mmap done concurrently by another thread. If, after that change, the memory region, which was originally backed by 4KB pages, is now backed by hugepages, the end address is rounded down to a hugepage boundary to avoid data loss (see "Fixes" below). This rounding may cause the end address to be truncated to the same address as the start. Make this corner case follow the same semantics as in other similar cases where the requested region has zero length (ie. return 0). This will make madvise_walk_vmas() continue to the next vma in the range (this time holding the process mm lock) which, due to the prev pointer becoming stale because of the vma change, will be the same hugepage-backed vma that was just checked before. The next time madvise_dontneed_free() runs for this vma, if the start address isn't aligned to a hugepage boundary, it'll return -EINVAL, which is also in line with the madvise api. From userspace perspective, madvise() will return EINVAL because the start address isn't aligned according to the new vma alignment requirements (hugepage), even though it was correctly page-aligned when the call was issued. Fixes: 8ebe0a5eaaeb ("mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs") Cc: stable(a)vger.kernel.org Signed-off-by: Ricardo Cañuelo Navarro <rcn(a)igalia.com> --- mm/madvise.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/madvise.c b/mm/madvise.c index 49f3a75046f6..c8e28d51978a 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -933,7 +933,9 @@ static long madvise_dontneed_free(struct vm_area_struct *vma, */ end = vma->vm_end; } - VM_WARN_ON(start >= end); + if (start == end) + return 0; + VM_WARN_ON(start > end); } if (behavior == MADV_DONTNEED || behavior == MADV_DONTNEED_LOCKED) -- 2.48.1

3 weeks, 4 days

2
3
0 0

[PATCH v3 6/6] ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> Commit 11c60f23ed13 ("integrity: Remove unused macro IMA_ACTION_RULE_FLAGS") removed the IMA_ACTION_RULE_FLAGS mask, due to it not being used after commit 0d73a55208e9 ("ima: re-introduce own integrity cache lock"). However, it seems that the latter commit mistakenly used the wrong mask when moving the code from ima_inode_post_setattr() to process_measurement(). There is no mention in the commit message about this change and it looks quite important, since changing from IMA_ACTIONS_FLAGS (later renamed to IMA_NONACTION_FLAGS) to IMA_ACTION_RULE_FLAGS was done by commit 42a4c603198f0 ("ima: fix ima_inode_post_setattr"). Restore the original change of resetting only the policy-specific flags and not the new file status, but with new mask 0xfb000000 since the policy-specific flags changed meanwhile. Also rename IMA_ACTION_RULE_FLAGS to IMA_NONACTION_RULE_FLAGS, to be consistent with IMA_NONACTION_FLAGS. Cc: stable(a)vger.kernel.org # v4.16.x Fixes: 11c60f23ed13 ("integrity: Remove unused macro IMA_ACTION_RULE_FLAGS") Reviewed-by: Mimi Zohar <zohar(a)linux.ibm.com> Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- security/integrity/ima/ima.h | 1 + security/integrity/ima/ima_main.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h index e1a3d1239bee..615900d4150d 100644 --- a/security/integrity/ima/ima.h +++ b/security/integrity/ima/ima.h @@ -141,6 +141,7 @@ struct ima_kexec_hdr { /* IMA iint policy rule cache flags */ #define IMA_NONACTION_FLAGS 0xff000000 +#define IMA_NONACTION_RULE_FLAGS 0xfb000000 #define IMA_DIGSIG_REQUIRED 0x01000000 #define IMA_PERMIT_DIRECTIO 0x02000000 #define IMA_NEW_FILE 0x04000000 diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 46adfd524dd8..7173dca20c23 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -275,7 +275,7 @@ static int process_measurement(struct file *file, const struct cred *cred, /* reset appraisal flags if ima_inode_post_setattr was called */ iint->flags &= ~(IMA_APPRAISE | IMA_APPRAISED | IMA_APPRAISE_SUBMASK | IMA_APPRAISED_SUBMASK | - IMA_NONACTION_FLAGS); + IMA_NONACTION_RULE_FLAGS); /* * Re-evaulate the file if either the xattr has changed or the -- 2.34.1

3 weeks, 4 days

2
1
0 0

Re: TCP Fast Retransmission Issue

by Ahmed, Shehab Sarar

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…

3 weeks, 4 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror