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

Patch "scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que to the 4.14-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: scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch and it can be found in the queue-4.14 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 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani <himanshu.madhani(a)cavium.com> Date: Sat, 16 Dec 2017 16:05:09 -0800 Subject: scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que From: Himanshu Madhani <himanshu.madhani(a)cavium.com> commit 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 upstream. This patch fixes following warnings reported by smatch: drivers/scsi/qla2xxx/qla_mid.c:586 qla25xx_delete_req_que() error: we previously assumed 'req' could be null (see line 580) drivers/scsi/qla2xxx/qla_mid.c:602 qla25xx_delete_rsp_que() error: we previously assumed 'rsp' could be null (see line 596) Fixes: 7867b98dceb7 ("scsi: qla2xxx: Fix memory leak in dual/target mode") Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_mid.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/scsi/qla2xxx/qla_mid.c +++ b/drivers/scsi/qla2xxx/qla_mid.c @@ -582,8 +582,9 @@ qla25xx_delete_req_que(struct scsi_qla_h ret = qla25xx_init_req_que(vha, req); if (ret != QLA_SUCCESS) return QLA_FUNCTION_FAILED; + + qla25xx_free_req_que(vha, req); } - qla25xx_free_req_que(vha, req); return ret; } @@ -598,8 +599,9 @@ qla25xx_delete_rsp_que(struct scsi_qla_h ret = qla25xx_init_rsp_que(vha, rsp); if (ret != QLA_SUCCESS) return QLA_FUNCTION_FAILED; + + qla25xx_free_rsp_que(vha, rsp); } - qla25xx_free_rsp_que(vha, rsp); return ret; } Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are queue-4.14/scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch queue-4.14/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch queue-4.14/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch

7 years, 6 months

1
0
0 0

Patch "usb: dwc3: Fix GDBGFIFOSPACE_TYPE values" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: Fix GDBGFIFOSPACE_TYPE values to the 4.14-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: usb-dwc3-fix-gdbgfifospace_type-values.patch and it can be found in the queue-4.14 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 b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Fri, 2 Feb 2018 13:21:35 -0800 Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream. The FIFO/Queue type values are incorrect. Correct them according to DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25). Additionally, this patch includes ProtocolStatusQ and AuxEventQ types. Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper") Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/core.h | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -166,13 +166,15 @@ #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0) #define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff) -#define DWC3_TXFIFOQ 1 -#define DWC3_RXFIFOQ 3 -#define DWC3_TXREQQ 5 -#define DWC3_RXREQQ 7 -#define DWC3_RXINFOQ 9 -#define DWC3_DESCFETCHQ 13 -#define DWC3_EVENTQ 15 +#define DWC3_TXFIFOQ 0 +#define DWC3_RXFIFOQ 1 +#define DWC3_TXREQQ 2 +#define DWC3_RXREQQ 3 +#define DWC3_RXINFOQ 4 +#define DWC3_PSTATQ 5 +#define DWC3_DESCFETCHQ 6 +#define DWC3_EVENTQ 7 +#define DWC3_AUXEVENTQ 8 /* Global RX Threshold Configuration Register */ #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19) Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are queue-4.14/usb-dwc3-fix-gdbgfifospace_type-values.patch

7 years, 6 months

1
0
0 0

