crypto: drbg - backport "fix maximum value checks on 32 bit systems"

This is a backport of commit b9347aff91ce4789619168539f08202d8d6a1177.
This backport is needed as without it the code will crash on 32-bit
systems.
    
The maximum values for additional input string or generated blocks is
larger than 1<<32. To ensure a sensible value on 32 bit systems, return
SIZE_MAX on 32 bit systems. This value is lower than the maximum
allowed values defined in SP800-90A. The standard allow lower maximum
values, but not larger values.

SIZE_MAX - 1 is used for drbg_max_addtl to allow
drbg_healthcheck_sanity to check the enforcement of the variable
without wrapping.
    
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: drbg - remove check for uninitialized DRBG handle

The drbg_healthcheck() contained a test to call the DRBG with an
uninitialized DRBG cipher handle. As this is an inappropriate use of the
kernel crypto API to try to generate random numbers before
initialization, checks verifying for an initialized DRBG have been
removed in previous patches.

Now, the drbg_healthcheck test must also be removed.

Changes V2: Added patch marker to email subject line.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

Pull crypto fixes from Herbert Xu:
 "This fixes the newly added drbg generator so that it actually works on
  32-bit machines.  Previously the code was only tested on 64-bit and on
  32-bit it overflowed and simply doesn't work"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: drbg - remove check for uninitialized DRBG handle
  crypto: drbg - backport "fix maximum value checks on 32 bit systems"
vfs: simplify and shrink stack frame of link_path_walk()

Commit 9226b5b440f2 ("vfs: avoid non-forwarding large load after small
store in path lookup") made link_path_walk() always access the
"hash_len" field as a single 64-bit entity, in order to avoid mixed size
accesses to the members.

However, what I didn't notice was that that effectively means that the
whole "struct qstr this" is now basically redundant.  We already
explicitly track the "const char *name", and if we just use "u64
hash_len" instead of "long len", there is nothing else left of the
"struct qstr".

We do end up wanting the "struct qstr" if we have a filesystem with a
"d_hash()" function, but that's a rare case, and we might as well then
just squirrell away the name and hash_len at that point.

End result: fewer live variables in the loop, a smaller stack frame, and
better code generation.  And we don't need to pass in pointers variables
to helper functions any more, because the return value contains all the
relevant information.  So this removes more lines than it adds, and the
source code is clearer too.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ia64: Fix syscall number for memfd_create

Cut & paste typo from the line above.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>