- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "IB/mlx5: Assign send CQ and recv CQ of UMR QP" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx5: Assign send CQ and recv CQ of UMR QP to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Majd Dibbiny <majd(a)mellanox.com> Date: Mon, 30 Oct 2017 14:23:13 +0200 Subject: IB/mlx5: Assign send CQ and recv CQ of UMR QP From: Majd Dibbiny <majd(a)mellanox.com> [ Upstream commit 31fde034a8bd964a5c7c1a5663fc87a913158db2 ] The UMR's QP is created by calling mlx5_ib_create_qp directly, and therefore the send CQ and the recv CQ on the ibqp weren't assigned. Assign them right after calling the mlx5_ib_create_qp to assure that any access to those pointers will work as expected and won't crash the system as might happen as part of reset flow. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Majd Dibbiny <majd(a)mellanox.com> Reviewed-by: Yishai Hadas <yishaih(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/main.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/hw/mlx5/main.c +++ b/drivers/infiniband/hw/mlx5/main.c @@ -1099,6 +1099,8 @@ static int create_umr_res(struct mlx5_ib qp->real_qp = qp; qp->uobject = NULL; qp->qp_type = MLX5_IB_QPT_REG_UMR; + qp->send_cq = init_attr->send_cq; + qp->recv_cq = init_attr->recv_cq; attr->qp_state = IB_QPS_INIT; attr->port_num = 1; Patches currently in stable-queue which might be from majd(a)mellanox.com are queue-3.18/ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.patch queue-3.18/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "IB/mlx4: Increase maximal message size under UD QP" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Increase maximal message size under UD QP to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-increase-maximal-message-size-under-ud-qp.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Mark Bloch <markb(a)mellanox.com> Date: Thu, 2 Nov 2017 15:22:26 +0200 Subject: IB/mlx4: Increase maximal message size under UD QP From: Mark Bloch <markb(a)mellanox.com> [ Upstream commit 5f22a1d87c5315a98981ecf93cd8de226cffe6ca ] Maximal message should be used as a limit to the max message payload allowed, without the headers. The ConnectX-3 check is done against this value includes the headers. When the payload is 4K this will cause the NIC to drop packets. Increase maximal message to 8K as workaround, this shouldn't change current behaviour because we continue to set the MTU to 4k. To reproduce; set MTU to 4296 on the corresponding interface, for example: ifconfig eth0 mtu 4296 (both server and client) On server: ib_send_bw -c UD -d mlx4_0 -s 4096 -n 1000000 -i1 -m 4096 On client: ib_send_bw -d mlx4_0 -c UD <server_ip> -s 4096 -n 1000000 -i 1 -m 4096 Fixes: 6e0d733d9215 ("IB/mlx4: Allow 4K messages for UD QPs") Signed-off-by: Mark Bloch <markb(a)mellanox.com> Reviewed-by: Majd Dibbiny <majd(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/qp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/mlx4/qp.c +++ b/drivers/infiniband/hw/mlx4/qp.c @@ -1465,7 +1465,7 @@ static int __mlx4_ib_modify_qp(struct ib context->mtu_msgmax = (IB_MTU_4096 << 5) | ilog2(dev->dev->caps.max_gso_sz); else - context->mtu_msgmax = (IB_MTU_4096 << 5) | 12; + context->mtu_msgmax = (IB_MTU_4096 << 5) | 13; } else if (attr_mask & IB_QP_PATH_MTU) { if (attr->path_mtu < IB_MTU_256 || attr->path_mtu > IB_MTU_4096) { pr_err("path MTU (%u) is invalid\n", Patches currently in stable-queue which might be from markb(a)mellanox.com are queue-3.18/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: edac-i5000-i5400-fix-use-of-mtr_dram_width-macro.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Jérémy Lefaure <jeremy.lefaure(a)lse.epita.fr> Date: Wed, 8 Mar 2017 20:18:09 -0500 Subject: EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro From: Jérémy Lefaure <jeremy.lefaure(a)lse.epita.fr> [ Upstream commit e61555c29c28a4a3b6ba6207f4a0883ee236004d ] The MTR_DRAM_WIDTH macro returns the data width. It is sometimes used as if it returned a boolean true if the width if 8. Fix the tests where MTR_DRAM_WIDTH is misused. Signed-off-by: JÃ©rÃ©my Lefaure <jeremy.lefaure(a)lse.epita.fr> Cc: linux-edac <linux-edac(a)vger.kernel.org> Link: http://lkml.kernel.org/r/20170309011809.8340-1-jeremy.lefaure@lse.epita.fr Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/i5000_edac.c | 2 +- drivers/edac/i5400_edac.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) --- a/drivers/edac/i5000_edac.c +++ b/drivers/edac/i5000_edac.c @@ -1293,7 +1293,7 @@ static int i5000_init_csrows(struct mem_ dimm->mtype = MEM_FB_DDR2; /* ask what device type on this row */ - if (MTR_DRAM_WIDTH(mtr)) + if (MTR_DRAM_WIDTH(mtr) == 8) dimm->dtype = DEV_X8; else dimm->dtype = DEV_X4; --- a/drivers/edac/i5400_edac.c +++ b/drivers/edac/i5400_edac.c @@ -1207,13 +1207,14 @@ static int i5400_init_dimms(struct mem_c dimm->nr_pages = size_mb << 8; dimm->grain = 8; - dimm->dtype = MTR_DRAM_WIDTH(mtr) ? DEV_X8 : DEV_X4; + dimm->dtype = MTR_DRAM_WIDTH(mtr) == 8 ? + DEV_X8 : DEV_X4; dimm->mtype = MEM_FB_DDR2; /* * The eccc mechanism is SDDC (aka SECC), with * is similar to Chipkill. */ - dimm->edac_mode = MTR_DRAM_WIDTH(mtr) ? + dimm->edac_mode = MTR_DRAM_WIDTH(mtr) == 8 ? EDAC_S8ECD8ED : EDAC_S4ECD4ED; ndimms++; } Patches currently in stable-queue which might be from jeremy.lefaure(a)lse.epita.fr are queue-3.18/edac-i5000-i5400-fix-definition-of-nrecmemb-register.patch queue-3.18/edac-i5000-i5400-fix-use-of-mtr_dram_width-macro.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "EDAC, i5000, i5400: Fix definition of NRECMEMB register" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled EDAC, i5000, i5400: Fix definition of NRECMEMB register to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: edac-i5000-i5400-fix-definition-of-nrecmemb-register.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Jérémy Lefaure <jeremy.lefaure(a)lse.epita.fr> Date: Wed, 28 Jun 2017 20:57:29 -0400 Subject: EDAC, i5000, i5400: Fix definition of NRECMEMB register From: Jérémy Lefaure <jeremy.lefaure(a)lse.epita.fr> [ Upstream commit a8c8261425649da58bdf08221570e5335ad33a31 ] In the i5000 and i5400 drivers, the NRECMEMB register is defined as a 16-bit value, which results in wrong shifts in the code, as reported by sparse. In the datasheets ([1], section 3.9.22.20 and [2], section 3.9.22.21), this register is a 32-bit register. A u32 value for the register fixes the wrong shifts warnings and matches the datasheet. Also fix the mask to access to the CAS bits [27:16] in the i5000 driver. [1]: https://www.intel.com/content/dam/doc/datasheet/5000p-5000v-5000z-chipset-m… [2]: https://www.intel.se/content/dam/doc/datasheet/5400-chipset-memory-controll… Signed-off-by: JÃ©rÃ©my Lefaure <jeremy.lefaure(a)lse.epita.fr> Cc: linux-edac <linux-edac(a)vger.kernel.org> Link: http://lkml.kernel.org/r/20170629005729.8478-1-jeremy.lefaure@lse.epita.fr Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/i5000_edac.c | 6 +++--- drivers/edac/i5400_edac.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) --- a/drivers/edac/i5000_edac.c +++ b/drivers/edac/i5000_edac.c @@ -227,7 +227,7 @@ #define NREC_RDWR(x) (((x)>>11) & 1) #define NREC_RANK(x) (((x)>>8) & 0x7) #define NRECMEMB 0xC0 -#define NREC_CAS(x) (((x)>>16) & 0xFFFFFF) +#define NREC_CAS(x) (((x)>>16) & 0xFFF) #define NREC_RAS(x) ((x) & 0x7FFF) #define NRECFGLOG 0xC4 #define NREEECFBDA 0xC8 @@ -371,7 +371,7 @@ struct i5000_error_info { /* These registers are input ONLY if there was a * Non-Recoverable Error */ u16 nrecmema; /* Non-Recoverable Mem log A */ - u16 nrecmemb; /* Non-Recoverable Mem log B */ + u32 nrecmemb; /* Non-Recoverable Mem log B */ }; @@ -407,7 +407,7 @@ static void i5000_get_error_info(struct NERR_FAT_FBD, &info->nerr_fat_fbd); pci_read_config_word(pvt->branchmap_werrors, NRECMEMA, &info->nrecmema); - pci_read_config_word(pvt->branchmap_werrors, + pci_read_config_dword(pvt->branchmap_werrors, NRECMEMB, &info->nrecmemb); /* Clear the error bits, by writing them back */ --- a/drivers/edac/i5400_edac.c +++ b/drivers/edac/i5400_edac.c @@ -368,7 +368,7 @@ struct i5400_error_info { /* These registers are input ONLY if there was a Non-Rec Error */ u16 nrecmema; /* Non-Recoverable Mem log A */ - u16 nrecmemb; /* Non-Recoverable Mem log B */ + u32 nrecmemb; /* Non-Recoverable Mem log B */ }; @@ -458,7 +458,7 @@ static void i5400_get_error_info(struct NERR_FAT_FBD, &info->nerr_fat_fbd); pci_read_config_word(pvt->branchmap_werrors, NRECMEMA, &info->nrecmema); - pci_read_config_word(pvt->branchmap_werrors, + pci_read_config_dword(pvt->branchmap_werrors, NRECMEMB, &info->nrecmemb); /* Clear the error bits, by writing them back */ Patches currently in stable-queue which might be from jeremy.lefaure(a)lse.epita.fr are queue-3.18/edac-i5000-i5400-fix-definition-of-nrecmemb-register.patch queue-3.18/edac-i5000-i5400-fix-use-of-mtr_dram_width-macro.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "i2c: riic: fix restart condition" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i2c: riic: fix restart condition to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: i2c-riic-fix-restart-condition.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Chris Brandt <chris.brandt(a)renesas.com> Date: Mon, 6 Mar 2017 15:20:51 -0500 Subject: i2c: riic: fix restart condition From: Chris Brandt <chris.brandt(a)renesas.com> [ Upstream commit 2501c1bb054290679baad0ff7f4f07c714251f4c ] While modifying the driver to use the STOP interrupt, the completion of the intermediate transfers need to wake the driver back up in order to initiate the next transfer (restart condition). Otherwise you get never ending interrupts and only the first transfer sent. Fixes: 71ccea095ea1 ("i2c: riic: correctly finish transfers") Reported-by: Simon Horman <horms(a)verge.net.au> Signed-off-by: Chris Brandt <chris.brandt(a)renesas.com> Tested-by: Simon Horman <horms+renesas(a)verge.net.au> Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/i2c/busses/i2c-riic.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-riic.c +++ b/drivers/i2c/busses/i2c-riic.c @@ -218,8 +218,12 @@ static irqreturn_t riic_tend_isr(int irq } if (riic->is_last || riic->err) { - riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER); + riic_clear_set_bit(riic, ICIER_TEIE, ICIER_SPIE, RIIC_ICIER); writeb(ICCR2_SP, riic->base + RIIC_ICCR2); + } else { + /* Transfer is complete, but do not send STOP */ + riic_clear_set_bit(riic, ICIER_TEIE, 0, RIIC_ICIER); + complete(&riic->msg_done); } return IRQ_HANDLED; Patches currently in stable-queue which might be from chris.brandt(a)renesas.com are queue-3.18/i2c-riic-fix-restart-condition.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: s5p-sss - Fix completing crypto request in IRQ handler" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: s5p-sss - Fix completing crypto request in IRQ handler to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Krzysztof Kozlowski <krzk(a)kernel.org> Date: Sun, 5 Mar 2017 19:14:07 +0200 Subject: crypto: s5p-sss - Fix completing crypto request in IRQ handler From: Krzysztof Kozlowski <krzk(a)kernel.org> [ Upstream commit 07de4bc88ce6a4d898cad9aa4c99c1df7e87702d ] In a regular interrupt handler driver was finishing the crypt/decrypt request by calling complete on crypto request. This is disallowed since converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface") and causes a warning: WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 skcipher_walk_first+0x13c/0x14c The interrupt is marked shared but in fact there are no other users sharing it. Thus the simplest solution seems to be to just use a threaded interrupt handler, after converting it to oneshot. Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/s5p-sss.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -682,8 +682,9 @@ static int s5p_aes_probe(struct platform dev_warn(dev, "feed control interrupt is not available.\n"); goto err_irq; } - err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt, - IRQF_SHARED, pdev->name, pdev); + err = devm_request_threaded_irq(dev, pdata->irq_fc, NULL, + s5p_aes_interrupt, IRQF_ONESHOT, + pdev->name, pdev); if (err < 0) { dev_warn(dev, "feed control interrupt is not available.\n"); goto err_irq; Patches currently in stable-queue which might be from krzk(a)kernel.org are queue-3.18/crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0 to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Randy Dunlap <rdunlap(a)infradead.org> Date: Fri, 17 Nov 2017 15:27:35 -0800 Subject: dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0 From: Randy Dunlap <rdunlap(a)infradead.org> [ Upstream commit 1f3c790bd5989fcfec9e53ad8fa09f5b740c958f ] line-range is supposed to treat "1-" as "1-endoffile", so handle the special case by setting last_lineno to UINT_MAX. Fixes this error: dynamic_debug:ddebug_parse_query: last-line:0 < 1st-line:1 dynamic_debug:ddebug_exec_query: query parse failed Link: http://lkml.kernel.org/r/10a6a101-e2be-209f-1f41-54637824788e@infradead.org Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Acked-by: Jason Baron <jbaron(a)akamai.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/dynamic_debug.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -353,6 +353,10 @@ static int ddebug_parse_query(char *word if (parse_lineno(last, &query->last_lineno) < 0) return -EINVAL; + /* special case for last lineno not specified */ + if (query->last_lineno == 0) + query->last_lineno = UINT_MAX; + if (query->last_lineno < query->first_lineno) { pr_err("last-line:%d < 1st-line:%d\n", query->last_lineno, Patches currently in stable-queue which might be from rdunlap(a)infradead.org are queue-3.18/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "axonram: Fix gendisk handling" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled axonram: Fix gendisk handling to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: axonram-fix-gendisk-handling.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Wed, 8 Mar 2017 14:56:05 +0100 Subject: axonram: Fix gendisk handling From: Jan Kara <jack(a)suse.cz> [ Upstream commit 672a2c87c83649fb0167202342ce85af9a3b4f1c ] It is invalid to call del_gendisk() when disk->queue is NULL. Fix error handling in axon_ram_probe() to avoid doing that. Also del_gendisk() does not drop a reference to gendisk allocated by alloc_disk(). That has to be done by put_disk(). Add that call where needed. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/sysdev/axonram.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/powerpc/sysdev/axonram.c +++ b/arch/powerpc/sysdev/axonram.c @@ -283,7 +283,9 @@ failed: if (bank->disk->major > 0) unregister_blkdev(bank->disk->major, bank->disk->disk_name); - del_gendisk(bank->disk); + if (bank->disk->flags & GENHD_FL_UP) + del_gendisk(bank->disk); + put_disk(bank->disk); } device->dev.platform_data = NULL; if (bank->io_addr != 0) @@ -308,6 +310,7 @@ axon_ram_remove(struct platform_device * device_remove_file(&device->dev, &dev_attr_ecc); free_irq(bank->irq_id, device); del_gendisk(bank->disk); + put_disk(bank->disk); iounmap((void __iomem *) bank->io_addr); kfree(bank); Patches currently in stable-queue which might be from jack(a)suse.cz are queue-3.18/axonram-fix-gendisk-handling.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "bnx2x: fix possible overrun of VFPF multicast addresses array" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bnx2x: fix possible overrun of VFPF multicast addresses array to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bnx2x-fix-possible-overrun-of-vfpf-multicast-addresses-array.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Michal Schmidt <mschmidt(a)redhat.com> Date: Fri, 3 Mar 2017 17:08:30 +0100 Subject: bnx2x: fix possible overrun of VFPF multicast addresses array From: Michal Schmidt <mschmidt(a)redhat.com> [ Upstream commit 22118d861cec5da6ed525aaf12a3de9bfeffc58f ] It is too late to check for the limit of the number of VF multicast addresses after they have already been copied to the req->multicast[] array, possibly overflowing it. Do the check before copying. Also fix the error path to not skip unlocking vf2pf_mutex. Signed-off-by: Michal Schmidt <mschmidt(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c @@ -826,7 +826,7 @@ int bnx2x_vfpf_set_mcast(struct net_devi struct bnx2x *bp = netdev_priv(dev); struct vfpf_set_q_filters_tlv *req = &bp->vf2pf_mbox->req.set_q_filters; struct pfvf_general_resp_tlv *resp = &bp->vf2pf_mbox->resp.general_resp; - int rc, i = 0; + int rc = 0, i = 0; struct netdev_hw_addr *ha; if (bp->state != BNX2X_STATE_OPEN) { @@ -841,6 +841,15 @@ int bnx2x_vfpf_set_mcast(struct net_devi /* Get Rx mode requested */ DP(NETIF_MSG_IFUP, "dev->flags = %x\n", dev->flags); + /* We support PFVF_MAX_MULTICAST_PER_VF mcast addresses tops */ + if (netdev_mc_count(dev) > PFVF_MAX_MULTICAST_PER_VF) { + DP(NETIF_MSG_IFUP, + "VF supports not more than %d multicast MAC addresses\n", + PFVF_MAX_MULTICAST_PER_VF); + rc = -EINVAL; + goto out; + } + netdev_for_each_mc_addr(ha, dev) { DP(NETIF_MSG_IFUP, "Adding mcast MAC: %pM\n", bnx2x_mc_addr(ha)); @@ -848,16 +857,6 @@ int bnx2x_vfpf_set_mcast(struct net_devi i++; } - /* We support four PFVF_MAX_MULTICAST_PER_VF mcast - * addresses tops - */ - if (i >= PFVF_MAX_MULTICAST_PER_VF) { - DP(NETIF_MSG_IFUP, - "VF supports not more than %d multicast MAC addresses\n", - PFVF_MAX_MULTICAST_PER_VF); - return -EINVAL; - } - req->n_multicast = i; req->flags |= VFPF_SET_Q_FILTERS_MULTICAST_CHANGED; req->vf_qid = 0; @@ -882,7 +881,7 @@ int bnx2x_vfpf_set_mcast(struct net_devi out: bnx2x_vfpf_finalize(bp, &req->first_tlv); - return 0; + return rc; } int bnx2x_vfpf_storm_rx_mode(struct bnx2x *bp) Patches currently in stable-queue which might be from mschmidt(a)redhat.com are queue-3.18/bnx2x-fix-possible-overrun-of-vfpf-multicast-addresses-array.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "audit: ensure that 'audit=1' actually enables audit for PID 1" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled audit: ensure that 'audit=1' actually enables audit for PID 1 to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Dec 14 21:30:47 CET 2017 From: Paul Moore <paul(a)paul-moore.com> Date: Fri, 1 Sep 2017 09:44:34 -0400 Subject: audit: ensure that 'audit=1' actually enables audit for PID 1 From: Paul Moore <paul(a)paul-moore.com> [ Upstream commit 173743dd99a49c956b124a74c8aacb0384739a4c ] Prior to this patch we enabled audit in audit_init(), which is too late for PID 1 as the standard initcalls are run after the PID 1 task is forked. This means that we never allocate an audit_context (see audit_alloc()) for PID 1 and therefore miss a lot of audit events generated by PID 1. This patch enables audit as early as possible to help ensure that when PID 1 is forked it can allocate an audit_context if required. Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/audit.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/kernel/audit.c +++ b/kernel/audit.c @@ -79,13 +79,13 @@ static int audit_initialized; #define AUDIT_OFF 0 #define AUDIT_ON 1 #define AUDIT_LOCKED 2 -u32 audit_enabled; -u32 audit_ever_enabled; +u32 audit_enabled = AUDIT_OFF; +u32 audit_ever_enabled = !!AUDIT_OFF; EXPORT_SYMBOL_GPL(audit_enabled); /* Default state when kernel boots without any parameters. */ -static u32 audit_default; +static u32 audit_default = AUDIT_OFF; /* If auditing cannot proceed, audit_failure selects what happens. */ static u32 audit_failure = AUDIT_FAIL_PRINTK; @@ -1173,8 +1173,6 @@ static int __init audit_init(void) skb_queue_head_init(&audit_skb_queue); skb_queue_head_init(&audit_skb_hold_queue); audit_initialized = AUDIT_INITIALIZED; - audit_enabled = audit_default; - audit_ever_enabled |= !!audit_default; audit_log(NULL, GFP_KERNEL, AUDIT_KERNEL, "initialized"); @@ -1191,6 +1189,8 @@ static int __init audit_enable(char *str audit_default = !!simple_strtol(str, NULL, 0); if (!audit_default) audit_initialized = AUDIT_DISABLED; + audit_enabled = audit_default; + audit_ever_enabled = !!audit_enabled; pr_info("%s\n", audit_default ? "enabled (after initialization)" : "disabled (until reboot)"); Patches currently in stable-queue which might be from paul(a)paul-moore.com are queue-3.18/audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch

7 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror