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:   Stephen Brennan <stephen.s.brennan@oracle.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     linux-kernel@vger.kernel.org, Luis Chamberlain <mcgrof@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org,
        Arnd Bergmann <arnd@arndb.de>,
        Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH v2 1/4] dcache: sweep cached negative dentries to the
 end of list of siblings
In-Reply-To: <YgSjo5wascR9mfnA@zeniv-ca.linux.org.uk>
References: <20220209231406.187668-1-stephen.s.brennan@oracle.com>
 <20220209231406.187668-2-stephen.s.brennan@oracle.com>
 <YgSjo5wascR9mfnA@zeniv-ca.linux.org.uk>
Date:   Tue, 15 Feb 2022 18:24:53 -0800
Message-ID: <875ypf8s5m.fsf@stepbren-lnx.us.oracle.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?fKClENC2BncHd/6WIDAhMYD6mJDTS1kfDv+9B+sIQVfiMvXqPFUiBN/+OYla?=
 =?us-ascii?Q?FdLwGGsJwXJsINxXqIEAC95Dxz/6i8gCspnDzjX92Ofq4Y5D8CeHQg1u1pzq?=
 =?us-ascii?Q?H1WX+2dEzNwdU9G+GEJxyVAEPv5IEH8X5Lo3kxz0ihlxXx9vPD0vh9tO1hlN?=
 =?us-ascii?Q?T/I0x8+iPSIahyItmLeAwsycKUFa7mhT5sIfUxmovo1bpW1Ly9EUFPhYpzMx?=
 =?us-ascii?Q?3lTJtkV/jgSXDfV7dQC7VNzFxf/OITjBqLFSNGrKr2SAWUVeiplNXW0UTwe0?=
 =?us-ascii?Q?TFuitlCcdcaFTSul8pDZ3TY3plH87Sp1n6vEUJ59AR8UKVa3KVOPemQYkhGT?=
 =?us-ascii?Q?0egkB8iP/cSY3mWQcz45rf58VRQ2YnCRl8P1r4DubInS164vzMD45Q7rc6yg?=
 =?us-ascii?Q?Zw/jWGLr225xdOPED7KYhHFSEVuDeEQ+G6BP3ipj3HuH04joB8vbR9mtWA+d?=
 =?us-ascii?Q?NnnicECeHSSTm7CWtMTMFBWe4Cf2FcEGZL+GU7W4vxqPnBOhvZgT4uqS3nF3?=
 =?us-ascii?Q?vjri2+okkCCIwxMiAioYKbw/3oDdTEaoZLGzBFVv9Y2VpbJ36jZTM2HfXk8N?=
 =?us-ascii?Q?ZOuwKliP3n7BdMYZG+LU3YmGOBcBn48CWvjYnOUUWRBwtJgSLrH0NWkf7EKx?=
 =?us-ascii?Q?pcjv6O4yR+w4DIuQDEXaMTuJa4kyiVcpJ0g2v5nTNqzBWHae5cU4otEubdAE?=
 =?us-ascii?Q?ULOwmGWR7tuhNFdMQutsDIGipfuB5QZrSmIHp0ttLKaf4cCLhauASm9Z78rk?=
 =?us-ascii?Q?oLru2NOAcn10eh75MFGmoLmibUCdIdB31B4eFaa0L2uyvLL02O17vj8OqYxU?=
 =?us-ascii?Q?GC/Offt5q/3qZ0cP5vk9QmoPheYlwgMYZChT0aWBQZIdj7GDgVo/Yr7X4Niq?=
 =?us-ascii?Q?pmBfILPCYoKsmglNbeqNgSHPpzAim4wnz/vXvOA2jkWiHwsL2DJeBfJu5TuQ?=
 =?us-ascii?Q?ZgmBA+0IwbiALn3/TaXa3YUDp3RPTYgg7erwP7Q/WPxXa070ziQ6Vzg8AAgf?=
 =?us-ascii?Q?3pwgpdGGj3L8xAp++Thnp3FMdPB0jYzy6FjtyjfvnrSMQ277u/B7lh2Ni44X?=
 =?us-ascii?Q?j3xz+pRZl4ugebwm7IJrFa/z6JznAZpxotTfigyH7VKwdTb9Fa6Bu6zi3MFs?=
 =?us-ascii?Q?9+aXBzQnIe0a5IhQRTTWZaPXtvPnTuFsGgTMM0e2smp5QO8qc1ryOkgoi/bP?=
 =?us-ascii?Q?H13ymmYFp1TionRoIBo9VJbsxvbszbFoY8FgLQ8nFmgMD9dILeGJKz62Upmp?=
 =?us-ascii?Q?NkGHFVZW9Ds+vHEXxjGZg3qP1meu867oVmdMawiMEn11g5V7UwiZ3LTUq991?=
 =?us-ascii?Q?j5vZEZPlXvwCPkZAzGhH8xRC1cJ3d/m0STp+tfLABGXskA5UVq/94q7YqC6V?=
 =?us-ascii?Q?0E2b6yezlvbd5VCm+SRenDpX/doklZCYLFzEDLk+jGWpkDwBws3MkKAt7AYd?=
 =?us-ascii?Q?EVyntyHwIexHiqFGIJh7M6Zs9Qb0achm8bGn2fYGpAZzd/JVKTJY+SiAiAJ6?=
 =?us-ascii?Q?Vwmq7qD3HdCxMkZRAYKLOeUgmShLx7CTFNq4Bj/bns7nfPT5wo0thzroMLzw?=
 =?us-ascii?Q?Ke+jNXxtJ/QsYRRPXGI4k0BOBbkrcVublDSD8QMvhYC4NJ28uvDfFzeqTb3D?=
 =?us-ascii?Q?5x2xj+FYEY6RbyxAIcVRxbGP25XNU3Ne5qLcDksq1TanrhqTULkYlnJBgK4h?=
 =?us-ascii?Q?MkksZQ=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93b8d60c-345b-4e5a-d7b9-08d9f0f3862b
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4166.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2022 02:24:57.0718
 (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: ULZcByx0OTPLPEEALODiJjyXfTFi5zm7Cx6M+43PB8OA+uv2hixatA1ExFBzD+2kCunzzp9/rkvYGlhNud4+CCMZmU6XRnO1rJUONZqC+3k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1341
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10259 signatures=675924
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 adultscore=0
 mlxlogscore=999 mlxscore=0 suspectscore=0 spamscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202160010
X-Proofpoint-GUID: gdcUmTJBQhVmv_R1uRTxNOJKYxHInSPY
X-Proofpoint-ORIG-GUID: gdcUmTJBQhVmv_R1uRTxNOJKYxHInSPY
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

Hi Al,

Al Viro <viro@zeniv.linux.org.uk> writes:
> On Wed, Feb 09, 2022 at 03:14:03PM -0800, Stephen Brennan wrote:
>
>> +static void sweep_negative(struct dentry *dentry)
>> +{
>> +	struct dentry *parent;
>> +
>> +	rcu_read_lock();
>> +	parent = lock_parent(dentry);
>> +	if (!parent) {
>> +		rcu_read_unlock();
>> +		return;
>> +	}
>> +
>> +	/*
>> +	 * If we did not hold a reference to dentry (as in the case of dput),
>> +	 * and dentry->d_lock was dropped in lock_parent(), then we could now be
>> +	 * holding onto a dead dentry. Be careful to check d_count and unlock
>> +	 * before dropping RCU lock, otherwise we could corrupt freed memory.
>> +	 */
>> +	if (!d_count(dentry) && d_is_negative(dentry) &&
>> +		!d_is_tail_negative(dentry)) {
>> +		dentry->d_flags |= DCACHE_TAIL_NEGATIVE;
>> +		list_move_tail(&dentry->d_child, &parent->d_subdirs);
>> +	}
>> +
>> +	spin_unlock(&parent->d_lock);
>> +	spin_unlock(&dentry->d_lock);
>> +	rcu_read_unlock();
>> +}
>
> 	I'm not sure if it came up the last time you'd posted this series
> (and I apologize if it had and I forgot the explanation), but... consider
> the comment in dentry_unlist().  What's to prevent the race described there
> making d_walk() skip a part of tree, by replacing the "lseek moving cursor
> in just the wrong moment" with "dput moving the negative dentry right next
> to the one being killed to the tail of the list"?

This did not come up previously, so thanks for pointing this out.

>
> 	The race in question:
> d_walk() is leaving a subdirectory.  We are here:
>         rcu_read_lock();
> ascend:
>         if (this_parent != parent) {
>
> It isn't - we are not back to the root of tree being walked.
> At this point this_parent is the directory we'd just finished looking into.
>
>                 struct dentry *child = this_parent;
>                 this_parent = child->d_parent;
>
> ... and now child points to it, and this_parent points to its parent.
>
>                 spin_unlock(&child->d_lock);
>
> No locks held.  Another CPU gets through successful rmdir().  child gets
> unhashed and dropped.  It's off the ->d_subdirs of this_parent; its
> ->d_child.next is still pointing where it used to, and whatever it points
> to won't be physically freed until rcu_read_unlock().
>
> Moreover, in the meanwhile this next sibling (negative, pinned) got dput().
> And had been moved to the tail of the this_parent->d_subdirs.  Since
> its ->d_child.prev does *NOT* point to child (which is off-list, about to
> be freed shortly, etc.), child->d_dchild.next is not modified - it still
> points to that (now moved) sibling.

It seems to me that, if we had taken a reference on child by
incrementing the reference count prior to unlocking it, then
dentry_unlist could never have been called, since we would never have
made it into __dentry_kill. child would still be on the list, and any
cursor (or sweep_negative) list updates would now be reflected in
child->d_child.next. But dput is definitely not safe while holding a
lock on a parent dentry (even more so now thanks to my patch), so that
is out of the question.

Would dput_to_list be an appropriate solution to that issue? We can
maintain a dispose list in d_walk and then for any dput which really
drops the refcount to 0, we can handle them after d_walk is done. It
shouldn't be that many dentries anyway.

>
>                 spin_lock(&this_parent->d_lock);
> Got it.
>
>                 /* might go back up the wrong parent if we have had a rename. */
>                 if (need_seqretry(&rename_lock, seq))
>                         goto rename_retry;
>
> Nope, hadn't happened.
>
>                 /* go into the first sibling still alive */
>                 do {
>                         next = child->d_child.next;
> ... and this is the moved sibling, now in the end of the ->d_subdirs.
>
>                         if (next == &this_parent->d_subdirs)
>                                 goto ascend;
>
> No, it is not - it's the last element of the list, not its anchor.
>
>                         child = list_entry(next, struct dentry, d_child);
>
> Our moved negative dentry.
>
>                 } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
>
> Not killed, that one.
>                 rcu_read_unlock();
>                 goto resume;
>
> ... and since that sucker has no children, we proceed to look at it,
> ascend and now we are at the end of this_parent->d_subdirs.  And we
> ascend out of it, having entirely skipped all branches that used to
> be between the rmdir victim and the end of the parent's ->d_subdirs.
>
> What am I missing here?  Unlike the trick we used with cursors (see
> dentry_unlist()) we can't predict who won't get moved in this case...

I don't think you're missing anything, unfortunately. Maybe if my above
idea pans out, we could prevent this, but I suppose without that,
reordering dentries among the subdirs list, and d_walk, are opposing
features. The cursor trick is neat but not applicable here.

>
> Note that treating "child is has DCACHE_DENTRY_KILLED" same as we do
> for rename_lock mismatches would not work unless you grab the spinlock
> component of rename_lock every time dentry becomes positive.  Which
> is obviously not feasible (it's a system-wide lock and cacheline
> pingpong alone would hurt us very badly, not to mention the contention
> issues due to the frequency of grabbing it going up by several orders
> of magnitude).

You won't catch me advocating for a global lock like that :P

I'm going to keep looking into this, since some of our high-uptime
customer machines have steady workloads which just keep churning out
negative dentries, and they tend to be in a particular subdirectory. If
the machine has oodles of free memory then we just let them create
dentries like candy until something eventually topples over, and it
tends to be something like this.

Thanks,
Stephen