On Fri 13-10-17 08:52:28, Dan Williams wrote:

On Fri, Oct 13, 2017 at 12:22 AM, Christoph Hellwig [off-list ref] wrote:

quoted

On Wed, Oct 11, 2017 at 03:11:21PM -0700, Dan Williams wrote:

quoted

quoted

+       /*
+        * We don't support synchronous mappings for non-DAX files. At least
+        * until someone comes with a sensible use case.
+        */
+       if (!IS_DAX(file_inode(file)) && (map_flags & MAP_SYNC))
+               return -EOPNOTSUPP;

Perhaps EPERM instead to differentiate the unsupported flags case?
There's precedent for mmap returning EPERM for reasons other than
incompatible PROT flags.

Why would we want to voluntarily use arcane errors for a entirely
new interface under our control?

-EOPNOTSUPP is nice and explicit about what is going on.

We have this general and perennial problem of parsing why the kernel
is throwing an error. It saves a debug step if the error code is
unique, and in this case would indicate that the filesystem supports
MAP_SYNC but the administrator failed to arrange for the device to be
in DAX mode.

So I understand this wish however I think the error codes should also
reflect the nature of the problem. And EPERM has something to do with access
permissions, not whether file supports DAX access or not.

								Honza

-- 
Jan Kara [off-list ref]
SUSE Labs, CR