June 2024 - Linux-stable-mirror

Re: Patch "driver core: platform: Emit a warning if a remove callback returned non-zero" has been added to the 5.10-stable tree

by Uwe Kleine-König

Hello Sasha, On 6/16/24 04:18, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > driver core: platform: Emit a warning if a remove callback returned non-zero > > to the 5.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > driver-core-platform-emit-a-warning-if-a-remove-call.patch > and it can be found in the queue-5.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 2f1ac60bc9668567f021c314312563951039f77b > Author: Uwe Kleine-König <uwe(a)kleine-koenig.org> > Date: Sun Feb 7 22:15:37 2021 +0100 > > driver core: platform: Emit a warning if a remove callback returned non-zero > > [ Upstream commit e5e1c209788138f33ca6558bf9f572f6904f486d ] > > The driver core ignores the return value of a bus' remove callback. However > a driver returning an error code is a hint that there is a problem, > probably a driver author who expects that returning e.g. -EBUSY has any > effect. > > The right thing to do would be to make struct platform_driver::remove() > return void. With the immense number of platform drivers this is however a > big quest and I hope to prevent at least a few new drivers that return an > error code here. > > Signed-off-by: Uwe Kleine-König <uwe(a)kleine-koenig.org> > Link: https://lore.kernel.org/r/20210207211537.19992-1-uwe@kleine-koenig.org > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Stable-dep-of: 55c421b36448 ("mmc: davinci: Don't strip remove function when driver is builtin") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> That looks wrong. If this patch should be included in stable, it shouldn't be because it's a dependency. 55c421b36448 works without this patch for sure. Either backport e5e1c2097881 because you think that warning should be in 5.10.x, or don't backport it. Best regards Uwe

4 months, 1 week

2
1
0 0

[PATCH v2] ata: ahci: Do not enable LPM if no LPM states are supported by the HBA

by Niklas Cassel

