Re: Orangefs, v4.5 and the merge window...

[Martin Brandenburg <martin@omnibond.com>]

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