1. 20 4月, 2008 2 次提交
  2. 20 3月, 2008 3 次提交
  3. 06 3月, 2008 1 次提交
    • E
      NFS: use new LSM interfaces to explicitly set mount options · f9c3a380
      Eric Paris 提交于
      NFS and SELinux worked together previously because SELinux had NFS
      specific knowledge built in.  This design was approved by both groups
      back in 2004 but the recent NFS changes to use nfs_parsed_mount_data and
      the usage of nfs_clone_mount_data showed this to be a poor fragile
      solution.  This patch fixes the NFS functionality regression by making
      use of the new LSM interfaces to allow an FS to explicitly set its own
      mount options.
      
      The explicit setting of mount options is done in the nfs get_sb
      functions which are called before the generic vfs hooks try to set mount
      options for filesystems which use text mount data.
      
      This does not currently support NFSv4 as that functionality did not
      exist in previous kernels and thus there is no regression.  I will be
      adding the needed code, which I believe to be the exact same as the v3
      code, in nfs4_get_sb for 2.6.26.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      f9c3a380
  4. 14 2月, 2008 1 次提交
  5. 30 1月, 2008 17 次提交
  6. 03 1月, 2008 1 次提交
  7. 12 12月, 2007 1 次提交
  8. 07 12月, 2007 1 次提交
  9. 27 11月, 2007 1 次提交
    • R
      NFS: mount failure causes bad page state · f16c9603
      Russell King 提交于
      While testing a kernel based upon ecd744ee
      (with wrong boot arguments), I got the following bad page state entry while
      NFS was trying to mount it's rootfs:
      
      IP-Config: Complete:
            device=eth0, addr=192.168.1.101, mask=255.255.255.0, gw=255.255.255.255,
           host=192.168.1.101, domain=, nis-domain=(none),
           bootserver=192.168.1.100, rootserver=192.168.1.100, rootpath=
      Looking up port of RPC 100003/2 on 192.168.1.100
      rpcbind: server 192.168.1.100 not responding, timed out
      Root-NFS: Unable to get nfsd port number from server, using default
      Looking up port of RPC 100005/1 on 192.168.1.100
      rpcbind: server 192.168.1.100 not responding, timed out
      Root-NFS: Unable to get mountd port number from server, using default
      mount: server 192.168.1.100 not responding, timed out
      Root-NFS: Server returned error -5 while mounting /nfs/rootfs/
      VFS: Unable to mount root fs via NFS, trying floppy.
      Bad page state in process 'swapper'
      page:c02b1260 flags:0x00000400 mapping:00000000 mapcount:0 count:0
      Trying to fix it up, but a reboot is needed
      Backtrace:
      [<c0023e34>] (dump_stack+0x0/0x14) from [<c0062570>] (bad_page+0x70/0xac)
      [<c0062500>] (bad_page+0x0/0xac) from [<c0064914>] (free_hot_cold_page+0x80/0x178)
      [<c0064894>] (free_hot_cold_page+0x0/0x178) from [<c0064a74>] (free_hot_page+0x14/0x18)
      [<c0064a60>] (free_hot_page+0x0/0x18) from [<c0067078>] (put_page+0xf8/0x154)
      [<c0066f80>] (put_page+0x0/0x154) from [<c007dbc8>] (kfree+0xc8/0xd0)
      [<c007db00>] (kfree+0x0/0xd0) from [<c00cbb54>] (nfs_get_sb+0x230/0x710)
      [<c00cb924>] (nfs_get_sb+0x0/0x710) from [<c0084334>] (vfs_kern_mount+0x58/0xac)[<c00842dc>] (vfs_kern_mount+0x0/0xac) from [<c00843c0>] (do_kern_mount+0x38/0xf4)
      [<c0084388>] (do_kern_mount+0x0/0xf4) from [<c0099c7c>] (do_mount+0x1e8/0x614)
      ...
      
      This seems to be caused by use of an uninitialised structure due to NULL
      options being passed to nfs_validate_mount_data().  Ensure that the
      parsed mount data is always initialised.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
           (Trond: added fix for the same bug in nfs4_validate_mount_data()).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f16c9603
  10. 18 11月, 2007 1 次提交
    • N
      kernel BUG at fs/nfs/namespace.c:108! - can be triggered by bad server · 4c1fe2f7
      Neil Brown 提交于
      
      Hi Trond,
      
      I have discovered that the BUG_ON in nfs_follow_mountpoint:
      
      	BUG_ON(IS_ROOT(dentry));
      
      can be triggered by a misbehaving server.
      
      What happens is the client does a lookup and discoveres that the named
      directory has a different fsid, so it initiates a mount.
      It then performs a GETATTR on the mounted directory and gets a
      different fsid again (due to a bug in the NFS server).
      This causes nfs_follow_mountpoint to be called on the newly mounted
      root, which triggers the BUG_ON.
      
      To duplicate this, have a directory which contains some mountpoints,
      and export that directory with the "crossmnt" flag using nfs-utils
      1.1.1 (or 1.1.0 I think)
      
      The GETATTR on the root of the mounted filesystem will return the
      information for the top exportpoint, while a lookup will return the
      correct information.  This difference causes the NFS client to BUG.
      
      I think the best way to fix this is to trap this possibility early, so
      just before completing the mount in the NFS client, check that it isn't
      going to use nfs_mountpoint_inode_operations.
      As long as i_op will never change once set (is that true?), this
      should be adequately safe.
      
      The following patch shows a possible approach, and it works for me.
      i.e. when the NFS server is misbehaving, I get ESTALE on those
      mountpoints, while when the NFS server is working correctly, I get
      correct behaviour on the client.
      
      NeilBrown
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4c1fe2f7
  11. 10 10月, 2007 11 次提交