Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Miklos Szeredi <miklos@szeredi.hu>,
        Steve French <smfrench@gmail.com>
CC:     lsf-pc <lsf-pc@lists.linux-foundation.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [LSF/MM/BPF TOPIC] making O_TMPFILE more atomic
Thread-Topic: [LSF/MM/BPF TOPIC] making O_TMPFILE more atomic
Thread-Index: AQHYXx8AcME9bSUZ70Wny3lit7kdCq0WugaA
Date:   Mon, 9 May 2022 15:47:49 +0000
Message-ID: <DAE0F6CD-F232-4305-9CCF-3F601124BFBC@oracle.com>
References: <CAH2r5mv7Z7XmyWgp5K8ZshA1OiMBTNGU-v8FdmwwkZaNNe=4wA@mail.gmail.com>
 <CAJfpegskJzpXXhWCdw6K9r2hKORiBdXfSrgpUhKqn9VVyuVuqw@mail.gmail.com>
In-Reply-To: <CAJfpegskJzpXXhWCdw6K9r2hKORiBdXfSrgpUhKqn9VVyuVuqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xaDjnDQk2k0kXBG2oA2YlX2AHEHJ9GdUnkMHhHe0kwL+7dWdyTWV+TOayQvx?=
 =?us-ascii?Q?g5unqWRyij3PgkUWgjPXZ088LfaMNnIhuTRlS5pkrF4NSDadvUGDEHQSmpA3?=
 =?us-ascii?Q?hKQJB453Ss24IJn/jrErBJlw2ClGP8ATyBf17nqRnVpQrxO6+d05WB7VkhqP?=
 =?us-ascii?Q?pnlLHTVF4QznI3FdUaXN1RGOqeGCYn2BONPB8IfzT/LBlcJPxQ1FCTGvtqtE?=
 =?us-ascii?Q?4ajFHf+aGvQuKghBjhdKmS2WMrxklMnQx3OwL3RW7U/Xw7jabLPAFHXnscX9?=
 =?us-ascii?Q?TR8Fj/4EhwZnCzNHzRIYR1yyrr5wq1TIQaorNiNIczmHnAJ2HTG5LF6HfFlM?=
 =?us-ascii?Q?TRUMiem7WlR92ycbqztchKJYdEeXHMZoMi0Q9PxhrsTUEuKB1AT7bDqgDmfw?=
 =?us-ascii?Q?Vx0+9XCYsyrq8Tet31y8CNPdsg5SZWcHb/rXSL3xx/Wuws90jii/t1GK7eXg?=
 =?us-ascii?Q?VSYbL0QTHDqN3ey3d/zo2MJep45ggyivzkql4Ii3iD+salwixIQnpbobSh/Q?=
 =?us-ascii?Q?MozY5afQ0swvgFu3Y496HnI7OYwKZ9ifLHbAzn5/Jy5wg69Zp0LbpyQMX+ZO?=
 =?us-ascii?Q?Tex7abG8d4X0fKB20duYDkJd6GtCstMBW/d+iNWhmpUID9NO2BCtpEyVQiRC?=
 =?us-ascii?Q?FlAlvUMeyFaBQPLQKGIZD4nCr9kkKrnMN8kj/w7ALVc7a6jtpBmntX2SbFvY?=
 =?us-ascii?Q?BSWe3mCfyd+LwyU6hEmMK04vZNsrDP1J9p9XoJdDhI0aOFMR0D2IEDlkQUgK?=
 =?us-ascii?Q?DIg0lMCkJazyEnsYkDqmxUR0nysuTOlpe3TqEn4NYdAwRvZkaG9jj4HbSUQV?=
 =?us-ascii?Q?TQa7MXXuVwYPB7DutsuwmrQVXno3rFyQp23HQG4ODlUFbQb054w4keRF9XcY?=
 =?us-ascii?Q?HQ6G/GLoQR3dccSvGn+SzxqqggQQER0lZDTsRhrTh+CuDP98WBNDMUWnuaU9?=
 =?us-ascii?Q?IO5McSOEfr729ImQWGtq8HQBroXLk61++QRjepXoLxQqodC/KAENg3GZiDsB?=
 =?us-ascii?Q?mjCgVM4HIw+dm4OeFMziJDk6dI/LiUGQ3EWnhzv1xQljT6PT1aucu7y+V66B?=
 =?us-ascii?Q?FvQAbqc0Z7XwE2gGXu727RwH3S5MS6BvzeeoNsXll2CX8DWurGeGtH7QSE4v?=
 =?us-ascii?Q?7NrbQ9uNMFIc6E/JyToOEbydq3iTwhkgQagy001d+tmPXc6Acfzlm2AYGSmw?=
 =?us-ascii?Q?XbaAXSJtYM4y0DZxk4Bh40kome37pkXBsBpQuvSUDrGo+7UGln7gitE6gpC2?=
 =?us-ascii?Q?qdhl3Jqz4INFQy6nOBSw/Llh/TID77FBaLKERc/yVtwQ3QwoOMLsa6p4Ds8B?=
 =?us-ascii?Q?sRWqGQdsCiBPhsJhobz3wquaO32hdOMfP47kp15bfg8jVO7B/I18+r+7vaCi?=
 =?us-ascii?Q?fH7vWewR3pL/ph8HndWw7CrYBM4VChyRBUg5azv/t+eIX45AIuMAO5fx6JuB?=
 =?us-ascii?Q?hr556cfVUtcZCtc3mLxaXseLtnFSrkEzU6JQIbdt61UDO/w2x58BK5cNcQ7Y?=
 =?us-ascii?Q?Le7i2JdmU1alRVBvUZw8y70lBvdm21hW1hP5gq89ZAdg4snSHtpvPYkusHTH?=
 =?us-ascii?Q?m0xBmc9BwzqPAwykjeF5ekrHKKOJS8g2RUgvJ9Y7eJI/rHhY99NIzXH3fnD7?=
 =?us-ascii?Q?qIrVCuO9yty9NdgUK0Is3crE+dKWi1QZ/XuVCZh5mmNzjVMeDlGa1ljZg6ax?=
 =?us-ascii?Q?pz0tHcDInQkowOdPqU/A72JhHzVzvZedM87gruEpek6UkrXVNMe+hYF7z1et?=
 =?us-ascii?Q?eE4wz778fgSmDCvxuJv8Sgp71mK9jiE=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BF4B23DC647E114F9A05E66935EB0F0E@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1020b36c-8e96-4193-976f-08da31d34583
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2022 15:47:49.9833
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OvNoYd/xZoRoiNJDutp5kZccj/nfVqBYyLoTczrU+njHx5tDTpg+/d+BSr/uMntTu6/hfGhg+6Mjig5nrvjooA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB3152
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-05-09_04:2022-05-09,2022-05-09 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 bulkscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2205090088
X-Proofpoint-GUID: jp6u6r6EGbNX24F3ti7PTgavFglIbJlh
X-Proofpoint-ORIG-GUID: jp6u6r6EGbNX24F3ti7PTgavFglIbJlh
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On May 3, 2022, at 2:52 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>=20
> On Thu, 24 Feb 2022 at 06:33, Steve French <smfrench@gmail.com> wrote:
>>=20
>> Currently creating tmpfiles on Linux can be problematic because the
>> tmpfile is not created and opened at the same time  (vfs_tmpfile calls
>> into the fs, then later vfs_open is called to open the tmpfile).   For
>> some filesystems it would be more natural to create and open the
>> tmpfile as one operation (because the action of creating the file on
>> some filesystems returns an open handle, so closing it then reopening
>> it would cause the tmpfile to be deleted).
>>=20
>> I would like to discuss whether the function do_tmpfile (which creates
>> and then opens the tmpfile) could have an option for a filesystem to
>> do this as one operation which would allow it to be more atomic and
>> allow it to work on a wider variety of filesystems.
>=20
> A related thread:
>=20
> https://lore.kernel.org/all/20201109100343.3958378-3-chirantan@chromium.o=
rg/#r
>=20
> There was no conclusion in the end. Not sure how hacky it would be to
> store the open file in the inode...

I just proposed adding a VFS API to make open/create atomic.
See 8/8 in this thread:

https://lore.kernel.org/linux-nfs/20220420192418.GB27805@fieldses.org/T/#m5=
05a59ad4e4ed1413ffc055a088de3182fb50bb4

It adds a sibling API to dentry_open(). I didn't have
O_TMPFILE in mind when I created this API.


--
Chuck Lever