Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1062531pxb; Fri, 1 Apr 2022 03:40:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweZ8pdDf+prUT2iCke4DhvEvOgYvp3pfesMQtUzyInhc6imlsk4zZG8OEguNcWVyuzrzrH X-Received: by 2002:a17:907:1c0e:b0:6df:d10f:9eae with SMTP id nc14-20020a1709071c0e00b006dfd10f9eaemr9066415ejc.592.1648809603639; Fri, 01 Apr 2022 03:40:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648809603; cv=none; d=google.com; s=arc-20160816; b=qbQkpduYHJWb6IrBoerZTxeRpaLTSOsX+CWRGPIjd8282ctrAKIPEF7OwJ1wHlkEP1 Pl7zf4ej2BeG9jd3qfRkQs8Ik/nQ3LGAA5Ey/BYVxBf26HMIc6DEKm9dtonTs5KmDhtb 51U9Ix5Gy4Kps5R929F2juJEzlZT5z+6BArEyHUUif+2LU/4yMf/GhHhGljVEzqLjJSy +ho4DWp2Ev6QrWAtATQaaCtoUI/msEWbc66tV5mq5qdiwi81/rrfXdqIkh8CB/yEY8ZI 6S45zUCWa0bZfwZp+l9Wz31yE/YbMstF2ldsnMmU/PEGH8De0nDPcx3C56TelKnwgn0G WIdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=U6ubVyBj38as5ODvGkC2B53srjaNL+Mv+ZjXdsr+jM8=; b=BAEM5ngEKPgD4vImXIKv1ojIflMJl9I9E0HdDGAeXjmTTWurcrd//QJvl82BJiK8qm K075sJ8+IJ274mZBHQTNWW48XQLjB+4VPsQVIPSwEhMS0SDgA8k0i58w64w4/ZcbODO9 Br1tr/p+88AP1OJ6bKGWNO6XqHKXih3nifYSK1vx/OMgNq9RtP61XcvsKD0dbsjhrJ3m NBWbvU6OSMrBswGj7oYypB/Isr31soxoZDPK2UzciqVd4x30voLp8OhYl4JpxD9qPV4U msq/BFOzVcrNeKr/JxuDzIV93HpAo3/3sQkjaKVJMU6TZJiCwgWW1hDLCaGx+JcE09Fo J+Lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KOCaD+P3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k11-20020a50e18b000000b00418c2b5bd89si1445546edl.107.2022.04.01.03.39.38; Fri, 01 Apr 2022 03:40:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KOCaD+P3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232292AbiCaRoi (ORCPT + 99 others); Thu, 31 Mar 2022 13:44:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229718AbiCaRog (ORCPT ); Thu, 31 Mar 2022 13:44:36 -0400 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 195331A7775 for ; Thu, 31 Mar 2022 10:42:49 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id k11so305811ilv.5 for ; Thu, 31 Mar 2022 10:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U6ubVyBj38as5ODvGkC2B53srjaNL+Mv+ZjXdsr+jM8=; b=KOCaD+P3GIvKPSqNHIQNAmKa4Vf1WscepMhpco1VgttITKOlurmEPIhskbFLSb7Fg5 AqFWxnnJYPjCnRolaik4JNfErwayE+4s/QjWXpN12Lebz8NUJhuwybfcQ3iDRcw76W7v kSF0A5YgSUYIvceZ5nMvrS45t5K6h2yfS930wYNZkUb082UR1d49PksjevHryYf6p4R3 inox+lUFRx3t6ythmpop7G5KyuiTdJ5rUZE0dLJdm/gnW6utqDX/g/MbJ1fSuPkIg2X0 BUO724aAfY8P+rwczuaymyiK4cxLq23LpwQeL485f1tmM/ZNLRu9g0KmKKNfid79i/5J pf9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U6ubVyBj38as5ODvGkC2B53srjaNL+Mv+ZjXdsr+jM8=; b=Y/0ANcJUvr2pTNhiPO3Op6zk8+D/SM7lvZG92k4k002XKXtPw+0kYOUO9JIXwNeVcI V+2ShSbHXXzPsQ02ySAQDC+EE8KD7V2vPRV2XEkoJ9utSTM+3qpoIfHetArBaSt0rxFO PZfjtcoLOsP6xnMRwVCTMwF6xJNAnw0guvhXujXPgUspdFZfi/huZRxs9Y9zqWWD6oQp ZybhvC2zLaWg1lTIEGHYJIOvIzryN+htrBL+VprD6OOP35gdiDiyxJg+G71uf7IDElz8 uVpkTjtr9Re2jTiYQY8y/C0omxfab8CMR4j9cTccOmo3m8jtDZYNueh33KVguxb6uBQp Oe3g== X-Gm-Message-State: AOAM533oFD6mG/g3JB/onfJ0dr8cY6dJqm7LeoDT5wZ69doqVqxg/srJ 5BTL3vn2L+YMvYkQvAjoK5Gns/aHKeq//CZThNd0qi4HuWH9cQ== X-Received: by 2002:a05:6e02:1a08:b0:2c9:caca:b2 with SMTP id s8-20020a056e021a0800b002c9caca00b2mr8773091ild.247.1648748568350; Thu, 31 Mar 2022 10:42:48 -0700 (PDT) MIME-Version: 1.0 References: <20220324210909.1843814-1-axelrasmussen@google.com> In-Reply-To: From: Axel Rasmussen Date: Thu, 31 Mar 2022 10:42:12 -0700 Message-ID: Subject: Re: [PATCH] mm/secretmem: fix panic when growing a memfd_secret To: Matthew Wilcox Cc: Andrew Morton , Mike Rapoport , Linux MM , LKML , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Any strong opinions on which error code is used? I think overall I would still pick EOPNOTSUPP, but happy to change it if anyone feels strongly. - I think ENOSYS is specific to syscall nr not defined - I think ENOTTY is specific to ioctls - The kernel (sort of mistakenly) defines ENOTSUPP instead of ENOTSUP, but it's marked deprecated and it's recommended to use EOPNOTSUPP instead (despite POSIX saying these should be distinct and for different uses). On Thu, Mar 24, 2022 at 2:44 PM Axel Rasmussen wrote: > > On Thu, Mar 24, 2022 at 2:33 PM Matthew Wilcox wrote: > > > > On Thu, Mar 24, 2022 at 02:09:09PM -0700, Axel Rasmussen wrote: > > > This patch avoids the panic by implementing a custom setattr for > > > memfd_secret, which detects resizes specifically (setting the size for > > > the first time works just fine, since there are no existing pages to try > > > to zero), and rejects them as not supported (ENOTSUP). > > > > Isn't ENOTTY the normal return value for this? Or even ENOSYS? > > I'm unsure. > > Since errno(3) says ENOTTY means "Inappropriate I/O control operation" > that makes me think it's meant to be used only for ioctls? > > I tried ENOSYS, but checkpatch warns me it's meant to be used for > "invalid syscall nr" and nothing else. > > ENOTSUP / ENOTSUPP / EOPNOTSUPP all have their own share of > weirdnesses too, though. There's the whole ENOTSUP / ENOTSUPP mess, > and then also the fact that glibc says ENOTSUP == EOPNOTSUPP, whereas > POSIX says EOPNOTSUPP should be distinct and used specifically for > sockets...