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

+ mm-revert-mm-shmem-fix-data-race-in-shmem_getattr.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: revert "mm: shmem: fix data-race in shmem_getattr()" has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-revert-mm-shmem-fix-data-race-in-shmem_getattr.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Date: Fri Nov 15 04:57:24 PM PST 2024 Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. Link: https://lkml.kernel.org/r/ZzdxKF39VEmXSSyN@tissot.1015granger.net [1] Fixes: https://lkml.kernel.org/r/ZzdxKF39VEmXSSyN@tissot.1015granger.net Cc: Chuck Lever <chuck.lever(a)oracle.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Jeongjun Park <aha310510(a)gmail.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 2 -- 1 file changed, 2 deletions(-) --- a/mm/shmem.c~mm-revert-mm-shmem-fix-data-race-in-shmem_getattr +++ a/mm/shmem.c @@ -1166,9 +1166,7 @@ static int shmem_getattr(struct mnt_idma stat->attributes_mask |= (STATX_ATTR_APPEND | STATX_ATTR_IMMUTABLE | STATX_ATTR_NODUMP); - inode_lock_shared(inode); generic_fillattr(idmap, request_mask, inode, stat); - inode_unlock_shared(inode); if (shmem_huge_global_enabled(inode, 0, 0, false, NULL, 0)) stat->blksize = HPAGE_PMD_SIZE; _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are fs-proc-vmcorec-fix-warning-when-config_mmu=n.patch mm-revert-mm-shmem-fix-data-race-in-shmem_getattr.patch

3 months, 1 week

2
1
0 0

[PATCH net V2] gve: Flow steering trigger reset only for timeout error

by Jeroen de Borst

From: Ziwei Xiao <ziweixiao(a)google.com> When configuring flow steering rules, the driver is currently going through a reset for all errors from the device. Instead, the driver should only reset when there's a timeout error from the device. Fixes: 57718b60df9b ("gve: Add flow steering adminq commands") Cc: stable(a)vger.kernel.org Signed-off-by: Ziwei Xiao <ziweixiao(a)google.com> Signed-off-by: Jeroen de Borst <jeroendb(a)google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy(a)google.com> --- v2: Added missing Signed-off-by drivers/net/ethernet/google/gve/gve_adminq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c index e44e8b139633..060e0e674938 100644 --- a/drivers/net/ethernet/google/gve/gve_adminq.c +++ b/drivers/net/ethernet/google/gve/gve_adminq.c @@ -1248,10 +1248,10 @@ gve_adminq_configure_flow_rule(struct gve_priv *priv, sizeof(struct gve_adminq_configure_flow_rule), flow_rule_cmd); - if (err) { + if (err == -ETIME) { dev_err(&priv->pdev->dev, "Timeout to configure the flow rule, trigger reset"); gve_reset(priv, true); - } else { + } else if (!err) { priv->flow_rules_cache.rules_cache_synced = false; } -- 2.47.0.277.g8800431eea-goog

3 months, 1 week

3
2
0 0

[PATCH net v3] netdev-genl: Hold rcu_read_lock in napi_get

by Joe Damato

Hold rcu_read_lock in netdev_nl_napi_get_doit, which calls napi_by_id and is required to be called under rcu_read_lock. Cc: stable(a)vger.kernel.org Fixes: 27f91aaf49b3 ("netdev-genl: Add netlink framework functions for napi") Signed-off-by: Joe Damato <jdamato(a)fastly.com> --- v3: - Separate the patches that were a series in v2 (and earlier) as they target different trees. v2: - Simplified by removing the helper and calling rcu_read_lock / unlock directly instead. net/core/netdev-genl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/netdev-genl.c b/net/core/netdev-genl.c index 1cb954f2d39e..d2baa1af9df0 100644 --- a/net/core/netdev-genl.c +++ b/net/core/netdev-genl.c @@ -215,6 +215,7 @@ int netdev_nl_napi_get_doit(struct sk_buff *skb, struct genl_info *info) return -ENOMEM; rtnl_lock(); + rcu_read_lock(); napi = napi_by_id(napi_id); if (napi) { @@ -224,6 +225,7 @@ int netdev_nl_napi_get_doit(struct sk_buff *skb, struct genl_info *info) err = -ENOENT; } + rcu_read_unlock(); rtnl_unlock(); if (err) base-commit: 5b366eae71937ae7412365340b431064625f9617 -- 2.25.1

