linux-toradex.git/drivers/dax, branch v5.9-rc5

Merge tag 'libnvdimm-fix-v5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2020-09-12T19:43:58+00:00

Pull libnvdimm fix from Vishal Verma:
 "Fix detection of dax support for block devices.

  Previous fixes in this area, which only affected printing of debug
  messages, had an incorrect condition for detection of dax. This fix
  should finally do the right thing"

* tag 'libnvdimm-fix-v5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  dax: fix detection of dax support for non-persistent memory block devices

Merge tag 'for-linus-5.9-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2020-09-06T16:59:27+00:00

Pull xen updates from Juergen Gross:
 "A small series for fixing a problem with Xen PVH guests when running
  as backends (e.g. as dom0).

  Mapping other guests' memory is now working via ZONE_DEVICE, thus not
  requiring to abuse the memory hotplug functionality for that purpose"

* tag 'for-linus-5.9-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen: add helpers to allocate unpopulated memory
  memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC
  xen/balloon: add header guard

memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC

2020-09-04T07:59:59+00:00

This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
being used by non DAX devices.

No functional change intended.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Ira Weiny 
Acked-by: Andrew Morton 
Reviewed-by: Pankaj Gupta 
Link: https://lore.kernel.org/r/20200901083326.21264-3-roger.pau@citrix.com
Signed-off-by: Juergen Gross

dax: fix detection of dax support for non-persistent memory block devices

2020-09-03T18:28:03+00:00

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 of operations 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.

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.

Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device")
Cc: Jan Kara 
Cc: Vishal Verma 
Reviewed-and-tested-by: Adrian Huang 
Reviewed-by: Ira Weiny 
Reviewed-by: Mike Snitzer 
Reviewed-by: Pankaj Gupta 
Signed-off-by: Coly Li 
Signed-off-by: Vishal Verma 
Link: https://lore.kernel.org/r/20200903161625.19524-1-colyli@suse.de

dax: do not print error message for non-persistent memory block device

2020-08-20T17:43:18+00:00

Commit 231609785cbf ("dax: print error message by pr_info()
in __generic_fsdax_supported()") happens to print the following
error message during booting when the non-persistent memory block
devices are configured by device mapper. Those error messages are
caused by the variable 'dax_dev' is NULL. Users might be confused
with those error messages since they do not use the persistent
memory device. Moreover, users might scare about "what's wrong
with my disks" because they see the 'error' and 'failed' keywords.

  # dmesg | grep fail
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdk3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)
  sdb3: error: dax access failed (-95)

  # lsblk
  NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
  sda               8:0    0   1.1T  0 disk
  ├─sda1            8:1    0   156M  0 part
  ├─sda2            8:2    0    40G  0 part
  └─sda3            8:3    0   1.1T  0 part
  sdb               8:16   0   1.1T  0 disk
  ├─sdb1            8:17   0   600M  0 part
  ├─sdb2            8:18   0     1G  0 part
  └─sdb3            8:19   0   1.1T  0 part
    ├─rhel00-swap 254:3    0     4G  0 lvm
    ├─rhel00-home 254:4    0     1T  0 lvm
    └─rhel00-root 254:5    0    50G  0 lvm
  sdc               8:32   0   1.1T  0 disk
  sdd               8:48   0   1.1T  0 disk
  sde               8:64   0   1.1T  0 disk
  sdf               8:80   0   1.1T  0 disk
  sdg               8:96   0   1.1T  0 disk
  sdh               8:112  0   3.3T  0 disk
  ├─sdh1            8:113  0   500M  0 part /boot/efi
  ├─sdh2            8:114  0    40G  0 part /
  ├─sdh3            8:115  0   2.9T  0 part /home
  └─sdh4            8:116  0 314.6G  0 part [SWAP]
  sdi               8:128  0   1.1T  0 disk
  sdj               8:144  0   3.3T  0 disk
  ├─sdj1            8:145  0   512M  0 part
  └─sdj2            8:146  0   3.3T  0 part
  sdk               8:160  0 119.2G  0 disk
  ├─sdk1            8:161  0   200M  0 part
  ├─sdk2            8:162  0     1G  0 part
  └─sdk3            8:163  0   118G  0 part
    ├─rhel-swap   254:0    0     4G  0 lvm
    ├─rhel-home   254:1    0    64G  0 lvm
    └─rhel-root   254:2    0    50G  0 lvm
  sdl               8:176  0 119.2G  0 disk

The call path is shown as follows:
  dm_table_determine_type
    dm_table_supports_dax
     device_supports_dax
       generic_fsdax_supported
        __generic_fsdax_supported