LPM consists of HIPM (host initiated power management) and DIPM (device initiated power management). ata_eh_set_lpm() will only enable HIPM if both the HBA and the device supports it. However, DIPM will be enabled as long as the device supports it. The HBA will later reject the device's request to enter a power state that it does not support (Slumber/Partial/DevSleep) (DevSleep is never initiated by the device). For a HBA that doesn't support any LPM states, simply don't set a LPM policy such that all the HIPM/DIPM probing/enabling will be skipped. Not enabling HIPM or DIPM in the first place is safer than relying on the device following the AHCI specification and respecting the NAK. (There are comments in the code that some devices misbehave when receiving a NAK.) Performing this check in ahci_update_initial_lpm_policy() also has the advantage that a HBA that doesn't support any LPM states will take the exact same code paths as a port that is external/hot plug capable. Side note: the port in ata_port_dbg() has not been given a unique id yet, but this is not overly important as the debug print is disabled unless explicitly enabled using dynamic debug. A follow-up series will make sure that the unique id assignment will be done earlier. For now, the important thing is that the function returns before setting the LPM policy. Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Cc: stable(a)vger.kernel.org Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- Changes since v1: Add debug print as suggested by Mika. drivers/ata/ahci.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 07d66d2c5f0d..5eb38fbbbecd 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1735,6 +1735,14 @@ static void ahci_update_initial_lpm_policy(struct ata_port *ap) if (ap->pflags & ATA_PFLAG_EXTERNAL) return; + /* If no LPM states are supported by the HBA, do not bother with LPM */ + if ((ap->host->flags & ATA_HOST_NO_PART) && + (ap->host->flags & ATA_HOST_NO_SSC) && + (ap->host->flags & ATA_HOST_NO_DEVSLP)) { + ata_port_dbg(ap, "no LPM states supported, not enabling LPM\n"); + return; + } + /* user modified policy via module param */ if (mobile_lpm_policy != -1) { policy = mobile_lpm_policy; -- 2.45.2

4 months, 1 week

4
5
0 0

[PATCH v2] riscv: dts: starfive: Set EMMC vqmmc maximum voltage to 3.3V on JH7110 boards

by Shengyu Qu

Currently, for JH7110 boards with EMMC slot, vqmmc voltage for EMMC is fixed to 1.8V, while the spec needs it to be 3.3V on low speed mode and should support switching to 1.8V when using higher speed mode. Since there are no other peripherals using the same voltage source of EMMC's vqmmc(ALDO4) on every board currently supported by mainline kernel, regulator-max-microvolt of ALDO4 should be set to 3.3V. Cc: stable(a)vger.kernel.org Signed-off-by: Shengyu Qu <wiagn233(a)outlook.com> Fixes: 7dafcfa79cc9 ("riscv: dts: starfive: enable DCDC1&ALDO4 node in axp15060") --- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi index 37b4c294ffcc..c7a549ec7452 100644 --- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi +++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi @@ -244,7 +244,7 @@ emmc_vdd: aldo4 { regulator-boot-on; regulator-always-on; regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; regulator-name = "emmc_vdd"; }; }; -- 2.39.2

4 months, 1 week

2
4
0 0

[PATCH v6] usb: dwc3: core: Workaround for CSR read timeout

by joswang

From: Jos Wang <joswang(a)lenovo.com> This is a workaround for STAR 4846132, which only affects DWC_usb31 version2.00a operating in host mode. There is a problem in DWC_usb31 version 2.00a operating in host mode that would cause a CSR read timeout When CSR read coincides with RAM Clock Gating Entry. By disable Clock Gating, sacrificing power consumption for normal operation. Cc: stable(a)vger.kernel.org Signed-off-by: Jos Wang <joswang(a)lenovo.com> --- v5 -> v6: no change v4 -> v5: no change v3 -> v4: modify commit message, add Cc: stable(a)vger.kernel.org v2 -> v3: - code refactor - modify comment, add STAR number, workaround applied in host mode - modify commit message, add STAR number, workaround applied in host mode - modify Author Jos Wang v1 -> v2: no change drivers/usb/dwc3/core.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 7ee61a89520b..2a3adc80fe0f 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -957,12 +957,16 @@ static bool dwc3_core_is_valid(struct dwc3 *dwc) static void dwc3_core_setup_global_control(struct dwc3 *dwc) { + unsigned int power_opt; + unsigned int hw_mode; u32 reg; reg = dwc3_readl(dwc->regs, DWC3_GCTL); reg &= ~DWC3_GCTL_SCALEDOWN_MASK; + hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0); + power_opt = DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1); - switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) { + switch (power_opt) { case DWC3_GHWPARAMS1_EN_PWROPT_CLK: /** * WORKAROUND: DWC3 revisions between 2.10a and 2.50a have an @@ -995,6 +999,20 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc) break; } + /* + * This is a workaround for STAR#4846132, which only affects + * DWC_usb31 version2.00a operating in host mode. + * + * There is a problem in DWC_usb31 version 2.00a operating + * in host mode that would cause a CSR read timeout When CSR + * read coincides with RAM Clock Gating Entry. By disable + * Clock Gating, sacrificing power consumption for normal + * operation. + */ + if (power_opt != DWC3_GHWPARAMS1_EN_PWROPT_NO && + hw_mode != DWC3_GHWPARAMS0_MODE_GADGET && DWC3_VER_IS(DWC31, 200A)) + reg |= DWC3_GCTL_DSBLCLKGTNG; + /* check if current dwc3 is on simulation board */ if (dwc->hwparams.hwparams6 & DWC3_GHWPARAMS6_EN_FPGA) { dev_info(dwc->dev, "Running with FPGA optimizations\n"); -- 2.17.1

4 months, 1 week

2
2
0 0

Re: Patch "ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()" has been added to the 6.9-stable tree

by Baokun Li

Hi Sasha, Thanks for adapting this patch to the stable branch. Just one nit. On 2024/6/16 10:05, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() > > to the 6.9-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: > ext4-fix-slab-out-of-bounds-in-ext4_mb_find_good_gro.patch > and it can be found in the queue-6.9 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 84cee2d2394a43766dd2990edac8a4a05817ef7b > Author: Baokun Li <libaokun1(a)huawei.com> > Date: Tue Mar 19 19:33:20 2024 +0800 > > ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() > > [ Upstream commit 13df4d44a3aaabe61cd01d277b6ee23ead2a5206 ] > > We can trigger a slab-out-of-bounds with the following commands: > > mkfs.ext4 -F /dev/$disk 10G > mount /dev/$disk /tmp/test > echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc > echo test > /tmp/test/file && sync > > ================================================================== > BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] > Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 > CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 > Call Trace: > dump_stack_lvl+0x2c/0x50 > kasan_report+0xb6/0xf0 > ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] > ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] > ext4_mb_new_blocks+0x88a/0x1370 [ext4] > ext4_ext_map_blocks+0x14f7/0x2390 [ext4] > ext4_map_blocks+0x569/0xea0 [ext4] > ext4_do_writepages+0x10f6/0x1bc0 [ext4] > [...] > ================================================================== > > The flow of issue triggering is as follows: > > // Set s_mb_group_prealloc to 2147483647 via sysfs > ext4_mb_new_blocks > ext4_mb_normalize_request > ext4_mb_normalize_group_request > ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc > ext4_mb_regular_allocator > ext4_mb_choose_next_group > ext4_mb_choose_next_group_best_avail > mb_avg_fragment_size_order > order = fls(len) - 2 = 29 > ext4_mb_find_good_group_avg_frag_lists > frag_list = &sbi->s_mb_avg_fragment_size[order] > if (list_empty(frag_list)) // Trigger SOOB! > > At 4k block size, the length of the s_mb_avg_fragment_size list is 14, > but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds > to be triggered by an attempt to access an element at index 29. > > Add a new attr_id attr_clusters_in_group with values in the range > [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as > that type to fix the issue. In addition avoid returning an order > from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) > and reduce some useless loops. > > Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") > CC: stable(a)vger.kernel.org > Signed-off-by: Baokun Li <libaokun1(a)huawei.com> > Reviewed-by: Jan Kara <jack(a)suse.cz> > Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> > Link: https://lore.kernel.org/r/20240319113325.3110393-5-libaokun1@huawei.com > Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index 714f83632e3f9..66b5a68b0254e 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -831,6 +831,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) > return 0; > if (order == MB_NUM_ORDERS(sb)) > order--; > + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) > + order = MB_NUM_ORDERS(sb) - 1; > return order; > } > > @@ -1008,6 +1010,8 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context > * goal length. > */ > order = fls(ac->ac_g_ex.fe_len) - 1; > + if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb))) > + order = MB_NUM_ORDERS(ac->ac_sb); > min_order = order - sbi->s_mb_best_avail_max_trim_order; > if (min_order < 0) > min_order = 0; > diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c > index 295ea9a32de91..ca66e33f61815 100644 > --- a/fs/ext4/sysfs.c > +++ b/fs/ext4/sysfs.c > @@ -29,6 +29,7 @@ typedef enum { > attr_trigger_test_error, > attr_first_error_time, > attr_last_error_time, > + attr_clusters_in_group, > attr_feature, > attr_pointer_ui, > attr_pointer_ul, > @@ -207,13 +208,14 @@ EXT4_ATTR_FUNC(sra_exceeded_retry_limit, 0444); > > EXT4_ATTR_OFFSET(inode_readahead_blks, 0644, inode_readahead, > ext4_sb_info, s_inode_readahead_blks); > +EXT4_ATTR_OFFSET(mb_group_prealloc, 0644, clusters_in_group, > + ext4_sb_info, s_mb_group_prealloc); > EXT4_RW_ATTR_SBI_UI(inode_goal, s_inode_goal); > EXT4_RW_ATTR_SBI_UI(mb_stats, s_mb_stats); > EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); > EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); > EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); > EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); > -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); > EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); > EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); > EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); > @@ -376,6 +378,7 @@ static ssize_t ext4_generic_attr_show(struct ext4_attr *a, > > switch (a->attr_id) { > case attr_inode_readahead: > + case attr_clusters_in_group: > case attr_pointer_ui: > if (a->attr_ptr == ptr_ext4_super_block_offset) > return sysfs_emit(buf, "%u\n", le32_to_cpup(ptr)); > @@ -459,6 +462,14 @@ static ssize_t ext4_attr_store(struct kobject *kobj, > else > *((unsigned int *) ptr) = t; > return len; > + case attr_clusters_in_group: Since commit f536808adcc3 "ext4: refactor out ext4_generic_attr_store()" is not backported to stable, the following judgement needs to be added here: if (!ptr) return 0; The patch for the 6.6-stable tree has the same problem. Regards, Baokun > + ret = kstrtouint(skip_spaces(buf), 0, &t); > + if (ret) > + return ret; > + if (t > sbi->s_clusters_per_group) > + return -EINVAL; > + *((unsigned int *) ptr) = t; > + return len; > case attr_pointer_ul: > if (!ptr) > return 0;

