Re: DazukoFS
[email protected] Tue, 27 Feb 2007 12:48:20 +0000
| Newsgroups | gmane.linux.dazuko.devel |
|---|---|
| Message-ID | <OFFA5293B0.28C7B1D2-ON8025728F.004603DB-8025728F.0046601A@sophos.com> |
John Ogness <[email protected]> wrote on 23/02/2007 21:28:03: > [email protected] wrote: > >>Well, yes, it does work. However, it uses the d_path() function. One of > >>the advantages of DazukoFS is that we can get away from the d_path() > >>function. The problem with this function is: > >> > >>4. __d_path() would allow us to get around #2, but it is not re-entrant > >>safe and it is not exported to modules > > > > What exactly do you mean with re-entrant safe? > > d_path() is a wrapper for __d_path() that does two things: It uses the > root mount of the current process and it calls __d_path() while holding > the necessary lock "dcache_lock". > > Unfortunately "dcache_lock" is a static variable within fs/dcache.c, > which means no other kernel code outside of fs/dcache.c can access this > lock. This means that a kernel module cannot safely call __d_path() (on > SMP machines) and must use the "restricted" d_path() function. > > Note: I just noticed that 2.6.20 now exports dcache_lock. Interesting... Yes, and for earlier version you could still get it from the System.map file which would be equivalent to syscall_table stuff. Then any re-implementation of __d_path can be safe. Btw, I just tried it on FreeBSD 6.2 and I seem to be missing /usr/src/sbin/mount_nullfs directory. Any ideas on where can I get that? Tvrtko Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20.