Re: [PATCH 0/7] Permit filesystem local caching and NFS superblock sharing [try #13]

[Ian Kent <raven@themaw.net>]

On Fri, 2006-09-01 at 22:58 -0700, Andrew Morton wrote:
> > > 
> > > It doesn't appear to be related to selinux.

I have a festering suspicion, but no evidence yet, that this is not
always the case.

> > > 
> > > On a stock, mostly-up-to-date FC5 installation:
> > > 
> > > 	echo 0 > /selinux/enforce
> > > 	service autofs stop
> > > 	service nfs stop
> > > 	service nfs start
> > > 	service autofs start

I'm now setup my little system the same.

[root@raven selinux]# uname -a
Linux raven.themaw.net 2.6.18-rc5-mm1 #1 SMP Sat Sep 2 23:11:01 WST 2006
x86_64 x86_64 x86_64 GNU/Linux

[root@raven selinux]# rpm -q autofs
autofs-4.1.4-29

[root@raven selinux]# getenforce
Permissive

[root@raven selinux]# rpm -q selinux-policy
selinux-policy-2.3.7-2.fc5

> > > 
> > > 
> > > sony:/home/akpm> ls -l /net/bix/usr/src
> > > total 0
> > > 
> > > sony:/home/akpm> showmount -e bix
> > > Export list for bix:
> > > /           *
> > > /usr/src    *
> > > /mnt/export *

Almost the same.

[root@raven selinux]# showmount -e budgie
Export list for budgie:
/        *
/usr/src *

> > > 
> > > 
> > > The automounter will mount bix:/ on /net/bix.  But I am unable to get it to
> > > mount bix's /usr/src on /net/bix/usr/src.
> > 
> > Is it the same symptom as before or is it that bix:/usr/src is not also
> > being mounted?

[root@raven selinux]# lsmod|grep autofs
autofs4                40776  1

I guess you haven't got the autofs module loaded instead of autofs4 by
mistake.

[raven@raven ~]$ mount
/dev/hda5 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/hda6 on /home type ext3 (rw)
/dev/hda7 on /work type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid3463) on /net type autofs
(rw,fd=5,pgrp=3463,minproto=2,maxproto=4)

[raven@raven ~]$ ls /net/budgie
autofs  cdrom  export71  initrd          lib         opt   sbin  usr
vmlinuz.old
bin     dev    floppy    initrd.img      lost+found  proc  sys   var
boot    etc    home      initrd.img.old  mnt         root  tmp   vmlinuz
[raven@raven ~]$ mount
/dev/hda5 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/hda6 on /home type ext3 (rw)
/dev/hda7 on /work type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid3463) on /net type autofs
(rw,fd=5,pgrp=3463,minproto=2,maxproto=4)
budgie:/ on /net/budgie type nfs
(rw,nosuid,nodev,hard,intr,addr=10.49.97.33)
budgie:/usr/src on /net/budgie/usr/src type nfs
(rw,nosuid,nodev,hard,intr,addr=10.49.97.33)

So I wonder what the different is between the setups?

> 
> When this saga first started an `ls -l /net/bix' showed a corrupted dentry
> for /net/bix/usr.  It was determined that this was SELinux-related.  Fixes were
> made and that no longer occurs.
> 
> Now, treading on /net/bix/usr/src does not cause bix:/usr/src to be mounted
> at /net/bix/usr/src.  Without git-nfs that mount does occur.
> 
> The present behaviour is unchanged if /selinux/enforce is set to 0.
> 
> > > Without git-nfs applied, /net/bix/usr/src mounts as expected.
> > > 
> > > iirc, we decided this is related to the fs-cache infrastructure work which
> > > went into git-nfs.  I think David can reproduce this?

Can you reproduce this David?

> > 
> > I'll build the latest mm kernel and try to reproduce it.
> > >From memory I couldn't reproduce it last time I tried.
> > Is there anything I need to add to rc5-mm1 for this?
> 
> Nope.

I'm stumped.

Ian



-- 
VGER BF report: H 0.0277086
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/