Patch "scsi: qla2xxx: Fix NULL pointer access for fcport structure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix NULL pointer access for fcport structure to the 4.14-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: scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch and it can be found in the queue-4.14 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 5c25d451163cab9be80744cbc5448d6b95ab8d1a Mon Sep 17 00:00:00 2001 From: Quinn Tran <quinn.tran(a)cavium.com> Date: Thu, 28 Dec 2017 12:33:09 -0800 Subject: scsi: qla2xxx: Fix NULL pointer access for fcport structure From: Quinn Tran <quinn.tran(a)cavium.com> commit 5c25d451163cab9be80744cbc5448d6b95ab8d1a upstream. when processing iocb in a timeout case, driver was trying to log messages without verifying if the fcport structure could have valid data. This results in a NULL pointer access. Fixes: 726b85487067("qla2xxx: Add framework for async fabric discovery") Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com> Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_init.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -102,11 +102,16 @@ qla2x00_async_iocb_timeout(void *data) struct srb_iocb *lio = &sp->u.iocb_cmd; struct event_arg ea; - ql_dbg(ql_dbg_disc, fcport->vha, 0x2071, - "Async-%s timeout - hdl=%x portid=%06x %8phC.\n", - sp->name, sp->handle, fcport->d_id.b24, fcport->port_name); + if (fcport) { + ql_dbg(ql_dbg_disc, fcport->vha, 0x2071, + "Async-%s timeout - hdl=%x portid=%06x %8phC.\n", + sp->name, sp->handle, fcport->d_id.b24, fcport->port_name); - fcport->flags &= ~FCF_ASYNC_SENT; + fcport->flags &= ~FCF_ASYNC_SENT; + } else { + pr_info("Async-%s timeout - hdl=%x.\n", + sp->name, sp->handle); + } switch (sp->type) { case SRB_LOGIN_CMD: Patches currently in stable-queue which might be from quinn.tran(a)cavium.com are queue-4.14/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch

7 years, 6 months

1
0
0 0

Patch "scsi: qla2xxx: Fix logo flag for qlt_free_session_done()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix logo flag for qlt_free_session_done() to the 4.14-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: scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch and it can be found in the queue-4.14 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 a2390348c19d0819d525d375414a7cfdacb51a68 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani <hmadhani(a)redhat.com> Date: Mon, 22 Jan 2018 12:04:20 -0800 Subject: scsi: qla2xxx: Fix logo flag for qlt_free_session_done() From: Himanshu Madhani <hmadhani(a)redhat.com> commit a2390348c19d0819d525d375414a7cfdacb51a68 upstream. Commit 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.")fixed the target re-login after session relogin is complete, but missed out the qlt_free_session_done() path. This patch clears send_els_logo flag in qlt_free_session_done() callback. [mkp: checkpatch] Fixes: 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.") Signed-off-by: Himanshu Madhani <hmadhani(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_target.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/qla2xxx/qla_target.c +++ b/drivers/scsi/qla2xxx/qla_target.c @@ -971,6 +971,7 @@ static void qlt_free_session_done(struct logo.id = sess->d_id; logo.cmd_count = 0; + sess->send_els_logo = 0; qlt_send_first_logo(vha, &logo); } Patches currently in stable-queue which might be from hmadhani(a)redhat.com are queue-4.14/scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch

7 years, 6 months

1
0
0 0

