Re: Update of file offset on write() etc. is non-atomic with I/O

[Al Viro]

On Mon, Mar 03, 2014 at 04:42:36PM -0800, Linus Torvalds wrote:
> On Mon, Mar 3, 2014 at 4:23 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > I wonder if something like
> >
> > static inline struct fd fdget(int fd)
> > {
> >         unsigned long v = __fdget(fd);
> >         return (struct fd){(struct file *)(v & ~1), v & 1};
> > }
> 
> Make it use "&3" so that we have the two bits we need, and I'll
> happily take that approach, yes.

Hmm...  You want to have that second flag dealt with inside fs/file.c
as well?  OK, but that'll need one more thing - __attribute__((aligned(4)))
on struct file declaration.  We have at least one weird architecture that
is happy to align everything on 16bit boundaries.  Granted, it's half-dead,
but there might be something besides m68k with the same weirdness...

It's probably not worth replacing struct fd with typedef to unsigned long -
too easy to have it confused with a file descriptor itself and pass to
something that expects e.g. int.  In any case, since we leave fdget()
inlined, compiler will see the unsigned long it's been initialized with,
so if it decides that it's cheaper to replace f.file with v & ~3 through
the whole thing, keep v around and discard local struct fd completely,
it'll be able to do so just fine...

I'll play around with cross-builds a bit and see what falls out of all
that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/