From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 646D1C001E0 for ; Sat, 15 Jul 2023 23:36:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229732AbjGOXgt (ORCPT ); Sat, 15 Jul 2023 19:36:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229679AbjGOXgs (ORCPT ); Sat, 15 Jul 2023 19:36:48 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35DFB271E for ; Sat, 15 Jul 2023 16:36:47 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2657d405ad5so2184893a91.1 for ; Sat, 15 Jul 2023 16:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1689464206; x=1692056206; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=t/mkW0jGzSqPxmGw9V0X5RkM5ItEmfXI12w10A2Eres=; b=ASLyRtXp8Yh09OikOhVYeIlu5bNpY1KPbFNZmvzee+mQSlD1a4yuBjIeYrCHl6OWro SRX0mHttxJTRKFZy6ihmc+Q20IlDS2cBlDSmGuITxJ0dNZrwqmDnvXQ8skguRkgzU1dU yMO2S2RQnxdwQErxmQH1R4cx0C5ST3d5RpqoM80FQwgMl0xIcr3iXBu2xdAHRi34mDkg cREPVv8GpoB47rP/7MJ1WrymktFTRyxN7c30Ih5exBOGdb03bK9UUgyppXmDWGlJAd/Q 0IXYjXeCTDTJhg0GXlQyjPUPIuBfEXfOyaMGZTv9cSchPM0wUQV+W0c1YRYro1Juz+3G Z1DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689464206; x=1692056206; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=t/mkW0jGzSqPxmGw9V0X5RkM5ItEmfXI12w10A2Eres=; b=NGENVrL9Av7p7+CopsdqpAouUNh1d3JQGZJe+2nqPhrpvq3Pgxu3d8wNNceK8+giHN m7GxoCElBdXXKORp+iX6MvKXLwm2nlhsjrppd2yE6OFxkjixgpb/x3pkMUq7FKWoE8dV XEgLE8sfQW712Jzm4Dz1kPtkuRIdAhYJUz1ExQqRaXBpcnT59WIbq7UqM2O+QIGWP/mE hmnXCSFgKSj5Hg3oayUIFZc+w9gVcKHiRUt4UK+m5wOnNLk4/xKLyXFa5xnomyUnohV4 LgPB1F7M+s5c69uVUmr/PC6CPYB/jr6H4BHtVg4KQ7YK0taY3Z4t2phhxWaWMpuF3eNS 8tIg== X-Gm-Message-State: ABy/qLbEuR9IP/giMgUwpEFH8O0K1EV6fgYIHmS9yeR6T77RuBQXhY7+ dpv5NkIrRwRdA/DHCrscFmeZKA== X-Google-Smtp-Source: APBJJlHBHNn9ic8rlAZHn4iUhijf/z7EF3FUM1bqEZgsTAkGKX1Rp8C01GUKBrM4SByqZu0DMgo+aw== X-Received: by 2002:a17:90b:482:b0:263:41d2:4e2 with SMTP id bh2-20020a17090b048200b0026341d204e2mr8518613pjb.32.1689464206607; Sat, 15 Jul 2023 16:36:46 -0700 (PDT) Received: from dread.disaster.area (pa49-186-119-116.pa.vic.optusnet.com.au. [49.186.119.116]) by smtp.gmail.com with ESMTPSA id 4-20020a17090a19c400b00263e4dc33aasm3103081pjj.11.2023.07.15.16.36.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jul 2023 16:36:45 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qKoob-006YsO-27; Sun, 16 Jul 2023 09:36:41 +1000 Date: Sun, 16 Jul 2023 09:36:41 +1000 From: Dave Chinner To: Leesoo Ahn Cc: Alexander Viro , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Leesoo Ahn Subject: Re: [PATCH v2] fs: inode: return proper error code in bmap() Message-ID: References: <20230715082204.1598206-1-lsahn@wewakecorp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230715082204.1598206-1-lsahn@wewakecorp.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 15, 2023 at 05:22:04PM +0900, Leesoo Ahn wrote: > Return -EOPNOTSUPP instead of -EINVAL which has the meaning of > the argument is an inappropriate value. The current error code doesn't > make sense to represent that a file system doesn't support bmap operation. > > Signed-off-by: Leesoo Ahn > --- > Changes since v1: > - Modify the comments of bmap() > - Modify subject and description requested by Markus Elfring > https://lore.kernel.org/lkml/20230715060217.1469690-1-lsahn@wewakecorp.com/ > > fs/inode.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/inode.c b/fs/inode.c > index 8fefb69e1f84..697c51ed226a 100644 > --- a/fs/inode.c > +++ b/fs/inode.c > @@ -1831,13 +1831,13 @@ EXPORT_SYMBOL(iput); > * 4 in ``*block``, with disk block relative to the disk start that holds that > * block of the file. > * > - * Returns -EINVAL in case of error, 0 otherwise. If mapping falls into a > + * Returns -EOPNOTSUPP in case of error, 0 otherwise. If mapping falls into a > * hole, returns 0 and ``*block`` is also set to 0. > */ > int bmap(struct inode *inode, sector_t *block) > { > if (!inode->i_mapping->a_ops->bmap) > - return -EINVAL; > + return -EOPNOTSUPP; > > *block = inode->i_mapping->a_ops->bmap(inode->i_mapping, *block); > return 0; What about the CONFIG_BLOCK=n wrapper? Also, all the in kernel consumers squash this error back to 0, -EIO or -EINVAL, so this change only ever propagates out to userspace via the return from ioctl(FIBMAP). Do we really need to change this and risk breaking userspace that handles -EINVAL correctly but not -EOPNOTSUPP? -Dave. -- Dave Chinner david@fromorbit.com