From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FF2D53B7 for ; Wed, 9 Aug 2023 11:00:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E37CBC433C8; Wed, 9 Aug 2023 11:00:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1691578834; bh=LxxPAO363gau4k3+8+d5yNDcEhAjhPn+8KCtVlaA+Mo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yloFmPo0GQ2B5F4zJ9W/yTFdZ3rxzHq5mBi1NpeZ08yrFEd6+3hjw8o58TflwtvYb +JYdy3sLfCw8SDnW7CQ3fYrDsryE7NdmFPOtB/4nQP5K7KdnvkimWY7Ie4GYMpdTfL 7i0EpYqt36QJkwAxniQZKWh1+sM2Ucyj/TwNFst8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Mateusz Guzik , Christian Brauner , Linus Torvalds Subject: [PATCH 5.15 73/92] file: reinstate f_pos locking optimization for regular files Date: Wed, 9 Aug 2023 12:41:49 +0200 Message-ID: <20230809103636.087989996@linuxfoundation.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230809103633.485906560@linuxfoundation.org> References: <20230809103633.485906560@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Linus Torvalds commit 797964253d358cf8d705614dda394dbe30120223 upstream. In commit 20ea1e7d13c1 ("file: always lock position for FMODE_ATOMIC_POS") we ended up always taking the file pos lock, because pidfd_getfd() could get a reference to the file even when it didn't have an elevated file count due to threading of other sharing cases. But Mateusz Guzik reports that the extra locking is actually measurable, so let's re-introduce the optimization, and only force the locking for directory traversal. Directories need the lock for correctness reasons, while regular files only need it for "POSIX semantics". Since pidfd_getfd() is about debuggers etc special things that are _way_ outside of POSIX, we can relax the rules for that case. Reported-by: Mateusz Guzik Cc: Christian Brauner Link: https://lore.kernel.org/linux-fsdevel/20230803095311.ijpvhx3fyrbkasul@f/ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- fs/file.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/fs/file.c +++ b/fs/file.c @@ -1062,12 +1062,28 @@ unsigned long __fdget_raw(unsigned int f return __fget_light(fd, 0); } +/* + * Try to avoid f_pos locking. We only need it if the + * file is marked for FMODE_ATOMIC_POS, and it can be + * accessed multiple ways. + * + * Always do it for directories, because pidfd_getfd() + * can make a file accessible even if it otherwise would + * not be, and for directories this is a correctness + * issue, not a "POSIX requirement". + */ +static inline bool file_needs_f_pos_lock(struct file *file) +{ + return (file->f_mode & FMODE_ATOMIC_POS) && + (file_count(file) > 1 || S_ISDIR(file_inode(file)->i_mode)); +} + unsigned long __fdget_pos(unsigned int fd) { unsigned long v = __fdget(fd); struct file *file = (struct file *)(v & ~3); - if (file && (file->f_mode & FMODE_ATOMIC_POS)) { + if (file && file_needs_f_pos_lock(file)) { v |= FDPUT_POS_UNLOCK; mutex_lock(&file->f_pos_lock); }