a crash when running strace from persistent memory
by Mikulas Patocka
Hi
There's a bug when you run strace from dax-based filesystem.
-- create real or emulated persistent memory device (/dev/pmem0)
mkfs.ext2 /dev/pmem0
-- mount it
mount -t ext2 -o dax /dev/pmem0 /mnt/test
-- copy the system to it (well, you can copy just a few files that are
needed for running strace and ls)
cp -ax / /mnt/test
-- bind the system directories
mount --bind /dev /mnt/test/dev
mount --bind /proc /mnt/test/proc
mount --bind /sys /mnt/test/sys
-- run strace on the ls command
chroot /mnt/test/ strace /bin/ls
You get this warning and ls is killed with SIGSEGV.
I bisected the problem and it is caused by the commit
17839856fd588f4ab6b789f482ed3ffd7c403e1f (gup: document and work around
"COW can break either way" issue). When I revert the patch (on the kernel
5.9-rc3), the bug goes away.
Mikulas
[ 84.190961] ------------[ cut here ]------------
[ 84.191504] WARNING: CPU: 6 PID: 1350 at mm/memory.c:2486 wp_page_copy.cold+0xdb/0xf6
[ 84.192398] Modules linked in: ext2 uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb fbdev ipv6 tun autofs4 binfmt_misc configfs af_packet mousedev virtio_balloon virtio_rng evdev rng_core pcspkr button raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx libcrc32c raid1 raid0 md_mod sd_mod t10_pi virtio_scsi virtio_net psmouse net_failover scsi_mod failover
[ 84.196301] CPU: 6 PID: 1350 Comm: strace Not tainted 5.9.0-rc3 #6
[ 84.197020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 84.197685] RIP: 0010:wp_page_copy.cold+0xdb/0xf6
[ 84.198231] Code: ff ff ff 0f 00 eb 8e 48 8b 3c 24 48 8b 74 24 08 ba 00 10 00 00 e8 33 87 1f 00 85 c0 74 1f 48 c7 c7 a7 2b ba 81 e8 cc b6 f0 ff <0f> 0b 48 8b 3c 24 e8 08 82 1f 00 41 be 01 00 00 00 eb ae 41 be 01
[ 84.200410] RSP: 0018:ffff88940c1dba58 EFLAGS: 00010282
[ 84.201035] RAX: 0000000000000006 RBX: ffff88940c1dbb00 RCX: 0000000000000000
[ 84.201842] RDX: 0000000000000003 RSI: ffffffff81b9c0fa RDI: 00000000ffffffff
[ 84.202650] RBP: ffffea004f0e4d80 R08: 0000000000000000 R09: 0000000000000000
[ 84.203460] R10: 0000000000000046 R11: 0000000000000000 R12: 0000000000000000
[ 84.204265] R13: ffff88940aa86318 R14: 00000000f7fac000 R15: ffff8893c8db3c40
[ 84.205083] FS: 00007fd8a8320740(0000) GS:ffff88940fb80000(0000) knlGS:0000000000000000
[ 84.206000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 84.206664] CR2: 00000000f7fac000 CR3: 00000013c93a6000 CR4: 00000000000006a0
[ 84.207481] Call Trace:
[ 84.207883] do_wp_page+0x172/0x6a0
[ 84.208285] handle_mm_fault+0xd0b/0x1540
[ 84.208753] __get_user_pages+0x21a/0x6c0
[ 84.209213] __get_user_pages_remote+0xc8/0x2a0
[ 84.209735] process_vm_rw_core.isra.0+0x1ac/0x440
[ 84.210318] ? __might_fault+0x26/0x40
[ 84.210758] ? _copy_from_user+0x6a/0xa0
[ 84.211208] ? __might_fault+0x26/0x40
[ 84.211642] ? _copy_from_user+0x6a/0xa0
[ 84.212091] process_vm_rw+0xd1/0x100
[ 84.212511] ? _copy_to_user+0x69/0x80
[ 84.212946] ? ptrace_get_syscall_info+0x9b/0x180
[ 84.213484] ? find_held_lock+0x2b/0x80
[ 84.213926] ? __x64_sys_ptrace+0x106/0x140
[ 84.214405] ? fpregs_assert_state_consistent+0x19/0x40
[ 84.215002] ? exit_to_user_mode_prepare+0x2d/0x120
[ 84.215556] __x64_sys_process_vm_readv+0x22/0x40
[ 84.216103] do_syscall_64+0x2d/0x80
[ 84.216518] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 84.217098] RIP: 0033:0x7fd8a84896da
[ 84.217512] Code: 48 8b 15 b9 f7 0b 00 f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 18 f0 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 36 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 06 c3 0f 1f 44 00 00 48 8b 15 81 f7 0b 00 f7
[ 84.219618] RSP: 002b:00007ffd08c3c678 EFLAGS: 00000246 ORIG_RAX: 0000000000000136
[ 84.220563] RAX: ffffffffffffffda RBX: 00000000f7fac000 RCX: 00007fd8a84896da
[ 84.221380] RDX: 0000000000000001 RSI: 00007ffd08c3c680 RDI: 0000000000000549
[ 84.222194] RBP: 00007ffd08c3c760 R08: 0000000000000001 R09: 0000000000000000
[ 84.222999] R10: 00007ffd08c3c690 R11: 0000000000000246 R12: 00000000f7faca80
[ 84.223804] R13: 0000000000000580 R14: 0000000000000549 R15: 00005589a50eee80
[ 84.223804] R13: 0000000000000580 R14: 0000000000000549 R15: 00005589a50eee80
[ 84.224612] ---[ end trace d8dbf2da5dc1b7ca ]---
1 year, 9 months
[PATCH] dax: fix for do not print error message for non-persistent memory block device
by Coly Li
When calling __generic_fsdax_supported(), a dax-unsupported device may
not have dax_dev as NULL, e.g. the dax related code block is not enabled
by Kconfig.
Therefore in __generic_fsdax_supported(), to check whether a device
supports DAX or not, the following order should be performed,
- If dax_dev pointer is NULL, it means the device driver explicitly
announce it doesn't support DAX. Then it is OK to directly return
false from __generic_fsdax_supported().
- If dax_dev pointer is NOT NULL, it might be because the driver doesn't
support DAX and not explicitly initialize related data structure. Then
bdev_dax_supported() should be called for further check.
IMHO if device driver desn't explicitly set its dax_dev pointer to NULL,
this is not a bug. Calling bdev_dax_supported() makes sure they can be
recognized as dax-unsupported eventually.
This patch does the following change for the above purpose,
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device")
Signed-off-by: Coly Li <colyli(a)suse.de>
Cc: Adrian Huang <ahuang12(a)lenovo.com>
Cc: Ira Weiny <ira.weiny(a)intel.com>
Cc: Jan Kara <jack(a)suse.com>
Cc: Mike Snitzer <snitzer(a)redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux(a)gmail.com>
Cc: Vishal Verma <vishal.l.verma(a)intel.com>
---
drivers/dax/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 32642634c1bb..e5767c83ea23 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -100,7 +100,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
return false;
}
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
pr_debug("%s: error: dax unsupported by block device\n",
bdevname(bdev, buf));
return false;
--
2.26.2
1 year, 9 months
[PATCH v2] powerpc/papr_scm: Limit the readability of 'perf_stats' sysfs attribute
by Vaibhav Jain
The newly introduced 'perf_stats' attribute uses the default access
mode of 0444 letting non-root users access performance stats of an
nvdimm and potentially force the kernel into issuing large number of
expensive HCALLs. Since the information exposed by this attribute
cannot be cached hence its better to ward of access to this attribute
from users who don't need to access these performance statistics.
Hence this patch updates access mode of 'perf_stats' attribute to
be only readable by root users.
Fixes: 2d02bf835e573 ('powerpc/papr_scm: Fetch nvdimm performance stats from PHYP')
Reported-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com>
---
Change-log:
v2:
* Instead of checking for perfmon_capable() inside show_perf_stats()
set the attribute as DEVICE_ATTR_ADMIN_RO [ Aneesh ]
* Update patch description
---
arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f439f0dfea7d1..a88a707a608aa 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -822,7 +822,7 @@ static ssize_t perf_stats_show(struct device *dev,
kfree(stats);
return rc ? rc : seq_buf_used(&s);
}
-DEVICE_ATTR_RO(perf_stats);
+DEVICE_ATTR_ADMIN_RO(perf_stats);
static ssize_t flags_show(struct device *dev,
struct device_attribute *attr, char *buf)
--
2.26.2
1 year, 9 months
[PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas
by Mike Rapoport
From: Mike Rapoport <rppt(a)linux.ibm.com>
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
v4 changes:
* rebase on v5.9-rc1
* Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill
* Make secret mappings exclusive by default and only require flags to
memfd_secret() system call for uncached mappings, thanks again Kirill :)
v3 changes:
* Squash kernel-parameters.txt update into the commit that added the
command line option.
* Make uncached mode explicitly selectable by architectures. For now enable
it only on x86.
v2 changes:
* Follow Michael's suggestion and name the new system call 'memfd_secret'
* Add kernel-parameters documentation about the boot option
* Fix i386-tinyconfig regression reported by the kbuild bot.
CONFIG_SECRETMEM now depends on !EMBEDDED to disable it on small systems
from one side and still make it available unconditionally on
architectures that support SET_DIRECT_MAP.
The file descriptor backing secret memory mappings is created using a
dedicated memfd_secret system call The desired protection mode for the
memory is configured using flags parameter of the system call. The mmap()
of the file descriptor created with memfd_secret() will create a "secret"
memory mapping. The pages in that mapping will be marked as not present in
the direct map and will have desired protection bits set in the user page
table. For instance, current implementation allows uncached mappings.
Although normally Linux userspace mappings are protected from other users,
such secret mappings are useful for environments where a hostile tenant is
trying to trick the kernel into giving them access to other tenants
mappings.
Additionally, the secret mappings may be used as a mean to protect guest
memory in a virtual machine host.
For demonstration of secret memory usage we've created a userspace library
[1] that does two things: the first is act as a preloader for openssl to
redirect all the OPENSSL_malloc calls to secret memory meaning any secret
keys get automatically protected this way and the other thing it does is
expose the API to the user who needs it. We anticipate that a lot of the
use cases would be like the openssl one: many toolkits that deal with
secret keys already have special handling for the memory to try to give
them greater protection, so this would simply be pluggable into the
toolkits without any need for user application modification.
I've hesitated whether to continue to use new flags to memfd_create() or to
add a new system call and I've decided to use a new system call after I've
started to look into man pages update. There would have been two completely
independent descriptions and I think it would have been very confusing.
Hiding secret memory mappings behind an anonymous file allows (ab)use of
the page cache for tracking pages allocated for the "secret" mappings as
well as using address_space_operations for e.g. page migration callbacks.
The anonymous file may be also used implicitly, like hugetlb files, to
implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm
ABIs in the future.
As the fragmentation of the direct map was one of the major concerns raised
during the previous postings, I've added an amortizing cache of PMD-size
pages to each file descriptor and an ability to reserve large chunks of the
physical memory at boot time and then use this memory as an allocation pool
for the secret memory areas.
v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org
v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org
v1: https://lore.kernel.org/lkml/20200720092435.17469-1-rppt@kernel.org/
rfc-v2: https://lore.kernel.org/lkml/20200706172051.19465-1-rppt@kernel.org/
rfc-v1: https://lore.kernel.org/lkml/20200130162340.GA14232@rapoport-lnx/
Mike Rapoport (6):
mm: add definition of PMD_PAGE_ORDER
mmap: make mlock_future_check() global
mm: introduce memfd_secret system call to create "secret" memory areas
arch, mm: wire up memfd_secret system call were relevant
mm: secretmem: use PMD-size pages to amortize direct map fragmentation
mm: secretmem: add ability to reserve memory at boot
arch/Kconfig | 7 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
fs/dax.c | 11 +-
include/linux/pgtable.h | 3 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/unistd.h | 7 +-
include/uapi/linux/magic.h | 1 +
include/uapi/linux/secretmem.h | 8 +
kernel/sys_ni.c | 2 +
mm/Kconfig | 4 +
mm/Makefile | 1 +
mm/internal.h | 3 +
mm/mmap.c | 5 +-
mm/secretmem.c | 451 +++++++++++++++++++++++++
20 files changed, 501 insertions(+), 12 deletions(-)
create mode 100644 include/uapi/linux/secretmem.h
create mode 100644 mm/secretmem.c
--
2.26.2
1 year, 9 months
[PATCH v4] dax: fix for do not print error message for non-persistent memory block device
by Coly Li
When calling __generic_fsdax_supported(), a dax-unsupported device may
not have dax_dev as NULL, e.g. the dax related code block is not enabled
by Kconfig.
Therefore in __generic_fsdax_supported(), to check whether a device
supports DAX or not, the following order should be performed,
- If dax_dev pointer is NULL, it means the device driver explicitly
announce it doesn't support DAX. Then it is OK to directly return
false from __generic_fsdax_supported().
- If dax_dev pointer is NOT NULL, it might be because the driver doesn't
support DAX and not explicitly initialize related data structure. Then
bdev_dax_supported() should be called for further check.
IMHO if device driver desn't explicitly set its dax_dev pointer to NULL,
this is not a bug. Calling bdev_dax_supported() makes sure they can be
recognized as dax-unsupported eventually.
This patch does the change for the above purpose.
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device")
Signed-off-by: Coly Li <colyli(a)suse.de>
Reviewed-and-tested-by: Adrian Huang <ahuang12(a)lenovo.com>
Reviewed-by: Ira Weiny <ira.weiny(a)intel.com>
Reviewed-by: Mike Snitzer <snitzer(a)redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux(a)gmail.com>
Cc: Jan Kara <jack(a)suse.com>
Cc: Vishal Verma <vishal.l.verma(a)intel.com>
---
Changelog:
v4: add Reviewed-by from Ira Weiny, remove the diff-like format comment
from commit log which suggested by Mike Snitzer.
v3: add more Reviewed-by from Mike Snitzer and Pankaj Gupta.
v2: add Reviewed-and-Tested-by from Adrian Huang.
v1: initial version.
drivers/dax/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 32642634c1bb..e5767c83ea23 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -100,7 +100,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
return false;
}
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
pr_debug("%s: error: dax unsupported by block device\n",
bdevname(bdev, buf));
return false;
--
2.26.2
1 year, 9 months
[PATCH v2] dax: fix for do not print error message for non-persistent memory block device
by Coly Li
When calling __generic_fsdax_supported(), a dax-unsupported device may
not have dax_dev as NULL, e.g. the dax related code block is not enabled
by Kconfig.
Therefore in __generic_fsdax_supported(), to check whether a device
supports DAX or not, the following order should be performed,
- If dax_dev pointer is NULL, it means the device driver explicitly
announce it doesn't support DAX. Then it is OK to directly return
false from __generic_fsdax_supported().
- If dax_dev pointer is NOT NULL, it might be because the driver doesn't
support DAX and not explicitly initialize related data structure. Then
bdev_dax_supported() should be called for further check.
IMHO if device driver desn't explicitly set its dax_dev pointer to NULL,
this is not a bug. Calling bdev_dax_supported() makes sure they can be
recognized as dax-unsupported eventually.
This patch does the following change for the above purpose,
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device")
Signed-off-by: Coly Li <colyli(a)suse.de>
Reviewed-and-Tested-by: Adrian Huang <ahuang12(a)lenovo.com>
Cc: Ira Weiny <ira.weiny(a)intel.com>
Cc: Jan Kara <jack(a)suse.com>
Cc: Mike Snitzer <snitzer(a)redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux(a)gmail.com>
Cc: Vishal Verma <vishal.l.verma(a)intel.com>
---
Changelog:
v2: add Reviewed-and-Tested-by from Adrian Huang.
v1: initial version.
drivers/dax/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 32642634c1bb..e5767c83ea23 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -100,7 +100,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
return false;
}
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
pr_debug("%s: error: dax unsupported by block device\n",
bdevname(bdev, buf));
return false;
--
2.26.2
1 year, 9 months
[PATCH v3] dax: fix for do not print error message for non-persistent memory block device
by Coly Li
When calling __generic_fsdax_supported(), a dax-unsupported device may
not have dax_dev as NULL, e.g. the dax related code block is not enabled
by Kconfig.
Therefore in __generic_fsdax_supported(), to check whether a device
supports DAX or not, the following order should be performed,
- If dax_dev pointer is NULL, it means the device driver explicitly
announce it doesn't support DAX. Then it is OK to directly return
false from __generic_fsdax_supported().
- If dax_dev pointer is NOT NULL, it might be because the driver doesn't
support DAX and not explicitly initialize related data structure. Then
bdev_dax_supported() should be called for further check.
IMHO if device driver desn't explicitly set its dax_dev pointer to NULL,
this is not a bug. Calling bdev_dax_supported() makes sure they can be
recognized as dax-unsupported eventually.
This patch does the following change for the above purpose,
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device")
Signed-off-by: Coly Li <colyli(a)suse.de>
Reviewed-and-Tested-by: Adrian Huang <ahuang12(a)lenovo.com>
Reviewed-by: Mike Snitzer <snitzer(a)redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux(a)gmail.com>
Cc: Ira Weiny <ira.weiny(a)intel.com>
Cc: Jan Kara <jack(a)suse.com>
Cc: Vishal Verma <vishal.l.verma(a)intel.com>
---
Changelog:
v3: add more Reviewed-by from Mike Snitzer and Pankaj Gupta.
v2: add Reviewed-and-Tested-by from Adrian Huang.
v1: initial version.
drivers/dax/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 32642634c1bb..e5767c83ea23 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -100,7 +100,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
return false;
}
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
pr_debug("%s: error: dax unsupported by block device\n",
bdevname(bdev, buf));
return false;
--
2.26.2
1 year, 9 months
flood of "dm-X: error: dax access failed" due to 5.9 commit
231609785cbfb
by Mike Snitzer
5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
__generic_fsdax_supported()") switched from pr_debug() to pr_info().
The justification in the commit header is really inadequate. If there
is a problem that you need to drill in on, repeat the testing after
enabling the dynamic debugging.
Otherwise, now all DM devices that aren't layered on DAX capable devices
spew really confusing noise to users when they simply activate their
non-DAX DM devices:
[66567.129798] dm-6: error: dax access failed (-5)
[66567.134400] dm-6: error: dax access failed (-5)
[66567.139152] dm-6: error: dax access failed (-5)
[66567.314546] dm-2: error: dax access failed (-95)
[66567.319380] dm-2: error: dax access failed (-95)
[66567.324254] dm-2: error: dax access failed (-95)
[66567.479025] dm-2: error: dax access failed (-95)
[66567.483713] dm-2: error: dax access failed (-95)
[66567.488722] dm-2: error: dax access failed (-95)
[66567.494061] dm-2: error: dax access failed (-95)
[66567.498823] dm-2: error: dax access failed (-95)
[66567.503693] dm-2: error: dax access failed (-95)
commit 231609785cbfb must be reverted.
Please advise, thanks.
Mike
1 year, 9 months
remove revalidate_disk()
by Christoph Hellwig
Hi Jens,
this series removes the revalidate_disk() function, which has been a
really odd duck in the last years. The prime reason why most people
use it is because it propagates a size change from the gendisk to
the block_device structure. But it also calls into the rather ill
defined ->revalidate_disk method which is rather useless for the
callers. So this adds a new helper to just propagate the size, and
cleans up all kinds of mess around this area. Follow on patches
will eventuall kill of ->revalidate_disk entirely, but ther are a lot
more patches needed for that.
Diffstat:
Documentation/filesystems/locking.rst | 3 --
block/genhd.c | 9 ++----
drivers/block/nbd.c | 8 ++---
drivers/block/rbd.c | 2 -
drivers/block/rnbd/rnbd-clt.c | 10 +------
drivers/block/virtio_blk.c | 2 -
drivers/block/zram/zram_drv.c | 4 +-
drivers/md/dm-raid.c | 2 -
drivers/md/md-cluster.c | 6 ++--
drivers/md/md-linear.c | 2 -
drivers/md/md.c | 10 +++----
drivers/md/md.h | 2 -
drivers/nvdimm/blk.c | 3 --
drivers/nvdimm/btt.c | 3 --
drivers/nvdimm/bus.c | 9 ++----
drivers/nvdimm/nd.h | 2 -
drivers/nvdimm/pmem.c | 3 --
drivers/nvme/host/core.c | 16 +++++++----
drivers/scsi/sd.c | 6 ++--
fs/block_dev.c | 46 ++++++++++++++++------------------
include/linux/blk_types.h | 4 ++
include/linux/genhd.h | 6 ++--
22 files changed, 74 insertions(+), 84 deletions(-)
1 year, 9 months
[PATCH 1/3] ndctl/namespace: Skip seed namespaces when processing all namespaces.
by Michal Suchanek
The seed namespaces are exposed by the kernel but most operations are
not valid on seed namespaces.
When processing all namespaces the user gets confusing errors from ndctl
trying to process seed namespaces. The kernel does not provide any way
to tell that a namspace is seed namespace but skipping namespaces with
zero size and UUID is a good heuristic.
The user can still specify the namespace by name directly in case
processing it is desirable.
Fixes: #41
Link: https://patchwork.kernel.org/patch/11473645/
Reviewed-by: Santosh S <santosh(a)fossix.org>
Tested-by: Harish Sriram <harish(a)linux.ibm.com>
Signed-off-by: Michal Suchanek <msuchanek(a)suse.de>
---
ndctl/namespace.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/ndctl/namespace.c b/ndctl/namespace.c
index e734248c9752..3fabe4799d75 100644
--- a/ndctl/namespace.c
+++ b/ndctl/namespace.c
@@ -2171,9 +2171,19 @@ static int do_xaction_namespace(const char *namespace,
ndctl_namespace_foreach_safe(region, ndns, _n) {
ndns_name = ndctl_namespace_get_devname(ndns);
- if (strcmp(namespace, "all") != 0
- && strcmp(namespace, ndns_name) != 0)
- continue;
+ if (strcmp(namespace, "all") == 0) {
+ static const uuid_t zero_uuid;
+ uuid_t uuid;
+
+ ndctl_namespace_get_uuid(ndns, uuid);
+ if (!ndctl_namespace_get_size(ndns) &&
+ !memcmp(uuid, zero_uuid, sizeof(uuid_t)))
+ continue;
+ } else {
+ if (strcmp(namespace, ndns_name) != 0)
+ continue;
+ }
+
switch (action) {
case ACTION_DISABLE:
rc = ndctl_namespace_disable_safe(ndns);
--
2.28.0
1 year, 10 months