| Message ID | 150655618343.700.16350109614227108839.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dan Williams <dan.j.williams@intel.com> writes: > If a dax buffer from a device that does not map pages is passed to > read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If > gdb attempts to examine the contents of a dax buffer from a device that > does not map pages it triggers SIGBUS. If fork(2) is called on a process > with a dax mapping from a device that does not map pages it triggers > SIGBUS. 'struct page' is required otherwise several kernel code paths > break in surprising ways. Disable filesystem-dax on devices that do not > map pages. > [...] > @@ -123,6 +124,12 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize) > return len < 0 ? len : -EIO; > } > > + if (!pfn_t_has_page(pfn)) { > + pr_err("VFS (%s): error: dax support not enabled\n", > + sb->s_id); Is the pr_err really necessary? At least one caller already prints a warning. It seems cleaner to me to let the caller determine whether it's worth printing anything. -Jeff
On Thu, Sep 28, 2017 at 9:25 AM, Jeff Moyer <jmoyer@redhat.com> wrote: > Dan Williams <dan.j.williams@intel.com> writes: > >> If a dax buffer from a device that does not map pages is passed to >> read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If >> gdb attempts to examine the contents of a dax buffer from a device that >> does not map pages it triggers SIGBUS. If fork(2) is called on a process >> with a dax mapping from a device that does not map pages it triggers >> SIGBUS. 'struct page' is required otherwise several kernel code paths >> break in surprising ways. Disable filesystem-dax on devices that do not >> map pages. >> > [...] >> @@ -123,6 +124,12 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize) >> return len < 0 ? len : -EIO; >> } >> >> + if (!pfn_t_has_page(pfn)) { >> + pr_err("VFS (%s): error: dax support not enabled\n", >> + sb->s_id); > > Is the pr_err really necessary? At least one caller already prints a > warning. It seems cleaner to me to let the caller determine whether > it's worth printing anything. Agreed, I'll drop it in v2.
diff --git a/drivers/dax/super.c b/drivers/dax/super.c index 30d8a5aedd23..d9ac57b3e49a 100644 --- a/drivers/dax/super.c +++ b/drivers/dax/super.c @@ -15,6 +15,7 @@ #include <linux/mount.h> #include <linux/magic.h> #include <linux/genhd.h> +#include <linux/pfn_t.h> #include <linux/cdev.h> #include <linux/hash.h> #include <linux/slab.h> @@ -123,6 +124,12 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize) return len < 0 ? len : -EIO; } + if (!pfn_t_has_page(pfn)) { + pr_err("VFS (%s): error: dax support not enabled\n", + sb->s_id); + return -EOPNOTSUPP; + } + return 0; } EXPORT_SYMBOL_GPL(__bdev_dax_supported);
If a dax buffer from a device that does not map pages is passed to read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If gdb attempts to examine the contents of a dax buffer from a device that does not map pages it triggers SIGBUS. If fork(2) is called on a process with a dax mapping from a device that does not map pages it triggers SIGBUS. 'struct page' is required otherwise several kernel code paths break in surprising ways. Disable filesystem-dax on devices that do not map pages. Cc: Jan Kara <jack@suse.cz> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- drivers/dax/super.c | 7 +++++++ 1 file changed, 7 insertions(+)