Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master 2019-01-07T05:24:46+00:00 2019-01-07T05:24:46+00:00 Dan Williams dan.j.williams@intel.com 2017-07-13T00:58:21+00:00 urn:sha1:51cf784c42d07fbd62cb604836a9270cf3361509 Towards eliminating the dax_class, move the dax-device-attribute enabling to a new bus.c file in the core. The amount of code thrash of sub-sequent patches is reduced as no logic changes are made, just pure code movement. A temporary export of unregister_dex_dax() and dax_attribute_groups is needed to preserve compilation, but those symbols become static again in a follow-on patch. Signed-off-by: Dan Williams <dan.j.williams@intel.com> 2019-01-07T05:24:46+00:00 Dan Williams dan.j.williams@intel.com 2017-07-14T20:54:50+00:00 urn:sha1:753a0850e707e9a8c5861356222f9b9e4eba7945 The multi-resource implementation anticipated discontiguous sub-division support. That has not yet materialized, delete the infrastructure and related code. Signed-off-by: Dan Williams <dan.j.williams@intel.com> 2019-01-07T05:24:46+00:00 Dan Williams dan.j.williams@intel.com 2017-07-19T22:57:44+00:00 urn:sha1:93694f9630b0ed29cda61df58e480dcb34ef52fd Nothing consumes this attribute of a region and devres otherwise remembers the value for de-allocation purposes. Signed-off-by: Dan Williams <dan.j.williams@intel.com> 2017-07-19T00:49:14+00:00 Dan Williams dan.j.williams@intel.com 2017-07-19T00:49:14+00:00 urn:sha1:bbb3be170ac2891526ad07b18af7db226879a8e7 Fix warnings of the form... WARNING: CPU: 10 PID: 4983 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/class/dax/dax12.0' Call Trace: dump_stack+0x63/0x86 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5a/0x80 ? kernfs_path_from_node+0x4f/0x60 sysfs_warn_dup+0x62/0x80 sysfs_do_create_link_sd.isra.2+0x97/0xb0 sysfs_create_link+0x25/0x40 device_add+0x266/0x630 devm_create_dax_dev+0x2cf/0x340 [dax] dax_pmem_probe+0x1f5/0x26e [dax_pmem] nvdimm_bus_probe+0x71/0x120 ...by reusing the namespace id for the device-dax instance name. Now that we have decided that there will never by more than one device-dax instance per libnvdimm-namespace parent device [1], we can directly reuse the namepace ids. There are some possible follow-on cleanups, but those are saved for a later patch to simplify the -stable backport. [1]: https://lists.01.org/pipermail/linux-nvdimm/2016-December/008266.html Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple pmem...") Cc: Jeff Moyer <jmoyer@redhat.com> Cc: <stable@vger.kernel.org> Reported-by: Dariusz Dokupil <dariusz.dokupil@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> 2017-04-13T04:59:14+00:00 Dan Williams dan.j.williams@intel.com 2017-04-11T16:49:49+00:00 urn:sha1:7b6be8444e0f0dd675b54d059793423d3c9b4c03 We want dax capable drivers to be able to publish a set of dax operations [1]. However, we do not want to further abuse block_devices to advertise these operations. Instead we will attach these operations to a dax device and add a lookup mechanism to go from block device path to a dax device. A dax capable driver like pmem or brd is responsible for registering a dax device, alongside a block device, and then a dax capable filesystem is responsible for retrieving the dax device by path name if it wants to call dax_operations. For now, we refactor the dax pseudo-fs to be a generic facility, rather than an implementation detail, of the device-dax use case. Where a "dax device" is just an inode + dax infrastructure, and "Device DAX" is a mapping service layered on top of that base 'struct dax_device'. "Filesystem DAX" is then a mapping service that layers a filesystem on top of that same base device. Filesystem DAX is associated with a block_device for now, but perhaps directly to a dax device in the future, or for new pmem-only filesystems. [1]: https://lkml.org/lkml/2017/1/19/880 Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com>