4 months, 1 week

2
2
0 0

[PATCH v2] xhci: Apply XHCI_RESET_TO_DEFAULT quirk to TGL

by Reka Norman

TGL systems have the same issue as ADL, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to TGL as well. The issue it fixes is a ~20s boot time delay when booting from S5. It affects TGL devices, and TGL support was added starting from v5.3. Cc: stable(a)vger.kernel.org Signed-off-by: Reka Norman <rekanorman(a)chromium.org> --- Changes in v2: - Add cc stable drivers/usb/host/xhci-pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index c040d816e626..137bd3da1128 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -49,6 +49,7 @@ #define PCI_DEVICE_ID_INTEL_DENVERTON_XHCI 0x19d0 #define PCI_DEVICE_ID_INTEL_ICE_LAKE_XHCI 0x8a13 #define PCI_DEVICE_ID_INTEL_TIGER_LAKE_XHCI 0x9a13 +#define PCI_DEVICE_ID_INTEL_TIGER_LAKE_PCH_XHCI 0xa0ed #define PCI_DEVICE_ID_INTEL_COMET_LAKE_XHCI 0xa3af #define PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI 0x51ed #define PCI_DEVICE_ID_INTEL_ALDER_LAKE_N_PCH_XHCI 0x54ed @@ -372,7 +373,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci->quirks |= XHCI_MISSING_CAS; if (pdev->vendor == PCI_VENDOR_ID_INTEL && - (pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI || + (pdev->device == PCI_DEVICE_ID_INTEL_TIGER_LAKE_PCH_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI || pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_N_PCH_XHCI)) xhci->quirks |= XHCI_RESET_TO_DEFAULT; -- 2.45.2.627.g7a2c4fd464-goog

