Hi,
在 2025/04/09 17:40, Christoph Hellwig 写道:
On Wed, Apr 09, 2025 at 05:27:11PM +0800, Yu Kuai wrote:
For that you'd be much better of just creating your own trivial
file_system_type with an inode fully controlled by your driver
that has a trivial set of address_space ops instead of oddly
mixi
When a dm-delay device is being suspended, the .presuspend() operation
is first executed (delay_presuspend()) to immediately issue all the BIOs
present in the delayed list of the device and also sets the device
may_delay boolean to false. At the same time, if any new BIO is issued
to the device wil
On 4/11/25 03:10, Benjamin Marzinski wrote:
>>> Don't we only need to do that if anything is queued up due to a
>>> suspension? Then again having a different patch might be premature
>>> optimization, it's not like anyone cares about dm-delay performance
>>> almost by definition :)
>>
>> True. I c
On 2025/4/10 15:15, Christoph Hellwig wrote:
> On Thu, Apr 10, 2025 at 11:52:17AM +0800, Zhang Yi wrote:
>>
>> Thank you for your review and comments. However, I'm not sure I fully
>> understand your points. Could you please provide more details?
>>
>> AFAIK, the NVMe protocol has the following des
On 4/10/25 4:54 PM, Christoph Hellwig wrote:
> On Thu, Apr 10, 2025 at 01:33:11PM +0900, Damien Le Moal wrote:
>> When a dm-delay devie is being suspended, the .presuspend() operation is
>
> s/devie/device/
>
>> first executed (delay_presuspend()) to immediately issue all the BIOs
>> present in t
With request-based dm, the mempools don't need reloading when switching
tables, but the unused table mempools are not freed until the active
table is finally freed. Free them immediately if they are not needed.
Fixes: 29dec90a0f1d9 ("dm: fix bio_set allocation")
Reviewed-by: Damien Le Moal
Signed
On Thu, 10 Apr 2025, Yu Kuai wrote:
> Hi,
>
> 在 2025/04/10 16:06, LongPing Wei 写道:
> > On 2025/4/10 15:36, Christoph Hellwig wrote:
> > > On Thu, Apr 10, 2025 at 11:09:04AM +0800, LongPing Wei wrote:
> > > > Fix the compile error when dm-bufio is built as a module.
> > > >
> > > > 1. dm-bufio
If dm_table_set_restrictions() fails while swapping tables,
device-mapper will continue using the previous table. It must be sure to
leave the mapped_device in it's previous state on failure. Otherwise
device-mapper could end up using the old table with settings from the
unused table.
Do not upda
If dm_get_live_table() returned NULL, dm_put_live_table() was never
called. Also, it is possible that md->zone_revalidate_map will change
while calling this function. Only read it once, so that we are always
using the same value. Otherwise we might miss a call to
dm_put_live_table().
Finally, whil
If a DM device that can pass down zone append commands is stacked on top
of a device that emulates zone append commands, it will allocate zone
append emulation resources, even though it doesn't use them. This is
because the underlying device will have max_hw_zone_append_sectors set
to 0 to request
With request-based dm, the mempools don't need reloading when switching
tables, but the unused table mempools are not freed until the active
table is finally freed. Free them immediately if they are not needed.
Fixes: 29dec90a0f1d9 ("dm: fix bio_set allocation")
Reviewed-by: Damien Le Moal
Signed
dm_revalidate_zones() only allowed new or previously unzoned devices to
call blk_revalidate_disk_zones(). If the device was already zoned,
disk->nr_zones would always equal md->nr_zones, so dm_revalidate_zones()
returned without doing any work. This would make the zoned settings for
the device not
__bind was changing the disk capacity, geometry and mempools of the
mapped device before calling dm_table_set_restrictions() which could
fail, forcing dm to drop the new table. Failing here would leave the
device using the old table but with the wrong capacity and mempools.
Move dm_table_set_restr
There were multiple places in dm's __bind() function where it could fail
and not completely roll back, leaving the device using the the old
table, but with device limits and resources from the new table.
Additionally, unused mempools for request-based devices were not always
freed immediately.
Als
Once again: no. You need to stop abusing the early lookup infrastructure
for anything not directly dealing with finding the root device
in init/. Stop messing with it to paper up the mistake of dm even
adding this code without proper review.
On Thu, Apr 10, 2025 at 05:02:00PM +0900, Damien Le Moal wrote:
> On 4/10/25 4:54 PM, Christoph Hellwig wrote:
> > On Thu, Apr 10, 2025 at 01:33:11PM +0900, Damien Le Moal wrote:
> >> When a dm-delay devie is being suspended, the .presuspend() operation is
> >
> > s/devie/device/
> >
> >> first e
On 4/10/25 5:15 AM, Benjamin Marzinski wrote:
>>> @@ -1873,11 +1898,17 @@ int dm_table_set_restrictions(struct dm_table *t,
>>> struct request_queue *q,
>>> limits->features &= ~BLK_FEAT_DAX;
>>>
>>> /* For a zoned table, setup the zone related queue attributes. */
>>> - if (IS
On Wed, Apr 02, 2025 at 08:44:39PM +0200, Mikulas Patocka wrote:
> Submitting large I/O with IOPRIO_CLASS_RT will block every other task that
> does some I/O, so I can't do that. It needs to be changed to
> IOPRIO_CLASS_NONE or IOPRIO_CLASS_IDLE.
Also random kernel code should not simply upgrade
On Thu, Apr 10, 2025 at 09:15:59AM +0200, Christoph Hellwig wrote:
> On Thu, Apr 10, 2025 at 11:52:17AM +0800, Zhang Yi wrote:
> >
> > Thank you for your review and comments. However, I'm not sure I fully
> > understand your points. Could you please provide more details?
> >
> > AFAIK, the NVMe p
Hi,
在 2025/04/10 16:06, LongPing Wei 写道:
On 2025/4/10 15:36, Christoph Hellwig wrote:
On Thu, Apr 10, 2025 at 11:09:04AM +0800, LongPing Wei wrote:
Fix the compile error when dm-bufio is built as a module.
1. dm-bufio module use blk_flush_plug();
2. blk_flush_plug is an inline function and it
On Thu, Apr 10, 2025 at 01:33:11PM +0900, Damien Le Moal wrote:
> When a dm-delay devie is being suspended, the .presuspend() operation is
s/devie/device/
> first executed (delay_presuspend()) to immediately issue all the BIOs
> present in the delayed list of the device and also sets the device
>
On 2025/4/10 17:11, Yu Kuai wrote:
Hi,
在 2025/04/10 16:06, LongPing Wei 写道:
On 2025/4/10 15:36, Christoph Hellwig wrote:
On Thu, Apr 10, 2025 at 11:09:04AM +0800, LongPing Wei wrote:
Fix the compile error when dm-bufio is built as a module.
1. dm-bufio module use blk_flush_plug();
2. blk_flu
On 2025/4/10 16:20, Keith Busch wrote:
> On Thu, Apr 10, 2025 at 09:15:59AM +0200, Christoph Hellwig wrote:
>> On Thu, Apr 10, 2025 at 11:52:17AM +0800, Zhang Yi wrote:
>>>
>>> Thank you for your review and comments. However, I'm not sure I fully
>>> understand your points. Could you please provide
On Wed, Apr 02, 2025 at 03:09:36PM +0800, LongPing Wei wrote:
>
> + dm_bufio_prefetch_with_ioprio(v->bufio, v->hash_start,
> + v->hash_blocks - v->hash_start,
> + IOPRIO_PRIO_VALUE(IOPRIO_CLASS_RT, 0));
Err, no. Random code should not prefetch with a RT priority.
The dm-init code, waiting for devices specified by dm-mod.waitfor (e.g.,
root=/dev/dm-0, dm-mod.waitfor=/dev/mmcblk0p23), fails sporadically with
dm-verity setups, as reported in:
https://lore.kernel.org/all/e746b8b5-c04c-4982-b4bc-0fa240742...@schwermer.no/T/
This occurs because early_lookup_bdev
This commit message is extremtly sparse. Not helped by the fact that
the series also misses a cover letter.
On Wed, Apr 02, 2025 at 03:09:34PM +0800, LongPing Wei wrote:
> 1. call blk_flush_plug when cache hit as the address of the subsequent
> bio is no longer contiguous with the previous bio;
On 2025/4/10 15:36, Christoph Hellwig wrote:
On Thu, Apr 10, 2025 at 11:09:04AM +0800, LongPing Wei wrote:
Fix the compile error when dm-bufio is built as a module.
1. dm-bufio module use blk_flush_plug();
2. blk_flush_plug is an inline function and it calls __blk_flush_plug.
Then don't call
On Thu, Apr 10, 2025 at 11:09:04AM +0800, LongPing Wei wrote:
> Fix the compile error when dm-bufio is built as a module.
>
> 1. dm-bufio module use blk_flush_plug();
> 2. blk_flush_plug is an inline function and it calls __blk_flush_plug.
Then don't call blk_flush_plug from dm-bufio, as drivers
On Thu, Apr 10, 2025 at 11:52:17AM +0800, Zhang Yi wrote:
>
> Thank you for your review and comments. However, I'm not sure I fully
> understand your points. Could you please provide more details?
>
> AFAIK, the NVMe protocol has the following description in the latest
> NVM Command Set Specifica
29 matches
Mail list logo
