[{"id":3673622,"web_url":"http://patchwork.ozlabs.org/comment/3673622/","msgid":"<20260405233222.GW3836593@ZenIV>","list_archive_url":null,"date":"2026-04-05T23:32:22","subject":"Re: [PATCH 2/2] smb: client: add support for O_TMPFILE","submitter":{"id":583,"url":"http://patchwork.ozlabs.org/api/people/583/","name":"Al Viro","email":"viro@ZenIV.linux.org.uk"},"content":"On Sun, Apr 05, 2026 at 06:18:19PM -0300, Paulo Alcantara wrote:\n\n> @@ -436,17 +457,13 @@ static int cifs_do_create(struct inode *inode, struct dentry *direntry, unsigned\n>  \t\tgoto out_err;\n>  \t}\n>  \n> -\tif (newinode)\n> -\t\tif (S_ISDIR(newinode->i_mode)) {\n> -\t\t\trc = -EISDIR;\n> -\t\t\tgoto out_err;\n> -\t\t}\n> +\tif (newinode && S_ISDIR(newinode->i_mode)) {\n> +\t\trc = -EISDIR;\n> +\t\tgoto out_err;\n> +\t}\n>  \n>  \td_drop(direntry);\n> -\td_add(direntry, newinode);\n\n> +\t\trc = __cifs_do_create(dir, direntry, full_path, xid,\n> +\t\t\t\t      tlink, oflags, mode, oplock,\n> +\t\t\t\t      fid, buf, &inode);\n> +\t\tif (!rc)\n> +\t\t\td_add(direntry, inode);\n\n\n> +\t\trc = __cifs_do_create(dir, dentry, path, xid, tlink,\n> +\t\t\t\t      file->f_flags, mode, &oplock,\n> +\t\t\t\t      &fid, NULL, &inode);\n> +\t\tif (!rc) {\n> +\t\t\tset_nlink(inode, 0);\n> +\t\t\tmark_inode_dirty(inode);\n> +\t\t\td_mark_tmpfile_name(file, &QSTR_LEN(name, size - 1));\n> +\t\t\td_instantiate(dentry, inode);\n\nI really don't like this \"not sure what the state is, d_drop() to\nget it unhashed\" pattern, _especially_ when d_drop() and d_add() or\nd_instantiate() get separated.\n\nNote, BTW, this d_add() call site is one of the two in the entire kernel\nthat are neither d_splice_alias() in disguise nor pass NULL as inode.\nThe other one is nfs_link(), where we also have this kind of \"d_drop()\nfirst, then use d_add()\" pattern.\n\nFolks, what state can dentry be in cifs_do_create()?  I'd rather see\nthat sorted out, not obfuscated even more.\n\nFWIW, that's a major headache for Neil's stuff around directory locking\nchanges - any place where we play with unhash-and-rehash needs separate\nanalysis.  d_drop() is not something to be used lightly; it obfuscates the\ndentry state and we'll need to translate those to the new locking scheme.","headers":{"Return-Path":"\n <linux-cifs+bounces-10670-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-cifs@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linux.org.uk header.i=@linux.org.uk header.a=rsa-sha256\n header.s=zeniv-20220401 header.b=gOtfBH6e;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10670-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk\n header.b=\"gOtfBH6e\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=62.89.141.173","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=ftp.linux.org.uk"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fppYs1lXNz1yFt\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 06 Apr 2026 09:28:49 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 2A20930063AB\n\tfor <incoming@patchwork.ozlabs.org>; Sun,  5 Apr 2026 23:28:47 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 97D7C33F5BC;\n\tSun,  5 Apr 2026 23:28:46 +0000 (UTC)","from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id F0F2433F8A3;\n\tSun,  5 Apr 2026 23:28:43 +0000 (UTC)","from viro by zeniv.linux.org.uk with local (Exim 4.99.1 #2 (Red Hat\n Linux))\n\tid 1w9Wx5-0000000Di4i-041w;\n\tSun, 05 Apr 2026 23:32:23 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775431726; cv=none;\n b=ekSUAypvoXagasKFRjhgB/RToKsNGiC+Vn00IL6KonmW9VFHJKHfUEwHaU+c0uenPYND+wseCTNLmuKdpvYDnf+VDhbH5QqCAJGNfHd1iDov6auJzLs1F2c1fFswrk6UKxWs8WcspXYR5BK63SwfoGVd2CTC4JC9PrUgHpLjYi0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775431726; c=relaxed/simple;\n\tbh=u8cVb4wU1yq68havVuiF0o8l9PzF/vN+DMfVKEO5GOs=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=F9RsvDbeboHIZVyJtCgJlUTGGOI7NCSSexB/f+pPBhSH1g8nl3Hu5qrjCSHfPaUe2IKcSbHSsZllF26LyAEdCNsWqTFFCcvrpifeU0cyJ4B+abE1+9OO+wt1aZ06/I6KHmN3uI46xC969dQnua7q3Q9AG7omiIcWzBZc0tmzWtg=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk;\n spf=none smtp.mailfrom=ftp.linux.org.uk;\n dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk\n header.b=gOtfBH6e; arc=none smtp.client-ip=62.89.141.173","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type:\n\tMIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=S6dL0DMlTr7pWinIvY0E9M0o6ErcEOcOmnsEnXhkEoY=; b=gOtfBH6ehak6y8ecVZ6XnaL6T0\n\t94Bc651XDuWUdTr9YHIMfzDwT97Bav6isqm12D7kAQ/PM965qTNTZeTahaZKDDRwZm5RZI53IDVCa\n\txCu87SzSSMz2rkWrDPcGHjO0hx/Wqv/BecY2CwX/XCjE+S2VZ1K/QuafR9avTKmHQtq1JLmztY9K1\n\tozBbjn4DCu+BG+LSlue/1cvKS4dCcVF+C5fYQlfKVZfyz0NoGyG9ZFV6GoESaGVoiVcMz1LTLmWCB\n\tqlkeJ2cnFO0vb9wC5rwnIepwz9oe65/DjU9l0RcztsrPLrsRUcTdPdAqnHh6mFB8H6+qhRQSdZgVA\n\tD26NiXwQ==;","Date":"Mon, 6 Apr 2026 00:32:22 +0100","From":"Al Viro <viro@zeniv.linux.org.uk>","To":"Paulo Alcantara <pc@manguebit.org>","Cc":"smfrench@gmail.com, David Howells <dhowells@redhat.com>,\n\tlinux-fsdevel@vger.kernel.org, linux-cifs@vger.kernel.org,\n\tNeil Brown <neil@brown.name>","Subject":"Re: [PATCH 2/2] smb: client: add support for O_TMPFILE","Message-ID":"<20260405233222.GW3836593@ZenIV>","References":"<20260405211819.1251369-1-pc@manguebit.org>\n <20260405211819.1251369-2-pc@manguebit.org>","Precedence":"bulk","X-Mailing-List":"linux-cifs@vger.kernel.org","List-Id":"<linux-cifs.vger.kernel.org>","List-Subscribe":"<mailto:linux-cifs+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-cifs+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260405211819.1251369-2-pc@manguebit.org>","Sender":"Al Viro <viro@ftp.linux.org.uk>"}},{"id":3673633,"web_url":"http://patchwork.ozlabs.org/comment/3673633/","msgid":"<177543319568.1474915.17445767081272255066@noble.neil.brown.name>","list_archive_url":null,"date":"2026-04-05T23:53:15","subject":"Re: [PATCH 2/2] smb: client: add support for O_TMPFILE","submitter":{"id":91821,"url":"http://patchwork.ozlabs.org/api/people/91821/","name":"NeilBrown","email":"neilb@ownmail.net"},"content":"On Mon, 06 Apr 2026, Al Viro wrote:\n> On Sun, Apr 05, 2026 at 06:18:19PM -0300, Paulo Alcantara wrote:\n> \n> > @@ -436,17 +457,13 @@ static int cifs_do_create(struct inode *inode, struct dentry *direntry, unsigned\n> >  \t\tgoto out_err;\n> >  \t}\n> >  \n> > -\tif (newinode)\n> > -\t\tif (S_ISDIR(newinode->i_mode)) {\n> > -\t\t\trc = -EISDIR;\n> > -\t\t\tgoto out_err;\n> > -\t\t}\n> > +\tif (newinode && S_ISDIR(newinode->i_mode)) {\n> > +\t\trc = -EISDIR;\n> > +\t\tgoto out_err;\n> > +\t}\n> >  \n> >  \td_drop(direntry);\n> > -\td_add(direntry, newinode);\n> \n> > +\t\trc = __cifs_do_create(dir, direntry, full_path, xid,\n> > +\t\t\t\t      tlink, oflags, mode, oplock,\n> > +\t\t\t\t      fid, buf, &inode);\n> > +\t\tif (!rc)\n> > +\t\t\td_add(direntry, inode);\n> \n> \n> > +\t\trc = __cifs_do_create(dir, dentry, path, xid, tlink,\n> > +\t\t\t\t      file->f_flags, mode, &oplock,\n> > +\t\t\t\t      &fid, NULL, &inode);\n> > +\t\tif (!rc) {\n> > +\t\t\tset_nlink(inode, 0);\n> > +\t\t\tmark_inode_dirty(inode);\n> > +\t\t\td_mark_tmpfile_name(file, &QSTR_LEN(name, size - 1));\n> > +\t\t\td_instantiate(dentry, inode);\n> \n> I really don't like this \"not sure what the state is, d_drop() to\n> get it unhashed\" pattern, _especially_ when d_drop() and d_add() or\n> d_instantiate() get separated.\n> \n> Note, BTW, this d_add() call site is one of the two in the entire kernel\n> that are neither d_splice_alias() in disguise nor pass NULL as inode.\n> The other one is nfs_link(), where we also have this kind of \"d_drop()\n> first, then use d_add()\" pattern.\n> \n> Folks, what state can dentry be in cifs_do_create()?  I'd rather see\n> that sorted out, not obfuscated even more.\n\ncifs_do_create() gets call from cifs_atomic_open() which is\n->atomic_open(), so dentry can be in-lookup or negative-hashed.\n\nIf is also called from cifs_create() (->create()) and as cifs_lookup()\nnever skips the lookup due to intent (like NFS does) the dentry will\nalways be hashed negative.\n\nSo dentry can be in-lookup or hashed-negative.  With current APIs we can\navoid d_drop() with\n\n if (d_in_lookup(dentry))\n    d_add(dentry, inode);\n else\n    d_instantiate(dentry, inode);\n\nthough I would prefer to provide an interface which handled both.\n\nNeilBrown\n\n\n> \n> FWIW, that's a major headache for Neil's stuff around directory locking\n> changes - any place where we play with unhash-and-rehash needs separate\n> analysis.  d_drop() is not something to be used lightly; it obfuscates the\n> dentry state and we'll need to translate those to the new locking scheme.\n>","headers":{"Return-Path":"\n <linux-cifs+bounces-10672-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-cifs@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ownmail.net header.i=@ownmail.net header.a=rsa-sha256\n header.s=fm2 header.b=Nc5j3f7w;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm2 header.b=Uo3d0MnJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10672-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net\n header.b=\"Nc5j3f7w\";\n\tdkim=pass (2048-bit key) header.d=messagingengine.com\n header.i=@messagingengine.com header.b=\"Uo3d0MnJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.12.124.151","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=ownmail.net","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=ownmail.net"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fpq6L0bWlz1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 06 Apr 2026 09:53:29 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id D1B053005AED\n\tfor <incoming@patchwork.ozlabs.org>; Sun,  5 Apr 2026 23:53:26 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C4FFE2F1FC9;\n\tSun,  5 Apr 2026 23:53:23 +0000 (UTC)","from fout-b8-smtp.messagingengine.com\n (fout-b8-smtp.messagingengine.com [202.12.124.151])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 49DF828751B;\n\tSun,  5 Apr 2026 23:53:21 +0000 (UTC)","from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])\n\tby mailfout.stl.internal (Postfix) with ESMTP id 635FC1D00060;\n\tSun,  5 Apr 2026 19:53:20 -0400 (EDT)","from phl-frontend-04 ([10.202.2.163])\n  by phl-compute-05.internal (MEProxy); Sun, 05 Apr 2026 19:53:20 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Sun,\n 5 Apr 2026 19:53:17 -0400 (EDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775433203; cv=none;\n b=dGIinwVHe83xarK3ehR8eIPlX4so/htgjBcF9TphGLYX+grrVG8CPiFGjbC5KcJCtPI6jRKeZicQAGkZ6uYdiPMHVJb0lPWq4boRMNkUPj3t5uSrTFlmwlInONntls3UmIW4P6HOAtII0rvbKOTwA9F9wtSbh+El555f1qtd79A=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775433203; c=relaxed/simple;\n\tbh=AQMHzBnALza5eY2MjjjaJfLYkZMud4a+1WKHhQBPrRg=;\n\th=Content-Type:MIME-Version:From:To:Cc:Subject:In-reply-to:\n\t References:Date:Message-id;\n b=btOYPY3qJeja0vk3eplWEvk+c72Ws3MVxAFH6806pu8oubs7I+RQAYVnvfJ+ehAm8vxTH1EvPNy9mkbwBL130ofhqnTXuUum77HpwCUEGH3pBIWTnZ3HMnqMjToJYzMMIoTvL6UGJY8QZEHZk2G2UhAYyRawaxguS+/Hf0P8BHY=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=ownmail.net;\n spf=pass smtp.mailfrom=ownmail.net;\n dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net\n header.b=Nc5j3f7w;\n dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com\n header.b=Uo3d0MnJ; arc=none smtp.client-ip=202.12.124.151","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h=\n\tcc:cc:content-transfer-encoding:content-type:content-type:date\n\t:date:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:reply-to:subject:subject:to:to; s=fm2; t=\n\t1775433200; x=1775519600; bh=sLDyAQJ4Qij5PU7AO3RaMblOxAB3WklwTIN\n\tzz9rGZbI=; b=Nc5j3f7w3KobSvPd2wXH9/Zft5j3Y5WohM4yxtSA45ujSlqzaBj\n\t9G2LK82c15RP2Yn/QPTjOd8oV/1F+xYd8omFJt0gCKs+wCh14gUf8CqtPY0GJpeq\n\t8us/C5jCsXCgUlvxJcJ3bO7wI/QX1NRQgMrpV3iKWLkaiAD0MRkwsiRmXby9Oznf\n\tn84wH2z51arkhhteCb6eKMWVJ6nr9152a9dmqdZMfVXpQJ7P7VFn+D9F8CPAydsy\n\tB+gHUYMHVOdAaje9vmnRjUWJj9JMs1+xGBaBBQRb2cvlDw4tPzNMM298ajFgfiV9\n\tqVZ2n/piH3Mno0fO6YVerKdJ1+slO3AvECw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:cc:content-transfer-encoding\n\t:content-type:content-type:date:date:feedback-id:feedback-id\n\t:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:reply-to:subject:subject:to:to:x-me-proxy\n\t:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1775433200; x=\n\t1775519600; bh=sLDyAQJ4Qij5PU7AO3RaMblOxAB3WklwTINzz9rGZbI=; b=U\n\to3d0MnJJhdI6CyjtsJZ0VRnxwP7BTBUqZZh9owfkwjsk9p0+sDvFBNseZ/ob1+EH\n\tnRroagTFZzyUMvj2b++IFmK+NZwSnqqxVTpfPyuodiDSIflBXCZrAxwq6lhR1MB+\n\t6rlPsrztlp5y0kwN0F6++0IYDxrrrjnbLBLGsih4H7u8bNioc7v0eTiJmI4dm7gf\n\t2Jj1Cxeu/UqdBeNogKebaGARRTXKSrj2AcafvR1lD9btD+8GCsvJi6TU4stDoYAu\n\tHcmzZeugKFchrXMrEfWzv4+4HtS/7xLwsD/zmCveS0XEqx5ceLWsJSHsF3egIssp\n\tOsITu5sgHtAv/NM4Us57A=="],"X-ME-Sender":"<xms:7_XSaerFqxHsb9XY644u7b99oOdIUk2BKxckgU8XvghtpeIqY1ZrPA>\n    <xme:7_XSae6EeTgOes9fXTjHCOz50abVteEoKGhKXH_Ioqidt256ylmuUih3YQRhK3S0T\n    2ouYuzP9vTJ0SB9JY6cFT_-TTyjpgRsLpBEIwAws0bgtawn8A>","X-ME-Received":"\n <xmr:7_XSaVdJ1xODTqSfaCM7p4zllDi8eZ-cwAIf5GQOZvV9w_PU8cy4_gWHTUtGP0jYJQ>","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduieduiecutefuodetggdotefrod\n    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr\n    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug\n    hrpegtgfgghffvvefujghffffkrhesthhqredttddtjeenucfhrhhomheppfgvihhluehr\n    ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe\n    eljedtfeegueekieetudevheduveefffevudetgfetudfhgedvgfdtieeguedujeenucev\n    lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse\n    hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeeipdhmohguvgepshhmthhpohhu\n    thdprhgtphhtthhopehvihhrohesiigvnhhivhdrlhhinhhugidrohhrghdruhhkpdhrtg\n    hpthhtoheplhhinhhugidqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp\n    rhgtphhtthhopehlihhnuhigqdgtihhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh\n    gtphhtthhopeguhhhofigvlhhlshesrhgvughhrghtrdgtohhmpdhrtghpthhtohepphgt\n    sehmrghnghhuvggsihhtrdhorhhgpdhrtghpthhtohepshhmfhhrvghntghhsehgmhgrih\n    hlrdgtohhm","X-ME-Proxy":"<xmx:7_XSaT7ScXutRmBTtCc730uFNHAh_vVV1Z6jRZjaok1a6euQbxI4tA>\n    <xmx:7_XSacsMN6_c36fIgIrMW1d16P6QyUjYafS0DTG3JDk1tI_vwm2epA>\n    <xmx:7_XSaTg0YDfsS2ll9uWksKJhiDPxGYnW9eiU2PI_P76SsW1Tn3RPfQ>\n    <xmx:7_XSaXrnWipGySpdpI8ZW9KiTxS7kVVHZEnADFUVkTXJpCGAO3kBFQ>\n    <xmx:8PXSabX0Jr2vKLp6NJpd7jfcDnmZIOTHC8YLjSfj1Knb2jA3DI_LJhDc>","Feedback-ID":"i9d664b8f:Fastmail","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"quoted-printable","Precedence":"bulk","X-Mailing-List":"linux-cifs@vger.kernel.org","List-Id":"<linux-cifs.vger.kernel.org>","List-Subscribe":"<mailto:linux-cifs+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-cifs+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","From":"NeilBrown <neilb@ownmail.net>","To":"\"Al Viro\" <viro@zeniv.linux.org.uk>","Cc":"\"Paulo Alcantara\" <pc@manguebit.org>, smfrench@gmail.com,\n \"David Howells\" <dhowells@redhat.com>, linux-fsdevel@vger.kernel.org,\n linux-cifs@vger.kernel.org","Subject":"Re: [PATCH 2/2] smb: client: add support for O_TMPFILE","In-reply-to":"<20260405233222.GW3836593@ZenIV>","References":"<20260405211819.1251369-1-pc@manguebit.org>\n  <20260405211819.1251369-2-pc@manguebit.org>\n  <20260405233222.GW3836593@ZenIV>","Date":"Mon, 06 Apr 2026 09:53:15 +1000","Message-id":"<177543319568.1474915.17445767081272255066@noble.neil.brown.name>","Reply-To":"NeilBrown <neil@brown.name>"}}]