3 months, 1 week

2
1
0 0

[PATCH v2] kunit: Fix potential null dereference in kunit_device_driver_test()

by Gax-c

From: Zichen Xie <zichenxie0106(a)gmail.com> kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. Fixes: d03c720e03bd ("kunit: Add APIs for managing devices") Signed-off-by: Zichen Xie <zichenxie0106(a)gmail.com> Cc: stable(a)vger.kernel.org --- v2: Add Cc tag. --- lib/kunit/kunit-test.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/kunit/kunit-test.c b/lib/kunit/kunit-test.c index 37e02be1e710..d9c781c859fd 100644 --- a/lib/kunit/kunit-test.c +++ b/lib/kunit/kunit-test.c @@ -805,6 +805,8 @@ static void kunit_device_driver_test(struct kunit *test) struct device *test_device; struct driver_test_state *test_state = kunit_kzalloc(test, sizeof(*test_state), GFP_KERNEL); + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, test_state); + test->priv = test_state; test_driver = kunit_driver_create(test, "my_driver"); -- 2.34.1

3 months, 1 week

2
1
0 0

[PATCH stable 6.1.y] cxl/pci: fix error code in __cxl_hdm_decode_init()

by Dan Carpenter

When commit 0cab68720598 ("cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window") was backported, this chunk moved from the cxl_hdm_decode_init() function which returns negative error codes to the __cxl_hdm_decode_init() function which returns false on error. So the error code needs to be modified from -ENXIO to false. This issue only exits in the 6.1.y kernels. In later kernels negative error codes are correct and the driver didn't exist in earlier kernels. Fixes: 031217128990 ("cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- drivers/cxl/core/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c index 8d92a24fd73d..97adf9a7ea89 100644 --- a/drivers/cxl/core/pci.c +++ b/drivers/cxl/core/pci.c @@ -377,7 +377,7 @@ static bool __cxl_hdm_decode_init(struct cxl_dev_state *cxlds, if (!allowed && info->mem_enabled) { dev_err(dev, "Range register decodes outside platform defined CXL ranges.\n"); - return -ENXIO; + return false; } /* -- 2.45.2

3 months, 1 week

3
2
0 0

[PATCH RESEND] mm/damon: fix order of arguments in damos_before_apply tracepoint

by SeongJae Park

From: Akinobu Mita <akinobu.mita(a)gmail.com> Since the order of the scheme_idx and target_idx arguments in TP_ARGS is reversed, they are stored in the trace record in reverse. Fixes: c603c630b509 ("mm/damon/core: add a tracepoint for damos apply target regions") Cc: <stable(a)vger.kernel.org> Cc: SeongJae Park <sj(a)kernel.org> Signed-off-by: Akinobu Mita <akinobu.mita(a)gmail.com> Signed-off-by: SeongJae Park <sj(a)kernel.org> Link: https://patch.msgid.link/20241112154828.40307-1-akinobu.mita@gmail.com --- include/trace/events/damon.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/trace/events/damon.h b/include/trace/events/damon.h index 23200aabccac..da4bd9fd1162 100644 --- a/include/trace/events/damon.h +++ b/include/trace/events/damon.h @@ -15,7 +15,7 @@ TRACE_EVENT_CONDITION(damos_before_apply, unsigned int target_idx, struct damon_region *r, unsigned int nr_regions, bool do_trace), - TP_ARGS(context_idx, target_idx, scheme_idx, r, nr_regions, do_trace), + TP_ARGS(context_idx, scheme_idx, target_idx, r, nr_regions, do_trace), TP_CONDITION(do_trace), -- 2.39.5