With the disk configuration listing from the command 'lsblk',
the member 'dev->dax_dev' of the block devices 'sdb3' and 'sdk3'
(configured by device mapper) is NULL in function
generic_fsdax_supported() because the member is configured in
function open_table_device().

To prevent the confusing error messages in this scenario (this is
normal behavior), just print those error messages by pr_debug()
by checking if dax_dev is NULL and the block device does not support
DAX.

Link: https://lore.kernel.org/r/20200819154236.24191-1-adrianhuang0701@gmail.com
Fixes: 231609785cbf ("dax: print error message by pr_info() in __generic_fsdax_supported()")
Cc: Coly Li 
Cc: Dan Williams 
Cc: Alasdair Kergon 
Cc: Mike Snitzer 
Acked-by: Coly Li 
Signed-off-by: Adrian Huang 
Signed-off-by: Vishal Verma

Merge tag 'libnvdimm-for-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2020-08-11T17:59:19+00:00

Pull libnvdimm updayes from Vishal Verma:
 "You'd normally receive this pull request from Dan Williams, but he's
  busy watching a newborn (Congrats Dan!), so I'm watching libnvdimm
  this cycle.

  This adds a new feature in libnvdimm - 'Runtime Firmware Activation',
  and a few small cleanups and fixes in libnvdimm and DAX. I'd
  originally intended to make separate topic-based pull requests - one
  for libnvdimm, and one for DAX, but some of the DAX material fell out
  since it wasn't quite ready.

  Summary:

   - add 'Runtime Firmware Activation' support for NVDIMMs that
     advertise the relevant capability

   - misc libnvdimm and DAX cleanups"

* tag 'libnvdimm-for-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  libnvdimm/security: ensure sysfs poll thread woke up and fetch updated attr
  libnvdimm/security: the 'security' attr never show 'overwrite' state
  libnvdimm/security: fix a typo
  ACPI: NFIT: Fix ARS zero-sized allocation
  dax: Fix incorrect argument passed to xas_set_err()
  ACPI: NFIT: Add runtime firmware activate support
  PM, libnvdimm: Add runtime firmware activation support
  libnvdimm: Convert to DEVICE_ATTR_ADMIN_RO()
  drivers/dax: Expand lock scope to cover the use of addresses
  fs/dax: Remove unused size parameter
  dax: print error message by pr_info() in __generic_fsdax_supported()
  driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
  tools/testing/nvdimm: Emulate firmware activation commands
  tools/testing/nvdimm: Prepare nfit_ctl_test() for ND_CMD_CALL emulation
  tools/testing/nvdimm: Add command debug messages
  tools/testing/nvdimm: Cleanup dimm index passing
  ACPI: NFIT: Define runtime firmware activation commands
  ACPI: NFIT: Move bus_dsm_mask out of generic nvdimm_bus_descriptor
  libnvdimm: Validate command family indices

drivers/dax: Expand lock scope to cover the use of addresses

2020-07-28T17:50:08+00:00

The addition of PKS protection to dax read lock/unlock will require that
the address returned by dax_direct_access() be protected by this lock.

Correct the locking by ensuring that the use of kaddr and end_kaddr
are covered by the dax read lock/unlock.

Link: https://lore.kernel.org/r/20200717072056.73134-12-ira.weiny@intel.com
Reviewed-by: Dan Williams 
Signed-off-by: Ira Weiny 
Signed-off-by: Vishal Verma

dax: print error message by pr_info() in __generic_fsdax_supported()

2020-07-28T17:49:27+00:00

In struct dax_operations, the callback routine dax_supported() returns
a bool type result. For false return value, the caller has no idea
whether the device does not support dax at all, or it is just some mis-
configuration issue.

An example is formatting an Ext4 file system on pmem device on top of
a NVDIMM namespace by,
 # mkfs.ext4 /dev/pmem0
If the fs block size does not match kernel space memory page size (which
is possible on non-x86 platform), mount this Ext4 file system will fail,
  # mount -o dax /dev/pmem0 /mnt
  mount: /mnt: wrong fs type, bad option, bad superblock on /dev/pmem0,
  missing codepage or helper program, or other error.
And from the dmesg output there is only the following information,
  [  307.853148] EXT4-fs (pmem0): DAX unsupported by block device.

The above information is quite confusing. Because definitely the pmem0
device supports dax operation, and the super block is consistent as how
it was created by mkfs.ext4.

Indeed the failure is from __generic_fsdax_supported() by the following
code piece,
        if (blocksize != PAGE_SIZE) {
               pr_debug("%s: error: unsupported blocksize for dax\n",
                                bdevname(bdev, buf));
                return false;
        }
It is because the Ext4 block size is 4KB and kernel page size is 8KB or
16KB.

It is not simple to make dax_supported() from struct dax_operations
or __generic_fsdax_supported() to return exact failure type right now.
So the simplest fix is to use pr_info() to print all the error messages
inside __generic_fsdax_supported(). Then users may find informative clue
from the kernel message at least.

Message printed by pr_debug() is very easy to be ignored by users. This
patch prints error message by pr_info() in __generic_fsdax_supported(),
when then mount fails, following lines can be found from dmesg output,
 [ 2705.500885] pmem0: error: unsupported blocksize for dax
 [ 2705.500888] EXT4-fs (pmem0): DAX unsupported by block device.
Now the users may have idea the mount failure is from pmem driver for
unsupported block size.

Link: https://lore.kernel.org/r/20200725162450.95999-1-colyli@suse.de
Cc: Dan Williams 
Cc: Anthony Iliopoulos 
Reported-by: Michal Suchanek 
Suggested-by: Jan Kara 
Reviewed-by: Jan Kara 
Reviewed-by: Ira Weiny 
Reviewed-by: Pankaj Gupta 
Signed-off-by: Coly Li 
Signed-off-by: Vishal Verma

block: remove the bd_queue field from struct block_device

2020-07-01T14:08:20+00:00

Just use bd_disk->queue instead.

Reviewed-by: Johannes Thumshirn 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

device-dax: add memory via add_memory_driver_managed()

2020-06-05T02:06:23+00:00

Currently, when adding memory, we create entries in /sys/firmware/memmap/
as "System RAM".  This will lead to kexec-tools to add that memory to the
fixed-up initial memmap for a kexec kernel (loaded via kexec_load()).  The
memory will be considered initial System RAM by the kexec'd kernel and can
no longer be reconfigured.  This is not what happens during a real reboot.

Let's add our memory via add_memory_driver_managed() now, so we won't
create entries in /sys/firmware/memmap/ and indicate the memory as "System
RAM (kmem)" in /proc/iomem.  This allows everybody (especially
kexec-tools) to identify that this memory is special and has to be treated
differently than ordinary (hotplugged) System RAM.

Before configuring the namespace:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-33fffffff : namespace0.0
	3280000000-32ffffffff : PCI Bus 0000:00

After configuring the namespace:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  148200000-33fffffff : dax0.0
	3280000000-32ffffffff : PCI Bus 0000:00

After loading kmem before this change:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  150000000-33fffffff : dax0.0
	    150000000-33fffffff : System RAM
	3280000000-32ffffffff : PCI Bus 0000:00

After loading kmem after this change:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  150000000-33fffffff : dax0.0
	    150000000-33fffffff : System RAM (kmem)
	3280000000-32ffffffff : PCI Bus 0000:00

After a proper reboot:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  148200000-33fffffff : dax0.0
	3280000000-32ffffffff : PCI Bus 0000:00

Within the kexec kernel before this change:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  150000000-33fffffff : System RAM
	3280000000-32ffffffff : PCI Bus 0000:00

Within the kexec kernel after this change:
	[root@localhost ~]# cat /proc/iomem
	...
	140000000-33fffffff : Persistent Memory
	  140000000-1481fffff : namespace0.0
	  148200000-33fffffff : dax0.0
	3280000000-32ffffffff : PCI Bus 0000:00

/sys/firmware/memmap/ before this change:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffdf000 (System RAM)
	00000000bffdf000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)
	0000000150000000-0000000340000000 (System RAM)

/sys/firmware/memmap/ after a proper reboot:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffdf000 (System RAM)
	00000000bffdf000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)

/sys/firmware/memmap/ after this change:
	0000000000000000-000000000009fc00 (System RAM)
	000000000009fc00-00000000000a0000 (Reserved)
	00000000000f0000-0000000000100000 (Reserved)
	0000000000100000-00000000bffdf000 (System RAM)
	00000000bffdf000-00000000c0000000 (Reserved)
	00000000feffc000-00000000ff000000 (Reserved)
	00000000fffc0000-0000000100000000 (Reserved)
	0000000100000000-0000000140000000 (System RAM)

kexec-tools already seem to basically ignore any System RAM that's not on
top level when searching for areas to place kexec images - but also for
determining crash areas to dump via kdump.  Changing the resource name
won't have an impact.

Handle unloading of the driver after memory hotremove failed properly, by
duplicating the string if necessary.

Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Acked-by: Pankaj Gupta 
Cc: Michal Hocko 
Cc: Pankaj Gupta 
Cc: Wei Yang 
Cc: Baoquan He 
Cc: Dave Hansen 
Cc: Eric Biederman 
Cc: Pavel Tatashin 
Cc: Dan Williams 
Link: http://lkml.kernel.org/r/20200508084217.9160-5-david@redhat.com
Signed-off-by: Linus Torvalds