Re: [PATCH] [RFC] Fix deadlock on regular nonseekable files

[Al Viro]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/