On Fri, Mar 20, 2015 at 5:53 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Fri, Mar 20, 2015 at 04:25:58PM +0000, Al Viro wrote: >> On Fri, Mar 20, 2015 at 05:01:23PM +0100, Miklos Szeredi wrote: >> >> > But it does take care of the majority of f_path users that actually want the >> > covering path. >> >> Bloody bad idea, IMO. I have no objections against adding _helpers_ from >> that patch (seq_file_path(), etc.), but I really don't like adding that >> second struct path there. And it still doesn't fix the issue with >> LSM, etc., so we'll _still_ need to fix it sane way. > > Obviously getting rid of the extra path would be good. But we still have lots > of f_path.dentry in filesystems and we need to start with that. So we'd need the following helpers: file_path() - d_path() but gets file seq_file_path() - seq_path() but gets file f_covering_path() - other uses of ->f_path that don't want the backing filesystem's dentry file_dentry() - uses of f_path.dentry that want the backing filesystem's dentry file_mount() - uses of f_path.mnt Hopefully that would cover all f_path uses. I'd really not want to keep f_path with that name, because it would just breed new f_path.dentry uses in filesystems. Better no direct f_path references at all. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
