On Tue, Apr 5, 2016 at 7:08 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> Since for non-seekable files the file position is kind of a strange
> thing anyway, also don't enforce atomic position updates for them.
I don't disagree with the patch at all, I'm just wondering exactly
what the deadlock was, and would love to have that description in the
commit message.
> (I do recognize that the application isn't really standard conforming,
> as it should use multiple file descriptors from all I understand. But
> it worked fine before that change, and so they claim the kernel to be
> at fault.)
Oh, absolutely. Very much a regression.
There are almost zero interesting applications that are "standard
conforming", so if we used that as an excuse to not fix kernel issues,
we'd never have to do any work. And we'd have no users ;)
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Al, make that a "Acked-by:", although I do want to repeat that it
would be lovely to hear what the app actually did to trigger the
problem.
Which /proc file is it that causes the read/write/lseek path to then
presumably recurse into another read/write/lseek and cause a deadlock?
Are there perhaps other cases we'd need to worry about?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
