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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B3BAC433EF for ; Thu, 31 Mar 2022 17:42:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3ED46B0072; Thu, 31 Mar 2022 13:42:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEE4B6B0073; Thu, 31 Mar 2022 13:42:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB50B6B0074; Thu, 31 Mar 2022 13:42:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id CD1386B0072 for ; Thu, 31 Mar 2022 13:42:49 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id A2CC681D60 for ; Thu, 31 Mar 2022 17:42:49 +0000 (UTC) X-FDA: 79305401658.09.984500B Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by imf19.hostedemail.com (Postfix) with ESMTP id 2F2841A0028 for ; Thu, 31 Mar 2022 17:42:49 +0000 (UTC) Received: by mail-il1-f169.google.com with SMTP id t15so278408ilq.12 for ; Thu, 31 Mar 2022 10:42:48 -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=QXyw0wIBSMqTaWj1wzTbPA3bu4xlFqL184azwkkdfFZXduJZE7hValVbdiKefs4JgV 2g5N7+SaWugudqwvt/lMuvlz+ab3K562/p+s1ZKsHB6PcmuVq8O8GRxVopyc4nUU4Gku saEI3mwm2071YJ39EWLK5XEJcNKBXrCICBU+Qs28GX0VGyf+ie2Aois1E9SzEgEf9G1E RAaXGSwzbk+yW1NtzmEUT9OkWYHP56wNO9Mrs+D+QFZa+gA4BkdaZ2h1WLUzh9MEAFoM fdyQerIWs5psjNPwHs8EKvJ+XNXrNv2PIX0uuUw11qenvjwwkS6cYP8wmmQTlNKgzC06 nuVA== X-Gm-Message-State: AOAM5311Kv67Z5axzKtFvf3o0fJm2myfhzjrauJ9X5tebrnQgHdUNm54 LuOuJJktyQtkUYt4ZafZaYpdvahxBTvLMd4nY9bMRQ== X-Google-Smtp-Source: ABdhPJzhrTiHesLUYytbExq7eH2GVZ+C3SxVbjPG4iZ47nyBE8cD82nlbPQh/5qffMfcXUwCDaN6MpXjfUeRDq8K5JE= 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2F2841A0028 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KOCaD+P3; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=axelrasmussen@google.com X-Stat-Signature: m8jd5ypg9yettte1y3os4ur13kbzp479 X-HE-Tag: 1648748569-797745 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000153, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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...