Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

175 participants
124009 discussions

[PATCH] PCI: Avoid work_on_cpu() in async probe workers

by Jinhui Guo

Commit ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver") speeds up the loading of large numbers of device drivers by submitting asynchronous probe workers to an unbounded workqueue and binding each worker to the CPU near the device’s NUMA node. These workers are not scheduled on isolated CPUs because their cpumask is restricted to housekeeping_cpumask(HK_TYPE_WQ) and housekeeping_cpumask(HK_TYPE_DOMAIN). However, when PCI devices reside on the same NUMA node, all their drivers’ probe workers are bound to the same CPU within that node, yet the probes still run in parallel because pci_call_probe() invokes work_on_cpu(). Introduced by commit 873392ca514f ("PCI: work_on_cpu: use in drivers/pci/pci-driver.c"), work_on_cpu() queues a worker on system_percpu_wq to bind the probe thread to the first CPU in the device’s NUMA node (chosen via cpumask_any_and() in pci_call_probe()). 1. The function __driver_attach() submits an asynchronous worker with callback __driver_attach_async_helper(). __driver_attach() async_schedule_dev(__driver_attach_async_helper, dev) async_schedule_node(func, dev, dev_to_node(dev)) async_schedule_node_domain(func, data, node, &async_dfl_domain) __async_schedule_node_domain(func, data, node, domain, entry) queue_work_node(node, async_wq, &entry->work) 2. The asynchronous probe worker ultimately calls work_on_cpu() in pci_call_probe(), binding the worker to the same CPU within the device’s NUMA node. __driver_attach_async_helper() driver_probe_device(drv, dev) __driver_probe_device(drv, dev) really_probe(dev, drv) call_driver_probe(dev, drv) dev->bus->probe(dev) pci_device_probe(dev) __pci_device_probe(drv, pci_dev) pci_call_probe(drv, pci_dev, id) cpu = cpumask_any_and(cpumask_of_node(node), wq_domain_mask) error = work_on_cpu(cpu, local_pci_probe, &ddi) schedule_work_on(cpu, &wfc.work); queue_work_on(cpu, system_percpu_wq, work) To fix the issue, pci_call_probe() must not call work_on_cpu() when it is already running inside an unbounded asynchronous worker. Because a driver can be probed asynchronously either by probe_type or by the kernel command line, we cannot rely on PROBE_PREFER_ASYNCHRONOUS alone. Instead, we test the PF_WQ_WORKER flag in current->flags; if it is set, pci_call_probe() is executing within an unbounded workqueue worker and should skip the extra work_on_cpu() call. Testing three NVMe devices on the same NUMA node of an AMD EPYC 9A64 2.4 GHz processor shows a 35 % probe-time improvement with the patch: Before (all on CPU 0): nvme 0000:01:00.0: CPU: 0, COMM: kworker/0:1, probe cost: 53372612 ns nvme 0000:02:00.0: CPU: 0, COMM: kworker/0:2, probe cost: 49532941 ns nvme 0000:03:00.0: CPU: 0, COMM: kworker/0:3, probe cost: 47315175 ns After (spread across CPUs 1, 2, 5): nvme 0000:01:00.0: CPU: 5, COMM: kworker/u1025:5, probe cost: 34765890 ns nvme 0000:02:00.0: CPU: 1, COMM: kworker/u1025:2, probe cost: 34696433 ns nvme 0000:03:00.0: CPU: 2, COMM: kworker/u1025:3, probe cost: 33233323 ns The improvement grows with more PCI devices because fewer probes contend for the same CPU. Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver") Cc: stable(a)vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- drivers/pci/pci-driver.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 7c2d9d596258..4bc47a84d330 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -366,9 +366,11 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev, /* * Prevent nesting work_on_cpu() for the case where a Virtual Function * device is probed from work_on_cpu() of the Physical device. + * Check PF_WQ_WORKER to prevent invoking work_on_cpu() in an asynchronous + * probe worker when the driver allows asynchronous probing. */ if (node < 0 || node >= MAX_NUMNODES || !node_online(node) || - pci_physfn_is_probed(dev)) { + pci_physfn_is_probed(dev) || (current->flags & PF_WQ_WORKER)) { cpu = nr_cpu_ids; } else { cpumask_var_t wq_domain_mask; -- 2.20.1

2 days, 7 hours

[PATCH v2] mfd: macsmc: Initialize mutex

by Janne Grunau

Initialize struct apple_smc's mutex in apple_smc_probe(). Using the mutex uninitialized surprisingly resulted only in occasional NULL pointer dereferences in apple_smc_read() calls from the probe() functions of sub devices. Fixes: e038d985c9823 ("mfd: Add Apple Silicon System Management Controller") Cc: stable(a)vger.kernel.org Signed-off-by: Janne Grunau <j(a)jannau.net> --- Changes in v2: - rewritten commit message - added missing Cc: stable - rebased onto v6.19-rc1 - Link to v1: https://lore.kernel.org/r/20250925-macsmc-mutex_init-v1-1-416e9e644735@jann… --- drivers/mfd/macsmc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c index e3893e255ce5e4bb4832d80ad1fc002d413a291a..3015e8d36d6e5bfdcea342c7d05a7b34788d7845 100644 --- a/drivers/mfd/macsmc.c +++ b/drivers/mfd/macsmc.c @@ -413,6 +413,7 @@ static int apple_smc_probe(struct platform_device *pdev) if (!smc) return -ENOMEM; + mutex_init(&smc->mutex); smc->dev = &pdev->dev; smc->sram_base = devm_platform_get_and_ioremap_resource(pdev, 1, &smc->sram); if (IS_ERR(smc->sram_base)) --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20250925-macsmc-mutex_init-80d7cb2aacfa Best regards, -- Janne Grunau <j(a)jannau.net>

2 days, 11 hours

[PATCH] mm/zswap: fix error pointer free in zswap_cpu_comp_prepare()

by Pavel Butsykin

crypto_alloc_acomp_node() may return ERR_PTR(), but the fail path checks only for NULL and can pass an error pointer to crypto_free_acomp(). Use IS_ERR_OR_NULL() to only free valid acomp instances. Fixes: 779b9955f643 ("mm: zswap: move allocations during CPU init outside the lock") Cc: stable(a)vger.kernel.org Signed-off-by: Pavel Butsykin <pbutsykin(a)cloudlinux.com> --- mm/zswap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/zswap.c b/mm/zswap.c index 5d0f8b13a958..ac9b7a60736b 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -787,7 +787,7 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node *node) return 0; fail: - if (acomp) + if (!IS_ERR_OR_NULL(acomp)) crypto_free_acomp(acomp); kfree(buffer); return ret; -- 2.52.0

2 days, 14 hours

[PATCH] edac: fix a resource leak in i3200_probe1()

by Haoxiang Li

If edac_mc_alloc() fails, also unmap the window. Add a goto to do so. Found by code review and compiled on ubuntu 20.04 Fixes: dd8ef1db87a4 ("edac: i3200 memory controller driver") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/edac/i3200_edac.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/edac/i3200_edac.c b/drivers/edac/i3200_edac.c index afccdebf5ac1..fd5dc33c406f 100644 --- a/drivers/edac/i3200_edac.c +++ b/drivers/edac/i3200_edac.c @@ -360,8 +360,10 @@ static int i3200_probe1(struct pci_dev *pdev, int dev_idx) layers[1].is_virt_csrow = false; mci = edac_mc_alloc(0, ARRAY_SIZE(layers), layers, sizeof(struct i3200_priv)); - if (!mci) - return -ENOMEM; + if (!mci) { + rc = -ENOMEM; + goto fail; + } edac_dbg(3, "MC: init mci\n"); -- 2.25.1

2 days, 15 hours

Re: [PATCH] MIPS: Loongson64: dts: fix phy-related definition of LS7A GMAC

by Jiaxun Yang

On Fri, 2 Jan 2026, at 3:52 PM, Icenowy Zheng wrote: > Currently the LS7A GMAC device tree node lacks a proper phy-handle > property pointing to the PHY node. > > In addition, the phy-mode property specifies "rgmii" without any > internal delay information, which means the board trace needs to add 2ns > delay to the RGMII data lines; but that isn't known to happen on any > Loongson board. The ACPI-based initialization codepath, which is used on > LoongArch-based 3A5000 + 7A1000 hardwares, specifies "rgmii-id" phy > mode, which should be the one we are using. > > Add the lacking phy-handle property and set proper phy-mode. > > Tested on a LS3A4000_7A1000_NUC_BOARD_V2.1 board with YT8521S PHY. > > Signed-off-by: Icenowy Zheng <zhengxingda(a)iscas.ac.cn> Good catch! This with fine with realtek phy chips but YT8521S seems to be picky. Reviewed-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> Also maybe: Cc: stable(a)vger.kernel.org Given those boards rely on built-in DT. Thanks > --- > arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi > b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi > index ee71045883e7e..6dee85909f5a6 100644 > --- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi > +++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi > @@ -199,7 +199,8 @@ gmac@3,0 { > <13 IRQ_TYPE_LEVEL_HIGH>; > interrupt-names = "macirq", "eth_lpi"; > interrupt-parent = <&pic>; > - phy-mode = "rgmii"; > + phy-mode = "rgmii-id"; > + phy-handle = <&phy0>; > mdio { > #address-cells = <1>; > #size-cells = <0>; > @@ -222,7 +223,8 @@ gmac@3,1 { > <15 IRQ_TYPE_LEVEL_HIGH>; > interrupt-names = "macirq", "eth_lpi"; > interrupt-parent = <&pic>; > - phy-mode = "rgmii"; > + phy-mode = "rgmii-id"; > + phy-handle = <&phy1>; > mdio { > #address-cells = <1>; > #size-cells = <0>; > -- > 2.52.0 -- - Jiaxun

