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 08E72EEB570 for ; Fri, 8 Sep 2023 20:34:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43B1D6B00F4; Fri, 8 Sep 2023 16:34:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EA8C6B00F6; Fri, 8 Sep 2023 16:34:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B21F6B00F7; Fri, 8 Sep 2023 16:34:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1B07A6B00F4 for ; Fri, 8 Sep 2023 16:34:34 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E5CCE1601B3 for ; Fri, 8 Sep 2023 20:34:33 +0000 (UTC) X-FDA: 81214583226.23.F816DCD Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) by imf10.hostedemail.com (Postfix) with ESMTP id F06C5C0008 for ; Fri, 8 Sep 2023 20:34:31 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=lwn.net header.s=20201203 header.b=HTkoomFf; spf=pass (imf10.hostedemail.com: domain of corbet@lwn.net designates 45.79.88.28 as permitted sender) smtp.mailfrom=corbet@lwn.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694205272; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MDqJnX+WbR6SonVUJc2b/jr2kB7zjQHa9+7BCtZ8K2A=; b=fz938IKiTOkMZt2HOWvbpXvXht4X2s0iEQY2OOw2toU18BiJRn73slTVVlVuNgUUCusJIE TBIAFrnN9x1PLhxYMlxgldz9E5ZS/oAynBze2xl3lhLtjnCox38URxWABTKZxkam0/9MBR z8jZ/XGnl2c8vQX5hm7grA/yhZTJhFM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=lwn.net header.s=20201203 header.b=HTkoomFf; spf=pass (imf10.hostedemail.com: domain of corbet@lwn.net designates 45.79.88.28 as permitted sender) smtp.mailfrom=corbet@lwn.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694205272; a=rsa-sha256; cv=none; b=zmgGOL0v2Kbcl6CfNhDsz6JocS3xxbekED2sj+z5hVlfJcS184N0/04mNO9TplKGyo7GCH xDvfaPsdRAaeDog4BSBkN3psw8bmd3uz46uTKF0JlHwIk8aRYHeuwlvoeSylDQkoYAf5Lv lBOEotOeqMpyJ1O8glt55x6uVm548rg= Received: from localhost (unknown [IPv6:2601:281:8300:73::646]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id E0603732; Fri, 8 Sep 2023 20:34:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net E0603732 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1694205270; bh=MDqJnX+WbR6SonVUJc2b/jr2kB7zjQHa9+7BCtZ8K2A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HTkoomFfydhscycwnKd3Cy9JPJ+BEWU99bVy1XpLrFCnWKMW1CV4/tdC2XtjtbO5t PTIgn9ZaMnT3Z7S7TkMeMYa+93uHTfbD725swExTm//fZ4BlPmpgp9EbCjgFTyHzUB KLZ1QEbzihpL7c7/ol1uYdiwqIFSWHTaLmyX/sHE3ALPXiYSRxdIwAzwxY311wXcRL hebiJpl7KFKV3t+IHOqNSFjOF7nDLjy3SahLBRBUBR23vWG/uVpo0DY0z7J6EPHGzw +IVmmMZqnaz7CAOuB/RXy9VY0qDIk2GVU/2jMyU2fYYPsKZLlTkzLhYsCSEMhQtvML Ck7Co0a4wQR/w== From: Jonathan Corbet To: Michal Clapinski , Mike Kravetz , Muchun Song , Andrew Morton , Hugh Dickins , Shuah Khan , Greg Kroah-Hartman , Arnd Bergmann , Yi Liu , Dominik Brodowski , Hans Verkuil , Steve French , Simon Ser , Jason Gunthorpe , Marc Dionne , Jiri Slaby , David Howells , Luca Vizzarro , Jeff Xu , Aleksa Sarai , Kees Cook , Daniel Verkamp , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Cc: Michal Clapinski Subject: Re: [PATCH v2 0/2] mm/memfd: add ioctl(MEMFD_CHECK_IF_ORIGINAL) In-Reply-To: <20230908175738.41895-1-mclapinski@google.com> References: <20230908175738.41895-1-mclapinski@google.com> Date: Fri, 08 Sep 2023 14:34:29 -0600 Message-ID: <87tts4z9nu.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: F06C5C0008 X-Rspam-User: X-Stat-Signature: dpchr9oyp9yx4u76eb1s698s4qdotqex X-Rspamd-Server: rspam01 X-HE-Tag: 1694205271-750145 X-HE-Meta: U2FsdGVkX1/za2dHw1OB+UPPHH94IBOkJINjOidA0kmtSfQq6b74peIhypVNKRhZ72boF7g+g1IMTZ1wDechbCdtVVO6xnUEu2MAMH7jm63Z/5tdQ/+rvxgwvEHPvJsbfxV10x5iCzIQauMgiI2sDvp2B+/YrwYPOyCpBDCLj1s4c2GCXQEUdsFM5GHZqTZW6tTuLvUtvLJuQaf58PZKy1Xm0wyBO677Vz4k3MiH8hipXiNxYNQb63wgvZ3ZFtKzGmHsys91ShPmYgyKfatHgTG03mGL0g0gnX4FM1S9uy/PgdyvzcSH/cbdqMRWQoLPtcDUCUSM/cfO7TvXjYSGRRe0d+CFYGKtvM0OIE8zbLELlOeubBI2ku9Dk/DVmFjhkb0zSve6NfUz5l7OMmGjnMLJE1tEMxdYzcALnij7bff3Z9h/KS9sbJQ402toaStEBwbDTdrvfIJFYP+b7Xb/3zUderK1lfhRF8pg0VRHx6gYGBZ5CpzhacumoQO/biupiCi2Mkljk4jlskmsGFDva2QbUKcmEo0/rD+0cpO2KjMM5GtanJJCjXreOc1nilai+E6tEttkLFnGKMqpmXNJzlwNj5/RCvVaT4zHP0AEfWgv3vvb7PRz3jr66uRVO5Kg8MwcbPmEi9HcnXeq4e6lQsYD3aAQyXmBgf0kFdMmxanhqYgGL6Y4fzRcdZ1e0apgb2WJfmMA6gW0zQ9wNPSHUGcGggQZiqlKqAnYYmnjsyJ4tCpm7hIP280wFhGGeQfsYZTo8ZWZtghUL3njjRKagw5IbIR3UkTPZ16KNs2Ui0g2q1eu2wTiF4fFVnkR1FMOczIWNUN9b8U7N/wwhmrPWdEugF4ZkKfVgxCYeL6vqCLj20R7h44rj5kCDJZqdMNeL3doJ2iaKnQE+SpKcjTNGvC31iijbzQNBUDKy1Bab2uKovWsoyBiMklZFi5qjS4k8A+BXtlTtivLAyJ07Tn mijhrxqV 5PBPMEruzJyh/ZL9Uik++6wydXDsdfrPBdt+VkgUku40AlFOiin+PJsSJBNcdU2ILK91684PTALkOjnX8GYfcuVAiICud+oqHNjTBwEXQjxJo8XTiaOv4rWhyhcPzKfF2AVtrsnlcZHALW1m4b6q7ON+dQWEi5N+xkqudxZ4DiPlXqGMmse/R6vCysvLRWLlCzxqtBxX5Vidqv/E= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Michal Clapinski writes: > This change introduces a way to check if an fd points to a memfd's > original open fd (the one created by memfd_create). > > We encountered an issue with migrating memfds in CRIU (checkpoint > restore in userspace - it migrates running processes between > machines). Imagine a scenario: > 1. Create a memfd. By default it's open with O_RDWR and yet one can > exec() to it (unlike with regular files, where one would get ETXTBSY). > 2. Reopen that memfd with O_RDWR via /proc/self/fd/. > > Now those 2 fds are indistinguishable from userspace. You can't exec() > to either of them (since the reopen incremented inode->i_writecount) > and their /proc/self/fdinfo/ are exactly the same. Unfortunately they > are not the same. If you close the second one, the first one becomes > exec()able again. If you close the first one, the other doesn't become > exec()able. Therefore during migration it does matter which is recreated > first and which is reopened but there is no way for CRIU to tell which > was first. So please bear with me...I'll confess that I don't fully understand the situation here, so this is probably a dumb question. It seems like you are adding this "original open" test as a way of working around a quirk with the behavior of subsequent opens. I don't *think* that this is part of the intended, documented behavior of memfds, it's just something that happens. You're exposing an artifact of the current implementation. Given that the two file descriptors are otherwise indistinguishable, might a better fix be to make them indistinguishable in this regard as well? Is there a good reason why the second fd doesn't become exec()able in this scenario and, if not, perhaps that behavior could be changed instead? Thanks, jon