Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

229 participants
124043 discussions

[PATCH 2/2] drm: xlnx: zynqmp_kms: set preferred_depth to 16 bpp

by Mikko Rapeli

Xorg fails to start with defaults on AMD KV260, /var/log/Xorg.0.log: [ 23.491] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 23.491] (II) Module fbdev: vendor="X.Org Foundation" [ 23.491] compiled for 1.21.1.18, module version = 0.5.1 [ 23.491] Module class: X.Org Video Driver [ 23.491] ABI class: X.Org Video Driver, version 25.2 [ 23.491] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 23.491] (II) FBDEV: driver for framebuffer: fbdev [ 23.510] (II) modeset(0): using drv /dev/dri/card1 [ 23.511] (WW) Falling back to old probe method for fbdev [ 23.511] (II) Loading sub module "fbdevhw" [ 23.511] (II) LoadModule: "fbdevhw" [ 23.511] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 23.511] (II) Module fbdevhw: vendor="X.Org Foundation" [ 23.511] compiled for 1.21.1.18, module version = 0.0.2 [ 23.511] ABI class: X.Org Video Driver, version 25.2 [ 23.512] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 23.512] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 23.512] (==) modeset(0): RGB weight 888 [ 23.512] (==) modeset(0): Default visual is TrueColor ... [ 23.911] (II) Loading sub module "fb" [ 23.911] (II) LoadModule: "fb" [ 23.911] (II) Module "fb" already built-in [ 23.911] (II) UnloadModule: "fbdev" [ 23.911] (II) Unloading fbdev [ 23.912] (II) UnloadSubModule: "fbdevhw" [ 23.912] (II) Unloading fbdevhw [ 24.238] (==) modeset(0): Backing store enabled [ 24.238] (==) modeset(0): Silken mouse enabled [ 24.249] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. [ 24.250] (==) modeset(0): DPMS enabled [ 24.250] (II) modeset(0): [DRI2] Setup complete [ 24.250] (II) modeset(0): [DRI2] DRI driver: kms_swrast [ 24.250] (II) modeset(0): [DRI2] VDPAU driver: kms_swrast ... [ 24.770] (II) modeset(0): Disabling kernel dirty updates, not required. [ 24.770] (EE) modeset(0): failed to set mode: Invalid argument xorg tries to use 24 and 32 bpp which pass on the fb API but which don't actually work on AMD KV260 when Xorg starts. As a workaround Xorg config can set color depth to 16 using /etc/X11/xorg.conf snippet: Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 16 EndSection But this is cumbersome on images meant for multiple different arm64 devices and boards. So instead set 16 bpp as preferred depth in zynqmp_kms fb driver which is used by Xorg in the logic to find out a working depth. Now Xorg startup and bpp query using fb API works and HDMI display shows graphics. /var/log/Xorg.0.log shows: [ 23.219] (II) LoadModule: "fbdev" [ 23.219] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 23.219] (II) Module fbdev: vendor="X.Org Foundation" [ 23.219] compiled for 1.21.1.18, module version = 0.5.1 [ 23.219] Module class: X.Org Video Driver [ 23.219] ABI class: X.Org Video Driver, version 25.2 [ 23.219] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 23.219] (II) FBDEV: driver for framebuffer: fbdev [ 23.238] (II) modeset(0): using drv /dev/dri/card1 [ 23.238] (WW) Falling back to old probe method for fbdev [ 23.238] (II) Loading sub module "fbdevhw" [ 23.238] (II) LoadModule: "fbdevhw" [ 23.239] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 23.239] (II) Module fbdevhw: vendor="X.Org Foundation" [ 23.239] compiled for 1.21.1.18, module version = 0.0.2 [ 23.239] ABI class: X.Org Video Driver, version 25.2 [ 23.240] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 16/16 [ 23.240] (==) modeset(0): Depth 16, (==) framebuffer bpp 16 [ 23.240] (==) modeset(0): RGB weight 565 [ 23.240] (==) modeset(0): Default visual is TrueColor ... [ 24.015] (==) modeset(0): Backing store enabled [ 24.015] (==) modeset(0): Silken mouse enabled [ 24.027] (II) modeset(0): Initializing kms color map for depth 16, 6 bpc. [ 24.028] (==) modeset(0): DPMS enabled [ 24.028] (II) modeset(0): [DRI2] Setup complete [ 24.028] (II) modeset(0): [DRI2] DRI driver: kms_swrast [ 24.028] (II) modeset(0): [DRI2] VDPAU driver: kms_swrast Cc: Bill Mills <bill.mills(a)linaro.org> Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Cc: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Mikko Rapeli <mikko.rapeli(a)linaro.org> --- drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c index ccc35cacd10cb..a42192c827af0 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c @@ -506,6 +506,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub) drm->mode_config.min_height = 0; drm->mode_config.max_width = ZYNQMP_DISP_MAX_WIDTH; drm->mode_config.max_height = ZYNQMP_DISP_MAX_HEIGHT; + drm->mode_config.preferred_depth = 16; ret = drm_vblank_init(drm, 1); if (ret) -- 2.34.1

