1. 04 10月, 2006 3 次提交
    • N
      [PATCH] knfsd: Avoid excess stack usage in svc_tcp_recvfrom · 3cc03b16
      NeilBrown 提交于
      ..  by allocating the array of 'kvec' in 'struct svc_rqst'.
      
      As we plan to increase RPCSVC_MAXPAGES from 8 upto 256, we can no longer
      allocate an array of this size on the stack.  So we allocate it in 'struct
      svc_rqst'.
      
      However svc_rqst contains (indirectly) an array of the same type and size
      (actually several, but they are in a union).  So rather than waste space, we
      move those arrays out of the separately allocated union and into svc_rqst to
      share with the kvec moved out of svc_tcp_recvfrom (various arrays are used at
      different times, so there is no conflict).
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3cc03b16
    • N
      [PATCH] knfsd: Replace two page lists in struct svc_rqst with one · 44524359
      NeilBrown 提交于
      We are planning to increase RPCSVC_MAXPAGES from about 8 to about 256.  This
      means we need to be a bit careful about arrays of size RPCSVC_MAXPAGES.
      
      struct svc_rqst contains two such arrays.  However the there are never more
      that RPCSVC_MAXPAGES pages in the two arrays together, so only one array is
      needed.
      
      The two arrays are for the pages holding the request, and the pages holding
      the reply.  Instead of two arrays, we can simply keep an index into where the
      first reply page is.
      
      This patch also removes a number of small inline functions that probably
      server to obscure what is going on rather than clarify it, and opencode the
      needed functionality.
      
      Also remove the 'rq_restailpage' variable as it is *always* 0.  i.e.  if the
      response 'xdr' structure has a non-empty tail it is always in the same pages
      as the head.
      
       check counters are initilised and incr properly
       check for consistant usage of ++ etc
       maybe extra some inlines for common approach
       general review
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: Magnus Maatta <novell@kiruna.se>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      44524359
    • E
      BUG_ON() conversion in fs/nfsd/ · 73dff8be
      Eric Sesterhenn 提交于
      This patch converts an if () BUG(); construct to BUG_ON();
      which occupies less space, uses unlikely and is safer when
      BUG() is disabled.
      Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      73dff8be
  2. 23 6月, 2006 1 次提交
  3. 11 4月, 2006 3 次提交
  4. 24 3月, 2006 1 次提交
  5. 19 1月, 2006 2 次提交
  6. 07 11月, 2005 1 次提交
  7. 08 7月, 2005 3 次提交
    • N
      [PATCH] nfsd4: fix fh_expire_type · e34ac862
      NeilBrown 提交于
      After discussion at the recent NFSv4 bake-a-thon, I realized that my
      assumption that NFS4_FH_PERSISTENT required filehandles to persist was a
      misreading of the spec.  This also fixes an interoperability problem with the
      Solaris client.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e34ac862
    • N
      [PATCH] nfsd4: seqid comments · 7fb64cee
      NeilBrown 提交于
      Add some comments on the use of so_seqid, in an attempt to avoid some of the
      confusion outlined in the previous patch....
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7fb64cee
    • N
      [PATCH] nfsd4: fix open_reclaim seqid · bd9aac52
      NeilBrown 提交于
      The sequence number we store in the sequence id is the last one we received
      from the client.  So on the next operation we'll check that the client gives
      us the next higher number.
      
      We increment sequence id's at the last moment, in encode, so that we're sure
      of knowing the right error return.  (The decision to increment the sequence id
      depends on the exact error returned.)
      
      However on the *first* use of a sequence number, if we set the sequence number
      to the one received from the client and then let the increment happen on
      encode, we'll be left with a sequence number one to high.
      
      For that reason, ENCODE_SEQID_OP_TAIL only increments the sequence id on
      *confirmed* stateowners.
      
      This creates a problem for open reclaims, which are confirmed on first use.
      Therefore the open reclaim code, as a special exception, *decrements* the
      sequence id, cancelling out the undesired increment on encode.  But this
      prevents the sequence id from ever being incremented in the case where
      multiple reclaims are sent with the same openowner.  Yuch!
      
      We could add another exception to the open reclaim code, decrementing the
      sequence id only if this is the first use of the open owner.
      
      But it's simpler by far to modify the meaning of the op_seqid field: instead
      of representing the previous value sent by the client, we take op_seqid, after
      encoding, to represent the *next* sequence id that we expect from the client.
      This eliminates the need for special-case handling of the first use of a
      stateowner.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bd9aac52
  8. 24 6月, 2005 3 次提交
  9. 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