3 months, 1 week

1
0
0 0

Re: Bluetooth kernel BUG with Intel AX211 (regression in 6.1.83)

by Linux regression tracking (Thorsten Leemhuis)

Hi stable team (and Bluetooth maintainers), I noticed a regression report about a BT problem in 6.1.y: On 21.04.24 15:54, Jeremy Lainé wrote: > > After upgrading my kernel to Debian's latest version (6.1.85), I > started encountering systematic kernel BUGs at boot, making the > bluetooth stack unusable. I initially reported this to Debian's bug > tracker: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069301 > > .. but have since confirmed that this is reproducible with vanilla > kernels, including the latest 6.1.y version (6.1.87). > > I tried various kernel versions (straight from kernel.org) to pinpoint > when the problem started occurring and the resultats are: Jeremy later wrote: > # first bad commit: [6083089ab00631617f9eac678df3ab050a9d837a] > Bluetooth: hci_conn: Consolidate code for aborting connections https://lore.kernel.org/all/8eeb980a-f04a-4e94-8065-25566cfef4dd@molgen.mpg… That's a13f316e90fdb1 ("Bluetooth: hci_conn: Consolidate code for aborting connections") [v6.6-rc1, v6.1.83 (6083089ab00631)] FWIW, there is a fix for the mainline commit under review: https://lore.kernel.org/all/20240411151929.403263-1-kovalev@altlinux.org/ But it is likely unrelated, as Jeremy later also wrote: > I'm now running 6.9-rc5 and have not been able to reproduce the issue, https://lore.kernel.org/all/CADRbXaA2yFjMo=_8_ZTubPbrrmWH9yx+aG5pUadnk395ko… Makes me wonder if 6.1.y is missing some other change a13f316e90fdb1 depends on. Ciao, Thorsten > I have included a trace below, and full system details are available > in the Debian bug listed above. Can you suggest any other tests I can > perform to help diagnose the origin of the problem? > > [ 22.660847] list_del corruption, ffff94d9f6302000->prev is > LIST_POISON2 (dead000000000122) > [ 22.660887] ------------[ cut here ]------------ > [ 22.660890] kernel BUG at lib/list_debug.c:56! > [ 22.660907] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI > [ 22.660917] CPU: 10 PID: 139 Comm: kworker/u25:0 Not tainted > 6.1.0-20-amd64 #1 Debian 6.1.85-1 > [ 22.660929] Hardware name: Dell Inc. XPS 9315/00KRKP, BIOS 1.19.1 03/14/2024 > [ 22.660936] Workqueue: hci0 hci_cmd_sync_work [bluetooth] > [ 22.661128] RIP: 0010:__list_del_entry_valid.cold+0x4b/0x6f > [ 22.661147] Code: fe ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 48 18 7a > 9f e8 14 a1 fe ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 10 18 7a 9f e8 00 > a1 fe ff <0f> 0b 48 89 fe 48 c7 c7 d8 17 7a 9f e8 ef a0 fe ff 0f 0b 48 > 89 fe > [ 22.661156] RSP: 0000:ffffae0e406efde0 EFLAGS: 00010246 > [ 22.661164] RAX: 000000000000004e RBX: ffff94d9f6302000 RCX: 0000000000000027 > [ 22.661172] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff94dfaf8a03a0 > [ 22.661177] RBP: ffff94d859392000 R08: 0000000000000000 R09: ffffae0e406efc78 > [ 22.661182] R10: 0000000000000003 R11: ffffffff9fed4448 R12: ffff94d859392000 > [ 22.661187] R13: ffff94d859392770 R14: ffff94d858cb9800 R15: dead000000000100 > [ 22.661194] FS: 0000000000000000(0000) GS:ffff94dfaf880000(0000) > knlGS:0000000000000000 > [ 22.661202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 22.661208] CR2: 00007f423c024038 CR3: 0000000799c04000 CR4: 0000000000750ee0 > [ 22.661214] PKRU: 55555554 > [ 22.661218] Call Trace: > [ 22.661225] <TASK> > [ 22.661232] ? __die_body.cold+0x1a/0x1f > [ 22.661246] ? die+0x2a/0x50 > [ 22.661257] ? do_trap+0xc5/0x110 > [ 22.661268] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661279] ? do_error_trap+0x6a/0x90 > [ 22.661289] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661298] ? exc_invalid_op+0x4c/0x60 > [ 22.661307] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661316] ? asm_exc_invalid_op+0x16/0x20 > [ 22.661328] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661337] hci_conn_del+0x136/0x3e0 [bluetooth] > [ 22.661466] hci_abort_conn_sync+0xaa/0x230 [bluetooth] > [ 22.661632] ? abort_conn_sync+0x3d/0x70 [bluetooth] > [ 22.661751] hci_cmd_sync_work+0x9f/0x150 [bluetooth] > [ 22.661915] process_one_work+0x1c4/0x380 > [ 22.661929] worker_thread+0x4d/0x380 > [ 22.661940] ? rescuer_thread+0x3a0/0x3a0 > [ 22.661950] kthread+0xd7/0x100 > [ 22.661959] ? kthread_complete_and_exit+0x20/0x20 > [ 22.661969] ret_from_fork+0x1f/0x30 > [ 22.661984] </TASK> > [ 22.661987] Modules linked in: ctr ccm nft_chain_nat xt_MASQUERADE > nf_nat nf_conntrack_netlink br_netfilter bridge stp llc xfrm_user > xfrm_algo nvme_fabrics rfcomm snd_seq_dummy snd_hrtimer snd_seq > snd_seq_device cmac algif_hash algif_skcipher af_alg snd_ctl_led > snd_soc_sof_sdw snd_soc_intel_hda_dsp_common snd_sof_probes > snd_soc_intel_sof_maxim_common snd_soc_rt715_sdca snd_soc_rt1316_sdw > regmap_sdw_mbq snd_hda_codec_hdmi regmap_sdw overlay ip6t_REJECT > nf_reject_ipv6 xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 > xt_LOG qrtr nf_log_syslog nft_limit bnep ipmi_devintf ipmi_msghandler > xt_limit xt_addrtype xt_tcpudp xt_conntrack nf_conntrack > nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables libcrc32c nfnetlink > binfmt_misc nls_ascii nls_cp437 vfat fat x86_pkg_temp_thermal > intel_powerclamp coretemp snd_soc_dmic snd_sof_pci_intel_tgl > snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation > soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp > snd_sof snd_sof_utils > [ 22.662122] snd_soc_hdac_hda snd_hda_ext_core > snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core kvm_intel > snd_compress btusb soundwire_bus btrtl kvm btbcm snd_hda_intel btintel > snd_intel_dspcfg btmtk dell_laptop snd_intel_sdw_acpi irqbypass > ledtrig_audio bluetooth snd_hda_codec i915 snd_hda_core rapl mei_hdcp > intel_rapl_msr snd_hwdep processor_thermal_device_pci dell_wmi joydev > hid_sensor_als intel_cstate jitterentropy_rng processor_thermal_device > snd_pcm hid_sensor_trigger processor_thermal_rfim dell_smbios > ucsi_acpi dcdbas hid_sensor_iio_common processor_thermal_mbox > drm_buddy intel_uncore iwlmvm pcspkr drbg iTCO_wdt typec_ucsi > dell_wmi_sysman snd_timer industrialio_triggered_buffer > drm_display_helper processor_thermal_rapl mei_me dell_wmi_descriptor > firmware_attributes_class kfifo_buf wmi_bmof ansi_cprng intel_pmc_bxt > cec snd roles intel_rapl_common ecdh_generic iTCO_vendor_support > int3403_thermal watchdog ecc industrialio mei soundcore typec > int3400_thermal rc_core mac80211 > [ 22.662253] int340x_thermal_zone intel_pmc_core button intel_hid > acpi_thermal_rel sparse_keymap ttm acpi_pad acpi_tad drm_kms_helper > libarc4 igen6_edac i2c_algo_bit ac evdev hid_multitouch serio_raw > iwlwifi cfg80211 rfkill msr parport_pc ppdev lp drm parport fuse loop > efi_pstore configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 > mbcache jbd2 crc32c_generic usbhid hid_sensor_custom hid_sensor_hub > dm_crypt dm_mod intel_ishtp_hid nvme nvme_core t10_pi > crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic > crc64 ahci libahci crct10dif_pclmul crct10dif_common libata > crc32_pclmul crc32c_intel scsi_mod spi_pxa2xx_platform > ghash_clmulni_intel dw_dmac hid_generic sha512_ssse3 scsi_common > dw_dmac_core xhci_pci sha512_generic sha256_ssse3 xhci_hcd sha1_ssse3 > usbcore i2c_hid_acpi intel_lpss_pci aesni_intel video intel_ish_ipc > i2c_i801 i2c_hid intel_lpss psmouse thunderbolt crypto_simd cryptd > i2c_smbus vmd intel_ishtp usb_common idma64 hid battery wmi > [ 22.662422] ---[ end trace 0000000000000000 ]--- > > Cheers, > > Jeremy #regzbot ^introduced 6083089ab0063 #regzbot title Bluetooth kernel BUG with Intel AX211 #regzbot duplicate: https://lore.kernel.org/all/8eeb980a-f04a-4e94-8065-25566cfef4dd@molgen.mpg… #regzbot ignore-activit

