May 2023 - Linux-stable-mirror

by Jan Kara

When a directory is moved to a different directory, some filesystems (udf, ext4, ocfs2, f2fs, and likely gfs2, reiserfs, and others) need to update their pointer to the parent and this must not race with other operations on the directory. Lock the directories when they are moved. Although not all filesystems need this locking, we perform it in vfs_rename() because getting the lock ordering right is really difficult and we don't want to expose these locking details to filesystems. CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- .../filesystems/directory-locking.rst | 26 ++++++++++--------- fs/namei.c | 22 ++++++++++------ 2 files changed, 28 insertions(+), 20 deletions(-) diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst index 504ba940c36c..dccd61c7c5c3 100644 --- a/Documentation/filesystems/directory-locking.rst +++ b/Documentation/filesystems/directory-locking.rst @@ -22,12 +22,11 @@ exclusive. 3) object removal. Locking rules: caller locks parent, finds victim, locks victim and calls the method. Locks are exclusive. -4) rename() that is _not_ cross-directory. Locking rules: caller locks -the parent and finds source and target. In case of exchange (with -RENAME_EXCHANGE in flags argument) lock both. In any case, -if the target already exists, lock it. If the source is a non-directory, -lock it. If we need to lock both, lock them in inode pointer order. -Then call the method. All locks are exclusive. +4) rename() that is _not_ cross-directory. Locking rules: caller locks the +parent and finds source and target. We lock both (provided they exist). If we +need to lock two inodes of different type (dir vs non-dir), we lock directory +first. If we need to lock two inodes of the same type, lock them in inode +pointer order. Then call the method. All locks are exclusive. NB: we might get away with locking the source (and target in exchange case) shared. @@ -44,15 +43,17 @@ All locks are exclusive. rules: * lock the filesystem - * lock parents in "ancestors first" order. + * lock parents in "ancestors first" order. If one is not ancestor of + the other, lock them in inode pointer order. * find source and target. * if old parent is equal to or is a descendent of target fail with -ENOTEMPTY * if new parent is equal to or is a descendent of source fail with -ELOOP - * If it's an exchange, lock both the source and the target. - * If the target exists, lock it. If the source is a non-directory, - lock it. If we need to lock both, do so in inode pointer order. + * Lock both the source and the target provided they exist. If we + need to lock two inodes of different type (dir vs non-dir), we lock + the directory first. If we need to lock two inodes of the same type, + lock them in inode pointer order. * call the method. All ->i_rwsem are taken exclusive. Again, we might get away with locking @@ -66,8 +67,9 @@ If no directory is its own ancestor, the scheme above is deadlock-free. Proof: - First of all, at any moment we have a partial ordering of the - objects - A < B iff A is an ancestor of B. + First of all, at any moment we have a linear ordering of the + objects - A < B iff (A is an ancestor of B) or (B is not an ancestor + of A and ptr(A) < ptr(B)). That ordering can change. However, the following is true: diff --git a/fs/namei.c b/fs/namei.c index 148570aabe74..6a5e26a529e1 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -4731,7 +4731,7 @@ SYSCALL_DEFINE2(link, const char __user *, oldname, const char __user *, newname * sb->s_vfs_rename_mutex. We might be more accurate, but that's another * story. * c) we have to lock _four_ objects - parents and victim (if it exists), - * and source (if it is not a directory). + * and source. * And that - after we got ->i_mutex on parents (until then we don't know * whether the target exists). Solution: try to be smart with locking * order for inodes. We rely on the fact that tree topology may change @@ -4815,10 +4815,16 @@ int vfs_rename(struct renamedata *rd) take_dentry_name_snapshot(&old_name, old_dentry); dget(new_dentry); - if (!is_dir || (flags & RENAME_EXCHANGE)) - lock_two_nondirectories(source, target); - else if (target) - inode_lock(target); + /* + * Lock all moved children. Moved directories may need to change parent + * pointer so they need the lock to prevent against concurrent + * directory changes moving parent pointer. For regular files we've + * historically always done this. The lockdep locking subclasses are + * somewhat arbitrary but RENAME_EXCHANGE in particular can swap + * regular files and directories so it's difficult to tell which + * subclasses to use. + */ + lock_two_inodes(source, target, I_MUTEX_NORMAL, I_MUTEX_NONDIR2); error = -EPERM; if (IS_SWAPFILE(source) || (target && IS_SWAPFILE(target))) @@ -4866,9 +4872,9 @@ int vfs_rename(struct renamedata *rd) d_exchange(old_dentry, new_dentry); } out: - if (!is_dir || (flags & RENAME_EXCHANGE)) - unlock_two_nondirectories(source, target); - else if (target) + if (source) + inode_unlock(source); + if (target) inode_unlock(target); dput(new_dentry); if (!error) { -- 2.35.3

2 years, 6 months

1
0
0 0

[PATCH 3/6] Revert "f2fs: fix potential corruption when moving a directory"

by Jan Kara

This reverts commit d94772154e524b329a168678836745d2773a6e02. The locking is going to be provided by VFS. CC: Jaegeuk Kim <jaegeuk(a)kernel.org> CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/f2fs/namei.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 77a71276ecb1..ad597b417fea 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -995,20 +995,12 @@ static int f2fs_rename(struct mnt_idmap *idmap, struct inode *old_dir, goto out; } - /* - * Copied from ext4_rename: we need to protect against old.inode - * directory getting converted from inline directory format into - * a normal one. - */ - if (S_ISDIR(old_inode->i_mode)) - inode_lock_nested(old_inode, I_MUTEX_NONDIR2); - err = -ENOENT; old_entry = f2fs_find_entry(old_dir, &old_dentry->d_name, &old_page); if (!old_entry) { if (IS_ERR(old_page)) err = PTR_ERR(old_page); - goto out_unlock_old; + goto out; } if (S_ISDIR(old_inode->i_mode)) { @@ -1116,9 +1108,6 @@ static int f2fs_rename(struct mnt_idmap *idmap, struct inode *old_dir, f2fs_unlock_op(sbi); - if (S_ISDIR(old_inode->i_mode)) - inode_unlock(old_inode); - if (IS_DIRSYNC(old_dir) || IS_DIRSYNC(new_dir)) f2fs_sync_fs(sbi->sb, 1); @@ -1133,9 +1122,6 @@ static int f2fs_rename(struct mnt_idmap *idmap, struct inode *old_dir, f2fs_put_page(old_dir_page, 0); out_old: f2fs_put_page(old_page, 0); -out_unlock_old: - if (S_ISDIR(old_inode->i_mode)) - inode_unlock(old_inode); out: iput(whiteout); return err; -- 2.35.3

2 years, 6 months

1
0
0 0

[PATCH 2/6] Revert "udf: Protect rename against modification of moved directory"

by Jan Kara

This reverts commit f950fd0529130a617b3da526da9fb6a896ce87c2. The locking is going to be provided by vfs_rename() in the following patches. CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/udf/namei.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/fs/udf/namei.c b/fs/udf/namei.c index fd20423d3ed2..fd29a66e7241 100644 --- a/fs/udf/namei.c +++ b/fs/udf/namei.c @@ -793,11 +793,6 @@ static int udf_rename(struct mnt_idmap *idmap, struct inode *old_dir, if (!empty_dir(new_inode)) goto out_oiter; } - /* - * We need to protect against old_inode getting converted from - * ICB to normal directory. - */ - inode_lock_nested(old_inode, I_MUTEX_NONDIR2); retval = udf_fiiter_find_entry(old_inode, &dotdot_name, &diriter); if (retval == -ENOENT) { @@ -806,10 +801,8 @@ static int udf_rename(struct mnt_idmap *idmap, struct inode *old_dir, old_inode->i_ino); retval = -EFSCORRUPTED; } - if (retval) { - inode_unlock(old_inode); + if (retval) goto out_oiter; - } has_diriter = true; tloc = lelb_to_cpu(diriter.fi.icb.extLocation); if (udf_get_lb_pblock(old_inode->i_sb, &tloc, 0) != @@ -889,7 +882,6 @@ static int udf_rename(struct mnt_idmap *idmap, struct inode *old_dir, udf_dir_entry_len(&diriter.fi)); udf_fiiter_write_fi(&diriter, NULL); udf_fiiter_release(&diriter); - inode_unlock(old_inode); inode_dec_link_count(old_dir); if (new_inode) @@ -901,10 +893,8 @@ static int udf_rename(struct mnt_idmap *idmap, struct inode *old_dir, } return 0; out_oiter: - if (has_diriter) { + if (has_diriter) udf_fiiter_release(&diriter); - inode_unlock(old_inode); - } udf_fiiter_release(&oiter); return retval; -- 2.35.3

2 years, 6 months

1
0
0 0

[PATCH 1/6] ext4: Remove ext4 locking of moved directory

by Jan Kara

Remove locking of moved directory in ext4_rename2(). We will take care of it in VFS instead. This effectively reverts commit 0813299c586b ("ext4: Fix possible corruption when moving a directory") and followup fixes. CC: Ted Tso <tytso(a)mit.edu> CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/namei.c | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 45b579805c95..0caf6c730ce3 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -3834,19 +3834,10 @@ static int ext4_rename(struct mnt_idmap *idmap, struct inode *old_dir, return retval; } - /* - * We need to protect against old.inode directory getting converted - * from inline directory format into a normal one. - */ - if (S_ISDIR(old.inode->i_mode)) - inode_lock_nested(old.inode, I_MUTEX_NONDIR2); - old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, &old.inlined); - if (IS_ERR(old.bh)) { - retval = PTR_ERR(old.bh); - goto unlock_moved_dir; - } + if (IS_ERR(old.bh)) + return PTR_ERR(old.bh); /* * Check for inode number is _not_ due to possible IO errors. @@ -4043,10 +4034,6 @@ static int ext4_rename(struct mnt_idmap *idmap, struct inode *old_dir, brelse(old.bh); brelse(new.bh); -unlock_moved_dir: - if (S_ISDIR(old.inode->i_mode)) - inode_unlock(old.inode); - return retval; } -- 2.35.3

2 years, 6 months

1
0
0 0

[PATCH] perf/x86/uncore: Correct the number of CHAs on SPR

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> The number of CHAs from the discovery table on some SPR variants is incorrect, because of a firmware issue. An accurate number can be read from the MSR UNC_CBO_CONFIG. Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support") Reported-by: Stephane Eranian <eranian(a)google.com> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/uncore_snbep.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index 7d1199554fe3..54abd93828bf 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -6138,6 +6138,7 @@ static struct intel_uncore_type spr_uncore_mdf = { }; #define UNCORE_SPR_NUM_UNCORE_TYPES 12 +#define UNCORE_SPR_CHA 0 #define UNCORE_SPR_IIO 1 #define UNCORE_SPR_IMC 6 #define UNCORE_SPR_UPI 8 @@ -6448,12 +6449,22 @@ static int uncore_type_max_boxes(struct intel_uncore_type **types, return max + 1; } +#define SPR_MSR_UNC_CBO_CONFIG 0x2FFE + void spr_uncore_cpu_init(void) { + struct intel_uncore_type *type; + u64 num_cbo; + uncore_msr_uncores = uncore_get_uncores(UNCORE_ACCESS_MSR, UNCORE_SPR_MSR_EXTRA_UNCORES, spr_msr_uncores); + type = uncore_find_type_by_id(uncore_msr_uncores, UNCORE_SPR_CHA); + if (type) { + rdmsrl(SPR_MSR_UNC_CBO_CONFIG, num_cbo); + type->num_boxes = num_cbo; + } spr_uncore_iio_free_running.num_boxes = uncore_type_max_boxes(uncore_msr_uncores, UNCORE_SPR_IIO); } -- 2.35.1

2 years, 6 months

5
4
0 0

[PATCH v3 5/6] PCI: hv: Add a per-bus mutex state_lock

by Dexuan Cui

In the case of fast device addition/removal, it's possible that hv_eject_device_work() can start to run before create_root_hv_pci_bus() starts to run; as a result, the pci_get_domain_bus_and_slot() in hv_eject_device_work() can return a 'pdev' of NULL, and hv_eject_device_work() can remove the 'hpdev', and immediately send a message PCI_EJECTION_COMPLETE to the host, and the host immediately unassigns the PCI device from the guest; meanwhile, create_root_hv_pci_bus() and the PCI device driver can be probing the dead PCI device and reporting timeout errors. Fix the issue by adding a per-bus mutex 'state_lock' and grabbing the mutex before powering on the PCI bus in hv_pci_enter_d0(): when hv_eject_device_work() starts to run, it's able to find the 'pdev' and call pci_stop_and_remove_bus_device(pdev): if the PCI device driver has loaded, the PCI device driver's probe() function is already called in create_root_hv_pci_bus() -> pci_bus_add_devices(), and now hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to call the PCI device driver's remove() function and remove the device reliably; if the PCI device driver hasn't loaded yet, the function call hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to remove the PCI device reliably and the PCI device driver's probe() function won't be called; if the PCI device driver's probe() is already running (e.g., systemd-udev is loading the PCI device driver), it must be holding the per-device lock, and after the probe() finishes and releases the lock, hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to proceed to remove the device reliably. Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Reviewed-by: Michael Kelley <mikelley(a)microsoft.com> Cc: stable(a)vger.kernel.org --- v2: Removed the "debug code". Fixed the "goto out" in hv_pci_resume() [Michael Kelley] Added Cc:stable v3: Added Michael's Reviewed-by. drivers/pci/controller/pci-hyperv.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 48feab095a144..3ae2f99dea8c2 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -489,7 +489,10 @@ struct hv_pcibus_device { struct fwnode_handle *fwnode; /* Protocol version negotiated with the host */ enum pci_protocol_version_t protocol_version; + + struct mutex state_lock; enum hv_pcibus_state state; + struct hv_device *hdev; resource_size_t low_mmio_space; resource_size_t high_mmio_space; @@ -2512,6 +2515,8 @@ static void pci_devices_present_work(struct work_struct *work) if (!dr) return; + mutex_lock(&hbus->state_lock); + /* First, mark all existing children as reported missing. */ spin_lock_irqsave(&hbus->device_list_lock, flags); list_for_each_entry(hpdev, &hbus->children, list_entry) { @@ -2593,6 +2598,8 @@ static void pci_devices_present_work(struct work_struct *work) break; } + mutex_unlock(&hbus->state_lock); + kfree(dr); } @@ -2741,6 +2748,8 @@ static void hv_eject_device_work(struct work_struct *work) hpdev = container_of(work, struct hv_pci_dev, wrk); hbus = hpdev->hbus; + mutex_lock(&hbus->state_lock); + /* * Ejection can come before or after the PCI bus has been set up, so * attempt to find it and tear down the bus state, if it exists. This @@ -2777,6 +2786,8 @@ static void hv_eject_device_work(struct work_struct *work) put_pcichild(hpdev); put_pcichild(hpdev); /* hpdev has been freed. Do not use it any more. */ + + mutex_unlock(&hbus->state_lock); } /** @@ -3562,6 +3573,7 @@ static int hv_pci_probe(struct hv_device *hdev, return -ENOMEM; hbus->bridge = bridge; + mutex_init(&hbus->state_lock); hbus->state = hv_pcibus_init; hbus->wslot_res_allocated = -1; @@ -3670,9 +3682,11 @@ static int hv_pci_probe(struct hv_device *hdev, if (ret) goto free_irq_domain; + mutex_lock(&hbus->state_lock); + ret = hv_pci_enter_d0(hdev); if (ret) - goto free_irq_domain; + goto release_state_lock; ret = hv_pci_allocate_bridge_windows(hbus); if (ret) @@ -3690,12 +3704,15 @@ static int hv_pci_probe(struct hv_device *hdev, if (ret) goto free_windows; + mutex_unlock(&hbus->state_lock); return 0; free_windows: hv_pci_free_bridge_windows(hbus); exit_d0: (void) hv_pci_bus_exit(hdev, true); +release_state_lock: + mutex_unlock(&hbus->state_lock); free_irq_domain: irq_domain_remove(hbus->irq_domain); free_fwnode: @@ -3945,20 +3962,26 @@ static int hv_pci_resume(struct hv_device *hdev) if (ret) goto out; + mutex_lock(&hbus->state_lock); + ret = hv_pci_enter_d0(hdev); if (ret) - goto out; + goto release_state_lock; ret = hv_send_resources_allocated(hdev); if (ret) - goto out; + goto release_state_lock; prepopulate_bars(hbus); hv_pci_restore_msi_state(hbus); hbus->state = hv_pcibus_installed; + mutex_unlock(&hbus->state_lock); return 0; + +release_state_lock: + mutex_unlock(&hbus->state_lock); out: vmbus_close(hdev->channel); return ret; -- 2.25.1

2 years, 6 months

2
1
0 0

[PATCH] ARM: dts: qcom-apq8060: Fix regulator node names

by Linus Walleij

commit 04715461abf7 altered the node names in a DTSI file used by qcom-apq8060-dragonboard.dts breaking the board. Align the node names in the DTS file and the board boots again. Cc: stable(a)vger.kernel.org Fixes: 04715461abf7 ("ARM: dts: qcom-msm8660: align RPM regulators node name with bindings") Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts index 8e4b61e4d4b1..e8fe321f3d89 100644 --- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts +++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts @@ -451,7 +451,7 @@ &rpm { * PM8901 supplies "preliminary regulators" whatever * that means */ - pm8901-regulators { + regulators-0 { vdd_l0-supply = <&pm8901_s4>; vdd_l1-supply = <&vph>; vdd_l2-supply = <&vph>; @@ -537,7 +537,7 @@ lvs0 { }; - pm8058-regulators { + regulators-1 { vdd_l0_l1_lvs-supply = <&pm8058_s3>; vdd_l2_l11_l12-supply = <&vph>; vdd_l3_l4_l5-supply = <&vph>; -- 2.34.1

2 years, 6 months

2
1
0 0

[PATCH] ARM: dts: qcom: ipq4019: fix broken NAND controller properties override

by Krzysztof Kozlowski

After renaming NAND controller node name from "qpic-nand" to "nand-controller", the board DTS/DTSI also have to be updated: Warning (unit_address_vs_reg): /soc/qpic-nand@79b0000: node has a unit name, but no reg or ranges property Cc: <stable(a)vger.kernel.org> Fixes: 9e1e00f18afc ("ARM: dts: qcom: Fix node name for NAND controller node") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 8 ++++---- arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 10 +++++----- arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi | 12 ++++++------ 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts index 79b0c6318e52..0993f840d1fc 100644 --- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts @@ -11,9 +11,9 @@ soc { dma-controller@7984000 { status = "okay"; }; - - qpic-nand@79b0000 { - status = "okay"; - }; }; }; + +&nand { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi index a63b3778636d..468ebc40d2ad 100644 --- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi @@ -102,10 +102,10 @@ pci@40000000 { status = "okay"; perst-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>; }; - - qpic-nand@79b0000 { - pinctrl-0 = <&nand_pins>; - pinctrl-names = "default"; - }; }; }; + +&nand { + pinctrl-0 = <&nand_pins>; + pinctrl-names = "default"; +}; diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi index 0107f552f520..7ef635997efa 100644 --- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi @@ -65,11 +65,11 @@ i2c@78b7000 { /* BLSP1 QUP2 */ dma-controller@7984000 { status = "okay"; }; - - qpic-nand@79b0000 { - pinctrl-0 = <&nand_pins>; - pinctrl-names = "default"; - status = "okay"; - }; }; }; + +&nand { + pinctrl-0 = <&nand_pins>; + pinctrl-names = "default"; + status = "okay"; +}; -- 2.34.1

2 years, 6 months

4
4
0 0

LTP: tracing: RIP: 0010:security_inode_permission+0x5/0x70

by Naresh Kamboju

While running LTP tracing tests on qemu-x86_64 following kernel crash noticed with stable-rc 6.3.4-rc2. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> FAILED COMMAND File: /lava-1/0/tests/0_ltp-tracing/automated/linux/ltp/output/LTP_tracing.failed TCONF COMMAND File: /opt/ltp/output/LTP_RUN_ON-LTP_tracing.log.tconf Running tests....... <4>[ 57.932577] int3: 0000 [#1] PREEMPT SMP PTI <4>[ 57.933090] CPU: 0 PID: 138 Comm: systemd-udevd Not tainted 6.3.4-rc2 #1 <4>[ 57.933243] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 <4>[ 57.933447] RIP: 0010:security_inode_permission+0x5/0x70 <4>[ 57.934163] Code: c0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 e8 <e7> 8d 64 18 f6 47 0d 02 75 50 55 48 89 e5 41 55 41 89 f5 41 54 49 <4>[ 57.934257] RSP: 0018:ffffa300c050bca0 EFLAGS: 00000246 <4>[ 57.934363] RAX: 00000000000041ed RBX: ffff9bda012805c0 RCX: 0000000000000000 <4>[ 57.934390] RDX: ffff9bda01f6df00 RSI: 0000000000000081 RDI: ffff9bda012805c0 <4>[ 57.934415] RBP: ffffa300c050bcd0 R08: ffffa300c050bd80 R09: 00000000ffffff9c <4>[ 57.934440] R10: 0000000000000fe0 R11: ffc9d09b99d09993 R12: 0000000000000081 <4>[ 57.934465] R13: 0000000000000000 R14: ffffffffa958f970 R15: 2f2f2f2f2f2f2f2f <4>[ 57.934544] FS: 00007fb89665f800(0000) GS:ffff9bda7bc00000(0000) knlGS:0000000000000000 <4>[ 57.934578] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 57.934604] CR2: 00007f60c9b0e000 CR3: 0000000104402000 CR4: 00000000000006f0 <4>[ 57.934793] Call Trace: <4>[ 57.934958] <TASK> <4>[ 57.935082] ? inode_permission+0x70/0x1a0 <4>[ 57.935235] link_path_walk.part.0.constprop.0+0xdd/0x3b0 <4>[ 57.935360] path_lookupat+0x3e/0x190 <4>[ 57.935426] filename_lookup+0xe8/0x1f0 <4>[ 57.935638] user_path_at_empty+0x42/0x60 <4>[ 57.935692] do_fchmodat+0x5f/0xc0 <4>[ 57.935809] __x64_sys_chmod+0x1f/0x30 <4>[ 57.935845] do_syscall_64+0x3e/0x90 <4>[ 57.935886] entry_SYSCALL_64_after_hwframe+0x72/0xdc <4>[ 57.935996] RIP: 0033:0x7fb8964fbd6b <4>[ 57.936393] Code: ff ff ff ff eb e6 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 5f 00 00 00 0f 05 c3 0f 1f 40 00 f3 0f 1e fa b8 5a 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 85 40 0f 00 f7 d8 64 89 01 48 <4>[ 57.936422] RSP: 002b:00007ffcf4c2aa38 EFLAGS: 00000202 ORIG_RAX: 000000000000005a <4>[ 57.936471] RAX: ffffffffffffffda RBX: 0000000000000190 RCX: 00007fb8964fbd6b <4>[ 57.936490] RDX: 00007ffcf4c2aa4f RSI: 0000000000000190 RDI: 00007ffcf4c2aa40 <4>[ 57.936504] RBP: 0000000000000190 R08: 0000000000000000 R09: 00007ffcf4c2a8e0 <4>[ 57.936528] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffcf4c2aa40 <4>[ 57.936542] R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000001 <4>[ 57.936754] </TASK> <4>[ 57.936853] Modules linked in: <4>[ 57.962890] ---[ end trace 0000000000000000 ]--- <4>[ 57.963006] RIP: 0010:security_inode_permission+0x5/0x70 <4>[ 57.963080] Code: c0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 e8 <e7> 8d 64 18 f6 47 0d 02 75 50 55 48 89 e5 41 55 41 89 f5 41 54 49 <4>[ 57.963105] RSP: 0018:ffffa300c050bca0 EFLAGS: 00000246 <4>[ 57.963145] RAX: 00000000000041ed RBX: ffff9bda012805c0 RCX: 0000000000000000 <4>[ 57.963163] RDX: ffff9bda01f6df00 RSI: 0000000000000081 RDI: ffff9bda012805c0 <4>[ 57.963180] RBP: ffffa300c050bcd0 R08: ffffa300c050bd80 R09: 00000000ffffff9c <4>[ 57.963195] R10: 0000000000000fe0 R11: ffc9d09b99d09993 R12: 0000000000000081 <4>[ 57.963209] R13: 0000000000000000 R14: ffffffffa958f970 R15: 2f2f2f2f2f2f2f2f <4>[ 57.963226] FS: 00007fb89665f800(0000) GS:ffff9bda7bc00000(0000) knlGS:0000000000000000 <4>[ 57.963246] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 57.963261] CR2: 00007f60c9b0e000 CR3: 0000000104402000 CR4: 00000000000006f0 <0>[ 57.963444] Kernel panic - not syncing: Fatal exception in interrupt <0>[ 57.964629] Kernel Offset: 0x26600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) links, - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.3… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.3… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2QCeudZ18KF3RXw3A5qf… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2QCeudZ18KF3RXw3A5qf… -- Linaro LKFT https://lkft.linaro.org

2 years, 6 months

4
3
0 0

[PATCH v1 0/1] 68020/030 signal handling following exceptions

by Finn Thain

This patch prevents potential stack corruption on 68020/030 when delivering signals following a bus error or (theoretically) an address error. Changed since RFC: - Dropped patch 1 because, as Andreas pointed out, it will not work properly. Finn Thain (1): m68k: Move signal frame following exception on 68020/030 arch/m68k/kernel/signal.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) -- 2.37.5

2 years, 6 months

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2023