On Fri, 11 Mar 2016, Al Viro wrote:
IIRC, there also had been some unpleasantness with getattr messing ->i_mode
halfway through... <checks> Yes - copy_attributes_to_inode() will be called,
and do
inode->i_mode = orangefs_inode_perms(attrs);
...
inode->i_mode |= S_IFLNK;
...
strncpy(orangefs_inode->link_target,
symname,
ORANGEFS_NAME_MAX);
If nothing else, *another* stat(2) racing with this one could pick the
intermediate value of ->i_mode and proceed to report it to userland.
Another problem is overwriting the symlink body; that can get very
unpleasant, since it might be traversed by another syscall right at that
moment. Any change of a symlink body means "we'd missed it going stale";
there is no way to change a symlink contents without removing it and
creating a new one. Should anything other than orangefs_iget() even bother
copying it? The same goes for inode type changes, of course (regular
vs. directory vs. symlink, etc.).
I thought I fixed most of that when I went over
d_revalidate. But now I see that there's the case that
the server attribute changes after revalidate and before
the operation e.g. chmod. What happens to the inode we
now know is stale? What if two processes notice it's
stale at the same time?
We can go ahead with the chmod even if the object type
has changed since the kernel last saw it. But OrangeFS
doesn't have NFS's sillyrename. So what do we do in the
middle of read when we get ENOENT? We ignore POSIX and
return it to userspace anyway and leave the bad inode
around now.
There's lots of unsanitized error codes from the server
going to userspace now.
Will writing i_mode in one shot fix it?
-- Martin
--
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