Patch "scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure to the 4.14-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: scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch and it can be found in the queue-4.14 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 6a2cf8d3663e13e19af636c2a8d92e766261dc45 Mon Sep 17 00:00:00 2001 From: Bill Kuzeja <William.Kuzeja(a)stratus.com> Date: Mon, 5 Mar 2018 00:02:55 -0500 Subject: scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure From: Bill Kuzeja <William.Kuzeja(a)stratus.com> commit 6a2cf8d3663e13e19af636c2a8d92e766261dc45 upstream. Because of the shifting around of code in qla2x00_probe_one recently, failures during adapter initialization can lead to problems, i.e. NULL pointer crashes and doubly freed data structures which cause eventual panics. This V2 version makes the relevant memory free routines idempotent, so repeat calls won't cause any harm. I also removed the problematic probe_init_failed exit point as it is not needed. Fixes: d64d6c5671db ("scsi: qla2xxx: Fix NULL pointer crash due to probe failure") Signed-off-by: Bill Kuzeja <william.kuzeja(a)stratus.com> Acked-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_os.c | 59 ++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 22 deletions(-) --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -442,7 +442,7 @@ static int qla2x00_alloc_queues(struct q ha->req_q_map[0] = req; set_bit(0, ha->rsp_qid_map); set_bit(0, ha->req_qid_map); - return 1; + return 0; fail_qpair_map: kfree(ha->base_qpair); @@ -459,6 +459,9 @@ fail_req_map: static void qla2x00_free_req_que(struct qla_hw_data *ha, struct req_que *req) { + if (!ha->req_q_map) + return; + if (IS_QLAFX00(ha)) { if (req && req->ring_fx00) dma_free_coherent(&ha->pdev->dev, @@ -469,14 +472,17 @@ static void qla2x00_free_req_que(struct (req->length + 1) * sizeof(request_t), req->ring, req->dma); - if (req) + if (req) { kfree(req->outstanding_cmds); - - kfree(req); + kfree(req); + } } static void qla2x00_free_rsp_que(struct qla_hw_data *ha, struct rsp_que *rsp) { + if (!ha->rsp_q_map) + return; + if (IS_QLAFX00(ha)) { if (rsp && rsp->ring) dma_free_coherent(&ha->pdev->dev, @@ -487,7 +493,8 @@ static void qla2x00_free_rsp_que(struct (rsp->length + 1) * sizeof(response_t), rsp->ring, rsp->dma); } - kfree(rsp); + if (rsp) + kfree(rsp); } static void qla2x00_free_queues(struct qla_hw_data *ha) @@ -1710,6 +1717,8 @@ qla2x00_abort_all_cmds(scsi_qla_host_t * struct qla_tgt_cmd *cmd; uint8_t trace = 0; + if (!ha->req_q_map) + return; spin_lock_irqsave(&ha->hardware_lock, flags); for (que = 0; que < ha->max_req_queues; que++) { req = ha->req_q_map[que]; @@ -3063,14 +3072,14 @@ qla2x00_probe_one(struct pci_dev *pdev, /* Set up the irqs */ ret = qla2x00_request_irqs(ha, rsp); if (ret) - goto probe_hw_failed; + goto probe_failed; /* Alloc arrays of request and response ring ptrs */ - if (!qla2x00_alloc_queues(ha, req, rsp)) { + if (qla2x00_alloc_queues(ha, req, rsp)) { ql_log(ql_log_fatal, base_vha, 0x003d, "Failed to allocate memory for queue pointers..." "aborting.\n"); - goto probe_init_failed; + goto probe_failed; } if (ha->mqenable && shost_use_blk_mq(host)) { @@ -3347,15 +3356,6 @@ skip_dpc: return 0; -probe_init_failed: - qla2x00_free_req_que(ha, req); - ha->req_q_map[0] = NULL; - clear_bit(0, ha->req_qid_map); - qla2x00_free_rsp_que(ha, rsp); - ha->rsp_q_map[0] = NULL; - clear_bit(0, ha->rsp_qid_map); - ha->max_req_queues = ha->max_rsp_queues = 0; - probe_failed: if (base_vha->timer_active) qla2x00_stop_timer(base_vha); @@ -4435,11 +4435,17 @@ qla2x00_mem_free(struct qla_hw_data *ha) if (ha->init_cb) dma_free_coherent(&ha->pdev->dev, ha->init_cb_size, ha->init_cb, ha->init_cb_dma); - vfree(ha->optrom_buffer); - kfree(ha->nvram); - kfree(ha->npiv_info); - kfree(ha->swl); - kfree(ha->loop_id_map); + + if (ha->optrom_buffer) + vfree(ha->optrom_buffer); + if (ha->nvram) + kfree(ha->nvram); + if (ha->npiv_info) + kfree(ha->npiv_info); + if (ha->swl) + kfree(ha->swl); + if (ha->loop_id_map) + kfree(ha->loop_id_map); ha->srb_mempool = NULL; ha->ctx_mempool = NULL; @@ -4455,6 +4461,15 @@ qla2x00_mem_free(struct qla_hw_data *ha) ha->ex_init_cb_dma = 0; ha->async_pd = NULL; ha->async_pd_dma = 0; + ha->loop_id_map = NULL; + ha->npiv_info = NULL; + ha->optrom_buffer = NULL; + ha->swl = NULL; + ha->nvram = NULL; + ha->mctp_dump = NULL; + ha->dcbx_tlv = NULL; + ha->xgmac_data = NULL; + ha->sfp_data = NULL; ha->s_dma_pool = NULL; ha->dl_dma_pool = NULL; Patches currently in stable-queue which might be from William.Kuzeja(a)stratus.com are queue-4.14/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch

7 years, 6 months

1
0
0 0

Re: NULL pointer dereferences with 4.14.27

by Holger Hoffstätte

(CC: davem, soheil & gregkh) On 03/17/18 20:12, Holger Hoffstätte wrote: > On 03/17/18 19:41, Carlos Carvalho wrote: >> I've put 4.14.27 this morning in this machine and in about 2h it started >> showing null dereferences identical to the following one. There were several of >> them, with about 1/2h of interval. Strangely it continued to work and I saw no >> other anomalies. I've just reverted to 4.14.26. >> >> It only happened in this machine, which has a net traffic of several Gb/s and >> thousands of simultaneous connections. >> >> Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 >> Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7 >> Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0 >> Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI >> Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted 4.14.27 #4 (snip) > > Fixed by: https://www.spinics.net/lists/netdev/msg489445.html > > -h > This patch is in the netdev patchwork at https://patchwork.ozlabs.org/patch/886324/ but has been marked as "not applicable" without further queued/rejected comment from Dave, so I believe it became a victim of email lossage. As the patch says it doesn't apply to anything older than 4.14, but it has been tested & reported by several people as fixing the problem, and indeed works fine. Since GregKH only accepts net patches from Dave I wanted to make sure it got queued up for 4.14. Thanks, Holger

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [PATCH 1/4] clk: bcm2835: Fix ana->maskX definitions

by Boris Brezillon

ana->maskX values are already '~'-ed in bcm2835_pll_set_rate(). Remove the '~' in the definition to fix ANA setup. Note that this commit fixes a long standing bug preventing one from using an HDMI display if it's plugged after the FW has booted Linux. This is because PLLH is used by the HDMI encoder to generate the pixel clock. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Reviewed-by: Eric Anholt <eric(a)anholt.net> --- drivers/clk/bcm/clk-bcm2835.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c index 44301a3d9963..2108a274185a 100644 --- a/drivers/clk/bcm/clk-bcm2835.c +++ b/drivers/clk/bcm/clk-bcm2835.c @@ -449,17 +449,17 @@ struct bcm2835_pll_ana_bits { static const struct bcm2835_pll_ana_bits bcm2835_ana_default = { .mask0 = 0, .set0 = 0, - .mask1 = (u32)~(A2W_PLL_KI_MASK | A2W_PLL_KP_MASK), + .mask1 = A2W_PLL_KI_MASK | A2W_PLL_KP_MASK, .set1 = (2 << A2W_PLL_KI_SHIFT) | (8 << A2W_PLL_KP_SHIFT), - .mask3 = (u32)~A2W_PLL_KA_MASK, + .mask3 = A2W_PLL_KA_MASK, .set3 = (2 << A2W_PLL_KA_SHIFT), .fb_prediv_mask = BIT(14), }; static const struct bcm2835_pll_ana_bits bcm2835_ana_pllh = { - .mask0 = (u32)~(A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK), + .mask0 = A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK, .set0 = (2 << A2W_PLLH_KA_SHIFT) | (2 << A2W_PLLH_KI_LOW_SHIFT), - .mask1 = (u32)~(A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK), + .mask1 = A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK, .set1 = (6 << A2W_PLLH_KP_SHIFT), .mask3 = 0, .set3 = 0, -- 2.14.1

7 years, 6 months

2
5
0 0

Re: [PATCH 4/4] clk: bcm2835: Make sure the PLL is gated before changing its rate

by Stephen Boyd

