Date: Sun, 05 Jan 2003 15:02:18 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Pawel Jakub Dawidek <P.Dawidek@prioris.mini.pw.edu.pl> Cc: freebsd-hackers@freebsd.org Subject: Re: Caching [sugestion]. Message-ID: <3E18B97A.32ABAE7@mindspring.com> References: <20030105215024.GB99855@prioris.mini.pw.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > I just wondering... > Now we got problems with caching, and problems could be seriuos in -CURRENT > when we want to use some TrustedBSD features, etc. > Sometimes there is NEED to get filename (or full path) from vnode to log > selected behaviour or many other useful things (for example property > working __getcwd()). > For now we could get pathname from cache, but not always it is possible. This is a much larger problem than you make it out to be. The problem is that you are effectively asking for a 1:1 correspondance between a path to an object and a vnode, so that it is always possible to reverse-convert an open file to a path. This is not a problem that can be solved in a cache, because vnode's are indexed through a file system by in-core inodes off a flat address space (via the ihash). The only reasonable way this can be handled completely would be by divorcing vmobject_t's from vnodes, and then changing the file system structure to have a physical on-disk reference object for each directory reference to an inode (i.e. make hard links into actual things, instead of making them merely be inode number references. In effect, you have to avoid creating an alias vmobject_t in the process of obtaining a second vnode reference to match a second in-core inode reference, which is needed to differentiate differences in physical path on the disk. This is very easy to prove to yourself experimentally, in the context of the existing cache, whose life you want to prolong by damaging the LRU algorithm -- and thereby locality of reference. The way to do this is to create a file in a directory, make a hard link to it in some other directory, reboot, and then run two programs in different terminal windows/on different virtual console screens: 1) Open the file 2) wait for a key press 3) Print the path to the file, as obtained from the cache By doing this as 1, 2, 1', 2', 3, 3', you will see that the first program will come up with the wrong path. Because access controls are enforced by means of inherited rights, you have just made ambiguous the path used to achieve the per process file table entery that referes to the vnode that referse to the in-core inode for the file in question: ideally, you would get the path-to-open that was used by both programs, rather than the one that was first or the one that was most recent (depending on cache state... the reboot was added to the process to make the diagnostic both predictable and repeatable, and to avoid the population of the cache out of order that occurs during the create). FWIW: As a general security princple, in addition, caching is harmful. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E18B97A.32ABAE7>