1 day, 13 hours

[PATCH 1/2] drm: xlnx: zynqmp_kms: Init fbdev with 16 bit color

by Mikko Rapeli

From: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com> Use RG16 buffer format for fbdev emulation. Fbdev backend is being used by Mali 400 userspace driver which expects 16 bit RGB pixel color format. This change should not affect console or other fbdev applications as we still have plenty of colors left. Cc: Bill Mills <bill.mills(a)linaro.org> Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Cc: stable(a)vger.kernel.org Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com> Signed-off-by: Mikko Rapeli <mikko.rapeli(a)linaro.org> --- drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c index 2bee0a2275ede..ccc35cacd10cb 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c @@ -525,7 +525,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub) goto err_poll_fini; /* Initialize fbdev generic emulation. */ - drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB888); + drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB565); return 0; -- 2.34.1

1 day, 13 hours

[PATCH 3/5] ceph: Free page array when ceph_submit_write fails

by Sam Edwards

If `locked_pages` is zero, the page array must not be allocated: ceph_process_folio_batch() uses `locked_pages` to decide when to allocate `pages`, and redundant allocations trigger ceph_allocate_page_array()'s BUG_ON(), resulting in a worker oops (and writeback stall) or even a kernel panic. Consequently, the main loop in ceph_writepages_start() assumes that the lifetime of `pages` is confined to a single iteration. The ceph_submit_write() function claims ownership of the page array on success. But failures only redirty/unlock the pages and fail to free the array, making the failure case in ceph_submit_write() fatal. Free the page array in ceph_submit_write()'s error-handling 'if' block so that the caller's invariant (that the array does not outlive the iteration) is maintained unconditionally, allowing failures in ceph_submit_write() to be recoverable as originally intended. Fixes: 1551ec61dc55 ("ceph: introduce ceph_submit_write() method") Cc: stable(a)vger.kernel.org Signed-off-by: Sam Edwards <CFSworks(a)gmail.com> --- fs/ceph/addr.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 2b722916fb9b..91cc43950162 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1466,6 +1466,13 @@ int ceph_submit_write(struct address_space *mapping, unlock_page(page); } + if (ceph_wbc->from_pool) { + mempool_free(ceph_wbc->pages, ceph_wb_pagevec_pool); + ceph_wbc->from_pool = false; + } else + kfree(ceph_wbc->pages); + ceph_wbc->pages = NULL; + ceph_osdc_put_request(req); return -EIO; } -- 2.51.2

1 day, 14 hours

[PATCH] iio: bmi270_i2c: Add MODULE_DEVICE_TABLE for BMI260/270

by Derek J. Clark

