Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755441Ab3JGDWf (ORCPT ); Sun, 6 Oct 2013 23:22:35 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:64711 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755100Ab3JGDWd (ORCPT ); Sun, 6 Oct 2013 23:22:33 -0400 MIME-Version: 1.0 In-Reply-To: <20130510102754.184cd90d@corrin.poochiereds.net> References: <20130510102754.184cd90d@corrin.poochiereds.net> Date: Sun, 6 Oct 2013 22:22:31 -0500 Message-ID: Subject: Re: Mount failure due to restricted access to a point along the mount path From: Shirish Pargaonkar To: Jeff Layton Cc: Miklos Szeredi , linux-cifs , Steve French , Kernel Mailing List , Suresh Jayaraman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2063 Lines: 54 So instead of breaking superblock sharing and fscache functionality with 2), it may be better off to explore 1). Will spend some time doing so. Regards, Shirish On Fri, May 10, 2013 at 9:27 AM, Jeff Layton wrote: > On Fri, 10 May 2013 16:13:30 +0200 > Miklos Szeredi wrote: > >> Hi, >> >> A while ago this was discussed: >> >> http://thread.gmane.org/gmane.linux.kernel.cifs/7779 >> >> This is essentially a regression introduced by the shared superblock >> changes in 3.0 and several SUSE customers are complaining about it. >> I've created a temporary fix which reverts 29 commits related to the >> shared superblock changes. It works, but it's obviously not a >> permanent fix, especially since we definitely don't want to diverge >> from mainline. >> >> Is this issue being worked on? Don't other distros have similar reports? >> >> Thanks, >> Miklos > > I don't know of anyone currently working on it. There are a couple of > possible approaches to fixing it, I think: > > 1) if the dentries to get down to the root of the mount don't already > exist, then attach some sort of "placeholder" inode that can be fleshed > out later if and when the dentry is accessed via other means. > > 2) do something like what NFS does (see commit 54ceac45). This becomes > a bit more complicated due to the fact that the server may not hand out > real inode numbers and we sometimes have to fake them up. > > #1 is probably simpler to implement, but I'll confess that I haven't > thought through all of the potential problems with it. > > -- > Jeff Layton > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/