* Re: [PATCH 7/7] crypto: doc - clarify AEAD memory structure
From: Stephan Mueller @ 2016-10-16 13:20 UTC (permalink / raw)
To: Markus Heiser; +Cc: herbert, linux-crypto, linux-doc, Harsh Jain
In-Reply-To: <62B7147E-395E-4615-AB9D-DA6B3E932FCD@darmarit.de>
Am Sonntag, 16. Oktober 2016, 15:11:38 CEST schrieb Markus Heiser:
Hi Markus,
> These are only my 2cent in hope that helps ... there is no rule
> to use any special markup ... use markup as you prefer ;-)
Thanks for the pointers. I will release a new patch set following your
suggestions after others had the chance to review and comment.
Thanks!
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 3/7] crypto: doc - fix source comments for Sphinx
From: Markus Heiser @ 2016-10-16 13:42 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert, linux-crypto, linux-doc
In-Reply-To: <2972819.9tl40PCxdP@positron.chronox.de>
Am 16.10.2016 um 15:03 schrieb Stephan Mueller <smueller@chronox.de>:
> Am Sonntag, 16. Oktober 2016, 14:56:49 CEST schrieb Markus Heiser:
>
> Hi Markus,
> ...
>
>> compared to DocBook, with sphinx you can use (have to use) the reST markup
>> in source code comments.
>>
>> Here, the code example is just a (indented) float text and this is
>> why you have to quote the asterisk "\*req,".
>
> Is there any preferred / suggested way whether to use literal or highlighted
> (or even my approach on) formatting?
No. IMO the "::" markup for code blocks is a good compromise. It is not
to verbose and prevents you quoting frequent asterisk in code examples.
--Markus--
> Ciao
> Stephan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: virtio-rng scatterlist null pointer dereference with VMAP_STACK=y
From: Andy Lutomirski @ 2016-10-16 16:59 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Andy Lutomirski, linux-crypto,
Matt Mackall, Herbert Xu, Rusty Russell, Jens Axboe, Dave Gordon
In-Reply-To: <20161016002151.GA18235@hydra.tuxags.com>
On Sat, Oct 15, 2016 at 5:21 PM, Matt Mullins <mmullins@mmlx.us> wrote:
> With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash:
>
> [ 1.470437] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 1.473350] IP: [<ffffffff812f7c35>] sg_init_one+0x65/0x90
> [ 1.474658] PGD 0
> [ 1.475169] Oops: 0000 [#1] SMP
>
> Entering kdb (current=0xffff880069b0c980, pid 1) on processor 1 Oops: (null)
> due to oops @ 0xffffffff812f7c35
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-08682-g41844e3 #246
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff880069b0c980 task.stack: ffffc90000c54000
> RIP: 0010:[<ffffffff812f7c35>] [<ffffffff812f7c35>] sg_init_one+0x65/0x90
> RSP: 0000:ffffc90000c57d00 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffffc90000c57d20 RCX: 0000000000082000
> RDX: 0000000000000d68 RSI: 0000000410000c57 RDI: ffffc90000c57d40
> RBP: 0000000000000820 R08: 0000000000000000 R09: ffffc90000c57d20
> R10: 0000000000019228 R11: ffff88017fff8500 R12: 0000000000000010
> R13: 0000000000000010 R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000001806000 CR4: 00000000001406a0
> Stack:
> ffff8800694bf500 0000000000000001 ffffc90000c57d68 ffffffff8138286f
> 0000000000000002 0000000000000000 0000000000000000 0000000000000000
> ffff8800694bf500 ffffc90000c57d68 ffff8800694bf500 0000000000000000
> Call Trace:
> [<ffffffff8138286f>] ? virtio_read+0x9f/0xe0
> [<ffffffff81381ade>] ? add_early_randomness+0x3e/0xa0
> [<ffffffff813820af>] ? set_current_rng+0x3f/0x160
> [<ffffffff81382416>] ? hwrng_register+0x186/0x1d0
> [<ffffffff81382620>] ? virtrng_scan+0x10/0x20
> [<ffffffff8135790e>] ? virtio_dev_probe+0x21e/0x2b0
> [<ffffffff8138789e>] ? really_probe+0x14e/0x250
> [<ffffffff81387a22>] ? __driver_attach+0x82/0xa0
> [<ffffffff813879a0>] ? really_probe+0x250/0x250
> [<ffffffff81385d22>] ? bus_for_each_dev+0x52/0x80
> [<ffffffff81387093>] ? bus_add_driver+0x1a3/0x220
> [<ffffffff818b0634>] ? hwrng_modinit+0xc/0xc
> [<ffffffff81388046>] ? driver_register+0x56/0xd0
> [<ffffffff818b0634>] ? hwrng_modinit+0xc/0xc
> [<ffffffff810003c2>] ? do_one_initcall+0x32/0x150
> [<ffffffff81095900>] ? parse_args+0x170/0x390
> [<ffffffff8188a188>] ? kernel_init_freeable+0x11e/0x1a3
> [<ffffffff818898f4>] ? set_debug_rodata+0xc/0xc
> [<ffffffff8157d930>] ? rest_init+0x70/0x70
> [<ffffffff8157d935>] ? kernel_init+0x5/0x100
> [<ffffffff81582625>] ? ret_from_fork+0x25/0x30
> Code: 01 c5 48 89 ee 48 89 e9 48 c1 ed 23 48 8b 04 ed c0 49 9c 81 48 c1 ee 0c
> 48 c1 e9 1b 48 85 c0 74 0a 0f b6 c9 48 c1 e1 04 48 01 c8 <48> 8b 08 48 89 f0 89
> 53 08 48 c1 e0 06 44 89 63 0c 48 83 e1 fc
>
>
> It looks like add_early_randomness() uses a buffer on the stack, which (with
> VMAP_STACK) fails to be added to a scatterlist due to use of virt_to_page in
> sg_set_buf().
>
> None of this looks obviously wrong to me, but in combination it is not
> functional. Hence, I don't have a particular fix in mind, and I've CC'ed folks
> from both the hw_random and scatterlist history.
Using a buffer on the stack is bogus here. Presumably virtio_read
should allocate a heap buffer.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: virtio-rng scatterlist null pointer dereference with VMAP_STACK=y
From: Andy Lutomirski @ 2016-10-16 17:11 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Andy Lutomirski, linux-crypto,
Matt Mackall, Herbert Xu, Rusty Russell, Jens Axboe
In-Reply-To: <CALCETrV6dT7dB1+KkHEo2V_kpO1STWBY196VUPRSVAZCQiJeOQ@mail.gmail.com>
On Sun, Oct 16, 2016 at 9:59 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Sat, Oct 15, 2016 at 5:21 PM, Matt Mullins <mmullins@mmlx.us> wrote:
>> With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash:
>>
>> [ 1.470437] BUG: unable to handle kernel NULL pointer dereference at (null)
>> [ 1.473350] IP: [<ffffffff812f7c35>] sg_init_one+0x65/0x90
>> [ 1.474658] PGD 0
>> [ 1.475169] Oops: 0000 [#1] SMP
>>
>> Entering kdb (current=0xffff880069b0c980, pid 1) on processor 1 Oops: (null)
>> due to oops @ 0xffffffff812f7c35
>> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-08682-g41844e3 #246
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff880069b0c980 task.stack: ffffc90000c54000
>> RIP: 0010:[<ffffffff812f7c35>] [<ffffffff812f7c35>] sg_init_one+0x65/0x90
>> RSP: 0000:ffffc90000c57d00 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: ffffc90000c57d20 RCX: 0000000000082000
>> RDX: 0000000000000d68 RSI: 0000000410000c57 RDI: ffffc90000c57d40
>> RBP: 0000000000000820 R08: 0000000000000000 R09: ffffc90000c57d20
>> R10: 0000000000019228 R11: ffff88017fff8500 R12: 0000000000000010
>> R13: 0000000000000010 R14: 0000000000000000 R15: 0000000000000000
>> FS: 0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000000000 CR3: 0000000001806000 CR4: 00000000001406a0
>> Stack:
>> ffff8800694bf500 0000000000000001 ffffc90000c57d68 ffffffff8138286f
>> 0000000000000002 0000000000000000 0000000000000000 0000000000000000
>> ffff8800694bf500 ffffc90000c57d68 ffff8800694bf500 0000000000000000
>> Call Trace:
>> [<ffffffff8138286f>] ? virtio_read+0x9f/0xe0
>> [<ffffffff81381ade>] ? add_early_randomness+0x3e/0xa0
>> [<ffffffff813820af>] ? set_current_rng+0x3f/0x160
>> [<ffffffff81382416>] ? hwrng_register+0x186/0x1d0
>> [<ffffffff81382620>] ? virtrng_scan+0x10/0x20
>> [<ffffffff8135790e>] ? virtio_dev_probe+0x21e/0x2b0
>> [<ffffffff8138789e>] ? really_probe+0x14e/0x250
>> [<ffffffff81387a22>] ? __driver_attach+0x82/0xa0
>> [<ffffffff813879a0>] ? really_probe+0x250/0x250
>> [<ffffffff81385d22>] ? bus_for_each_dev+0x52/0x80
>> [<ffffffff81387093>] ? bus_add_driver+0x1a3/0x220
>> [<ffffffff818b0634>] ? hwrng_modinit+0xc/0xc
>> [<ffffffff81388046>] ? driver_register+0x56/0xd0
>> [<ffffffff818b0634>] ? hwrng_modinit+0xc/0xc
>> [<ffffffff810003c2>] ? do_one_initcall+0x32/0x150
>> [<ffffffff81095900>] ? parse_args+0x170/0x390
>> [<ffffffff8188a188>] ? kernel_init_freeable+0x11e/0x1a3
>> [<ffffffff818898f4>] ? set_debug_rodata+0xc/0xc
>> [<ffffffff8157d930>] ? rest_init+0x70/0x70
>> [<ffffffff8157d935>] ? kernel_init+0x5/0x100
>> [<ffffffff81582625>] ? ret_from_fork+0x25/0x30
>> Code: 01 c5 48 89 ee 48 89 e9 48 c1 ed 23 48 8b 04 ed c0 49 9c 81 48 c1 ee 0c
>> 48 c1 e9 1b 48 85 c0 74 0a 0f b6 c9 48 c1 e1 04 48 01 c8 <48> 8b 08 48 89 f0 89
>> 53 08 48 c1 e0 06 44 89 63 0c 48 83 e1 fc
>>
>>
>> It looks like add_early_randomness() uses a buffer on the stack, which (with
>> VMAP_STACK) fails to be added to a scatterlist due to use of virt_to_page in
>> sg_set_buf().
>>
>> None of this looks obviously wrong to me, but in combination it is not
>> functional. Hence, I don't have a particular fix in mind, and I've CC'ed folks
>> from both the hw_random and scatterlist history.
>
> Using a buffer on the stack is bogus here. Presumably virtio_read
> should allocate a heap buffer.
On second thought, this clearly belongs in the core code. Patch coming.
^ permalink raw reply
* Re: [PATCH 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Matt Mullins @ 2016-10-16 21:19 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Jens Axboe, Matt Mullins, linux-crypto
In-Reply-To: <4169224b6858d1cf149f1a73f8a03603fa19076d.1476638125.git.luto@kernel.org>
On Sun, Oct 16, 2016 at 10:17:15AM -0700, Andy Lutomirski wrote:
> 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.
I hadn't noticed the existing kmalloc in the __init, for the explicit purpose
of virt_to_page().
This boots on the VM from which I had grabbed the stack trace yesterday.
Tested-by: Matt Mullins <mmullins@mmlx.us>
Looks like an extra quote snuck in your To: line, so I'm not sure if this was
distributed as widely as you intended.
^ 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
* 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
* [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: 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
* 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
* [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
* [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 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
* 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
* 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 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
* [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] 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
* 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: 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
* [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: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
* 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 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
* [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
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