On Tue, Jun 11, 2024 at 02:56:59PM +0900, Damien Le Moal wrote:
> > + if (!bsize)
> > + bsize = loop_default_blocksize(lo, inode->i_sb->s_bdev);
>
> If bsize is specified and there is a backing dev used with direct IO, should
> it
> be checked that bsize is a multiple of bdev_logical_
On Tue, Jun 11, 2024 at 02:53:19PM +0900, Damien Le Moal wrote:
> > + /* reset the block size to the default */
> > + lim = queue_limits_start_update(lo->lo_queue);
> > + lim.logical_block_size = 512;
>
> Nit: SECTOR_SIZE ? maybe ?
Yes. I was following the existing code, but SECTOR_SIZE is
On Tue, Jun 11, 2024 at 07:52:39AM +0200, Christoph Hellwig wrote:
> > Maybe we should clear the other zone related limits here ? If the drive is
> > reformatted/converted from SMR to CMR (FORMAT WITH PRESET), the other zone
> > limits may be set already, no ?
>
> b
On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote:
> > - if (lim->zoned)
> > + if (sdkp->device->type == TYPE_ZBC)
>
> Nit: use sd_is_zoned() here ?
Yes.
> > - if (!sd_is_zoned(sdkp))
> > + if (!sd_is_zoned(sdkp)) {
> > + lim->zoned = false;
>
> Maybe we should cl
Move the bounce field into the flags field to reclaim a little bit of
space.
Signed-off-by: Christoph Hellwig
---
block/blk-settings.c| 1 -
block/blk.h | 2 +-
drivers/scsi/scsi_lib.c | 2 +-
include/linux/blkdev.h | 6 --
4 files changed, 6 insertions(+), 5 deletions
Move the pci_p2pdma flag into the queue_limits feature field so that it
can be set atomically and all I/O is frozen when changing the flag.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c | 1 -
drivers/nvme/host/core.c | 8 +++-
include/linux/blkdev.h | 7 ---
3 files
Move the skip_tagset_quiesce flag into the queue_limits feature field so
that it can be set atomically and all I/O is frozen when changing the
flag.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c | 1 -
drivers/nvme/host/core.c | 8 +---
include/linux/blkdev.h | 6 --
3
Move the zone_resetall flag into the queue_limits feature field so that
it can be set atomically and all I/O is frozen when changing the flag.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c | 1 -
drivers/block/null_blk/zoned.c | 3 +--
drivers/block/ublk_drv.c | 4
Move the boolean zoned field into the flags field to reclaim a little
bit of space.
Signed-off-by: Christoph Hellwig
---
block/blk-settings.c | 5 ++---
drivers/block/null_blk/zoned.c | 2 +-
drivers/block/ublk_drv.c | 2 +-
drivers/block/virtio_blk.c | 5 +++--
drivers
Move the dax flag into the queue_limits feature field so that it
can be set atomically and all I/O is frozen when changing the flag.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c | 1 -
drivers/md/dm-table.c| 4 ++--
drivers/nvdimm/pmem.c| 7 ++-
drivers
underlying devices.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 5 ++--
block/blk-mq-debugfs.c| 1 -
block/blk-mq.c| 31 +++-
block/blk-settings.c | 10 ---
block/blk-sysfs.c | 4 +--
drivers/md/dm-table.c
underlying devices.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c| 1 -
block/blk-mq.c| 2 +-
block/blk-settings.c | 9 +
drivers/block/brd.c | 4 ++--
drivers/md/dm-table.c | 16 ++--
drivers/md/md.c
Move the synchronous flag into the queue_limits feature field so that it
can be set atomically and all I/O is frozen when changing the flag.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c| 1 -
drivers/block/brd.c | 2 +-
drivers/block/zram/zram_drv.c | 4
devices.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c | 1 -
block/blk-sysfs.c | 29 +
drivers/block/drbd/drbd_main.c | 5 ++---
drivers/block/rbd.c| 9 +++--
drivers/block/zram/zram_drv.c | 2 +-
drivers/md/dm
pointless.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c| 1 -
block/blk-mq.c| 6 +-
block/blk-sysfs.c | 2 +-
drivers/md/dm-table.c | 12 +---
drivers/md/dm.c | 13 +++--
drivers/md/md.c
t out without the flag set.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c| 1 -
block/blk-sysfs.c | 6 +++---
drivers/block/mtip32xx/mtip32xx.c | 1 -
drivers/md/dm-table.c | 18 --
drivers/mmc/core/queue.c | 2 --
driver
rotational devices even if that is
probably not their main use today (e.g. virtio_blk and drbd).
The flag is automatically inherited in blk_stack_limits matching the
existing behavior in dm and md.
Signed-off-by: Christoph Hellwig
---
arch/m68k/emu/nfblock.c | 1 +
arch/um/drivers
is a pre-existing data integrity bug in those
targets that really needs fixing, after which a non-zero num_flush_bios
should be required in dm for targets that map to underlying devices.
Signed-off-by: Christoph Hellwig
---
.../block/writeback_cache_control.rst | 67 +++
Fold blk_flush_policy into the only caller to prepare for pending changes
to it.
Signed-off-by: Christoph Hellwig
---
block/blk-flush.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-flush.c
index
queue_attr_store updates attributes used to control generating I/O, and
can cause malformed bios if changed with I/O in flight. Freeze the queue
in common code instead of adding it to almost every attribute.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c| 5 +++--
block/blk-sysfs.c
blkfront always had a robust negotiation protocol for detecting a write
cache. Stop simply disabling cache flushes when they fail as that is
a grave error.
Signed-off-by: Christoph Hellwig
---
drivers/block/xen-blkfront.c | 29 +
1 file changed, 9 insertions(+), 20
Move setting the cache control flags in nbd in preparation for moving
these flags into the queue_limits structure.
Signed-off-by: Christoph Hellwig
---
drivers/block/nbd.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block
virtblk_update_cache_mode boils down to a single call to
blk_queue_write_cache. Remove it in preparation for moving the cache
control flags into the queue_limits.
Signed-off-by: Christoph Hellwig
---
drivers/block/virtio_blk.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions
This prepares for moving the rotational flag into the queue_limits and
also fixes it for the case where the loop device is backed by a block
device.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff
Fix the code in loop_reconfigure_limits to pick a default block size for
O_DIRECT file descriptors to also work when the loop device sits on top
of a block device and not just on a regular file on a block device based
file system.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 8
The LOOP_CONFIGURE path automatically upgrades the block size to that
of the underlying file for O_DIRECT file descriptors, but the
LOOP_SET_BLOCK_SIZE path does not. Fix this by lifting the code to
pick the block size into common code.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c
__loop_clr_fd wants to clear all settings on the device. Prepare for
moving more settings into the block limits by open coding
loop_reconfigure_limits.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a
model")
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.h | 7 ++-
drivers/scsi/sd_zbc.c | 7 +--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
index 726f1613f6cb56..65dff3c2108926 100644
--- a/drivers/scsi/sd.h
+++
Move a bit of code that sets up the zone flag and the write granularity
into sd_zbc_read_zones to be with the rest of the zoned limits.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 21 +
drivers/scsi/sd_zbc.c | 13 -
2 files changed, 13 insertions
Simplify loop_reconfigure_limits by always updating the discard limits.
This adds a little more work to loop_set_block_size, but doesn't change
the outcome as the discard flag won't change.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 10 --
1 file changed, 4
;
> The only question is whether that violates some assumption elsewhere in the
> SCSI layer?
It shouldn't.
> Anyway patch below that works for me on v6.10-rc2.
This looks good to me:
Reviewed-by: Christoph Hellwig
On Fri, May 31, 2024 at 12:28:21AM +1000, Michael Ellerman wrote:
> No that's wrong. The actual hardware page size is 4K, but
> CONFIG_PAGE_SIZE and PAGE_SHIFT etc. is 64K.
>
> So at least for this user the driver used to work with 64K pages, and
> now doesn't.
Which suggested that the communicat
Adding ben and the linuxppc list.
Context: pata_macio initialization now fails as we enforce that the
segment size is set properly.
On Wed, May 15, 2024 at 04:52:29PM -0700, Guenter Roeck wrote:
> pata_macio_common_init() Calling ata_host_activate() with limit 65280
> ...
> max_segment_size is 65
On Tue, Feb 20, 2024 at 02:32:53PM -0600, Maxwell Bland wrote:
> Present non-uniform use of __vmalloc_node and __vmalloc_node_range makes
> enforcing appropriate code and data seperation untenable on certain
> microarchitectures, as VMALLOC_START and VMALLOC_END are monolithic
> while the use of th
On Tue, Jan 16, 2024 at 12:19:39PM -0800, Yosry Ahmed wrote:
> Well, better compression ratios for one :)
>
> I think a long time ago there were complaints that zsmalloc had higher
> latency than zbud/z3fold, but since then a lot of things have changed
> (including nice compaction optimization fro
On Fri, Jan 12, 2024 at 04:38:30PM -0800, Nhat Pham wrote:
> >
> > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > well.
>
> Makes sense to me. Should we do the same thing to zbud? We probably
> have
On Sun, Jan 07, 2024 at 10:39:07AM +0800, Huacai Chen wrote:
> > Do you mean that LoongArch32 does not support double-precision FP in
> > hardware?
> > At least both of the consumers in this series use double-precision, so my
> > first
> > thought is that LoongArch32 could not select ARCH_HAS_KER
Looks good:
Reviewed-by: Christoph Hellwig
; Signed-off-by: Samuel Holland
Looks good:
Reviewed-by: Christoph Hellwig
Thanks for all the great documentation!
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> Actually tracking all possibly-FPU-tainted functions and their call sites is
> probably possible, but a much larger task.
I think objtool should be able to do that reasonably easily, it already
does it for checking section where use
On Mon, Dec 11, 2023 at 10:12:27AM -0600, Samuel Holland wrote:
> On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
>
> Unfortunately, not all of the relevant options can be no-prefixed:
Ok. That is another good argument for having the obj-fpu += syntax
I proposed. You might need help
Looks good:
Reviewed-by: Christoph Hellwig
> obj-$(CONFIG_TEST_FPU) += test_fpu.o
> -CFLAGS_test_fpu.o += $(FPU_CFLAGS)
> +test_fpu-y := test_fpu_glue.o test_fpu_impl.o
> +CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
Btw, I really wonder if having a
modname-fpu += foo.o
syntax in kbuild wouldn't be preferable to this. Of coure that requires
> +#ifdef __riscv_f
> +
> +#define kernel_fpu_begin() \
> + static_assert(false, "floating-point code must use a separate
> translation unit")
> +#define kernel_fpu_end() kernel_fpu_begin()
> +
> +#else
> +
> +void kernel_fpu_begin(void);
> +void kernel_fpu_end(void);
> +
> +#endif
I'll assum
Looks good:
Reviewed-by: Christoph Hellwig
; export the CFLAGS adjustments.
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 09:54:36PM -0800, Samuel Holland wrote:
> LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
> asm/fpu.h, so it only needs to add kernel_fpu_available() and export
> the CFLAGS adjustments.
Looks good:
Reviewed-by: Christoph Hellwig
lang options work so that if you add a
no-prefixed version of the option later it transparently gets removed?
Except for that:
Reviewed-by: Christoph Hellwig
> + * linux/arch/arm64/include/asm/fpu.h
Same comment as for arm here. Except for that:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 09:54:33PM -0800, Samuel Holland wrote:
> Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
> tree, use it instead of duplicating the flags here.
Looks good:
Reviewed-by: Christoph Hellwig
date.
Except for that:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Nov 22, 2023 at 10:22:11AM -0500, Peter Xu wrote:
> The other reason I feel like hugepd may or may not be further developed for
> new features like large folio is that I saw Power9 started to shift to
> radix pgtables, and afaics hugepd is only supported in hash tables
> (hugepd_ok()). But
> - select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) ||
> (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
> + select DRM_AMD_DC_FP if ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG
> + select DRM_AMD_DC_FP if PPC64 && ALTIVEC
> + select DRM_AMD_DC_FP if RISCV && FPU
> +
On Tue, Nov 21, 2023 at 10:59:35AM -0500, Peter Xu wrote:
> > What prevents us from ever using hugepd with file mappings? I think
> > it would naturally fit in with how large folios for the pagecache work.
> >
> > So keeping this check and generalizing it seems like the better idea to
> > me.
>
On Wed, Nov 15, 2023 at 08:29:02PM -0500, Peter Xu wrote:
> Hugepd format is only used in PowerPC with hugetlbfs. In commit
> a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
> file-backed mappings"), we added a check to fail gup-fast if there's
> potential risk of violating GUP o
Looks good:
Reviewed-by: Christoph Hellwig
> + /* set 64-bit DMA mask and coherent DMA mask */
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
The comment is a bit silly :)
> + if (ret)
> + return ret;
Also no need to check the return value when setting a 64-bit mask,
but I guess it desn't hurt here.
On Thu, Aug 10, 2023 at 08:09:27AM +0800, Ming Lei wrote:
> 1) some archs support 'nr_cpus=1' for kdump kernel, which is fine, since
> num_possible_cpus becomes 1.
>
> 2) some archs do not support 'nr_cpus=1', and have to rely on
> 'max_cpus=1', so num_possible_cpus isn't changed, and kernel just
Thanks,
applied to the dma-mapping tree for 6.6.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
> Thanks for your patch, which is now commit 322dbe898f82fd8a
> ("ARM: dma-mapping: split out arch_dma_mark_clean() helper") in
> esmil/jh7100-dmapool.
Well, something is wrong with that branch then, and this series still
needs more work, and should eventually be merged through the dma-mapping
tre
This should be fixed by
"btrfs: fix the uptodate assert in btree_csum_one_bio"
on the list.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
ameter from GUP altogether.
>
> Acked-by: David Hildenbrand
> Acked-by: Dennis Dalessandro (for
> qib)
> Signed-off-by: Lorenzo Stoakes
Looks good:
Reviewed-by: Christoph Hellwig
Thanks,
applied to the dma-mapping tree for 6.4.
On Fri, Mar 24, 2023 at 09:17:38AM +, Jiaxun Yang wrote:
> >
> > Is patch a 6.3 candidate or should all of it go into 6.4?
>
> Please leave it for 6.4, as corresponding MIPS arch part will be a part of
> 6.4.
Ok. I'll really need review from the MIPS and drivers/of/ maintainers,
through.
> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
> {
> + dma_cache_wback(paddr, size);
> +}
>
> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
> +{
> + dma_cache_inv(paddr, size);
> }
> +static inline void arch_dma_cache_wback_inv(phys_
On Thu, Mar 23, 2023 at 09:07:31PM +, Jiaxun Yang wrote:
>
>
> > 2023年3月23日 07:29，Christoph Hellwig 写道：
> >
> > The series looks fine to me. How should we merge it?
>
> Perhaps go through dma-mapping tree?
Is patch a 6.3 candidate or should all of it go into 6.4?
The series looks fine to me. How should we merge it?
> - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
Doesn't powerpc need to select CONFIG_ARCH_DMA_DEFAULT_COHERENT now,
or even better should be doing that in the patch adding that
symbol?
In fact I wonder if adding CONFIG_ARCH_DMA_DEFAULT_COHERENT and removing
OF_DMA_DEFAULT_
> +config ARCH_DMA_DEFAULT_COHERENT
> + bool
Please add a comment here explaining when an architecture should
ѕelect this symbol.
On Thu, Feb 23, 2023 at 11:36:41AM +, Jiaxun Yang wrote:
> dma_default_coherent was decleared unconditionally at kernel/dma/mapping.c
> but only decleared when any of non-coherent options is enabled in
> dma-map-ops.h.
Overly lone line here.
> }
> #else
> +#define dma_default_coherent true
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
On Tue, Feb 21, 2023 at 12:46:11PM +, Jiaxun Yang wrote:
> Provide a kconfig option to allow arches to manipulate default
> value of dma_default_coherent in Kconfig.
I don't see the win over just doing this by setting dma_default_coherent
in the early boot code.
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
> dma_default_coherent can be useful for determine default coherency
> even on arches without noncoherent support.
How?
On Tue, Feb 21, 2023 at 12:46:07PM +, Jiaxun Yang wrote:
> As now we are always managing DMA coherence on per dev bias,
> there is no need to have such option. And it's not selected
> by any platform.
I think the real point here is that this is dead code, so it can
obviously go away, but:
>
> +/**
> + * vm_account_init - Initialise a new struct vm_account.
> + * @vm_account: pointer to uninitialised vm_account.
> + * @task: task to charge against.
> + * @user: user to charge against. Must be non-NULL for VM_ACCOUNT_USER.
> + * @flags: flags to use when charging to vm_account.
> + *
>
ps3vram iterates over the bio one segment, that is page aligned and max
page sized chunk, a time. Because of that there is no point in
calling bio_split_to_limits, or explicitly setting the default limits
that are only used by bio_split_to_limits.
Signed-off-by: Christoph Hellwig
---
drivers
I would have split this into one patch that adds the new
zap_vma_pages helper, and one to remove zap_page_range to split the
separate changes.
But the overall result looks fine, so feel free to add:
Reviewed-by: Christoph Hellwig
to this or the split patches.
> unsigned long size = vma->vm_end - vma->vm_start;
>
> if (vma_is_special_mapping(vma, vdso_info[VDSO_ABI_AA64].dm))
> - zap_page_range(vma, vma->vm_start, size);
> + zap_vma_page_range(vma, vma->vm_start, size);
> #ifdef CONFI
ps3_system_bus_type is only used inside of system-bus.c, so remove
the external declaration and the very outdated comment next to it.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/ps3.h | 4
arch/powerpc/platforms/ps3/system-bus.c | 2 +-
2 files changed, 1
Thanks, this is long overdue!
Acked-by: Christoph Hellwig
> +#if IS_ENABLED(CONFIG_EEH) && IS_ENABLED(CONFIG_VFIO_IOMMU_SPAPR_TCE)
> #include
> #endif
>
> @@ -689,7 +689,7 @@ void vfio_pci_core_close_device(struct vfio_device
> *core_vdev)
> vdev->sriov_pf_core_dev->vf_token->users--;
> mutex_unlock(&vdev->sriov_pf_core_d
On Mon, Aug 22, 2022 at 01:40:23PM +1000, Michael Ellerman wrote:
> Randy Dunlap writes:
> > drivers/gpu/drm/amd/amdkfd/kfd_device.c calls cpu_smt_mask().
> > This is an inline function on powerpc which references
> > cpu_smallcore_map.
> >
> > Fixes: 425752c63b6f ("powerpc: Detect the presence of
Miguel,
handwaiving and pointing to git trees is not how Linux development
works. Please make sure all the patches go to the relevant lists
and maintainers first, and actually do have ACKs.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Sun, Jul 17, 2022 at 12:34:52PM +0900, Stafford Horne wrote:
> The generic pci.h header now only provides a definition of
> pci_get_legacy_ide_irq which is used by architectures that support PNP.
> Of the architectures that use asm-generic/pci.h this is only x86.
Please move this into a separat
On Wed, Jun 29, 2022 at 09:38:00AM +1200, Michael Schmitz wrote:
> That's one of the 'liberties' I alluded to. The reason I left these in is
> that I'm none too certain what device feature the DMA API uses to decide a
> device isn't cache-coherent.
The DMA API does not look at device features at a
On Wed, Jun 29, 2022 at 11:09:00AM +1200, Michael Schmitz wrote:
> And all SCSI buffers are allocated using kmalloc? No way at all for user
> space to pass unaligned data?
Most that you will see actually comes from the page allocator. But
the block layer has a dma_alignment limit, and when usersp
On Tue, Jun 14, 2022 at 03:54:12PM +0200, Laurent Dufour wrote:
> The watchdog_mutex is exported to allow some variable to be changed under
> its protection and prevent any conflict.
> The lockup_detector_reconfigure() function is exported and is expected to
> be called under the protection of watc
On Fri, Jun 24, 2022 at 10:50:33AM +0530, Anshuman Khandual wrote:
> > On most architectures this should be const now, only very few ever
> > modify it.
>
> Will make it a 'static const pgprot_t protection_map[16] __ro_after_init'
> on platforms that do not change the protection_map[] even during
On Fri, Jun 24, 2022 at 10:13:13AM +0530, Anshuman Khandual wrote:
> vm_get_page_prot(), in order for it to be reused on platforms that do not
> require custom implementation. Finally, ARCH_HAS_VM_GET_PAGE_PROT can just
> be dropped, as all platforms now define and export vm_get_page_prot(), via
>
Looks good:
Reviewed-by: Christoph Hellwig
101 - 200 of 2342 matches
Mail list logo
