lkml.org 
[lkml]   [2015]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [RFC] Fix deadlock on regular nonseekable files
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?


\
 
 \ /
  Last update: 2015-03-20 20:41    [W:0.072 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site