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 6A109C433EF for ; Mon, 18 Jul 2022 13:04:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235193AbiGRNEC (ORCPT ); Mon, 18 Jul 2022 09:04:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235173AbiGRND6 (ORCPT ); Mon, 18 Jul 2022 09:03:58 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C01C360F8 for ; Mon, 18 Jul 2022 06:03:56 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id e15so15190296edj.2 for ; Mon, 18 Jul 2022 06:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kohlschutter-com.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zM3JzhRssik7POz7o5zHEQmq3nlUbfeSo9DWVPrJQK0=; b=uyNTCGd5YUjRh25MM8MbjG2pfHd13DW9QxeLHwxPdMr/HplpVZnizhjdh/UcRb6tBB fCUS2xYCqMnKffsyN9BJAVAtVbr0FHNTDXh3MN1iUUIxO+4PWQzLGO+xuzHr+n8ucgVw l/xOxeJ9yuI8bUIPGD+weacTDu7ZBXxmPyyLqXglJEiaAw30JHtpgT2rs48ex4eqBXZz 6f3lFWK50iQfYcPT7KeLfknMMuMWeVFqDd3UIIBkhTS/uK30mDX28V7wjxGctX7CL7fY tjew/FkcwCaTXMZwnau7VLfG8lkLAZaM3/znyOtX363b/HY2ggAG/e1o2SIqbrh7G2tM m6nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zM3JzhRssik7POz7o5zHEQmq3nlUbfeSo9DWVPrJQK0=; b=ucvVeXu1It3O85IS2YZfsAJ7xXcVt4JMoFBuo1yTHhxVzS6wLIKnbOobsAuqukQgzP DC0vGPBDiFoskNRB0G9uWnp2plHMTUG5Er8KoGkrpMx7/oLgxBLv3K+GtR2MuMIf0131 gebubABsabRlHCrS6jFhfVp9N2xJnV2FCD79JcS1vbgeHyCZ9dZelKJ5KahZmQHpLYWE qX+G7+cBaEzsJUOlAJRIh64N6azH4ZsMRJiNnkDJIea2II4wnOjQ04fwa2REl8NTpJQC VHeyRr5eoLmTKm9k9JR3FgVoz6hPGib19yFzMzBbeEUJJAsW2D3YrmpETCis3JshQFB9 bCfg== X-Gm-Message-State: AJIora9UgQXyp1V78Z5q0hMfPw4CZKtGl9EaQkIJ87lPdm5L6DHJqZyU 9PEKMBWBjjqdL9aJ9ZOVmqUaE/aFXRu9k+Vm X-Google-Smtp-Source: AGRyM1sGi7hDRHgbtbQ1r4bhDDCZKOUJkCZ0vIKaczfxZ3PORpdqu17Jsa5awBE4iVj+SejJfaQlNw== X-Received: by 2002:a05:6402:12d8:b0:43a:6a70:9039 with SMTP id k24-20020a05640212d800b0043a6a709039mr37051772edx.379.1658149435052; Mon, 18 Jul 2022 06:03:55 -0700 (PDT) Received: from smtpclient.apple (ip5b434222.dynamic.kabel-deutschland.de. [91.67.66.34]) by smtp.gmail.com with ESMTPSA id g21-20020a1709061e1500b00722f8d02928sm5555089ejj.174.2022.07.18.06.03.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2022 06:03:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH] [REGRESSION] ovl: Handle ENOSYS when fileattr support is missing in lower/upper fs From: =?utf-8?Q?Christian_Kohlsch=C3=BCtter?= In-Reply-To: Date: Mon, 18 Jul 2022 15:03:52 +0200 Cc: overlayfs , linux-kernel , linux-fsdevel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B9D76D5-C794-4A49-A76F-3D4C10385EE0@kohlschutter.com> <83A29F9C-1A91-4753-953A-0C98E8A9832C@kohlschutter.com> To: Miklos Szeredi , torvalds@linux-foundation.org X-Mailer: Apple Mail (2.3696.100.31) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 18.07.2022 um 14:21 schrieb Miklos Szeredi : >=20 > On Mon, 18 Jul 2022 at 12:56, Christian Kohlsch=C3=BCtter > wrote: >=20 >> However, users of fuse that have no business with overlayfs suddenly = see their ioctl return ENOTTY instead of ENOSYS. >=20 > And returning ENOTTY is the correct behavior. See this comment in > : >=20 > /* > * This error code is special: arch syscall entry code will return > * -ENOSYS if users try to call a syscall that doesn't exist. To keep > * failures of syscalls that really do exist distinguishable from > * failures due to attempts to use a nonexistent syscall, syscall > * implementations should refrain from returning -ENOSYS. > */ > #define ENOSYS 38 /* Invalid system call number */ >=20 > Thanks, > Miklos That ship is sailed since ENOSYS was returned to user-space for the = first time. It reminds me a bit of Linus' "we do not break userspace" email from = 2012 [1, 2], where Linus wrote: > Applications *do* care about error return values. There's no way in > hell you can willy-nilly just change them. And if you do change them, > and applications break, there is no way in hell you can then blame the > application. (Adding Linus for clarification whether his statement is still true in = 2022, and marking subject with regression tag for visibility.) As far as I, a fuse user, understand, fuse uses ENOSYS as a specific = marker to indicate permanent failure: =46rom libfuse = https://libfuse.github.io/doxygen/structfuse__lowlevel__ops.html: > If this request is answered with an error code of ENOSYS, this is = treated as a permanent failure with error code EOPNOTSUPP, i.e. all = future getxattr() requests will fail with EOPNOTSUPP without being send = to the filesystem process. (also see https://man.openbsd.org/fuse_new.3) Again, in summary: 1. I believe the fix should be in ovl, because ovl caused the = regression. 2. Fixing in fuse would not be sufficient because other lower = filesystems that also return ENOSYS remain affected (a cursory search = indicates ecryptfs also returns ENOSYS). 3. Fixing in fuse would break user-space. We do not break userspace. Cheers, Christian [1] https://lkml.org/lkml/2012/12/23/75 [2] https://lkml.org/lkml/2012/12/23/99=