On Fri, Mar 20, 2015 at 08:00:52PM +0100, Marek Marczykowski-Górecki wrote:
> > What the devil does that have to do with seeks, anyway? Exact
> > same problem will happen for blocking read() vs. another read() attempts
> > on the same descriptor. With perfectly accepted lseek() (which will also
> > have to block, as per 2.9.7).
>
> Yes, the problem here is because this particular file (/proc/xen/xenbus)
> blocks the read() operation waiting for new events. Because of said
> commit, now it also blocks write() operation used to send some request
> (which would result in some response, so unblocking read() call). It
> shouldn't be a normal file in the first place...
Aha. OK, so you have something that looks a whole lot like a FIFO in
that respect, and this semantics simply isn't compatible with read()
being atomic wrt write().
So just have that flag explicitly knocked out in your ->open(), preferably
with a comment explaining why is that done. Having lseek() is a red herring
in that respect - the same problem would exist if that file *did* have
something done on lseek().
That's actually what I'm objecting against - "uses nonseekable_open()" is
used a weird proxy for "can't have read(), write(), etc. atomic wrt each
other". It's not true in either direction - there's a lot of e.g. procfs
files that are just fine with current exclusion and there can very well
be files _not_ using nonseekable_open() that would break the same way
and for the same reasons as /proc/xen/xenbus does.
It's trivial to fix - either by explicit filp->f_mode &= ~FMODE_ATOMIC_POS;
in xenbus_file_open(), or by adding
static inline void no_atomic_pos(struct file *f)
{
f->f_mode &= ~FMODE_ATOMIC_POS;
}
somewhere in include/linux/fs.h and having it called in the same
xenbus_file_open(). Either way, it ought to come with something
along the lines of
/*
* we can't live with read() vs. write() atomicity, since we use
* write() as source of events returned by read() and write()
* called after another thread has blocked in read() waiting for
* events cannot be required to wait for that read() to finish.
*/
next to this removal of FMODE_ATOMIC_POS, whichever way we express it...
Objections?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
