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 652F9C433EF for ; Mon, 18 Jul 2022 14:25:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235477AbiGROZf (ORCPT ); Mon, 18 Jul 2022 10:25:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235286AbiGROZb (ORCPT ); Mon, 18 Jul 2022 10:25:31 -0400 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22E88E08F for ; Mon, 18 Jul 2022 07:25:30 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id b11so21507739eju.10 for ; Mon, 18 Jul 2022 07:25:30 -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=b6t/+N1+W4VgPAXHp/M2TXDSX6kb6MT08vG4t3aPV7Y=; b=hYqn7R98IMdzc6HipEjUlR51NKcNaoBacjkT3TcxcxIuRdjAYzqdTrAGx0rFsnqUSI TpsrZra4NWPfmdWwtUK1aDzL22O+cymCz6OvXo4T8Cp/D5ai3DOi+/t3GMnjpUKqZL62 j0HDmQc9IrLr1T2+YJreGR7BCgpandjjF8U+qRG5AlRFnzk385HkT2K0GyuPxDEMDPe4 bbBf4EOHNRy6rMmtvs9btboFHvlTYQK778xevsYj2hY4UiRyFUpIFX1wHOf0fCPQO1qE fDmLydJk0lZl+80aSxdi2cIB61U3e33zYpCNr2LoKYBx408ckXRPDXZn/m33w0xsdyMY YMLQ== 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=b6t/+N1+W4VgPAXHp/M2TXDSX6kb6MT08vG4t3aPV7Y=; b=Zj9VR8+FhhuTkanQoNsKQqpZwiwu9K5GqRRFC9FUN6Pv2WIYsHvLFAhkWhUZh/iEiv KQGqJ6nNPufGzJ9/7ZixLRigxFCUDBI+zyah8Gk+epCFkRmEBWkY0USt7+W5sLMhNGAS EhHP+CsSqpdfDlldTCs0+wG8+YyAyMyS7iMBhCNoefrEUJrXv5WE+jK7Tsx9CH9tGxQl W/uQKwGssRdg2rHWOinfkmgOmw8I0UAVbwEb6X9PpVg15qC0gWYGa2ujeShqwfktN6Dj sfVX9nWTphul2h2oGUZLxrB7j69vtRX2S5ClcDCJnJLry+eaCDFbAcgI4qI34ggc5P9m /mKg== X-Gm-Message-State: AJIora9G4f+GRzUNqiQ6HijQ8OK2W8nniYN6OMI9sUr0elyo6AvDFP+T QEsNN5dFZn7LCqQGQK7ozT0p5w== X-Google-Smtp-Source: AGRyM1s3YCiSLu6Q+lwm6jJZnCAwBaMfFoNhVeKfCxoPL6URn0nvMrdPHNss2DkgRYaK39HWt1g24w== X-Received: by 2002:a17:906:5d08:b0:6ff:8ed:db63 with SMTP id g8-20020a1709065d0800b006ff08eddb63mr26256399ejt.408.1658154328599; Mon, 18 Jul 2022 07:25:28 -0700 (PDT) Received: from smtpclient.apple (ip5b434222.dynamic.kabel-deutschland.de. [91.67.66.34]) by smtp.gmail.com with ESMTPSA id eg52-20020a05640228b400b0043a6fde6e7bsm8533243edb.19.2022.07.18.07.25.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2022 07:25:28 -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 16:25:26 +0200 Cc: Linus Torvalds , overlayfs , linux-kernel , linux-fsdevel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <0B8DA307-7E1F-4534-B864-BC2632740C89@kohlschutter.com> References: <4B9D76D5-C794-4A49-A76F-3D4C10385EE0@kohlschutter.com> <83A29F9C-1A91-4753-953A-0C98E8A9832C@kohlschutter.com> To: Miklos Szeredi 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 15:13 schrieb Miklos Szeredi : >=20 > On Mon, 18 Jul 2022 at 15:03, Christian Kohlsch=C3=BCtter > wrote: >>=20 >> 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 >>=20 >> That ship is sailed since ENOSYS was returned to user-space for the = first time. >>=20 >> 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. >=20 > Correct. The question is whether any application would break in this > case. I think not, but you are free to prove otherwise. >=20 > Thanks, > Miklos I'm not going to do that since I expect any answer I give would not = change your position here. All I know is there is a non-zero chance such = programs exist. If you're willing to go ahead with the fuse change you proposed, I see = no purpose in debating with you further since you're the kernel = maintainer of both file systems. That change "fixes" the problem that I had seen in my setup; I do not = know the extent of side effects, but I expect some could surface = eventually. Once you're done fixing fuse, please also talk to the folks over at = https://github.com/trapexit/mergerfs who explicitly return ENOSYS upon = request. Who knows, maybe someone is audacious enough to try mergerfs as = a lower filesystem for overlay? Alas, I think this a clash between the philosophies of writing robust = code versus writing against a personal interpretation of some = specification. You refer to "asm-generic/errno.h" as the specification and rationale = for treating ENOSYS as sacrosanct. Note that the comment says "should = refrain from", it doesn't say "must not", and that's why we're in this = mess. It therefore wouldn't hurt to be lenient when a lower filesystem returns = an error code known to refer to "unsupported operation", and that's what = my original patch to ovl does. I thought this approach would resonate with you, since you must have = been following the same logic when you added the special-case check for = "EINVAL" as an exception for ntfs-3g in the commit that most likely = triggered the regression ("ovl: fix filattr copy-up failure") 9 months = ago. I honestly wonder why you're risking further breakage, having introduced = that regression only recently. So long, Christian