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

[PATCH net] net/packet: fix a race in packet_set_ring() and packet_notifier()

by Willem de Bruijn

From: Willem de Bruijn <willemb(a)google.com> When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()"). There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken. The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Quang Le <quanglex97(a)gmail.com> Signed-off-by: Willem de Bruijn <willemb(a)google.com> --- net/packet/af_packet.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index bc438d0d96a7..a7017d7f0927 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -4573,10 +4573,10 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, spin_lock(&po->bind_lock); was_running = packet_sock_flag(po, PACKET_SOCK_RUNNING); num = po->num; - if (was_running) { - WRITE_ONCE(po->num, 0); + WRITE_ONCE(po->num, 0); + if (was_running) __unregister_prot_hook(sk, false); - } + spin_unlock(&po->bind_lock); synchronize_net(); @@ -4608,10 +4608,10 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, mutex_unlock(&po->pg_vec_lock); spin_lock(&po->bind_lock); - if (was_running) { - WRITE_ONCE(po->num, num); + WRITE_ONCE(po->num, num); + if (was_running) register_prot_hook(sk); - } + spin_unlock(&po->bind_lock); if (pg_vec && (po->tp_version > TPACKET_V2)) { /* Because we don't support block-based V3 on tx-ring */ -- 2.50.1.565.gc32cd1483b-goog

3 months, 3 weeks

1
1
0 0

[PATCH v3] x86/cpu/intel: Fix the constant_tsc model check for Pentium 4s

by Suchit Karunakaran

The logic to synthesize constant_tsc for Pentium 4s (Family 15) is wrong. Since INTEL_P4_PRESCOTT is numerically greater than INTEL_P4_WILLAMETTE, the logic always results in false and never sets X86_FEATURE_CONSTANT_TSC for any Pentium 4 model. The error was introduced while replacing the x86_model check with a VFM one. The original check was as follows: if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); Fix the logic to cover all Pentium 4 models from Prescott (model 3) to Cedarmill (model 6) which is the last model released in Family 15. Fixes: fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks") Cc: <stable(a)vger.kernel.org> # v6.15 Signed-off-by: Suchit Karunakaran <suchitkarunakaran(a)gmail.com> --- Changes since v2: - Improve commit message Changes since v1: - Fix incorrect logic arch/x86/kernel/cpu/intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 076eaa41b8c8..6f5bd5dbc249 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -262,7 +262,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) if (c->x86_power & (1 << 8)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC); - } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_WILLAMETTE) || + } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_CEDARMILL) || (c->x86_vfm >= INTEL_CORE_YONAH && c->x86_vfm <= INTEL_IVYBRIDGE)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); } -- 2.50.1

3 months, 3 weeks

4
13
0 0

[PATCH 0/3] dmaengine: ti: k3-udma: Fix/improve the completion helper

by Miquel Raynal

While working on a BeaglePlay with the UART controller and making it use DMA, I figured the DMA controller completion helper was clearly misbehaving. On one side, with slow devices like a UART controller, the helper uses an unusual polling delay of 1s. On the other side, the helper can also perform 0us sleeps which means the driver does not sleep at all in some situations and keeps the CPU busy waiting. Finally, while I was digging into these issues, it felt like the helper was a bit too complex and could be simplified, which is what I did in patch 3. I initially worked on v6.7.x which did not had the spinlocks, I hope I didn't got them wrong. I also tested this with v6.17-rc7. Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- Miquel Raynal (3): dmaengine: ti: k3-udma: Reduce completion polling delay dmaengine: ti: k3-udma: Ensure a minimum polling delay dmaengine: ti: k3-udma: Simplify the completion worker drivers/dma/ti/k3-udma.c | 85 ++++++++++++++++++++---------------------------- 1 file changed, 36 insertions(+), 49 deletions(-) --- base-commit: b59220b9fa2c3da4295d71913146cd64b869fcf9 change-id: 20250731-ti-dma-timeout-1c64868b5baf Best regards, -- Miquel Raynal <miquel.raynal(a)bootlin.com>

3 months, 3 weeks

1
2
0 0

