From patchwork Mon Oct 12 13:50:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 7375311 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id AF411BEEA4 for ; Mon, 12 Oct 2015 13:48:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B46DC20411 for ; Mon, 12 Oct 2015 13:48:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 59D25205E7 for ; Mon, 12 Oct 2015 13:48:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752572AbbJLNse (ORCPT ); Mon, 12 Oct 2015 09:48:34 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:33224 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752628AbbJLNsd (ORCPT ); Mon, 12 Oct 2015 09:48:33 -0400 Received: by wicge5 with SMTP id ge5so18473660wic.0 for ; Mon, 12 Oct 2015 06:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MulcrNVrvRq91kMb3MyijB0Xk84tWAPeJGn2fasI36U=; b=cYk5c2WeyZeBs43ZieEr+K04DFwPqpgGeIRZRanV0p2aOWmFFUCwYExqQtqnn46Bm3 FqAYyDxqc1TzZZV4pID9Tk7bpQ8QxdcxtZuTVokp7Y7U4j/ReUtaQ7hFeB5w6wDCQOId 2RA1S1G8Pa5rFMNXpUhzaB41Tvj1TYdIL2HHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=MulcrNVrvRq91kMb3MyijB0Xk84tWAPeJGn2fasI36U=; b=kZBYvTPEewKsqAstYo68RQpFCtNFiVyQWuo0IYgXp+0Nas0iaQ9MtuyafTxoHhXO/W Nd5Veit5/BFPp1LnB7Sakat3AzNu7xqldlFAxZsoA7vHKBjaaiOF+ZiUBiEGHz3rh0hW NWkLDbPEgEAMCjpOPm9If7oKCZ8tJmir+roRhbqaDDXznqj3WaYmJu7WWYPUq7tRfu/K 9nRL4km3ZMN9Km3mfui9ouPtV1l8pqRXrdsSyog/u+Z+E3aoChzfIwvrkwEF8bcBUPoY llQmjNtwlGmEgVurzIXn+Yb3aSF3SPfWNCM6g26ukVXVXJRIRa512mApYFus2s+lJPjH +NNA== X-Gm-Message-State: ALoCoQklolYr/PDtirm6aT2NUhTWP4rYQfcujHlMKE+jYkwib0AnuNLcjdBMUUQVs/mNE9JddWWM X-Received: by 10.194.202.137 with SMTP id ki9mr29128552wjc.16.1444657711637; Mon, 12 Oct 2015 06:48:31 -0700 (PDT) Received: from tucsk (pool-dsl-22-000b.externet.hu. [217.173.34.11]) by smtp.gmail.com with ESMTPSA id pl7sm10978364wic.4.2015.10.12.06.48.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Oct 2015 06:48:30 -0700 (PDT) Date: Mon, 12 Oct 2015 15:50:05 +0200 From: Miklos Szeredi To: Alban Crequy Cc: David Howells , sds@tycho.nsa.gov, Alexander Viro , linux-fsdevel@vger.kernel.org, LSM , linux-unionfs@vger.kernel.org, "linux-kernel@vger.kernel.org" , Iago =?utf-8?B?TMOzcGV6?= Galeiras Subject: Re: overlayfs: regression bug from 4bacc9c9 (Make f_path always point to the overlay and f_inode to the underlay) Message-ID: <20151012135005.GA10697@tucsk> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Oct 07, 2015 at 02:23:23PM +0200, Alban Crequy wrote: > Hi, > > I'm reporting an issue in overlay fs that was introduced in v4.2 (it > worked on v4.1): when overlay fs is mounted inside a overlay fs, I get > a "no such device or address" error (ENXIO) during open(). After > adding some debug printks, I found that the ENXIO comes from > fs/inode.c:no_open(). > > The bug was initially reported on: > https://github.com/coreos/rkt/issues/1537 > > The following commands can reproduce the issue: Thanks for the excellent report. See below for a fix. Please let me know if you see any issues. Thanks, Miklos Tested-by: Alban Crequy --- Subject: ovl: fix open in stacked overlay From: Miklos Szeredi If two overlayfs filesystems are stacked on top of each other, then we need recursion in ovl_d_select_inode(). I guess d_backing_inode() is supposed to do that. But currently it doesn't and that functionality is open coded in vfs_open(). This is now copied into ovl_d_select_inode() to fix this regression. Reported-by: Alban Crequy Signed-off-by: Miklos Szeredi Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay...") Cc: David Howells Cc: # v4.2+ --- fs/overlayfs/inode.c | 3 +++ 1 file changed, 3 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -363,6 +363,9 @@ struct inode *ovl_d_select_inode(struct ovl_path_upper(dentry, &realpath); } + if (realpath.dentry->d_flags & DCACHE_OP_SELECT_INODE) + return realpath.dentry->d_op->d_select_inode(realpath.dentry, file_flags); + return d_backing_inode(realpath.dentry); }