* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..1a0c6a486a9c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -21,6 +21,7 @@ config ARM
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+ select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
new file mode 100644
index 000000000000..19c3dddd901a
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/hwcap.h>
+
+/*
+ * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
+ * of optional CPU features it defines, ARM's CPU capability bits have been
+ * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
+ * covers a subset of the available CPU features.
+ *
+ * Currently, only a few of those are suitable for automatic module loading
+ * (which is the primary use case of this facility) and those happen to be all
+ * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
+ */
+#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
+#define cpu_feature(x) ilog2(HWCAP2_ ## x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ return elf_hwcap2 & (1UL << num);
+}
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] ARM: add module autoloading support for crypto modules
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
This series wires up the crypto modules that use the ARM 32-bit versions of
the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
feature bits via the CPU modalias. This is very similar to the arm64
implementation, with the notable exception that ARM has its CPU feature
definitions split across HWCAP and HWCAP2.
Given that the crypto feature bits are all exposed via HWCAP2, and considering
that there are currently no features exposed via HWCAP that are relevant to
udev module autoloading, exposing HWCAP2 only should be sufficient, at least
for now.
Note to Herbert: patches #2 - #5 all depend on #1, which requires an ack from
Russell, so please don't pull anything until #1 has been acked and/or merged.
Ard Biesheuvel (5):
ARM: wire up HWCAP2 feature bits to the CPU modalias
crypto: arm/aes-ce - enable module autoloading based on CPU feature
bits
crypto: arm/ghash-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha1-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha2-ce - enable module autoloading based on CPU feature
bits
arch/arm/Kconfig | 1 +
arch/arm/crypto/aes-ce-glue.c | 5 ++-
arch/arm/crypto/ghash-ce-glue.c | 6 ++--
arch/arm/crypto/sha1-ce-glue.c | 5 ++-
arch/arm/crypto/sha2-ce-glue.c | 5 ++-
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
6 files changed, 41 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/include/asm/cpufeature.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH 00/28] Reenable maybe-uninitialized warnings
From: Christoph Hellwig @ 2016-10-18 5:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, linux-kernel, x86, linux-media,
Mauro Carvalho Chehab, Martin Schwidefsky, linux-s390,
Ilya Dryomov, dri-devel, linux-mtd, Herbert Xu, linux-crypto,
David S. Miller, netdev, Greg Kroah-Hartman, ceph-devel,
linux-f2fs-devel, linux-ext4, netfilter-devel
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote:
> This is a set of patches that I hope to get into v4.9 in some form
> in order to turn on the -Wmaybe-uninitialized warnings again.
Hi Arnd,
I jsut complained to Geert that I was introducing way to many
bugs or pointless warnings for some compilers lately, but gcc didn't
warn me about them. From a little research the lack of
-Wmaybe-uninitialized seems to be the reason for it, so I'm all
for re-enabling it.
^ permalink raw reply
* [PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2016-10-17 22:19 UTC (permalink / raw)
To: Linus Torvalds, Michal Marek
Cc: Nicolas Pitre, Greg Kroah-Hartman, Heiko Carstens, dri-devel,
linux-mtd, Ingo Molnar, linux-s390, Herbert Xu, x86,
Christian Borntraeger, Ilya Dryomov, linux-ext4, linux-media,
Kees Cook, Arnd Bergmann, linux-kbuild, Josh Poimboeuf,
ceph-devel, Mauro Carvalho Chehab, linux-snps-arc, netdev,
linux-kernel, linux-f2fs-devel, netfilter-devel, linux-crypto,
Vineet Gupta
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that
I had not addressed until then. This caused a lot of actual bugs to
get merged into mainline, and I sent several dozen patches for these
during the v4.9 development cycle. Most of these are actual bugs,
some are for correct code that is safe because it is only called
under external constraints that make it impossible to run into
the case that gcc sees, and in a few cases gcc is just stupid and
finds something that can obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got
(I can provide the combined patch for the other warnings if anyone
is interested), so I hope we can get the warning back and let people
catch the actual bugs earlier.
Note that the majority of the patches I created are for the third kind
of problem (stupid false-positives), for one of two reasons:
- some of them only get triggered in certain combinations of config
options, so we don't always run into them, and
- the actual bugs tend to get addressed much quicker as they also
lead to incorrect runtime behavior.
These 27 patches address the warnings that either occur in one of the more
common configurations (defconfig, allmodconfig, or something built by the
kbuild robot or kernelci.org), or they are about a real bug. It would be
good to get these all into v4.9 if we want to turn on the warning again.
I have tested these extensively with gcc-4.9 and gcc-6 and done a bit
of testing with gcc-5, and all of these should now be fine. gcc-4.8
is much worse about the false-positive warnings and is also fairly old
now, so I'm leaving the warning disabled with that version. gcc-4.7 and
older don't understand the -Wno-maybe-uninitialized option and are not
affected by this patch either way.
I have another (smaller) series of patches for warnings that are both
harmless and not as easy to trigger, and I will send them for inclusion
in v4.10.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Makefile | 10 ++++++----
arch/arc/Makefile | 4 +++-
scripts/Makefile.ubsan | 4 ++++
3 files changed, 13 insertions(+), 5 deletions(-)
Cc: x86@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-mtd@lists.infradead.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ceph-devel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: linux-ext4@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
diff --git a/Makefile b/Makefile
index 512e47a..43cd3d9 100644
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
LDFLAGS_vmlinux =
-CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
@@ -620,7 +620,6 @@ ARCH_CFLAGS :=
include arch/$(SRCARCH)/Makefile
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
-KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
@@ -629,15 +628,18 @@ KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS += -Os
+KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
else
ifdef CONFIG_PROFILE_ALL_BRANCHES
-KBUILD_CFLAGS += -O2
+KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,)
else
KBUILD_CFLAGS += -O2
endif
endif
+KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
+ $(call cc-disable-warning,maybe-uninitialized,))
+
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index aa82d13..19cce22 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -71,7 +71,9 @@ cflags-$(CONFIG_ARC_DW2_UNWIND) += -fasynchronous-unwind-tables $(cfi)
ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
# Generic build system uses -O2, we want -O3
# Note: No need to add to cflags-y as that happens anyways
-ARCH_CFLAGS += -O3
+#
+# Disable the false maybe-uninitialized warings gcc spits out at -O3
+ARCH_CFLAGS += -O3 $(call cc-disable-warning,maybe-uninitialized,)
endif
# small data is default for elf32 tool-chain. If not usable, disable it
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index dd779c4..3b1b138 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -17,4 +17,8 @@ endif
ifdef CONFIG_UBSAN_NULL
CFLAGS_UBSAN += $(call cc-option, -fsanitize=null)
endif
+
+ # -fsanitize=* options makes GCC less smart than usual and
+ # increase number of 'maybe-uninitialized false-positives
+ CFLAGS_UBSAN += $(call cc-option, -Wno-maybe-uninitialized)
endif
--
2.9.0
^ permalink raw reply related
* [PATCH 15/28] crypto: aesni: avoid -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2016-10-17 22:13 UTC (permalink / raw)
To: Herbert Xu, x86
Cc: Linus Torvalds, linux-kernel, Arnd Bergmann, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Borislav Petkov,
Stephan Mueller, linux-crypto
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
The rfc4106 encrypy/decrypt helper functions cause an annoying
false-positive warning in allmodconfig if we turn on
-Wmaybe-uninitialized warnings again:
arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
The problem seems to be that the compiler doesn't track the state of the
'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
section.
This reorganizes the code to avoid that variable and have the shared
code in a separate function to avoid some of the conditional branches.
The resulting functions are a bit longer but also slightly less complex,
leaving no room for speculation on the part of the compiler.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The conversion is nontrivial, and I have only build-tested it, so this
could use a careful review and testing.
---
arch/x86/crypto/aesni-intel_glue.c | 121 ++++++++++++++++++++++---------------
1 file changed, 73 insertions(+), 48 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 0ab5ee1..054155b 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -269,6 +269,34 @@ static void (*aesni_gcm_dec_tfm)(void *ctx, u8 *out,
u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
u8 *auth_tag, unsigned long auth_tag_len);
+static inline void aesni_do_gcm_enc_tfm(void *ctx, u8 *out,
+ const u8 *in, unsigned long plaintext_len, u8 *iv,
+ u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
+ u8 *auth_tag, unsigned long auth_tag_len)
+{
+ kernel_fpu_begin();
+ aesni_gcm_enc_tfm(ctx, out, in, plaintext_len, iv, hash_subkey,
+ aad, aad_len, auth_tag, auth_tag_len);
+ kernel_fpu_end();
+}
+
+static inline int aesni_do_gcm_dec_tfm(void *ctx, u8 *out,
+ const u8 *in, unsigned long ciphertext_len, u8 *iv,
+ u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
+ u8 *auth_tag, unsigned long auth_tag_len)
+{
+ kernel_fpu_begin();
+ aesni_gcm_dec_tfm(ctx, out, in, ciphertext_len, iv, hash_subkey, aad,
+ aad_len, auth_tag, auth_tag_len);
+ kernel_fpu_end();
+
+ /* Compare generated tag with passed in tag. */
+ if (crypto_memneq(in + ciphertext_len, auth_tag, auth_tag_len))
+ return -EBADMSG;
+
+ return 0;
+}
+
static inline struct
aesni_rfc4106_gcm_ctx *aesni_rfc4106_gcm_ctx_get(struct crypto_aead *tfm)
{
@@ -879,7 +907,6 @@ static int rfc4106_set_authsize(struct crypto_aead *parent,
static int helper_rfc4106_encrypt(struct aead_request *req)
{
- u8 one_entry_in_sg = 0;
u8 *src, *dst, *assoc;
__be32 counter = cpu_to_be32(1);
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
@@ -908,7 +935,6 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
req->src->offset + req->src->length <= PAGE_SIZE &&
sg_is_last(req->dst) &&
req->dst->offset + req->dst->length <= PAGE_SIZE) {
- one_entry_in_sg = 1;
scatterwalk_start(&src_sg_walk, req->src);
assoc = scatterwalk_map(&src_sg_walk);
src = assoc + req->assoclen;
@@ -916,7 +942,23 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
if (unlikely(req->src != req->dst)) {
scatterwalk_start(&dst_sg_walk, req->dst);
dst = scatterwalk_map(&dst_sg_walk) + req->assoclen;
+
+ aesni_do_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
+ ctx->hash_subkey, assoc, req->assoclen - 8,
+ dst + req->cryptlen, auth_tag_len);
+
+ scatterwalk_unmap(dst - req->assoclen);
+ scatterwalk_advance(&dst_sg_walk, req->dst->length);
+ scatterwalk_done(&dst_sg_walk, 1, 0);
+ } else {
+ aesni_do_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
+ ctx->hash_subkey, assoc, req->assoclen - 8,
+ dst + req->cryptlen, auth_tag_len);
}
+
+ scatterwalk_unmap(assoc);
+ scatterwalk_advance(&src_sg_walk, req->src->length);
+ scatterwalk_done(&src_sg_walk, req->src == req->dst, 0);
} else {
/* Allocate memory for src, dst, assoc */
assoc = kmalloc(req->cryptlen + auth_tag_len + req->assoclen,
@@ -925,28 +967,14 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
return -ENOMEM;
scatterwalk_map_and_copy(assoc, req->src, 0,
req->assoclen + req->cryptlen, 0);
- src = assoc + req->assoclen;
- dst = src;
- }
+ dst = src = assoc + req->assoclen;
- kernel_fpu_begin();
- aesni_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
- ctx->hash_subkey, assoc, req->assoclen - 8,
- dst + req->cryptlen, auth_tag_len);
- kernel_fpu_end();
+ aesni_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
+ ctx->hash_subkey, assoc, req->assoclen - 8,
+ dst + req->cryptlen, auth_tag_len);
- /* The authTag (aka the Integrity Check Value) needs to be written
- * back to the packet. */
- if (one_entry_in_sg) {
- if (unlikely(req->src != req->dst)) {
- scatterwalk_unmap(dst - req->assoclen);
- scatterwalk_advance(&dst_sg_walk, req->dst->length);
- scatterwalk_done(&dst_sg_walk, 1, 0);
- }
- scatterwalk_unmap(assoc);
- scatterwalk_advance(&src_sg_walk, req->src->length);
- scatterwalk_done(&src_sg_walk, req->src == req->dst, 0);
- } else {
+ /* The authTag (aka the Integrity Check Value) needs to be written
+ * back to the packet. */
scatterwalk_map_and_copy(dst, req->dst, req->assoclen,
req->cryptlen + auth_tag_len, 1);
kfree(assoc);
@@ -956,7 +984,6 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
static int helper_rfc4106_decrypt(struct aead_request *req)
{
- u8 one_entry_in_sg = 0;
u8 *src, *dst, *assoc;
unsigned long tempCipherLen = 0;
__be32 counter = cpu_to_be32(1);
@@ -990,47 +1017,45 @@ static int helper_rfc4106_decrypt(struct aead_request *req)
req->src->offset + req->src->length <= PAGE_SIZE &&
sg_is_last(req->dst) &&
req->dst->offset + req->dst->length <= PAGE_SIZE) {
- one_entry_in_sg = 1;
scatterwalk_start(&src_sg_walk, req->src);
assoc = scatterwalk_map(&src_sg_walk);
src = assoc + req->assoclen;
- dst = src;
if (unlikely(req->src != req->dst)) {
scatterwalk_start(&dst_sg_walk, req->dst);
dst = scatterwalk_map(&dst_sg_walk) + req->assoclen;
- }
-
- } else {
- /* Allocate memory for src, dst, assoc */
- assoc = kmalloc(req->cryptlen + req->assoclen, GFP_ATOMIC);
- if (!assoc)
- return -ENOMEM;
- scatterwalk_map_and_copy(assoc, req->src, 0,
- req->assoclen + req->cryptlen, 0);
- src = assoc + req->assoclen;
- dst = src;
- }
- kernel_fpu_begin();
- aesni_gcm_dec_tfm(aes_ctx, dst, src, tempCipherLen, iv,
- ctx->hash_subkey, assoc, req->assoclen - 8,
- authTag, auth_tag_len);
- kernel_fpu_end();
-
- /* Compare generated tag with passed in tag. */
- retval = crypto_memneq(src + tempCipherLen, authTag, auth_tag_len) ?
- -EBADMSG : 0;
+ retval = aesni_do_gcm_dec_tfm(aes_ctx, dst, src,
+ tempCipherLen, iv, ctx->hash_subkey,
+ assoc, req->assoclen - 8, authTag,
+ auth_tag_len);
- if (one_entry_in_sg) {
- if (unlikely(req->src != req->dst)) {
scatterwalk_unmap(dst - req->assoclen);
scatterwalk_advance(&dst_sg_walk, req->dst->length);
scatterwalk_done(&dst_sg_walk, 1, 0);
+ } else {
+ dst = src;
+ retval = aesni_do_gcm_dec_tfm(aes_ctx, dst, src,
+ tempCipherLen, iv, ctx->hash_subkey,
+ assoc, req->assoclen - 8, authTag,
+ auth_tag_len);
}
scatterwalk_unmap(assoc);
scatterwalk_advance(&src_sg_walk, req->src->length);
scatterwalk_done(&src_sg_walk, req->src == req->dst, 0);
} else {
+ /* Allocate memory for src, dst, assoc */
+ assoc = kmalloc(req->cryptlen + req->assoclen, GFP_ATOMIC);
+ if (!assoc)
+ return -ENOMEM;
+ scatterwalk_map_and_copy(assoc, req->src, 0,
+ req->assoclen + req->cryptlen, 0);
+ dst = src = assoc + req->assoclen;
+
+ retval = aesni_do_gcm_dec_tfm(aes_ctx, dst, src, tempCipherLen,
+ iv, ctx->hash_subkey, assoc,
+ req->assoclen - 8, authTag,
+ auth_tag_len);
+
scatterwalk_map_and_copy(dst, req->dst, req->assoclen,
tempCipherLen, 1);
kfree(assoc);
--
2.9.0
^ permalink raw reply related
* [PATCH 00/28] Reenable maybe-uninitialized warnings
From: Arnd Bergmann @ 2016-10-17 22:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-s390, linux-ext4, Herbert Xu, Arnd Bergmann, netdev, x86,
ceph-devel, linux-kernel, dri-devel, linux-f2fs-devel, linux-mtd,
linux-crypto, Greg Kroah-Hartman, Martin Schwidefsky,
netfilter-devel, Ilya Dryomov, Mauro Carvalho Chehab,
David S. Miller, linux-media
This is a set of patches that I hope to get into v4.9 in some form
in order to turn on the -Wmaybe-uninitialized warnings again.
After talking to Linus in person at Linaro Connect about this, I
spent some time on finding all the remaining warnings, and this
is the resulting patch series. More details are in the description
of the last patch that actually enables the warning.
Let me know if there are other warnings that I missed, and whether
you think these are still appropriate for v4.9 or not.
A couple of patches are non-obvious, and could use some more
detailed review.
Arnd
Arnd Bergmann (28):
[v2] netfilter: nf_tables: avoid uninitialized variable warning
[v2] mtd: mtk: avoid warning in mtk_ecc_encode
[v2] infiniband: shut up a maybe-uninitialized warning
f2fs: replace a build-time warning with runtime WARN_ON
ext2: avoid bogus -Wmaybe-uninitialized warning
NFSv4.1: work around -Wmaybe-uninitialized warning
ceph: avoid false positive maybe-uninitialized warning
staging: lustre: restore initialization of return code
staging: lustre: remove broken dead code in
cfs_cpt_table_create_pattern
UBI: fix uninitialized access of vid_hdr pointer
block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized
[media] rc: print correct variable for z8f0811
[media] dib0700: fix uninitialized data on 'repeat' event
iio: accel: sca3000_core: avoid potentially uninitialized variable
crypto: aesni: avoid -Wmaybe-uninitialized warning
pcmcia: fix return value of soc_pcmcia_regulator_set
spi: fsl-espi: avoid processing uninitalized data on error
drm: avoid uninitialized timestamp use in wait_vblank
brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
net: bcm63xx: avoid referencing uninitialized variable
net/hyperv: avoid uninitialized variable
x86: apm: avoid uninitialized data
x86: mark target address as output in 'insb' asm
x86: math-emu: possible uninitialized variable use
s390: pci: don't print uninitialized data for debugging
nios2: fix timer initcall return value
rocker: fix maybe-uninitialized warning
Kbuild: bring back -Wmaybe-uninitialized warning
Makefile | 10 +-
arch/arc/Makefile | 4 +-
arch/nios2/kernel/time.c | 1 +
arch/s390/pci/pci_dma.c | 2 +-
arch/x86/crypto/aesni-intel_glue.c | 121 +++++++++++++--------
arch/x86/include/asm/io.h | 4 +-
arch/x86/kernel/apm_32.c | 5 +-
arch/x86/math-emu/Makefile | 4 +-
arch/x86/math-emu/reg_compare.c | 16 +--
drivers/block/rbd.c | 1 +
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/infiniband/core/cma.c | 56 +++++-----
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
drivers/media/usb/dvb-usb/dib0700_core.c | 10 +-
drivers/mtd/nand/mtk_ecc.c | 19 ++--
drivers/mtd/ubi/eba.c | 2 +-
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 +-
drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 +-
drivers/net/hyperv/netvsc_drv.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
drivers/pcmcia/soc_common.c | 2 +-
drivers/spi/spi-fsl-espi.c | 2 +-
drivers/staging/iio/accel/sca3000_core.c | 2 +
.../staging/lustre/lnet/libcfs/linux/linux-cpu.c | 7 --
drivers/staging/lustre/lustre/lov/lov_pack.c | 2 +
fs/ceph/super.c | 3 +-
fs/ext2/inode.c | 7 +-
fs/f2fs/data.c | 7 ++
fs/nfs/nfs4session.c | 10 +-
net/netfilter/nft_range.c | 10 +-
scripts/Makefile.ubsan | 4 +
31 files changed, 187 insertions(+), 141 deletions(-)
--
Cc: x86@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-mtd@lists.infradead.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ceph-devel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: linux-ext4@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
2.9.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Stephan Mueller @ 2016-10-17 21:14 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, linux-crypto, linux-kernel@vger.kernel.org,
Matt Mackall, Herbert Xu, Rusty Russell, Jens Axboe, Matt Mullins
In-Reply-To: <CALCETrXGRf3z8gGw6fjeMCzb=X_OF6y0Rbhh-wAGjUVad8eaMg@mail.gmail.com>
Am Montag, 17. Oktober 2016, 14:03:17 CEST schrieb Andy Lutomirski:
Hi Andy,
> On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller <smueller@chronox.de>
wrote:
> > Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski:
> >
> > Hi Andy,
> >
> >> Sure, but shouldn't that be a separate patch covering the whole hw_crypto
> >> core?
> >
> > I think that you are right -- there are many more cases where a memset(0)
> > is warranted.
> >
> > Do you want to make this change or should I send a patch?
>
> Can you do it? I have my work cut out for me making sure that all the
> known regressions get stomped quickly...
Sure, will do.
Thanks.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Andy Lutomirski @ 2016-10-17 21:03 UTC (permalink / raw)
To: Stephan Mueller
Cc: Andy Lutomirski, linux-crypto, linux-kernel@vger.kernel.org,
Matt Mackall, Herbert Xu, Rusty Russell, Jens Axboe, Matt Mullins
In-Reply-To: <1709183.xhj4cRUFK9@tauon.atsec.com>
On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski:
>
> Hi Andy,
>>
>> Sure, but shouldn't that be a separate patch covering the whole hw_crypto
>> core?
>
> I think that you are right -- there are many more cases where a memset(0) is
> warranted.
>
> Do you want to make this change or should I send a patch?
Can you do it? I have my work cut out for me making sure that all the
known regressions get stomped quickly...
^ permalink raw reply
* Re: [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Javier Martinez Canillas @ 2016-10-17 19:53 UTC (permalink / raw)
To: Fabio Estevam
Cc: Herbert Xu, Neil Armstrong, Kevin Hilman,
PrasannaKumar Muralidharan, Marcel Selhorst, linux-kernel,
Jarkko Sakkinen, Jason Gunthorpe, tpmdd-devel, linux-crypto,
Matt Mackall, Carlo Caione, linux-amlogic, Peter Huewe,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOMZO5B+iDyNJ-heFU2Th-HQHocLS3Lz5zV7hFhiLs7ESJt2gw@mail.gmail.com>
Hello Fabio,
On 10/17/2016 04:45 PM, Fabio Estevam wrote:
> On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas
> <javier@osg.samsung.com> wrote:
>
>> --- a/drivers/char/tpm/Kconfig
>> +++ b/drivers/char/tpm/Kconfig
>> @@ -32,7 +32,7 @@ config TCG_TIS_CORE
>>
>> config TCG_TIS
>> tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO Interface"
>> - depends on X86
>> + depends on X86 || COMPILE_TEST
>
> This is a separate change.
>
Yes, I did a commit by mistake. Sorry about that.
Jason already pointed out and I posted a v2.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Javier Martinez Canillas @ 2016-10-17 19:51 UTC (permalink / raw)
To: linux-kernel
Cc: Jason Gunthorpe, Javier Martinez Canillas, Kevin Hilman,
Neil Armstrong, PrasannaKumar Muralidharan, Carlo Caione,
linux-amlogic, Herbert Xu, Matt Mackall, linux-arm-kernel,
linux-crypto
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias: platform:meson-rng
After this patch:
$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias: platform:meson-rng
alias: of:N*T*Camlogic,meson-rngC*
alias: of:N*T*Camlogic,meson-rng
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v2:
- Remove unrelated changes added by mistake. Suggested by Jason Gunthorpe.
drivers/char/hw_random/meson-rng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
index 58bef39f7286..51864a509be7 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
{ .compatible = "amlogic,meson-rng", },
{},
};
+MODULE_DEVICE_TABLE(of, meson_rng_of_match);
static struct platform_driver meson_rng_driver = {
.probe = meson_rng_probe,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Javier Martinez Canillas @ 2016-10-17 19:47 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-kernel, Jarkko Sakkinen, Marcel Selhorst, Peter Huewe,
Kevin Hilman, Neil Armstrong, tpmdd-devel,
PrasannaKumar Muralidharan, Carlo Caione, Herbert Xu,
linux-amlogic, Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <20161017194501.GD8122@obsidianresearch.com>
Hello Jason,
On 10/17/2016 04:45 PM, Jason Gunthorpe wrote:
> On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote:
>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>
>> drivers/char/hw_random/meson-rng.c | 1 +
>> drivers/char/tpm/Kconfig | 2 +-
>
> Looks like this patch should not have tpm in it.
>
Argh, yes. I had some unrelated changes in my staging area and did a
commit by mistake. Thanks a lot for pointing out and sorry for that.
I'll post a v2 without this.
> Jason
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Fabio Estevam @ 2016-10-17 19:45 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Herbert Xu, Neil Armstrong, Kevin Hilman,
Matt Mackall, Marcel Selhorst, Jarkko Sakkinen, Jason Gunthorpe,
tpmdd-devel, linux-crypto, PrasannaKumar Muralidharan,
Carlo Caione, linux-amlogic, Peter Huewe,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1476733214-19044-1-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -32,7 +32,7 @@ config TCG_TIS_CORE
>
> config TCG_TIS
> tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO Interface"
> - depends on X86
> + depends on X86 || COMPILE_TEST
This is a separate change.
^ permalink raw reply
* Re: [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Jason Gunthorpe @ 2016-10-17 19:45 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Herbert Xu, Neil Armstrong, Kevin Hilman, Matt Mackall,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, PrasannaKumar Muralidharan,
Carlo Caione, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1476733214-19044-1-git-send-email-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote:
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> drivers/char/hw_random/meson-rng.c | 1 +
> drivers/char/tpm/Kconfig | 2 +-
Looks like this patch should not have tpm in it.
Jason
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
^ permalink raw reply
* [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Javier Martinez Canillas @ 2016-10-17 19:40 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Jarkko Sakkinen, Marcel Selhorst,
Peter Huewe, Kevin Hilman, Neil Armstrong, tpmdd-devel,
PrasannaKumar Muralidharan, Carlo Caione, Jason Gunthorpe,
Herbert Xu, linux-amlogic, Matt Mackall, linux-arm-kernel,
linux-crypto
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias: platform:meson-rng
After this patch:
$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias: platform:meson-rng
alias: of:N*T*Camlogic,meson-rngC*
alias: of:N*T*Camlogic,meson-rng
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/char/hw_random/meson-rng.c | 1 +
drivers/char/tpm/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
index 58bef39f7286..51864a509be7 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
{ .compatible = "amlogic,meson-rng", },
{},
};
+MODULE_DEVICE_TABLE(of, meson_rng_of_match);
static struct platform_driver meson_rng_driver = {
.probe = meson_rng_probe,
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1e7766..982ed2fe927c 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -32,7 +32,7 @@ config TCG_TIS_CORE
config TCG_TIS
tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO Interface"
- depends on X86
+ depends on X86 || COMPILE_TEST
select TCG_TIS_CORE
---help---
If you have a TPM security chip that is compliant with the
--
2.7.4
^ permalink raw reply related
* Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Stephan Mueller @ 2016-10-17 18:36 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, linux-crypto, linux-kernel@vger.kernel.org,
Matt Mackall, Herbert Xu, Rusty Russell, Jens Axboe, Matt Mullins
In-Reply-To: <CALCETrVYuo1yNWyRQBRt3HwM4EJ7c5FAMZdEgnzKCHqMRCryXQ@mail.gmail.com>
Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski:
Hi Andy,
>
> Sure, but shouldn't that be a separate patch covering the whole hw_crypto
> core?
I think that you are right -- there are many more cases where a memset(0) is
warranted.
Do you want to make this change or should I send a patch?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Andy Lutomirski @ 2016-10-17 17:30 UTC (permalink / raw)
To: Stephan Mueller
Cc: Andy Lutomirski, linux-crypto, linux-kernel@vger.kernel.org,
Matt Mackall, Herbert Xu, Rusty Russell, Jens Axboe, Matt Mullins
In-Reply-To: <2711337.nAU4qxUyQs@tauon.atsec.com>
On Mon, Oct 17, 2016 at 10:17 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski:
>
> Hi Andy,
>
>> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
>> index 9203f2d130c0..340f96e44642 100644
>> --- a/drivers/char/hw_random/core.c
>> +++ b/drivers/char/hw_random/core.c
>> @@ -84,14 +84,14 @@ static size_t rng_buffer_size(void)
>>
>> static void add_early_randomness(struct hwrng *rng)
>> {
>> - unsigned char bytes[16];
>> int bytes_read;
>> + size_t size = min_t(size_t, 16, rng_buffer_size());
>>
>> mutex_lock(&reading_mutex);
>> - bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
>> + bytes_read = rng_get_data(rng, rng_buffer, size, 1);
>> mutex_unlock(&reading_mutex);
>> if (bytes_read > 0)
>> - add_device_randomness(bytes, bytes_read);
>> + add_device_randomness(rng_buffer, bytes_read);
>
> Shouldn't there be a memset(0) of the rng_buffer at this point to avoid having
> such data lingering in memory?
Sure, but shouldn't that be a separate patch covering the whole hw_crypto core?
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Stephan Mueller @ 2016-10-17 17:17 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-crypto, linux-kernel, Matt Mackall, Herbert Xu,
Rusty Russell, Jens Axboe, Matt Mullins
In-Reply-To: <4169224b6858d1cf149f1a73f8a03603fa19076d.1476638125.git.luto@kernel.org>
Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski:
Hi Andy,
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 9203f2d130c0..340f96e44642 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -84,14 +84,14 @@ static size_t rng_buffer_size(void)
>
> static void add_early_randomness(struct hwrng *rng)
> {
> - unsigned char bytes[16];
> int bytes_read;
> + size_t size = min_t(size_t, 16, rng_buffer_size());
>
> mutex_lock(&reading_mutex);
> - bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
> + bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> mutex_unlock(&reading_mutex);
> if (bytes_read > 0)
> - add_device_randomness(bytes, bytes_read);
> + add_device_randomness(rng_buffer, bytes_read);
Shouldn't there be a memset(0) of the rng_buffer at this point to avoid having
such data lingering in memory?
Ciao
Stephan
^ permalink raw reply
* [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Andy Lutomirski @ 2016-10-17 17:06 UTC (permalink / raw)
To: linux-crypto, linux-kernel, Matt Mackall, Herbert Xu,
Rusty Russell
Cc: Jens Axboe, Matt Mullins, Andy Lutomirski
hw_random carefully avoids using a stack buffer except in
add_early_randomness(). This causes a crash in virtio_rng if
CONFIG_VMAP_STACK=y.
Reported-by: Matt Mullins <mmullins@mmlx.us>
Tested-by: Matt Mullins <mmullins@mmlx.us>
Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
This fixes a crash in 4.9-rc1.
resending because I typoed the git send-email command. I stealthily added
Matt's Tested-by, too.
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d130c0..340f96e44642 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -84,14 +84,14 @@ static size_t rng_buffer_size(void)
static void add_early_randomness(struct hwrng *rng)
{
- unsigned char bytes[16];
int bytes_read;
+ size_t size = min_t(size_t, 16, rng_buffer_size());
mutex_lock(&reading_mutex);
- bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
+ bytes_read = rng_get_data(rng, rng_buffer, size, 1);
mutex_unlock(&reading_mutex);
if (bytes_read > 0)
- add_device_randomness(bytes, bytes_read);
+ add_device_randomness(rng_buffer, bytes_read);
}
static inline void cleanup_rng(struct kref *kref)
--
2.7.4
^ permalink raw reply related
* [PATCH -next] crypto: gcm - Fix error return code in crypto_gcm_create_common()
From: Wei Yongjun @ 2016-10-17 15:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -EINVAL from the invalid alg ivsize error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
crypto/gcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/gcm.c b/crypto/gcm.c
index f624ac9..39c261d 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -672,11 +672,11 @@ static int crypto_gcm_create_common(struct crypto_template *tmpl,
ctr = crypto_spawn_skcipher_alg(&ctx->ctr);
/* We only support 16-byte blocks. */
+ err = -EINVAL;
if (crypto_skcipher_alg_ivsize(ctr) != 16)
goto out_put_ctr;
/* Not a stream cipher? */
- err = -EINVAL;
if (ctr->base.cra_blocksize != 1)
goto out_put_ctr;
^ permalink raw reply related
* [PATCH -next] crypto: ccp - Fix non static symbol warning
From: Wei Yongjun @ 2016-10-17 15:08 UTC (permalink / raw)
To: Tom Lendacky, Gary Hook, Herbert Xu; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/crypto/ccp/ccp-dev.c:44:6: warning:
symbol 'ccp_error_codes' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/ccp/ccp-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index cafa633..c25515a 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -41,7 +41,7 @@ struct ccp_tasklet_data {
};
/* Human-readable error strings */
-char *ccp_error_codes[] = {
+static char *ccp_error_codes[] = {
"",
"ERR 01: ILLEGAL_ENGINE",
"ERR 02: ILLEGAL_KEY_ID",
^ permalink raw reply related
* Re: [PATCH 4/7] crypto: doc - fix separation of cipher / req API
From: Jani Nikula @ 2016-10-17 13:20 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert, linux-crypto, linux-doc
In-Reply-To: <2825279.IxJ3MjTap5@positron.chronox.de>
On Mon, 17 Oct 2016, Stephan Mueller <smueller@chronox.de> wrote:
> Am Montag, 17. Oktober 2016, 14:04:14 CEST schrieb Jani Nikula:
>
> Hi Jani,
>
>> The directive parameter is plural functions for a reason - you can
>> specify multiple functions in the same directive. Splitting this to
>> multiple directives causes the header file to be parsed again for each
>> directive.
>>
>> IMO this can be fixed in a follow-up patch. Same for other patches in
>> this series.
>
> Thank you very much for the hint. I followed the path what the DocBook
> to Sphinx converter generated. I will change it in my patchset, but
> may I suggest that the converter tool (tmplcvt) should be fixed, too?
I don't think it's worth the trouble.
Now it's a straightforward docproc directive to Sphinx kernel-doc
directive extension conversion, with one-to-one mapping. It would be
quite a bit more complicated to gather all of the consecutive directives
together, in a rather quickly hacked up tool which we'll throw away once
all DocBooks have been converted over.
And as I said, I think you can fix this up afterwards too. It's not
broken, it's just a bit slower.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 4/7] crypto: doc - fix separation of cipher / req API
From: Stephan Mueller @ 2016-10-17 12:35 UTC (permalink / raw)
To: Jani Nikula; +Cc: herbert, linux-crypto, linux-doc
In-Reply-To: <87h98btexd.fsf@intel.com>
Am Montag, 17. Oktober 2016, 14:04:14 CEST schrieb Jani Nikula:
Hi Jani,
> The directive parameter is plural functions for a reason - you can
> specify multiple functions in the same directive. Splitting this to
> multiple directives causes the header file to be parsed again for each
> directive.
>
> IMO this can be fixed in a follow-up patch. Same for other patches in
> this series.
Thank you very much for the hint. I followed the path what the DocBook to
Sphinx converter generated. I will change it in my patchset, but may I suggest
that the converter tool (tmplcvt) should be fixed, too?
Ciao
Stephan
^ permalink raw reply
* [RESEND][PATCH] crypto: caam: add support for iMX6UL
From: Marcus Folkesson @ 2016-10-17 11:28 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Horia Geanta, Arnd Bergmann, Alex Porosanu, Srinivas Kandagatla,
Baoyou Xie, Russell King
Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marcus Folkesson
i.MX6UL does only require three clocks to enable CAAM module.
Signed-off-by: Marcus Folkesson <marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Horia Geantă <horia.geanta-3arQi8VN3Tc@public.gmane.org>
---
.../devicetree/bindings/crypto/fsl-sec4.txt | 20 +++++++++++++
drivers/crypto/caam/ctrl.c | 35 ++++++++++++----------
2 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index adeca34..10a425f 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -123,6 +123,9 @@ PROPERTIES
EXAMPLE
+
+iMX6QDL/SX requires four clocks
+
crypto@300000 {
compatible = "fsl,sec-v4.0";
fsl,sec-era = <2>;
@@ -139,6 +142,23 @@ EXAMPLE
clock-names = "mem", "aclk", "ipg", "emi_slow";
};
+
+iMX6UL does only require three clocks
+
+ crypto: caam@2140000 {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x2140000 0x3c000>;
+ ranges = <0 0x2140000 0x3c000>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
+ <&clks IMX6UL_CLK_CAAM_ACLK>,
+ <&clks IMX6UL_CLK_CAAM_IPG>;
+ clock-names = "mem", "aclk", "ipg";
+ };
+
=====================================================================
Job Ring (JR) Node
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112e..5abaf37 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -329,8 +329,8 @@ static int caam_remove(struct platform_device *pdev)
clk_disable_unprepare(ctrlpriv->caam_ipg);
clk_disable_unprepare(ctrlpriv->caam_mem);
clk_disable_unprepare(ctrlpriv->caam_aclk);
- clk_disable_unprepare(ctrlpriv->caam_emi_slow);
-
+ if (!of_machine_is_compatible("fsl,imx6ul"))
+ clk_disable_unprepare(ctrlpriv->caam_emi_slow);
return 0;
}
@@ -481,14 +481,16 @@ static int caam_probe(struct platform_device *pdev)
}
ctrlpriv->caam_aclk = clk;
- clk = caam_drv_identify_clk(&pdev->dev, "emi_slow");
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
- dev_err(&pdev->dev,
- "can't identify CAAM emi_slow clk: %d\n", ret);
- return ret;
+ if (!of_machine_is_compatible("fsl,imx6ul")) {
+ clk = caam_drv_identify_clk(&pdev->dev, "emi_slow");
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+ dev_err(&pdev->dev,
+ "can't identify CAAM emi_slow clk: %d\n", ret);
+ return ret;
+ }
+ ctrlpriv->caam_emi_slow = clk;
}
- ctrlpriv->caam_emi_slow = clk;
ret = clk_prepare_enable(ctrlpriv->caam_ipg);
if (ret < 0) {
@@ -509,11 +511,13 @@ static int caam_probe(struct platform_device *pdev)
goto disable_caam_mem;
}
- ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
- if (ret < 0) {
- dev_err(&pdev->dev, "can't enable CAAM emi slow clock: %d\n",
- ret);
- goto disable_caam_aclk;
+ if (!of_machine_is_compatible("fsl,imx6ul")) {
+ ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "can't enable CAAM emi slow clock: %d\n",
+ ret);
+ goto disable_caam_aclk;
+ }
}
/* Get configuration properties from device tree */
@@ -829,7 +833,8 @@ caam_remove:
iounmap_ctrl:
iounmap(ctrl);
disable_caam_emi_slow:
- clk_disable_unprepare(ctrlpriv->caam_emi_slow);
+ if (!of_machine_is_compatible("fsl,imx6ul"))
+ clk_disable_unprepare(ctrlpriv->caam_emi_slow);
disable_caam_aclk:
clk_disable_unprepare(ctrlpriv->caam_aclk);
disable_caam_mem:
--
2.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 4/7] crypto: doc - fix separation of cipher / req API
From: Jani Nikula @ 2016-10-17 11:04 UTC (permalink / raw)
To: Stephan Mueller, herbert; +Cc: linux-crypto, linux-doc
In-Reply-To: <5908263.2TLWr89bHl@positron.chronox.de>
On Sun, 16 Oct 2016, Stephan Mueller <smueller@chronox.de> wrote:
> Keep the cipher API and the request API function documentation in
> separate sections.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
> Documentation/crypto/api-akcipher.rst | 25 +++++++++++++------------
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/crypto/api-akcipher.rst b/Documentation/crypto/api-akcipher.rst
> index 305e616..0d5899f 100644
> --- a/Documentation/crypto/api-akcipher.rst
> +++ b/Documentation/crypto/api-akcipher.rst
> @@ -25,32 +25,32 @@ Asymmetric Cipher API
> .. kernel-doc:: include/crypto/akcipher.h
> :functions: crypto_akcipher_set_priv_key
>
> -Asymmetric Cipher Request Handle
> ---------------------------------
> -
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: akcipher_request_alloc
> + :functions: crypto_akcipher_maxsize
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: akcipher_request_free
> + :functions: crypto_akcipher_encrypt
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: akcipher_request_set_callback
> + :functions: crypto_akcipher_decrypt
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: akcipher_request_set_crypt
> + :functions: crypto_akcipher_sign
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: crypto_akcipher_maxsize
> + :functions: crypto_akcipher_verify
The directive parameter is plural functions for a reason - you can
specify multiple functions in the same directive. Splitting this to
multiple directives causes the header file to be parsed again for each
directive.
IMO this can be fixed in a follow-up patch. Same for other patches in
this series.
BR,
Jani.
> +
> +Asymmetric Cipher Request Handle
> +--------------------------------
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: crypto_akcipher_encrypt
> + :functions: akcipher_request_alloc
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: crypto_akcipher_decrypt
> + :functions: akcipher_request_free
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: crypto_akcipher_sign
> + :functions: akcipher_request_set_callback
>
> .. kernel-doc:: include/crypto/akcipher.h
> - :functions: crypto_akcipher_verify
> + :functions: akcipher_request_set_crypt
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] padata: Remove unused but set variables
From: Tobias Klauser @ 2016-10-17 10:16 UTC (permalink / raw)
To: Steffen Klassert; +Cc: linux-crypto, linux-kernel
Remove the unused but set variable pinst in padata_parallel_worker to
fix the following warning when building with 'W=1':
kernel/padata.c: In function ‘padata_parallel_worker’:
kernel/padata.c:68:26: warning: variable ‘pinst’ set but not used [-Wunused-but-set-variable]
Also remove the now unused variable pd which is only used to set pinst.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
kernel/padata.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 7848f0566403..05316c9f32da 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -64,15 +64,11 @@ static int padata_cpu_hash(struct parallel_data *pd)
static void padata_parallel_worker(struct work_struct *parallel_work)
{
struct padata_parallel_queue *pqueue;
- struct parallel_data *pd;
- struct padata_instance *pinst;
LIST_HEAD(local_list);
local_bh_disable();
pqueue = container_of(parallel_work,
struct padata_parallel_queue, work);
- pd = pqueue->pd;
- pinst = pd->pinst;
spin_lock(&pqueue->parallel.lock);
list_replace_init(&pqueue->parallel.list, &local_list);
--
2.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox