1. 02 11月, 2009 1 次提交
    • E
      9p: fix readdir corner cases · 3e2796a9
      Eric Van Hensbergen 提交于
      The patch below also addresses a couple of other corner cases in readdir
      seen with a large (e.g. 64k) msize.  I'm not sure what people think of
      my co-opting of fid->aux here.  I'd be happy to rework if there's a better
      way.
      
      When the size of the user supplied buffer passed to readdir is smaller
      than the data returned in one go by the 9P read request, v9fs_dir_readdir()
      currently discards extra data so that, on the next call, a 9P read
      request will be issued with offset < previous offset + bytes returned,
      which voilates the constraint described in paragraph 3 of read(5) description.
      This patch preseves the leftover data in fid->aux for use in the next call.
      Signed-off-by: NJim Garlick <garlick@llnl.gov>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      3e2796a9
  2. 18 8月, 2009 2 次提交
  3. 15 7月, 2009 2 次提交
  4. 06 4月, 2009 3 次提交
  5. 20 1月, 2009 1 次提交
  6. 14 11月, 2008 1 次提交
  7. 06 11月, 2008 5 次提交
    • R
      net/9p: fix printk format warnings · b0d5fdef
      Randy Dunlap 提交于
      Fix printk format warnings in net/9p.
      Built cleanly on 7 arches.
      
      net/9p/client.c:820: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:820: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:867: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:867: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:932: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:932: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'u64'
      net/9p/client.c:982: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:982: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:1025: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:1025: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 12 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 13 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 12 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 13 has type 'u64'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      b0d5fdef
    • R
      unsigned fid->fid cannot be negative · 9f3e9bbe
      Roel Kluin 提交于
      Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      9f3e9bbe
    • T
      p9: Fix leak of waitqueue in request allocation path · 45abdf1c
      Tom Tucker 提交于
      If a T or R fcall cannot be allocated, the function returns an error
      but neglects to free the wait queue that was successfully allocated.
      
      If it comes through again a second time this wq will be overwritten
      with a new allocation and the old allocation will be leaked.
      
      Also, if the client is subsequently closed, the close path will
      attempt to clean up these allocations, so set the req fields to
      NULL to avoid duplicate free.
      Signed-off-by: NTom Tucker <tom@opengridcomputing.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      45abdf1c
    • T
      9p: Remove unneeded free of fcall for Flush · 82b189ea
      Tom Tucker 提交于
      T and R fcall are reused until the client is destroyed. There does
      not need to be a special case for Flush
      Signed-off-by: NTom Tucker <tom@opengridcomputing.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      82b189ea
    • T
      9p: Make all client spin locks IRQ safe · cac23d65
      Tom Tucker 提交于
      The client lock must be IRQ safe. Some of the lock acquisition paths
      took regular spin locks.
      Signed-off-by: NTom Tucker <tom@opengridcomputing.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      cac23d65
  8. 05 11月, 2008 1 次提交
    • R
      net/9p: fix printk format warnings · b22cecdd
      Randy Dunlap 提交于
      Fix printk format warnings in net/9p.
      Built cleanly on 7 arches.
      
      net/9p/client.c:820: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:820: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:867: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:867: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:932: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:932: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'u64'
      net/9p/client.c:982: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:982: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:1025: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      net/9p/client.c:1025: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 12 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'u64'
      net/9p/client.c:1227: warning: format '%llx' expects type 'long long unsigned int', but argument 13 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 12 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 8 has type 'u64'
      net/9p/client.c:1252: warning: format '%llx' expects type 'long long unsigned int', but argument 13 has type 'u64'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b22cecdd
  9. 23 10月, 2008 1 次提交
  10. 18 10月, 2008 12 次提交
  11. 14 10月, 2008 1 次提交
  12. 25 9月, 2008 1 次提交
    • T
      9p: implement proper trans module refcounting and unregistration · 72029fe8
      Tejun Heo 提交于
      9p trans modules aren't refcounted nor were they unregistered
      properly.  Fix it.
      
      * Add 9p_trans_module->owner and reference the module on each trans
        instance creation and put it on destruction.
      
      * Protect v9fs_trans_list with a spinlock.  This isn't strictly
        necessary as the list is manipulated only during module loading /
        unloading but it's a good idea to make the API safe.
      
      * Unregister trans modules when the corresponding module is being
        unloaded.
      
      * While at it, kill unnecessary EXPORT_SYMBOL on p9_trans_fd_init().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      72029fe8
  13. 15 5月, 2008 2 次提交
  14. 07 2月, 2008 4 次提交
  15. 18 10月, 2007 3 次提交
    • E
      9p: fix bad kconfig cross-dependency · fb0466c3
      Eric Van Hensbergen 提交于
      This patch moves transport dynamic registration and matching to the net
      module to prevent a bad Kconfig dependency between the net and fs 9p modules.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      fb0466c3
    • L
      9p: attach-per-user · ba17674f
      Latchesar Ionkov 提交于
      The 9P2000 protocol requires the authentication and permission checks to be
      done in the file server. For that reason every user that accesses the file
      server tree has to authenticate and attach to the server separately.
      Multiple users can share the same connection to the server.
      
      Currently v9fs does a single attach and executes all I/O operations as a
      single user. This makes using v9fs in multiuser environment unsafe as it
      depends on the client doing the permission checking.
      
      This patch improves the 9P2000 support by allowing every user to attach
      separately. The patch defines three modes of access (new mount option
      'access'):
      
      - attach-per-user (access=user) (default mode for 9P2000.u)
       If a user tries to access a file served by v9fs for the first time, v9fs
       sends an attach command to the server (Tattach) specifying the user. If
       the attach succeeds, the user can access the v9fs tree.
       As there is no uname->uid (string->integer) mapping yet, this mode works
       only with the 9P2000.u dialect.
      
      - allow only one user to access the tree (access=<uid>)
       Only the user with uid can access the v9fs tree. Other users that attempt
       to access it will get EPERM error.
      
      - do all operations as a single user (access=any) (default for 9P2000)
       V9fs does a single attach and all operations are done as a single user.
       If this mode is selected, the v9fs behavior is identical with the current
       one.
      Signed-off-by: NLatchesar Ionkov <lucho@ionkov.net>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      ba17674f
    • E
      9p: Make transports dynamic · a80d923e
      Eric Van Hensbergen 提交于
      This patch abstracts out the interfaces to underlying transports so that
      new transports can be added as modules.  This should also allow kernel
      configuration of transports without ifdef-hell.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      a80d923e