Re: [PATCH] btrfs: don't return EINTR

[Josef Bacik <josef@redhat.com>]

On Tue, Apr 17, 2012 at 08:56:11PM +0200, Arne Jansen wrote:
> On 04/17/12 20:22, Josef Bacik wrote:
> >On Tue, Apr 17, 2012 at 11:24:01AM -0400, Chris Mason wrote:
> >>On Tue, Apr 17, 2012 at 04:15:32PM +0200, Arne Jansen wrote:
> >>>On 14.04.2012 14:56, Arne Jansen wrote:
> >>>>It is basically a good thing if we are interruptible when waiting for
> >>>>free space, but the generality in which it is implemented currently
> >>>>leads to system calls being interruptible that are not documented this
> >>>>way. For example git can't handle interrupted unlink(), leading to
> >>>>corrupt repos under space pressure.
> >>>
> >>>Is this patch a candidate for the next rc?
> >>
> >>The EINTR came from Josef.  We do want to be able to break out of long
> >>flushes, but I want to check with him to see if there was a specific bug
> >>this was solving?
> >
> >Sorry I was -ENOINTERNET, no the only thing I was fixing was being able to break
> >out of long flushes.  Maybe instead of using the big hammer here we just make
> >unlink ignore EINTR and try again, or maybe pass down a flag saying I can't be
> >interrupted?  Thanks,
> >
> 
> unlink() is the only call I've seen problems with, but there are
> probably other calls where EINTR is also unexpected.
> Also, just retrying the unlink internally won't help as the signal
> is still pending.
> How can we gather a list of calls where EINTR is ok?

Well then passing a flag down that says we can't interrupt I guess is what we're
going to have to do and just wait uninterruptible.  I think our best bet is to
just fix them as they come up, I thought all system calls could return EINTR but
apparently I was wrong :).  Thanks,

Josef