1. 06 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: tidy up up meaning of 'buffer size' in nfsd/sunrpc · c6b0a9f8
      NeilBrown 提交于
      There is some confusion about the meaning of 'bufsz' for a sunrpc server.
      In some cases it is the largest message that can be sent or received.  In
      other cases it is the largest 'payload' that can be included in a NFS
      message.
      
      In either case, it is not possible for both the request and the reply to be
      this large.  One of the request or reply may only be one page long, which
      fits nicely with NFS.
      
      So we remove 'bufsz' and replace it with two numbers: 'max_payload' and
      'max_mesg'.  Max_payload is the size that the server requests.  It is used
      by the server to check the max size allowed on a particular connection:
      depending on the protocol a lower limit might be used.
      
      max_mesg is the largest single message that can be sent or received.  It is
      calculated as the max_payload, rounded up to a multiple of PAGE_SIZE, and
      with PAGE_SIZE added to overhead.  Only one of the request and reply may be
      this size.  The other must be at most one page.
      
      Cc: Greg Banks <gnb@sgi.com>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c6b0a9f8
  2. 04 10月, 2006 4 次提交
    • O
      [PATCH] knfsd: register all RPC programs with portmapper by default · bc5fea42
      Olaf Kirch 提交于
      The NFSACL patches introduced support for multiple RPC services listening on
      the same transport.  However, only the first of these services was registered
      with portmapper.  This was perfectly fine for nfsacl, as you traditionally do
      not want these to show up in a portmapper listing.
      
      The patch below changes the default behavior to always register all services
      listening on a given transport, but retains the old behavior for nfsacl
      services.
      Signed-off-by: NOlaf Kirch <okir@suse.de>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bc5fea42
    • G
      [PATCH] knfsd: Prepare knfsd for support of rsize/wsize of up to 1MB, over TCP · 7adae489
      Greg Banks 提交于
      The limit over UDP remains at 32K.  Also, make some of the apparently
      arbitrary sizing constants clearer.
      
      The biggest change here involves replacing NFSSVC_MAXBLKSIZE by a function of
      the rqstp.  This allows it to be different for different protocols (udp/tcp)
      and also allows it to depend on the servers declared sv_bufsiz.
      
      Note that we don't actually increase sv_bufsz for nfs yet.  That comes next.
      Signed-off-by: NGreg Banks <gnb@melbourne.sgi.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7adae489
    • 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
  3. 02 10月, 2006 7 次提交
  4. 29 9月, 2006 2 次提交
  5. 01 7月, 2006 1 次提交
  6. 11 4月, 2006 1 次提交
  7. 19 1月, 2006 1 次提交
  8. 07 11月, 2005 1 次提交
  9. 23 6月, 2005 2 次提交
  10. 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