Quoting Eric Anholt (2018-03-13 09:56:57) > Stephen Boyd <sboyd(a)kernel.org> writes: > > > > What exactly is going on here? It sounds like the framework isn't aware > > of the 'on/off' boot state of certain clks (a known problem) and that's > > causing some sort of problem when changing rates? This usually happens > > with PLLs that are enabled at boot time and can't support their rate > > changing when they're enabled. We really should start reading on/off > > state and "hand off" that enabled state to something in the framework so > > we at least know if a clk is enabled or not out of boot. There was some > > work on clk handoff done a while ago by Mike that never landed which may > > be useful to finish this off. Maybe we can pass that enabled state off > > to the clk we always create for a clk_hw structure at registration time > > and then have clk_disable_unused operate on that clk pointer at late > > init. > > Yes, the usual problem of clk not handling boot-time clock state well. > > That said, it's patch 1 that's critical for fixing many of our users, > and we need that in as soon as possible. #2 is also reviewed and ready. Got it. I'll pick up the first two then.

7 years, 6 months

1
0
0 0

Patch "btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device to the 4.9-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: btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch and it can be found in the queue-4.9 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 fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 30 Jan 2018 16:07:37 +0200 Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device From: Nikolay Borisov <nborisov(a)suse.com> commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream. Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then btrfs_free_stale_devices will proceed to also free the btrfs_fs_devices struct itself. Currently this leads to a use after free since list_for_each_entry will try to perform a check on the already freed memory to see if it has to terminate the loop. The fix is to use 'break' when we know we are freeing the current fs_devs. Fixes: 4fde46f0cc71 ("Btrfs: free the stale device") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Anand Jain <anand.jain(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -583,6 +583,7 @@ void btrfs_free_stale_device(struct btrf btrfs_sysfs_remove_fsid(fs_devs); list_del(&fs_devs->list); free_fs_devices(fs_devs); + break; } else { fs_devs->num_devices--; list_del(&dev->dev_list); Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.9/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 6 months

1
0
0 0

Patch "btrfs: alloc_chunk: fix DUP stripe size handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: alloc_chunk: fix DUP stripe size handling to the 4.9-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: btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch and it can be found in the queue-4.9 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 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001 From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Date: Mon, 5 Feb 2018 17:45:11 +0100 Subject: btrfs: alloc_chunk: fix DUP stripe size handling From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> commit 92e222df7b8f05c565009c7383321b593eca488b upstream. In case of using DUP, we search for enough unallocated disk space on a device to hold two stripes. The devices_info[ndevs-1].max_avail that holds the amount of unallocated space found is directly assigned to stripe_size, while it's actually twice the stripe size. Later on in the code, an unconditional division of stripe_size by dev_stripes corrects the value, but in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size. The unconditional division later tries to correct stripe_size, but will actually make sure we can't allocate more than half the max_chunk_size. Fix this by moving the division by dev_stripes before the max chunk size check, so it always contains the right value, instead of putting a duct tape division in further on to get it fixed again. Since in all other cases than DUP, dev_stripes is 1, this change only affects DUP. Other attempts in the past were made to fix this: * 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried to fix the same problem, but still resulted in part of the code acting on a wrongly doubled stripe_size value. * 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally broke this fix again. The real problem was already introduced with the rest of the code in 73c5de0051. The user visible result however will be that the max chunk size for DUP will suddenly double, while it's actually acting according to the limits in the code again like it was 5 years ago. Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com> Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation") Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6") Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ update comment ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4748,10 +4748,13 @@ static int __btrfs_alloc_chunk(struct bt if (devs_max && ndevs > devs_max) ndevs = devs_max; /* - * the primary goal is to maximize the number of stripes, so use as many - * devices as possible, even if the stripes are not maximum sized. + * The primary goal is to maximize the number of stripes, so use as + * many devices as possible, even if the stripes are not maximum sized. + * + * The DUP profile stores more than one stripe per device, the + * max_avail is the total size so we have to adjust. */ - stripe_size = devices_info[ndevs-1].max_avail; + stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes); num_stripes = ndevs * dev_stripes; /* @@ -4791,8 +4794,6 @@ static int __btrfs_alloc_chunk(struct bt stripe_size = devices_info[ndevs-1].max_avail; } - stripe_size = div_u64(stripe_size, dev_stripes); - /* align to BTRFS_STRIPE_LEN */ stripe_size = div_u64(stripe_size, raid_stripe_len); stripe_size *= raid_stripe_len; Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are queue-4.9/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror