On Thu, Jan 09, 2025 at 09:12:03AM +0100, Greg Kroah-Hartman wrote:
> > Hey, when I duplicated the method to convert sysfs over to a proper
> > seq_file based approach that avoids buffer overflows you basically
> > came up with the same line that Alexei had here.
>
> I did? Sorry about that, I do
On Thu, Jan 09, 2025 at 08:56:37AM +0100, Greg Kroah-Hartman wrote:
> The "pointless" penalty will go away once we convert all instances, and
> really, it's just one pointer check, sysfs files should NOT be a hot
> path for anything real, and one more pointer check should be cached and
> not measur
;)
> Reported-by: Philipp Hortmann
> Closes: https://lore.kernel.org/39256db9-3d73-4e86-a49b-300dfd670...@gmail.com
> Signed-off-by: Geert Uytterhoeven
Looks fine:
Reviewed-by: Christoph Hellwig
But looking at the report it seems like no one cares about ps3 upstream,
and in fact the only
You've sent me less than a handfull of 14 patches, there's no way
to properly review this.
with this patch powerpc loses the CONFIG_DEBUG_VIRTUAL pfn_valid
check. It will be added back in a generic version later.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 1 -
arch/arc/include/asm/io.h | 3 ---
arch/arm/include/asm/memory.h | 6 --
, so add that to the generic version.
Signed-off-by: Christoph Hellwig
---
include/asm-generic/memory_model.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/asm-generic/memory_model.h
b/include/asm-generic/memory_model.h
index a73a140cbecd..6d1fb6162ac1 100644
--- a
page_to_phys is duplicated by all architectures, and from some strange
reason placed in where it doesn't fit at all.
phys_to_page is only provided by a few architectures despite having a lot
of open coded users.
Provide generic versions in to make these
helpers more easily usable.
Changes s
Back in the day a lot of logic was implemented inline in dma-mapping.h and
needed various includes. Move of this has long been moved out of line,
so we can drop various includes to improve kernel rebuild times.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/svm.c | 1
o add that to the generic version.
Signed-off-by: Christoph Hellwig
---
include/asm-generic/memory_model.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/asm-generic/memory_model.h
b/include/asm-generic/memory_model.h
index a73a140cbecdd7..6d1fb6162ac1a6 100644
--- a/in
with this patch powerpc loses the CONFIG_DEBUG_VIRTUAL pfn_valid
check. It will be added back in a generic version later.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 1 -
arch/arc/include/asm/io.h | 3 ---
arch/arm/include/asm/memory.h | 6 --
page_to_phys is duplicated by all architectures, and from some strange
reason placed in where it doesn't fit at all.
phys_to_page is only provided by a few architectures despite having a lot
of open coded users.
Provide generic versions in to make these
helpers more easily usable.
Changes s
On Sun, Oct 13, 2024 at 11:43:41AM +0300, Mike Rapoport wrote:
> > But why? That's pretty different from our normal style of arch hooks,
> > and introduces an indirect call in a security sensitive area.
>
> Will change to __weak hook.
Isn't the callback required when using the large ROX page?
On Thu, Oct 10, 2024 at 03:57:33PM +0300, Mike Rapoport wrote:
> On Wed, Oct 09, 2024 at 11:58:33PM -0700, Christoph Hellwig wrote:
> > On Wed, Oct 09, 2024 at 09:08:15PM +0300, Mike Rapoport wrote:
> > > /**
> > > * struct execmem_info - architecture para
On Thu, Oct 10, 2024 at 09:03:42AM +0200, Christoph Hellwig wrote:
> > I think we should try to have a little fewer nested macros
> > to evaluate here, right now this ends up expanding
> > __pfn_to_phys, PFN_PHYS, PAGE_SHIFT, CONFIG_PAGE_SHIFT,
> > page_to_pfn and __page_to
On Tue, Oct 08, 2024 at 08:33:07AM +0200, Christoph Hellwig wrote:
> On Mon, Oct 07, 2024 at 07:34:18PM +0530, Venkat Rao Bagalkote wrote:
> > Greetings!!!
> >
> >
> > Observing Kfence errors, while running fsstress test on Power PC platform
>
> Is this new
On Wed, Oct 09, 2024 at 02:06:27PM +, Arnd Bergmann wrote:
> This is clearly a good idea, and I'm happy to take that through
> the asm-generic tree if there are no complaints.
>
> Do you have any other patches that depend on it?
Well, I have new code that would benefit from these helpers, but
On Wed, Oct 09, 2024 at 09:08:15PM +0300, Mike Rapoport wrote:
> /**
> * struct execmem_info - architecture parameters for code allocations
> + * @fill_trapping_insns: set memory to contain instructions that will trap
> * @ranges: array of parameter sets defining architecture specific
> * pa
struct module *mod);
Please drop all the pointless externs while you're at it.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
amed text-patching.h and add an empty
> header in asm-generic for architectures that do not support text patching.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
uct vm_struct *vm);
> +extern __init void vm_area_register_early(struct vm_struct *vm, size_t
> align);
Please drop the externs while you're at it. (one more down below)
Otherwise looks good:
Reviewed-by: Christoph Hellwig
d-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 1 -
arch/arc/include/asm/io.h | 3 ---
arch/arm/include/asm/memory.h | 6 --
arch/arm64/include/asm/memory.h | 6 --
arch/csky/include/asm/page.h| 3 ---
arch/hexagon/include/asm/p
page_to_phys is duplicated by all architectures, and from some strange
reason placed in where it doesn't fit at all.
phys_to_page is only provided by a few architectures despite having a lot
of open coded users.
Provide generic versions in to make these
helpers more easily usable.
Diffstat:
On Tue, Oct 08, 2024 at 09:50:09AM +0200, Julian Vetter wrote:
> lib/iomap_copy.c | 127 +++
On top of the previous comments: this really should be iomem_copy.c
instead.
On Tue, Oct 08, 2024 at 09:27:20AM +, Arnd Bergmann wrote:
> > #endif /* CONFIG_TRACE_MMIO_ACCESS */
> >
> > +extern void memcpy_fromio(void *to, const volatile void __iomem *from,
> > + size_t count);
> > +extern void memcpy_toio(volatile void __iomem *to, const void *fro
On Mon, Oct 07, 2024 at 07:34:18PM +0530, Venkat Rao Bagalkote wrote:
> Greetings!!!
>
>
> Observing Kfence errors, while running fsstress test on Power PC platform
Is this new or is this the first time you run kfence? Any chance you
could bisect it?
I'd still prefer to just kill it right away, but as the second best
option I'm ok with this:
Acked-by: Christoph Hellwig
I've pulled this into the dma-mapping for-next tree, although I'd
love to see one of the vdpa maintainers look over patch 1. I'm
pretty sure it's correct, but a confirmation would be good.
On Wed, Aug 28, 2024 at 08:21:14AM +0200, Andreas Larsson wrote:
> On 2024-08-28 08:10, Christoph Hellwig wrote:
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -177,8 +177,8 @@ config XEN_GRANT_DMA_ALLOC
> >
> > config SWIOTLB_XEN
>
should probably be
marked broken, but we can give them a bit of a grace period for that.
Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
Acked-by: Sakari Ailus # for IPU6
Acked-by: Robin Murphy
---
arch/Kconfig | 9 +
arch/alpha/Kconfig
vdpa_sim has been fixed to not override the dma_map_ops in commit
6c3d329e6486 ("vdpa_sim: get rid of DMA ops"), so don't select the
symbol and don't depend on HAS_DMA.
Signed-off-by: Christoph Hellwig
---
drivers/vdpa/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 dele
Hi all,
we've had a long standing problems where drivers try to hook into the
DMA_OPS mechanisms to override them for something that is not DMA, or
to introduce additional dispatching.
Now that we are not using DMA_OPS support for dma-iommu and can build
kernels without DMA_OPS support on many co
On Sat, Aug 24, 2024 at 12:17:57PM -0500, Segher Boessenkool wrote:
> > Are these functions also used on DMA coherent memory ?
>
> Most won't show up high on most profiles, heh. Which you already
> can see from the problem not being attacked yet: if it was so obviously
> a problem, some people wo
On Mon, Aug 26, 2024 at 02:27:27PM +0800, Jason Wang wrote:
> Actually I meant, we can extend the virtio_config_ops to allow mapping
> ops there, then simulator and VDUSE can hook the map ops there.
>From a quick glance that feels like the right layer of abstraction,
although the config part of th
Hi all,
we've had a long standing problems where drivers try to hook into the
DMA_OPS mechanisms to override them for something that is not DMA, or
to introduce additional dispatching.
Now that we are not using DMA_OPS support for dma-iommu and can build
kernels without DMA_OPS support on many co
broken, but we can give them a bit of a grace
period for that.
Signed-off-by: Christoph Hellwig
---
arch/Kconfig | 9 +
arch/alpha/Kconfig | 2 +-
arch/arm/Kconfig | 2 +-
arch/arm64/Kconfig | 1 +
arch
On Fri, Aug 23, 2024 at 08:06:00AM -0500, Segher Boessenkool wrote:
> What does "uncached memory" even mean here? Literally it would be
> I=1 memory (uncachEABLE memory), but more likely you want M=0 memory
> here ("non-memory memory", "not well-behaved memory", MMIO often).
Regular kernel memory
dma_alloc_from_pool is the allocator used when the caller can't
sleep, and as that is reusing memory it really has to call memset
or a memset-like function on the already uncached memory
unfortunately. The dma engine operation that is doing this allocation
is documented as not being able to sleep,
On Thu, Aug 22, 2024 at 06:39:33AM +, LEROY Christophe wrote:
> powerpc has a magic instruction 'dcbz' which clears a full cacheline in
> one go. It is far more efficient than a loop to store zeros, and since
> 2015 memset(0) has been implemented with that instruction (commit
> 5b2a32e80634
On Thu, Aug 22, 2024 at 05:25:10AM +, LEROY Christophe wrote:
> > and this results in a call to dma_direct_allocation(), which has one
> > innocent looking memset():
>
>
> memset() can't be used on non-cached memory, memset_io() has to be used
> instead.
No, we use memset on uncached memory
Thanks,
applied to the dma-mapping tree for Linux 6.12.
On Thu, Aug 22, 2024 at 12:13:52AM +0300, Sergei Shtylyov wrote:
> On 8/20/24 6:04 AM, Michael Ellerman wrote:
>
> > The overflow/underflow conditions in pata_macio_qc_prep() should never
> > happen. But if they do there's no need to kill the system entirely, a
> > WARN and failing the IO request
On Sat, Aug 17, 2024 at 09:46:31AM +1000, Michael Ellerman wrote:
> Same behaviour on a kernel with PAGE_SIZE = 4KB.
>
> I don't know why max_sectors_kb starts out with a different value on my
> system, but anyway the bug is lurking there, even if it doesn't trip by
> default in some configuration
On Wed, Jul 31, 2024 at 06:24:24PM -0700, Nathan Chancellor wrote:
> Unfortunately, I am not sure either... I do not see anything obviously,
> so perhaps it could just be avoided with the __diag() infrastructure?
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 3dbc0b89d6fb..b58e
Ok, I guess this is what Robin was referring to.
A midlayer like SCSI really shouldn't directly call dma layer
functions without knowing that the underlying bus is DMA capable.
I'll see what I can do about it, and in the meantime drop this patch
and the companion from the dma-mapping tree.
On Mon, Jul 29, 2024 at 07:12:08PM -0700, Nathan Chancellor wrote:
> > | ~~ ^~~~
> >include/linux/dma-mapping.h:77:40: note: expanded from macro
> > 'DMA_BIT_MASK'
> > 77 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1UL
On Thu, Jul 25, 2024 at 01:35:46PM +0200, Wouter Verhelst wrote:
> NBD actually exports a flag for rotational devices; it's defined in
> nbd.h in the NBD userland source as
>
> #define NBD_FLAG_ROTATIONAL (1 << 4)/* Use elevator algorithm -
> rotational media */
>
> which is passed i
On Tue, Jul 02, 2024 at 08:19:01PM +1000, Alistair Popple wrote:
> > (B) As long as we have subpage mapcounts, this prevents vmemmap
> > optimizations [1]. Is that only used for device-dax for now and are
> > there no plans to make use of that for fs-dax?
>
> I don't have any plans to. Thi
On Tue, Jul 02, 2024 at 09:18:31AM +0200, David Hildenbrand wrote:
> We have this comparably nasty vmf_insert_mixed() that FS dax abused to
> insert into !VM_MIXED VMAs. Is that abuse now stopping and are there maybe
> ways to get rid of vmf_insert_mixed()?
Unfortunately it is also used by a few
On Mon, Jul 01, 2024 at 04:22:19PM +0800, Oliver Sang wrote:
> from below, it seems the patchset doesn't introduce any performance
> improvement
> but a regression now. is this expected?
Not having the improvement at least alleviate my concerns about data
integrity. I'm still curious where it co
> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> index eb61598..b7a31ae 100644
> --- a/drivers/dax/device.c
> +++ b/drivers/dax/device.c
> @@ -126,11 +126,11 @@ static vm_fault_t __dev_dax_pte_fault(struct dev_dax
> *dev_dax,
> return VM_FAULT_SIGBUS;
> }
>
> -
On Thu, Jun 27, 2024 at 10:54:20AM +1000, Alistair Popple wrote:
> static struct nouveau_dmem_chunk *nouveau_page_to_chunk(struct page *page)
> {
> - return container_of(page->pgmap, struct nouveau_dmem_chunk, pagemap);
> + return container_of(page_dev_pagemap(page), struct nouveau_dmem_c
On Thu, Jun 27, 2024 at 10:54:19AM +1000, Alistair Popple wrote:
> When a fs dax page is freed it has to notify filesystems that the page
> has been unpinned/unmapped and is free. Currently this involves
> special code in the page free paths to detect a transition of refcount
> from 2 to 1 and to c
; Signed-off-by: Alistair Popple
> Reviewed-by: Jan Kara
I'm pretty sure I already review this ages ago, but:
Reviewed-by: Christoph Hellwig
On Thu, Jun 27, 2024 at 10:54:17AM +1000, Alistair Popple wrote:
> The reference counts for ZONE_DEVICE private pages should be
> initialised by the driver when the page is actually allocated by the
> driver allocator, not when they are first created. This is currently
> the case for MEMORY_DEVICE_
On Thu, Jun 27, 2024 at 10:54:21AM +1000, Alistair Popple wrote:
> +extern void prep_compound_page(struct page *page, unsigned int order);
No need for the extern.
> static int insert_page_into_pte_locked(struct vm_area_struct *vma, pte_t
> *pte,
> - unsigned long addr, struc
On Thu, Jun 27, 2024 at 10:35:38AM +0800, Oliver Sang wrote:
>
> I failed to apply patch in your previous reply to 1122c0c1cc or current tip
> of axboe-block/for-next:
> c1440ed442a58 (axboe-block/for-next) Merge branch 'for-6.11/block' into
> for-next
That already includes it.
>
> but it's ok
On Wed, Jun 26, 2024 at 02:11:11PM +0800, Oliver Sang wrote:
> hi, Christoph Hellwig,
>
> On Mon, Jun 24, 2024 at 10:35:37AM +0200, Christoph Hellwig wrote:
> > This is odd to say at least. Any chance you can check the value
> > of /sys/block/$DEVICE/queue/rotational fo
On Wed, Jun 26, 2024 at 10:10:49AM +0800, Oliver Sang wrote:
> I'm not sure I understand this test request. as in title, we see a good
> improvement of aim7 for 1122c0c1cc, and we didn't observe other issues for
> this commit.
The improvement suggests we are not sending cache flushes when we shoul
did have a volatile write cache I'm a bit lost what the problem
was and this probably won't fix the issue.
---
>From 81c816827197f811e14add7a79220ed9eef6af02 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 25 Jun 2024 08:48:18 +0200
Subject: md: set md-specific flags
On Mon, Jun 24, 2024 at 11:08:16AM -0600, Keith Busch wrote:
> On Mon, Jun 17, 2024 at 08:04:41AM +0200, Christoph Hellwig wrote:
> > -#define blk_queue_nonrot(q)test_bit(QUEUE_FLAG_NONROT,
> > &(q)->queue_flags)
> > +#define blk_queue_nonrot(q)
On Mon, Jun 24, 2024 at 03:45:57PM +0200, Niklas Cassel wrote:
> Seems to be ATA SSD:
> https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com/job.yaml
>
> ssd_partitions:
> "/dev/disk/by-id/ata-INTEL_SSDSC2BG012T4_BTHC428201ZX1P2OGN-part1"
>
> Most likely b
This is odd to say at least. Any chance you can check the value
of /sys/block/$DEVICE/queue/rotational for the relevant device before
and after this commit? And is this an ATA or NVMe SSD?
On Wed, Jun 19, 2024 at 08:21:14AM -0600, Jens Axboe wrote:
> Please check for-6.11/block, as I pulled in the changes to the main
> block branch and that threw some merge conflicts mostly due to Damien's
> changes in for-6.11/block. While fixing those up, I also came across
> oddities like:
>
> (l
Move the bounce flag into the features field to reclaim a little bit of
space.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-settings.c| 1 -
block/blk.h | 2 +-
drivers/scsi/scsi_lib.c | 2 +-
include/linux/blkdev.h | 6 --
4 files changed, 6
Move the skip_tagset_quiesce flag into the queue_limits feature field so
that it can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/nvme/host/core.c | 8 +---
include/linux/blkdev.h | 6
Move the pci_p2pdma flag into the queue_limits feature field so that it
can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/nvme/host/core.c | 8 +++-
include/linux/blkdev.h | 7 ---
3
Move the zone_resetall flag into the queue_limits feature field so that
it can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/block/null_blk/zoned.c | 3 +--
drivers/block/ublk_drv.c
Move the zoned flags into the features field to reclaim a little
bit of space.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-settings.c | 5 ++---
drivers/block/null_blk/zoned.c | 2 +-
drivers/block/ublk_drv.c | 2 +-
drivers/block/virtio_blk.c
-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
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
Move the dax flag into the queue_limits feature field so that it can be
set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c | 1 -
drivers/md/dm-table.c| 4 ++--
drivers/nvdimm/pmem.c| 7
.
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 | 18 +++---
drivers/md/md.c | 18
-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
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
Move the synchronous flag into the queue_limits feature field so that it
can be set atomically with the queue frozen.
Signed-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
block/blk-mq-debugfs.c| 1 -
drivers/block/brd.c | 2 +-
drivers/block/zram/zram_drv.c | 4
: 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 | 5 ++---
drivers/nvme
igned-off-by: Christoph Hellwig
Reviewed-by: Damien Le Moal
---
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
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
Reviewed-by: Damien Le Moal
---
arch/m68k/emu/nfblock.c | 1 +
arch/um
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
Acked-by: Ulf Hansson [mmc]
---
.../block/writeback_cache_control.rst
Fold blk_flush_policy into the only caller to prepare for pending changes
to it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Reviewed-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
---
block/blk-flush.c | 33 +++--
1 file changed, 15 insertions
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
Reviewed-by: Bart Van Assche
Reviewed-by: Damien Le
Move setting the cache control flags in nbd in preparation for moving
these flags into the queue_limits structure.
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Reviewed-by: Josef Bacik
Reviewed-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
---
drivers/block/nbd.c | 17
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
Reviewed-by: Bart Van Assche
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Damien Le Moal
Reviewed
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
Reviewed-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
Reviewed-by: Bart Van Assche
---
drivers/block/loop.c
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
Reviewed-by: Hannes Reinecke
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
Reviewed-by: Hannes
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
Reviewed-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
R
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 | 9 +
2 files changed, 10 insertions
__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
Reviewed-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
Reviewed-by: Bart Van Assche
---
drivers/block
is.
Fixes: 7437bb73f087 ("block: remove support for the host aware zone model")
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
Reviewed-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/sd.c | 6 +-
driver
Hi all,
this is the third and last major series to convert settings to
queue_limits for this merge window. After a bunch of prep patches to
get various drivers in shape, it moves all the queue_flags that specify
driver controlled features into the queue limits so that they can be
set atomically a
cleared inside of blkfront. This removes old
debug code to check for such a mismatch which was previously impossible
to hit, including the check for passthrough requests that blkfront
never used to start with.
Signed-off-by: Christoph Hellwig
---
drivers/block/xen-blkfront.c | 44
On Mon, Jun 17, 2024 at 08:01:04AM +0900, Damien Le Moal wrote:
> On 6/13/24 18:39, Christoph Hellwig wrote:
> > On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote:
> >>> + if (sdkp->device->type == TYPE_ZBC)
> >>
> >> Nit: use sd_is_zoned(
g like the patch below, which keeps
the existing behavior, but insolates the block layer from it and
removes the only user of blk_queue_write_cache from interrupt
context:
---
>From e6e82c769ab209a77302994c3829cf6ff7a595b8 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Thu, 30 May 2024 0
On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote:
> > + if (sdkp->device->type == TYPE_ZBC)
>
> Nit: use sd_is_zoned() here ?
Actually - is there much in even keeping sd_is_zoned now that the
host aware support is removed? Just open coding the type check isn't
any more code, and
On Wed, Jun 12, 2024 at 10:01:18AM +0200, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> > blkfront always had a robust negotiation protocol for detecting a write
> > cache. Stop simply disabling cache flushes when they fail as that
On Tue, Jun 11, 2024 at 05:21:07PM +0900, Damien Le Moal wrote:
> Kind of the same remark as for io_stat about this not really being a device
> feature. But I guess seeing "features" as a queue feature rather than just a
> device feature makes it OK to have poll (and io_stat) as a feature rather th
On Tue, Jun 11, 2024 at 05:16:37PM +0900, Damien Le Moal wrote:
> > @@ -1825,9 +1815,7 @@ int dm_table_set_restrictions(struct dm_table *t,
> > struct request_queue *q,
> > int r;
> >
> > if (dm_table_supports_nowait(t))
> > - blk_queue_flag_set(QUEUE_FLAG_NOWAIT, q);
> > - e
On Tue, Jun 11, 2024 at 05:09:45PM +0900, Damien Le Moal wrote:
> On 6/11/24 2:19 PM, Christoph Hellwig wrote:
> > Move the io_stat flag into the queue_limits feature field so that it
> > can be set atomically and all I/O is frozen when changing the flag.
>
> Why a fe
On Tue, Jun 11, 2024 at 04:55:04PM +0900, Damien Le Moal wrote:
> On 6/11/24 2:19 PM, Christoph Hellwig wrote:
> > Move the cache control settings into the queue_limits so that they
> > can be set atomically and all I/O is frozen when changing the
> > flags.
>
>
1 - 100 of 1682 matches
Mail list logo