Currently BMI260 & BMI270 devices do not automatically load this driver. To fix this, add missing MODULE_DEVICE_TABLE for the i2c, acpi, and of device tables so the driver will load when the hardware is detected. Tested on my OneXPlayer F1 Pro. Signed-off-by: Derek J. Clark <derekjohn.clark(a)gmail.com> --- drivers/iio/imu/bmi270/bmi270_i2c.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/imu/bmi270/bmi270_i2c.c b/drivers/iio/imu/bmi270/bmi270_i2c.c index b909a421ad01..b92da4e0776f 100644 --- a/drivers/iio/imu/bmi270/bmi270_i2c.c +++ b/drivers/iio/imu/bmi270/bmi270_i2c.c @@ -37,6 +37,7 @@ static const struct i2c_device_id bmi270_i2c_id[] = { { "bmi270", (kernel_ulong_t)&bmi270_chip_info }, { } }; +MODULE_DEVICE_TABLE(i2c, bmi270_i2c_id); static const struct acpi_device_id bmi270_acpi_match[] = { /* GPD Win Mini, Aya Neo AIR Pro, OXP Mini Pro, etc. */ @@ -45,12 +46,14 @@ static const struct acpi_device_id bmi270_acpi_match[] = { { "BMI0260", (kernel_ulong_t)&bmi260_chip_info }, { } }; +MODULE_DEVICE_TABLE(acpi, bmi270_acpi_match); static const struct of_device_id bmi270_of_match[] = { { .compatible = "bosch,bmi260", .data = &bmi260_chip_info }, { .compatible = "bosch,bmi270", .data = &bmi270_chip_info }, { } }; +MODULE_DEVICE_TABLE(of, bmi270_of_match); static struct i2c_driver bmi270_i2c_driver = { .driver = { -- 2.51.2

1 day, 15 hours

[PATCH] media: v4l2-flash: Enter LED off state after file handle closed

by cy_huang＠richtek.com

From: ChiYuan Huang <cy_huang(a)richtek.com> To make sure LED enter off state after file handle is closed, initiatively configure LED_MODE to NONE. This can guarantee whatever the previous state is torch or strobe mode, the final state will be off. Cc: stable(a)vger.kernel.org Fixes : 42bd6f59ae90 ("media: Add registration helpers for V4L2 flash sub-devices") Reported-by: Roger Wang <roger-hy.wang(a)mediatek.com> Signed-off-by: ChiYuan Huang <cy_huang(a)richtek.com> --- Hi, We encounter an issue. When the upper layer camera process is crashed, if the new process did not reinit the LED, it will keeps the previous state whatever it's in torch or strobe mode OS will handle the resource management. So when the process is crashed or terminated, the 'close' API will be called to release resources. That's why we add the initiative action to trigger LED off in file handle close is called. --- drivers/media/v4l2-core/v4l2-flash-led-class.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c b/drivers/media/v4l2-core/v4l2-flash-led-class.c index 355595a0fefa..347b37f3ef69 100644 --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c @@ -623,6 +623,12 @@ static int v4l2_flash_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) return 0; if (led_cdev) { + /* If file handle is released, make sure LED enter off state */ + ret = v4l2_ctrl_s_ctrl(v4l2_flash->ctrls[LED_MODE], + V4L2_FLASH_LED_MODE_NONE); + if (ret) + return ret; + mutex_lock(&led_cdev->led_access); if (v4l2_flash->ctrls[STROBE_SOURCE]) -- 2.34.1

1 day, 15 hours

Action Needed: Mailbox Quota Exceeded – Manage Emails Now

by Urgent!!

1 day, 15 hours

FAILED: patch "[PATCH] vfio/pci: Disable qword access to the PCI ROM bar" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x dc85a46928c41423ad89869baf05a589e2975575 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2026010500-herself-pentagon-8cde@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc85a46928c41423ad89869baf05a589e2975575 Mon Sep 17 00:00:00 2001 From: Kevin Tian <kevin.tian(a)intel.com> Date: Thu, 18 Dec 2025 08:16:49 +0000 Subject: [PATCH] vfio/pci: Disable qword access to the PCI ROM bar Commit 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci") enables qword access to the PCI bar resources. However certain devices (e.g. Intel X710) are observed with problem upon qword accesses to the rom bar, e.g. triggering PCI aer errors. This is triggered by Qemu which caches the rom content by simply does a pread() of the remaining size until it gets the full contents. The other bars would only perform operations at the same access width as their guest drivers. Instead of trying to identify all broken devices, universally disable qword access to the rom bar i.e. going back to the old way which worked reliably for years. Reported-by: Farrah Chen <farrah.chen(a)intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220740 Fixes: 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci") Cc: stable(a)vger.kernel.org Signed-off-by: Kevin Tian <kevin.tian(a)intel.com> Tested-by: Farrah Chen <farrah.chen(a)intel.com> Link: https://lore.kernel.org/r/20251218081650.555015-2-kevin.tian@intel.com Signed-off-by: Alex Williamson <alex(a)shazbot.org> diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c index 84d142a47ec6..b45a24d00387 100644 --- a/drivers/vfio/pci/nvgrace-gpu/main.c +++ b/drivers/vfio/pci/nvgrace-gpu/main.c @@ -561,7 +561,7 @@ nvgrace_gpu_map_and_read(struct nvgrace_gpu_pci_core_device *nvdev, ret = vfio_pci_core_do_io_rw(&nvdev->core_device, false, nvdev->resmem.ioaddr, buf, offset, mem_count, - 0, 0, false); + 0, 0, false, VFIO_PCI_IO_WIDTH_8); } return ret; @@ -693,7 +693,7 @@ nvgrace_gpu_map_and_write(struct nvgrace_gpu_pci_core_device *nvdev, ret = vfio_pci_core_do_io_rw(&nvdev->core_device, false, nvdev->resmem.ioaddr, (char __user *)buf, pos, mem_count, - 0, 0, true); + 0, 0, true, VFIO_PCI_IO_WIDTH_8); } return ret; diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c index 6192788c8ba3..25380b7dfe18 100644 --- a/drivers/vfio/pci/vfio_pci_rdwr.c +++ b/drivers/vfio/pci/vfio_pci_rdwr.c @@ -135,7 +135,8 @@ VFIO_IORDWR(64) ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, void __iomem *io, char __user *buf, loff_t off, size_t count, size_t x_start, - size_t x_end, bool iswrite) + size_t x_end, bool iswrite, + enum vfio_pci_io_width max_width) { ssize_t done = 0; int ret; @@ -150,20 +151,19 @@ ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, else fillable = 0; - if (fillable >= 8 && !(off % 8)) { + if (fillable >= 8 && !(off % 8) && max_width >= 8) { ret = vfio_pci_iordwr64(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) return ret; - } else - if (fillable >= 4 && !(off % 4)) { + } else if (fillable >= 4 && !(off % 4) && max_width >= 4) { ret = vfio_pci_iordwr32(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) return ret; - } else if (fillable >= 2 && !(off % 2)) { + } else if (fillable >= 2 && !(off % 2) && max_width >= 2) { ret = vfio_pci_iordwr16(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) @@ -234,6 +234,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, void __iomem *io; struct resource *res = &vdev->pdev->resource[bar]; ssize_t done; + enum vfio_pci_io_width max_width = VFIO_PCI_IO_WIDTH_8; if (pci_resource_start(pdev, bar)) end = pci_resource_len(pdev, bar); @@ -262,6 +263,16 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, if (!io) return -ENOMEM; x_end = end; + + /* + * Certain devices (e.g. Intel X710) don't support qword + * access to the ROM bar. Otherwise PCI AER errors might be + * triggered. + * + * Disable qword access to the ROM bar universally, which + * worked reliably for years before qword access is enabled. + */ + max_width = VFIO_PCI_IO_WIDTH_4; } else { int ret = vfio_pci_core_setup_barmap(vdev, bar); if (ret) { @@ -278,7 +289,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, } done = vfio_pci_core_do_io_rw(vdev, res->flags & IORESOURCE_MEM, io, buf, pos, - count, x_start, x_end, iswrite); + count, x_start, x_end, iswrite, max_width); if (done >= 0) *ppos += done; @@ -352,7 +363,7 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_core_device *vdev, char __user *buf, * to the memory enable bit in the command register. */ done = vfio_pci_core_do_io_rw(vdev, false, iomem, buf, off, count, - 0, 0, iswrite); + 0, 0, iswrite, VFIO_PCI_IO_WIDTH_8); vga_put(vdev->pdev, rsrc); diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h index 706877f998ff..1ac86896875c 100644 --- a/include/linux/vfio_pci_core.h +++ b/include/linux/vfio_pci_core.h @@ -145,6 +145,13 @@ struct vfio_pci_core_device { struct list_head dmabufs; }; +enum vfio_pci_io_width { + VFIO_PCI_IO_WIDTH_1 = 1, + VFIO_PCI_IO_WIDTH_2 = 2, + VFIO_PCI_IO_WIDTH_4 = 4, + VFIO_PCI_IO_WIDTH_8 = 8, +}; + /* Will be exported for vfio pci drivers usage */ int vfio_pci_core_register_dev_region(struct vfio_pci_core_device *vdev, unsigned int type, unsigned int subtype, @@ -188,7 +195,8 @@ pci_ers_result_t vfio_pci_core_aer_err_detected(struct pci_dev *pdev, ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, void __iomem *io, char __user *buf, loff_t off, size_t count, size_t x_start, - size_t x_end, bool iswrite); + size_t x_end, bool iswrite, + enum vfio_pci_io_width max_width); bool __vfio_pci_memory_enabled(struct vfio_pci_core_device *vdev); bool vfio_pci_core_range_intersect_range(loff_t buf_start, size_t buf_cnt, loff_t reg_start, size_t reg_cnt,

1 day, 15 hours

[to-be-updated] maple_tree-add-dead-node-check-in-mas_dup_alloc.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: maple_tree: add dead node check in mas_dup_alloc() has been removed from the -mm tree. Its filename was maple_tree-add-dead-node-check-in-mas_dup_alloc.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Boudewijn van der Heide <boudewijn(a)delta-utec.com> Subject: maple_tree: add dead node check in mas_dup_alloc() Date: Sat, 3 Jan 2026 17:57:58 +0100 __mt_dup() is exported and can be called without internal locking, relying on the caller to provide appropriate synchronization. If a caller fails to hold proper locks, the source tree may be modified concurrently, potentially resulting in dead nodes during traversal. The call stack is: __mt_dup() �� mas_dup_build() �� mas_dup_alloc() [accesses node->slot[]] mas_dup_alloc() may access node slots without first verifying that the node is still alive. If a dead node is encountered, its memory layout may have been switched to the RCU union member, making slot array access undefined behavior as we would be reading from the rcu_head structure instead. If __mt_dup() is invoked without the required external locking and the source tree is concurrently modified, a node can transition to the dead RCU layout while mas_dup_alloc() is still traversing it. In that case the code may interpret the rcu_head contents as slot pointers. Practically, this could lead to invalid pointer dereferences (kernel oops) or corruption of the duplicated tree. Depending on how that duplicated tree is later used (e.g. in mm/VMA paths), the effects could be userspace-visible, such as fork() failures, process crashes, or broader system instability. My understanding is that current in-tree users hold the appropriate locks and should not hit this, as triggering it requires violating the __mt_dup() synchronization contract. The risk primarily comes from the fact that __mt_dup() is exported (EXPORT_SYMBOL), making it reachable by out-of-tree modules or future callers which may not follow the locking rules. Add an explicit dead node check to detect concurrent modification during duplication. When a dead node is detected, return -EBUSY to indicate that the tree is undergoing concurrent modification. Link: https://lkml.kernel.org/r/20260103165758.74094-1-boudewijn@delta-utec.com Fixes: fd32e4e9b764 ("maple_tree: introduce interfaces __mt_dup() and mtree_dup()") Signed-off-by: Boudewijn van der Heide <boudewijn(a)delta-utec.com> Cc: Alice Ryhl <aliceryhl(a)google.com> Cc: Andrew Ballance <andrewjballance(a)gmail.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/lib/maple_tree.c~maple_tree-add-dead-node-check-in-mas_dup_alloc +++ a/lib/maple_tree.c @@ -6251,6 +6251,11 @@ static inline void mas_dup_alloc(struct /* Allocate memory for child nodes. */ type = mte_node_type(mas->node); new_slots = ma_slots(new_node, type); + if (unlikely(ma_dead_node(node))) { + mas_set_err(mas, -EBUSY); + return; + } + count = mas->node_request = mas_data_end(mas) + 1; mas_alloc_nodes(mas, gfp); if (unlikely(mas_is_err(mas))) _ Patches currently in -mm which might be from boudewijn(a)delta-utec.com are

1 day, 17 hours

FAILED: patch "[PATCH] LoongArch: Refactor register restoration in" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

1 day, 17 hours

[PATCH 6.6] LoongArch: Refactor register restoration in ftrace_common_return

by Huacai Chen

From: Chenghao Duan <duanchenghao(a)kylinos.cn> commit 45cb47c628dfbd1994c619f3eac271a780602826 upstream. Refactor the register restoration sequence in the ftrace_common_return function to clearly distinguish between the logic of normal returns and direct call returns in function tracing scenarios. The logic is as follows: 1. In the case of a normal return, the execution flow returns to the traced function, and ftrace must ensure that the register data is consistent with the state when the function was entered. ra = parent return address; t0 = traced function return address. 2. In the case of a direct call return, the execution flow jumps to the custom trampoline function, and ftrace must ensure that the register data is consistent with the state when ftrace was entered. ra = traced function return address; t0 = parent return address. Cc: stable(a)vger.kernel.org Fixes: 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support") Signed-off-by: Chenghao Duan <duanchenghao(a)kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/kernel/mcount_dyn.S | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/loongarch/kernel/mcount_dyn.S b/arch/loongarch/kernel/mcount_dyn.S index 482aa553aa2d..5fb3a6e5e5c6 100644 --- a/arch/loongarch/kernel/mcount_dyn.S +++ b/arch/loongarch/kernel/mcount_dyn.S @@ -93,7 +93,6 @@ SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) * at the callsite, so there is no need to restore the T series regs. */ ftrace_common_return: - PTR_L ra, sp, PT_R1 PTR_L a0, sp, PT_R4 PTR_L a1, sp, PT_R5 PTR_L a2, sp, PT_R6 @@ -103,12 +102,17 @@ ftrace_common_return: PTR_L a6, sp, PT_R10 PTR_L a7, sp, PT_R11 PTR_L fp, sp, PT_R22 - PTR_L t0, sp, PT_ERA PTR_L t1, sp, PT_R13 - PTR_ADDI sp, sp, PT_SIZE bnez t1, .Ldirect + + PTR_L ra, sp, PT_R1 + PTR_L t0, sp, PT_ERA + PTR_ADDI sp, sp, PT_SIZE jr t0 .Ldirect: + PTR_L t0, sp, PT_R1 + PTR_L ra, sp, PT_ERA + PTR_ADDI sp, sp, PT_SIZE jr t1 SYM_CODE_END(ftrace_common) @@ -155,6 +159,8 @@ SYM_CODE_END(return_to_handler) #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS SYM_CODE_START(ftrace_stub_direct_tramp) - jr t0 + move t1, ra + move ra, t0 + jr t1 SYM_CODE_END(ftrace_stub_direct_tramp) #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */ -- 2.47.3

1 day, 17 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror