On 1/29/24 16:52, Johannes Thumshirn wrote:
> Pass GFP_KERNEL instead of GFP_NOFS to the blkdev_zone_mgmt() call in
> zonefs_zone_mgmt().
>
> As as zonefs_zone_mgmt() and zonefs_inode_zone_mgmt() are never called
> from a place that can recurse back into the filesystem on memory reclaim,
> it is
On 2/6/24 02:28, Bart Van Assche wrote:
> On 2/1/24 23:30, Damien Le Moal wrote:
>> @@ -916,9 +888,8 @@ bool blk_update_request(struct request *req, blk_status_t
>> error,
>> if (blk_crypto_rq_has_keyslot(req) && nr_bytes >= blk_rq_bytes(req))
>> __blk_crypto_rq_put_keyslot(req);
On 2/3/24 21:11, Jens Axboe wrote:
>> I forgot to mention that the patches are against Jens block/for-next
>> branch with the addition of Christoph's "clean up blk_mq_submit_bio"
>> patches [1] and my patch "null_blk: Always split BIOs to respect queue
>> limits" [2].
>
> I figured that was the
On 2/6/24 10:25, Bart Van Assche wrote:
> On 2/5/24 16:07, Damien Le Moal wrote:
>> On 2/6/24 03:18, Bart Van Assche wrote:
>>> Are there numbers available about the performance differences (bandwidth
>>> and latency) between plugging zoned write bios and zoned write plugging
>>> requests?
>>
>>
On 2/7/24 06:20, Bart Van Assche wrote:
> On 2/5/24 15:55, Damien Le Moal wrote:
>> The array of struct blk_zone_wplug for the disk is sized for the total
>> number of
>> zones of the drive. The reason for that is that we want to retain the
>> wp_offset
>> value for all zones, even if they are
On Mon, Feb 05, 2024 at 01:46:38PM +0100, Martin Wilck wrote:
> Socket activation will start multipathd on systems that don't have multipath
> hardware. This is often not desired. On systems that do have multipath
> hardware, OTOH, it is highly recommended to enable multipathd.service directly
>
On Mon, Feb 05, 2024 at 01:46:37PM +0100, Martin Wilck wrote:
> This allows us to remove the lumsy MPATH_SBIN_PATH property and
> related tests.
>
> Signed-off-by: Martin Wilck
Reviewed-by: Benjamin Marzinski
> ---
> .gitignore| 1 +
> Makefile.inc
On Mon, Feb 05, 2024 at 01:46:36PM +0100, Martin Wilck wrote:
> If a map reload happens while udev is processing rules for a coldplug
> event, DM_SUSPENDED may be set if the respective test in 10-dm.rules
> happens while the device is suspened. This will cause the rules for all
> higher block
Mathieu Desnoyers wrote:
> On 2024-02-08 17:37, Dan Williams wrote:
> > Mathieu Desnoyers wrote:
> >> On 2024-02-08 16:39, Dan Williams wrote:
> >> [...]
> >>>
> >>> So per other feedback on earlier patches, I think this hunk deserves to
> >>> be moved to its own patch earlier in the series as a
On Mon, Feb 05, 2024 at 01:46:35PM +0100, Martin Wilck wrote:
> We have to import the properties if either DM_NOSCAN or
> DM_DISABLE_OTHER_RULES_FLAG is set, because blkid will be skipped
> in both cases. Also, if DM_UDEV_PRIMARY_SOURCE_FLAG is not set,
> it makes no sense to try and import the
On Mon, Feb 05, 2024 at 01:46:34PM +0100, Martin Wilck wrote:
> Make sure we import all properties that are also imported in
> 13-dm-disk.rules. Keep importing ID_FS_TYPE for now to avoid
> breakage, even if 13-dm-disk.rules does not.
>
> Signed-off-by: Martin Wilck
> ---
>
On Tue, Feb 06, 2024 at 11:50:46AM +0100, Martin Wilck wrote:
> On Mon, 2024-02-05 at 15:44 -0500, Benjamin Marzinski wrote:
> > On Mon, Feb 05, 2024 at 01:46:33PM +0100, Martin Wilck wrote:
> > > DM_UDEV_DISABLE_OTHER_RULES_FLAG and DM_NOSCAN may be already set
> > > from previous rules, e.g. if
On Thu, Feb 08, 2024 at 12:04:45AM -0800, Song Liu wrote:
> Hi Benjamin,
>
> On Mon, Feb 5, 2024 at 7:58 PM Benjamin Marzinski wrote:
> >
> > On Tue, Feb 06, 2024 at 09:36:18AM +0800, Yu Kuai wrote:
> > > Hi!
> > >
> > > 在 2024/02/06 3:35, Benjamin Marzinski 写道:
> > > > Could you run the test
On 2024-02-08 17:37, Dan Williams wrote:
Mathieu Desnoyers wrote:
On 2024-02-08 16:39, Dan Williams wrote:
[...]
So per other feedback on earlier patches, I think this hunk deserves to
be moved to its own patch earlier in the series as a standalone fixup.
Done.
Rest of this patch looks
Mathieu Desnoyers wrote:
> On 2024-02-08 16:39, Dan Williams wrote:
> [...]
> >
> > So per other feedback on earlier patches, I think this hunk deserves to
> > be moved to its own patch earlier in the series as a standalone fixup.
>
> Done.
>
> >
> > Rest of this patch looks good to me.
>
>
On 2024-02-08 17:12, Andrew Morton wrote:
On Thu, 8 Feb 2024 17:04:52 -0500 Mathieu Desnoyers
wrote:
[...]
Should I keep this patch 01/12 within the series for v5 or should I
send it separately ?
Doesn't matter much, but perfectionism does say "standalone patch please".
Will do. I plan
On 2024-02-08 16:55, Dan Williams wrote:
[...]
Oh... I see you cleanup what I was talking about later in the series.
For my taste I don't like to see tech-debt added and then removed later
in the series. The whole series would appear to get smaller by removing
the alloc_dax() returning NULL
On Thu, 8 Feb 2024 17:04:52 -0500 Mathieu Desnoyers
wrote:
> > The series seems useful but is at v4 without much sign of review
> > activity. I think I'll take silence as assent and shall slam it all
> > into -next and see who shouts at me.
> >
>
> Thanks Andrew for picking it up! Dan just
On 2024-02-08 16:39, Dan Williams wrote:
[...]
So per other feedback on earlier patches, I think this hunk deserves to
be moved to its own patch earlier in the series as a standalone fixup.
Done.
Rest of this patch looks good to me.
Adding your Acked-by to what is left of this patch if
On 2024-02-08 16:37, Dan Williams wrote:
[...]
+DEFINE_FREE(cleanup_dax, struct dax_dev *, if (!IS_ERR_OR_NULL(_T))
virtio_fs_cleanup_dax(_T))
This IS_ERR_OR_NULL is ok because dax_dev is initialized to NULL, but
maybe this could just be IS_ERR() and then initialize @dax_dev to
On 2024-02-08 16:36, Dan Williams wrote:
[...]
Just another "ditto" on alloc_dax() returning NULL so that the ternary
can be removed, but otherwise this looks good.
Done.
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-08 16:34, Dan Williams wrote:
[...]
Similar feedback as the pmem change, lets not propagate the mistake that
alloc_dax() could return NULL, none of the callers of alloc_dax()
properly handled NULL and it was just luck that none of the use cases
tried to use alloc_dax() in the
On 2024-02-08 16:32, Dan Williams wrote:
Mathieu Desnoyers wrote:
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of nvdimm/pmem
pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
For the
On 2024-02-08 16:21, Andrew Morton wrote:
On Thu, 8 Feb 2024 13:49:02 -0500 Mathieu Desnoyers
wrote:
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
out_cleanup_dax:
Mathieu Desnoyers wrote:
> Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
> the callers do not have to handle NULL return values anymore.
>
> Signed-off-by: Mathieu Desnoyers
> Cc: Alasdair Kergon
> Cc: Mike Snitzer
> Cc: Mikulas Patocka
> Cc: Andrew Morton
> Cc: Linus
Mathieu Desnoyers wrote:
> commit d92576f1167c ("dax: does not work correctly with virtual aliasing
> caches")
> prevents DAX from building on architectures with virtually aliased
> dcache with:
>
> depends on !(ARM || MIPS || SPARC)
>
> This check is too broad (e.g. recent ARMv7 don't have
Mathieu Desnoyers wrote:
> Introduce a generic way to query whether the data cache is virtually
> aliased on all architectures. Its purpose is to ensure that subsystems
> which are incompatible with virtually aliased data caches (e.g. FS_DAX)
> can reliably query this.
>
> For data cache
Mathieu Desnoyers wrote:
> Replace the following fs/Kconfig:FS_DAX dependency:
>
> depends on !(ARM || MIPS || SPARC)
>
> By a runtime check within alloc_dax(). This runtime check returns
> ERR_PTR(-EOPNOTSUPP) if the @ops parameter is non-NULL (which means
> the kernel is using an aliased
Mathieu Desnoyers wrote:
> In preparation for checking whether the architecture has data cache
> aliasing within alloc_dax(), modify the error handling of virtio
> virtio_fs_setup_dax() to treat alloc_dax() -EOPNOTSUPP failure as
> non-fatal.
>
> For the transition, consider that alloc_dax()
Mathieu Desnoyers wrote:
> In preparation for checking whether the architecture has data cache
> aliasing within alloc_dax(), modify the error handling of dcssblk
> dcssblk_add_store() to handle alloc_dax() -EOPNOTSUPP failures.
>
> Considering that s390 is not a data cache aliasing architecture,
Mathieu Desnoyers wrote:
> In preparation for checking whether the architecture has data cache
> aliasing within alloc_dax(), modify the error handling of dm alloc_dev()
> to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
>
> For the transition, consider that alloc_dax() returning NULL is
Mathieu Desnoyers wrote:
> In preparation for checking whether the architecture has data cache
> aliasing within alloc_dax(), modify the error handling of nvdimm/pmem
> pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
>
> For the transition, consider that alloc_dax()
Mathieu Desnoyers wrote:
> Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
> before setting pmem->dax_dev, which therefore issues the two following
> calls on NULL pointers:
>
> out_cleanup_dax:
> kill_dax(pmem->dax_dev);
> put_dax(pmem->dax_dev);
>
>
On Thu, 2024-02-08 at 04:02 +0100, Xose Vazquez Perez wrote:
> https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-std-1
>
> Cc: Martin Wilck
> Cc: Benjamin Marzinski
> Cc: Christophe Varoqui
> Cc: DM-DEVEL ML
> Signed-off-by: Xose Vazquez Perez
Reviewed-by: Martin Wilck
On Thu, 8 Feb 2024 13:49:02 -0500 Mathieu Desnoyers
wrote:
> Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
> before setting pmem->dax_dev, which therefore issues the two following
> calls on NULL pointers:
>
> out_cleanup_dax:
> kill_dax(pmem->dax_dev);
>
On Thu, Feb 8, 2024 at 8:56 AM Tejun Heo wrote:
>
> On Wed, Feb 07, 2024 at 11:02:37AM -0800, Allen wrote:
> > https://github.com/allenpais/for-6.9-bh-conversions
> >
> > I am holding on to the patch that converts drivers/media/*, as I haven't
> > found
> > a right way to replace
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Introduce a generic way to query whether the data cache is virtually
aliased on all architectures. Its purpose is to ensure that subsystems
which are incompatible with virtually aliased data caches (e.g. FS_DAX)
can reliably query this.
For data cache aliasing, there are three scenarios
Replace the following fs/Kconfig:FS_DAX dependency:
depends on !(ARM || MIPS || SPARC)
By a runtime check within alloc_dax(). This runtime check returns
ERR_PTR(-EOPNOTSUPP) if the @ops parameter is non-NULL (which means
the kernel is using an aliased mapping) on an architecture which
has data
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
prevents DAX from building on architectures with virtually aliased
dcache with:
depends on !(ARM || MIPS || SPARC)
This check is too broad (e.g. recent ARMv7 don't have virtually aliased
dcaches), and also
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of virtio
virtio_fs_setup_dax() to treat alloc_dax() -EOPNOTSUPP failure as
non-fatal.
For the transition, consider that alloc_dax() returning NULL is the
same as returning
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of dm alloc_dev()
to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
For the transition, consider that alloc_dax() returning NULL is the
same as returning -EOPNOTSUPP.
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of dcssblk
dcssblk_add_store() to handle alloc_dax() -EOPNOTSUPP failures.
Considering that s390 is not a data cache aliasing architecture,
and considering that DCSSBLK
This commit introduced in v4.0 prevents building FS_DAX on 32-bit ARM,
even on ARMv7 which does not have virtually aliased data caches:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
It used to work fine before: I have customers using DAX over pmem on
ARMv7,
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
out_cleanup_dax:
kill_dax(pmem->dax_dev);
put_dax(pmem->dax_dev);
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of nvdimm/pmem
pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
For the transition, consider that alloc_dax() returning NULL is the
same as returning
Add details describing the vdo zone and thread model to the
documentation comments for major vdo components. Also added
some high-level description of the block map structure.
Signed-off-by: Matthew Sakai
---
drivers/md/dm-vdo/block-map.h| 15 +++
drivers/md/dm-vdo/dedupe.c
Signed-off-by: Matthew Sakai
---
Documentation/admin-guide/device-mapper/index.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/admin-guide/device-mapper/index.rst
b/Documentation/admin-guide/device-mapper/index.rst
index cde52cc09645..cc5aec861576 100644
---
Add more documentation details for most aspects of the data_vio
read and write processes. Also correct a few minor errors and
rewrite some text for clarity.
Signed-off-by: Matthew Sakai
---
.../admin-guide/device-mapper/vdo-design.rst | 674 --
1 file changed, 446
Add details about I/O handling in vdo, and details about
concurrency and locking. Also add vdo documentation to
the device-mapper doc index.
Matthew Sakai (3):
dm vdo: add vdo documentation to device-mapper index
dm vdo: add vio lifecycle details to doc
dm vdo: add documentation details on
On Wed, Feb 07, 2024 at 11:02:37AM -0800, Allen wrote:
> https://github.com/allenpais/for-6.9-bh-conversions
>
> I am holding on to the patch that converts drivers/media/*, as I haven't
> found
> a right way to replace tasklet_[disable/enable] api's. The rest should be
> ready
> in a day or
Hi Benjamin,
On Mon, Feb 5, 2024 at 7:58 PM Benjamin Marzinski wrote:
>
> On Tue, Feb 06, 2024 at 09:36:18AM +0800, Yu Kuai wrote:
> > Hi!
> >
> > 在 2024/02/06 3:35, Benjamin Marzinski 写道:
> > > Could you run the test with something like
> > >
> > > # make check_local T=lvconvert-repair-raid.sh
55 matches
Mail list logo
