From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755858AbZKINLd (ORCPT ); Mon, 9 Nov 2009 08:11:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755827AbZKINLd (ORCPT ); Mon, 9 Nov 2009 08:11:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58051 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754664AbZKINLc (ORCPT ); Mon, 9 Nov 2009 08:11:32 -0500 Date: Mon, 9 Nov 2009 08:11:31 -0500 From: Jeff Layton To: ebiederm@xmission.com (Eric W. Biederman) Cc: Jamie Lokier , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, adobriyan@gmail.com, viro@ZenIV.linux.org.uk Subject: Re: [PATCH] proc: revalidate dentry returned by proc_pid_follow_link Message-ID: <20091109081131.7ebfde76@tlielax.poochiereds.net> In-Reply-To: References: <1257513594-31071-1-git-send-email-jlayton@redhat.com> <20091106203601.GD27751@shareable.org> <20091106160612.4cd05e76@tlielax.poochiereds.net> <20091108201237.79af5cac@tupile.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 08 Nov 2009 19:30:55 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote: > Jeff Layton writes: > > >> Hmm. Looking at the code I get the impression that a file bind mount > >> will have exactly the same problem. > >> > >> Can you confirm. > >> > >> If file bind mounts also have this problem a bugfix to to just > >> proc seems questionable. > >> > > > > I'm not sure I understand what you mean by "file bind mount". Is that > > something like mounting with "-o loop" ? > > # cd /tmp > # echo foo > foo > # echo bar > bar > # mount --bind foo bar > # cat bar > foo > # > > > I'm not at all opposed to fixing this in a more broad fashion, but as > > best I can tell, the only place that LAST_BIND is used is in procfs. > > proc does appear to be the only user of LAST_BIND. With a file bind > mount we can get to the same ok: label without a revalidate. The > difference is that we came from __follow_mount instead of follow_link. > > At least that is how I read the code. > Thanks. Yes, you're correct. That scenario does seem to have a similar problem. I'm not quite sure yet how to fix it there yet. It's easy enough to force a d_revalidate at a higher level. The tricky bit is what to do when that returns 0 or an error. When I spoke to Al about this, he suggested returning -ESTALE from the follow_link routine if that occurs. That would force LOOKUP_REVAL to get set and cause the whole chain of dentries to be revalidated back up to the root (if necessary). That's a little more difficult in the file bind mount case as I don't see where it calls link_path_walk at all and hence can't really deal with an ESTALE on a reval properly. I'll need to study this code some more to see what the right fix is. If you (or anyone) has a suggestion, I'd love to hear it. -- Jeff Layton From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH] proc: revalidate dentry returned by proc_pid_follow_link Date: Mon, 9 Nov 2009 08:11:31 -0500 Message-ID: <20091109081131.7ebfde76@tlielax.poochiereds.net> References: <1257513594-31071-1-git-send-email-jlayton@redhat.com> <20091106203601.GD27751@shareable.org> <20091106160612.4cd05e76@tlielax.poochiereds.net> <20091108201237.79af5cac@tupile.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org To: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Return-path: In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Sun, 08 Nov 2009 19:30:55 -0800 ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) wrote: > Jeff Layton writes: > > >> Hmm. Looking at the code I get the impression that a file bind mount > >> will have exactly the same problem. > >> > >> Can you confirm. > >> > >> If file bind mounts also have this problem a bugfix to to just > >> proc seems questionable. > >> > > > > I'm not sure I understand what you mean by "file bind mount". Is that > > something like mounting with "-o loop" ? > > # cd /tmp > # echo foo > foo > # echo bar > bar > # mount --bind foo bar > # cat bar > foo > # > > > I'm not at all opposed to fixing this in a more broad fashion, but as > > best I can tell, the only place that LAST_BIND is used is in procfs. > > proc does appear to be the only user of LAST_BIND. With a file bind > mount we can get to the same ok: label without a revalidate. The > difference is that we came from __follow_mount instead of follow_link. > > At least that is how I read the code. > Thanks. Yes, you're correct. That scenario does seem to have a similar problem. I'm not quite sure yet how to fix it there yet. It's easy enough to force a d_revalidate at a higher level. The tricky bit is what to do when that returns 0 or an error. When I spoke to Al about this, he suggested returning -ESTALE from the follow_link routine if that occurs. That would force LOOKUP_REVAL to get set and cause the whole chain of dentries to be revalidated back up to the root (if necessary). That's a little more difficult in the file bind mount case as I don't see where it calls link_path_walk at all and hence can't really deal with an ESTALE on a reval properly. I'll need to study this code some more to see what the right fix is. If you (or anyone) has a suggestion, I'd love to hear it. -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH] proc: revalidate dentry returned by proc_pid_follow_link Date: Mon, 9 Nov 2009 08:11:31 -0500 Message-ID: <20091109081131.7ebfde76@tlielax.poochiereds.net> References: <1257513594-31071-1-git-send-email-jlayton@redhat.com> <20091106203601.GD27751@shareable.org> <20091106160612.4cd05e76@tlielax.poochiereds.net> <20091108201237.79af5cac@tupile.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Jamie Lokier , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, adobriyan@gmail.com, viro@ZenIV.linux.org.uk To: ebiederm@xmission.com (Eric W. Biederman) Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58051 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754664AbZKINLc (ORCPT ); Mon, 9 Nov 2009 08:11:32 -0500 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Sun, 08 Nov 2009 19:30:55 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote: > Jeff Layton writes: > > >> Hmm. Looking at the code I get the impression that a file bind mount > >> will have exactly the same problem. > >> > >> Can you confirm. > >> > >> If file bind mounts also have this problem a bugfix to to just > >> proc seems questionable. > >> > > > > I'm not sure I understand what you mean by "file bind mount". Is that > > something like mounting with "-o loop" ? > > # cd /tmp > # echo foo > foo > # echo bar > bar > # mount --bind foo bar > # cat bar > foo > # > > > I'm not at all opposed to fixing this in a more broad fashion, but as > > best I can tell, the only place that LAST_BIND is used is in procfs. > > proc does appear to be the only user of LAST_BIND. With a file bind > mount we can get to the same ok: label without a revalidate. The > difference is that we came from __follow_mount instead of follow_link. > > At least that is how I read the code. > Thanks. Yes, you're correct. That scenario does seem to have a similar problem. I'm not quite sure yet how to fix it there yet. It's easy enough to force a d_revalidate at a higher level. The tricky bit is what to do when that returns 0 or an error. When I spoke to Al about this, he suggested returning -ESTALE from the follow_link routine if that occurs. That would force LOOKUP_REVAL to get set and cause the whole chain of dentries to be revalidated back up to the root (if necessary). That's a little more difficult in the file bind mount case as I don't see where it calls link_path_walk at all and hence can't really deal with an ESTALE on a reval properly. I'll need to study this code some more to see what the right fix is. If you (or anyone) has a suggestion, I'd love to hear it. -- Jeff Layton