2 days, 16 hours

[PATCH] PCI: j721e: Add config guards for Cadence Host and Endpoint library APIs

by Siddharth Vadapalli

Commit under Fixes enabled loadable module support for the driver under the assumption that it shall be the sole user of the Cadence Host and Endpoint library APIs. This assumption guarantees that we won't end up in a case where the driver is built-in and the library support is built as a loadable module. With the introduction of [1], this assumption is no longer valid. The SG2042 driver could be built as a loadable module, implying that the Cadence Host library is also selected as a loadable module. However, the pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=y due to which the Cadence Endpoint library is built-in. Despite the library drivers being built as specified by their respective consumers, since the 'pci-j721e.c' driver has references to the Cadence Host library APIs as well, we run into a build error as reported at [0]. Fix this by adding config guards as a temporary workaround. The proper fix is to split the 'pci-j721e.c' driver into independent Host and Endpoint drivers as aligned at [2]. Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/ Cc: <stable(a)vger.kernel.org> [0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/ [1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") [2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fastmail… Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- drivers/pci/controller/cadence/pci-j721e.c | 43 +++++++++++++--------- 1 file changed, 26 insertions(+), 17 deletions(-) diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c index 5bc5ab20aa6d..67c5e02afccf 100644 --- a/drivers/pci/controller/cadence/pci-j721e.c +++ b/drivers/pci/controller/cadence/pci-j721e.c @@ -628,10 +628,12 @@ static int j721e_pcie_probe(struct platform_device *pdev) gpiod_set_value_cansleep(gpiod, 1); } - ret = cdns_pcie_host_setup(rc); - if (ret < 0) { - clk_disable_unprepare(pcie->refclk); - goto err_pcie_setup; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret = cdns_pcie_host_setup(rc); + if (ret < 0) { + clk_disable_unprepare(pcie->refclk); + goto err_pcie_setup; + } } break; @@ -642,9 +644,11 @@ static int j721e_pcie_probe(struct platform_device *pdev) goto err_get_sync; } - ret = cdns_pcie_ep_setup(ep); - if (ret < 0) - goto err_pcie_setup; + if (IS_ENABLED(CONFIG_PCI_J721E_EP)) { + ret = cdns_pcie_ep_setup(ep); + if (ret < 0) + goto err_pcie_setup; + } break; } @@ -669,10 +673,11 @@ static void j721e_pcie_remove(struct platform_device *pdev) struct cdns_pcie_ep *ep; struct cdns_pcie_rc *rc; - if (pcie->mode == PCI_MODE_RC) { + if (IS_ENABLED(CONFIG_PCI_J721E_HOST) && + pcie->mode == PCI_MODE_RC) { rc = container_of(cdns_pcie, struct cdns_pcie_rc, pcie); cdns_pcie_host_disable(rc); - } else { + } else if (IS_ENABLED(CONFIG_PCI_J721E_EP)) { ep = container_of(cdns_pcie, struct cdns_pcie_ep, pcie); cdns_pcie_ep_disable(ep); } @@ -739,10 +744,12 @@ static int j721e_pcie_resume_noirq(struct device *dev) gpiod_set_value_cansleep(pcie->reset_gpio, 1); } - ret = cdns_pcie_host_link_setup(rc); - if (ret < 0) { - clk_disable_unprepare(pcie->refclk); - return ret; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret = cdns_pcie_host_link_setup(rc); + if (ret < 0) { + clk_disable_unprepare(pcie->refclk); + return ret; + } } /* @@ -752,10 +759,12 @@ static int j721e_pcie_resume_noirq(struct device *dev) for (enum cdns_pcie_rp_bar bar = RP_BAR0; bar <= RP_NO_BAR; bar++) rc->avail_ib_bar[bar] = true; - ret = cdns_pcie_host_init(rc); - if (ret) { - clk_disable_unprepare(pcie->refclk); - return ret; + if (IS_ENABLED(CONFIG_PCI_J721E_HOST)) { + ret = cdns_pcie_host_init(rc); + if (ret) { + clk_disable_unprepare(pcie->refclk); + return ret; + } } } -- 2.51.1