4 months, 1 week

2
1
0 0

[PATCH] ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14AHP9

by Pablo Caño

Lenovo Yoga Pro 7 14AHP9 (PCI SSID 17aa:3891) seems requiring a similar workaround like Yoga 9 model and Yoga 7 Pro 14APH8 for the bass speaker. --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index aa76d1c88589..f9223fedf8e9 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10525,6 +10525,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x387e, "Yoga S780-16 pro Quad YC", ALC287_FIXUP_TAS2781_I2C), SND_PCI_QUIRK(0x17aa, 0x3881, "YB9 dual power mode2 YC", ALC287_FIXUP_TAS2781_I2C), SND_PCI_QUIRK(0x17aa, 0x3882, "Lenovo Yoga Pro 7 14APH8", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), + SND_PCI_QUIRK(0x17aa, 0x3891, "Lenovo Yoga Pro 7 14AHP9", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), SND_PCI_QUIRK(0x17aa, 0x3884, "Y780 YG DUAL", ALC287_FIXUP_TAS2781_I2C), SND_PCI_QUIRK(0x17aa, 0x3886, "Y780 VECO DUAL", ALC287_FIXUP_TAS2781_I2C), SND_PCI_QUIRK(0x17aa, 0x38a7, "Y780P AMD YG dual", ALC287_FIXUP_TAS2781_I2C), -- 2.45.2

4 months, 1 week

2
1
0 0

Re: Patch "kbuild: rust: force `alloc` extern to allow "empty" Rust files" has been added to the 6.1-stable tree

by Miguel Ojeda

On Sun, Jun 16, 2024 at 4:11 AM Sasha Levin <sashal(a)kernel.org> wrote: > > Cc: stable(a)vger.kernel.org # v6.6+ This cannot be backported to 6.1 unless we upgrade the compiler, since the feature is not available in old versions. For future reference, this patch got picked for 6.1 a couple more times: https://lore.kernel.org/stable/CANiq72=V1=D-X5ncqN1pyfE4L1bz5zFRdBot6HpkCYi… https://lore.kernel.org/stable/CANiq72ndLzts-KzUv_22vHF0tYkPvROv=oG+KP2KhbC… If I had known it would cause your scripts to pick it up repeatedly, then I would have probably avoided `Fixes`/`Cc` -- it is a very minor issue. Cheers, Miguel

