Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp403633yba; Wed, 3 Apr 2019 10:57:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2Drz4sV/VfOXpUkf2/0x86HLHI01mhdBFvyCGKeHN4ySJaw9Y2FsrWLlJ9UarQQ+dPuL9 X-Received: by 2002:a63:460a:: with SMTP id t10mr987216pga.354.1554314268102; Wed, 03 Apr 2019 10:57:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554314268; cv=none; d=google.com; s=arc-20160816; b=GXk2dj2yicMOdW8q/dXERSHOic625j9AVqaqRLgnDf49RLLgha9gzUNadjaECfyvCd 0APvqpuoAZzIxTR8XXiTbSB+sTTTfz2MuIJqSL/3wWJQudgEjPBe/gY/w9LFO+eUt/8e XOYIZl0GMJ1LABTYGUAixff0UkEhk+Rq3K9Ay42MOxsrxpW6ZxyR1FmggJ4kotPxMILX i7TCXmdVJa1H4cfcN8uF/nLFEO7MKO8m+4fOpVeRutmujuvp9QoGS08ksRmhst4/Rn65 DR4dDhc6fS7Yc0AxvU7y4gkaPJ67hpQfJ03HARJRTDcYYOFt4O+6QdtPbk5LGjmrBtnh RswA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature; bh=PxDq6sqsxX3UdiY2YPlqWIL/OxZS2aP7l6arbZ0e3zs=; b=ZqQN5hdT6My6oqUOiqxtvvPBuK9Upc7TcI3udvx7r+0aBOSfEjYw6F4bFnYJIcuQbV yBIOInb/4XzrxPWRHlCZiFzqLA3iqmWfB+diVdrhRC9XTAWJtJ8Yx3yUDLh2KbEgaAkH +vYuJdX58sr46lGTMZEJAUfdoLosMttUJrd6+xZ57lP0VzsHK9h1jhf0GYT9ZmTAVvVn klmAj6wL+cWbGtSezshJLTIQt6gRF8b+uwcXDCeZ487mVtBNSMBYYf2dZJQgZgcqBeJj cwCGiZPllyqXSfCqyoSqCG2VhagvfEiERVN5GCe2gZ/A3fRoDwd0BqTaLC9diwY2HlxL V6Gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=ECT6lpn3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u5si14949685pgl.36.2019.04.03.10.57.32; Wed, 03 Apr 2019 10:57:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=ECT6lpn3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726461AbfDCR43 (ORCPT + 99 others); Wed, 3 Apr 2019 13:56:29 -0400 Received: from a9-30.smtp-out.amazonses.com ([54.240.9.30]:48858 "EHLO a9-30.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726084AbfDCR43 (ORCPT ); Wed, 3 Apr 2019 13:56:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554314187; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=Wyd/86VQr4yB+T3sAKBmvWlFZRyqyhljETAB3MKNVBw=; b=ECT6lpn36hcc5RiE9hxy2iLqLJPNP+ceZdI1xVdCLGsleGlkdonBVCwBaMVznKj4 9CTvSAAFdKBjZ5hY26du2Zk6Bwpjfzk1DQnCiRgMlrd7d6F9fC1XJwzxF8Lb0VLl5iT ZVRQU9YU3p/X/L7Wsb55owNa6j6s7KblS1qdWtJ0= Date: Wed, 3 Apr 2019 17:56:27 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Al Viro cc: "Tobin C. Harding" , Andrew Morton , Roman Gushchin , Alexander Viro , Christoph Hellwig , Pekka Enberg , David Rientjes , Joonsoo Kim , Matthew Wilcox , Miklos Szeredi , Andreas Dilger , Waiman Long , Tycho Andersen , Theodore Ts'o , Andi Kleen , David Chinner , Nick Piggin , Rik van Riel , Hugh Dickins , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [RFC PATCH v2 14/14] dcache: Implement object migration In-Reply-To: <20190403170811.GR2217@ZenIV.linux.org.uk> Message-ID: <01000169e458534a-3c6a5d6f-3054-4c64-b5f9-7f46c811eeac-000000@email.amazonses.com> References: <20190403042127.18755-1-tobin@kernel.org> <20190403042127.18755-15-tobin@kernel.org> <20190403170811.GR2217@ZenIV.linux.org.uk> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2019.04.03-54.240.9.30 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Apr 2019, Al Viro wrote: > Let's do d_invalidate() on random dentries and hope they go away. > With convoluted and brittle logics for deciding which ones to > spare, which is actually wrong. This will pick mountpoints > and tear them out, to start with. > > NAKed-by: Al Viro > > And this is a NAK for the entire approach; if it has a positive refcount, > LEAVE IT ALONE. Period. Don't play this kind of games, they are wrong. > d_invalidate() is not something that can be done to an arbitrary dentry. Well could you help us figure out how to do it the right way? We (the MM guys) are having a hard time not being familiar with the filesystem stuff. This is an RFC and we want to know how to do this right.