On Wed, Aug 04, 2021 at 11:41:39AM +0200, Christoph Hellwig wrote:
> allows device mapper to use the normal scheme
> of calling add_disk when it is ready to accept I/O.
For clarity, even after this patchset, the device is not ready to accept
I/O when add_disk is called. It is ready to accept I/O
On Tue, Aug 10, 2021 at 12:31:43AM +0100, Alasdair G Kergon wrote:
> When loading tables, our tools also always refer to devices using
> the 'major:minor' format, which isn't affected, rather than using
Wrong - that is also affected.
So there is a
On Wed, Aug 04, 2021 at 11:41:46AM +0200, Christoph Hellwig wrote:
> device mapper is currently the only outlier that tries to call
> register_disk after add_disk, leading to fairly inconsistent state
> of these block layer data structures.
> Note that this introduces a user visible change: the
On 8/4/21 3:41 AM, Christoph Hellwig wrote:
> Hi all,
>
> The device mapper code currently has a somewhat odd gendisk registration
> scheme where it calls add_disk early, but uses a special flag to skip the
> "queue registration", which is a major part of add_disk. This series
> improves the
On many core systems using dm-crypt, heavy spinlock contention in
percpu_counter_compare() can be observed when the dmcrypt page allocation
limit for a given device is reached or close to be reached. This is due
to percpu_counter_compare() taking a spinlock to compute an exact
result on
On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
For reflinked files, one dax page may be associated more than once with
different fime mapping and index. It will report warning. Now, since
^^^typo here?
we have introduced dax-RMAP for this case and also have to keep its
On 04/08/2021 10:56, Christoph Hellwig wrote:
Use bvec_virt instead of open coding it.
Signed-off-by: Christoph Hellwig
---
arch/um/drivers/ubd_kern.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index
Hello everyone,
On 22.07.21 11:17, Ahmad Fatoum wrote:
> While keys of differing type have a common struct key definition, there is
> no common scheme to the payload and key material extraction differs.
>
> For kernel functionality that supports different key types,
> this means duplicated code
The filesystem part of the pmem failure handling is at minimum built
on PAGE_SIZE granularity - an inheritance from general memory_failure
handling. However, with Intel's DCPMEM technology, the error blast
radius is no more than 256bytes, and might get smaller with future
hardware generation,
On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
This is the case where the holder represents a mapped device, or a list
of mapped devices more exactly(because it is possible to create more
than one mapped device on one pmem device).
Could you share how do you test this scenario?
thanks,
-jane
On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
- /*
-* Prevent the inode from being freed while we are interrogating
-* the address_space, typically this would be handled by
-* lock_page(), but dax pages do not use the page lock. This
-* also prevents changes
On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
+ mapping = VFS_I(ip)->i_mapping;
+ if (IS_ENABLED(CONFIG_MEMORY_FAILURE)) {
+ for (i = 0; i < rec->rm_blockcount; i++) {
+ error = mf_dax_kill_procs(mapping, rec->rm_offset + i,
+
On 7/30/2021 3:01 AM, Shiyang Ruan wrote:
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -214,6 +214,8 @@ enum dax_device_flags {
* @cdev: optional character interface for "device dax"
* @host: optional name for lookups where the device path is not available
* @private: dax
On Wed, Aug 04, 2021 at 11:56:27AM +0200, Christoph Hellwig wrote:
> Use bvec_virt instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/virtio_blk.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
Reviewed-by: Stefan Hajnoczi
signature.asc
On 8/4/2021 2:56 AM, Christoph Hellwig wrote:
Add a helper to get the virtual address for a bvec. This avoids that
all callers need to know about the page + offset representation.
Signed-off-by: Christoph Hellwig
Looks good.
Reviewed-by: Chaitanya Kulkarni
--
-ck
--
dm-devel mailing
On Wed, 2021-08-04 at 11:56 +0200, Christoph Hellwig wrote:
> Use bvec_virt instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/rbd.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> index
@@ -134,6 +134,12 @@ static int hwpoison_filter_dev(struct page *p)
if (PageSlab(p))
return -EINVAL;
+ if (pfn_valid(page_to_pfn(p))) {
+ if (is_device_fsdax_page(p))
+ return 0;
+ } else
+ return -EINVAL;
+
On Wed, Aug 04, 2021 at 11:56:34AM +0200, Christoph Hellwig wrote:
> Use bvec_virt instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/nvme/host/core.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvme/host/core.c
On 8/4/2021 2:56 AM, Christoph Hellwig wrote:
Use the bvec_virt helper to clean up the bio integrity processing a
little bit.
Signed-off-by: Christoph Hellwig
Looks good.
Reviewed-by: Chaitanya Kulkarni
--
-ck
--
dm-devel mailing list
dm-devel@redhat.com
Am 04.08.21 um 11:56 schrieb Christoph Hellwig:
> Use bvec_virt instead of open coding it.
>
> Signed-off-by: Christoph Hellwig
Looks good.
Reviewed-by: Stefan Haberland
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
20 matches
Mail list logo
