Dan Williams <dan.j.williams@xxxxxxxxx> 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
