Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932443AbcCUUWU (ORCPT ); Mon, 21 Mar 2016 16:22:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37446 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932345AbcCUUWS (ORCPT ); Mon, 21 Mar 2016 16:22:18 -0400 From: Jeff Moyer To: Christoph Hellwig Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch] direct-io: propagate -ENOSPC errors References: <20160321160208.GA15481@infradead.org> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Mon, 21 Mar 2016 16:22:16 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1510 Lines: 43 Hi, Christoph, Christoph Hellwig 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