[PATCH 1/1] userfaultfd: fix a crash when UFFDIO_MOVE handles a THP hole

by Suren Baghdasaryan

When UFFDIO_MOVE is used with UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES and it encounters a non-present THP, it fails to properly recognize an unmapped hole and tries to access a non-existent folio, resulting in a crash. Add a check to skip non-present THPs. Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Reported-by: syzbot+b446dbe27035ef6bd6c2(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68794b5c.a70a0220.693ce.0050.GAE@google.com/ Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org --- mm/userfaultfd.c | 38 +++++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index cbed91b09640..60be8080ddd0 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -1818,27 +1818,35 @@ ssize_t move_pages(struct userfaultfd_ctx *ctx, unsigned long dst_start, ptl = pmd_trans_huge_lock(src_pmd, src_vma); if (ptl) { - /* Check if we can move the pmd without splitting it. */ - if (move_splits_huge_pmd(dst_addr, src_addr, src_start + len) || - !pmd_none(dst_pmdval)) { - struct folio *folio = pmd_folio(*src_pmd); + if (pmd_present(*src_pmd) || is_pmd_migration_entry(*src_pmd)) { + /* Check if we can move the pmd without splitting it. */ + if (move_splits_huge_pmd(dst_addr, src_addr, src_start + len) || + !pmd_none(dst_pmdval)) { + if (pmd_present(*src_pmd)) { + struct folio *folio = pmd_folio(*src_pmd); + + if (!folio || (!is_huge_zero_folio(folio) && + !PageAnonExclusive(&folio->page))) { + spin_unlock(ptl); + err = -EBUSY; + break; + } + } - if (!folio || (!is_huge_zero_folio(folio) && - !PageAnonExclusive(&folio->page))) { spin_unlock(ptl); - err = -EBUSY; - break; + split_huge_pmd(src_vma, src_pmd, src_addr); + /* The folio will be split by move_pages_pte() */ + continue; } + err = move_pages_huge_pmd(mm, dst_pmd, src_pmd, + dst_pmdval, dst_vma, src_vma, + dst_addr, src_addr); + } else { + /* nothing to do to move a hole */ spin_unlock(ptl); - split_huge_pmd(src_vma, src_pmd, src_addr); - /* The folio will be split by move_pages_pte() */ - continue; + err = 0; } - - err = move_pages_huge_pmd(mm, dst_pmd, src_pmd, - dst_pmdval, dst_vma, src_vma, - dst_addr, src_addr); step_size = HPAGE_PMD_SIZE; } else { if (pmd_none(*src_pmd)) { base-commit: 01da54f10fddf3b01c5a3b80f6b16bbad390c302 -- 2.50.1.552.g942d659e1b-goog

3 months, 3 weeks

4
5
0 0

Need to Know About Details of NRF Retail's Big Show

by Alyssa Campbell

Hi, Hope today's treating you well! I wanted to know if you would be interested in purchasing the attendees list of NRF 2025 Retail's Big Show ? Attendees count: 25,000 Leads Contact Information: Company Name, Web URL, Contact Name, Title, Direct Email, Phone Number, Mailing Address, Industry, Employee Size, Annual Sales. If this ignites your interest please let me know, I'd be glad to offer you the pricing options, for your assessment. I'm grateful for your quick reply. Can't wait to hear from you. Best Alyssa Campbell Demand Generation Manager B2B Connect, Inc. Please respond with a 'REMOVE' if you don't wish to receive further emails

3 months, 3 weeks

1
0
0 0

[PATCH] serial: sc16is7xx: fix bug in flow control levels init

by Hugo Villeneuve

From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> When trying to set MCR[2], XON1 is incorrectly accessed instead. And when writing to the TCR register to configure flow control levels, we are incorrectly writing to the MSR register. The default value of $00 is then used for TCR, which means that selectable trigger levels in FCR are used in place of TCR. TCR/TLR access requires EFR[4] (enable enhanced functions) and MCR[2] to be set. EFR[4] is already set in probe(). MCR access requires LCR[7] to be zero. Since LCR is set to $BF when trying to set MCR[2], XON1 is incorrectly accessed instead because MCR shares the same address space as XON1. Since MCR[2] is unmodified and still zero, when writing to TCR we are in fact writing to MSR because TCR/TLR registers share the same address space as MSR/SPR. Fix by first removing useless reconfiguration of EFR[4] (enable enhanced functions), as it is already enabled in sc16is7xx_probe() since commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed"). Now LCR is $00, which means that MCR access is enabled. Also remove regcache_cache_bypass() calls since we no longer access the enhanced registers set, and TCR is already declared as volatile (in fact by declaring MSR as volatile, which shares the same address). Finally disable access to TCR/TLR registers after modifying them by clearing MCR[2]. Note: the comment about "... and internal clock div" is wrong and can be ignored/removed as access to internal clock div registers (DLL/DLH) is permitted only when LCR[7] is logic 1, not when enhanced features is enabled. And DLL/DLH access is not needed in sc16is7xx_startup(). Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable(a)vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> --- drivers/tty/serial/sc16is7xx.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 5ea8aadb6e69c..9056cb82456f1 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -1177,17 +1177,6 @@ static int sc16is7xx_startup(struct uart_port *port) sc16is7xx_port_write(port, SC16IS7XX_FCR_REG, SC16IS7XX_FCR_FIFO_BIT); - /* Enable EFR */ - sc16is7xx_port_write(port, SC16IS7XX_LCR_REG, - SC16IS7XX_LCR_CONF_MODE_B); - - regcache_cache_bypass(one->regmap, true); - - /* Enable write access to enhanced features and internal clock div */ - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - /* Enable TCR/TLR */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_TCRTLR_BIT, @@ -1199,7 +1188,8 @@ static int sc16is7xx_startup(struct uart_port *port) SC16IS7XX_TCR_RX_RESUME(24) | SC16IS7XX_TCR_RX_HALT(48)); - regcache_cache_bypass(one->regmap, false); + /* Disable TCR/TLR access */ + sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_TCRTLR_BIT, 0); /* Now, initialize the UART */ sc16is7xx_port_write(port, SC16IS7XX_LCR_REG, SC16IS7XX_LCR_WORD_LEN_8); base-commit: 260f6f4fda93c8485c8037865c941b42b9cba5d2 -- 2.39.5

3 months, 3 weeks

1
0
0 0

[PATCH] PCI: vmd: Assign VMD IRQ domain before enumeration

by Artur Piechocki

From: Nirmal Patel <nirmal.patel(a)linux.intel.com> During the boot process all the PCI devices are assigned default PCI-MSI IRQ domain including VMD endpoint devices. If interrupt-remapping is enabled by IOMMU, the PCI devices except VMD get new INTEL-IR-MSI IRQ domain. And VMD is supposed to create and assign a separate VMD-MSI IRQ domain for its child devices in order to support MSI-X remapping capabilities. Now when MSI-X remapping in VMD is disabled in order to improve performance, VMD skips VMD-MSI IRQ domain assignment process to its child devices. Thus the devices behind VMD get default PCI-MSI IRQ domain instead of INTEL-IR-MSI IRQ domain when VMD creates root bus and configures child devices. As a result host OS fails to boot and DMAR errors were observed when interrupt remapping was enabled on Intel Icelake CPUs. For instance: DMAR: DRHD: handling fault status reg 2 DMAR: [INTR-REMAP] Request device [0xe2:0x00.0] fault index 0xa00 [fault reason 0x25] Blocked a compatibility format interrupt request To fix this issue, dev_msi_info struct in dev struct maintains correct value of IRQ domain. VMD will use this information to assign proper IRQ domain to its child devices when it doesn't create a separate IRQ domain. Link: https://lore.kernel.org/r/20220511095707.25403-2-nirmal.patel@linux.intel.c… Cc: stable(a)vger.kernel.org Signed-off-by: Nirmal Patel <nirmal.patel(a)linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Signed-off-by: Artur Piechocki <artur.piechocki(a)open-e.com> --- drivers/pci/controller/vmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index eb05cceab964..5015adc04d19 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -853,6 +853,9 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) vmd_attach_resources(vmd); if (vmd->irq_domain) dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain); + else + dev_set_msi_domain(&vmd->bus->dev, + dev_get_msi_domain(&vmd->dev->dev)); vmd_acpi_begin(); -- 2.50.1

3 months, 3 weeks

1
0
0 0

Re: Patch "Revert "cgroup_freezer: cgroup_freezing: Check if not frozen"" has been added to the 6.15-stable tree

by Chen Ridong

> This is a note to let you know that I've just added the patch titled > > Revert "cgroup_freezer: cgroup_freezing: Check if not frozen" > > to the 6.15-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: > revert-cgroup_freezer-cgroup_freezing-check-if-not-f.patch > and it can be found in the queue-6.15 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. > The patch ("sched,freezer: Remove unnecessary warning in __thaw_task") should also be merged to prevent triggering another warning in __thaw_task(). Best regards, Ridong > > > commit ee09694849a570cbc32015b5329b7c2f3f778748 > Author: Chen Ridong <chenridong(a)huawei.com> > Date: Thu Jul 17 08:55:50 2025 +0000 > > Revert "cgroup_freezer: cgroup_freezing: Check if not frozen" > > [ Upstream commit 14a67b42cb6f3ab66f41603c062c5056d32ea7dd ] > > This reverts commit cff5f49d433fcd0063c8be7dd08fa5bf190c6c37. > > Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not > frozen") modified the cgroup_freezing() logic to verify that the FROZEN > flag is not set, affecting the return value of the freezing() function, > in order to address a warning in __thaw_task. > > A race condition exists that may allow tasks to escape being frozen. The > following scenario demonstrates this issue: > > CPU 0 (get_signal path) CPU 1 (freezer.state reader) > try_to_freeze read freezer.state > __refrigerator freezer_read > update_if_frozen > WRITE_ONCE(current->__state, TASK_FROZEN); > ... > /* Task is now marked frozen */ > /* frozen(task) == true */ > /* Assuming other tasks are frozen */ > freezer->state |= CGROUP_FROZEN; > /* freezing(current) returns false */ > /* because cgroup is frozen (not freezing) */ > break out > __set_current_state(TASK_RUNNING); > /* Bug: Task resumes running when it should remain frozen */ > > The existing !frozen(p) check in __thaw_task makes the > WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables > reverting the commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check > if not frozen") to resolve the issue. > > The warning has been removed in the previous patch. This patch revert the > commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not > frozen") to complete the fix. > > Fixes: cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") > Reported-by: Zhong Jiawei<zhongjiawei1(a)huawei.com> > Signed-off-by: Chen Ridong <chenridong(a)huawei.com> > Signed-off-by: Tejun Heo <tj(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/kernel/cgroup/legacy_freezer.c b/kernel/cgroup/legacy_freezer.c index 507b8f19a262e..dd9417425d929 100644 > --- a/kernel/cgroup/legacy_freezer.c > +++ b/kernel/cgroup/legacy_freezer.c > @@ -66,15 +66,9 @@ static struct freezer *parent_freezer(struct freezer *freezer) bool cgroup_freezing(struct task_struct *task) { > bool ret; > - unsigned int state; > > rcu_read_lock(); > - /* Check if the cgroup is still FREEZING, but not FROZEN. The extra > - * !FROZEN check is required, because the FREEZING bit is not cleared > - * when the state FROZEN is reached. > - */ > - state = task_freezer(task)->state; > - ret = (state & CGROUP_FREEZING) && !(state & CGROUP_FROZEN); > + ret = task_freezer(task)->state & CGROUP_FREEZING; > rcu_read_unlock(); > > return ret; >

3 months, 3 weeks

3
23
0 0

[PATCH V3] Bluetooth: bfusb: Fix use-after-free and memory leak in device lifecycle

by Salah Triki

The driver stores a reference to the `usb_device` structure (`udev`) in its private data (`data->udev`), which can persist beyond the immediate context of the `bfusb_probe()` function. Without proper reference count management, this can lead to two issues: 1. A `use-after-free` scenario if `udev` is accessed after its main reference count drops to zero (e.g., if the device is disconnected and the `data` structure is still active). 2. A `memory leak` if `udev`'s reference count is not properly decremented during driver disconnect, preventing the `usb_device` object from being freed. To correctly manage the `udev` lifetime, explicitly increment its reference count with `usb_get_dev(udev)` when storing it in the driver's private data. Correspondingly, decrement the reference count with `usb_put_dev(data->udev)` in the `bfusb_disconnect()` callback. This ensures `udev` remains valid while referenced by the driver's private data and is properly released when no longer needed. Signed-off-by: Salah Triki <salah.triki(a)gmail.com> Fixes: 9c724357f432d ("[Bluetooth] Code cleanup of the drivers source code") Cc: stable(a)vger.kernel.org Cc: Marcel Holtmann <marcel(a)holtmann.org> Cc: Luiz Augusto von Dentz <luiz.dentz(a)gmail.com> Cc: linux-bluetooth(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org --- Changes in v3: - Add tag Cc Changes in v2: - Add tags Fixes and Cc drivers/bluetooth/bfusb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c index 8df310983bf6..f966bd8361b0 100644 --- a/drivers/bluetooth/bfusb.c +++ b/drivers/bluetooth/bfusb.c @@ -622,7 +622,7 @@ static int bfusb_probe(struct usb_interface *intf, const struct usb_device_id *i if (!data) return -ENOMEM; - data->udev = udev; + data->udev = usb_get_dev(udev); data->bulk_in_ep = bulk_in_ep->desc.bEndpointAddress; data->bulk_out_ep = bulk_out_ep->desc.bEndpointAddress; data->bulk_pkt_size = le16_to_cpu(bulk_out_ep->desc.wMaxPacketSize); @@ -701,6 +701,8 @@ static void bfusb_disconnect(struct usb_interface *intf) usb_set_intfdata(intf, NULL); + usb_put_dev(data->udev); + bfusb_close(hdev); hci_unregister_dev(hdev); -- 2.43.0

3 months, 3 weeks

2
3
0 0

[PATCH] iomap: Fix broken data integrity guarantees for O_SYNC writes

by Jan Kara

Commit d279c80e0bac ("iomap: inline iomap_dio_bio_opflags()") has broken the logic in iomap_dio_bio_iter() in a way that when the device does support FUA (or has no writeback cache) and the direct IO happens to freshly allocated or unwritten extents, we will *not* issue fsync after completing direct IO O_SYNC / O_DSYNC write because the IOMAP_DIO_WRITE_THROUGH flag stays mistakenly set. Fix the problem by clearing IOMAP_DIO_WRITE_THROUGH whenever we do not perform FUA write as it was originally intended. CC: John Garry <john.g.garry(a)oracle.com> CC: "Ritesh Harjani (IBM)" <ritesh.list(a)gmail.com> Fixes: d279c80e0bac ("iomap: inline iomap_dio_bio_opflags()") CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/iomap/direct-io.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) BTW, I've spotted this because some performance tests got suspiciously fast on recent kernels :) Sadly no easy improvement to cherry-pick for me to fix customer issue I'm chasing... diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 6f25d4cfea9f..b84f6af2eb4c 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -363,14 +363,14 @@ static int iomap_dio_bio_iter(struct iomap_iter *iter, struct iomap_dio *dio) if (iomap->flags & IOMAP_F_SHARED) dio->flags |= IOMAP_DIO_COW; - if (iomap->flags & IOMAP_F_NEW) { + if (iomap->flags & IOMAP_F_NEW) need_zeroout = true; - } else if (iomap->type == IOMAP_MAPPED) { - if (iomap_dio_can_use_fua(iomap, dio)) - bio_opf |= REQ_FUA; - else - dio->flags &= ~IOMAP_DIO_WRITE_THROUGH; - } + else if (iomap->type == IOMAP_MAPPED && + iomap_dio_can_use_fua(iomap, dio)) + bio_opf |= REQ_FUA; + + if (!(bio_opf & REQ_FUA)) + dio->flags &= ~IOMAP_DIO_WRITE_THROUGH; /* * We can only do deferred completion for pure overwrites that -- 2.43.0

3 months, 3 weeks

6
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror