January 2020 - Linux-stable-mirror

[PATCH v2 08/11] megaraid_sas: Do not initiate OCR if controller is not in ready state

by Anand Lodnoor

Driver initiates OCR if a DCMD command times out. But there is a deadlock if the driver attempts to invoke another OCR before the mutex lock (reset_mutex) is released from the previous session of OCR. This patch takes care of the above scenario using new flag MEGASAS_FUSION_OCR_NOT_POSSIBLE to indicate if OCR is possible. Cc: stable(a)vger.kernel.org Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Anand Lodnoor <anand.lodnoor(a)broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 3 ++- drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 ++- drivers/scsi/megaraid/megaraid_sas_fusion.h | 1 + 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 8bee5629..792db75 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4403,7 +4403,8 @@ int megasas_alloc_cmds(struct megasas_instance *instance) if (instance->adapter_type == MFI_SERIES) return KILL_ADAPTER; else if (instance->unload || - test_bit(MEGASAS_FUSION_IN_RESET, &instance->reset_flags)) + test_bit(MEGASAS_FUSION_OCR_NOT_POSSIBLE, + &instance->reset_flags)) return IGNORE_TIMEOUT; else return INITIATE_OCR; diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 6860fd2..8b6cc1b 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -4851,6 +4851,7 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int reason) if (instance->requestorId && !instance->skip_heartbeat_timer_del) del_timer_sync(&instance->sriov_heartbeat_timer); set_bit(MEGASAS_FUSION_IN_RESET, &instance->reset_flags); + set_bit(MEGASAS_FUSION_OCR_NOT_POSSIBLE, &instance->reset_flags); atomic_set(&instance->adprecovery, MEGASAS_ADPRESET_SM_POLLING); instance->instancet->disable_intr(instance); megasas_sync_irqs((unsigned long)instance); @@ -5059,7 +5060,7 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int reason) instance->skip_heartbeat_timer_del = 1; retval = FAILED; out: - clear_bit(MEGASAS_FUSION_IN_RESET, &instance->reset_flags); + clear_bit(MEGASAS_FUSION_OCR_NOT_POSSIBLE, &instance->reset_flags); mutex_unlock(&instance->reset_mutex); return retval; } diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h b/drivers/scsi/megaraid/megaraid_sas_fusion.h index 8358b68..d57ecc7 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.h +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h @@ -89,6 +89,7 @@ enum MR_RAID_FLAGS_IO_SUB_TYPE { #define MEGASAS_FP_CMD_LEN 16 #define MEGASAS_FUSION_IN_RESET 0 +#define MEGASAS_FUSION_OCR_NOT_POSSIBLE 1 #define RAID_1_PEER_CMDS 2 #define JBOD_MAPS_COUNT 2 #define MEGASAS_REDUCE_QD_COUNT 64 -- 1.8.3.1

4 years, 12 months

1
0
0 0

[PATCH] USB: serial: opticon: fix control-message timeouts

by Johan Hovold

The driver was issuing synchronous uninterruptible control requests without using a timeout. This could lead to the driver hanging on open() or tiocmset() due to a malfunctioning (or malicious) device until the device is physically disconnected. The USB upper limit of five seconds per request should be more than enough. Fixes: 309a057932ab ("USB: opticon: add rts and cts support") Cc: stable <stable(a)vger.kernel.org> # 2.6.39 Cc: Martin Jansen <martin.jansen(a)opticon.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- This was reported to me off-list to be an issue with some opticon devices. Let's address the obvious bug while waiting for a bug report to be sent to the list. Johan drivers/usb/serial/opticon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c index cb7aac9cd9e7..ed2b4e6dca38 100644 --- a/drivers/usb/serial/opticon.c +++ b/drivers/usb/serial/opticon.c @@ -113,7 +113,7 @@ static int send_control_msg(struct usb_serial_port *port, u8 requesttype, retval = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0), requesttype, USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE, - 0, 0, buffer, 1, 0); + 0, 0, buffer, 1, USB_CTRL_SET_TIMEOUT); kfree(buffer); if (retval < 0) -- 2.24.1

4 years, 12 months

2
2
0 0

[PATCH 2/2] USB: serial: opticon: stop all I/O on close()

by Johan Hovold

Make sure to stop any submitted write URBs on close(). This specifically avoids a NULL-pointer dereference or use-after-free in case of a late completion event after driver unbind. Fixes: 648d4e16567e ("USB: serial: opticon: add write support") Cc: stable <stable(a)vger.kernel.org> # 2.6.30: xxx: USB: serial: opticon: add chars_in_buffer() implementation Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/opticon.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c index f7bccf14a71f..61ce359221ec 100644 --- a/drivers/usb/serial/opticon.c +++ b/drivers/usb/serial/opticon.c @@ -42,6 +42,8 @@ struct opticon_private { bool cts; int outstanding_urbs; int outstanding_bytes; + + struct usb_anchor anchor; }; @@ -150,6 +152,15 @@ static int opticon_open(struct tty_struct *tty, struct usb_serial_port *port) return res; } +static void opticon_close(struct usb_serial_port *port) +{ + struct opticon_private *priv = usb_get_serial_port_data(port); + + usb_kill_anchored_urbs(&priv->anchor); + + usb_serial_generic_close(port); +} + static void opticon_write_control_callback(struct urb *urb) { struct usb_serial_port *port = urb->context; @@ -226,10 +237,13 @@ static int opticon_write(struct tty_struct *tty, struct usb_serial_port *port, (unsigned char *)dr, buffer, count, opticon_write_control_callback, port); + usb_anchor_urb(urb, priv->anchor); + /* send it down the pipe */ ret = usb_submit_urb(urb, GFP_ATOMIC); if (ret) { dev_err(&port->dev, "failed to submit write urb: %d\n", ret); + usb_unanchor_urb(urb); goto error; } @@ -364,6 +378,7 @@ static int opticon_port_probe(struct usb_serial_port *port) return -ENOMEM; spin_lock_init(&priv->lock); + init_usb_anchor(&priv->anchor); usb_set_serial_port_data(port, priv); @@ -391,6 +406,7 @@ static struct usb_serial_driver opticon_device = { .port_probe = opticon_port_probe, .port_remove = opticon_port_remove, .open = opticon_open, + .close = opticon_close, .write = opticon_write, .write_room = opticon_write_room, .chars_in_buffer = opticon_chars_in_buffer, -- 2.24.1

4 years, 12 months

1
0
0 0

Re: [PATCH 3/4] x86/resctrl: Fix a deadlock due to inaccurate active reference of kernfs node

by Xiaochen Shen

Hi Sasha, The backporting for v4.14.x stable tree needs some manual tweaking due to difference code bases: 1. x86/resctrl rename/re-arrange in v5.0 upstream kernel. 2. Code change in upstream commit cfd0f34e4cd5 ("x86/intel_rdt: Add diagnostics when making directories"). The backporting for v4.19.x stable tree needs some manual tweaking due to difference code bases: x86/resctrl rename/re-arrange in v5.0 upstream kernel. I will work on the backporting once this patch is merged into upstream. Thank you. On 1/9/2020 22:36, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: c7d9aac61311 ("x86/intel_rdt/cqm: Add mkdir support for RDT monitoring"). > > The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162. > > v5.4.8: Build OK! > v4.19.93: Failed to apply! Possible dependencies: > Unable to calculate > > v4.14.162: Failed to apply! Possible dependencies: > cfd0f34e4cd5 ("x86/intel_rdt: Add diagnostics when making directories") > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? > -- Best regards, Xiaochen

4 years, 12 months

1
0
0 0

Re: [PATCH 2/4] x86/resctrl: Fix use-after-free due to inaccurate refcount of rdtgroup

by Xiaochen Shen

Hi Sasha, The backporting for v4.14.x stable tree needs some manual tweaking due to difference code bases: 1. x86/resctrl rename/re-arrange in v5.0 upstream kernel. 2. Code re-arrange in upstream commit 17eafd076291 ("x86/intel_rdt: Split resource group removal in two"). The backporting for v4.19.x stable tree needs some manual tweaking due to difference code bases: x86/resctrl rename/re-arrange in v5.0 upstream kernel. I will work on the backporting once this patch is merged into upstream. Thank you. On 1/9/2020 22:36, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: f3cbeacaa06e ("x86/intel_rdt/cqm: Add rmdir support"). > > The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162. > > v5.4.8: Build OK! > v4.19.93: Failed to apply! Possible dependencies: > Unable to calculate > > v4.14.162: Failed to apply! Possible dependencies: > 17eafd076291 ("x86/intel_rdt: Split resource group removal in two") > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? > -- Best regards, Xiaochen

4 years, 12 months

1
0
0 0

Re: [PATCH 1/4] x86/resctrl: Fix use-after-free when deleting resource groups

by Xiaochen Shen

Hi Sasha, The backporting for v4.14.x and v4.19.x stable trees needs some manual tweaking due to difference code bases (since x86/resctrl rename/re-arrange in v5.0 upstream kernel). I will work on the backporting once this patch is merged into upstream. Thank you. On 1/9/2020 22:36, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: f3cbeacaa06e ("x86/intel_rdt/cqm: Add rmdir support"). > > The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162. > > v5.4.8: Build OK! > v4.19.93: Failed to apply! Possible dependencies: > Unable to calculate > > v4.14.162: Failed to apply! Possible dependencies: > Unable to calculate > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? > -- Best regards, Xiaochen

4 years, 12 months

1
0
0 0

[PATCH] ALSA: usb-audio: fix sync-ep altsetting sanity check

by Johan Hovold

The altsetting sanity check in set_sync_ep_implicit_fb_quirk() was checking for there to be at least one altsetting but then went on to access the second one, which may not exist. This could lead to random slab data being used to initialise the sync endpoint in snd_usb_add_endpoint(). Fixes: c75a8a7ae565 ("ALSA: snd-usb: add support for implicit feedback") Fixes: ca10a7ebdff1 ("ALSA: usb-audio: FT C400 sync playback EP to capture EP") Fixes: 5e35dc0338d8 ("ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204") Fixes: 17f08b0d9aaf ("ALSA: usb-audio: add implicit fb quirk for Axe-Fx II") Fixes: 103e9625647a ("ALSA: usb-audio: simplify set_sync_ep_implicit_fb_quirk") Cc: stable <stable(a)vger.kernel.org> # 3.5 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- sound/usb/pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index a11c8150af58..0e4eab96e23e 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -370,7 +370,7 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, add_sync_ep_from_ifnum: iface = usb_ifnum_to_if(dev, ifnum); - if (!iface || iface->num_altsetting == 0) + if (!iface || iface->num_altsetting < 2) return -EINVAL; alts = &iface->altsetting[1]; -- 2.24.1

4 years, 12 months

2
1
0 0

[5.4-stable] Driver memory fixes

by Ben Hutchings

Please pick the following commits for 5.4-stable: 3d94a4a8373b mwifiex: fix possible heap overflow in mwifiex_process_country_ie() bbe692e349e2 rpmsg: char: release allocated memory db8fd2cde932 mwifiex: pcie: Fix memory leak in mwifiex_pcie_alloc_cmdrsp_buf 0e62395da2bd scsi: bfa: release allocated memory in case of error a2cdd07488e6 rtl8xxxu: prevent leaking urb b8d17e7d93d2 ath10k: fix memory leak They all apply and build cleanly. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

4 years, 12 months

2
1
0 0

stable-rc/linux-4.19.y boot: 79 boots: 1 failed, 77 passed with 1 untried/unknown (v4.19.95-35-g2bdac5496636)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 79 boots: 1 failed, 77 passed with 1 untried/unknown (v4.19.95-35-g2bdac5496636) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.95-35… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.95-35-g2bdac5496636 Git Commit: 2bdac549663665fe972016b13afee6db879e82da Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 47 unique boards, 15 SoC families, 13 builds out of 202 Boot Regressions Detected: arm: versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.19.95) arm64: defconfig: gcc-8: meson-gxl-s905x-khadas-vim: lab-baylibre: new failure (last pass: v4.19.95) Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxl-s905x-khadas-vim: 1 failed lab --- For more info write to <info(a)kernelci.org>

4 years, 12 months

1
0
0 0

stable-rc/linux-4.4.y boot: 24 boots: 0 failed, 24 passed (v4.4.209-22-gfbc4ae7c27ee)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 24 boots: 0 failed, 24 passed (v4.4.209-22-gfbc4ae7c27ee) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.209-22-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.209-22-gfbc4ae7c27ee Git Commit: fbc4ae7c27ee627bdaa119f497844a16da15b8d9 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 16 unique boards, 5 SoC families, 7 builds out of 189 --- For more info write to <info(a)kernelci.org>

4 years, 12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2020