On Wed, Dec 17, 2014 at 10:52:56AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 17, 2014 at 06:58:32AM -0800, Omar Sandoval wrote:
> > See my previous message. If we use O_DIRECT on the original open, then
> > filesystems that implement bmap but not direct_IO will no longer work.
> > These are the ones that I found in my tree:
>
> In the long run I don't think they are worth keeping. But to keep you
> out of that discussion you can just try an open without O_DIRECT if the
> open with the flag failed.
Umm... That's one possibility, of course (and if swapon(2) is on someone's
hotpath, I really would like to see what the hell they are doing - it has
to be interesting in a sick way).
Said that, there's an interesting problem with O_DIRECT. It's irrelevant
in this case, but it *can* be changed halfway through e.g write(2) and
AFAICS we have at least some suspicious codepaths. Look at
ext4_file_write_iter(), for example. We check O_DIRECT, then grab some
locks, then proceed to look at the results of that check, do some work...
and call __generic_file_write_iter(), which checks O_DIRECT again. If
it has been cleared (or, probably worse, set) it looks like we'll get
an interesting bunch of holes.
Should we just labda-expand that call of __generic_file_write_iter() and
replace its
if (unlikely(file->f_flags & O_DIRECT)) {
with
if (odirect)
to be guaranteed that it'll match the things we'd done before the call?
I'm looking through the callchains right now in search of similar places
right now, will follow up when I'm done...
BTW, speaking of read/write vs. swap - what's the story with e.g. AFS
write() checking IS_SWAPFILE() and failing with -EBUSY? Note that
* it's done before acquiring i_mutex, so it isn't race-free
* it's dubious from the POSIX POV - EBUSY isn't in the error
list for write(2).
* other filesystems generally don't have anything of that sort.
NFS does, but local ones do not...
Besides, do we even allow swapfiles on AFS?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
