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 62615C4725D for ; Thu, 18 Jan 2024 01:39:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE6126B0080; Wed, 17 Jan 2024 20:39:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E95E56B0083; Wed, 17 Jan 2024 20:39:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0F886B0085; Wed, 17 Jan 2024 20:39:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BFED56B0080 for ; Wed, 17 Jan 2024 20:39:16 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8CBB0120182 for ; Thu, 18 Jan 2024 01:39:16 +0000 (UTC) X-FDA: 81690723912.16.ACC2F35 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf12.hostedemail.com (Postfix) with ESMTP id 8FC2140009 for ; Thu, 18 Jan 2024 01:39:14 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=oEsrkKcs; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf12.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705541955; h=from:from:sender: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=w13llrR137QJAbt1+mR8vqmqXqRNx+wxIFH7k4GCagI=; b=zCq/l/Dp+muYkt5AMK9Qy6xNwRvydPjCQy82UOt8cEX+OzOVExZZn5MTLN+i2eIVWvfGuG j3gvn1TqEZi/EeoqtrAfIm4vik56dZeyrzhxCf2+NyRuDiMlHVIFVmhDJ38DObnXEtwwqe 1rJNpvlZrjOtHCyWCE/ihANX0o4I06k= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=oEsrkKcs; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf12.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705541955; a=rsa-sha256; cv=none; b=6/007Ltlcfi9Qv7OSrZVaqrcj0UcwlFt43ibcHmHB7WOtA94F0Df/fUb6zLK4GF2ANtUxw OYNIJ7gcL/4FJ6rZkpVeV9rQljv0pdtoIkxgxMdBAgZt2eDLSJ0slCC35gxEO0tHa3KAu3 I6VdYpm6ex5f972esann65B9qsK8V6s= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=w13llrR137QJAbt1+mR8vqmqXqRNx+wxIFH7k4GCagI=; b=oEsrkKcsfc9527LZXvFsOgbVc+ qgbY5hmf3S19u2tybAPsbbS8x9aZ1O/G2cYeBtMkZnH7NwD3qHNVfdOBVZwQQQ7bQkoEW6/pBJ5/x x02BhWXyjamDfUZe9u7tAfcM+2dAjqkPVcDflmm4LRShv41d94aLq3BUxbuEg0MByGmp/a5gG0SiE oIrdKJdMzTOubP1Ikd5ltd89GqFB/JdQMzOfm7Dn7ZtxHZbvxxXplWyJ6oJ6oqr4S2pYU513Vlr+P FntGEluXLPNaomz0N+DMs9OvPsAA1e+XulU0pQZl+K33D1E75vNzUDEzeswRbgRDArKwQcRi69t3H 13Fs2i5Q==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1rQHMv-006xCv-19; Thu, 18 Jan 2024 01:38:57 +0000 Date: Thu, 18 Jan 2024 01:38:57 +0000 From: Al Viro To: Baolin Wang Cc: akpm@linux-foundation.org, willy@infradead.org, brauner@kernel.org, jack@suse.cz, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs: improve dump_mapping() robustness Message-ID: <20240118013857.GO1674809@ZenIV> References: <937ab1f87328516821d39be672b6bc18861d9d3e.1705391420.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <937ab1f87328516821d39be672b6bc18861d9d3e.1705391420.git.baolin.wang@linux.alibaba.com> X-Rspamd-Queue-Id: 8FC2140009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ok49xik41zex9nmkrrxrm1sbxx3pbdht X-HE-Tag: 1705541954-645570 X-HE-Meta: U2FsdGVkX1+lR8znPwfpd2w1pdDXJwgfi2JmXZtJXMgV/TpnKlLLIgEvYdY7+8AakfiFJtI3FSknWofQPf25iGw0yUyxJDA9scpwq/8sUn3SFku0v779WeTathOk9aeUlkf0TdqqnP4pXS1zuLYV4ZUDBmHJzS2sTqdRnVGQzqUm9LVIPs29A9BAacKz87CQ0o7HpBmhZGC7XX8E21TUBF9gxiCUsz+vBORyYqUA1E0+FZS/zHNdei6A9RskFQXDrNd1+O+PI4l6L0yMUVgNLuLCLJVa/LtilbJgDOe3bkgIr6vWGO6uCzz8gUxWgivqr+1s7FpKFp0lgRBkouHNXQli69NhqVAEcK6v15Fs7YDa0PNIUYlL53h1rcYNRYYQLTU358ODLVh8wuwGfXz9NbNMOc1NLCqHZ8SvtE3C3OeESSwTvtuT6oncd75qkvXSkKaWzpoZUCXvH1GRyXx01Xfs/jivYJXGefmZrm1m7Xw938fjJh9Ns6v099ojF41K7xxeV10e59iA2agaA60H7MrvIEFKhSw3z9Ujx8S56zIlqbLc6SpXGo2dkxltrPSq5CoYe0hoXYDhoVvzQTSFedqgAkmnZLKigAqqcngqYXcXW/y8/Lwcivau8KiXtv4TuxAETjGe84eg1jXBVlDrQ/aBg0USNcfa4v1WC1jERkTsb8NZpzAanOquXY18s9TbgJO7FmH6Nj32l59odxv6zkcedU9OZq4Yt/k7Fh5qZ98gHvdrS7P6aCfW0daM47zQ4gjasvZjyKqn7HPi9CRFurPX6FwS7O0CebtaX7JkNaanhKFv8DhXnovWFSRguAYEVpOAQsW2cZyiRlTOnenYlbELQRYbMns3SSFuKDQinQlnfR9+vSBKkih1FANEGfcfExoCXxlpwtPAtQsD2VSXHJfJo5zcVYjPROCRFX0Xix2XKyAkCd7/KgUSnuuusDxYdkDZaGXC/X7sD9yYD08 9cRTmEF/ OBz3P15m4f29i7nPfwE13vOXkLsRmEkAT96+8Yul9eEH9EJEyMDC7IRr2Eifm2zFPX/O2QJgXw4lydwb9lEu8ktJYf4aJiKzkFp3ZZCQbmTpZ98W8mPfRhXTwFtKDLfpTZMWfsoldm/iDQQirSDpbSiU9xJFXT9Dqtvu6e4y+7dRB44XD9NKYoCR8a8l2S73/Pm6GnV2hFdu1Nzryd2yek7+gBNtYPWpn8Gp+waPKVBq6Wnv5f/jK2eYcRYKmStTAdOg3lQJ/W9fpkwm1ZNpFEwk7UlaLl9b16X6hP1R6MRnNtYVbfeEwEnyQujt9P6NV4uAEmo8wArTdsPdtdE5M7F+OsNXA5rVKAbpT/Yg42dSPgtVnbTNvdTNuDPMXnxEFfjcKyXM50AkZm+g= 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: List-Subscribe: List-Unsubscribe: On Tue, Jan 16, 2024 at 03:53:35PM +0800, Baolin Wang wrote: > With checking the 'dentry.parent' and 'dentry.d_name.name' used by > dentry_name(), I can see dump_mapping() will output the invalid dentry > instead of crashing the system when this issue is reproduced again. > dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias); > - if (get_kernel_nofault(dentry, dentry_ptr)) { > + if (get_kernel_nofault(dentry, dentry_ptr) || > + !dentry.d_parent || !dentry.d_name.name) { > pr_warn("aops:%ps ino:%lx invalid dentry:%px\n", > a_ops, ino, dentry_ptr); > return; That's nowhere near enough. Your ->d_name.name can bloody well be pointing to an external name that gets freed right under you. Legitimately so. Think what happens if dentry has a long name (longer than would fit into the embedded array) and gets renamed name just after you copy it into a local variable. Old name will get freed. Yes, freeing is RCU-delayed, but I don't see anything that would prevent your thread losing CPU and not getting it back until after the sucker's been freed.