On Mon, Nov 27, 2023 at 11:52:15AM +, Usama Arif wrote:
> By recall do you mean put the LONGTERM pages back? If I removed the check in
> check_vma and allowed the mappings to happen in fsdax, I can see that the
> mappings unmap/unpin in vfio_iommu_type1_unmap_dma later on which eventually
>
We don't have any way to recall the LONGTERM mappings, so we can't
support them on DAX for now.
On Tue, Aug 01, 2023 at 11:23:36AM -0400, Jeff Moyer wrote:
> I am slightly embarrassed to have to ask this question, but what are the
> implications of setting this queue flag? Is the submit_bio routine
> expected to never block?
Yes, at least not significantly.
> Is the I/O expected to be
On Fri, May 12, 2023 at 03:43:01AM -0700, Chaitanya Kulkarni wrote:
> Allow user to set the QUEUE_FLAG_NOWAIT optionally using module
> parameter to retain the default behaviour.
Why?
On Mon, Oct 17, 2022 at 01:17:23PM -0700, Dan Williams wrote:
> Historically, no. The block-device is allowed to disappear while inodes
> are still live.
Btw, while I agree with what you wrote below this sentence is at least
a bit confusing. Struct block_device/gendisk/request_queue will always
On Tue, Sep 20, 2022 at 03:08:03AM +, Wu, Dennis wrote:
> Hi, Dan,
> Will we add this patch to some new kernel version?
How about addressing my comments and explaining what the exact
data integrity model is here first?
is expected so do not
> warn when that happens.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Fri, Aug 26, 2022 at 10:18:01AM -0700, Dan Williams wrote:
> The SB_BORN flag is stored in the vfs superblock, not xfs_sb.
Oops, yes:
Reviewed-by: Christoph Hellwig
On Tue, Jul 12, 2022 at 06:25:30PM -0700, Dan Williams wrote:
> > This goes back to my question from years ago: why do we ever
> > do this deep flush in the Linux nvdimm stack to start with?
>
> The rationale is to push the data to smaller failure domain. Similar to
> flushing disk write-caches.
On Wed, Jun 29, 2022 at 04:31:18PM +0800, Dennis.Wu wrote:
> reason: in the current BTT implimentation deepflush is always
> used and deepflush is very expensive. Since customer already
> know the ADR can protect the WPQ data in memory controller and
> no need to call deepflush to get better
On Mon, Jun 20, 2022 at 09:40:11AM +1000, Dave Chinner wrote:
> That doesn't change the fact we are issuing cache flushes from the
> log checkpoint code - it just changes how we issue them. We removed
> the explicit blkdev_issue_flush_async() call from the cache path and
> went back to the old way
s not been seen in the wild, elide notifying -stable.
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 09, 2022 at 07:49:37PM -0800, Dan Williams wrote:
> Now that none of the configuration paths consider BLK namespaces, delete
> the BLK namespace data and supporting code.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
e the one in
> iomap_unshare_iter().
Looks good:
Reviewed-by: Christoph Hellwig
On Sat, Dec 11, 2021 at 05:50:51PM +, Matthew Wilcox wrote:
> On Wed, Dec 08, 2021 at 10:12:03AM +0100, Christoph Hellwig wrote:
> > bytes also hold the return value from iomap_write_end, which can contain
> > a negative error value. As bytes is always less than the
On Wed, Dec 08, 2021 at 04:55:59PM -0800, Darrick J. Wong wrote:
> Ok, so ... I don't know what I'm supposed to apply this to? Is this
> something that should go in Christoph's development branch?
This is against the decouple DAX from block devices series, which also
decouples DAX zeroing from
ed-by: Dan Carpenter
Signed-off-by: Christoph Hellwig
---
fs/iomap/buffered-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index b1511255b4df8..ac040d607f4fe 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
On Thu, Nov 04, 2021 at 10:17:31AM -0700, Christoph Hellwig wrote:
> On Thu, Nov 04, 2021 at 10:09:37AM -0700, Dan Williams wrote:
> > Hmm, so the driver has 2 modes "labeled" and "label-less", in the
> > labeled mode it waits for an explicit:
On Thu, Nov 04, 2021 at 10:09:37AM -0700, Dan Williams wrote:
> Hmm, so the driver has 2 modes "labeled" and "label-less", in the
> labeled mode it waits for an explicit:
>
> ndctl create-namespace
>
> ...to provision region capacity into a namespace. In label-less mode
> it just assumes
On Thu, Nov 04, 2021 at 09:00:01AM -0700, Dan Williams wrote:
> > Any idea what might be missing in the attached config? This seems to
> > be independent of the tested kernel version (5.14, 5.15, master).
>
> Can you share your qemu command line
qemu-system-x86_64 -enable-kvm \
-machine
I've update my typical test configs last week without saving the old
ones, and now the Qemu emulated NFIT devices don't show anyway more
despite the kernel showing a NFIT table:
# mesg | grep -i nfit
[0.009184] ACPI: NFIT 0xBFFE02FA 000198 (v01 BOCHS BXPCNFIT
0001 BXPC 0001)
No driver is left using the external pgmap refcount, so remove the
code to support it.
Signed-off-by: Christoph Hellwig
---
Changes since v1:
- fix compile in p2pdma.c
- drop the alredy merged first patch
drivers/pci/p2pdma.c | 2 +-
include/linux/memremap.h | 18
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
---
drivers/nvdimm/btt.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm
Using local kmaps slightly reduces the chances to stray writes, and
the bvec interface cleans up the code a little bit.
Signed-off-by: Christoph Hellwig
---
drivers/nvdimm/blk.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm
Hi all,
this series uses the bvec_kmap_local helper in the nvdimm subsystem.
Diffstat:
blk.c |7 +++
btt.c | 10 --
2 files changed, 7 insertions(+), 10 deletions(-)
On Mon, Sep 27, 2021 at 10:16:10PM -0700, Darrick J. Wong wrote:
> > > My test machinse all hit this when writeback throttling is enabled, so
> > >
> > > Tested-by: Darrick J. Wong
> >
> > Do you mean the series fixed it for you?
>
> Yes.
Thanks! I was just a little confused this came in in
On Mon, Sep 27, 2021 at 04:02:59PM -0700, Darrick J. Wong wrote:
> > > Looping xfstests generic/108 or xfs/279 on mountpoints with fsdax
> > > enabled can lead to panic like this:
> >
> > Does this still happen with this series:
> >
> >
On Wed, Sep 22, 2021 at 10:55:01AM -0700, Dan Williams wrote:
> This looks like your send script picked up the wrong cover letter?
Yes. Or the human running the script to be exact :)
_disk into device_add_disk")
Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
Reviewed-by: Dan Williams
---
block/genhd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index 7b6e5e1cf9564..409cf608cc5bd 100644
--- a/block/genhd.c
+
dax_attribute_group is only used by the pmem driver, and can avoid the
completely pointless lookup by the disk name if moved there. This
leaves just a single caller of dax_get_by_host, so move dax_get_by_host
into the same ifdef block as that caller.
Signed-off-by: Christoph Hellwig
Reviewed
The recent block layer refactoring broke the way how the pmem driver
abused device_add_disk. Fix this by properly passing the attribute groups
to device_add_disk.
Fixes: 52b85909f85d ("block: fold register_disk into device_add_disk")
Signed-off-by: Christoph Hellwig
Reviewed-by:
Not required at all, and having this causes a huge kernel rebuild
as soon as something in dax.h changes.
Signed-off-by: Christoph Hellwig
---
include/linux/mempolicy.h | 1 -
mm/memory-failure.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mempolicy.h
All callers already have a dax_device obtained from fs_dax_get_by_bdev
at hand, so just pass that to dax_supported() insted of doing another
lookup.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
drivers/dax/super.c | 42 +-
fs/ext2
Refactor the DAX setup code in preparation of removing
bdev_dax_supported.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
fs/xfs/xfs_super.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index
dax_supported calls into ->dax_supported which checks for fsdax support.
Don't bother building it for !CONFIG_FS_DAX as it will always return
false.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
drivers/dax/super.c | 36 ++--
include/linux/da
Just implement generic_fsdax_supported directly out of line instead of
adding a wrapper. Given that generic_fsdax_supported is only supplied
for CONFIG_FS_DAX builds this also allows to not provide it at all for
!CONFIG_FS_DAX builds.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
Move the dax_read_lock/dax_read_unlock pair from the callers into
dax_supported to make it a little easier to use.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
drivers/dax/super.c | 16 +---
drivers/md/dm-table.c | 9 ++---
2 files changed, 11 insertions
And move the code around a bit to avoid a forward declaration.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
drivers/dax/super.c | 109 ++--
include/linux/dax.h | 5 --
2 files changed, 54 insertions(+), 60 deletions(-)
diff --git
There is no point in trying to finding the dax device if the DAX flag is
not set on the queue as none of the users of the device mapper exported
block devices could make use of the DAX capability.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
drivers/md/dm.c | 2 +-
1 file
Just use the %pg format specifier instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dan Williams
---
drivers/dax/super.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 44736cbd446e..3e6d7e9ee34f
Rename the main option text to clarify it is for file system access,
and add a bit of text that explains how to actually switch a nvdimm
to a fsdax capable state.
Signed-off-by: Christoph Hellwig
---
fs/Kconfig | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff
Hi all,
this series first clarifies how to use fsdax in the Kconfig help a bit,
and then untangles the code path that checks if fsdax is supported.
Changes since v1:
- improve the FS_DAX Kconfig help text further
- write a proper commit log for a patch missing it
Diffstat
drivers/dax/super.c
On Mon, Aug 23, 2021 at 11:45:52AM -0700, Dan Williams wrote:
> On Mon, Aug 23, 2021 at 5:37 AM Christoph Hellwig wrote:
> >
> > Rename the main option text to clarify it is for file system access,
> > and add a bit of text that explains how to actually switch a nvdimm
&
On Mon, Aug 23, 2021 at 02:15:47PM -0700, Dan Williams wrote:
> > +static inline bool dax_supported(struct dax_device *dax_dev,
> > + struct block_device *bdev, int blocksize, sector_t start,
> > + sector_t len)
> > +{
> > + return false;
> > +}
>
> I've started
All callers already have a dax_device obtained from fs_dax_get_by_bdev
at hand, so just pass that to dax_supported() insted of doing another
lookup.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 42 +-
fs/ext2/super.c | 3 ++-
fs/ext4
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_super.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 2c9e26a44546..5a89bf601d97 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -314,6 +314,14
dax_supported calls into ->dax_supported which checks for fsdax support.
Don't bother building it for !CONFIG_FS_DAX as it will always return
false.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 36 ++--
include/linux/dax.h | 18 ++
Just implement generic_fsdax_supported directly out of line instead of
adding a wrapper. Given that generic_fsdax_supported is only supplied
for CONFIG_FS_DAX builds this also allows to not provide it at all for
!CONFIG_FS_DAX builds.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c
Move the dax_read_lock/dax_read_unlock pair from the callers into
dax_supported to make it a little easier to use.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 16 +---
drivers/md/dm-table.c | 9 ++---
2 files changed, 11 insertions(+), 14 deletions(-)
diff
And move the code around a bit to avoid a forward declaration.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 109 ++--
include/linux/dax.h | 5 --
2 files changed, 54 insertions(+), 60 deletions(-)
diff --git a/drivers/dax/super.c b
There is no point in trying to finding the dax device if the DAX flag is
not set on the queue as none of the users of the device mapper exported
block devices could make use of the DAX capability.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm.c | 2 +-
1 file changed, 1 insertion(+), 1
Just use the %pg format specifier instead.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 44736cbd446e..3e6d7e9ee34f 100644
--- a/drivers/dax
Rename the main option text to clarify it is for file system access,
and add a bit of text that explains how to actually switch a nvdimm
to a fsdax capable state.
Signed-off-by: Christoph Hellwig
---
fs/Kconfig | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git
Hi all,
this series first clarifies how to use fsdax in the Kconfig help a bit,
and te untangles the code path that checks if fsdax is supported.
Diffstat
drivers/dax/super.c | 191 +++---
drivers/md/dm-table.c |9 --
drivers/md/dm.c |
Hi all,
looking at the recent ZONE_DEVICE related changes we still have a
horrible maze of different code paths. I already suggested to
depend on ARCH_HAS_PTE_SPECIAL for ZONE_DEVICE there, which all modern
architectures have anyway. But the other odd special case is
CONFIG_FS_DAX_LIMITED which
On Thu, Aug 19, 2021 at 02:25:52PM -0700, Dan Williams wrote:
> Given most of the iomap_iter users don't care about srcmap, i.e. are
> not COW cases, they are leaving srcmap zero initialized. Should the
> IOMAP types be incremented by one so that there is no IOMAP_HOLE
> confusion? In other words,
On Thu, Aug 12, 2021 at 11:20:17AM -0700, Darrick J. Wong wrote:
> The history of the gluecode that enables us to walk a bunch of extent
> mappings. In the beginning it was the _apply function, but now in our
> spectre-weary world, you've switched it to a direct loop to reduce the
> number of
On Wed, Aug 11, 2021 at 12:18:00PM -0700, Darrick J. Wong wrote:
> + while ((ret = iomap_iter(, ops)) > 0) {
> + if (iter.iomap.type == IOMAP_MAPPED)
> + bno = iomap_sector(, iter.pos) >> blkshift;
> + /* leave iter.processed unset to abort loop */
>
On Wed, Aug 11, 2021 at 12:17:08PM -0700, Darrick J. Wong wrote:
> > iter.c is also my preference, but in the end I don't care too much.
>
> Ok. My plan for this is to change this patch to add the new iter code
> to apply.c, and change patch 24 to remove iomap_apply. I'll add a patch
> on the
On Tue, Aug 10, 2021 at 05:31:18PM -0700, Darrick J. Wong wrote:
> > +static inline void iomap_iter_done(struct iomap_iter *iter)
>
> I wonder why this is a separate function, since it only has debugging
> warnings and tracepoints?
The reason for these two sub-helpers was to force me to
On Mon, Aug 09, 2021 at 11:45:09PM -0700, Darrick J. Wong wrote:
> > fs/iomap.c without having to take the tree back in time to find
> > those files...
>
> ...or put the new code in apply.c, remove iomap_apply, and don't bother
> with the renaming at all?
>
> I don't see much reason to break the
On Mon, Aug 09, 2021 at 11:39:51PM -0700, Darrick J. Wong wrote:
> Can't this at least be rephrased as:
>
> const uint bno_shift = (mapping->host->i_blkbits - SECTOR_SHIFT);
>
> while ((ret = iomap_iter(, ops)) > 0) {
> if (iter.iomap.type == IOMAP_MAPPED)
>
The srcmap returned from iomap_iter_srcmap is never modified, so mark
the iomap returned from it const and constify a lot of code that never
modifies the iomap.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/iomap/buffered-io.c | 38
Avoid the open coded calls to ->iomap_begin and ->iomap_end and call
iomap_iter instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/dax.c | 193 +--
1 file changed, 75 insertions(+), 118 deletions(-)
diff --gi
-by: Christoph Hellwig
Reviewed-by: Ritesh Harjani
Reviewed-by: Darrick J. Wong
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 297 ---
1 file changed, 149 insertions(+), 148 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index c09d721629d167
-by: Ritesh Harjani
Reviewed-by: Darrick J. Wong
[hch: minor cleanups]
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 153 ++-
1 file changed, 84 insertions(+), 69 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 51da45301350a6..c09d721629d167
Instead of another internal flags namespace inside of buffered-io.c,
just pass a UNSHARE hint in the main iomap flags field.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/iomap/buffered-io.c | 23 +--
include/linux/iomap.h | 1 +
2 files changed, 10
Pass the iomap_iter structure instead of individual parameters to
various internal helpers for buffered I/O.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/iomap/buffered-io.c | 137 -
1 file changed, 66 insertions(+), 71 deletions
iomap_apply is unused now, so remove it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/iomap/Makefile | 1 -
fs/iomap/apply.c | 99 ---
fs/iomap/trace.h | 40 -
include/linux/iomap.h | 10 -
4
Switch the dax_iomap_rw implementation to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 49 -
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 4d63040fd71f56..51da45301350a6 100644
Switch iomap_swapfile_activate to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/swapfile.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/fs/iomap/swapfile.c b/fs/iomap/swapfile.c
index 6250ca6a1f851d..7069606eca85b2
Rewrite iomap_seek_data to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/seek.c | 47 ---
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git a/fs/iomap/seek.c b/fs/iomap/seek.c
index fed8f9005f9e46..a845c012b50c67 100644
Rewrite iomap_seek_hole to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/seek.c | 51 +
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/fs/iomap/seek.c b/fs/iomap/seek.c
index ce6fb810854fec..fed8f9005f9e46 100644
Rewrite the ->bmap implementation based on iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/fiemap.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/fs/iomap/fiemap.c b/fs/iomap/fiemap.c
index acad09a8c188df..60daadba16c149 100
Rewrite the ->fiemap implementation based on iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/fiemap.c | 70 ---
1 file changed, 29 insertions(+), 41 deletions(-)
diff --git a/fs/iomap/fiemap.c b/fs/iomap/fiemap.c
index aab070df4a2
Switch iomap_page_mkwrite to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/buffered-io.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 3a23f7346938fb
Switch iomap_zero_range to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/buffered-io.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 4f525727462f33..3a23f7346938fb
Switch iomap_file_unshare to use iomap_iter.
Signed-off-by: Christoph Hellwig
---
fs/iomap/buffered-io.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 4c7e82928cc546..4f525727462f33
Switch the page cache read functions to use iomap_iter instead of
iomap_apply.
Signed-off-by: Christoph Hellwig
---
fs/iomap/buffered-io.c | 80 +++---
1 file changed, 37 insertions(+), 43 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered
The actor should never return a larger value than the length that was
passed in. The current code handles this gracefully, but the opcoming
iter model will be more picky.
Signed-off-by: Christoph Hellwig
---
fs/iomap/buffered-io.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
iomap_read_page_sync never modifies the passed in iomap, so mark
it const.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/iomap/buffered-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index
__block_write_begin_int never modifies the passed in iomap, so mark it
const.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/buffer.c | 4 ++--
fs/internal.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index
Signed-off-by: Christoph Hellwig
---
include/linux/iomap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index 8030483331d17f..560247130357b5 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -99,7 +99,7
These aren't actually used by the only instance implementing the methods.
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/gfs2/bmap.c | 5 ++---
fs/iomap/buffered-io.c | 6 +++---
include/linux/iomap.h | 5 ++---
3 files changed, 7 insertions(+), 9 deletions
Signed-off-by: Christoph Hellwig
Reviewed-by: Darrick J. Wong
---
fs/iomap/trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/iomap/trace.h b/fs/iomap/trace.h
index fdc7ae388476f5..e9cd5cc0d6ba40 100644
--- a/fs/iomap/trace.h
+++ b/fs/iomap/trace.h
@@ -2,7 +2,7
On Mon, Jul 19, 2021 at 10:57:56AM -0700, Darrick J. Wong wrote:
> Which seems to translate to:
>
> -machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,nvdimm=on
> -object
> memory-backend-file,id=memnvdimm0,prealloc=no,mem-path=/run/g.mem,share=yes,size=10739515392,align=128M
>
On Mon, Jul 26, 2021 at 09:39:22AM -0700, Darrick J. Wong wrote:
> The documentation needs to be much more explicit about the fact that you
> cannot "break;" your way out of an iomap_iter loop. I think the comment
> should be rewritten along these lines:
>
> "Iterate over filesystem-provided
On Tue, Jul 20, 2021 at 08:10:05AM +1000, Dave Chinner wrote:
> At first I wondered "iomi? Strange name, why is this one-off name
> used?" and then I realised it's because this function also takes an
> struct iov_iter named "iter".
>
> That's going to cause confusion in the long run - iov_iter
On Mon, Jul 19, 2021 at 10:05:45AM -0700, Darrick J. Wong wrote:
> > bno = 0;
> > - ret = iomap_apply(inode, pos, blocksize, 0, ops, ,
> > - iomap_bmap_actor);
> > + while ((ret = iomap_iter(, ops)) > 0) {
> > + if (iter.iomap.type != IOMAP_MAPPED)
> > +
On Tue, Jul 20, 2021 at 07:48:38AM +1000, Dave Chinner wrote:
> We should avoid namespace conflicts where function names shadow
> object types. iomap_iterate() is fine as the function name - there's
> no need for abbreviation here because it's not an overly long name.
> This will makes it clearly
On Mon, Jul 19, 2021 at 09:56:00AM -0700, Darrick J. Wong wrote:
> Linus previously complained to me about filesystem code (especially
> iomap since it was "newer") (ab)using loff_t variables to store the
> lengths of byte ranges. It was "loff_t length;" (or so willy
> recollects) that tripped
On Mon, Jul 19, 2021 at 09:08:20AM -0700, Darrick J. Wong wrote:
> IMHO, constifiying functions is a good way to signal to /programmers/
> that they're not intended to touch the arguments, so
Yes, that is the point here. Basically the iomap and iter should
be pretty much const, and we almost get
On Mon, Jun 28, 2021 at 08:02:11AM +0800, Shiyang Ruan wrote:
> +int dax_holder_notify_failure(struct dax_device *dax_dev, loff_t offset,
> + size_t size, void *data)
> +{
> + int rc = -ENXIO;
> + if (!dax_dev)
> + return rc;
> +
> + if
On Mon, Jun 28, 2021 at 08:02:18AM +0800, Shiyang Ruan wrote:
> Since owner tracking is triggerred by pmem device, these functions are
> useless. So remove them.
What about ext2 and ext4?
1 - 100 of 167 matches
Mail list logo
