1. 25 12月, 2008 8 次提交
    • H
      libcrc32c: Add crc32c_le macro · 0426c166
      Herbert Xu 提交于
      The bnx2x driver actually uses the crc32c_le name so this patch
      restores the crc32c_le symbol through a macro.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0426c166
    • H
      libcrc32c: Move implementation to crypto crc32c · 69c35efc
      Herbert Xu 提交于
      This patch swaps the role of libcrc32c and crc32c.  Previously
      the implementation was in libcrc32c and crc32c was a wrapper.
      Now the code is in crc32c and libcrc32c just calls the crypto
      layer.
      
      The reason for the change is to tap into the algorithm selection
      capability of the crypto API so that optimised implementations
      such as the one utilising Intel's CRC32C instruction can be
      used where available.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      69c35efc
    • H
      crypto: hash - Export shash through hash · 5f7082ed
      Herbert Xu 提交于
      This patch allows shash algorithms to be used through the old hash
      interface.  This is a transitional measure so we can convert the
      underlying algorithms to shash before converting the users across.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5f7082ed
    • H
      crypto: hash - Add import/export interface · dec8b786
      Herbert Xu 提交于
      It is often useful to save the partial state of a hash function
      so that it can be used as a base for two or more computations.
      
      The most prominent example is HMAC where all hashes start from
      a base determined by the key.  Having an import/export interface
      means that we only have to compute that base once rather than
      for each message.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dec8b786
    • H
      crypto: hash - Export shash through ahash · 3b2f6df0
      Herbert Xu 提交于
      This patch allows shash algorithms to be used through the ahash
      interface.  This is required before we can convert digest algorithms
      over to shash.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3b2f6df0
    • H
      crypto: hash - Add shash interface · 7b5a080b
      Herbert Xu 提交于
      The shash interface replaces the current synchronous hash interface.
      It improves over hash in two ways.  Firstly shash is reentrant,
      meaning that the same tfm may be used by two threads simultaneously
      as all hashing state is stored in a local descriptor.
      
      The other enhancement is that shash no longer takes scatter list
      entries.  This is because shash is specifically designed for
      synchronous algorithms and as such scatter lists are unnecessary.
      
      All existing hash users will be converted to shash once the
      algorithms have been completely converted.
      
      There is also a new finup function that combines update with final.
      This will be extended to ahash once the algorithm conversion is
      done.
      
      This is also the first time that an algorithm type has their own
      registration function.  Existing algorithm types will be converted
      to this way in due course.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7b5a080b
    • H
      crypto: api - Rebirth of crypto_alloc_tfm · 7b0bac64
      Herbert Xu 提交于
      This patch reintroduces a completely revamped crypto_alloc_tfm.
      The biggest change is that we now take two crypto_type objects
      when allocating a tfm, a frontend and a backend.  In fact this
      simply formalises what we've been doing behind the API's back.
      
      For example, as it stands crypto_alloc_ahash may use an
      actual ahash algorithm or a crypto_hash algorithm.  Putting
      this in the API allows us to do this much more cleanly.
      
      The existing types will be converted across gradually.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7b0bac64
    • H
      crypto: api - Move type exit function into crypto_tfm · 4a779486
      Herbert Xu 提交于
      The type exit function needs to undo any allocations done by the type
      init function.  However, the type init function may differ depending
      on the upper-level type of the transform (e.g., a crypto_blkcipher
      instantiated as a crypto_ablkcipher).
      
      So we need to move the exit function out of the lower-level
      structure and into crypto_tfm itself.
      
      As it stands this is a no-op since nobody uses exit functions at
      all.  However, all cases where a lower-level type is instantiated
      as a different upper-level type (such as blkcipher as ablkcipher)
      will be converted such that they allocate the underlying transform
      and use that instead of casting (e.g., crypto_ablkcipher casted
      into crypto_blkcipher).  That will need to use a different exit
      function depending on the upper-level type.
      
      This patch also allows the type init/exit functions to call (or not)
      cra_init/cra_exit instead of always calling them from the top level.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4a779486
  2. 24 12月, 2008 13 次提交
    • O
      nfsd: support callbacks with gss flavors · 61054b14
      Olga Kornievskaia 提交于
      This patch adds server-side support for callbacks other than AUTH_SYS.
      Signed-off-by: NOlga Kornievskaia <aglo@citi.umich.edu>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      61054b14
    • O
      rpc: pass target name down to rpc level on callbacks · 608207e8
      Olga Kornievskaia 提交于
      The rpc client needs to know the principal that the setclientid was done
      as, so it can tell gssd who to authenticate to.
      Signed-off-by: NOlga Kornievskaia <aglo@citi.umich.edu>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      608207e8
    • O
      nfsd: pass client principal name in rsc downcall · 68e76ad0
      Olga Kornievskaia 提交于
      Two principals are involved in krb5 authentication: the target, who we
      authenticate *to* (normally the name of the server, like
      nfs/server.citi.umich.edu@CITI.UMICH.EDU), and the source, we we
      authenticate *as* (normally a user, like bfields@UMICH.EDU)
      
      In the case of NFSv4 callbacks, the target of the callback should be the
      source of the client's setclientid call, and the source should be the
      nfs server's own principal.
      
      Therefore we allow svcgssd to pass down the name of the principal that
      just authenticated, so that on setclientid we can store that principal
      name with the new client, to be used later on callbacks.
      Signed-off-by: NOlga Kornievskaia <aglo@citi.umich.edu>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      68e76ad0
    • \
      rpc: add an rpc_pipe_open method · c3810608
      \"J. Bruce Fields\ 提交于
      We want to transition to a new gssd upcall which is text-based and more
      easily extensible.
      
      To simplify upgrades, as well as testing and debugging, it will help if
      we can upgrade gssd (to a version which understands the new upcall)
      without having to choose at boot (or module-load) time whether we want
      the new or the old upcall.
      
      We will do this by providing two different pipes: one named, as
      currently, after the mechanism (normally "krb5"), and supporting the
      old upcall.  One named "gssd" and supporting the new upcall version.
      
      We allow gssd to indicate which version it supports by its choice of
      which pipe to open.
      
      As we have no interest in supporting *simultaneous* use of both
      versions, we'll forbid opening both pipes at the same time.
      
      So, add a new pipe_open callback to the rpc_pipefs api, which the gss
      code can use to track which pipes have been open, and to refuse opens of
      incompatible pipes.
      
      We only need this to be called on the first open of a given pipe.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c3810608
    • B
      sunrpc: get rid of rpc_rqst.rq_bufsize · c977a2ef
      Benny Halevy 提交于
      rq_bufsize is not used.
      Signed-off-by: NMike Sager <Mike.Sager@netapp.com>
      Signed-off-by: NBenny Halevy <bhalevy@panasas.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c977a2ef
    • P
      optimize attribute timeouts for "noac" and "actimeo=0" · 64672d55
      Peter Staubach 提交于
      Hi.
      
      I've been looking at a bugzilla which describes a problem where
      a customer was advised to use either the "noac" or "actimeo=0"
      mount options to solve a consistency problem that they were
      seeing in the file attributes.  It turned out that this solution
      did not work reliably for them because sometimes, the local
      attribute cache was believed to be valid and not timed out.
      (With an attribute cache timeout of 0, the cache should always
      appear to be timed out.)
      
      In looking at this situation, it appears to me that the problem
      is that the attribute cache timeout code has an off-by-one
      error in it.  It is assuming that the cache is valid in the
      region, [read_cache_jiffies, read_cache_jiffies + attrtimeo].  The
      cache should be considered valid only in the region,
      [read_cache_jiffies, read_cache_jiffies + attrtimeo).  With this
      change, the options, "noac" and "actimeo=0", work as originally
      expected.
      
      This problem was previously addressed by special casing the
      attrtimeo == 0 case.  However, since the problem is only an off-
      by-one error, the cleaner solution is address the off-by-one
      error and thus, not require the special case.
      
          Thanx...
      
              ps
      Signed-off-by: NPeter Staubach <staubach@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      64672d55
    • T
      dc0b027d
    • T
      bd7bf9d5
    • T
      NFSv4: Remove nfs_client->cl_sem · 95d35cb4
      Trond Myklebust 提交于
      Now that we're using the flags to indicate state that needs to be
      recovered, as well as having implemented proper refcounting and spinlocking
      on the state and open_owners, we can get rid of nfs_client->cl_sem. The
      only remaining case that was dubious was the file locking, and that case is
      now covered by the nfsi->rwsem.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      95d35cb4
    • C
      NLM: allow lockd requests from an unprivileged port · 0cb2659b
      Chuck Lever 提交于
      If the admin has specified the "noresvport" option for an NFS mount
      point, the kernel's NFS client uses an unprivileged source port for
      the main NFS transport.  The kernel's lockd client should use an
      unprivileged port in this case as well.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0cb2659b
    • C
      NFS: add "[no]resvport" mount option · d740351b
      Chuck Lever 提交于
      The standard default security setting for NFS is AUTH_SYS.  An NFS
      client connects to NFS servers via a privileged source port and a
      fixed standard destination port (2049).  The client sends raw uid and
      gid numbers to identify users making NFS requests, and the server
      assumes an appropriate authority on the client has vetted these
      values because the source port is privileged.
      
      On Linux, by default in-kernel RPC services use a privileged port in
      the range between 650 and 1023 to avoid using source ports of well-
      known IP services.  Using such a small range limits the number of NFS
      mount points and the number of unique NFS servers to which a client
      can connect concurrently.
      
      An NFS client can use unprivileged source ports to expand the range of
      source port numbers, allowing more concurrent server connections and
      more NFS mount points.  Servers must explicitly allow NFS connections
      from unprivileged ports for this to work.
      
      In the past, bumping the value of the sunrpc.max_resvport sysctl on
      the client would permit the NFS client to use unprivileged ports.
      Bumping this setting also changes the maximum port number used by
      other in-kernel RPC services, some of which still required a port
      number less than 1023.
      
      This is exacerbated by the way source port numbers are chosen by the
      Linux RPC client, which starts at the top of the range and works
      downwards.  It means that bumping the maximum means all RPC services
      requesting a source port will likely get an unprivileged port instead
      of a privileged one.
      
      Changing this setting effects all NFS mount points on a client.  A
      sysadmin could not selectively choose which mount points would use
      non-privileged ports and which could not.
      
      Lastly, this mechanism of expanding the limit on the number of NFS
      mount points was entirely undocumented.
      
      To address the need for the NFS client to use a large range of source
      ports without interfering with the activity of other in-kernel RPC
      services, we introduce a new NFS mount option.  This option explicitly
      tells only the NFS client to use a non-privileged source port when
      communicating with the NFS server for one specific mount point.
      
      This new mount option is called "resvport," like the similar NFS mount
      option on FreeBSD and Mac OS X.  A sister patch for nfs-utils will be
      submitted that documents this new option in nfs(5).
      
      The default setting for this new mount option requires the NFS client
      to use a privileged port, as before.  Explicitly specifying the
      "noresvport" mount option allows the NFS client to use an unprivileged
      source port for this mount point when connecting to the NFS server
      port.
      
      This mount option is supported only for text-based NFS mounts.
      
      [ Sidebar: it is widely known that security mechanisms based on the
        use of privileged source ports are ineffective.  However, the NFS
        client can combine the use of unprivileged ports with the use of
        secure authentication mechanisms, such as Kerberos.  This allows a
        large number of connections and mount points while ensuring a useful
        level of security.
      
        Eventually we may change the default setting for this option
        depending on the security flavor used for the mount.  For example,
        if the mount is using only AUTH_SYS, then the default setting will
        be "resvport;" if the mount is using a strong security flavor such
        as krb5, the default setting will be "noresvport." ]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      [Trond.Myklebust@netapp.com: Fixed a bug whereby nfs4_init_client()
      was being called with incorrect arguments.]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d740351b
    • C
      NFS: Move declaration of nfs_mount() to fs/nfs/internal.h · 146ec944
      Chuck Lever 提交于
      Clean up:  The nfs_mount() function is not to be used outside of the
      NFS client.  Move its public declaration to fs/nfs/internal.h.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      146ec944
    • T
      SUNRPC: Remove the last remnant of the BKL... · 88a9fe8c
      Trond Myklebust 提交于
      Somehow, this escaped the previous purge. There should be no need to keep
      any extra locks in the XDR callbacks.
      
      The NFS client XDR code only writes into private objects, whereas all reads
      of shared objects are confined to fields that do not change, such as
      filehandles...
      
      Ditto for lockd, the NFSv2/v3 client mount code, and rpcbind.
      
      The nfsd XDR code may require the BKL, but since it does a synchronous RPC
      call from a thread that already holds the lock, that issue is moot.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      88a9fe8c
  3. 23 12月, 2008 1 次提交
  4. 22 12月, 2008 3 次提交
  5. 21 12月, 2008 2 次提交
  6. 20 12月, 2008 9 次提交
  7. 19 12月, 2008 4 次提交