2 days, 16 hours

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.18-stable tree

by Hal Feng

> On 19.12.25 20:31, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.18-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.18 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. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit f922a9b37397e7db449e3fa61c33c542ad783f87 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index cd1816a12bb99..dc11b62399ad5 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

2 days, 16 hours

[PATCH net] bnxt_en: Fix NULL pointer crash in bnxt_ptp_enable during error cleanup

by Breno Leitao

When bnxt_init_one() fails during initialization (e.g., bnxt_init_int_mode returns -ENODEV), the error path calls bnxt_free_hwrm_resources() which destroys the DMA pool and sets bp->hwrm_dma_pool to NULL. Subsequently, bnxt_ptp_clear() is called, which invokes ptp_clock_unregister(). Since commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events"), ptp_clock_unregister() now calls ptp_disable_all_events(), which in turn invokes the driver's .enable() callback (bnxt_ptp_enable()) to disable PTP events before completing the unregistration. bnxt_ptp_enable() attempts to send HWRM commands via bnxt_ptp_cfg_pin() and bnxt_ptp_cfg_event(), both of which call hwrm_req_init(). This function tries to allocate from bp->hwrm_dma_pool, causing a NULL pointer dereference: bnxt_en 0000:01:00.0 (unnamed net_device) (uninitialized): bnxt_init_int_mode err: ffffffed KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] Call Trace: __hwrm_req_init (drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c:72) bnxt_ptp_enable (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:323 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:517) ptp_disable_all_events (drivers/ptp/ptp_chardev.c:66) ptp_clock_unregister (drivers/ptp/ptp_clock.c:518) bnxt_ptp_clear (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:1134) bnxt_init_one (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16889) Lines are against commit f8f9c1f4d0c7 ("Linux 6.19-rc3") Fix this by checking if bp->hwrm_dma_pool is NULL at the start of bnxt_ptp_enable(). During error/cleanup paths when HWRM resources have been freed, return success without attempting to send commands since the hardware is being torn down anyway. During normal operation, the DMA pool is always valid so PTP functionality is unaffected. Signed-off-by: Breno Leitao <leitao(a)debian.org> Fixes: a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") Cc: stable(a)vger.kernel.org --- drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c index a8a74f07bb54..a749bbfa398e 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c @@ -482,6 +482,13 @@ static int bnxt_ptp_enable(struct ptp_clock_info *ptp_info, int pin_id; int rc; + /* Return success if HWRM resources are not available. + * This can happen during error/cleanup paths when DMA pool has been + * freed. + */ + if (!bp->hwrm_dma_pool) + return 0; + switch (rq->type) { case PTP_CLK_REQ_EXTTS: /* Configure an External PPS IN */ --- base-commit: 80380f6ce46f38a0d1200caade2f03de4b6c1d27 change-id: 20251231-bnxt-c54d317d8bfe Best regards, -- Breno Leitao <leitao(a)debian.org>

2 days, 16 hours

Complete your payment now

by linux-stable-mirror＠lists.linaro.org

Hi there! I regret to inform you about some sad news for you. Approximately a month or two ago I have succeeded to gain a total access to all your devices utilized for browsing internet. Moving forward, I have started observing your internet activities on continuous basis. Go ahead and take a look at the sequence of events provided below for your reference: Initially I bought an exclusive access from hackers to a long list of email accounts (in today's world, that is really a common thing, which can arranged via internet). Evidently, it wasn't hard for me to proceed with logging in your email account linux-stable- mirror(a)lists.linaro.org. Within the same week, I moved on with installing a Trojan virus in Operating Systems for all devices that you use to login to email. Frankly speaking, it wasn't a challenging task for me at all (since you were kind enough to click some of the links in your inbox emails before). Yeah, geniuses are among us. Because of this Trojan I am able to gain access to entire set of controllers in devices (e.g., your video camera, keyboard, microphone and others). As result, I effortlessly downloaded all data, as well as photos, web browsing history and other types of data to my servers. Moreover, I have access to all social networks accounts that you regularly use, including emails, including chat history, messengers, contacts list etc. My unique virus is incessantly refreshing its signatures (due to control by a driver), and hence remains undetected by any type of antiviruses. Hence, I guess by now you can already see the reason why I always remained undetected until this very letter... During the process of compilation of all the materials associated with you, I also noticed that you are a huge supporter and regular user of websites hosting nasty adult content. Turns out to be, you really love visiting porn websites, as well as watching exciting videos and enduring unforgettable pleasures. As a matter of fact, I was not able to withstand the temptation, but to record certain nasty solo action with you in main role, and later produced a few videos exposing your masturbation and cumming scenes. If until now you don't believe me, all I need is one-two mouse clicks to make all those videos with everyone you know, including your friends, colleagues, relatives and others. Moreover, I am able to upload all that video content online for everyone to see. I sincerely think, you certainly would not wish such incidents to take place, in view of the lustful things demonstrated in your commonly watched videos, (you absolutely know what I mean by that) it will cause a huge adversity for you. There is still a solution to this matter, and here is what you need to do: You make a transaction of 950 USD to my account (an equivalent in bitcoins, which recorded depending on the exchange rate at the date of funds transfer), hence upon receiving the transfer, I will immediately get rid of all those lustful videos without delay. After that we can make it look like there was nothing happening beforehand. Additionally, I can confirm that all the Trojan software is going to be disabled and erased from all devices that you use. You have nothing to worry about, because I keep my word at all times. That is indeed a beneficial bargain that comes with a relatively reduced price, taking into consideration that your profile and traffic were under close monitoring during a long time frame. If you are still unclear regarding how to buy and perform transactions with bitcoins - everything is available online. The amount: 950 USD The Address Part 1: 3D42CBNFwifmjT4rH The Address Part 2: nW3BmvrFwdUNpgi1Q So, you have to manually copy + paste Part1 and Part2 in one string made of 34 characters with no space between the parts that start with "3" and end with "Q" is the actually address where you should send the money to. All you have is 48 hours and the countdown begins once this email is opened (in other words 2 days). The following list includes things you should remember and avoid doing: - There's no point to try replying my email (since this email and return address were created inside your inbox). - There's no point in calling police or any other types of security services either. Furthermore, don't you dare sharing this info with any of your friends. If I discover that (taking into consideration my skills, it will be really simple, because I control all your systems and continuously monitor them) your nasty clip will be shared with public straight away. - There's no point in looking for me too - it won't result in any success. Transactions with cryptocurrency are completely anonymous and untraceable. - There's no point in reinstalling your OS on devices or trying to throw them away. That won't solve the issue, since all clips with you as main character are already uploaded on remote servers. Things that may be concerning you: - That funds transfer won't be delivered to me. Breathe out, I can track down everything right away, so once funds transfer is finished, I will know for sure, since I interminably track down all activities done by you (my Trojan virus controls all processes remotely, just as TeamViewer). - That your videos will be distributed, even though you have completed money transfer to my wallet. Trust me, it is worthless for me to still bother you after money transfer is successful. Moreover, if that was ever part of my plan, I would do make it happen way earlier! We are going to approach and deal with it in a clear manner! In conclusion, I'd like to recommend one more thing... after this you need to make certain you don't get involved in similar kind of unpleasant events anymore! My recommendation - ensure all your passwords are replaced with new ones on a regular basis.

2 days, 23 hours

FAILED: patch "[PATCH] NFSD: NFSv4 file creation neglects setting ACL" 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 913f7cf77bf14c13cfea70e89bcb6d0b22239562 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025122941-civic-revered-b250@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 913f7cf77bf14c13cfea70e89bcb6d0b22239562 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Tue, 18 Nov 2025 19:51:19 -0500 Subject: [PATCH] NFSD: NFSv4 file creation neglects setting ACL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given". The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode. Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL. Reported-by: Aurélien Couderc <aurelien.couderc2002(a)gmail.com> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs") Cc: Roland Mainz <roland.mainz(a)nrubsig.org> Cc: stable(a)vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h index fa46f8b5f132..1dd3ae3ceb3a 100644 --- a/fs/nfsd/vfs.h +++ b/fs/nfsd/vfs.h @@ -67,7 +67,8 @@ static inline bool nfsd_attrs_valid(struct nfsd_attrs *attrs) struct iattr *iap = attrs->na_iattr; return (iap->ia_valid || (attrs->na_seclabel && - attrs->na_seclabel->len)); + attrs->na_seclabel->len) || + attrs->na_pacl || attrs->na_dpacl); } __be32 nfserrno (int errno);

3 days, 3 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror