1. 03 11月, 2010 2 次提交
    • J
      cifs: convert tlink_tree to a rbtree · b647c35f
      Jeff Layton 提交于
      Radix trees are ideal when you want to track a bunch of pointers and
      can't embed a tracking structure within the target of those pointers.
      The tradeoff is an increase in memory, particularly if the tree is
      sparse.
      
      In CIFS, we use the tlink_tree to track tcon_link structs. A tcon_link
      can never be in more than one tlink_tree, so there's no impediment to
      using a rb_tree here instead of a radix tree.
      
      Convert the new multiuser mount code to use a rb_tree instead. This
      should reduce the memory required to manage the tlink_tree.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      b647c35f
    • J
      cifs: store pointer to master tlink in superblock (try #2) · 413e661c
      Jeff Layton 提交于
      This is the second version of this patch, the only difference between
      it and the first one is that this explicitly makes cifs_sb_master_tlink
      a static inline.
      
      Instead of keeping a tag on the master tlink in the tree, just keep a
      pointer to the master in the superblock. That eliminates the need for
      using the radix tree to look up a tagged entry.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      413e661c
  2. 13 10月, 2010 1 次提交
    • J
      cifs: don't use vfsmount to pin superblock for oplock breaks · d7c86ff8
      Jeff Layton 提交于
      Filesystems aren't really supposed to do anything with a vfsmount. It's
      considered a layering violation since vfsmounts are entirely managed at
      the VFS layer.
      
      CIFS currently keeps an active reference to a vfsmount in order to
      prevent the superblock vanishing before an oplock break has completed.
      What we really want to do instead is to keep sb->s_active high until the
      oplock break has completed. This patch borrows the scheme that NFS uses
      for handling sillyrenames.
      
      An atomic_t is added to the cifs_sb_info. When it transitions from 0 to
      1, an extra reference to the superblock is taken (by bumping the
      s_active value). When it transitions from 1 to 0, that reference is
      dropped and a the superblock teardown may proceed if there are no more
      references to it.
      
      Also, the vfsmount pointer is removed from cifsFileInfo and from
      cifs_new_fileinfo, and some bogus forward declarations are removed from
      cifsfs.h.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Acked-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      d7c86ff8
  3. 08 10月, 2010 2 次提交
    • J
      cifs: implement recurring workqueue job to prune old tcons · 2de970ff
      Jeff Layton 提交于
      Create a workqueue job that cleans out unused tlinks. For now, it uses
      a hardcoded expire time of 10 minutes. When it's done, the work rearms
      itself. On umount, the work is cancelled before tearing down the tlink
      tree.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      2de970ff
    • J
      cifs: add routines to build sessions and tcons on the fly · 9d002df4
      Jeff Layton 提交于
      This patch is rather large, but it's a bit difficult to do piecemeal...
      
      For non-multiuser mounts, everything will basically work as it does
      today. A call to cifs_sb_tlink will return the "master" tcon link.
      
      Turn the tcon pointer in the cifs_sb into a radix tree that uses the
      fsuid of the process as a key. The value is a new "tcon_link" struct
      that contains info about a tcon that's under construction.
      
      When a new process needs a tcon, it'll call cifs_sb_tcon. That will
      then look up the tcon_link in the radix tree. If it exists and is
      valid, it's returned.
      
      If it doesn't exist, then we stuff a new tcon_link into the tree and
      mark it as pending and then go and try to build the session/tcon.
      If that works, the tcon pointer in the tcon_link is updated and the
      pending flag is cleared.
      
      If the construction fails, then we set the tcon pointer to an ERR_PTR
      and clear the pending flag.
      
      If the radix tree is searched and the tcon_link is marked pending
      then we go to sleep and wait for the pending flag to be cleared.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      9d002df4
  4. 07 10月, 2010 1 次提交
  5. 30 9月, 2010 2 次提交
  6. 02 8月, 2010 1 次提交
  7. 22 4月, 2010 1 次提交
  8. 12 3月, 2009 2 次提交
    • S
      [CIFS] fix build error · 4717bed6
      Steve French 提交于
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      4717bed6
    • S
      [CIFS] Add new nostrictsync cifs mount option to avoid slow SMB flush · be652445
      Steve French 提交于
      If this mount option is set, when an application does an
      fsync call then the cifs client does not send an SMB Flush
      to the server (to force the server to write all dirty data
      for this file immediately to disk), although cifs still sends
      all dirty (cached) file data to the server and waits for the
      server to respond to the write write.  Since SMB Flush can be
      very slow, and some servers may be reliable enough (to risk
      delaying slightly flushing the data to disk on the server),
      turning on this option may be useful to improve performance for
      applications that fsync too much, at a small risk of server
      crash.  If this mount option is not set, by default cifs will
      send an SMB flush request (and wait for a response) on every
      fsync call.
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      be652445
  9. 26 12月, 2008 1 次提交
    • S
      [CIFS] add mount option to send mandatory rather than advisory locks · 13a6e42a
      Steve French 提交于
      Some applications/subsystems require mandatory byte range locks
      (as is used for Windows/DOS/OS2 etc). Sending advisory (posix style)
      byte range lock requests (instead of mandatory byte range locks) can
      lead to problems for these applications (which expect that other
      clients be prevented from writing to portions of the file which
      they have locked and are updating).  This mount option allows
      mounting cifs with the new mount option "forcemand" (or
      "forcemandatorylock") in order to have the cifs client use mandatory
      byte range locks (ie SMB/CIFS/Windows/NTFS style locks) rather than
      posix byte range lock requests, even if the server would support
      posix byte range lock requests.  This has no effect if the server
      does not support the CIFS Unix Extensions (since posix style locks
      require support for the CIFS Unix Extensions), but for mounts
      to Samba servers this can be helpful for Wine and applications
      that require mandatory byte range locks.
      Acked-by: NJeff Layton <jlayton@redhat.com>
      CC: Alexander Bokovoy <ab@samba.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      13a6e42a
  10. 14 11月, 2008 1 次提交
  11. 13 5月, 2008 1 次提交
    • J
      [CIFS] CIFS currently allows for permissions to be changed on files, even · d0a9c078
      Jeff Layton 提交于
      when unix extensions and cifsacl support are disabled. These
      permissions changes are "ephemeral" however. They are lost whenever
      a share is mounted and unmounted, or when memory pressure forces
      the inode out of the cache.
      
      Because of this, we'd like to introduce a behavior change to make
      CIFS behave more like local DOS/Windows filesystems. When unix
      extensions and cifsacl support aren't enabled, then don't silently
      ignore changes to permission bits that can't be reflected on the
      server.
      
      Still, there may be people relying on the current behavior for
      certain applications. This patch adds a new "dynperm" (and a
      corresponding "nodynperm") mount option that will be intended
      to make the client fall back to legacy behavior when setting
      these modes.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      d0a9c078
  12. 11 1月, 2008 1 次提交
  13. 13 7月, 2007 1 次提交
  14. 01 5月, 2007 1 次提交
    • S
      [CIFS] UID/GID override on CIFS mounts to Samba · 4523cc30
      Steve French 提交于
      When CIFS Unix Extensions are negotiated we get the Unix uid and gid
      owners of the file from the server (on the Unix Query Path Info
      levels), but if the server's uids don't match the client uid's users
      were having to disable the Unix Extensions (which turned off features
      they still wanted).   The changeset patch allows users to override uid
      and/or gid for file/directory owner with a default uid and/or gid
      specified at mount (as is often done when mounting from Linux cifs
      client to Windows server).  This changeset also displays the uid
      and gid used by default in /proc/mounts (if applicable).
      
      Also cleans up code by adding some of the missing spaces after
      "if" keywords per-kernel style guidelines (as suggested by Randy Dunlap
      when he reviewed the patch).
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      4523cc30
  15. 21 9月, 2006 1 次提交
  16. 13 1月, 2006 1 次提交
  17. 20 8月, 2005 1 次提交
  18. 19 8月, 2005 1 次提交
  19. 15 7月, 2005 1 次提交
    • S
      [CIFS] Add compat with SFU (part 1) · d7245c2c
      Steve French 提交于
      This should help the case of creating fifos and other special files to
      servers which do not support the Unix extensions.
      
      Signed-off-by: Steve French (sfrench@us.ibm.com)
      
      Thanks to Martin Koeppe for his suggestions and good analysis
      d7245c2c
  20. 23 6月, 2005 1 次提交
  21. 29 4月, 2005 1 次提交
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4