Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp720292ybg; Sun, 26 Jul 2020 19:43:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmFS1u2JVtyEo8fO8EAZLzf3HGoA29FGMh9kritgBzoCRDPg5R9ADv3T3VsHcA0eMF63PD X-Received: by 2002:a17:906:f298:: with SMTP id gu24mr18839190ejb.302.1595817833234; Sun, 26 Jul 2020 19:43:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595817833; cv=none; d=google.com; s=arc-20160816; b=a6s4mOcW85o+h8/U6uv/M9/4sa3f/ViC90ouXE1tfsYthgX5yk7Hl1y+FLtQNQGOqQ r4+dyllbSt5Ojl1+E86yojRsdewwNcTG3rpFc3R2GemN2sc/zehTqkGnz8bpg5USwSw1 +E+T/wC3IcTPfRapRP30nI9HXeAl9qgnWFsrH0ghM8dOffP7xn9pOHacoEC8rGIBar1g +MxvJTf7SsvhtYev8XThMr1hTmouLHm6SoesjbKlUCQiXYxs8L08ujNmWwKsdGjfcWUd lo0O9s4OF4y1RNfzpKOA1YNWHTYqgKWiea4mdFKUcDAm+Db0jZ/XTSgKk/12XgubcyOE +n+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=L1m0eCQ/Xr0B6WMM8L82kxvbYoy6O069ntOBtgrYL2Y=; b=EwPrGzFBbeupyUKFqZU0Nyn36p6clN3AUKOQ0n/SARoZG2dUI1LVcHyP8ZhpNe/iX7 m5LbVXKs2Z+G527tI2e56pKydOtgpD6lyQb42KJD8iKnpXmbLbXZ2gmhnrRYsZA7iqmD GKKWZpkDeAHvD6PJl6lk/ay2HfsUq/+UZhTUbk2j+1NdKZ0KOdbt/loyHCCcNJ00XYRJ tv2q8INQFjzwhSogy5Cx3qplVMC3d55uyrU0h+nQlV9q5HuGlwUr4wSJi8N5fxb60wLx UaLrec7jN1nljmMaNmYZCPbqULJ1igZ6ltQY1x95+NqW9BSPXRECAX61MfNO7g+4D2fG NavA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si3701835ejf.619.2020.07.26.19.43.31; Sun, 26 Jul 2020 19:43:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727856AbgG0Clz (ORCPT + 99 others); Sun, 26 Jul 2020 22:41:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726044AbgG0Clz (ORCPT ); Sun, 26 Jul 2020 22:41:55 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46BEEC0619D2; Sun, 26 Jul 2020 19:41:55 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jzt5J-003N6N-Ej; Mon, 27 Jul 2020 02:41:49 +0000 Date: Mon, 27 Jul 2020 03:41:49 +0100 From: Al Viro To: Christoph Hellwig Cc: Lukasz Stelmach , Marek Szyprowski , linux-kernel@vger.kernel.org, "H. Peter Anvin" , Song Liu , Linus Torvalds , linux-raid@vger.kernel.org, linux-fsdevel@vger.kernel.org, Bartlomiej Zolnierkiewicz , Shaohua Li Subject: Re: [PATCH 16/23] initramfs: simplify clean_rootfs Message-ID: <20200727024149.GB795125@ZenIV.linux.org.uk> References: <20200714190427.4332-1-hch@lst.de> <20200714190427.4332-17-hch@lst.de> <7f37802c-d8d9-18cd-7394-df51fa785988@samsung.com> <20200718100035.GA8856@lst.de> <20200723092200.GA19922@lst.de> <20200723142734.GA11080@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200723142734.GA11080@lst.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 23, 2020 at 04:27:34PM +0200, Christoph Hellwig wrote: > On Thu, Jul 23, 2020 at 04:25:34PM +0200, Lukasz Stelmach wrote: > > >> Can you comment out the call to d_genocide? It seems like for your > > >> the fact that clean_rootfs didn't actually clean up was a feature and > > >> not a bug. > > >> > > >> I guess the old, pre-2008 code also wouldn't have worked for you in > > >> that case. > > > > > > Did you get a chance to try this? > > > > Indeed, commenting out d_genocide() helps. > > So given that people have relied on at least the basic device nodes > like /dev/console to not go away since 2008, I wonder if we should just > remove clean_rootfs entirely > > Linus, Al? First of all, d_genocide() is simply wrong here from VFS point of view. _IF_ you want recursive removal, you need simple_recursive_remove(path.dentry, NULL). And it's a userland-visible change of behaviour. As for removal of clean_rootfs()... FWIW, the odds of an image that would eventually fail accidentally getting past the signature mismatch check are fairly low. I've no idea what scenario the author of that thing used to have; that would be Shaohua Li . Cc'd...