From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Subject: Re: [d_path 0/7] Fixes to d_path: Respin Date: Fri, 20 Apr 2007 13:45:09 +0200 Message-ID: <200704201345.09858.agruen@suse.de> References: <20070412090809.917795000@suse.de> <20070419232303.300441585@schurl.suse.de> <20070420103008.15f37eec@the-village.bc.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: jjohansen@suse.de, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, chrisw@sous-sol.org, Andrew Morton To: Alan Cox Return-path: Received: from ns.suse.de ([195.135.220.2]:43313 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993013AbXDTLpA (ORCPT ); Fri, 20 Apr 2007 07:45:00 -0400 In-Reply-To: <20070420103008.15f37eec@the-village.bc.nu> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Friday 20 April 2007 11:30, Alan Cox wrote: > > As far as I can see, glibc internally looks at /proc/mounts (or else > > mtab) to find out where tmpfs is mounted for opening files there, and to > > look up filesystem information for statfs(), while accessing that path, > > too. Fstatfs() also looks into the same files, but it only matches by > > filesystem type, so this is only a very unreliable heuristic, anyway. > > > > So judging from that, glibc users should be fine. > > So glibc does use it and you will change behaviour Not for statfs(), shm_open(), and sem_open(). Possibly for fstatfs(): fstatfs() has no way of looking up mount points per path name in /proc/mounts, and so it resorts to mapping from the numeric statfs->f_type to the filesystem name (e.g., "ext3"), looks up the first mount point with that name, and sets the statfs->f_flag flags based on that entry. This field may change from one arbitrary value to another. Andreas