On Thu, Sep 28, 2017 at 9:25 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote:
> 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.
Agreed, I'll drop it in v2.
--
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>
