Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1361959 > unrolled thread

Re: [patch] direct-io: propagate -ENOSPC errors

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [patch] direct-io: propagate -ENOSPC errors Christoph Hellwig <hch@infradead.org> - 2016-03-21 17:10 +0100
    Re: [patch] direct-io: propagate -ENOSPC errors Jeff Moyer <jmoyer@redhat.com> - 2016-03-21 21:30 +0100

#1361959 — Re: [patch] direct-io: propagate -ENOSPC errors

On Mon, Mar 14, 2016 at 05:10:00PM -0400, Jeff Moyer wrote:
> dio_bio_complete turns all errors into -EIO.  This is historical,
> since you used to only get 1 bit precision for errors (BIO_UPTODATE).
> Now that we get actual error codes, we can return the appropriate
> code to userspace.  File systems seem to only propagate either EIO
> or ENOSPC, so I've followed suit in this patch.

Do we?  Just propagating some errors defintively seems odd.  Even
if we do we should have a central helper doing that mapping instead
of opencoding it in various places.

[toc] | [next] | [standalone]

#1362138

Hi, Christoph,

Christoph Hellwig <hch@infradead.org> writes:

> On Mon, Mar 14, 2016 at 05:10:00PM -0400, Jeff Moyer wrote:
>> dio_bio_complete turns all errors into -EIO.  This is historical,
>> since you used to only get 1 bit precision for errors (BIO_UPTODATE).
>> Now that we get actual error codes, we can return the appropriate
>> code to userspace.  File systems seem to only propagate either EIO
>> or ENOSPC, so I've followed suit in this patch.
>
> Do we?

Sometimes!  :)  I was referring to this:

static inline void mapping_set_error(struct address_space *mapping, int error)
{
        if (unlikely(error)) {
                if (error == -ENOSPC)
                        set_bit(AS_ENOSPC, &mapping->flags);
                else
                        set_bit(AS_EIO, &mapping->flags);
        }
}

> Just propagating some errors defintively seems odd.

Not really.  read, write, etc only expect a subset of errnos to be
returned.  The goal was not to leak kernel-internal or unexpected error
numbers to userspace, and I didn't think I would be able to successfully
audit all code paths that lead here.  So, I opted for a more
conservative patch that just allows one more errno through.

> Even if we do we should have a central helper doing that mapping
> instead of opencoding it in various places.

OK.  I would argue that the right place to filter out errno's would be
up in the vfs.  I do wonder if I'm just being overly paranoid, though.

Al, do you have any opinions, here?

Cheers,
Jeff

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web