4 months, 1 week

2
1
0 0

[PATCHv3 6.6.y 0/3] Fix missing lib.sh for net/unicast_extensions.sh and net/pmtu.sh tests

by Po-Hsu Lin

Since upstream commit: * 0f4765d0 "selftests/net: convert unicast_extensions.sh to run it in unique namespace" * 378f082e "selftests/net: convert pmtu.sh to run it in unique namespace" The lib.sh from commit 25ae948b "selftests/net: add lib.sh" will be needed. Otherwise these test will complain about missing files and fail: $ sudo ./unicast_extensions.sh ./unicast_extensions.sh: line 31: lib.sh: No such file or directory ... $ sudo ./pmtu.sh ./pmtu.sh: line 201: lib.sh: No such file or directory ./pmtu.sh: line 941: cleanup_all_ns: command not found ... Another commit b6925b4e "selftests/net: add variable NS_LIST for lib.sh" is needed to add support for the cleanup_all_ns above. And 2114e833 "selftests: forwarding: Avoid failures to source net/lib.sh" is a follow-up fix for tests inside the net/forwarding directory. V2: Add 2114e833 "selftests: forwarding: Avoid failures to source net/lib.sh" as suggested by Hangbin Liu. V3: Adjust commit 25ae948b to add lib.sh directly to TEST_FILES in Makefile, as we already have upstream commit 06efafd8 that would make this change landed in 6.6.y. Benjamin Poirier (1): selftests: forwarding: Avoid failures to source net/lib.sh Hangbin Liu (2): selftests/net: add lib.sh selftests/net: add variable NS_LIST for lib.sh tools/testing/selftests/net/Makefile | 2 +- tools/testing/selftests/net/forwarding/lib.sh | 52 +++++++-------- tools/testing/selftests/net/lib.sh | 93 +++++++++++++++++++++++++++ 3 files changed, 120 insertions(+), 27 deletions(-) create mode 100644 tools/testing/selftests/net/lib.sh -- 2.7.4

4 months, 1 week

2
4
0 0

[PATCH 6.1] Revert "fork: defer linking file vma until vma is fully initialized"

by Sam James

This reverts commit 0c42f7e039aba3de6d7dbf92da708e2b2ecba557. The backport is incomplete and causes xfstests failures. The consequences of the incomplete backport seem worse than the original issue, so pick the lesser evil and revert until a full backport is ready. Link: https://lore.kernel.org/stable/20240604004751.3883227-1-leah.rumancik@gmail… Reported-by: Leah Rumancik <leah.rumancik(a)gmail.com> Signed-off-by: Sam James <sam(a)gentoo.org> --- kernel/fork.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 7e9a5919299b4..85617928041cf 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -662,15 +662,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, } else if (anon_vma_fork(tmp, mpnt)) goto fail_nomem_anon_vma_fork; tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT); - /* - * Copy/update hugetlb private vma information. - */ - if (is_vm_hugetlb_page(tmp)) - hugetlb_dup_vma_private(tmp); - - if (tmp->vm_ops && tmp->vm_ops->open) - tmp->vm_ops->open(tmp); - file = tmp->vm_file; if (file) { struct address_space *mapping = file->f_mapping; @@ -687,6 +678,12 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, i_mmap_unlock_write(mapping); } + /* + * Copy/update hugetlb private vma information. + */ + if (is_vm_hugetlb_page(tmp)) + hugetlb_dup_vma_private(tmp); + /* Link the vma into the MT */ mas.index = tmp->vm_start; mas.last = tmp->vm_end - 1; @@ -698,6 +695,9 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, if (!(tmp->vm_flags & VM_WIPEONFORK)) retval = copy_page_range(tmp, mpnt); + if (tmp->vm_ops && tmp->vm_ops->open) + tmp->vm_ops->open(tmp); + if (retval) goto loop_out; } -- 2.45.2

4 months, 1 week

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024