#
1b764601 |
| 26-Aug-2021 |
Christoph Hellwig <hch@lst.de> |
dax: mark dax_get_by_host static
And move the code around a bit to avoid a forward declaration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Li
dax: mark dax_get_by_host static
And move the code around a bit to avoid a forward declaration.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/r/20210826135510.6293-5-hch@lst.de Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
39b6389a |
| 26-Aug-2021 |
Christoph Hellwig <hch@lst.de> |
dax: stop using bdevname
Just use the %pg format specifier instead.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/
dax: stop using bdevname
Just use the %pg format specifier instead.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/r/20210826135510.6293-3-hch@lst.de Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40 |
|
#
b05d4c57 |
| 25-May-2021 |
Ira Weiny <ira.weiny@intel.com> |
dax: Ensure errno is returned from dax_direct_access
If the caller specifies a negative nr_pages that is an invalid parameter.
Return -EINVAL to ensure callers get an errno if they want to check it
dax: Ensure errno is returned from dax_direct_access
If the caller specifies a negative nr_pages that is an invalid parameter.
Return -EINVAL to ensure callers get an errno if they want to check it.
Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> Link: https://lore.kernel.org/r/20210525172428.3634316-4-ira.weiny@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
6f24784f |
| 31-Jan-2021 |
Al Viro <viro@zeniv.linux.org.uk> |
whack-a-mole: don't open-code iminor/imajor
several instances creeped back into the tree...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
Revision tags: v5.10 |
|
#
1aa57431 |
| 01-Dec-2020 |
Wang Hai <wanghai38@huawei.com> |
device-dax/core: Fix memory leak when rmmod dax.ko
When I repeatedly modprobe and rmmod dax.ko, kmemleak report a memory leak as follows:
unreferenced object 0xffff9a5588c05088 (size 8): comm "mo
device-dax/core: Fix memory leak when rmmod dax.ko
When I repeatedly modprobe and rmmod dax.ko, kmemleak report a memory leak as follows:
unreferenced object 0xffff9a5588c05088 (size 8): comm "modprobe", pid 261, jiffies 4294693644 (age 42.063s) ... backtrace: [<00000000e007ced0>] kstrdup+0x35/0x70 [<000000002ae73897>] kstrdup_const+0x3d/0x50 [<000000002b00c9c3>] kvasprintf_const+0xbc/0xf0 [<000000008023282f>] kobject_set_name_vargs+0x3b/0xd0 [<00000000d2cbaa4e>] kobject_set_name+0x62/0x90 [<00000000202e7a22>] bus_register+0x7f/0x2b0 [<000000000b77792c>] 0xffffffffc02840f7 [<000000002d5be5ac>] 0xffffffffc02840b4 [<00000000dcafb7cd>] do_one_initcall+0x58/0x240 [<00000000049fe480>] do_init_module+0x56/0x1e2 [<0000000022671491>] load_module+0x2517/0x2840 [<000000001a2201cb>] __do_sys_finit_module+0x9c/0xe0 [<000000003eb304e7>] do_syscall_64+0x33/0x40 [<0000000051c5fd06>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
When rmmod dax is executed, dax_bus_exit() is missing. This patch can fix this bug.
Fixes: 9567da0b408a ("device-dax: Introduce bus + driver model") Cc: <stable@vger.kernel.org> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20201201135929.66530-1-wanghai38@huawei.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
224adad2 |
| 01-Dec-2020 |
Wang Hai <wanghai38@huawei.com> |
device-dax/core: Fix memory leak when rmmod dax.ko
commit 1aa574312518ef1d60d2dc62d58f7021db3b163a upstream.
When I repeatedly modprobe and rmmod dax.ko, kmemleak report a memory leak as follows:
device-dax/core: Fix memory leak when rmmod dax.ko
commit 1aa574312518ef1d60d2dc62d58f7021db3b163a upstream.
When I repeatedly modprobe and rmmod dax.ko, kmemleak report a memory leak as follows:
unreferenced object 0xffff9a5588c05088 (size 8): comm "modprobe", pid 261, jiffies 4294693644 (age 42.063s) ... backtrace: [<00000000e007ced0>] kstrdup+0x35/0x70 [<000000002ae73897>] kstrdup_const+0x3d/0x50 [<000000002b00c9c3>] kvasprintf_const+0xbc/0xf0 [<000000008023282f>] kobject_set_name_vargs+0x3b/0xd0 [<00000000d2cbaa4e>] kobject_set_name+0x62/0x90 [<00000000202e7a22>] bus_register+0x7f/0x2b0 [<000000000b77792c>] 0xffffffffc02840f7 [<000000002d5be5ac>] 0xffffffffc02840b4 [<00000000dcafb7cd>] do_one_initcall+0x58/0x240 [<00000000049fe480>] do_init_module+0x56/0x1e2 [<0000000022671491>] load_module+0x2517/0x2840 [<000000001a2201cb>] __do_sys_finit_module+0x9c/0xe0 [<000000003eb304e7>] do_syscall_64+0x33/0x40 [<0000000051c5fd06>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
When rmmod dax is executed, dax_bus_exit() is missing. This patch can fix this bug.
Fixes: 9567da0b408a ("device-dax: Introduce bus + driver model") Cc: <stable@vger.kernel.org> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20201201135929.66530-1-wanghai38@huawei.com Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10 |
|
#
d4c5da50 |
| 17-Sep-2020 |
Adrian Huang <ahuang12@lenovo.com> |
dax: Fix stack overflow when mounting fsdax pmem device
When mounting fsdax pmem device, commit 6180bb446ab6 ("dax: fix detection of dax support for non-persistent memory block devices") introduces
dax: Fix stack overflow when mounting fsdax pmem device
When mounting fsdax pmem device, commit 6180bb446ab6 ("dax: fix detection of dax support for non-persistent memory block devices") introduces the stack overflow [1][2]. Here is the call path for mounting ext4 file system: ext4_fill_super bdev_dax_supported __bdev_dax_supported dax_supported generic_fsdax_supported __generic_fsdax_supported bdev_dax_supported
The call path leads to the infinite calling loop, so we cannot call bdev_dax_supported() in __generic_fsdax_supported(). The sanity checking of the variable 'dax_dev' is moved prior to the two bdev_dax_pgoff() checks [3][4].
[1] https://lore.kernel.org/linux-nvdimm/1420999447.1004543.1600055488770.JavaMail.zimbra@redhat.com/ [2] https://lore.kernel.org/linux-nvdimm/alpine.LRH.2.02.2009141131220.30651@file01.intranet.prod.int.rdu2.redhat.com/ [3] https://lore.kernel.org/linux-nvdimm/CA+RJvhxBHriCuJhm-D8NvJRe3h2MLM+ZMFgjeJjrRPerMRLvdg@mail.gmail.com/ [4] https://lore.kernel.org/linux-nvdimm/20200903160608.GU878166@iweiny-DESK2.sc.intel.com/
Fixes: 6180bb446ab6 ("dax: fix detection of dax support for non-persistent memory block devices") Reported-by: Yi Zhang <yi.zhang@redhat.com> Reported-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Reviewed-by: Jan Kara <jack@suse.cz> Tested-by: Ritesh Harjani <riteshh@linux.ibm.com> Cc: Coly Li <colyli@suse.de> Cc: Ira Weiny <ira.weiny@intel.com> Cc: John Pittman <jpittman@redhat.com> Link: https://lore.kernel.org/r/20200917111549.6367-1-adrianhuang0701@gmail.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
e2ec5128 |
| 20-Sep-2020 |
Jan Kara <jack@suse.cz> |
dm: Call proper helper to determine dax support
DM was calling generic_fsdax_supported() to determine whether a device referenced in the DM table supports DAX. However this is a helper for "leaf" de
dm: Call proper helper to determine dax support
DM was calling generic_fsdax_supported() to determine whether a device referenced in the DM table supports DAX. However this is a helper for "leaf" device drivers so that they don't have to duplicate common generic checks. High level code should call dax_supported() helper which that calls into appropriate helper for the particular device. This problem manifested itself as kernel messages:
dm-3: error: dax access failed (-95)
when lvm2-testsuite run in cases where a DM device was stacked on top of another DM device.
Fixes: 7bf7eac8d648 ("dax: Arrange for dax_supported check to span multiple devices") Cc: <stable@vger.kernel.org> Tested-by: Adrian Huang <ahuang12@lenovo.com> Signed-off-by: Jan Kara <jack@suse.cz> Acked-by: Mike Snitzer <snitzer@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/160061715195.13131.5503173247632041975.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60 |
|
#
1a9d5d40 |
| 19-Aug-2020 |
Vivek Goyal <vgoyal@redhat.com> |
dax: Modify bdev_dax_pgoff() to handle NULL bdev
virtiofs does not have a block device but it has dax device. Modify bdev_dax_pgoff() to be able to handle that.
If there is no bdev, that means dax
dax: Modify bdev_dax_pgoff() to handle NULL bdev
virtiofs does not have a block device but it has dax device. Modify bdev_dax_pgoff() to be able to handle that.
If there is no bdev, that means dax offset is 0. (It can't be a partition block device starting at an offset in dax device).
This is little hackish. There have been discussions about getting rid of dax not supporting partitions.
https://lore.kernel.org/linux-fsdevel/20200107125159.GA15745@infradead.org/
IMHO, this path can easily break exisitng users. For example ioctl(BLKPG_ADD_PARTITION) will start breaking on block devices supporting DAX. Also, I personally find it very useful to be able to partition dax devices and still be able to use DAX.
Alternatively, I tried to store offset into dax device information in iomap interface, but that got NACKed.
https://lore.kernel.org/linux-fsdevel/20200217133117.GB20444@infradead.org/
I can't think of a good path to solve this issue properly. So to make progress, it seems this patch is least bad option for now and I hope we can take it.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Christoph Hellwig <hch@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Vishal L Verma <vishal.l.verma@intel.com> Cc: "Weiny, Ira" <ira.weiny@intel.com> Cc: linux-nvdimm@lists.01.org Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
show more ...
|
#
6180bb44 |
| 03-Sep-2020 |
Coly Li <colyli@suse.de> |
dax: fix detection of dax support for non-persistent memory block devices
When calling __generic_fsdax_supported(), a dax-unsupported device may not have dax_dev as NULL, e.g. the dax related code b
dax: fix detection of dax support for non-persistent memory block devices
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 <jack@suse.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Reviewed-and-tested-by: Adrian Huang <ahuang12@lenovo.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Mike Snitzer <snitzer@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Link: https://lore.kernel.org/r/20200903161625.19524-1-colyli@suse.de
show more ...
|
#
c2affe92 |
| 19-Aug-2020 |
Adrian Huang <ahuang12@lenovo.com> |
dax: do not print error message for non-persistent memory block device
Commit 231609785cbf ("dax: print error message by pr_info() in __generic_fsdax_supported()") happens to print the following err
dax: do not print error message for non-persistent memory block device
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 <colyli@suse.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@redhat.com> Acked-by: Coly Li <colyli@suse.de> Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
show more ...
|
Revision tags: v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53 |
|
#
eedfd73d |
| 17-Jul-2020 |
Ira Weiny <ira.weiny@intel.com> |
drivers/dax: Expand lock scope to cover the use of addresses
The addition of PKS protection to dax read lock/unlock will require that the address returned by dax_direct_access() be protected by this
drivers/dax: Expand lock scope to cover the use of addresses
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 <dan.j.williams@intel.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
show more ...
|
#
23160978 |
| 25-Jul-2020 |
Coly Li <colyli@suse.de> |
dax: print error message by pr_info() in __generic_fsdax_supported()
In struct dax_operations, the callback routine dax_supported() returns a bool type result. For false return value, the caller has
dax: print error message by pr_info() in __generic_fsdax_supported()
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 <dan.j.williams@intel.com> Cc: Anthony Iliopoulos <ailiopoulos@suse.com> Reported-by: Michal Suchanek <msuchanek@suse.com> Suggested-by: Jan Kara <jack@suse.com> Reviewed-by: Jan Kara <jack@suse.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
show more ...
|
Revision tags: v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7 |
|
#
e556f6ba |
| 26-Jun-2020 |
Christoph Hellwig <hch@lst.de> |
block: remove the bd_queue field from struct block_device
Just use bd_disk->queue instead.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
block: remove the bd_queue field from struct block_device
Just use bd_disk->queue instead.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30 |
|
#
4e4ced93 |
| 01-Apr-2020 |
Vivek Goyal <vgoyal@redhat.com> |
dax: Move mandatory ->zero_page_range() check in alloc_dax()
zero_page_range() dax operation is mandatory for dax devices. Right now that check happens in dax_zero_page_range() function. Dan thinks
dax: Move mandatory ->zero_page_range() check in alloc_dax()
zero_page_range() dax operation is mandatory for dax devices. Right now that check happens in dax_zero_page_range() function. Dan thinks that's too late and its better to do the check earlier in alloc_dax().
I also modified alloc_dax() to return pointer with error code in it in case of failure. Right now it returns NULL and caller assumes failure happened due to -ENOMEM. But with this ->zero_page_range() check, I need to return -EINVAL instead.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Link: https://lore.kernel.org/r/20200401161125.GB9398@redhat.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24 |
|
#
f605a263 |
| 28-Feb-2020 |
Vivek Goyal <vgoyal@redhat.com> |
dax, pmem: Add a dax operation zero_page_range
Add a dax operation zero_page_range, to zero a page. This will also clear any known poison in the page being zeroed.
As of now, zeroing of one page is
dax, pmem: Add a dax operation zero_page_range
Add a dax operation zero_page_range, to zero a page. This will also clear any known poison in the page being zeroed.
As of now, zeroing of one page is allowed in a single call. There are no callers which are trying to zero more than a page in a single call. Once we grow the callers which zero more than a page in single call, we can add that support. Primary reason for not doing that yet is that this will add little complexity in dm implementation where a range might be spanning multiple underlying targets and one will have to split the range into multiple sub ranges and call zero_page_range() on individual targets.
Suggested-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Link: https://lore.kernel.org/r/20200228163456.1587-3-vgoyal@redhat.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9 |
|
#
f01b16a8 |
| 06-Jan-2020 |
Vivek Goyal <vgoyal@redhat.com> |
dax: Get rid of fs_dax_get_by_host() helper
Looks like nobody is using fs_dax_get_by_host() except fs_dax_get_by_bdev() and it can easily use dax_get_by_host() instead.
IIUC, fs_dax_get_by_host() w
dax: Get rid of fs_dax_get_by_host() helper
Looks like nobody is using fs_dax_get_by_host() except fs_dax_get_by_bdev() and it can easily use dax_get_by_host() instead.
IIUC, fs_dax_get_by_host() was only introduced so that one could compile with CONFIG_FS_DAX=n and CONFIG_DAX=m. fs_dax_get_by_bdev() achieves the same purpose and hence it looks like fs_dax_get_by_host() is not needed anymore.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20200106181117.GA16248@redhat.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2 |
|
#
fefc1d97 |
| 05-Jul-2019 |
Pankaj Gupta <pagupta@redhat.com> |
libnvdimm: add dax_dev sync flag
This patch adds 'DAXDEV_SYNC' flag which is set for nd_region doing synchronous flush. This later is used to disable MAP_SYNC functionality for ext4 & xfs filesystem
libnvdimm: add dax_dev sync flag
This patch adds 'DAXDEV_SYNC' flag which is set for nd_region doing synchronous flush. This later is used to disable MAP_SYNC functionality for ext4 & xfs filesystem for devices don't support synchronous flush.
Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
5b497af4 |
| 29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 295
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of ve
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 295
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of version 2 of the gnu general public license as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 64 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.894819585@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5 |
|
#
75d4e06f |
| 25-Mar-2019 |
David Howells <dhowells@redhat.com> |
vfs: Convert dax to use the new mount API
Convert the dax filesystem to the new internal mount API as the old one will be obsoleted and removed. This allows greater flexibility in communication of
vfs: Convert dax to use the new mount API
Convert the dax filesystem to the new internal mount API as the old one will be obsoleted and removed. This allows greater flexibility in communication of mount parameters between userspace, the VFS and the filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Dan Williams <dan.j.williams@intel.com> cc: Vishal Verma <vishal.l.verma@intel.com> cc: Keith Busch <keith.busch@intel.com> cc: Dave Jiang <dave.jiang@intel.com> cc: linux-nvdimm@lists.01.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
#
1f58bb18 |
| 20-May-2019 |
Al Viro <viro@zeniv.linux.org.uk> |
mount_pseudo(): drop 'name' argument, switch to d_make_root()
Once upon a time we used to set ->d_name of e.g. pipefs root so that d_path() on pipes would work. These days it's completely pointless
mount_pseudo(): drop 'name' argument, switch to d_make_root()
Once upon a time we used to set ->d_name of e.g. pipefs root so that d_path() on pipes would work. These days it's completely pointless - dentries of pipes are not even connected to pipefs root. However, mount_pseudo() had set the root dentry name (passed as the second argument) and callers kept inventing names to pass to it. Including those that didn't *have* any non-root dentries to start with...
All of that had been pointless for about 8 years now; it's time to get rid of that cargo-culting...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
#
1a6e9e76 |
| 20-May-2019 |
Dan Williams <dan.j.williams@intel.com> |
device-dax: Drop register_filesystem()
The device-dax fs is only there to allocate a common inode for each device-node that refers to the same device by major:minor. It is otherwise not user mountab
device-dax: Drop register_filesystem()
The device-dax fs is only there to allocate a common inode for each device-node that refers to the same device by major:minor. It is otherwise not user mountable and need not be displayed in /proc/filesystems.
Reported-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
#
7bf7eac8 |
| 16-May-2019 |
Dan Williams <dan.j.williams@intel.com> |
dax: Arrange for dax_supported check to span multiple devices
Pankaj reports that starting with commit ad428cdb525a "dax: Check the end of the block-device capacity with dax_direct_access()" device-
dax: Arrange for dax_supported check to span multiple devices
Pankaj reports that starting with commit ad428cdb525a "dax: Check the end of the block-device capacity with dax_direct_access()" device-mapper no longer allows dax operation. This results from the stricter checks in __bdev_dax_supported() that validate that the start and end of a block-device map to the same 'pagemap' instance.
Teach the dax-core and device-mapper to validate the 'pagemap' on a per-target basis. This is accomplished by refactoring the bdev_dax_supported() internals into generic_fsdax_supported() which takes a sector range to validate. Consequently generic_fsdax_supported() is suitable to be used in a device-mapper ->iterate_devices() callback. A new ->dax_supported() operation is added to allow composite devices to split and route upper-level bdev_dax_supported() requests.
Fixes: ad428cdb525a ("dax: Check the end of the block-device...") Cc: <stable@vger.kernel.org> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Reported-by: Pankaj Gupta <pagupta@redhat.com> Reviewed-by: Pankaj Gupta <pagupta@redhat.com> Tested-by: Pankaj Gupta <pagupta@redhat.com> Tested-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
53e22829 |
| 10-Apr-2019 |
Al Viro <viro@zeniv.linux.org.uk> |
dax: make use of ->free_inode()
we might want to drop ->destroy_inode() there - it's used only for WARN_ON() now, and AFAICS that could be moved to ->evict_inode() if we had one...
Reviewed-by: Jan
dax: make use of ->free_inode()
we might want to drop ->destroy_inode() there - it's used only for WARN_ON() now, and AFAICS that could be moved to ->evict_inode() if we had one...
Reviewed-by: Jan Kara <jack@suse.cz> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
Revision tags: v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25 |
|
#
ad428cdb |
| 20-Feb-2019 |
Dan Williams <dan.j.williams@intel.com> |
dax: Check the end of the block-device capacity with dax_direct_access()
The checks in __bdev_dax_supported() helped mitigate a potential data corruption bug in the pmem driver's handling of section
dax: Check the end of the block-device capacity with dax_direct_access()
The checks in __bdev_dax_supported() helped mitigate a potential data corruption bug in the pmem driver's handling of section alignment padding. Strengthen the checks, including checking the end of the range, to validate the dev_pagemap, Xarray entries, and sector-to-pfn translation established for pmem namespaces.
Acked-by: Jan Kara <jack@suse.cz> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|