linux.git/drivers/dax/bus.c, branch v5.13

dax: avoid -Wempty-body warnings

2021-03-22T16:20:06+00:00

gcc warns about an empty body in an else statement:

drivers/dax/bus.c: In function 'do_id_store':
drivers/dax/bus.c:94:48: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body]
   94 |                         /* nothing to remove */;
      |                                                ^
drivers/dax/bus.c:99:43: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body]
   99 |                 /* dax_id already added */;
      |                                           ^

In both of these cases, the 'else' exists only to have a place to
add a comment, but that comment doesn't really explain that much
either, so the easiest way to shut up that warning is to just
remove the else.

Signed-off-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20210322114514.3490752-1-arnd@kernel.org
Signed-off-by: Dan Williams

dax-device: Make remove callback return void

2021-02-17T03:45:13+00:00

The driver core ignores the return value of struct bus_type::remove()
because there is only little that can be done. To simplify the quest to
make this function return void, let struct dax_device_driver::remove()
return void, too. All users already unconditionally return 0, this commit
makes it obvious that returning an error code isn't intended.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210205222842.34896-6-uwe@kleine-koenig.org
Signed-off-by: Dan Williams

device-dax: Fix error path in dax_driver_register

2021-02-17T03:42:03+00:00

The static variable match_always_count is supposed to track if there is
a driver registered that has .match_always set. If driver_register()
fails, the previous increment must be undone.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210205222842.34896-4-uwe@kleine-koenig.org
Signed-off-by: Dan Williams

device-dax: Properly handle drivers without remove callback

2021-02-17T03:41:26+00:00

If all resources are allocated in .probe() using devm_ functions it
might make sense to not provide a .remove() callback. Then the right
thing is to just return success.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210205222842.34896-3-uwe@kleine-koenig.org
Signed-off-by: Dan Williams

device-dax: Prevent registering drivers without probe callback

2021-02-17T03:40:20+00:00

The bus probe function dax_bus_probe() calls the probe callback without
checking it to be non-NULL. Prevent a NULL pointer exception if a driver
without a probe function is registered by refusing to register this
driver.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210205222842.34896-2-uwe@kleine-koenig.org
Signed-off-by: Dan Williams

device-dax: Fix default return code of range_parse()

2021-02-16T22:37:43+00:00

The return value of range_parse() indicates the size when it is
positive.  The error code should be negative.

Signed-off-by: Shiyang Ruan 
Reviewed-by: Joao Martins 
Link: https://lore.kernel.org/r/20210126021331.1059933-1-ruansy.fnst@cn.fujitsu.com
Reported-by: Zhang Qilong 
Fixes: 8490e2e25b5a ("device-dax: add a range mapping allocation attribute")
Signed-off-by: Dan Williams

device-dax: Avoid an unnecessary check in alloc_dev_dax_range()

2020-12-24T18:06:57+00:00

Swap the calling sequence of krealloc() and __request_region(), call the
latter first. In this way, the value of dev_dax->nr_range does not need to
be considered when __request_region() failed.

Signed-off-by: Zhen Lei 
Link: https://lore.kernel.org/r/20201219081840.1149-2-thunder.leizhen@huawei.com
Signed-off-by: Dan Williams

device-dax: Fix range release

2020-12-24T18:06:13+00:00

There are multiple locations that open-code the release of the last
range in a device-dax instance. Consolidate this into a new
dev_dax_trim_range() helper.

This also addresses a kmemleak report:

# cat /sys/kernel/debug/kmemleak
[..]
unreferenced object 0xffff976bd46f6240 (size 64):
   comm "ndctl", pid 23556, jiffies 4299514316 (age 5406.733s)
   hex dump (first 32 bytes):
     00 00 00 00 00 00 00 00 00 00 20 c3 37 00 00 00  .......... .7...
     ff ff ff 7f 38 00 00 00 00 00 00 00 00 00 00 00  ....8...........
   backtrace:
     [<00000000064003cf>] __kmalloc_track_caller+0x136/0x379
     [<00000000d85e3c52>] krealloc+0x67/0x92
     [<00000000d7d3ba8a>] __alloc_dev_dax_range+0x73/0x25c
     [<0000000027d58626>] devm_create_dev_dax+0x27d/0x416
     [<00000000434abd43>] __dax_pmem_probe+0x1c9/0x1000 [dax_pmem_core]
     [<0000000083726c1c>] dax_pmem_probe+0x10/0x1f [dax_pmem]
     [<00000000b5f2319c>] nvdimm_bus_probe+0x9d/0x340 [libnvdimm]
     [<00000000c055e544>] really_probe+0x230/0x48d
     [<000000006cabd38e>] driver_probe_device+0x122/0x13b
     [<0000000029c7b95a>] device_driver_attach+0x5b/0x60
     [<0000000053e5659b>] bind_store+0xb7/0xc3
     [<00000000d3bdaadc>] drv_attr_store+0x27/0x31
     [<00000000949069c5>] sysfs_kf_write+0x4a/0x57
     [<000000004a8b5adf>] kernfs_fop_write+0x150/0x1e5
     [<00000000bded60f0>] __vfs_write+0x1b/0x34
     [<00000000b92900f0>] vfs_write+0xd8/0x1d1

Reported-by: Jane Chu 
Cc: Zhen Lei 
Link: https://lore.kernel.org/r/160834570161.1791850.14911670304441510419.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams

device-dax: delete a redundancy check in dev_dax_validate_align()

2020-12-17T21:52:28+00:00

After we have done the alignment check for the length of each range, the
alignment check for dev_dax_size(dev_dax) is no longer needed, because it
get the sum of the length of each range.

Signed-off-by: Zhen Lei 
Link: https://lore.kernel.org/r/20201120092057.2144-1-thunder.leizhen@huawei.com
Signed-off-by: Dan Williams

device-dax: add a range mapping allocation attribute

2020-10-14T01:38:29+00:00

Add a sysfs attribute which denotes a range from the dax region to be
allocated.  It's an write only @mapping sysfs attribute in the format of
'-' to allocate a range.  @start and @end use hexadecimal
values and the @pgoff is implicitly ordered wrt to previous writes to
@mapping sysfs e.g.  a write of a range of length 1G the pgoff is
0..1G(-4K), a second write will use @pgoff for 1G+4K...

This range mapping interface is useful for:

 1) Application which want to implement its own allocation logic, and
    thus pick the desired ranges from dax_region.

 2) For use cases like VMM fast restart[0] where after kexec we want
    to the same gpa<->phys mappings (as originally created before kexec).

[0] https://static.sched.com/hosted_files/kvmforum2019/66/VMM-fast-restart_kvmforum2019.pdf

Signed-off-by: Joao Martins 
Signed-off-by: Dan Williams 
Signed-off-by: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Ard Biesheuvel 
Cc: Benjamin Herrenschmidt 
Cc: Ben Skeggs 
Cc: Bjorn Helgaas 
Cc: Borislav Petkov 
Cc: Boris Ostrovsky 
Cc: Brice Goglin 
Cc: Catalin Marinas 
Cc: Daniel Vetter 
Cc: Dave Hansen 
Cc: Dave Jiang 
Cc: David Airlie 
Cc: David Hildenbrand 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Hulk Robot 
Cc: Ingo Molnar 
Cc: Ira Weiny 
Cc: Jason Gunthorpe 
Cc: Jason Yan 
Cc: Jeff Moyer 
Cc: "Jérôme Glisse" 
Cc: Jia He 
Cc: Jonathan Cameron 
Cc: Juergen Gross 
Cc: kernel test robot 
Cc: Michael Ellerman 
Cc: Mike Rapoport 
Cc: Paul Mackerras 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Randy Dunlap 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Tom Lendacky 
Cc: Vishal Verma 
Cc: Vivek Goyal 
Cc: Wei Yang 
Cc: Will Deacon 
Link: https://lkml.kernel.org/r/159643106970.4062302.10402616567780784722.stgit@dwillia2-desk3.amr.corp.intel.com
Link: https://lore.kernel.org/r/20200716172913.19658-5-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/160106119570.30709.4548889722645210610.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Linus Torvalds