3 months, 1 week

7
22
0 0

[PATCH] PCI: of_property: Assign PCI instead of CPU bus address to dynamic PCI nodes

by Andrea della Porta

When populating "ranges" property for a PCI bridge or endpoint, of_pci_prop_ranges() incorrectly use the CPU bus address of the resource. In such PCI nodes, the window should instead be in PCI address space. Call pci_bus_address() on the resource in order to obtain the PCI bus address. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Cc: stable(a)vger.kernel.org Signed-off-by: Andrea della Porta <andrea.porta(a)suse.com> Acked-by: Bjorn Helgaas <bhelgaas(a)google.com> Tested-by: Herve Codina <herve.codina(a)bootlin.com> --- This patch, originally preparatory for a bigger patchset (see [1]), has been splitted in a standalone one for better management and because it contains a bugfix which is probably of interest to stable branch. drivers/pci/of_property.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c index 5a0b98e69795..886c236e5de6 100644 --- a/drivers/pci/of_property.c +++ b/drivers/pci/of_property.c @@ -126,7 +126,7 @@ static int of_pci_prop_ranges(struct pci_dev *pdev, struct of_changeset *ocs, if (of_pci_get_addr_flags(&res[j], &flags)) continue; - val64 = res[j].start; + val64 = pci_bus_address(pdev, &res[j] - pdev->resource); of_pci_set_address(pdev, rp[i].parent_addr, val64, 0, flags, false); if (pci_is_bridge(pdev)) { -- 2.35.3

3 months, 1 week

3
5
0 0

LKFT CI: improving Networking selftests results when validating stable kernels

by Matthieu Baerts

Hello LKFT maintainers, CI operators, First, I would like to say thank you to the people behind the LKFT project for validating stable kernels (and more), and including some Network selftests in their tests suites. A lot of improvements around the networking kselftests have been done this year. At the last Netconf [1], we discussed how these tests were validated on stable kernels from CIs like the LKFT one, and we have some suggestions to improve the situation. KSelftests from the same version -------------------------------- According to the doc [2], kselftests should support all previous kernel versions. The LKFT CI is then using the kselftests from the last stable release to validate all stable versions. Even if there are good reasons to do that, we would like to ask for an opt-out for this policy for the networking tests: this is hard to maintain with the increased complexity, hard to validate on all stable kernels before applying patches, and hard to put in place in some situations. As a result, many tests are failing on older kernels, and it looks like it is a lot of work to support older kernels, and to maintain this. Many networking tests are validating the internal behaviour that is not exposed to the userspace. A typical example: some tests look at the raw packets being exchanged during a test, and this behaviour can change without modifying how the userspace is interacting with the kernel. The kernel could expose capabilities, but that's not something that seems natural to put in place for internal behaviours that are not exposed to end users. Maybe workarounds could be used, e.g. looking at kernel symbols, etc. Nut that doesn't always work, increase the complexity, and often "false positive" issue will be noticed only after a patch hits stable, and will cause a bunch of tests to be ignored. Regarding fixes, ideally they will come with a new or modified test that can also be backported. So the coverage can continue to grow in stable versions too. Do you think that from the kernel v6.12 (or before?), the LKFT CI could run the networking kselftests from the version that is being validated, and not from a newer one? So validating the selftests from v6.12.1 on a v6.12.1, and not the ones from a future v6.16.y on a v6.12.42. Skipped tests ------------- It looks like many tests are skipped: - Some have been in a skip file [3] for a while: maybe they can be removed? - Some are skipped because of missing tools: maybe they can be added? e.g. iputils, tshark, ipv6toolkit, etc. - Some tests are in 'net', but in subdirectories, and hence not tested, e.g. forwarding, packetdrill, netfilter, tcp_ao. Could they be tested too? How can we change this to increase the code coverage using existing tests? KVM --- It looks like different VMs are being used to execute the different tests. Do these VMs benefit from any accelerations like KVM? If not, some tests might fail because the environment is too slow. The KSFT_MACHINE_SLOW=yes env var can be set to increase some tolerances, timeout or to skip some parts, but that might not be enough for some tests. Notifications ------------- In case of new regressions, who is being notified? Are the people from the MAINTAINERS file, and linked to the corresponding selftests being notified or do they need to do the monitoring on their side? Looking forward to improving the networking selftests results when validating stable kernels! [1] https://netdev.bots.linux.dev/netconf/2024/ [2] https://docs.kernel.org/dev-tools/kselftest.html [3] https://github.com/Linaro/test-definitions/blob/master/automated/linux/ksel… Cheers, Matt -- Sponsored by the NGI0 Core fund.

3 months, 1 week

3
6
0 0

generic/645 failing on ext4, xfs (probably others) on all LTS kernels

by Theodore Ts'o

The test generic/645 is failing on (at least) 6.6, 6.1, 5.15 LTS kernels. This fix is apparently commit dacfd001eaf2 ("fs/mnt_idmapping.c: Return -EINVAL when no map is written"), but in order to take this patch, it looks like we need to backport the 4 patch series "mnt_idmapping: decouple from namespaces"[1] (and possibly others; I haven't tried yet). [1] https://lore.kernel.org/all/20231122-vfs-mnt_idmap-v1-0-dae4abdde5bd@kernel… This looks fairly involved so the questions I have are: (1) Should we request this patch series plus commit dacfd001eaf2 into the stable kernels --- or should I just add a versioned excludes[2] and just skip generic/645 from all kernels older than Linux 6.9 if we think it's too involved and/or risky to backport these id mapping changes? (2) How much do we care that generic/645 is failing on LTS kernels? Are user/applications going to notice or care? Thanks, - Ted [2] Like this: diff --git a/test-appliance/files/root/fs/global_exclude b/test-appliance/files/root/fs/global_exclude index d7acf89f..42902152 100644 --- a/test-appliance/files/root/fs/global_exclude +++ b/test-appliance/files/root/fs/global_exclude @@ -30,6 +30,14 @@ generic/484 generic/554 #endif +#if LINUX_VERSION_CODE < KERNEL_VERSION(6,9,0) +// This test failure is fixed by commit dacfd001eaf2 +// ("fs/mnt_idmapping.c: Return -EINVAL when no map is written"), +// but it's too involved to backport it and its dependencies to +// the LTS kernels. +generic/645 +#endif + #ifndef IS_DAX_CONFIG // Unless we are testing the dax config, we can exclude all dax tests -g dax

3 months, 1 week

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror