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

Patch "parport_pc: Add support for WCH CH382L PCI-E single parallel port card." 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 parport_pc: Add support for WCH CH382L PCI-E single parallel port card. 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: parport_pc-add-support-for-wch-ch382l-pci-e-single-parallel-port-card.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 823f7923833c6cc2b16e601546d607dcfb368004 Mon Sep 17 00:00:00 2001 From: Alexander Gerasiov <gq(a)redlab-i.ru> Date: Sun, 4 Feb 2018 02:50:22 +0300 Subject: parport_pc: Add support for WCH CH382L PCI-E single parallel port card. From: Alexander Gerasiov <gq(a)redlab-i.ru> commit 823f7923833c6cc2b16e601546d607dcfb368004 upstream. WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382 but serial ports are not soldered on board. Detected as Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850]) Signed-off-by: Alexander Gerasiov <gq(a)redlab-i.ru> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/parport/parport_pc.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards { netmos_9901, netmos_9865, quatech_sppxp100, + wch_ch382l, }; @@ -2708,6 +2709,7 @@ static struct parport_pc_pci { /* netmos_9901 */ { 1, { { 0, -1 }, } }, /* netmos_9865 */ { 1, { { 0, -1 }, } }, /* quatech_sppxp100 */ { 1, { { 0, 1 }, } }, + /* wch_ch382l */ { 1, { { 2, -1 }, } }, }; static const struct pci_device_id parport_pc_pci_tbl[] = { @@ -2797,6 +2799,8 @@ static const struct pci_device_id parpor /* Quatech SPPXP-100 Parallel port PCI ExpressCard */ { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 }, + /* WCH CH382L PCI-E single parallel port card */ + { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l }, { 0, } /* terminate list */ }; MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl); Patches currently in stable-queue which might be from gq(a)redlab-i.ru are queue-4.14/parport_pc-add-support-for-wch-ch382l-pci-e-single-parallel-port-card.patch

7 years, 5 months

1
0
0 0

Patch "serial: 8250: Add Nuvoton NPCM UART" 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 serial: 8250: Add Nuvoton NPCM UART 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: serial-8250-add-nuvoton-npcm-uart.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 f597fbce38d230af95384f4a04e0a13a1d0ad45d Mon Sep 17 00:00:00 2001 From: Joel Stanley <joel(a)jms.id.au> Date: Mon, 5 Mar 2018 22:17:38 +1030 Subject: serial: 8250: Add Nuvoton NPCM UART From: Joel Stanley <joel(a)jms.id.au> commit f597fbce38d230af95384f4a04e0a13a1d0ad45d upstream. The Nuvoton UART is almost compatible with the 8250 driver when probed via the 8250_of driver, however it requires some extra configuration at startup. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Joel Stanley <joel(a)jms.id.au> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/serial/8250.txt | 1 drivers/tty/serial/8250/8250_of.c | 1 drivers/tty/serial/8250/8250_port.c | 33 ++++++++++++++++++++++ include/uapi/linux/serial_core.h | 3 ++ 4 files changed, 38 insertions(+) --- a/Documentation/devicetree/bindings/serial/8250.txt +++ b/Documentation/devicetree/bindings/serial/8250.txt @@ -24,6 +24,7 @@ Required properties: - "ti,da830-uart" - "aspeed,ast2400-vuart" - "aspeed,ast2500-vuart" + - "nuvoton,npcm750-uart" - "serial" if the port type is unknown. - reg : offset and length of the register set for the device. - interrupts : should contain uart interrupt. --- a/drivers/tty/serial/8250/8250_of.c +++ b/drivers/tty/serial/8250/8250_of.c @@ -321,6 +321,7 @@ static const struct of_device_id of_plat { .compatible = "mrvl,mmp-uart", .data = (void *)PORT_XSCALE, }, { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, }, + { .compatible = "nuvoton,npcm750-uart", .data = (void *)PORT_NPCM, }, { /* end of list */ }, }; MODULE_DEVICE_TABLE(of, of_platform_serial_table); --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -51,6 +51,10 @@ #define UART_EXAR_SLEEP 0x8b /* Sleep mode */ #define UART_EXAR_DVID 0x8d /* Device identification */ +/* Nuvoton NPCM timeout register */ +#define UART_NPCM_TOR 7 +#define UART_NPCM_TOIE BIT(7) /* Timeout Interrupt Enable */ + /* * Debugging. */ @@ -297,6 +301,15 @@ static const struct serial8250_config ua UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT, .flags = UART_CAP_FIFO, }, + [PORT_NPCM] = { + .name = "Nuvoton 16550", + .fifo_size = 16, + .tx_loadsz = 16, + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 | + UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT, + .rxtrig_bytes = {1, 4, 8, 14}, + .flags = UART_CAP_FIFO, + }, }; /* Uart divisor latch read */ @@ -2168,6 +2181,15 @@ int serial8250_do_startup(struct uart_po UART_DA830_PWREMU_MGMT_FREE); } + if (port->type == PORT_NPCM) { + /* + * Nuvoton calls the scratch register 'UART_TOR' (timeout + * register). Enable it, and set TIOC (timeout interrupt + * comparator) to be 0x20 for correct operation. + */ + serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE | 0x20); + } + #ifdef CONFIG_SERIAL_8250_RSA /* * If this is an RSA port, see if we can kick it up to the @@ -2490,6 +2512,15 @@ static unsigned int xr17v35x_get_divisor return quot_16 >> 4; } +/* Nuvoton NPCM UARTs have a custom divisor calculation */ +static unsigned int npcm_get_divisor(struct uart_8250_port *up, + unsigned int baud) +{ + struct uart_port *port = &up->port; + + return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2; +} + static unsigned int serial8250_get_divisor(struct uart_8250_port *up, unsigned int baud, unsigned int *frac) @@ -2510,6 +2541,8 @@ static unsigned int serial8250_get_divis quot = 0x8002; else if (up->port.type == PORT_XR17V35X) quot = xr17v35x_get_divisor(up, baud, frac); + else if (up->port.type == PORT_NPCM) + quot = npcm_get_divisor(up, baud); else quot = uart_get_divisor(port, baud); --- a/include/uapi/linux/serial_core.h +++ b/include/uapi/linux/serial_core.h @@ -76,6 +76,9 @@ #define PORT_SUNZILOG 38 #define PORT_SUNSAB 39 +/* Nuvoton UART */ +#define PORT_NPCM 40 + /* Intel EG20 */ #define PORT_PCH_8LINE 44 #define PORT_PCH_2LINE 45 Patches currently in stable-queue which might be from joel(a)jms.id.au are queue-4.14/serial-8250-add-nuvoton-npcm-uart.patch

7 years, 5 months

1
0
0 0

Patch "mei: remove dev_err message on an unsupported ioctl" 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 mei: remove dev_err message on an unsupported ioctl 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: mei-remove-dev_err-message-on-an-unsupported-ioctl.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 bb0829a741792b56c908d7745bc0b2b540293bcc Mon Sep 17 00:00:00 2001 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 27 Feb 2018 16:21:05 +0000 Subject: mei: remove dev_err message on an unsupported ioctl From: Colin Ian King <colin.king(a)canonical.com> commit bb0829a741792b56c908d7745bc0b2b540293bcc upstream. Currently the driver spams the kernel log on unsupported ioctls which is unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway. I suspect this was originally for debugging purposes but it really is not required so remove it. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/main.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/misc/mei/main.c +++ b/drivers/misc/mei/main.c @@ -507,7 +507,6 @@ static long mei_ioctl(struct file *file, break; default: - dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd); rets = -ENOIOCTLCMD; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.14/mei-remove-dev_err-message-on-an-unsupported-ioctl.patch

7 years, 5 months

1
0
0 0

Patch "/dev/mem: Avoid overwriting "err" in read_mem()" 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 /dev/mem: Avoid overwriting "err" in read_mem() 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: dev-mem-avoid-overwriting-err-in-read_mem.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 b5b38200ebe54879a7264cb6f33821f61c586a7e Mon Sep 17 00:00:00 2001 From: Kees Cook <keescook(a)chromium.org> Date: Tue, 27 Mar 2018 14:06:14 -0700 Subject: /dev/mem: Avoid overwriting "err" in read_mem() From: Kees Cook <keescook(a)chromium.org> commit b5b38200ebe54879a7264cb6f33821f61c586a7e upstream. Successes in probe_kernel_read() would mask failures in copy_to_user() during read_mem(). Reported-by: Brad Spengler <spender(a)grsecurity.net> Fixes: 22ec1a2aea73 ("/dev/mem: Add bounce buffer for copy-out") Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/mem.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -137,7 +137,7 @@ static ssize_t read_mem(struct file *fil while (count > 0) { unsigned long remaining; - int allowed; + int allowed, probe; sz = size_inside_page(p, count); @@ -160,9 +160,9 @@ static ssize_t read_mem(struct file *fil if (!ptr) goto failed; - err = probe_kernel_read(bounce, ptr, sz); + probe = probe_kernel_read(bounce, ptr, sz); unxlate_dev_mem_ptr(p, ptr); - if (err) + if (probe) goto failed; remaining = copy_to_user(buf, bounce, sz); Patches currently in stable-queue which might be from keescook(a)chromium.org are queue-4.14/dev-mem-avoid-overwriting-err-in-read_mem.patch

7 years, 5 months

1
0
0 0

Patch "media: usbtv: prevent double free in error case" 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 media: usbtv: prevent double free in error case 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: media-usbtv-prevent-double-free-in-error-case.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 50e7044535537b2a54c7ab798cd34c7f6d900bd2 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Mon, 8 Jan 2018 09:21:07 -0500 Subject: media: usbtv: prevent double free in error case From: Oliver Neukum <oneukum(a)suse.com> commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream. Quoting the original report: It looks like there is a double-free vulnerability in Linux usbtv driver on an error path of usbtv_probe function. When audio registration fails, usbtv_video_free function ends up freeing usbtv data structure, which gets freed the second time under usbtv_video_fail label. usbtv_audio_fail: usbtv_video_free(usbtv); => v4l2_device_put(&usbtv->v4l2_dev); => v4l2_device_put => kref_put => v4l2_device_release => usbtv_release (CALLBACK) => kfree(usbtv) (1st time) usbtv_video_fail: usb_set_intfdata(intf, NULL); usb_put_dev(usbtv->udev); kfree(usbtv); (2nd time) So, as we have refcounting, use it Reported-by: Yavuz, Tuba <tuba(a)ece.ufl.edu> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> CC: stable(a)vger.kernel.org Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/usbtv/usbtv-core.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -112,6 +112,8 @@ static int usbtv_probe(struct usb_interf return 0; usbtv_audio_fail: + /* we must not free at this point */ + usb_get_dev(usbtv->udev); usbtv_video_free(usbtv); usbtv_video_fail: Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.14/media-usbtv-prevent-double-free-in-error-case.patch

7 years, 5 months

1
0
0 0

Patch "crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one" 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 crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one 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: crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.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 8f461b1e02ed546fbd0f11611138da67fd85a30f Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Mon, 19 Feb 2018 23:48:12 -0800 Subject: crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one From: Eric Biggers <ebiggers(a)google.com> commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream. With ecb-cast5-avx, if a 128+ byte scatterlist element followed a shorter one, then the algorithm accidentally encrypted/decrypted only 8 bytes instead of the expected 128 bytes. Fix it by setting the encryption/decryption 'fn' correctly. Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers") Cc: <stable(a)vger.kernel.org> # v3.8+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/cast5_avx_glue.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/crypto/cast5_avx_glue.c +++ b/arch/x86/crypto/cast5_avx_glue.c @@ -66,8 +66,6 @@ static int ecb_crypt(struct blkcipher_de void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src); int err; - fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way; - err = blkcipher_walk_virt(desc, walk); desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP; @@ -79,6 +77,7 @@ static int ecb_crypt(struct blkcipher_de /* Process multi-block batch */ if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) { + fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way; do { fn(ctx, wdst, wsrc); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.14/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch

7 years, 5 months

1
0
0 0

Patch "crypto: testmgr - Fix incorrect values in PKCS#1 test vector" 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 crypto: testmgr - Fix incorrect values in PKCS#1 test vector 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: crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.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 333e18c5cc74438f8940c7f3a8b3573748a371f9 Mon Sep 17 00:00:00 2001 From: Conor McLoughlin <conor.mcloughlin(a)intel.com> Date: Tue, 13 Feb 2018 08:29:56 +0000 Subject: crypto: testmgr - Fix incorrect values in PKCS#1 test vector From: Conor McLoughlin <conor.mcloughlin(a)intel.com> commit 333e18c5cc74438f8940c7f3a8b3573748a371f9 upstream. The RSA private key for the first form should have version, prime1, prime2, exponent1, exponent2, coefficient values 0. With non-zero values for prime1,2, exponent 1,2 and coefficient the Intel QAT driver will assume that values are provided for the private key second form. This will result in signature verification failures for modules where QAT device is present and the modules are signed with rsa,sha256. Cc: <stable(a)vger.kernel.org> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu(a)intel.com> Signed-off-by: Conor McLoughlin <conor.mcloughlin(a)intel.com> Reviewed-by: Stephan Mueller <smueller(a)chronox.de> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/testmgr.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/crypto/testmgr.h +++ b/crypto/testmgr.h @@ -548,7 +548,7 @@ static const struct akcipher_testvec rsa static const struct akcipher_testvec pkcs1pad_rsa_tv_template[] = { { .key = - "\x30\x82\x03\x1f\x02\x01\x10\x02\x82\x01\x01\x00\xd7\x1e\x77\x82" + "\x30\x82\x03\x1f\x02\x01\x00\x02\x82\x01\x01\x00\xd7\x1e\x77\x82" "\x8c\x92\x31\xe7\x69\x02\xa2\xd5\x5c\x78\xde\xa2\x0c\x8f\xfe\x28" "\x59\x31\xdf\x40\x9c\x60\x61\x06\xb9\x2f\x62\x40\x80\x76\xcb\x67" "\x4a\xb5\x59\x56\x69\x17\x07\xfa\xf9\x4c\xbd\x6c\x37\x7a\x46\x7d" @@ -597,8 +597,8 @@ static const struct akcipher_testvec pkc "\xfe\xf8\x27\x1b\xd6\x55\x60\x5e\x48\xb7\x6d\x9a\xa8\x37\xf9\x7a" "\xde\x1b\xcd\x5d\x1a\x30\xd4\xe9\x9e\x5b\x3c\x15\xf8\x9c\x1f\xda" "\xd1\x86\x48\x55\xce\x83\xee\x8e\x51\xc7\xde\x32\x12\x47\x7d\x46" - "\xb8\x35\xdf\x41\x02\x01\x30\x02\x01\x30\x02\x01\x30\x02\x01\x30" - "\x02\x01\x30", + "\xb8\x35\xdf\x41\x02\x01\x00\x02\x01\x00\x02\x01\x00\x02\x01\x00" + "\x02\x01\x00", .key_len = 804, /* * m is SHA256 hash of following message: Patches currently in stable-queue which might be from conor.mcloughlin(a)intel.com are queue-4.14/crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.patch

7 years, 5 months

1
0
0 0

Patch "crypto: lrw - Free rctx->ext with kzfree" 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 crypto: lrw - Free rctx->ext with kzfree 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: crypto-lrw-free-rctx-ext-with-kzfree.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 8c9bdab21289c211ca1ca6a5f9b7537b4a600a02 Mon Sep 17 00:00:00 2001 From: Herbert Xu <herbert(a)gondor.apana.org.au> Date: Fri, 23 Mar 2018 08:14:44 +0800 Subject: crypto: lrw - Free rctx->ext with kzfree From: Herbert Xu <herbert(a)gondor.apana.org.au> commit 8c9bdab21289c211ca1ca6a5f9b7537b4a600a02 upstream. The buffer rctx->ext contains potentially sensitive data and should be freed with kzfree. Cc: <stable(a)vger.kernel.org> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher") Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/lrw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/crypto/lrw.c +++ b/crypto/lrw.c @@ -313,7 +313,7 @@ static void exit_crypt(struct skcipher_r rctx->left = 0; if (rctx->ext) - kfree(rctx->ext); + kzfree(rctx->ext); } static int do_encrypt(struct skcipher_request *req, int err) Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are queue-4.14/crypto-caam-fix-null-dereference-at-error-path.patch queue-4.14/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch queue-4.14/crypto-arm-arm64-fix-random-regeneration-of-s_shipped.patch queue-4.14/crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch queue-4.14/crypto-inside-secure-fix-clock-management.patch queue-4.14/crypto-lrw-free-rctx-ext-with-kzfree.patch queue-4.14/crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.patch queue-4.14/crypto-ahash-fix-early-termination-in-hash-walk.patch

7 years, 5 months

1
0
0 0

Patch "crypto: ccp - return an actual key size from RSA max_size callback" 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 crypto: ccp - return an actual key size from RSA max_size callback 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: crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.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 0a9eb80e643064266868bd2fb2cd608e669309b0 Mon Sep 17 00:00:00 2001 From: "Maciej S. Szmigiero" <mail(a)maciej.szmigiero.name> Date: Sat, 24 Feb 2018 17:03:21 +0100 Subject: crypto: ccp - return an actual key size from RSA max_size callback From: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> commit 0a9eb80e643064266868bd2fb2cd608e669309b0 upstream. rsa-pkcs1pad uses a value returned from a RSA implementation max_size callback as a size of an input buffer passed to the RSA implementation for encrypt and sign operations. CCP RSA implementation uses a hardware input buffer which size depends only on the current RSA key length, so it should return this key length in the max_size callback, too. This also matches what the kernel software RSA implementation does. Previously, the value returned from this callback was always the maximum RSA key size the CCP hardware supports. This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd() tried to copy this large input buffer into a RSA key length-sized hardware input buffer. Signed-off-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP") Cc: stable(a)vger.kernel.org Acked-by: Gary R Hook <gary.hook(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/ccp/ccp-crypto-rsa.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/crypto/ccp/ccp-crypto-rsa.c +++ b/drivers/crypto/ccp/ccp-crypto-rsa.c @@ -60,10 +60,9 @@ static int ccp_rsa_complete(struct crypt static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm) { - if (ccp_version() > CCP_VERSION(3, 0)) - return CCP5_RSA_MAXMOD; - else - return CCP_RSA_MAXMOD; + struct ccp_ctx *ctx = akcipher_tfm_ctx(tfm); + + return ctx->u.rsa.n_len; } static int ccp_rsa_crypt(struct akcipher_request *req, bool encrypt) Patches currently in stable-queue which might be from mail(a)maciej.szmigiero.name are queue-4.14/crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch

7 years, 5 months

1
0
0 0

Patch "crypto: inside-secure - fix clock management" 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 crypto: inside-secure - fix clock management 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: crypto-inside-secure-fix-clock-management.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 f962eb46e7a9b98a58d2483f5eb216e738fec732 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT <gregory.clement(a)bootlin.com> Date: Tue, 13 Mar 2018 17:48:40 +0100 Subject: crypto: inside-secure - fix clock management From: Gregory CLEMENT <gregory.clement(a)bootlin.com> commit f962eb46e7a9b98a58d2483f5eb216e738fec732 upstream. In this driver the clock is got but never put when the driver is removed or if there is an error in the probe. Using the managed version of clk_get() allows to let the kernel take care of it. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") cc: stable(a)vger.kernel.org Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/inside-secure/safexcel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/crypto/inside-secure/safexcel.c +++ b/drivers/crypto/inside-secure/safexcel.c @@ -789,7 +789,7 @@ static int safexcel_probe(struct platfor return PTR_ERR(priv->base); } - priv->clk = of_clk_get(dev->of_node, 0); + priv->clk = devm_clk_get(&pdev->dev, NULL); if (!IS_ERR(priv->clk)) { ret = clk_prepare_enable(priv->clk); if (ret) { Patches currently in stable-queue which might be from gregory.clement(a)bootlin.com are queue-4.14/crypto-inside-secure-fix-clock-management.patch

7 years, 5 months

1
0
0 0

Patch "crypto: caam - Fix null dereference at error path" 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 crypto: caam - Fix null dereference at error path 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: crypto-caam-fix-null-dereference-at-error-path.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 b85149f6f5d5a9279f29a73b2e95342f4d465e73 Mon Sep 17 00:00:00 2001 From: Rui Miguel Silva <rui.silva(a)linaro.org> Date: Thu, 22 Feb 2018 14:22:47 +0000 Subject: crypto: caam - Fix null dereference at error path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Rui Miguel Silva <rui.silva(a)linaro.org> commit b85149f6f5d5a9279f29a73b2e95342f4d465e73 upstream. caam_remove already removes the debugfs entry, so we need to remove the one immediately before calling caam_remove. This fix a NULL dereference at error paths is caam_probe fail. Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support") Tested-by: Ryan Harkin <ryan.harkin(a)linaro.org> Cc: "Horia Geantă" <horia.geanta(a)nxp.com> Cc: Aymen Sghaier <aymen.sghaier(a)nxp.com> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Lukas Auer <lukas.auer(a)aisec.fraunhofer.de> Cc: <stable(a)vger.kernel.org> # 4.12+ Reviewed-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Rui Miguel Silva <rui.silva(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/caam/ctrl.c | 3 --- 1 file changed, 3 deletions(-) --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -813,9 +813,6 @@ static int caam_probe(struct platform_de return 0; caam_remove: -#ifdef CONFIG_DEBUG_FS - debugfs_remove_recursive(ctrlpriv->dfs_root); -#endif caam_remove(pdev); return ret; Patches currently in stable-queue which might be from rui.silva(a)linaro.org are queue-4.14/crypto-caam-fix-null-dereference-at-error-path.patch

7 years, 5 months

1
0
0 0

Patch "crypto: ahash - Fix early termination in hash walk" 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 crypto: ahash - Fix early termination in hash walk 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: crypto-ahash-fix-early-termination-in-hash-walk.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 900a081f6912a8985dc15380ec912752cb66025a Mon Sep 17 00:00:00 2001 From: Herbert Xu <herbert(a)gondor.apana.org.au> Date: Mon, 26 Mar 2018 08:53:25 +0800 Subject: crypto: ahash - Fix early termination in hash walk From: Herbert Xu <herbert(a)gondor.apana.org.au> commit 900a081f6912a8985dc15380ec912752cb66025a upstream. When we have an unaligned SG list entry where there is no leftover aligned data, the hash walk code will incorrectly return zero as if the entire SG list has been processed. This patch fixes it by moving onto the next page instead. Reported-by: Eli Cooper <elicooper(a)gmx.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/ahash.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/crypto/ahash.c +++ b/crypto/ahash.c @@ -92,13 +92,14 @@ int crypto_hash_walk_done(struct crypto_ if (nbytes && walk->offset & alignmask && !err) { walk->offset = ALIGN(walk->offset, alignmask + 1); - walk->data += walk->offset; - nbytes = min(nbytes, ((unsigned int)(PAGE_SIZE)) - walk->offset); walk->entrylen -= nbytes; - return nbytes; + if (nbytes) { + walk->data += walk->offset; + return nbytes; + } } if (walk->flags & CRYPTO_ALG_ASYNC) Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are queue-4.14/crypto-caam-fix-null-dereference-at-error-path.patch queue-4.14/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch queue-4.14/crypto-arm-arm64-fix-random-regeneration-of-s_shipped.patch queue-4.14/crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch queue-4.14/crypto-inside-secure-fix-clock-management.patch queue-4.14/crypto-lrw-free-rctx-ext-with-kzfree.patch queue-4.14/crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.patch queue-4.14/crypto-ahash-fix-early-termination-in-hash-walk.patch

7 years, 5 months

1
0
0 0

Patch "crypto: arm, arm64 - Fix random regeneration of S_shipped" 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 crypto: arm,arm64 - Fix random regeneration of S_shipped 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: crypto-arm-arm64-fix-random-regeneration-of-s_shipped.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 6aaf49b495b446ff6eec0ac983f781ca0dc56a73 Mon Sep 17 00:00:00 2001 From: Leonard Crestez <leonard.crestez(a)nxp.com> Date: Tue, 13 Mar 2018 22:17:23 +0200 Subject: crypto: arm,arm64 - Fix random regeneration of S_shipped From: Leonard Crestez <leonard.crestez(a)nxp.com> commit 6aaf49b495b446ff6eec0ac983f781ca0dc56a73 upstream. The decision to rebuild .S_shipped is made based on the relative timestamps of .S_shipped and .pl files but git makes this essentially random. This means that the perl script might run anyway (usually at most once per checkout), defeating the whole purpose of _shipped. Fix by skipping the rule unless explicit make variables are provided: REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO. This can produce nasty occasional build failures downstream, for example for toolchains with broken perl. The solution is minimally intrusive to make it easier to push into stable. Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379 Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com> Cc: <stable(a)vger.kernel.org> Reviewed-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/crypto/Makefile | 2 ++ arch/arm64/crypto/Makefile | 2 ++ 2 files changed, 4 insertions(+) --- a/arch/arm/crypto/Makefile +++ b/arch/arm/crypto/Makefile @@ -54,6 +54,7 @@ crct10dif-arm-ce-y := crct10dif-ce-core. crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o +ifdef REGENERATE_ARM_CRYPTO quiet_cmd_perl = PERL $@ cmd_perl = $(PERL) $(<) > $(@) @@ -62,5 +63,6 @@ $(src)/sha256-core.S_shipped: $(src)/sha $(src)/sha512-core.S_shipped: $(src)/sha512-armv4.pl $(call cmd,perl) +endif .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S --- a/arch/arm64/crypto/Makefile +++ b/arch/arm64/crypto/Makefile @@ -58,6 +58,7 @@ CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_ $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE $(call if_changed_rule,cc_o_c) +ifdef REGENERATE_ARM64_CRYPTO quiet_cmd_perlasm = PERLASM $@ cmd_perlasm = $(PERL) $(<) void $(@) @@ -66,5 +67,6 @@ $(src)/sha256-core.S_shipped: $(src)/sha $(src)/sha512-core.S_shipped: $(src)/sha512-armv8.pl $(call cmd,perlasm) +endif .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S Patches currently in stable-queue which might be from leonard.crestez(a)nxp.com are queue-4.14/crypto-arm-arm64-fix-random-regeneration-of-s_shipped.patch

7 years, 5 months

1
0
0 0

Patch "USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator" 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 USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator 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: usb-serial-ftdi_sio-add-support-for-harman-firmwarehubemulator.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 6555ad13a01952c16485c82a52ad1f3e07e34b3a Mon Sep 17 00:00:00 2001 From: Clemens Werther <clemens.werther(a)gmail.com> Date: Fri, 16 Mar 2018 10:20:46 +0100 Subject: USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator From: Clemens Werther <clemens.werther(a)gmail.com> commit 6555ad13a01952c16485c82a52ad1f3e07e34b3a upstream. Add device id for Harman FirmwareHubEmulator to make the device auto-detectable by the driver. Signed-off-by: Clemens Werther <clemens.werther(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 6 ++++++ 2 files changed, 7 insertions(+) --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -936,6 +936,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(FTDI_VID, FTDI_SCIENCESCOPE_LS_LOGBOOK_PID) }, { USB_DEVICE(FTDI_VID, FTDI_SCIENCESCOPE_HS_LOGBOOK_PID) }, { USB_DEVICE(FTDI_VID, FTDI_CINTERION_MC55I_PID) }, + { USB_DEVICE(FTDI_VID, FTDI_FHE_PID) }, { USB_DEVICE(FTDI_VID, FTDI_DOTEC_PID) }, { USB_DEVICE(QIHARDWARE_VID, MILKYMISTONE_JTAGSERIAL_PID), .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk }, --- a/drivers/usb/serial/ftdi_sio_ids.h +++ b/drivers/usb/serial/ftdi_sio_ids.h @@ -1425,6 +1425,12 @@ #define FTDI_CINTERION_MC55I_PID 0xA951 /* + * Product: FirmwareHubEmulator + * Manufacturer: Harman Becker Automotive Systems + */ +#define FTDI_FHE_PID 0xA9A0 + +/* * Product: Comet Caller ID decoder * Manufacturer: Crucible Technologies */ Patches currently in stable-queue which might be from clemens.werther(a)gmail.com are queue-3.18/usb-serial-ftdi_sio-add-support-for-harman-firmwarehubemulator.patch

7 years, 5 months

1
0
0 0

Patch "USB: serial: cp210x: add ELDAT Easywave RX09 id" 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 USB: serial: cp210x: add ELDAT Easywave RX09 id 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: usb-serial-cp210x-add-eldat-easywave-rx09-id.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 1f1e82f74c0947e40144688c9e36abe4b3999f49 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Tue, 6 Mar 2018 09:32:43 +0100 Subject: USB: serial: cp210x: add ELDAT Easywave RX09 id From: Johan Hovold <johan(a)kernel.org> commit 1f1e82f74c0947e40144688c9e36abe4b3999f49 upstream. Add device id for ELDAT Easywave RX09 tranceiver. Reported-by: Jan Jansen <nattelip(a)hotmail.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -149,6 +149,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x12B8, 0xEC62) }, /* Link G4+ ECU */ { USB_DEVICE(0x13AD, 0x9999) }, /* Baltech card reader */ { USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */ + { USB_DEVICE(0x155A, 0x1006) }, /* ELDAT Easywave RX09 */ { USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal Automation Controller */ { USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC Interface */ { USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface */ Patches currently in stable-queue which might be from johan(a)kernel.org are queue-3.18/usb-serial-ftdi_sio-add-support-for-harman-firmwarehubemulator.patch queue-3.18/usb-serial-ftdi_sio-add-rt-systems-vx-8-cable.patch queue-3.18/usb-serial-cp210x-add-eldat-easywave-rx09-id.patch

7 years, 5 months

1
0
0 0

Patch "parport_pc: Add support for WCH CH382L PCI-E single parallel port card." 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 parport_pc: Add support for WCH CH382L PCI-E single parallel port card. 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: parport_pc-add-support-for-wch-ch382l-pci-e-single-parallel-port-card.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 823f7923833c6cc2b16e601546d607dcfb368004 Mon Sep 17 00:00:00 2001 From: Alexander Gerasiov <gq(a)redlab-i.ru> Date: Sun, 4 Feb 2018 02:50:22 +0300 Subject: parport_pc: Add support for WCH CH382L PCI-E single parallel port card. From: Alexander Gerasiov <gq(a)redlab-i.ru> commit 823f7923833c6cc2b16e601546d607dcfb368004 upstream. WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382 but serial ports are not soldered on board. Detected as Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850]) Signed-off-by: Alexander Gerasiov <gq(a)redlab-i.ru> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/parport/parport_pc.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards { netmos_9901, netmos_9865, quatech_sppxp100, + wch_ch382l, }; @@ -2708,6 +2709,7 @@ static struct parport_pc_pci { /* netmos_9901 */ { 1, { { 0, -1 }, } }, /* netmos_9865 */ { 1, { { 0, -1 }, } }, /* quatech_sppxp100 */ { 1, { { 0, 1 }, } }, + /* wch_ch382l */ { 1, { { 2, -1 }, } }, }; static const struct pci_device_id parport_pc_pci_tbl[] = { @@ -2797,6 +2799,8 @@ static const struct pci_device_id parpor /* Quatech SPPXP-100 Parallel port PCI ExpressCard */ { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 }, + /* WCH CH382L PCI-E single parallel port card */ + { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l }, { 0, } /* terminate list */ }; MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl); Patches currently in stable-queue which might be from gq(a)redlab-i.ru are queue-3.18/parport_pc-add-support-for-wch-ch382l-pci-e-single-parallel-port-card.patch

7 years, 5 months

1
0
0 0

Patch "USB: serial: ftdi_sio: add RT Systems VX-8 cable" 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 USB: serial: ftdi_sio: add RT Systems VX-8 cable 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: usb-serial-ftdi_sio-add-rt-systems-vx-8-cable.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 9608e5c0f079390473b484ef92334dfd3431bb89 Mon Sep 17 00:00:00 2001 From: Major Hayden <major(a)mhtx.net> Date: Fri, 23 Feb 2018 14:29:54 -0600 Subject: USB: serial: ftdi_sio: add RT Systems VX-8 cable From: Major Hayden <major(a)mhtx.net> commit 9608e5c0f079390473b484ef92334dfd3431bb89 upstream. This patch adds a device ID for the RT Systems cable used to program Yaesu VX-8R/VX-8DR handheld radios. It uses the main FTDI VID instead of the common RT Systems VID. Signed-off-by: Major Hayden <major(a)mhtx.net> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 3 +++ 2 files changed, 4 insertions(+) --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -773,6 +773,7 @@ static const struct usb_device_id id_tab .driver_info = (kernel_ulong_t)&ftdi_NDI_device_quirk }, { USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) }, { USB_DEVICE(NOVITUS_VID, NOVITUS_BONO_E_PID) }, + { USB_DEVICE(FTDI_VID, RTSYSTEMS_USB_VX8_PID) }, { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) }, { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) }, { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) }, --- a/drivers/usb/serial/ftdi_sio_ids.h +++ b/drivers/usb/serial/ftdi_sio_ids.h @@ -903,6 +903,9 @@ /* * RT Systems programming cables for various ham radios */ +/* This device uses the VID of FTDI */ +#define RTSYSTEMS_USB_VX8_PID 0x9e50 /* USB-VX8 USB to 7 pin modular plug for Yaesu VX-8 radio */ + #define RTSYSTEMS_VID 0x2100 /* Vendor ID */ #define RTSYSTEMS_USB_S03_PID 0x9001 /* RTS-03 USB to Serial Adapter */ #define RTSYSTEMS_USB_59_PID 0x9e50 /* USB-59 USB to 8 pin plug */ Patches currently in stable-queue which might be from major(a)mhtx.net are queue-3.18/usb-serial-ftdi_sio-add-rt-systems-vx-8-cable.patch

7 years, 5 months

1
0
0 0

Patch "media: usbtv: prevent double free in error case" 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 media: usbtv: prevent double free in error case 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: media-usbtv-prevent-double-free-in-error-case.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 50e7044535537b2a54c7ab798cd34c7f6d900bd2 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Mon, 8 Jan 2018 09:21:07 -0500 Subject: media: usbtv: prevent double free in error case From: Oliver Neukum <oneukum(a)suse.com> commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream. Quoting the original report: It looks like there is a double-free vulnerability in Linux usbtv driver on an error path of usbtv_probe function. When audio registration fails, usbtv_video_free function ends up freeing usbtv data structure, which gets freed the second time under usbtv_video_fail label. usbtv_audio_fail: usbtv_video_free(usbtv); => v4l2_device_put(&usbtv->v4l2_dev); => v4l2_device_put => kref_put => v4l2_device_release => usbtv_release (CALLBACK) => kfree(usbtv) (1st time) usbtv_video_fail: usb_set_intfdata(intf, NULL); usb_put_dev(usbtv->udev); kfree(usbtv); (2nd time) So, as we have refcounting, use it Reported-by: Yavuz, Tuba <tuba(a)ece.ufl.edu> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> CC: stable(a)vger.kernel.org Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/usbtv/usbtv-core.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -95,6 +95,8 @@ static int usbtv_probe(struct usb_interf return 0; usbtv_audio_fail: + /* we must not free at this point */ + usb_get_dev(usbtv->udev); usbtv_video_free(usbtv); usbtv_video_fail: Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-3.18/media-usbtv-prevent-double-free-in-error-case.patch

7 years, 5 months

1
0
0 0

Patch "mei: remove dev_err message on an unsupported ioctl" 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 mei: remove dev_err message on an unsupported ioctl 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: mei-remove-dev_err-message-on-an-unsupported-ioctl.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 bb0829a741792b56c908d7745bc0b2b540293bcc Mon Sep 17 00:00:00 2001 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 27 Feb 2018 16:21:05 +0000 Subject: mei: remove dev_err message on an unsupported ioctl From: Colin Ian King <colin.king(a)canonical.com> commit bb0829a741792b56c908d7745bc0b2b540293bcc upstream. Currently the driver spams the kernel log on unsupported ioctls which is unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway. I suspect this was originally for debugging purposes but it really is not required so remove it. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/main.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/misc/mei/main.c +++ b/drivers/misc/mei/main.c @@ -556,7 +556,6 @@ static long mei_ioctl(struct file *file, break; default: - dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd); rets = -ENOIOCTLCMD; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-3.18/mei-remove-dev_err-message-on-an-unsupported-ioctl.patch

7 years, 5 months

1
0
0 0

Patch "crypto: ahash - Fix early termination in hash walk" 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: ahash - Fix early termination in hash walk 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-ahash-fix-early-termination-in-hash-walk.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 900a081f6912a8985dc15380ec912752cb66025a Mon Sep 17 00:00:00 2001 From: Herbert Xu <herbert(a)gondor.apana.org.au> Date: Mon, 26 Mar 2018 08:53:25 +0800 Subject: crypto: ahash - Fix early termination in hash walk From: Herbert Xu <herbert(a)gondor.apana.org.au> commit 900a081f6912a8985dc15380ec912752cb66025a upstream. When we have an unaligned SG list entry where there is no leftover aligned data, the hash walk code will incorrectly return zero as if the entire SG list has been processed. This patch fixes it by moving onto the next page instead. Reported-by: Eli Cooper <elicooper(a)gmx.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/ahash.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/crypto/ahash.c +++ b/crypto/ahash.c @@ -90,13 +90,14 @@ int crypto_hash_walk_done(struct crypto_ if (nbytes && walk->offset & alignmask && !err) { walk->offset = ALIGN(walk->offset, alignmask + 1); - walk->data += walk->offset; - nbytes = min(nbytes, ((unsigned int)(PAGE_SIZE)) - walk->offset); walk->entrylen -= nbytes; - return nbytes; + if (nbytes) { + walk->data += walk->offset; + return nbytes; + } } if (walk->flags & CRYPTO_ALG_ASYNC) Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are queue-3.18/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch queue-3.18/crypto-ahash-fix-early-termination-in-hash-walk.patch

7 years, 5 months

1
0
0 0

Patch "crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one" 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: x86/cast5-avx - fix ECB encryption when long sg follows short one 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-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.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 8f461b1e02ed546fbd0f11611138da67fd85a30f Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Mon, 19 Feb 2018 23:48:12 -0800 Subject: crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one From: Eric Biggers <ebiggers(a)google.com> commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream. With ecb-cast5-avx, if a 128+ byte scatterlist element followed a shorter one, then the algorithm accidentally encrypted/decrypted only 8 bytes instead of the expected 128 bytes. Fix it by setting the encryption/decryption 'fn' correctly. Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers") Cc: <stable(a)vger.kernel.org> # v3.8+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/cast5_avx_glue.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/crypto/cast5_avx_glue.c +++ b/arch/x86/crypto/cast5_avx_glue.c @@ -67,8 +67,6 @@ static int ecb_crypt(struct blkcipher_de void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src); int err; - fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way; - err = blkcipher_walk_virt(desc, walk); desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP; @@ -80,6 +78,7 @@ static int ecb_crypt(struct blkcipher_de /* Process multi-block batch */ if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) { + fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way; do { fn(ctx, wdst, wsrc); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-3.18/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch queue-3.18/libata-fix-length-validation-of-atapi-relayed-scsi-commands.patch queue-3.18/libata-remove-warn-for-dma-or-pio-command-without-data.patch

7 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] crypto: talitos - fix IPsec cipher in length" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2b1227301a8e4729409694e323b72c064c47cb6b Mon Sep 17 00:00:00 2001 From: LEROY Christophe <christophe.leroy(a)c-s.fr> Date: Thu, 22 Mar 2018 10:57:01 +0100 Subject: [PATCH] crypto: talitos - fix IPsec cipher in length MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the "extent" field of the descriptor pointer. Cc: <stable(a)vger.kernel.org> # 4.8+ Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU") Reported-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Tested-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 9a9788d7d5a8..3cfd53a00dc1 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1146,10 +1146,10 @@ static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count, return count; } -static int talitos_sg_map(struct device *dev, struct scatterlist *src, - unsigned int len, struct talitos_edesc *edesc, - struct talitos_ptr *ptr, - int sg_count, unsigned int offset, int tbl_off) +static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src, + unsigned int len, struct talitos_edesc *edesc, + struct talitos_ptr *ptr, int sg_count, + unsigned int offset, int tbl_off, int elen) { struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); @@ -1158,6 +1158,7 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src, to_talitos_ptr(ptr, 0, 0, is_sec1); return 1; } + to_talitos_ptr_ext_set(ptr, elen, is_sec1); if (sg_count == 1) { to_talitos_ptr(ptr, sg_dma_address(src) + offset, len, is_sec1); return sg_count; @@ -1166,7 +1167,7 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src, to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, len, is_sec1); return sg_count; } - sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len, + sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len + elen, &edesc->link_tbl[tbl_off]); if (sg_count == 1) { /* Only one segment now, so no link tbl needed*/ @@ -1180,6 +1181,15 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src, return sg_count; } +static int talitos_sg_map(struct device *dev, struct scatterlist *src, + unsigned int len, struct talitos_edesc *edesc, + struct talitos_ptr *ptr, int sg_count, + unsigned int offset, int tbl_off) +{ + return talitos_sg_map_ext(dev, src, len, edesc, ptr, sg_count, offset, + tbl_off, 0); +} + /* * fill in and submit ipsec_esp descriptor */ @@ -1197,7 +1207,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq, unsigned int ivsize = crypto_aead_ivsize(aead); int tbl_off = 0; int sg_count, ret; - int sg_link_tbl_len; + int elen = 0; bool sync_needed = false; struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); @@ -1239,17 +1249,11 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq, * extent is bytes of HMAC postpended to ciphertext, * typically 12 for ipsec */ - sg_link_tbl_len = cryptlen; - - if (is_ipsec_esp) { - to_talitos_ptr_ext_set(&desc->ptr[4], authsize, is_sec1); - - if (desc->hdr & DESC_HDR_MODE1_MDEU_CICV) - sg_link_tbl_len += authsize; - } + if (is_ipsec_esp && (desc->hdr & DESC_HDR_MODE1_MDEU_CICV)) + elen = authsize; - ret = talitos_sg_map(dev, areq->src, sg_link_tbl_len, edesc, - &desc->ptr[4], sg_count, areq->assoclen, tbl_off); + ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[4], + sg_count, areq->assoclen, tbl_off, elen); if (ret > 1) { tbl_off += ret;

7 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] crypto: talitos - fix IPsec cipher in length" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2b1227301a8e4729409694e323b72c064c47cb6b Mon Sep 17 00:00:00 2001 From: LEROY Christophe <christophe.leroy(a)c-s.fr> Date: Thu, 22 Mar 2018 10:57:01 +0100 Subject: [PATCH] crypto: talitos - fix IPsec cipher in length MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the "extent" field of the descriptor pointer. Cc: <stable(a)vger.kernel.org> # 4.8+ Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU") Reported-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Tested-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 9a9788d7d5a8..3cfd53a00dc1 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1146,10 +1146,10 @@ static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count, return count; } -static int talitos_sg_map(struct device *dev, struct scatterlist *src, - unsigned int len, struct talitos_edesc *edesc, - struct talitos_ptr *ptr, - int sg_count, unsigned int offset, int tbl_off) +static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src, + unsigned int len, struct talitos_edesc *edesc, + struct talitos_ptr *ptr, int sg_count, + unsigned int offset, int tbl_off, int elen) { struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); @@ -1158,6 +1158,7 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src, to_talitos_ptr(ptr, 0, 0, is_sec1); return 1; } + to_talitos_ptr_ext_set(ptr, elen, is_sec1); if (sg_count == 1) { to_talitos_ptr(ptr, sg_dma_address(src) + offset, len, is_sec1); return sg_count; @@ -1166,7 +1167,7 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src, to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, len, is_sec1); return sg_count; } - sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len, + sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len + elen, &edesc->link_tbl[tbl_off]); if (sg_count == 1) { /* Only one segment now, so no link tbl needed*/ @@ -1180,6 +1181,15 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src, return sg_count; } +static int talitos_sg_map(struct device *dev, struct scatterlist *src, + unsigned int len, struct talitos_edesc *edesc, + struct talitos_ptr *ptr, int sg_count, + unsigned int offset, int tbl_off) +{ + return talitos_sg_map_ext(dev, src, len, edesc, ptr, sg_count, offset, + tbl_off, 0); +} + /* * fill in and submit ipsec_esp descriptor */ @@ -1197,7 +1207,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq, unsigned int ivsize = crypto_aead_ivsize(aead); int tbl_off = 0; int sg_count, ret; - int sg_link_tbl_len; + int elen = 0; bool sync_needed = false; struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); @@ -1239,17 +1249,11 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq, * extent is bytes of HMAC postpended to ciphertext, * typically 12 for ipsec */ - sg_link_tbl_len = cryptlen; - - if (is_ipsec_esp) { - to_talitos_ptr_ext_set(&desc->ptr[4], authsize, is_sec1); - - if (desc->hdr & DESC_HDR_MODE1_MDEU_CICV) - sg_link_tbl_len += authsize; - } + if (is_ipsec_esp && (desc->hdr & DESC_HDR_MODE1_MDEU_CICV)) + elen = authsize; - ret = talitos_sg_map(dev, areq->src, sg_link_tbl_len, edesc, - &desc->ptr[4], sg_count, areq->assoclen, tbl_off); + ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[4], + sg_count, areq->assoclen, tbl_off, elen); if (ret > 1) { tbl_off += ret;

7 years, 5 months

1
0
0 0

[PATCH v4.9.y 00/27] arm64 meltdown patches

by Mark Rutland

Hi Greg, These patches backport KPTI to v4.9.y (based on v4.9.92), providing protection against meltdown on arm64 platforms. I picked up Alex Shi's backport for review and testing, and as I found a couple of issues to fix up, I'm sending this with my Signed-off-by in the chain, with those fixups applied and noted. To the best of my understanding the code is correct, in the context of the v4.9.y kernel, and I've tested the seires on arm64 hardware available to me. i.e. if this didn't have my Signed-off-by it would have my Reviewed-by and Tested-by tags. Are you happy to pick these up for v4.9.93? Thanks, Mark. AKASHI Takahiro (1): module: extend 'rodata=off' boot cmdline parameter to module mappings Jayachandran C (2): arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs arm64: Turn on KPTI only on CPUs that need it Marc Zyngier (2): arm64: Allow checking of a CPU-local erratum arm64: Force KPTI to be disabled on Cavium ThunderX Mark Rutland (1): arm64: factor out entry stack manipulation Suzuki K Poulose (1): arm64: capabilities: Handle duplicate entries for a capability Will Deacon (20): arm64: mm: Use non-global mappings for kernel space arm64: mm: Move ASID from TTBR0 to TTBR1 arm64: mm: Allocate ASIDs in pairs arm64: mm: Add arm64_kernel_unmapped_at_el0 helper arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI arm64: entry: Add exception trampoline page for exceptions from EL0 arm64: mm: Map entry trampoline into trampoline and kernel page tables arm64: entry: Explicitly pass exception level to kernel_ventry macro arm64: entry: Hook up entry trampoline to exception vectors arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 arm64: kaslr: Put kernel vectors address in separate data page arm64: use RET instruction for exiting the trampoline arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry arm64: Take into account ID_AA64PFR0_EL1.CSV3 arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0() arm64: kpti: Add ->enable callback to remap swapper using nG mappings arm64: entry: Reword comment about post_ttbr_update_workaround arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives arch/arm64/Kconfig | 12 ++ arch/arm64/include/asm/assembler.h | 3 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cputype.h | 3 + arch/arm64/include/asm/fixmap.h | 6 + arch/arm64/include/asm/mmu.h | 11 ++ arch/arm64/include/asm/mmu_context.h | 7 ++ arch/arm64/include/asm/pgtable-hwdef.h | 1 + arch/arm64/include/asm/pgtable-prot.h | 35 +++--- arch/arm64/include/asm/pgtable.h | 1 + arch/arm64/include/asm/proc-fns.h | 6 - arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/include/asm/tlbflush.h | 16 ++- arch/arm64/kernel/asm-offsets.c | 6 +- arch/arm64/kernel/cpu-reset.S | 2 +- arch/arm64/kernel/cpufeature.c | 135 ++++++++++++++++++--- arch/arm64/kernel/entry.S | 188 ++++++++++++++++++++++++---- arch/arm64/kernel/head.S | 2 +- arch/arm64/kernel/process.c | 12 +- arch/arm64/kernel/sleep.S | 2 +- arch/arm64/kernel/vmlinux.lds.S | 22 +++- arch/arm64/mm/context.c | 25 ++-- arch/arm64/mm/mmu.c | 31 +++++ arch/arm64/mm/proc.S | 216 +++++++++++++++++++++++++++++++-- include/linux/init.h | 3 + init/main.c | 7 +- kernel/module.c | 20 ++- 27 files changed, 675 insertions(+), 101 deletions(-) -- 2.11.0

7 years, 5 months

6
62
0 0

Re: [PATCH v2] Btrfs: fix NULL pointer dereference in log_dir_items

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 9.9156) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

3
3
0 0

[PATCH] drm/i915/dp: Send DPCD ON for MST before phy_up

by Lyude Paul

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

7 years, 5 months

3
2
0 0

Re: [PATCH] Add Second Fan Support for Thinkpad P50

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 9.2381) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

2
1
0 0

Re: [PATCH] usbip: vhci_hcd: Fix usb device and sockfd leaks

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 10.6103) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Failed to apply! Possible dependencies: f0f1beb8f155 ("usbip: vhci_hcd: Fix usb device and sockfd leaks") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

2
1
0 0

Re: [PATCH 5/6] clocksource/drivers/imx-tpm: Correct some registers operation flow

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 11.8806) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: 506a7be93ff7 ("clocksource/drivers/imx-tpm: Correct some registers operation flow") v4.4.126: Failed to apply! Possible dependencies: 506a7be93ff7 ("clocksource/drivers/imx-tpm: Correct some registers operation flow") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 3/5] MIPS: perf: Fix perf with MT counting other threads

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 16.4885) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Failed to apply! Possible dependencies: e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads") v4.14.32: Failed to apply! Possible dependencies: e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads") v4.9.92: Failed to apply! Possible dependencies: 4e099ca64578 ("MIPS: perf: Use correct VPE ID when setting up VPE tracing") e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads") v4.4.126: Failed to apply! Possible dependencies: 4e099ca64578 ("MIPS: perf: Use correct VPE ID when setting up VPE tracing") e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 1/5] MIPS: perf: More robustly probe for the presence of per-tc counters

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 7.7428) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Failed to apply! Possible dependencies: dddf796db4e3 ("MIPS: perf: More robustly probe for the presence of per-tc counters") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 2/2] usb: dwc2: gadget: Change default values

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 8.8219) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Failed to apply! Possible dependencies: 808260f0b5d6 ("usb: dwc2: gadget: Change default values") v4.14.32: Failed to apply! Possible dependencies: 808260f0b5d6 ("usb: dwc2: gadget: Change default values") v4.9.92: Failed to apply! Possible dependencies: 6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support") 808260f0b5d6 ("usb: dwc2: gadget: Change default values") v4.4.126: Failed to apply! Possible dependencies: 6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support") 808260f0b5d6 ("usb: dwc2: gadget: Change default values") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 0/2] usb: dwc2: gadget: Fixes for LPM

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 8.8219) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Failed to apply! Possible dependencies: 9fca971e94df ("usb: dwc2: gadget: Change default values") v4.14.32: Failed to apply! Possible dependencies: 9fca971e94df ("usb: dwc2: gadget: Change default values") v4.9.92: Failed to apply! Possible dependencies: 6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support") 9fca971e94df ("usb: dwc2: gadget: Change default values") v4.4.126: Failed to apply! Possible dependencies: 6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support") 9fca971e94df ("usb: dwc2: gadget: Change default values") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 83.4612) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Failed to apply! Possible dependencies: 40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers") v4.14.32: Failed to apply! Possible dependencies: 40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers") v4.9.92: Failed to apply! Possible dependencies: 40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers") 52510ee93488 ("soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC") v4.4.126: Failed to apply! Possible dependencies: 40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers") 52510ee93488 ("soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

by Sasha Levin

Hi. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 72b39cfc4d75 ("mm, memory_hotplug: do not fail offlining too early"). The bot has also determined it's probably a bug fixing patch. (score: 77.7460) The bot has tested the following trees: v4.15.15 . v4.15.15: Build OK! -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH net-next] pptp: remove a buggy dst release in pptp_connect()

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 30.1120) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

[PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS

by Lyude Paul

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when none of the sinks are turned on since it's possible for us to have a single atomic commit which results in disabling each downstream sink, followed by subsequently re-enabling each sink. If we don't do this, we'll end up stalling any pending ESI interrupts from the sink for up to 1ms. Unfortunately, dropping ESIs during this timespan makes it so that link fallback retraining for MST (which I will be submitting to the ML shortly) fails due to the channel EQ failure interrupts potentially getting dropped. Additionally, when performing a modeset that brings the hub status's link status from bad -> good having ESIs disabled for that long causes us to miss the hub's response to us trying to start link training as well. Since any sink with MST is going to support DisplayPort 1.2 anyway, save us the hassle of trying to wait until the sink comes back up and just never shut the aux block down. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..0479c377981b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) return; if (mode != DRM_MODE_DPMS_ON) { + unsigned char data = intel_dp->is_mst ? + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; + if (downstream_hpd_needs_d0(intel_dp)) return; - ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, - DP_SET_POWER_D3); + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data); } else { struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); -- 2.14.3

7 years, 5 months

6
15
0 0

Re: Re: KASAN: use-after-free Read in snd_pcm_timer_resolution

by Sasha Levin

Hi. [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has also determined it's probably a bug fixing patch. (score: 98.8113) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 6.9494) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

by Sasha Levin

Hi. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 9.8897) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

[PATCH] fanotify: fix logic of events on child

by Amir Goldstein

When event on child inodes are sent to the parent inode mark and parent inode mark was not marked with FAN_EVENT_ON_CHILD, the event will not be delivered to the listener process. However, if the same process also has a mount mark, the event to the parent inode will be delivered regadless of the mount mark mask. This behavior is incorrect in the case where the mount mark mask does not contain the specific event type. For example, the process adds a mark on a directory with mask FAN_MODIFY (without FAN_EVENT_ON_CHILD) and a mount mark with mask FAN_CLOSE_NOWRITE (without FAN_ONDIR). A modify event on a file inside that directory (and inside that mount) should not create a FAN_MODIFY event, because neither of the marks requested to get that event on the file. Fixes: 1968f5eed54c ("fanotify: use both marks when possible") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> --- fs/notify/fanotify/fanotify.c | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) Jan, While working on the super block mark patches [1], I stumbbled on this bug. I figured I might as well send the fix out now. I have written an LTP test [2] to reproduce it. Thanks, Amir. [1] https://github.com/amir73il/linux/commits/fanotify_sb [2] https://github.com/amir73il/ltp/commits/fanotify_sb diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 6702a6a0bbb5..e0e6a9d627df 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -92,7 +92,7 @@ static bool fanotify_should_send_event(struct fsnotify_mark *inode_mark, u32 event_mask, const void *data, int data_type) { - __u32 marks_mask, marks_ignored_mask; + __u32 marks_mask = 0, marks_ignored_mask = 0; const struct path *path = data; pr_debug("%s: inode_mark=%p vfsmnt_mark=%p mask=%x data=%p" @@ -108,24 +108,20 @@ static bool fanotify_should_send_event(struct fsnotify_mark *inode_mark, !d_can_lookup(path->dentry)) return false; - if (inode_mark && vfsmnt_mark) { - marks_mask = (vfsmnt_mark->mask | inode_mark->mask); - marks_ignored_mask = (vfsmnt_mark->ignored_mask | inode_mark->ignored_mask); - } else if (inode_mark) { - /* - * if the event is for a child and this inode doesn't care about - * events on the child, don't send it! - */ - if ((event_mask & FS_EVENT_ON_CHILD) && - !(inode_mark->mask & FS_EVENT_ON_CHILD)) - return false; - marks_mask = inode_mark->mask; - marks_ignored_mask = inode_mark->ignored_mask; - } else if (vfsmnt_mark) { - marks_mask = vfsmnt_mark->mask; - marks_ignored_mask = vfsmnt_mark->ignored_mask; - } else { - BUG(); + /* + * if the event is for a child and this inode doesn't care about + * events on the child, don't send it! + */ + if (inode_mark && + (!(event_mask & FS_EVENT_ON_CHILD) || + (inode_mark->mask & FS_EVENT_ON_CHILD))) { + marks_mask |= inode_mark->mask; + marks_ignored_mask |= inode_mark->ignored_mask; + } + + if (vfsmnt_mark) { + marks_mask |= vfsmnt_mark->mask; + marks_ignored_mask |= vfsmnt_mark->ignored_mask; } if (d_is_dir(path->dentry) && -- 2.7.4

7 years, 5 months

2
1
0 0

[PATCH] powerpc/64s: Fix dt_cpu_ftrs to have restore_cpu clear unwanted LPCR bits

by Nicholas Piggin

Presently the dt_cpu_ftrs restore_cpu will only add bits to the LPCR for secondaries, but some bits must be removed (e.g., UPRT for HPT). Not clearing these bits on secondaries causes checkstops when booting with disable_radix. restore_cpu can not just set LPCR, because it is also called by the idle wakeup code which relies on opal_slw_set_reg to restore the value of LPCR, at least on P8 which does not save LPCR to stack in the idle code. Fix this by including a mask of bits to clear from LPCR as well, which is used by restore_cpu. This is a little messy now, but it's a minimal fix that can be backported. Longer term, the idle SPR save/restore code can be reworked to completely avoid calls to restore_cpu, then restore_cpu would be able to unconditionally set LPCR to match boot processor environment. Fixes: 5a61ef74f269f ("powerpc/64s: Support new device tree binding for discovering CPU features") Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> --- I tested this fix and it boots a POWER9 with disable_radix, where previously it checkstopped. Deeper idle states seem to work too, after they're enabled with a firmware override. arch/powerpc/kernel/dt_cpu_ftrs.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c index 11a3a4fed3fb..ed7605d8fd2d 100644 --- a/arch/powerpc/kernel/dt_cpu_ftrs.c +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c @@ -83,6 +83,7 @@ static int hv_mode; static struct { u64 lpcr; + u64 lpcr_clear; u64 hfscr; u64 fscr; } system_registers; @@ -91,6 +92,8 @@ static void (*init_pmu_registers)(void); static void __restore_cpu_cpufeatures(void) { + u64 lpcr; + /* * LPCR is restored by the power on engine already. It can be changed * after early init e.g., by radix enable, and we have no unified API @@ -103,8 +106,10 @@ static void __restore_cpu_cpufeatures(void) * The best we can do to accommodate secondary boot and idle restore * for now is "or" LPCR with existing. */ - - mtspr(SPRN_LPCR, system_registers.lpcr | mfspr(SPRN_LPCR)); + lpcr = mfspr(SPRN_LPCR); + lpcr |= system_registers.lpcr; + lpcr &= ~system_registers.lpcr_clear; + mtspr(SPRN_LPCR, lpcr); if (hv_mode) { mtspr(SPRN_LPID, 0); mtspr(SPRN_HFSCR, system_registers.hfscr); @@ -324,8 +329,9 @@ static int __init feat_enable_mmu_hash_v3(struct dt_cpu_feature *f) { u64 lpcr; + system_registers.lpcr_clear |= (LPCR_ISL | LPCR_UPRT | LPCR_HR); lpcr = mfspr(SPRN_LPCR); - lpcr &= ~LPCR_ISL; + lpcr &= ~(LPCR_ISL | LPCR_UPRT | LPCR_HR); mtspr(SPRN_LPCR, lpcr); cur_cpu_spec->mmu_features |= MMU_FTRS_HASH_BASE; -- 2.16.3

7 years, 5 months

2
1
0 0

[git:media_tree/fixes] media: v4l2-core: fix size of devnode_nums[] bitarray

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: v4l2-core: fix size of devnode_nums[] bitarray Author: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Thu Apr 5 06:51:15 2018 -0300 The size of devnode_nums[] bit array is too short to store information for VFL_TYPE_TOUCH. That causes it to override other memory regions. Thankfully, on recent reports, it is overriding video_device[] array, trigging a WARN_ON(). Yet, it just warns about the problem, but let the code excecuting, with generates an OOPS: [ 43.177394] WARNING: CPU: 1 PID: 711 at drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 [videodev] [ 43.177396] Modules linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul [ 43.177426] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect [ 43.177466] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel [ 43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1 [ 43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [ 43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev] [ 43.177482] RSP: 0000:ffffa5c5c231b420 EFLAGS: 00010202 [ 43.177484] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000000 [ 43.177485] RDX: ffffffffc0c44cc0 RSI: ffffffffffffffff RDI: ffffffffc0c44cc0 [ 43.177486] RBP: ffffa5c5c231b478 R08: ffffffffc0c96900 R09: ffff8eda1a51f018 [ 43.177487] R10: 0000000000000600 R11: 00000000000003b6 R12: 0000000000000000 [ 43.177488] R13: 0000000000000005 R14: ffffffffc0c96900 R15: ffff8eda1d6d91c0 [ 43.177489] FS: 00007fd2d8ef2480(0000) GS:ffff8eda33480000(0000) knlGS:0000000000000000 [ 43.177490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.177491] CR2: 00007ffe0a6ad01c CR3: 0000000456ae2004 CR4: 00000000003606e0 [ 43.177492] Call Trace: [ 43.177498] ? devres_add+0x5f/0x70 [ 43.177502] rmi_f54_probe+0x437/0x470 [rmi_core] [ 43.177505] rmi_function_probe+0x25/0x30 [rmi_core] [ 43.177507] driver_probe_device+0x310/0x480 [ 43.177509] __device_attach_driver+0x86/0x100 [ 43.177511] ? __driver_attach+0xf0/0xf0 [ 43.177512] bus_for_each_drv+0x6b/0xb0 [ 43.177514] __device_attach+0xdd/0x160 [ 43.177516] device_initial_probe+0x13/0x20 [ 43.177518] bus_probe_device+0x95/0xa0 [ 43.177519] device_add+0x44b/0x680 [ 43.177522] rmi_register_function+0x62/0xd0 [rmi_core] [ 43.177525] rmi_create_function+0x112/0x1a0 [rmi_core] [ 43.177527] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] [ 43.177530] rmi_scan_pdt+0xca/0x1a0 [rmi_core] [ 43.177535] rmi_init_functions+0x5b/0x120 [rmi_core] [ 43.177537] rmi_driver_probe+0x152/0x3c0 [rmi_core] [ 43.177547] ? sysfs_create_link+0x25/0x40 [ 43.177549] driver_probe_device+0x310/0x480 [ 43.177551] __device_attach_driver+0x86/0x100 [ 43.177553] ? __driver_attach+0xf0/0xf0 [ 43.177554] bus_for_each_drv+0x6b/0xb0 [ 43.177556] __device_attach+0xdd/0x160 [ 43.177558] device_initial_probe+0x13/0x20 [ 43.177560] bus_probe_device+0x95/0xa0 [ 43.177561] device_add+0x44b/0x680 [ 43.177564] rmi_register_transport_device+0x84/0x100 [rmi_core] [ 43.177568] rmi_input_configured+0xbf/0x1a0 [hid_rmi] [ 43.177571] ? input_allocate_device+0xdf/0xf0 [ 43.177574] hidinput_connect+0x4a9/0x37a0 [hid] [ 43.177578] hid_connect+0x326/0x3d0 [hid] [ 43.177581] hid_hw_start+0x42/0x70 [hid] [ 43.177583] rmi_probe+0x115/0x510 [hid_rmi] [ 43.177586] hid_device_probe+0xd3/0x150 [hid] [ 43.177588] ? sysfs_create_link+0x25/0x40 [ 43.177590] driver_probe_device+0x310/0x480 [ 43.177592] __driver_attach+0xbf/0xf0 [ 43.177593] ? driver_probe_device+0x480/0x480 [ 43.177595] bus_for_each_dev+0x74/0xb0 [ 43.177597] ? kmem_cache_alloc_trace+0x1a6/0x1c0 [ 43.177599] driver_attach+0x1e/0x20 [ 43.177600] bus_add_driver+0x167/0x260 [ 43.177602] ? 0xffffffffc0cbc000 [ 43.177604] driver_register+0x60/0xe0 [ 43.177605] ? 0xffffffffc0cbc000 [ 43.177607] __hid_register_driver+0x63/0x70 [hid] [ 43.177610] rmi_driver_init+0x23/0x1000 [hid_rmi] [ 43.177612] do_one_initcall+0x52/0x191 [ 43.177615] ? _cond_resched+0x19/0x40 [ 43.177617] ? kmem_cache_alloc_trace+0xa2/0x1c0 [ 43.177619] ? do_init_module+0x27/0x209 [ 43.177621] do_init_module+0x5f/0x209 [ 43.177623] load_module+0x1987/0x1f10 [ 43.177626] ? ima_post_read_file+0x96/0xa0 [ 43.177629] SYSC_finit_module+0xfc/0x120 [ 43.177630] ? SYSC_finit_module+0xfc/0x120 [ 43.177632] SyS_finit_module+0xe/0x10 [ 43.177634] do_syscall_64+0x73/0x130 [ 43.177637] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 43.177638] RIP: 0033:0x7fd2d880b839 [ 43.177639] RSP: 002b:00007ffe0a6b2368 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 43.177641] RAX: ffffffffffffffda RBX: 000055cdd86542e0 RCX: 00007fd2d880b839 [ 43.177641] RDX: 0000000000000000 RSI: 00007fd2d84ea0e5 RDI: 0000000000000016 [ 43.177642] RBP: 00007fd2d84ea0e5 R08: 0000000000000000 R09: 00007ffe0a6b2480 [ 43.177643] R10: 0000000000000016 R11: 0000000000000246 R12: 0000000000000000 [ 43.177644] R13: 000055cdd8688930 R14: 0000000000020000 R15: 000055cdd86542e0 [ 43.177645] Code: 48 c7 c7 54 b4 c3 c0 e8 96 9d ec dd e9 d4 fb ff ff 0f 0b 41 be ea ff ff ff e9 c7 fb ff ff 0f 0b 41 be ea ff ff ff e9 ba fb ff ff <0f> 0b e9 d8 f4 ff ff 83 fa 01 0f 84 c4 02 00 00 48 83 78 68 00 [ 43.177675] ---[ end trace d44d9bc41477c2dd ]--- [ 43.177679] BUG: unable to handle kernel NULL pointer dereference at 0000000000000499 [ 43.177723] IP: __video_register_device+0x1cc/0x1090 [videodev] [ 43.177749] PGD 0 P4D 0 [ 43.177764] Oops: 0000 [#1] SMP PTI [ 43.177780] Modules linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul [ 43.178055] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect [ 43.178337] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel [ 43.178380] CPU: 1 PID: 711 Comm: systemd-udevd Tainted: G W 4.16.0 #1 [ 43.178411] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [ 43.178441] RIP: 0010:__video_register_device+0x1cc/0x1090 [videodev] [ 43.178467] RSP: 0000:ffffa5c5c231b420 EFLAGS: 00010202 [ 43.178490] RAX: ffffffffc0c44cc0 RBX: 0000000000000005 RCX: ffffffffc0c454c0 [ 43.178519] RDX: 0000000000000001 RSI: ffff8eda1d6d9118 RDI: ffffffffc0c44cc0 [ 43.178549] RBP: ffffa5c5c231b478 R08: ffffffffc0c96900 R09: ffff8eda1a51f018 [ 43.178579] R10: 0000000000000600 R11: 00000000000003b6 R12: 0000000000000000 [ 43.178608] R13: 0000000000000005 R14: ffffffffc0c96900 R15: ffff8eda1d6d91c0 [ 43.178636] FS: 00007fd2d8ef2480(0000) GS:ffff8eda33480000(0000) knlGS:0000000000000000 [ 43.178669] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.178693] CR2: 0000000000000499 CR3: 0000000456ae2004 CR4: 00000000003606e0 [ 43.178721] Call Trace: [ 43.178736] ? devres_add+0x5f/0x70 [ 43.178755] rmi_f54_probe+0x437/0x470 [rmi_core] [ 43.178779] rmi_function_probe+0x25/0x30 [rmi_core] [ 43.178805] driver_probe_device+0x310/0x480 [ 43.178828] __device_attach_driver+0x86/0x100 [ 43.178851] ? __driver_attach+0xf0/0xf0 [ 43.178884] bus_for_each_drv+0x6b/0xb0 [ 43.178904] __device_attach+0xdd/0x160 [ 43.178925] device_initial_probe+0x13/0x20 [ 43.178948] bus_probe_device+0x95/0xa0 [ 43.178968] device_add+0x44b/0x680 [ 43.178987] rmi_register_function+0x62/0xd0 [rmi_core] [ 43.181747] rmi_create_function+0x112/0x1a0 [rmi_core] [ 43.184677] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] [ 43.187505] rmi_scan_pdt+0xca/0x1a0 [rmi_core] [ 43.190171] rmi_init_functions+0x5b/0x120 [rmi_core] [ 43.192809] rmi_driver_probe+0x152/0x3c0 [rmi_core] [ 43.195403] ? sysfs_create_link+0x25/0x40 [ 43.198253] driver_probe_device+0x310/0x480 [ 43.201083] __device_attach_driver+0x86/0x100 [ 43.203800] ? __driver_attach+0xf0/0xf0 [ 43.206503] bus_for_each_drv+0x6b/0xb0 [ 43.209291] __device_attach+0xdd/0x160 [ 43.212207] device_initial_probe+0x13/0x20 [ 43.215146] bus_probe_device+0x95/0xa0 [ 43.217885] device_add+0x44b/0x680 [ 43.220597] rmi_register_transport_device+0x84/0x100 [rmi_core] [ 43.223321] rmi_input_configured+0xbf/0x1a0 [hid_rmi] [ 43.226051] ? input_allocate_device+0xdf/0xf0 [ 43.228814] hidinput_connect+0x4a9/0x37a0 [hid] [ 43.231701] hid_connect+0x326/0x3d0 [hid] [ 43.234548] hid_hw_start+0x42/0x70 [hid] [ 43.237302] rmi_probe+0x115/0x510 [hid_rmi] [ 43.239862] hid_device_probe+0xd3/0x150 [hid] [ 43.242558] ? sysfs_create_link+0x25/0x40 [ 43.242828] audit: type=1400 audit(1522795151.600:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine" pid=1151 comm="apparmor_parser" [ 43.244859] driver_probe_device+0x310/0x480 [ 43.244862] __driver_attach+0xbf/0xf0 [ 43.246982] audit: type=1400 audit(1522795151.600:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=1151 comm="apparmor_parser" [ 43.249403] ? driver_probe_device+0x480/0x480 [ 43.249405] bus_for_each_dev+0x74/0xb0 [ 43.253200] audit: type=1400 audit(1522795151.600:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine//snap_update_ns" pid=1151 comm="apparmor_parser" [ 43.254055] ? kmem_cache_alloc_trace+0x1a6/0x1c0 [ 43.256282] audit: type=1400 audit(1522795151.604:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/sbin/dhclient" pid=1152 comm="apparmor_parser" [ 43.258436] driver_attach+0x1e/0x20 [ 43.260875] audit: type=1400 audit(1522795151.604:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1152 comm="apparmor_parser" [ 43.263118] bus_add_driver+0x167/0x260 [ 43.267676] audit: type=1400 audit(1522795151.604:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1152 comm="apparmor_parser" [ 43.268807] ? 0xffffffffc0cbc000 [ 43.268812] driver_register+0x60/0xe0 [ 43.271184] audit: type=1400 audit(1522795151.604:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=1152 comm="apparmor_parser" [ 43.274081] ? 0xffffffffc0cbc000 [ 43.274086] __hid_register_driver+0x63/0x70 [hid] [ 43.288367] rmi_driver_init+0x23/0x1000 [hid_rmi] [ 43.291501] do_one_initcall+0x52/0x191 [ 43.292348] audit: type=1400 audit(1522795151.652:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1242 comm="apparmor_parser" [ 43.294212] ? _cond_resched+0x19/0x40 [ 43.300028] ? kmem_cache_alloc_trace+0xa2/0x1c0 [ 43.303475] ? do_init_module+0x27/0x209 [ 43.306842] do_init_module+0x5f/0x209 [ 43.310269] load_module+0x1987/0x1f10 [ 43.313704] ? ima_post_read_file+0x96/0xa0 [ 43.317174] SYSC_finit_module+0xfc/0x120 [ 43.320754] ? SYSC_finit_module+0xfc/0x120 [ 43.324065] SyS_finit_module+0xe/0x10 [ 43.327387] do_syscall_64+0x73/0x130 [ 43.330909] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 43.334305] RIP: 0033:0x7fd2d880b839 [ 43.337810] RSP: 002b:00007ffe0a6b2368 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 43.341259] RAX: ffffffffffffffda RBX: 000055cdd86542e0 RCX: 00007fd2d880b839 [ 43.344613] RDX: 0000000000000000 RSI: 00007fd2d84ea0e5 RDI: 0000000000000016 [ 43.347962] RBP: 00007fd2d84ea0e5 R08: 0000000000000000 R09: 00007ffe0a6b2480 [ 43.351456] R10: 0000000000000016 R11: 0000000000000246 R12: 0000000000000000 [ 43.354845] R13: 000055cdd8688930 R14: 0000000000020000 R15: 000055cdd86542e0 [ 43.358224] Code: c7 05 ad 12 02 00 00 00 00 00 48 8d 88 00 08 00 00 eb 09 48 83 c0 08 48 39 c1 74 31 48 8b 10 48 85 d2 74 ef 49 8b b7 98 04 00 00 <48> 39 b2 98 04 00 00 75 df 48 63 92 f8 04 00 00 f0 48 0f ab 15 [ 43.361764] RIP: __video_register_device+0x1cc/0x1090 [videodev] RSP: ffffa5c5c231b420 [ 43.365281] CR2: 0000000000000499 This patch fixes the array size and changes the WARN_ON() to return an error, instead of letting the Kernel to proceed with registering. Cc: stable(a)vger.kernel.org # For Kernel 4.16 Fixes: 4839c58f034a ("media: v4l2-dev: convert VFL_TYPE_* into an enum") Reported-by: Peter Geis <pgwipeout(a)gmail.com> Reported-by: Jaak Ristioja <jaak(a)ristioja.ee> Reported-by: Michał Siemek <mihau69(a)gmail.com> Reviewed-by: Hans Verkuil <hans.verkuil(a)cisco.com> Reviewed-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> drivers/media/v4l2-core/v4l2-dev.c | 8 ++++++-- include/media/v4l2-dev.h | 12 ++++++------ 2 files changed, 12 insertions(+), 8 deletions(-) --- diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index 0301fe426a43..1d0b2208e8fb 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -939,10 +939,14 @@ int __video_register_device(struct video_device *vdev, #endif vdev->minor = i + minor_offset; vdev->num = nr; - devnode_set(vdev); /* Should not happen since we thought this minor was free */ - WARN_ON(video_device[vdev->minor] != NULL); + if (WARN_ON(video_device[vdev->minor])) { + mutex_unlock(&videodev_lock); + printk(KERN_ERR "video_device not empty!\n"); + return -ENFILE; + } + devnode_set(vdev); vdev->index = get_index(vdev); video_device[vdev->minor] = vdev; mutex_unlock(&videodev_lock); diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h index 27634e8d2585..f60cf9cf3b9c 100644 --- a/include/media/v4l2-dev.h +++ b/include/media/v4l2-dev.h @@ -33,13 +33,13 @@ */ enum vfl_devnode_type { VFL_TYPE_GRABBER = 0, - VFL_TYPE_VBI = 1, - VFL_TYPE_RADIO = 2, - VFL_TYPE_SUBDEV = 3, - VFL_TYPE_SDR = 4, - VFL_TYPE_TOUCH = 5, + VFL_TYPE_VBI, + VFL_TYPE_RADIO, + VFL_TYPE_SUBDEV, + VFL_TYPE_SDR, + VFL_TYPE_TOUCH, + VFL_TYPE_MAX /* Shall be the last one */ }; -#define VFL_TYPE_MAX VFL_TYPE_TOUCH /** * enum vfl_direction - Identifies if a &struct video_device corresponds

7 years, 5 months

1
0
0 0

[PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

by Mauro Carvalho Chehab

The size of devnode_nums[] bit array is too short to store information for VFL_TYPE_TOUCH. That causes it to override other memory regions. Thankfully, on recent reports, it is overriding video_device[] array, trigging a WARN_ON(). Yet, it just warns about the problem, but let the code excecuting, with generates an OOPS: [ 43.177394] WARNING: CPU: 1 PID: 711 at drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 [videodev] [ 43.177396] Modules linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul [ 43.177426] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect [ 43.177466] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel [ 43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1 [ 43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [ 43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev] [ 43.177482] RSP: 0000:ffffa5c5c231b420 EFLAGS: 00010202 [ 43.177484] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000000 [ 43.177485] RDX: ffffffffc0c44cc0 RSI: ffffffffffffffff RDI: ffffffffc0c44cc0 [ 43.177486] RBP: ffffa5c5c231b478 R08: ffffffffc0c96900 R09: ffff8eda1a51f018 [ 43.177487] R10: 0000000000000600 R11: 00000000000003b6 R12: 0000000000000000 [ 43.177488] R13: 0000000000000005 R14: ffffffffc0c96900 R15: ffff8eda1d6d91c0 [ 43.177489] FS: 00007fd2d8ef2480(0000) GS:ffff8eda33480000(0000) knlGS:0000000000000000 [ 43.177490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.177491] CR2: 00007ffe0a6ad01c CR3: 0000000456ae2004 CR4: 00000000003606e0 [ 43.177492] Call Trace: [ 43.177498] ? devres_add+0x5f/0x70 [ 43.177502] rmi_f54_probe+0x437/0x470 [rmi_core] [ 43.177505] rmi_function_probe+0x25/0x30 [rmi_core] [ 43.177507] driver_probe_device+0x310/0x480 [ 43.177509] __device_attach_driver+0x86/0x100 [ 43.177511] ? __driver_attach+0xf0/0xf0 [ 43.177512] bus_for_each_drv+0x6b/0xb0 [ 43.177514] __device_attach+0xdd/0x160 [ 43.177516] device_initial_probe+0x13/0x20 [ 43.177518] bus_probe_device+0x95/0xa0 [ 43.177519] device_add+0x44b/0x680 [ 43.177522] rmi_register_function+0x62/0xd0 [rmi_core] [ 43.177525] rmi_create_function+0x112/0x1a0 [rmi_core] [ 43.177527] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] [ 43.177530] rmi_scan_pdt+0xca/0x1a0 [rmi_core] [ 43.177535] rmi_init_functions+0x5b/0x120 [rmi_core] [ 43.177537] rmi_driver_probe+0x152/0x3c0 [rmi_core] [ 43.177547] ? sysfs_create_link+0x25/0x40 [ 43.177549] driver_probe_device+0x310/0x480 [ 43.177551] __device_attach_driver+0x86/0x100 [ 43.177553] ? __driver_attach+0xf0/0xf0 [ 43.177554] bus_for_each_drv+0x6b/0xb0 [ 43.177556] __device_attach+0xdd/0x160 [ 43.177558] device_initial_probe+0x13/0x20 [ 43.177560] bus_probe_device+0x95/0xa0 [ 43.177561] device_add+0x44b/0x680 [ 43.177564] rmi_register_transport_device+0x84/0x100 [rmi_core] [ 43.177568] rmi_input_configured+0xbf/0x1a0 [hid_rmi] [ 43.177571] ? input_allocate_device+0xdf/0xf0 [ 43.177574] hidinput_connect+0x4a9/0x37a0 [hid] [ 43.177578] hid_connect+0x326/0x3d0 [hid] [ 43.177581] hid_hw_start+0x42/0x70 [hid] [ 43.177583] rmi_probe+0x115/0x510 [hid_rmi] [ 43.177586] hid_device_probe+0xd3/0x150 [hid] [ 43.177588] ? sysfs_create_link+0x25/0x40 [ 43.177590] driver_probe_device+0x310/0x480 [ 43.177592] __driver_attach+0xbf/0xf0 [ 43.177593] ? driver_probe_device+0x480/0x480 [ 43.177595] bus_for_each_dev+0x74/0xb0 [ 43.177597] ? kmem_cache_alloc_trace+0x1a6/0x1c0 [ 43.177599] driver_attach+0x1e/0x20 [ 43.177600] bus_add_driver+0x167/0x260 [ 43.177602] ? 0xffffffffc0cbc000 [ 43.177604] driver_register+0x60/0xe0 [ 43.177605] ? 0xffffffffc0cbc000 [ 43.177607] __hid_register_driver+0x63/0x70 [hid] [ 43.177610] rmi_driver_init+0x23/0x1000 [hid_rmi] [ 43.177612] do_one_initcall+0x52/0x191 [ 43.177615] ? _cond_resched+0x19/0x40 [ 43.177617] ? kmem_cache_alloc_trace+0xa2/0x1c0 [ 43.177619] ? do_init_module+0x27/0x209 [ 43.177621] do_init_module+0x5f/0x209 [ 43.177623] load_module+0x1987/0x1f10 [ 43.177626] ? ima_post_read_file+0x96/0xa0 [ 43.177629] SYSC_finit_module+0xfc/0x120 [ 43.177630] ? SYSC_finit_module+0xfc/0x120 [ 43.177632] SyS_finit_module+0xe/0x10 [ 43.177634] do_syscall_64+0x73/0x130 [ 43.177637] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 43.177638] RIP: 0033:0x7fd2d880b839 [ 43.177639] RSP: 002b:00007ffe0a6b2368 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 43.177641] RAX: ffffffffffffffda RBX: 000055cdd86542e0 RCX: 00007fd2d880b839 [ 43.177641] RDX: 0000000000000000 RSI: 00007fd2d84ea0e5 RDI: 0000000000000016 [ 43.177642] RBP: 00007fd2d84ea0e5 R08: 0000000000000000 R09: 00007ffe0a6b2480 [ 43.177643] R10: 0000000000000016 R11: 0000000000000246 R12: 0000000000000000 [ 43.177644] R13: 000055cdd8688930 R14: 0000000000020000 R15: 000055cdd86542e0 [ 43.177645] Code: 48 c7 c7 54 b4 c3 c0 e8 96 9d ec dd e9 d4 fb ff ff 0f 0b 41 be ea ff ff ff e9 c7 fb ff ff 0f 0b 41 be ea ff ff ff e9 ba fb ff ff <0f> 0b e9 d8 f4 ff ff 83 fa 01 0f 84 c4 02 00 00 48 83 78 68 00 [ 43.177675] ---[ end trace d44d9bc41477c2dd ]--- [ 43.177679] BUG: unable to handle kernel NULL pointer dereference at 0000000000000499 [ 43.177723] IP: __video_register_device+0x1cc/0x1090 [videodev] [ 43.177749] PGD 0 P4D 0 [ 43.177764] Oops: 0000 [#1] SMP PTI [ 43.177780] Modules linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul [ 43.178055] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect [ 43.178337] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel [ 43.178380] CPU: 1 PID: 711 Comm: systemd-udevd Tainted: G W 4.16.0 #1 [ 43.178411] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [ 43.178441] RIP: 0010:__video_register_device+0x1cc/0x1090 [videodev] [ 43.178467] RSP: 0000:ffffa5c5c231b420 EFLAGS: 00010202 [ 43.178490] RAX: ffffffffc0c44cc0 RBX: 0000000000000005 RCX: ffffffffc0c454c0 [ 43.178519] RDX: 0000000000000001 RSI: ffff8eda1d6d9118 RDI: ffffffffc0c44cc0 [ 43.178549] RBP: ffffa5c5c231b478 R08: ffffffffc0c96900 R09: ffff8eda1a51f018 [ 43.178579] R10: 0000000000000600 R11: 00000000000003b6 R12: 0000000000000000 [ 43.178608] R13: 0000000000000005 R14: ffffffffc0c96900 R15: ffff8eda1d6d91c0 [ 43.178636] FS: 00007fd2d8ef2480(0000) GS:ffff8eda33480000(0000) knlGS:0000000000000000 [ 43.178669] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.178693] CR2: 0000000000000499 CR3: 0000000456ae2004 CR4: 00000000003606e0 [ 43.178721] Call Trace: [ 43.178736] ? devres_add+0x5f/0x70 [ 43.178755] rmi_f54_probe+0x437/0x470 [rmi_core] [ 43.178779] rmi_function_probe+0x25/0x30 [rmi_core] [ 43.178805] driver_probe_device+0x310/0x480 [ 43.178828] __device_attach_driver+0x86/0x100 [ 43.178851] ? __driver_attach+0xf0/0xf0 [ 43.178884] bus_for_each_drv+0x6b/0xb0 [ 43.178904] __device_attach+0xdd/0x160 [ 43.178925] device_initial_probe+0x13/0x20 [ 43.178948] bus_probe_device+0x95/0xa0 [ 43.178968] device_add+0x44b/0x680 [ 43.178987] rmi_register_function+0x62/0xd0 [rmi_core] [ 43.181747] rmi_create_function+0x112/0x1a0 [rmi_core] [ 43.184677] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] [ 43.187505] rmi_scan_pdt+0xca/0x1a0 [rmi_core] [ 43.190171] rmi_init_functions+0x5b/0x120 [rmi_core] [ 43.192809] rmi_driver_probe+0x152/0x3c0 [rmi_core] [ 43.195403] ? sysfs_create_link+0x25/0x40 [ 43.198253] driver_probe_device+0x310/0x480 [ 43.201083] __device_attach_driver+0x86/0x100 [ 43.203800] ? __driver_attach+0xf0/0xf0 [ 43.206503] bus_for_each_drv+0x6b/0xb0 [ 43.209291] __device_attach+0xdd/0x160 [ 43.212207] device_initial_probe+0x13/0x20 [ 43.215146] bus_probe_device+0x95/0xa0 [ 43.217885] device_add+0x44b/0x680 [ 43.220597] rmi_register_transport_device+0x84/0x100 [rmi_core] [ 43.223321] rmi_input_configured+0xbf/0x1a0 [hid_rmi] [ 43.226051] ? input_allocate_device+0xdf/0xf0 [ 43.228814] hidinput_connect+0x4a9/0x37a0 [hid] [ 43.231701] hid_connect+0x326/0x3d0 [hid] [ 43.234548] hid_hw_start+0x42/0x70 [hid] [ 43.237302] rmi_probe+0x115/0x510 [hid_rmi] [ 43.239862] hid_device_probe+0xd3/0x150 [hid] [ 43.242558] ? sysfs_create_link+0x25/0x40 [ 43.242828] audit: type=1400 audit(1522795151.600:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine" pid=1151 comm="apparmor_parser" [ 43.244859] driver_probe_device+0x310/0x480 [ 43.244862] __driver_attach+0xbf/0xf0 [ 43.246982] audit: type=1400 audit(1522795151.600:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=1151 comm="apparmor_parser" [ 43.249403] ? driver_probe_device+0x480/0x480 [ 43.249405] bus_for_each_dev+0x74/0xb0 [ 43.253200] audit: type=1400 audit(1522795151.600:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine//snap_update_ns" pid=1151 comm="apparmor_parser" [ 43.254055] ? kmem_cache_alloc_trace+0x1a6/0x1c0 [ 43.256282] audit: type=1400 audit(1522795151.604:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/sbin/dhclient" pid=1152 comm="apparmor_parser" [ 43.258436] driver_attach+0x1e/0x20 [ 43.260875] audit: type=1400 audit(1522795151.604:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1152 comm="apparmor_parser" [ 43.263118] bus_add_driver+0x167/0x260 [ 43.267676] audit: type=1400 audit(1522795151.604:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1152 comm="apparmor_parser" [ 43.268807] ? 0xffffffffc0cbc000 [ 43.268812] driver_register+0x60/0xe0 [ 43.271184] audit: type=1400 audit(1522795151.604:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=1152 comm="apparmor_parser" [ 43.274081] ? 0xffffffffc0cbc000 [ 43.274086] __hid_register_driver+0x63/0x70 [hid] [ 43.288367] rmi_driver_init+0x23/0x1000 [hid_rmi] [ 43.291501] do_one_initcall+0x52/0x191 [ 43.292348] audit: type=1400 audit(1522795151.652:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1242 comm="apparmor_parser" [ 43.294212] ? _cond_resched+0x19/0x40 [ 43.300028] ? kmem_cache_alloc_trace+0xa2/0x1c0 [ 43.303475] ? do_init_module+0x27/0x209 [ 43.306842] do_init_module+0x5f/0x209 [ 43.310269] load_module+0x1987/0x1f10 [ 43.313704] ? ima_post_read_file+0x96/0xa0 [ 43.317174] SYSC_finit_module+0xfc/0x120 [ 43.320754] ? SYSC_finit_module+0xfc/0x120 [ 43.324065] SyS_finit_module+0xe/0x10 [ 43.327387] do_syscall_64+0x73/0x130 [ 43.330909] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 43.334305] RIP: 0033:0x7fd2d880b839 [ 43.337810] RSP: 002b:00007ffe0a6b2368 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 43.341259] RAX: ffffffffffffffda RBX: 000055cdd86542e0 RCX: 00007fd2d880b839 [ 43.344613] RDX: 0000000000000000 RSI: 00007fd2d84ea0e5 RDI: 0000000000000016 [ 43.347962] RBP: 00007fd2d84ea0e5 R08: 0000000000000000 R09: 00007ffe0a6b2480 [ 43.351456] R10: 0000000000000016 R11: 0000000000000246 R12: 0000000000000000 [ 43.354845] R13: 000055cdd8688930 R14: 0000000000020000 R15: 000055cdd86542e0 [ 43.358224] Code: c7 05 ad 12 02 00 00 00 00 00 48 8d 88 00 08 00 00 eb 09 48 83 c0 08 48 39 c1 74 31 48 8b 10 48 85 d2 74 ef 49 8b b7 98 04 00 00 <48> 39 b2 98 04 00 00 75 df 48 63 92 f8 04 00 00 f0 48 0f ab 15 [ 43.361764] RIP: __video_register_device+0x1cc/0x1090 [videodev] RSP: ffffa5c5c231b420 [ 43.365281] CR2: 0000000000000499 This patch fixes the array size and changes the WARN_ON() to return an error, instead of letting the Kernel to proceed with registering. Cc: stable(a)vger.kernel.org Reported-by: Peter Geis <pgwipeout(a)gmail.com> Reported-by: Jaak Ristioja <jaak(a)ristioja.ee> Reported-by: Michał Siemek <mihau69(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> --- drivers/media/v4l2-core/v4l2-dev.c | 8 ++++++-- include/media/v4l2-dev.h | 12 ++++++------ 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index 0301fe426a43..1d0b2208e8fb 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -939,10 +939,14 @@ int __video_register_device(struct video_device *vdev, #endif vdev->minor = i + minor_offset; vdev->num = nr; - devnode_set(vdev); /* Should not happen since we thought this minor was free */ - WARN_ON(video_device[vdev->minor] != NULL); + if (WARN_ON(video_device[vdev->minor])) { + mutex_unlock(&videodev_lock); + printk(KERN_ERR "video_device not empty!\n"); + return -ENFILE; + } + devnode_set(vdev); vdev->index = get_index(vdev); video_device[vdev->minor] = vdev; mutex_unlock(&videodev_lock); diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h index 27634e8d2585..e59742e47501 100644 --- a/include/media/v4l2-dev.h +++ b/include/media/v4l2-dev.h @@ -33,13 +33,13 @@ */ enum vfl_devnode_type { VFL_TYPE_GRABBER = 0, - VFL_TYPE_VBI = 1, - VFL_TYPE_RADIO = 2, - VFL_TYPE_SUBDEV = 3, - VFL_TYPE_SDR = 4, - VFL_TYPE_TOUCH = 5, + VFL_TYPE_VBI, + VFL_TYPE_RADIO, + VFL_TYPE_SUBDEV, + VFL_TYPE_SDR, + VFL_TYPE_TOUCH, + VFL_TYPE_MAX /* Should be the last one */ }; -#define VFL_TYPE_MAX VFL_TYPE_TOUCH /** * enum vfl_direction - Identifies if a &struct video_device corresponds -- 2.14.3

7 years, 5 months

3
3
0 0

[PATCH] media: v4l2-core: fix size of devnode_nums[] bitarray

by Mauro Carvalho Chehab

The size of devnode_nums[] bit array is too short to store information for VFL_TYPE_TOUCH. That causes it to override other memory regions. Thankfully, on recent reports, it is overriding video_device[] array, trigging a WARN_ON(). Yet, it just warns about the problem, but let the code excecuting, with generates an OOPS: [ 43.177394] WARNING: CPU: 1 PID: 711 at drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 [videodev] [ 43.177396] Modules linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul [ 43.177426] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect [ 43.177466] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel [ 43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1 [ 43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [ 43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev] [ 43.177482] RSP: 0000:ffffa5c5c231b420 EFLAGS: 00010202 [ 43.177484] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000000 [ 43.177485] RDX: ffffffffc0c44cc0 RSI: ffffffffffffffff RDI: ffffffffc0c44cc0 [ 43.177486] RBP: ffffa5c5c231b478 R08: ffffffffc0c96900 R09: ffff8eda1a51f018 [ 43.177487] R10: 0000000000000600 R11: 00000000000003b6 R12: 0000000000000000 [ 43.177488] R13: 0000000000000005 R14: ffffffffc0c96900 R15: ffff8eda1d6d91c0 [ 43.177489] FS: 00007fd2d8ef2480(0000) GS:ffff8eda33480000(0000) knlGS:0000000000000000 [ 43.177490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.177491] CR2: 00007ffe0a6ad01c CR3: 0000000456ae2004 CR4: 00000000003606e0 [ 43.177492] Call Trace: [ 43.177498] ? devres_add+0x5f/0x70 [ 43.177502] rmi_f54_probe+0x437/0x470 [rmi_core] [ 43.177505] rmi_function_probe+0x25/0x30 [rmi_core] [ 43.177507] driver_probe_device+0x310/0x480 [ 43.177509] __device_attach_driver+0x86/0x100 [ 43.177511] ? __driver_attach+0xf0/0xf0 [ 43.177512] bus_for_each_drv+0x6b/0xb0 [ 43.177514] __device_attach+0xdd/0x160 [ 43.177516] device_initial_probe+0x13/0x20 [ 43.177518] bus_probe_device+0x95/0xa0 [ 43.177519] device_add+0x44b/0x680 [ 43.177522] rmi_register_function+0x62/0xd0 [rmi_core] [ 43.177525] rmi_create_function+0x112/0x1a0 [rmi_core] [ 43.177527] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] [ 43.177530] rmi_scan_pdt+0xca/0x1a0 [rmi_core] [ 43.177535] rmi_init_functions+0x5b/0x120 [rmi_core] [ 43.177537] rmi_driver_probe+0x152/0x3c0 [rmi_core] [ 43.177547] ? sysfs_create_link+0x25/0x40 [ 43.177549] driver_probe_device+0x310/0x480 [ 43.177551] __device_attach_driver+0x86/0x100 [ 43.177553] ? __driver_attach+0xf0/0xf0 [ 43.177554] bus_for_each_drv+0x6b/0xb0 [ 43.177556] __device_attach+0xdd/0x160 [ 43.177558] device_initial_probe+0x13/0x20 [ 43.177560] bus_probe_device+0x95/0xa0 [ 43.177561] device_add+0x44b/0x680 [ 43.177564] rmi_register_transport_device+0x84/0x100 [rmi_core] [ 43.177568] rmi_input_configured+0xbf/0x1a0 [hid_rmi] [ 43.177571] ? input_allocate_device+0xdf/0xf0 [ 43.177574] hidinput_connect+0x4a9/0x37a0 [hid] [ 43.177578] hid_connect+0x326/0x3d0 [hid] [ 43.177581] hid_hw_start+0x42/0x70 [hid] [ 43.177583] rmi_probe+0x115/0x510 [hid_rmi] [ 43.177586] hid_device_probe+0xd3/0x150 [hid] [ 43.177588] ? sysfs_create_link+0x25/0x40 [ 43.177590] driver_probe_device+0x310/0x480 [ 43.177592] __driver_attach+0xbf/0xf0 [ 43.177593] ? driver_probe_device+0x480/0x480 [ 43.177595] bus_for_each_dev+0x74/0xb0 [ 43.177597] ? kmem_cache_alloc_trace+0x1a6/0x1c0 [ 43.177599] driver_attach+0x1e/0x20 [ 43.177600] bus_add_driver+0x167/0x260 [ 43.177602] ? 0xffffffffc0cbc000 [ 43.177604] driver_register+0x60/0xe0 [ 43.177605] ? 0xffffffffc0cbc000 [ 43.177607] __hid_register_driver+0x63/0x70 [hid] [ 43.177610] rmi_driver_init+0x23/0x1000 [hid_rmi] [ 43.177612] do_one_initcall+0x52/0x191 [ 43.177615] ? _cond_resched+0x19/0x40 [ 43.177617] ? kmem_cache_alloc_trace+0xa2/0x1c0 [ 43.177619] ? do_init_module+0x27/0x209 [ 43.177621] do_init_module+0x5f/0x209 [ 43.177623] load_module+0x1987/0x1f10 [ 43.177626] ? ima_post_read_file+0x96/0xa0 [ 43.177629] SYSC_finit_module+0xfc/0x120 [ 43.177630] ? SYSC_finit_module+0xfc/0x120 [ 43.177632] SyS_finit_module+0xe/0x10 [ 43.177634] do_syscall_64+0x73/0x130 [ 43.177637] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 43.177638] RIP: 0033:0x7fd2d880b839 [ 43.177639] RSP: 002b:00007ffe0a6b2368 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 43.177641] RAX: ffffffffffffffda RBX: 000055cdd86542e0 RCX: 00007fd2d880b839 [ 43.177641] RDX: 0000000000000000 RSI: 00007fd2d84ea0e5 RDI: 0000000000000016 [ 43.177642] RBP: 00007fd2d84ea0e5 R08: 0000000000000000 R09: 00007ffe0a6b2480 [ 43.177643] R10: 0000000000000016 R11: 0000000000000246 R12: 0000000000000000 [ 43.177644] R13: 000055cdd8688930 R14: 0000000000020000 R15: 000055cdd86542e0 [ 43.177645] Code: 48 c7 c7 54 b4 c3 c0 e8 96 9d ec dd e9 d4 fb ff ff 0f 0b 41 be ea ff ff ff e9 c7 fb ff ff 0f 0b 41 be ea ff ff ff e9 ba fb ff ff <0f> 0b e9 d8 f4 ff ff 83 fa 01 0f 84 c4 02 00 00 48 83 78 68 00 [ 43.177675] ---[ end trace d44d9bc41477c2dd ]--- [ 43.177679] BUG: unable to handle kernel NULL pointer dereference at 0000000000000499 [ 43.177723] IP: __video_register_device+0x1cc/0x1090 [videodev] [ 43.177749] PGD 0 P4D 0 [ 43.177764] Oops: 0000 [#1] SMP PTI [ 43.177780] Modules linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul [ 43.178055] crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect [ 43.178337] sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video pinctrl_sunrisepoint pinctrl_intel [ 43.178380] CPU: 1 PID: 711 Comm: systemd-udevd Tainted: G W 4.16.0 #1 [ 43.178411] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [ 43.178441] RIP: 0010:__video_register_device+0x1cc/0x1090 [videodev] [ 43.178467] RSP: 0000:ffffa5c5c231b420 EFLAGS: 00010202 [ 43.178490] RAX: ffffffffc0c44cc0 RBX: 0000000000000005 RCX: ffffffffc0c454c0 [ 43.178519] RDX: 0000000000000001 RSI: ffff8eda1d6d9118 RDI: ffffffffc0c44cc0 [ 43.178549] RBP: ffffa5c5c231b478 R08: ffffffffc0c96900 R09: ffff8eda1a51f018 [ 43.178579] R10: 0000000000000600 R11: 00000000000003b6 R12: 0000000000000000 [ 43.178608] R13: 0000000000000005 R14: ffffffffc0c96900 R15: ffff8eda1d6d91c0 [ 43.178636] FS: 00007fd2d8ef2480(0000) GS:ffff8eda33480000(0000) knlGS:0000000000000000 [ 43.178669] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.178693] CR2: 0000000000000499 CR3: 0000000456ae2004 CR4: 00000000003606e0 [ 43.178721] Call Trace: [ 43.178736] ? devres_add+0x5f/0x70 [ 43.178755] rmi_f54_probe+0x437/0x470 [rmi_core] [ 43.178779] rmi_function_probe+0x25/0x30 [rmi_core] [ 43.178805] driver_probe_device+0x310/0x480 [ 43.178828] __device_attach_driver+0x86/0x100 [ 43.178851] ? __driver_attach+0xf0/0xf0 [ 43.178884] bus_for_each_drv+0x6b/0xb0 [ 43.178904] __device_attach+0xdd/0x160 [ 43.178925] device_initial_probe+0x13/0x20 [ 43.178948] bus_probe_device+0x95/0xa0 [ 43.178968] device_add+0x44b/0x680 [ 43.178987] rmi_register_function+0x62/0xd0 [rmi_core] [ 43.181747] rmi_create_function+0x112/0x1a0 [rmi_core] [ 43.184677] ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core] [ 43.187505] rmi_scan_pdt+0xca/0x1a0 [rmi_core] [ 43.190171] rmi_init_functions+0x5b/0x120 [rmi_core] [ 43.192809] rmi_driver_probe+0x152/0x3c0 [rmi_core] [ 43.195403] ? sysfs_create_link+0x25/0x40 [ 43.198253] driver_probe_device+0x310/0x480 [ 43.201083] __device_attach_driver+0x86/0x100 [ 43.203800] ? __driver_attach+0xf0/0xf0 [ 43.206503] bus_for_each_drv+0x6b/0xb0 [ 43.209291] __device_attach+0xdd/0x160 [ 43.212207] device_initial_probe+0x13/0x20 [ 43.215146] bus_probe_device+0x95/0xa0 [ 43.217885] device_add+0x44b/0x680 [ 43.220597] rmi_register_transport_device+0x84/0x100 [rmi_core] [ 43.223321] rmi_input_configured+0xbf/0x1a0 [hid_rmi] [ 43.226051] ? input_allocate_device+0xdf/0xf0 [ 43.228814] hidinput_connect+0x4a9/0x37a0 [hid] [ 43.231701] hid_connect+0x326/0x3d0 [hid] [ 43.234548] hid_hw_start+0x42/0x70 [hid] [ 43.237302] rmi_probe+0x115/0x510 [hid_rmi] [ 43.239862] hid_device_probe+0xd3/0x150 [hid] [ 43.242558] ? sysfs_create_link+0x25/0x40 [ 43.242828] audit: type=1400 audit(1522795151.600:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine" pid=1151 comm="apparmor_parser" [ 43.244859] driver_probe_device+0x310/0x480 [ 43.244862] __driver_attach+0xbf/0xf0 [ 43.246982] audit: type=1400 audit(1522795151.600:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=1151 comm="apparmor_parser" [ 43.249403] ? driver_probe_device+0x480/0x480 [ 43.249405] bus_for_each_dev+0x74/0xb0 [ 43.253200] audit: type=1400 audit(1522795151.600:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/snap/core/4206/usr/lib/snapd/snap-confine//snap_update_ns" pid=1151 comm="apparmor_parser" [ 43.254055] ? kmem_cache_alloc_trace+0x1a6/0x1c0 [ 43.256282] audit: type=1400 audit(1522795151.604:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/sbin/dhclient" pid=1152 comm="apparmor_parser" [ 43.258436] driver_attach+0x1e/0x20 [ 43.260875] audit: type=1400 audit(1522795151.604:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1152 comm="apparmor_parser" [ 43.263118] bus_add_driver+0x167/0x260 [ 43.267676] audit: type=1400 audit(1522795151.604:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1152 comm="apparmor_parser" [ 43.268807] ? 0xffffffffc0cbc000 [ 43.268812] driver_register+0x60/0xe0 [ 43.271184] audit: type=1400 audit(1522795151.604:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=1152 comm="apparmor_parser" [ 43.274081] ? 0xffffffffc0cbc000 [ 43.274086] __hid_register_driver+0x63/0x70 [hid] [ 43.288367] rmi_driver_init+0x23/0x1000 [hid_rmi] [ 43.291501] do_one_initcall+0x52/0x191 [ 43.292348] audit: type=1400 audit(1522795151.652:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1242 comm="apparmor_parser" [ 43.294212] ? _cond_resched+0x19/0x40 [ 43.300028] ? kmem_cache_alloc_trace+0xa2/0x1c0 [ 43.303475] ? do_init_module+0x27/0x209 [ 43.306842] do_init_module+0x5f/0x209 [ 43.310269] load_module+0x1987/0x1f10 [ 43.313704] ? ima_post_read_file+0x96/0xa0 [ 43.317174] SYSC_finit_module+0xfc/0x120 [ 43.320754] ? SYSC_finit_module+0xfc/0x120 [ 43.324065] SyS_finit_module+0xe/0x10 [ 43.327387] do_syscall_64+0x73/0x130 [ 43.330909] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 43.334305] RIP: 0033:0x7fd2d880b839 [ 43.337810] RSP: 002b:00007ffe0a6b2368 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 43.341259] RAX: ffffffffffffffda RBX: 000055cdd86542e0 RCX: 00007fd2d880b839 [ 43.344613] RDX: 0000000000000000 RSI: 00007fd2d84ea0e5 RDI: 0000000000000016 [ 43.347962] RBP: 00007fd2d84ea0e5 R08: 0000000000000000 R09: 00007ffe0a6b2480 [ 43.351456] R10: 0000000000000016 R11: 0000000000000246 R12: 0000000000000000 [ 43.354845] R13: 000055cdd8688930 R14: 0000000000020000 R15: 000055cdd86542e0 [ 43.358224] Code: c7 05 ad 12 02 00 00 00 00 00 48 8d 88 00 08 00 00 eb 09 48 83 c0 08 48 39 c1 74 31 48 8b 10 48 85 d2 74 ef 49 8b b7 98 04 00 00 <48> 39 b2 98 04 00 00 75 df 48 63 92 f8 04 00 00 f0 48 0f ab 15 [ 43.361764] RIP: __video_register_device+0x1cc/0x1090 [videodev] RSP: ffffa5c5c231b420 [ 43.365281] CR2: 0000000000000499 This patch fixes the array size and changes the WARN_ON() to return an error, instead of letting the Kernel to proceed with registering. Cc: stable(a)vger.kernel.org Reported-by: Peter Geis <pgwipeout(a)gmail.com> Reported-by: Jaak Ristioja <jaak(a)ristioja.ee> Reported-by: Michał Siemek <mihau69(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> --- drivers/media/v4l2-core/v4l2-dev.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index 0301fe426a43..cc95d6023d57 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -93,7 +93,7 @@ ATTRIBUTE_GROUPS(video_device); */ static struct video_device *video_device[VIDEO_NUM_DEVICES]; static DEFINE_MUTEX(videodev_lock); -static DECLARE_BITMAP(devnode_nums[VFL_TYPE_MAX], VIDEO_NUM_DEVICES); +static DECLARE_BITMAP(devnode_nums[VFL_TYPE_MAX + 1], VIDEO_NUM_DEVICES); /* Device node utility functions */ @@ -942,7 +942,11 @@ int __video_register_device(struct video_device *vdev, devnode_set(vdev); /* Should not happen since we thought this minor was free */ - WARN_ON(video_device[vdev->minor] != NULL); + if (WARN_ON(video_device[vdev->minor])) { + mutex_unlock(&videodev_lock); + printk(KERN_ERR "video_device not empty!\n"); + return -ENFILE; + } vdev->index = get_index(vdev); video_device[vdev->minor] = vdev; mutex_unlock(&videodev_lock); -- 2.14.3

7 years, 5 months

1
0
0 0

[PATCH] locking/qrwlock: Give priority to readers with irqs disabled to prevent deadlock

by Kirill Tkhai

The following situation leads to deadlock: [task 1] [task 2] [task 3] kill_fasync() mm_update_next_owner() copy_process() spin_lock_irqsave(&fa->fa_lock) read_lock(&tasklist_lock) write_lock_irq(&tasklist_lock) send_sigio() <IRQ> ... read_lock(&fown->lock) kill_fasync() ... read_lock(&tasklist_lock) spin_lock_irqsave(&fa->fa_lock) ... Task 1 can't acquire read locked tasklist_lock, since there is already task 3 expressed its wish to take the lock exclusive. Task 2 holds the read locked lock, but it can't take the spin lock. The patch makes queued_read_lock_slowpath() to give task 1 the same priority as it was an interrupt handler, and to take the lock dispite of task 3 is waiting it, and this prevents the deadlock. It seems there is no better way to detect such the situations, also in general it's not good to wait so long for readers with interrupts disabled, since read_lock may nest with another locks and delay the system. Signed-off-by: Kirill Tkhai <ktkhai(a)virtuozzo.com> --- kernel/locking/qrwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c index c7471c3fb798..d15df85de8f5 100644 --- a/kernel/locking/qrwlock.c +++ b/kernel/locking/qrwlock.c @@ -32,7 +32,7 @@ void queued_read_lock_slowpath(struct qrwlock *lock) /* * Readers come here when they cannot get the lock without waiting */ - if (unlikely(in_interrupt())) { + if (unlikely(irqs_disabled())) { /* * Readers in interrupt context will get the lock immediately * if the writer is just waiting (not holding the lock yet),

7 years, 5 months

4
8
0 0

[PATCH] dvb_frontend: fix locking issues at dvb_frontend_get_event()

by Mauro Carvalho Chehab

As warned by smatch: drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'. Locked on: line 288 line 295 line 306 line 314 Unlocked on: line 303 The lock implementation for get event is wrong, as, if an interrupt occurs, down_interruptible() will fail, and the routine will call up() twice when userspace calls the ioctl again. The bad code is there since when Linux migrated to git, in 2005. Cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> --- drivers/media/dvb-core/dvb_frontend.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c index e33414975065..a4ada1ccf0df 100644 --- a/drivers/media/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb-core/dvb_frontend.c @@ -275,8 +275,20 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe, wake_up_interruptible (&events->wait_queue); } +static int dvb_frontend_test_event(struct dvb_frontend_private *fepriv, + struct dvb_fe_events *events) +{ + int ret; + + up(&fepriv->sem); + ret = events->eventw != events->eventr; + down(&fepriv->sem); + + return ret; +} + static int dvb_frontend_get_event(struct dvb_frontend *fe, - struct dvb_frontend_event *event, int flags) + struct dvb_frontend_event *event, int flags) { struct dvb_frontend_private *fepriv = fe->frontend_priv; struct dvb_fe_events *events = &fepriv->events; @@ -294,13 +306,8 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe, if (flags & O_NONBLOCK) return -EWOULDBLOCK; - up(&fepriv->sem); - - ret = wait_event_interruptible (events->wait_queue, - events->eventw != events->eventr); - - if (down_interruptible (&fepriv->sem)) - return -ERESTARTSYS; + ret = wait_event_interruptible(events->wait_queue, + dvb_frontend_test_event(fepriv, events)); if (ret < 0) return ret; -- 2.14.3

7 years, 5 months

1
0
0 0

[git:media_tree/fixes] media: v4l2-compat-ioctl32: don't oops on overlay

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: v4l2-compat-ioctl32: don't oops on overlay Author: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Wed Mar 28 13:59:22 2018 -0400 At put_v4l2_window32(), it tries to access kp->clips. However, kp points to an userspace pointer. So, it should be obtained via get_user(), otherwise it can OOPS: vivid-000: ================== END STATUS ================== BUG: unable to handle kernel paging request at 00000000fffb18e0 IP: [<ffffffffc05468d9>] __put_v4l2_format32+0x169/0x220 [videodev] PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 800000042548f067 Oops: 0001 [#1] SMP Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich video crc32c_intel [last unloaded: media] CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 task: ffff8804293f8000 ti: ffff8803f5640000 task.ti: ffff8803f5640000 RIP: 0010:[<ffffffffc05468d9>] [<ffffffffc05468d9>] __put_v4l2_format32+0x169/0x220 [videodev] RSP: 0018:ffff8803f5643e28 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffb1ab4 RDX: 00000000fffb1a68 RSI: 00000000fffb18d8 RDI: 00000000fffb1aa8 RBP: ffff8803f5643e48 R08: 0000000000000001 R09: ffff8803f54b0378 R10: 0000000000000000 R11: 0000000000000168 R12: 00000000fffb18c0 R13: 00000000fffb1a94 R14: 00000000fffb18c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880456d00000(0063) knlGS:00000000f7100980 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 00000000fffb18e0 CR3: 00000003f552b000 CR4: 00000000003407e0 Stack: 00000000fffb1a94 00000000c0cc5640 0000000000000056 ffff8804274f3600 ffff8803f5643ed0 ffffffffc0547e16 0000000000000003 ffff8803f5643eb0 ffffffff81301460 ffff88009db44b01 ffff880441942520 ffff8800c0d05640 Call Trace: [<ffffffffc0547e16>] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev] [<ffffffff81301460>] ? file_has_perm+0x70/0xc0 [<ffffffff81252a2c>] compat_SyS_ioctl+0xec/0x1200 [<ffffffff8173241a>] sysenter_dispatch+0x7/0x21 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f RIP [<ffffffffc05468d9>] __put_v4l2_format32+0x169/0x220 [videodev] RSP <ffff8803f5643e28> CR2: 00000000fffb18e0 Tested with vivid driver on Kernel v3.18.102. Same bug happens upstream too: BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev] Read of size 8 at addr 00000000ffe48400 by task v4l2-compliance/8713 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 Call Trace: dump_stack+0x5c/0x7c kasan_report+0x164/0x380 ? __put_v4l2_format32+0x98/0x4d0 [videodev] __put_v4l2_format32+0x98/0x4d0 [videodev] v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev] ? __fsnotify_inode_delete+0x20/0x20 ? __put_v4l2_format32+0x4d0/0x4d0 [videodev] compat_SyS_ioctl+0x646/0x14d0 ? do_ioctl+0x30/0x30 do_fast_syscall_32+0x191/0x3f4 entry_SYSENTER_compat+0x6b/0x7a ================================================================== Disabling lock debugging due to kernel taint BUG: unable to handle kernel paging request at 00000000ffe48400 IP: __put_v4l2_format32+0x98/0x4d0 [videodev] PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 80000003256af067 Oops: 0001 [#1] SMP KASAN Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer intel_rapl_perf drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel CPU: 0 PID: 8713 Comm: v4l2-compliance Tainted: G B 4.16.0-rc4+ #108 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 RIP: 0010:__put_v4l2_format32+0x98/0x4d0 [videodev] RSP: 0018:ffff8803b9be7d30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8803ac983e80 RCX: ffffffff8cd929f2 RDX: 1ffffffff1d0a149 RSI: 0000000000000297 RDI: 0000000000000297 RBP: 00000000ffe485c0 R08: fffffbfff1cf5123 R09: ffffffff8e7a8948 R10: 0000000000000001 R11: fffffbfff1cf5122 R12: 00000000ffe483e0 R13: 00000000ffe485c4 R14: ffff8803ac985918 R15: 00000000ffe483e8 FS: 0000000000000000(0000) GS:ffff880407400000(0063) knlGS:00000000f7a46980 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 00000000ffe48400 CR3: 00000003a83f2003 CR4: 00000000003606f0 Call Trace: v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev] ? __fsnotify_inode_delete+0x20/0x20 ? __put_v4l2_format32+0x4d0/0x4d0 [videodev] compat_SyS_ioctl+0x646/0x14d0 ? do_ioctl+0x30/0x30 do_fast_syscall_32+0x191/0x3f4 entry_SYSENTER_compat+0x6b/0x7a Code: 4c 89 f7 4d 8d 7c 24 08 e8 e6 a4 69 cb 48 8b 83 98 1a 00 00 48 83 e8 10 49 39 c7 0f 87 9d 01 00 00 49 8d 7c 24 20 e8 c8 a4 69 cb <4d> 8b 74 24 20 4c 89 ef 4c 89 fe ba 10 00 00 00 e8 23 d9 08 cc RIP: __put_v4l2_format32+0x98/0x4d0 [videodev] RSP: ffff8803b9be7d30 CR2: 00000000ffe48400 cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Reviewed-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c index 5198c9eeb348..4312935f1dfc 100644 --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c @@ -101,7 +101,7 @@ static int get_v4l2_window32(struct v4l2_window __user *kp, static int put_v4l2_window32(struct v4l2_window __user *kp, struct v4l2_window32 __user *up) { - struct v4l2_clip __user *kclips = kp->clips; + struct v4l2_clip __user *kclips; struct v4l2_clip32 __user *uclips; compat_caddr_t p; u32 clipcount; @@ -116,6 +116,8 @@ static int put_v4l2_window32(struct v4l2_window __user *kp, if (!clipcount) return 0; + if (get_user(kclips, &kp->clips)) + return -EFAULT; if (get_user(p, &up->clips)) return -EFAULT; uclips = compat_ptr(p);

7 years, 5 months

1
0
0 0

[PATCH v2] Fix DID_OK handling in __scsi_error_from_host_byte()

by Bart Van Assche

Commit e39a97353e53 modified __scsi_error_from_host_byte() such that that function translates DID_OK into BLK_STS_OK. However, the description of that commit is wrong: it mentions that commit 2a842acab109 introduced a bug in __scsi_error_from_host_byte() although that commit did not change the behavior of that function. Additionally, commit e39a97353e53 introduced a severe bug: it causes commands that fail with hostbyte=DID_OK and driverbyte=DRIVER_SENSE to be completed with BLK_STS_OK. Fix __scsi_error_from_host_byte() by only translating good status values into BLK_STS_OK. Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Reported-by: Damien Le Moal <damien.lemoal(a)wdc.com> Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Cc: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: stable(a)vger.kernel.org --- Changes compared to v1: - Modified __scsi_error_from_host_byte() such that it again returns BLK_STS_OK for CONDITION MET and other result codes that represent success. drivers/scsi/scsi_lib.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 74a39db57d49..1496b34af409 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -736,7 +736,13 @@ static blk_status_t __scsi_error_from_host_byte(struct scsi_cmnd *cmd, { switch (host_byte(result)) { case DID_OK: - return BLK_STS_OK; + /* + * Also check the other bytes than the status byte in result + * to handle the case when a SCSI LLD sets result to + * DRIVER_SENSE << 24 without setting SAM_STAT_CHECK_CONDITION. + */ + return scsi_status_is_good(result) && (result & ~0xff) == 0 ? + BLK_STS_OK : BLK_STS_IOERR; case DID_TRANSPORT_FAILFAST: return BLK_STS_TRANSPORT; case DID_TARGET_FAILURE: -- 2.16.2

7 years, 5 months

6
6
0 0

[PATCH 1/2] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK

by Jan Glauber

Enabling virtual mapped kernel stacks breaks the thunderx_zip driver. On compression or decompression the executing CPU hangs in an endless loop. The reason for this is the usage of __pa by the driver which does no longer work for an address that is not part of the 1:1 mapping. The zip driver allocates a result struct on the stack and needs to tell the hardware the physical address within this struct that is used to signal the completion of the request. As the hardware gets the wrong address after the broken __pa conversion it writes to an arbitrary address. The zip driver then waits forever for the completion byte to contain a non-zero value. Allocating the result struct from 1:1 mapped memory resolves this bug. Signed-off-by: Jan Glauber <jglauber(a)cavium.com> Reviewed-by: Robert Richter <rrichter(a)cavium.com> Cc: stable <stable(a)vger.kernel.org> # 4.14 --- drivers/crypto/cavium/zip/zip_crypto.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/cavium/zip/zip_crypto.c b/drivers/crypto/cavium/zip/zip_crypto.c index 8df4d26..2fc9b03 100644 --- a/drivers/crypto/cavium/zip/zip_crypto.c +++ b/drivers/crypto/cavium/zip/zip_crypto.c @@ -124,7 +124,7 @@ int zip_compress(const u8 *src, unsigned int slen, struct zip_kernel_ctx *zip_ctx) { struct zip_operation *zip_ops = NULL; - struct zip_state zip_state; + struct zip_state *zip_state; struct zip_device *zip = NULL; int ret; @@ -135,20 +135,23 @@ int zip_compress(const u8 *src, unsigned int slen, if (!zip) return -ENODEV; - memset(&zip_state, 0, sizeof(struct zip_state)); + zip_state = kzalloc(sizeof(*zip_state), GFP_KERNEL); + if (!zip_state) + return -ENOMEM; + zip_ops = &zip_ctx->zip_comp; zip_ops->input_len = slen; zip_ops->output_len = *dlen; memcpy(zip_ops->input, src, slen); - ret = zip_deflate(zip_ops, &zip_state, zip); + ret = zip_deflate(zip_ops, zip_state, zip); if (!ret) { *dlen = zip_ops->output_len; memcpy(dst, zip_ops->output, *dlen); } - + kfree(zip_state); return ret; } @@ -157,7 +160,7 @@ int zip_decompress(const u8 *src, unsigned int slen, struct zip_kernel_ctx *zip_ctx) { struct zip_operation *zip_ops = NULL; - struct zip_state zip_state; + struct zip_state *zip_state; struct zip_device *zip = NULL; int ret; @@ -168,7 +171,10 @@ int zip_decompress(const u8 *src, unsigned int slen, if (!zip) return -ENODEV; - memset(&zip_state, 0, sizeof(struct zip_state)); + zip_state = kzalloc(sizeof(*zip_state), GFP_KERNEL); + if (!zip_state) + return -ENOMEM; + zip_ops = &zip_ctx->zip_decomp; memcpy(zip_ops->input, src, slen); @@ -179,13 +185,13 @@ int zip_decompress(const u8 *src, unsigned int slen, zip_ops->input_len = slen; zip_ops->output_len = *dlen; - ret = zip_inflate(zip_ops, &zip_state, zip); + ret = zip_inflate(zip_ops, zip_state, zip); if (!ret) { *dlen = zip_ops->output_len; memcpy(dst, zip_ops->output, *dlen); } - + kfree(zip_state); return ret; } -- 2.7.4

7 years, 5 months

2
2
0 0

Re: [GIT PULL] commits for Linux 3.18

by Harsh Shandilya

On 5 April 2018 12:32:38 PM IST, Harsh Shandilya <msfjarvis(a)gmail.com> wrote: > > >On 5 April 2018 11:54:28 AM IST, Sasha Levin ><Alexander.Levin(a)microsoft.com> wrote: >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA512 >> >>Hi Greg, >> >>Pleae pull commits for Linux 3.18 . >> >>I've sent a review request for all commits over a week ago and all >>comments were addressed. >> >> >>Thanks, >>Sasha >> >>===== >> >> >>The following changes since commit >>89dad4ea47357950b8ba09886e02ff4fd0793f9e: >> >> Linux 3.18.99 (2018-03-11 16:12:20 +0100) >> >>are available in the Git repository at: >> >>git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git >>tags/for-greg-3.18-04052018 >> >>for you to fetch changes up to >>5ea952bd1f538212d63bbd34b42e2cc769074259: >> >>signal/arm: Document conflicts with SI_USER and SIGFPE (2018-04-05 >>00:51:03 -0400) >> >>- ---------------------------------------------------------------- >>for-greg-3.18-04052018 >> >>- ---------------------------------------------------------------- >>Jason A. Donenfeld (1): >> skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow >> >This patch introduces build warnings[1] with GCC 7.3.1 that were fixed >upstream by commit 3f29770723fe498a5c5f57c3a31a996ebdde03e1 ("ipsec: >check return value of skb_to_sgvec always"). FWIW, this was an arm64 build in the CAF msm-3.18 tree with the attached config, but the warning exists on x86_64 with a clean -stable tree as well. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

7 years, 5 months

1
0
0 0

Re: [PATCH v2] nvmet: fix nvmet_execute_write_zeroes function

by Sasha Levin

Hi "Rodrigo R. Galvao". [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 6.9916) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: d262920998c8: ("nvmet: add support for the Write Zeroes command") 78ce3daa7d70: ("nvmet: fix byte swap in nvmet_execute_write_zeroes") d262920998c8: ("nvmet: add support for the Write Zeroes command") v4.4.126: Failed to apply! Possible dependencies: d262920998c8: ("nvmet: add support for the Write Zeroes command") a07b4970f464: ("nvmet: add a generic NVMe target") 78ce3daa7d70: ("nvmet: fix byte swap in nvmet_execute_write_zeroes") d262920998c8: ("nvmet: add support for the Write Zeroes command") a07b4970f464: ("nvmet: add a generic NVMe target") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

2
1
0 0

Re: [PATCH] Input: synaptics-rmi4 - Fix an unchecked out of memory error path

by Sasha Levin

Hi Christophe JAILLET. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 7.5278) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Failed to apply! Possible dependencies: 8d99758dee31: ("Input: synaptics-rmi4 - add SPI transport driver") ff8f83708b3e: ("Input: synaptics-rmi4 - add support for 2D sensors and F11") fdf51604f104: ("Input: synaptics-rmi4 - add I2C transport driver") 2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") 2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") fdf51604f104: ("Input: synaptics-rmi4 - add I2C transport driver") 2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") 2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH net v5 3/3] ipv6: udp6: set dst cache for a connected sk if current not valid

by Sasha Levin

Hi Alexey Kodanev. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: 33c162a980fe ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update. The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.15.15: Failed to apply! Possible dependencies: 22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()") v4.14.32: Failed to apply! Possible dependencies: 22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()") v4.9.92: Failed to apply! Possible dependencies: 22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()") -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] f2fs: fix to show encrypt flag in FS_IOC_GETFLAGS

by Sasha Levin

Hi Chao Yu. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 11.4088) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: 2c1d03056991: ("f2fs: support F2FS_IOC_FS{GET,SET}XATTR") 34dc77ad7436: ("f2fs: add ioctl to do gc with target block address") e066b83c9b40: ("f2fs: add ioctl to flush data from faster device to cold area") cac5a3d8f517: ("f2fs: fix 446 coding style warnings in f2fs.h") 7c45729a4d6d: ("f2fs: keep dirty inodes selectively for checkpoint") 15d04354555f: ("f2fs: call f2fs_balance_fs for setattr") v4.4.126: Failed to apply! Possible dependencies: 2c1d03056991: ("f2fs: support F2FS_IOC_FS{GET,SET}XATTR") 34dc77ad7436: ("f2fs: add ioctl to do gc with target block address") e066b83c9b40: ("f2fs: add ioctl to flush data from faster device to cold area") 4dd6f977fc77: ("f2fs: support an ioctl to move a range of data blocks") d323d005ac4a: ("f2fs: support file defragment") 8da4b8c48e7b: ("lib/uuid.c: move generate_random_uuid() to uuid.c") 9b7365fc1c82: ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA

by Sasha Levin

Hi Jian-Hong Pan. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 8.0442) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Failed to apply! Possible dependencies: 0202f5cd9aab: ("ALSA: hda/realtek - Add support for ALC1220") v4.9.92: Failed to apply! Possible dependencies: 0202f5cd9aab: ("ALSA: hda/realtek - Add support for ALC1220") 7beb3a6e9335: ("ALSA: hda - Support Gigabyte Gaming board with dual Realtek codecs") v4.4.126: Failed to apply! Possible dependencies: 0202f5cd9aab: ("ALSA: hda/realtek - Add support for ALC1220") 7beb3a6e9335: ("ALSA: hda - Support Gigabyte Gaming board with dual Realtek codecs") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] resource: Fix integer overflow at reallocation

by Sasha Levin

Hi Takashi Iwai. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: 23c570a67448 resource: ability to resize an allocated resource. The bot has also determined it's probably a bug fixing patch. (score: 99.2157) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 02/45] Fix exception_enter() return value

by Sasha Levin

Hi David Howells. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 5.5190) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Failed to apply! Possible dependencies: 2e9d1e150abf: ("x86/entry: Avoid interrupt flag save and restore") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH net 2/2] net: bgmac: Fix endian access in bgmac_dma_tx_ring_free()

by Sasha Levin

Hi Florian Fainelli. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: 9cde94506eac bgmac: implement scatter/gather support. The bot has also determined it's probably a bug fixing patch. (score: 45.9160) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH net 1/2] net: bgmac: Correctly annotate register space

by Sasha Levin

Hi Florian Fainelli. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: f6a95a24957a net: ethernet: bgmac: Add platform device support. The bot has also determined it's probably a bug fixing patch. (score: 67.8237) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: dd5c5d037f5e: ("net: ethernet: bgmac: add NS2 support") 1676aba5ef7e: ("net: ethernet: bgmac: device tree phy enablement") -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] kvm: Add emulation for movups/movupd

by Sasha Levin

Hi Stefan Fritsch. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 5.6100) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH] soc: bcm: raspberrypi-power: Fix use of __packed

by Sasha Levin

Hi Florian Fainelli. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: a09cd356586d ARM: bcm2835: add rpi power domain driver. The bot has also determined it's probably a bug fixing patch. (score: 35.5765) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH net] route: check sysctl_fib_multipath_use_neigh earlier than hash

by Sasha Levin

Hi Xin Long. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: a6db4494d218 net: ipv4: Consider failed nexthops in multipath routes. The bot has also determined it's probably a bug fixing patch. (score: 58.0140) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 01/12] m68k/mac: Revisit floppy disc controller base addresses

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 17.4954) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Failed to apply! Possible dependencies: b87eaec27eca: ("nubus: Add expansion_type values for various Mac models") v4.14.32: Failed to apply! Possible dependencies: b87eaec27eca: ("nubus: Add expansion_type values for various Mac models") v4.9.92: Failed to apply! Possible dependencies: b87eaec27eca: ("nubus: Add expansion_type values for various Mac models") a9373f40ac3a: ("m68k/mac: Adopt platform_device_register_simple()") v4.4.126: Failed to apply! Possible dependencies: b87eaec27eca: ("nubus: Add expansion_type values for various Mac models") a9373f40ac3a: ("m68k/mac: Adopt platform_device_register_simple()") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 30.4620) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 08/12] block/swim: Don't log an error message for an invalid ioctl

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 3.2953) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 07/12] block/swim: Remove extra put_disk() call from error path

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 1.4859) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: 103db8b2dfa5: ("swim: stop sharing request queue across multiple gendisks") v4.4.126: Failed to apply! Possible dependencies: 103db8b2dfa5: ("swim: stop sharing request queue across multiple gendisks") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 11/12] block/swim: Fix IO error at end of medium

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 30.0899) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Failed to apply! Possible dependencies: 1eaee38a196c: ("block/swim: Rename macros to avoid inconsistent inverted logic") v4.14.32: Failed to apply! Possible dependencies: 1eaee38a196c: ("block/swim: Rename macros to avoid inconsistent inverted logic") v4.9.92: Failed to apply! Possible dependencies: 1eaee38a196c: ("block/swim: Rename macros to avoid inconsistent inverted logic") v4.4.126: Failed to apply! Possible dependencies: 1eaee38a196c: ("block/swim: Rename macros to avoid inconsistent inverted logic") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 12/12] block/swim: Select appropriate drive on device open

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 3.6525) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 02/12] m68k/mac: Fix SWIM memory resource end address

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 10.3464) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Failed to apply! Possible dependencies: a9373f40ac3a: ("m68k/mac: Adopt platform_device_register_simple()") v4.4.126: Failed to apply! Possible dependencies: a9373f40ac3a: ("m68k/mac: Adopt platform_device_register_simple()") Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 10/12] block/swim: Check drive type

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 7.1126) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build failed! Errors: drivers/block/swim.c:838:26: error: ‘ONEMEG_DRIVE’ undeclared (first use in this function); did you mean ‘TWOMEG_DRIVE’? v4.14.32: Build failed! Errors: drivers/block/swim.c:838:26: error: ‘ONEMEG_DRIVE’ undeclared (first use in this function); did you mean ‘TWOMEG_DRIVE’? v4.9.92: Build failed! Errors: drivers/block/swim.c:822:26: error: ‘ONEMEG_DRIVE’ undeclared (first use in this function); did you mean ‘TWOMEG_DRIVE’? v4.4.126: Build failed! Errors: drivers/block/swim.c:822:26: error: ‘ONEMEG_DRIVE’ undeclared (first use in this function); did you mean ‘TWOMEG_DRIVE’? Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 06/12] block/swim: Fix array bounds check

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed because it contains a "Fixes:" tag. fixing commit: 8852ecd97488 m68k: mac - Add SWIM floppy support. The bot has also determined it's probably a bug fixing patch. (score: 56.6352) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 05/12] block/swim: Use HEDSEL bit in ISM mode register

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 10.3364) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

Re: [PATCH 04/12] m68k/mac: Place ISM IOP in bypass mode

by Sasha Levin

Hi Finn Thain. [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 21.9936) The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, v4.15.15: Build OK! v4.14.32: Build OK! v4.9.92: Build OK! v4.4.126: Build OK! Please let us know if you'd like to have this patch included in a stable tree. -- Thanks. Sasha

7 years, 5 months

1
0
0 0

[PATCH 2/2] sd_zbc: Avoid errors due to sd_zbc_setup() execution

by Damien Le Moal

From: Bart Van Assche <bart.vanassche(a)wdc.com> Since SCSI scanning occurs asynchronously, since sd_revalidate_disk() is called from sd_probe_async() and since sd_revalidate_disk() calls sd_zbc_read_zones() it can happen that sd_zbc_read_zones() is called concurrently with operations referencing a drive zone bitmaps and number of zones. Make sure that this race does not cause failures when revalidate does not detect any change by making the following changes to sd_zbc_setup(): - Ensure that sd_zbc_setup_seq_zones_bitmap() does not change any ZBC metadata in the request queue. - Only modify the ZBC information in the request queue that has changed. If the number of zones has changed, update q->nr_zones, q->seq_zones_wlock and q->seq_zones_bitmap. If the type of some zones has changed but not the number of zones, only update the zone type information. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> [Damien] Updated commit message and changed nr_zones/bitmap swap order. Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Hannes Reinecke <hare(a)suse.com> Cc: stable(a)vger.kernel.org --- drivers/scsi/sd_zbc.c | 45 +++++++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 18 deletions(-) diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c index b59454ed5087..39ddbe92769c 100644 --- a/drivers/scsi/sd_zbc.c +++ b/drivers/scsi/sd_zbc.c @@ -551,14 +551,13 @@ static sector_t sd_zbc_get_seq_zones(struct scsi_disk *sdkp, unsigned char *buf, } /** - * sd_zbc_setup_seq_zones_bitmap - Initialize the disk seq zone bitmap. + * sd_zbc_setup_seq_zones_bitmap - Initialize a seq zone bitmap. * @sdkp: target disk * * Allocate a zone bitmap and initialize it by identifying sequential zones. */ -static int sd_zbc_setup_seq_zones_bitmap(struct scsi_disk *sdkp) +static unsigned long *sd_zbc_setup_seq_zones_bitmap(struct scsi_disk *sdkp) { - struct request_queue *q = sdkp->disk->queue; unsigned long *seq_zones_bitmap; sector_t lba = 0; unsigned char *buf; @@ -566,7 +565,7 @@ static int sd_zbc_setup_seq_zones_bitmap(struct scsi_disk *sdkp) seq_zones_bitmap = sd_zbc_alloc_zone_bitmap(sdkp); if (!seq_zones_bitmap) - return -ENOMEM; + return ERR_PTR(-ENOMEM); buf = kmalloc(SD_ZBC_BUF_SIZE, GFP_KERNEL); if (!buf) @@ -589,12 +588,9 @@ static int sd_zbc_setup_seq_zones_bitmap(struct scsi_disk *sdkp) kfree(buf); if (ret) { kfree(seq_zones_bitmap); - return ret; + return ERR_PTR(ret); } - - q->seq_zones_bitmap = seq_zones_bitmap; - - return 0; + return seq_zones_bitmap; } static void sd_zbc_cleanup(struct scsi_disk *sdkp) @@ -630,24 +626,37 @@ static int sd_zbc_setup(struct scsi_disk *sdkp) * of zones changed. */ if (sdkp->nr_zones != q->nr_zones) { + struct request_queue *q = sdkp->disk->queue; + unsigned long *seq_zones_wlock = NULL, *seq_zones_bitmap = NULL; + size_t zone_bitmap_size; - sd_zbc_cleanup(sdkp); - - q->nr_zones = sdkp->nr_zones; if (sdkp->nr_zones) { - q->seq_zones_wlock = sd_zbc_alloc_zone_bitmap(sdkp); - if (!q->seq_zones_wlock) { + seq_zones_wlock = sd_zbc_alloc_zone_bitmap(sdkp); + if (!seq_zones_wlock) { ret = -ENOMEM; goto err; } - ret = sd_zbc_setup_seq_zones_bitmap(sdkp); - if (ret) { - sd_zbc_cleanup(sdkp); + seq_zones_bitmap = sd_zbc_setup_seq_zones_bitmap(sdkp); + if (IS_ERR(seq_zones_bitmap)) { + ret = PTR_ERR(seq_zones_bitmap); + kfree(seq_zones_wlock); goto err; } } - + zone_bitmap_size = BITS_TO_LONGS(sdkp->nr_zones) * + sizeof(unsigned long); + if (q->nr_zones != sdkp->nr_zones) { + swap(q->seq_zones_wlock, seq_zones_wlock); + swap(q->seq_zones_bitmap, seq_zones_bitmap); + q->nr_zones = sdkp->nr_zones; + } else if (memcmp(q->seq_zones_bitmap, seq_zones_bitmap, + zone_bitmap_size) != 0) { + memcpy(q->seq_zones_bitmap, seq_zones_bitmap, + zone_bitmap_size); + } + kfree(seq_zones_wlock); + kfree(seq_zones_bitmap); } return 0; -- 2.14.3

7 years, 5 months

3
2
0 0

[PATCH 1/2] sd_zbc: Avoid errors due to sd_zbc_check_zone_size() execution

by Damien Le Moal

When sd_revalidate() is executed for a ZBC disk (zoned block device), sd_zbc_read_zones() is called to revalidate the disk zone configuration. This executes sd_zbc_check_zone_size() to check that the disk zone sizes are in line with the defined constraints (all zones must be the same size and a power of 2 number of LBAs). As part of its execution, sd_zbc_check_zone_size() was temporarily setting sdkp->zone_blocks to 0. If during the execution of sd_zbc_check_zone_size() within sd_revalidate() context, another context issues a command which references sdkp->zone_blocks to check zone alignment of the command (e.g. a zone reset is issued and sd_zbc_setup_reset_cmnd() is called), an invalid value for the disk zone size is used and the alignment check fails. Simply fix this by using an on-stack variable inside sd_zbc_check_zone_size() instead of directly using sdkp->zone_blocks. This change is valid for both revalidate as well as for the first scan of the device. Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: <stable(a)vger.kernel.org> --- drivers/scsi/sd_zbc.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c index 89cf4498f535..b59454ed5087 100644 --- a/drivers/scsi/sd_zbc.c +++ b/drivers/scsi/sd_zbc.c @@ -403,6 +403,7 @@ static int sd_zbc_check_capacity(struct scsi_disk *sdkp, unsigned char *buf) */ static int sd_zbc_check_zone_size(struct scsi_disk *sdkp) { + u64 sdkp_zone_blocks = sdkp->zone_blocks; u64 zone_blocks = 0; sector_t block = 0; unsigned char *buf; @@ -412,8 +413,6 @@ static int sd_zbc_check_zone_size(struct scsi_disk *sdkp) int ret; u8 same; - sdkp->zone_blocks = 0; - /* Get a buffer */ buf = kmalloc(SD_ZBC_BUF_SIZE, GFP_KERNEL); if (!buf) @@ -446,11 +445,11 @@ static int sd_zbc_check_zone_size(struct scsi_disk *sdkp) /* Parse zone descriptors */ while (rec < buf + buf_len) { zone_blocks = get_unaligned_be64(&rec[8]); - if (sdkp->zone_blocks == 0) { - sdkp->zone_blocks = zone_blocks; - } else if (zone_blocks != sdkp->zone_blocks && + if (sdkp_zone_blocks == 0) { + sdkp_zone_blocks = zone_blocks; + } else if (zone_blocks != sdkp_zone_blocks && (block + zone_blocks < sdkp->capacity - || zone_blocks > sdkp->zone_blocks)) { + || zone_blocks > sdkp_zone_blocks)) { zone_blocks = 0; goto out; } @@ -467,7 +466,7 @@ static int sd_zbc_check_zone_size(struct scsi_disk *sdkp) } while (block < sdkp->capacity); - zone_blocks = sdkp->zone_blocks; + zone_blocks = sdkp_zone_blocks; out: if (!zone_blocks) { -- 2.14.3

7 years, 5 months

3
2
0 0

[PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up

by Lyude Paul

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- Sorry for all the spam guys! This is my last attempt at getting this patch to actually come up on intel-gfx's patchwork page instead of dri-devel. I have no idea what is going on with patchwork right now :|, but maybe removing dri-devel from the CC entirely will help. drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

7 years, 5 months

1
0
0 0

[PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up

by Lyude Paul

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

7 years, 5 months

1
0
0 0

[nacked] mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/memblock: fix potential issue in memblock_search_pfn_nid() has been removed from the -mm tree. Its filename was mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid.patch This patch was dropped because it was nacked ------------------------------------------------------ From: Wei Yang <richard.weiyang(a)gmail.com> Subject: mm/memblock: fix potential issue in memblock_search_pfn_nid() memblock_search_pfn_nid() returns the nid and the [start|end]_pfn of the memory region where pfn sits in. While the calculation of start_pfn has potential issue when the regions base is not page aligned. For example, we assume PAGE_SHIFT is 12 and base is 0x1234. Current implementation would return 1 while this is not correct. This patch fixes this by using PFN_UP(). The original commit is commit e76b63f80d93 ("memblock, numa: binary search node id") and merged in v3.12. Link: http://lkml.kernel.org/r/20180330033055.22340-1-richard.weiyang@gmail.com Fixes: e76b63f80d93 ("memblock, numa: binary search node id") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Yinghai Lu <yinghai(a)kernel.org> Cc: Jia He <hejianet(a)gmail.com> Cc: <stable(a)vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/memblock.c~mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid mm/memblock.c --- a/mm/memblock.c~mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid +++ a/mm/memblock.c @@ -1646,7 +1646,7 @@ int __init_memblock memblock_search_pfn_ if (mid == -1) return -1; - *start_pfn = PFN_DOWN(type->regions[mid].base); + *start_pfn = PFN_UP(type->regions[mid].base); *end_pfn = PFN_DOWN(type->regions[mid].base + type->regions[mid].size); return type->regions[mid].nid; _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are mm-check-__highest_present_sectioin_nr-directly-in-memory_dev_init.patch

7 years, 5 months

1
0
0 0

+ lib-fix-stall-in-__bitmap_parselist.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib: fix stall in __bitmap_parselist() has been added to the -mm tree. Its filename is lib-fix-stall-in-__bitmap_parselist.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/lib-fix-stall-in-__bitmap_parselis… and later at http://ozlabs.org/~akpm/mmotm/broken-out/lib-fix-stall-in-__bitmap_parselis… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Yury Norov <ynorov(a)caviumnetworks.com> Subject: lib: fix stall in __bitmap_parselist() syzbot is catching stalls at __bitmap_parselist() (https://syzkaller.appspot.com/bug?id=ad7e0351fbc90535558514a71cd3edc1168199…). The trigger is unsigned long v = 0; bitmap_parselist("7:,", &v, BITS_PER_LONG); which results in hitting infinite loop at while (a <= b) { off = min(b - a + 1, used_size); bitmap_set(maskp, a, off); a += group_size; } due to used_size == group_size == 0. Link: http://lkml.kernel.org/r/20180404162647.15763-1-ynorov@caviumnetworks.com Fixes: 0a5ce0831d04382a ("lib/bitmap.c: make bitmap_parselist() thread-safe and much faster") Signed-off-by: Yury Norov <ynorov(a)caviumnetworks.com> Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+6887cbb011c8054e8a3d(a)syzkaller.appspotmail.com> Cc: Noam Camus <noamca(a)mellanox.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/bitmap.c | 2 +- lib/test_bitmap.c | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff -puN lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/bitmap.c --- a/lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/bitmap.c @@ -607,7 +607,7 @@ static int __bitmap_parselist(const char /* if no digit is after '-', it's wrong*/ if (at_start && in_range) return -EINVAL; - if (!(a <= b) || !(used_size <= group_size)) + if (!(a <= b) || group_size == 0 || !(used_size <= group_size)) return -EINVAL; if (b >= nmaskbits) return -ERANGE; diff -puN lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/test_bitmap.c --- a/lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/test_bitmap.c @@ -255,6 +255,10 @@ static const struct test_bitmap_parselis {-EINVAL, "-1", NULL, 8, 0}, {-EINVAL, "-0", NULL, 8, 0}, {-EINVAL, "10-1", NULL, 8, 0}, + {-EINVAL, "0-31:", NULL, 8, 0}, + {-EINVAL, "0-31:0", NULL, 8, 0}, + {-EINVAL, "0-31:0/0", NULL, 8, 0}, + {-EINVAL, "0-31:1/0", NULL, 8, 0}, {-EINVAL, "0-31:10/1", NULL, 8, 0}, }; _ Patches currently in -mm which might be from ynorov(a)caviumnetworks.com are lib-fix-stall-in-__bitmap_parselist.patch

7 years, 5 months

1
0
0 0

[PATCH] blk-mq: order getting budget and driver tag

by Ming Lei

This patch orders getting budget and driver tag by making sure to acquire driver tag after budget is got, this way can help to avoid the following race: 1) before dispatch request from scheduler queue, get one budget first, then dequeue a request, call it request A. 2) in another IO path for dispatching request B which is from hctx->dispatch, driver tag is got, then try to get budget in blk_mq_dispatch_rq_list(), unfortunately the budget is held by request A. 3) meantime blk_mq_dispatch_rq_list() is called for dispatching request A, and try to get driver tag first, unfortunately no driver tag is available because the driver tag is held by request B 4) both two IO pathes can't move on, and IO stall is caused. This issue can be observed when running dbench on USB storage. This patch fixes this issue by always getting budget before getting driver tag. Cc: stable(a)vger.kernel.org Fixes: de1482974080ec9e ("blk-mq: introduce .get_budget and .put_budget in blk_mq_ops") Cc: Christoph Hellwig <hch(a)lst.de> Cc: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 16e83e6df404..90838e998f66 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1188,7 +1188,12 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, struct blk_mq_queue_data bd; rq = list_first_entry(list, struct request, queuelist); - if (!blk_mq_get_driver_tag(rq, &hctx, false)) { + + hctx = blk_mq_map_queue(rq->q, rq->mq_ctx->cpu); + if (!got_budget && !blk_mq_get_dispatch_budget(hctx)) + break; + + if (!blk_mq_get_driver_tag(rq, NULL, false)) { /* * The initial allocation attempt failed, so we need to * rerun the hardware queue when a tag is freed. The @@ -1197,8 +1202,7 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, * we'll re-run it below. */ if (!blk_mq_mark_tag_wait(&hctx, rq)) { - if (got_budget) - blk_mq_put_dispatch_budget(hctx); + blk_mq_put_dispatch_budget(hctx); /* * For non-shared tags, the RESTART check * will suffice. @@ -1209,11 +1213,6 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, } } - if (!got_budget && !blk_mq_get_dispatch_budget(hctx)) { - blk_mq_put_driver_tag(rq); - break; - } - list_del_init(&rq->queuelist); bd.rq = rq; @@ -1812,11 +1811,11 @@ static blk_status_t __blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx, if (q->elevator && !bypass_insert) goto insert; - if (!blk_mq_get_driver_tag(rq, NULL, false)) + if (!blk_mq_get_dispatch_budget(hctx)) goto insert; - if (!blk_mq_get_dispatch_budget(hctx)) { - blk_mq_put_driver_tag(rq); + if (!blk_mq_get_driver_tag(rq, NULL, false)) { + blk_mq_put_dispatch_budget(hctx); goto insert; } -- 2.9.5

7 years, 5 months

2
1
0 0

[PATCH 1/1] drm/i915: Keep AUX block running when disabling DPMS for MST

by Lyude Paul

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when none of the sinks are turned on since it's possible for us to have a single atomic commit which results in disabling each downstream sink, followed by subsequently re-enabling each sink. If we don't do this, we'll end up stalling any pending ESI interrupts from the sink for up to 1ms. Unfortunately, dropping ESIs during this timespan makes it so that link fallback retraining for MST (which I will be submitting to the ML shortly) fails due to the channel EQ failure interrupts potentially getting dropped. Additionally, when performing a modeset that brings the hub status's link status from bad -> good having ESIs disabled for that long causes us to miss the hub's response to us trying to start link training as well. Since any sink with MST is going to support DisplayPort 1.2 anyway, save us the hassle of trying to wait until the sink comes back up and just never shut the aux block down. Changes since v2: - Fix patch name, no functional changes Changes since v3: - acks, t-b's Signed-off-by: Lyude Paul <lyude(a)redhat.com> Acked-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Tested-by: Laura Abbott <labbott(a)redhat.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..0479c377981b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) return; if (mode != DRM_MODE_DPMS_ON) { + unsigned char data = intel_dp->is_mst ? + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; + if (downstream_hpd_needs_d0(intel_dp)) return; - ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, - DP_SET_POWER_D3); + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data); } else { struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); -- 2.14.3

7 years, 5 months

1
0
0 0

[PATCH v2][RESEND] drm/i915: Keep AUX block running when disabling DPMS for MST

by Lyude Paul

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when none of the sinks are turned on since it's possible for us to have a single atomic commit which results in disabling each downstream sink, followed by subsequently re-enabling each sink. If we don't do this, we'll end up stalling any pending ESI interrupts from the sink for up to 1ms. Unfortunately, dropping ESIs during this timespan makes it so that link fallback retraining for MST (which I will be submitting to the ML shortly) fails due to the channel EQ failure interrupts potentially getting dropped. Additionally, when performing a modeset that brings the hub status's link status from bad -> good having ESIs disabled for that long causes us to miss the hub's response to us trying to start link training as well. Since any sink with MST is going to support DisplayPort 1.2 anyway, save us the hassle of trying to wait until the sink comes back up and just never shut the aux block down. Changes since v2: - Fix patch name, no functional changes Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..0479c377981b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) return; if (mode != DRM_MODE_DPMS_ON) { + unsigned char data = intel_dp->is_mst ? + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; + if (downstream_hpd_needs_d0(intel_dp)) return; - ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, - DP_SET_POWER_D3); + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data); } else { struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); -- 2.14.3

7 years, 5 months

1
0
0 0

[PATCH] Revert "scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"

by Bart Van Assche

The description of commit e39a97353e53 is wrong: it mentions that commit 2a842acab109 introduced a bug in __scsi_error_from_host_byte() although that commit did not change the behavior of that function. Additionally, that commit introduced a severe bug: it causes commands that fail with hostbyte=DID_OK and driverbyte=DRIVER_SENSE to be completed with BLK_STS_OK. Although that commit claims to fix a bug it does not mention which bug it fixes. Hence revert that commit. Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Reported-by: Damien Le Moal <damien.lemoal(a)wdc.com> Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Cc: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: stable(a)vger.kernel.org --- drivers/scsi/scsi_lib.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 74a39db57d49..71f5b010684c 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -735,8 +735,6 @@ static blk_status_t __scsi_error_from_host_byte(struct scsi_cmnd *cmd, int result) { switch (host_byte(result)) { - case DID_OK: - return BLK_STS_OK; case DID_TRANSPORT_FAILFAST: return BLK_STS_TRANSPORT; case DID_TARGET_FAILURE: -- 2.16.2

7 years, 5 months

2
1
0 0

[PATCH] w1: gpio: fix problem with platfom data in w1-gpio

by Pawel Dembicki

In devices, where fdt is used, is impossible to apply platform data without proper fdt node. This patch allow to use platform data in devices with fdt. Signed-off-by: Pawel Dembicki <paweldembicki(a)gmail.com> --- drivers/w1/masters/w1-gpio.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c index a90728ceec5a..7b80762941af 100644 --- a/drivers/w1/masters/w1-gpio.c +++ b/drivers/w1/masters/w1-gpio.c @@ -112,17 +112,16 @@ static int w1_gpio_probe_dt(struct platform_device *pdev) static int w1_gpio_probe(struct platform_device *pdev) { struct w1_bus_master *master; - struct w1_gpio_platform_data *pdata; + struct w1_gpio_platform_data *pdata = dev_get_platdata(&pdev->dev); int err; - if (of_have_populated_dt()) { + if (of_have_populated_dt() && !pdata) { err = w1_gpio_probe_dt(pdev); if (err < 0) return err; + pdata = dev_get_platdata(&pdev->dev); } - pdata = dev_get_platdata(&pdev->dev); - if (!pdata) { dev_err(&pdev->dev, "No configuration data\n"); return -ENXIO; -- 2.14.1

7 years, 5 months

4
7
0 0

[PATCHv2] scsi: Fix failed request error code

by Hannes Reinecke

With the introduction of commit e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking additional sense information will have a return code set to BLK_STS_OK. This results in the request issuer to see successful request execution despite the failure. An example of such case is an unaligned write on a host managed ZAC disk connected to a SAS HBA with a malfunctioning SAT. The unaligned write command gets aborted but has no additional sense information. sd 10:0:0:0: [sde] tag#3905 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 10:0:0:0: [sde] tag#3905 Sense Key : Aborted Command [current] sd 10:0:0:0: [sde] tag#3905 Add. Sense: No additional sense information sd 10:0:0:0: [sde] tag#3905 CDB: Write(16) 8a 00 00 00 00 00 02 0c 00 01 00 00 00 01 00 00 print_req_error: I/O error, dev sde, sector 274726920 In scsi_io_completion(), sense key handling to not change the request error code and success being reported to the issuer. Fix this by making sure that the error code always indicates an error if scsi_io_completion() decide that the action to be taken for a failed command is to not retry it and terminate it immediately (ACTION_FAIL) . Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Signed-off-by: Hannes Reinecke <hare(a)suse.com> Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Cc: <stable(a)vger.kernel.org> --- drivers/scsi/scsi_lib.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 393f9db8f41b..9389c41e2829 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -905,6 +905,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes) goto requeue; error = __scsi_error_from_host_byte(cmd, result); + /* + * If the hostbyte was DID_OK, but the sense code is valid + * we always should set BLK_STS_IOERR. + */ + if (error == BLK_STS_OK && sense_valid) + error = BLK_STS_IOERR; if (host_byte(result) == DID_RESET) { /* Third party bus reset or reset for error recovery -- 2.12.3

7 years, 5 months

3
2
0 0

[PATCH for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

by Mauro Carvalho Chehab

Hi Greg, Those are the backports meant to solve CVE-2017-13166 on Kernel 3.18. It contains two v4l2-ctrls fixes that are required to avoid crashes at the test application. I wrote two patches myself for Kernel 3.18 in order to solve some issues specific for Kernel 3.18 with aren't needed upstream. one is actually a one-line change backport. The other one makes sure that both 32-bits and 64-bits version of some ioctl calls will return the same value for a reserved field. I noticed an extra bug while testing it, but the bug also hits upstream, and should be backported all the way down all stable/LTS versions. So, I'll send it the usual way, after merging upsream. Regards, Mauro Daniel Mentz (2): media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic Hans Verkuil (12): media: v4l2-ioctl.c: don't copy back the result for -ENOTTY media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF media: v4l2-compat-ioctl32.c: fix the indentation media: v4l2-compat-ioctl32.c: move 'helper' functions to __get/put_v4l2_format32 media: v4l2-compat-ioctl32.c: avoid sizeof(type) media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32 media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32 media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors media: v4l2-ctrls: fix sparse warning Mauro Carvalho Chehab (2): media: v4l2-compat-ioctl32: use compat_u64 for video standard media: v4l2-compat-ioctl32: initialize a reserved field Ricardo Ribalda (2): vb2: V4L2_BUF_FLAG_DONE is set after DQBUF media: media/v4l2-ctrls: volatiles should not generate CH_VALUE drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1020 +++++++++++++++---------- drivers/media/v4l2-core/v4l2-ctrls.c | 96 ++- drivers/media/v4l2-core/v4l2-ioctl.c | 5 +- drivers/media/v4l2-core/videobuf2-core.c | 5 + 4 files changed, 691 insertions(+), 435 deletions(-) -- 2.14.3

7 years, 5 months

4
39
0 0

Patch "media: v4l2-compat-ioctl32.c: fix the indentation" 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 media: v4l2-compat-ioctl32.c: fix the indentation 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: media-v4l2-compat-ioctl32.c-fix-the-indentation.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 b7b957d429f601d6d1942122b339474f31191d75 Mon Sep 17 00:00:00 2001 From: Hans Verkuil <hans.verkuil(a)cisco.com> Date: Wed, 24 Jan 2018 04:35:48 -0500 Subject: media: v4l2-compat-ioctl32.c: fix the indentation From: Hans Verkuil <hans.verkuil(a)cisco.com> commit b7b957d429f601d6d1942122b339474f31191d75 upstream. The indentation of this source is all over the place. Fix this. This patch only changes whitespace. Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # for v4.15 and up Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 216 +++++++++++++------------- 1 file changed, 108 insertions(+), 108 deletions(-) --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c @@ -48,11 +48,11 @@ struct v4l2_window32 { static int get_v4l2_window32(struct v4l2_window *kp, struct v4l2_window32 __user *up) { if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_window32)) || - copy_from_user(&kp->w, &up->w, sizeof(up->w)) || - get_user(kp->field, &up->field) || - get_user(kp->chromakey, &up->chromakey) || - get_user(kp->clipcount, &up->clipcount)) - return -EFAULT; + copy_from_user(&kp->w, &up->w, sizeof(up->w)) || + get_user(kp->field, &up->field) || + get_user(kp->chromakey, &up->chromakey) || + get_user(kp->clipcount, &up->clipcount)) + return -EFAULT; if (kp->clipcount > 2048) return -EINVAL; if (kp->clipcount) { @@ -82,10 +82,10 @@ static int get_v4l2_window32(struct v4l2 static int put_v4l2_window32(struct v4l2_window *kp, struct v4l2_window32 __user *up) { if (copy_to_user(&up->w, &kp->w, sizeof(kp->w)) || - put_user(kp->field, &up->field) || - put_user(kp->chromakey, &up->chromakey) || - put_user(kp->clipcount, &up->clipcount)) - return -EFAULT; + put_user(kp->field, &up->field) || + put_user(kp->chromakey, &up->chromakey) || + put_user(kp->clipcount, &up->clipcount)) + return -EFAULT; return 0; } @@ -97,7 +97,7 @@ static inline int get_v4l2_pix_format(st } static inline int get_v4l2_pix_format_mplane(struct v4l2_pix_format_mplane *kp, - struct v4l2_pix_format_mplane __user *up) + struct v4l2_pix_format_mplane __user *up) { if (copy_from_user(kp, up, sizeof(struct v4l2_pix_format_mplane))) return -EFAULT; @@ -112,7 +112,7 @@ static inline int put_v4l2_pix_format(st } static inline int put_v4l2_pix_format_mplane(struct v4l2_pix_format_mplane *kp, - struct v4l2_pix_format_mplane __user *up) + struct v4l2_pix_format_mplane __user *up) { if (copy_to_user(up, kp, sizeof(struct v4l2_pix_format_mplane))) return -EFAULT; @@ -200,7 +200,7 @@ static int __get_v4l2_format32(struct v4 return get_v4l2_sliced_vbi_format(&kp->fmt.sliced, &up->fmt.sliced); default: printk(KERN_INFO "compat_ioctl32: unexpected VIDIOC_FMT type %d\n", - kp->type); + kp->type); return -EINVAL; } } @@ -241,7 +241,7 @@ static int __put_v4l2_format32(struct v4 return put_v4l2_sliced_vbi_format(&kp->fmt.sliced, &up->fmt.sliced); default: printk(KERN_INFO "compat_ioctl32: unexpected VIDIOC_FMT type %d\n", - kp->type); + kp->type); return -EINVAL; } } @@ -275,7 +275,7 @@ static int get_v4l2_standard32(struct v4 { /* other fields are not set by the user, nor used by the driver */ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_standard32)) || - get_user(kp->index, &up->index)) + get_user(kp->index, &up->index)) return -EFAULT; return 0; } @@ -283,13 +283,13 @@ static int get_v4l2_standard32(struct v4 static int put_v4l2_standard32(struct v4l2_standard *kp, struct v4l2_standard32 __user *up) { if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_standard32)) || - put_user(kp->index, &up->index) || - copy_to_user(up->id, &kp->id, sizeof(__u64)) || - copy_to_user(up->name, kp->name, 24) || - copy_to_user(&up->frameperiod, &kp->frameperiod, sizeof(kp->frameperiod)) || - put_user(kp->framelines, &up->framelines) || - copy_to_user(up->reserved, kp->reserved, 4 * sizeof(__u32))) - return -EFAULT; + put_user(kp->index, &up->index) || + copy_to_user(up->id, &kp->id, sizeof(__u64)) || + copy_to_user(up->name, kp->name, 24) || + copy_to_user(&up->frameperiod, &kp->frameperiod, sizeof(kp->frameperiod)) || + put_user(kp->framelines, &up->framelines) || + copy_to_user(up->reserved, kp->reserved, 4 * sizeof(__u32))) + return -EFAULT; return 0; } @@ -329,14 +329,14 @@ struct v4l2_buffer32 { }; static int get_v4l2_plane32(struct v4l2_plane __user *up, struct v4l2_plane32 __user *up32, - enum v4l2_memory memory) + enum v4l2_memory memory) { void __user *up_pln; compat_long_t p; if (copy_in_user(up, up32, 2 * sizeof(__u32)) || - copy_in_user(&up->data_offset, &up32->data_offset, - sizeof(__u32))) + copy_in_user(&up->data_offset, &up32->data_offset, + sizeof(__u32))) return -EFAULT; if (memory == V4L2_MEMORY_USERPTR) { @@ -350,7 +350,7 @@ static int get_v4l2_plane32(struct v4l2_ return -EFAULT; } else { if (copy_in_user(&up->m.mem_offset, &up32->m.mem_offset, - sizeof(__u32))) + sizeof(__u32))) return -EFAULT; } @@ -358,23 +358,23 @@ static int get_v4l2_plane32(struct v4l2_ } static int put_v4l2_plane32(struct v4l2_plane __user *up, struct v4l2_plane32 __user *up32, - enum v4l2_memory memory) + enum v4l2_memory memory) { if (copy_in_user(up32, up, 2 * sizeof(__u32)) || - copy_in_user(&up32->data_offset, &up->data_offset, - sizeof(__u32))) + copy_in_user(&up32->data_offset, &up->data_offset, + sizeof(__u32))) return -EFAULT; /* For MMAP, driver might've set up the offset, so copy it back. * USERPTR stays the same (was userspace-provided), so no copying. */ if (memory == V4L2_MEMORY_MMAP) if (copy_in_user(&up32->m.mem_offset, &up->m.mem_offset, - sizeof(__u32))) + sizeof(__u32))) return -EFAULT; /* For DMABUF, driver might've set up the fd, so copy it back. */ if (memory == V4L2_MEMORY_DMABUF) if (copy_in_user(&up32->m.fd, &up->m.fd, - sizeof(int))) + sizeof(int))) return -EFAULT; return 0; @@ -389,19 +389,19 @@ static int get_v4l2_buffer32(struct v4l2 int ret; if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_buffer32)) || - get_user(kp->index, &up->index) || - get_user(kp->type, &up->type) || - get_user(kp->flags, &up->flags) || - get_user(kp->memory, &up->memory) || - get_user(kp->length, &up->length)) - return -EFAULT; + get_user(kp->index, &up->index) || + get_user(kp->type, &up->type) || + get_user(kp->flags, &up->flags) || + get_user(kp->memory, &up->memory) || + get_user(kp->length, &up->length)) + return -EFAULT; if (V4L2_TYPE_IS_OUTPUT(kp->type)) if (get_user(kp->bytesused, &up->bytesused) || - get_user(kp->field, &up->field) || - get_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) || - get_user(kp->timestamp.tv_usec, - &up->timestamp.tv_usec)) + get_user(kp->field, &up->field) || + get_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) || + get_user(kp->timestamp.tv_usec, + &up->timestamp.tv_usec)) return -EFAULT; if (V4L2_TYPE_IS_MULTIPLANAR(kp->type)) { @@ -418,13 +418,13 @@ static int get_v4l2_buffer32(struct v4l2 uplane32 = compat_ptr(p); if (!access_ok(VERIFY_READ, uplane32, - num_planes * sizeof(struct v4l2_plane32))) + num_planes * sizeof(struct v4l2_plane32))) return -EFAULT; /* We don't really care if userspace decides to kill itself * by passing a very big num_planes value */ uplane = compat_alloc_user_space(num_planes * - sizeof(struct v4l2_plane)); + sizeof(struct v4l2_plane)); kp->m.planes = (__force struct v4l2_plane *)uplane; while (--num_planes >= 0) { @@ -442,12 +442,12 @@ static int get_v4l2_buffer32(struct v4l2 break; case V4L2_MEMORY_USERPTR: { - compat_long_t tmp; + compat_long_t tmp; - if (get_user(tmp, &up->m.userptr)) - return -EFAULT; + if (get_user(tmp, &up->m.userptr)) + return -EFAULT; - kp->m.userptr = (unsigned long)compat_ptr(tmp); + kp->m.userptr = (unsigned long)compat_ptr(tmp); } break; case V4L2_MEMORY_OVERLAY: @@ -473,22 +473,22 @@ static int put_v4l2_buffer32(struct v4l2 int ret; if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_buffer32)) || - put_user(kp->index, &up->index) || - put_user(kp->type, &up->type) || - put_user(kp->flags, &up->flags) || - put_user(kp->memory, &up->memory)) - return -EFAULT; + put_user(kp->index, &up->index) || + put_user(kp->type, &up->type) || + put_user(kp->flags, &up->flags) || + put_user(kp->memory, &up->memory)) + return -EFAULT; if (put_user(kp->bytesused, &up->bytesused) || - put_user(kp->field, &up->field) || - put_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) || - put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) || - copy_to_user(&up->timecode, &kp->timecode, sizeof(struct v4l2_timecode)) || - put_user(kp->sequence, &up->sequence) || - put_user(kp->reserved2, &up->reserved2) || - put_user(kp->reserved, &up->reserved) || - put_user(kp->length, &up->length)) - return -EFAULT; + put_user(kp->field, &up->field) || + put_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) || + put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) || + copy_to_user(&up->timecode, &kp->timecode, sizeof(struct v4l2_timecode)) || + put_user(kp->sequence, &up->sequence) || + put_user(kp->reserved2, &up->reserved2) || + put_user(kp->reserved, &up->reserved) || + put_user(kp->length, &up->length)) + return -EFAULT; if (V4L2_TYPE_IS_MULTIPLANAR(kp->type)) { num_planes = kp->length; @@ -552,11 +552,11 @@ static int get_v4l2_framebuffer32(struct u32 tmp; if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_framebuffer32)) || - get_user(tmp, &up->base) || - get_user(kp->capability, &up->capability) || - get_user(kp->flags, &up->flags) || - copy_from_user(&kp->fmt, &up->fmt, sizeof(up->fmt))) - return -EFAULT; + get_user(tmp, &up->base) || + get_user(kp->capability, &up->capability) || + get_user(kp->flags, &up->flags) || + copy_from_user(&kp->fmt, &up->fmt, sizeof(up->fmt))) + return -EFAULT; kp->base = (__force void *)compat_ptr(tmp); return 0; } @@ -566,11 +566,11 @@ static int put_v4l2_framebuffer32(struct u32 tmp = (u32)((unsigned long)kp->base); if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_framebuffer32)) || - put_user(tmp, &up->base) || - put_user(kp->capability, &up->capability) || - put_user(kp->flags, &up->flags) || - copy_to_user(&up->fmt, &kp->fmt, sizeof(up->fmt))) - return -EFAULT; + put_user(tmp, &up->base) || + put_user(kp->capability, &up->capability) || + put_user(kp->flags, &up->flags) || + copy_to_user(&up->fmt, &kp->fmt, sizeof(up->fmt))) + return -EFAULT; return 0; } @@ -602,11 +602,11 @@ static inline int put_v4l2_input32(struc } struct v4l2_ext_controls32 { - __u32 ctrl_class; - __u32 count; - __u32 error_idx; - __u32 reserved[2]; - compat_caddr_t controls; /* actually struct v4l2_ext_control32 * */ + __u32 ctrl_class; + __u32 count; + __u32 error_idx; + __u32 reserved[2]; + compat_caddr_t controls; /* actually struct v4l2_ext_control32 * */ }; struct v4l2_ext_control32 { @@ -645,11 +645,11 @@ static int get_v4l2_ext_controls32(struc compat_caddr_t p; if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_ext_controls32)) || - get_user(kp->ctrl_class, &up->ctrl_class) || - get_user(kp->count, &up->count) || - get_user(kp->error_idx, &up->error_idx) || - copy_from_user(kp->reserved, up->reserved, sizeof(kp->reserved))) - return -EFAULT; + get_user(kp->ctrl_class, &up->ctrl_class) || + get_user(kp->count, &up->count) || + get_user(kp->error_idx, &up->error_idx) || + copy_from_user(kp->reserved, up->reserved, sizeof(kp->reserved))) + return -EFAULT; n = kp->count; if (n == 0) { kp->controls = NULL; @@ -659,7 +659,7 @@ static int get_v4l2_ext_controls32(struc return -EFAULT; ucontrols = compat_ptr(p); if (!access_ok(VERIFY_READ, ucontrols, - n * sizeof(struct v4l2_ext_control32))) + n * sizeof(struct v4l2_ext_control32))) return -EFAULT; kcontrols = compat_alloc_user_space(n * sizeof(struct v4l2_ext_control)); kp->controls = (__force struct v4l2_ext_control *)kcontrols; @@ -694,11 +694,11 @@ static int put_v4l2_ext_controls32(struc compat_caddr_t p; if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_ext_controls32)) || - put_user(kp->ctrl_class, &up->ctrl_class) || - put_user(kp->count, &up->count) || - put_user(kp->error_idx, &up->error_idx) || - copy_to_user(up->reserved, kp->reserved, sizeof(up->reserved))) - return -EFAULT; + put_user(kp->ctrl_class, &up->ctrl_class) || + put_user(kp->count, &up->count) || + put_user(kp->error_idx, &up->error_idx) || + copy_to_user(up->reserved, kp->reserved, sizeof(up->reserved))) + return -EFAULT; if (!kp->count) return 0; @@ -706,7 +706,7 @@ static int put_v4l2_ext_controls32(struc return -EFAULT; ucontrols = compat_ptr(p); if (!access_ok(VERIFY_WRITE, ucontrols, - n * sizeof(struct v4l2_ext_control32))) + n * sizeof(struct v4l2_ext_control32))) return -EFAULT; while (--n >= 0) { @@ -743,15 +743,15 @@ struct v4l2_event32 { static int put_v4l2_event32(struct v4l2_event *kp, struct v4l2_event32 __user *up) { if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_event32)) || - put_user(kp->type, &up->type) || - copy_to_user(&up->u, &kp->u, sizeof(kp->u)) || - put_user(kp->pending, &up->pending) || - put_user(kp->sequence, &up->sequence) || - put_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) || - put_user(kp->timestamp.tv_nsec, &up->timestamp.tv_nsec) || - put_user(kp->id, &up->id) || - copy_to_user(up->reserved, kp->reserved, 8 * sizeof(__u32))) - return -EFAULT; + put_user(kp->type, &up->type) || + copy_to_user(&up->u, &kp->u, sizeof(kp->u)) || + put_user(kp->pending, &up->pending) || + put_user(kp->sequence, &up->sequence) || + put_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) || + put_user(kp->timestamp.tv_nsec, &up->timestamp.tv_nsec) || + put_user(kp->id, &up->id) || + copy_to_user(up->reserved, kp->reserved, 8 * sizeof(__u32))) + return -EFAULT; return 0; } @@ -768,12 +768,12 @@ static int get_v4l2_edid32(struct v4l2_e u32 tmp; if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_edid32)) || - get_user(kp->pad, &up->pad) || - get_user(kp->start_block, &up->start_block) || - get_user(kp->blocks, &up->blocks) || - get_user(tmp, &up->edid) || - copy_from_user(kp->reserved, up->reserved, sizeof(kp->reserved))) - return -EFAULT; + get_user(kp->pad, &up->pad) || + get_user(kp->start_block, &up->start_block) || + get_user(kp->blocks, &up->blocks) || + get_user(tmp, &up->edid) || + copy_from_user(kp->reserved, up->reserved, sizeof(kp->reserved))) + return -EFAULT; kp->edid = (__force u8 *)compat_ptr(tmp); return 0; } @@ -783,12 +783,12 @@ static int put_v4l2_edid32(struct v4l2_e u32 tmp = (u32)((unsigned long)kp->edid); if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_edid32)) || - put_user(kp->pad, &up->pad) || - put_user(kp->start_block, &up->start_block) || - put_user(kp->blocks, &up->blocks) || - put_user(tmp, &up->edid) || - copy_to_user(up->reserved, kp->reserved, sizeof(up->reserved))) - return -EFAULT; + put_user(kp->pad, &up->pad) || + put_user(kp->start_block, &up->start_block) || + put_user(kp->blocks, &up->blocks) || + put_user(tmp, &up->edid) || + copy_to_user(up->reserved, kp->reserved, sizeof(up->reserved))) + return -EFAULT; return 0; } Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are queue-3.18/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch queue-3.18/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch queue-3.18/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch queue-3.18/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch queue-3.18/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch queue-3.18/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch queue-3.18/media-v4l2-ctrls-fix-sparse-warning.patch queue-3.18/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch queue-3.18/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch queue-3.18/media-media-v4l2-ctrls-volatiles-should-not-generate-ch_value.patch queue-3.18/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch queue-3.18/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch queue-3.18/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch queue-3.18/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch queue-3.18/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch queue-3.18/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch

7 years, 5 months

1
0
0 0

Patch "media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF" 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 media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF 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: media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.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 3ee6d040719ae09110e5cdf24d5386abe5d1b776 Mon Sep 17 00:00:00 2001 From: Hans Verkuil <hans.verkuil(a)cisco.com> Date: Wed, 24 Jan 2018 08:37:04 -0500 Subject: media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF From: Hans Verkuil <hans.verkuil(a)cisco.com> commit 3ee6d040719ae09110e5cdf24d5386abe5d1b776 upstream. The result of the VIDIOC_PREPARE_BUF ioctl was never copied back to userspace since it was missing in the switch. Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # for v4.15 and up Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c @@ -996,6 +996,7 @@ static long do_video_ioctl(struct file * err = put_v4l2_create32(&karg.v2crt, up); break; + case VIDIOC_PREPARE_BUF: case VIDIOC_QUERYBUF: case VIDIOC_QBUF: case VIDIOC_DQBUF: Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are queue-3.18/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch queue-3.18/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch queue-3.18/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch queue-3.18/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch queue-3.18/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch queue-3.18/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch queue-3.18/media-v4l2-ctrls-fix-sparse-warning.patch queue-3.18/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch queue-3.18/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch queue-3.18/media-media-v4l2-ctrls-volatiles-should-not-generate-ch_value.patch queue-3.18/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch queue-3.18/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch queue-3.18/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch queue-3.18/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch queue-3.18/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch queue-3.18/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch

7 years, 5 months

1
0
0 0

[PATCH 00/15] mpt3sas: Enhancements and Defect fixes.

by Chaitra P B

Chaitra P B (15): mpt3sas: Fixed warnings. mpt3sas: Pre-allocate RDPQ Array at driver boot time. mpt3sas: Add sanity checks for scsi tracker before accessing it. mpt3sas: Lockless access for chain buffers. mpt3sas: Optimize I/O memory consumption in driver. mpt3sas: Enhanced handling of Sense Buffer. mpt3sas: Added support for SAS Device Discovery Error Event. mpt3sas: Increase event log buffer to support 24 port HBA's. mpt3sas: Allow processing of events during driver unload. mpt3sas: Cache enclosure pages during enclosure add. mpt3sas: Report Firmware Package Version from HBA Driver. mpt3sas: Update MPI Headers mpt3sas: For NVME device, issue a protocol level reset instead of hot reset and use TM timeout value exposed in PCIe Device Page 2. mpt3sas: fix possible memory leak. mpt3sas: Update driver version "25.100.00.00" drivers/scsi/mpt3sas/mpi/mpi2.h | 9 +- drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 30 +- drivers/scsi/mpt3sas/mpi/mpi2_init.h | 2 +- drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 7 +- drivers/scsi/mpt3sas/mpt3sas_base.c | 484 ++++++++++++++++++++++------- drivers/scsi/mpt3sas/mpt3sas_base.h | 62 +++- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 38 ++- drivers/scsi/mpt3sas/mpt3sas_ctl.h | 2 +- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 503 +++++++++++++++++++++---------- drivers/scsi/mpt3sas/mpt3sas_warpdrive.c | 3 +- 10 files changed, 840 insertions(+), 300 deletions(-) -- 1.8.3.1

7 years, 5 months

6
24
0 0

[git:media_tree/fixes] media: vsp1: Fix BRx conditional path in WPF

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: vsp1: Fix BRx conditional path in WPF Author: Kieran Bingham <kieran.bingham(a)ideasonboard.com> Date: Mon Mar 26 09:29:17 2018 -0400 When a BRx is provided by a pipeline, the WPF must determine the master layer. Currently the condition to check this identifies pipe->bru || pipe->num_inputs > 1. The code then moves on to dereference pipe->bru, thus the check fails static analysers on the possibility that pipe->num_inputs could be greater than 1 without pipe->bru being set. The reality is that the pipeline must have a BRx to support more than one input, thus this could never cause a fault - however it also identifies that the num_inputs > 1 check is redundant. Remove the redundant check - and always configure the master layer appropriately when we have a BRx configured in our pipeline. Fixes: 6134148f6098 ("v4l: vsp1: Add support for the BRS entity") Cc: stable(a)vger.kernel.org Suggested-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> drivers/media/platform/vsp1/vsp1_wpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c b/drivers/media/platform/vsp1/vsp1_wpf.c index f7f3b4b2c2de..8bd6b2f1af15 100644 --- a/drivers/media/platform/vsp1/vsp1_wpf.c +++ b/drivers/media/platform/vsp1/vsp1_wpf.c @@ -452,7 +452,7 @@ static void wpf_configure(struct vsp1_entity *entity, : VI6_WPF_SRCRPF_RPF_ACT_SUB(input->entity.index); } - if (pipe->bru || pipe->num_inputs > 1) + if (pipe->bru) srcrpf |= pipe->bru->type == VSP1_ENTITY_BRU ? VI6_WPF_SRCRPF_VIRACT_MST : VI6_WPF_SRCRPF_VIRACT2_MST;

7 years, 5 months

1
0
0 0

[RESEND] drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value

by Chris Wilson

From: Xidong Wang <wangxidong_97(a)163.com> Along the eb_lookup_vmas() error path, the return value from kmem_cache_alloc() was freed using kfree(). Fix it to use the proper kmem_cache_free() instead. Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by: Xidong Wang <wangxidong_97(a)163.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.14+ Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8c170db8495d..0414228cd2b5 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -728,7 +728,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) err = radix_tree_insert(handles_vma, handle, vma); if (unlikely(err)) { - kfree(lut); + kmem_cache_free(eb->i915->luts, lut); goto err_obj; } -- 2.16.3

7 years, 5 months

1
0
0 0

Patch "bitmap: fix memset optimization on big-endian systems" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bitmap: fix memset optimization on big-endian systems to the 4.16-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: bitmap-fix-memset-optimization-on-big-endian-systems.patch and it can be found in the queue-4.16 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 21035965f60b0502fc6537b232839389bb4ce664 Mon Sep 17 00:00:00 2001 From: Omar Sandoval <osandov(a)fb.com> Date: Mon, 2 Apr 2018 15:58:31 -0700 Subject: bitmap: fix memset optimization on big-endian systems From: Omar Sandoval <osandov(a)fb.com> commit 21035965f60b0502fc6537b232839389bb4ce664 upstream. Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible") introduced an optimization to bitmap_{set,clear}() which uses memset() when the start and length are constants aligned to a byte. This is wrong on big-endian systems; our bitmaps are arrays of unsigned long, so bit n is not at byte n / 8 in memory. This was caught by the Btrfs selftests, but the bitmap selftests also fail when run on a big-endian machine. We can still use memset if the start and length are aligned to an unsigned long, so do that on big-endian. The same problem applies to the memcmp in bitmap_equal(), so fix it there, too. Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible") Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations") Cc: stable(a)kernel.org Reported-by: "Erhard F." <erhard_f(a)mailbox.org> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/bitmap.h | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -302,12 +302,20 @@ static inline void bitmap_complement(uns __bitmap_complement(dst, src, nbits); } +#ifdef __LITTLE_ENDIAN +#define BITMAP_MEM_ALIGNMENT 8 +#else +#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long)) +#endif +#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1) + static inline int bitmap_equal(const unsigned long *src1, const unsigned long *src2, unsigned int nbits) { if (small_const_nbits(nbits)) return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits)); - if (__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + if (__builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) return !memcmp(src1, src2, nbits / 8); return __bitmap_equal(src1, src2, nbits); } @@ -358,8 +366,10 @@ static __always_inline void bitmap_set(u { if (__builtin_constant_p(nbits) && nbits == 1) __set_bit(start, map); - else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) && - __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + else if (__builtin_constant_p(start & BITMAP_MEM_MASK) && + IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) && + __builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) memset((char *)map + start / 8, 0xff, nbits / 8); else __bitmap_set(map, start, nbits); @@ -370,8 +380,10 @@ static __always_inline void bitmap_clear { if (__builtin_constant_p(nbits) && nbits == 1) __clear_bit(start, map); - else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) && - __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + else if (__builtin_constant_p(start & BITMAP_MEM_MASK) && + IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) && + __builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) memset((char *)map + start / 8, 0, nbits / 8); else __bitmap_clear(map, start, nbits); Patches currently in stable-queue which might be from osandov(a)fb.com are queue-4.16/bitmap-fix-memset-optimization-on-big-endian-systems.patch

7 years, 5 months

1
0
0 0

Patch "bitmap: fix memset optimization on big-endian systems" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bitmap: fix memset optimization on big-endian systems to the 4.15-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: bitmap-fix-memset-optimization-on-big-endian-systems.patch and it can be found in the queue-4.15 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 21035965f60b0502fc6537b232839389bb4ce664 Mon Sep 17 00:00:00 2001 From: Omar Sandoval <osandov(a)fb.com> Date: Mon, 2 Apr 2018 15:58:31 -0700 Subject: bitmap: fix memset optimization on big-endian systems From: Omar Sandoval <osandov(a)fb.com> commit 21035965f60b0502fc6537b232839389bb4ce664 upstream. Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible") introduced an optimization to bitmap_{set,clear}() which uses memset() when the start and length are constants aligned to a byte. This is wrong on big-endian systems; our bitmaps are arrays of unsigned long, so bit n is not at byte n / 8 in memory. This was caught by the Btrfs selftests, but the bitmap selftests also fail when run on a big-endian machine. We can still use memset if the start and length are aligned to an unsigned long, so do that on big-endian. The same problem applies to the memcmp in bitmap_equal(), so fix it there, too. Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible") Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations") Cc: stable(a)kernel.org Reported-by: "Erhard F." <erhard_f(a)mailbox.org> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/bitmap.h | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -271,12 +271,20 @@ static inline void bitmap_complement(uns __bitmap_complement(dst, src, nbits); } +#ifdef __LITTLE_ENDIAN +#define BITMAP_MEM_ALIGNMENT 8 +#else +#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long)) +#endif +#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1) + static inline int bitmap_equal(const unsigned long *src1, const unsigned long *src2, unsigned int nbits) { if (small_const_nbits(nbits)) return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits)); - if (__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + if (__builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) return !memcmp(src1, src2, nbits / 8); return __bitmap_equal(src1, src2, nbits); } @@ -327,8 +335,10 @@ static __always_inline void bitmap_set(u { if (__builtin_constant_p(nbits) && nbits == 1) __set_bit(start, map); - else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) && - __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + else if (__builtin_constant_p(start & BITMAP_MEM_MASK) && + IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) && + __builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) memset((char *)map + start / 8, 0xff, nbits / 8); else __bitmap_set(map, start, nbits); @@ -339,8 +349,10 @@ static __always_inline void bitmap_clear { if (__builtin_constant_p(nbits) && nbits == 1) __clear_bit(start, map); - else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) && - __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + else if (__builtin_constant_p(start & BITMAP_MEM_MASK) && + IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) && + __builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) memset((char *)map + start / 8, 0, nbits / 8); else __bitmap_clear(map, start, nbits); Patches currently in stable-queue which might be from osandov(a)fb.com are queue-4.15/bitmap-fix-memset-optimization-on-big-endian-systems.patch

7 years, 5 months

1
0
0 0

Patch "bitmap: fix memset optimization on big-endian systems" 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 bitmap: fix memset optimization on big-endian systems 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: bitmap-fix-memset-optimization-on-big-endian-systems.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 21035965f60b0502fc6537b232839389bb4ce664 Mon Sep 17 00:00:00 2001 From: Omar Sandoval <osandov(a)fb.com> Date: Mon, 2 Apr 2018 15:58:31 -0700 Subject: bitmap: fix memset optimization on big-endian systems From: Omar Sandoval <osandov(a)fb.com> commit 21035965f60b0502fc6537b232839389bb4ce664 upstream. Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible") introduced an optimization to bitmap_{set,clear}() which uses memset() when the start and length are constants aligned to a byte. This is wrong on big-endian systems; our bitmaps are arrays of unsigned long, so bit n is not at byte n / 8 in memory. This was caught by the Btrfs selftests, but the bitmap selftests also fail when run on a big-endian machine. We can still use memset if the start and length are aligned to an unsigned long, so do that on big-endian. The same problem applies to the memcmp in bitmap_equal(), so fix it there, too. Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible") Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations") Cc: stable(a)kernel.org Reported-by: "Erhard F." <erhard_f(a)mailbox.org> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/bitmap.h | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -262,12 +262,20 @@ static inline void bitmap_complement(uns __bitmap_complement(dst, src, nbits); } +#ifdef __LITTLE_ENDIAN +#define BITMAP_MEM_ALIGNMENT 8 +#else +#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long)) +#endif +#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1) + static inline int bitmap_equal(const unsigned long *src1, const unsigned long *src2, unsigned int nbits) { if (small_const_nbits(nbits)) return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits)); - if (__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + if (__builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) return !memcmp(src1, src2, nbits / 8); return __bitmap_equal(src1, src2, nbits); } @@ -318,8 +326,10 @@ static __always_inline void bitmap_set(u { if (__builtin_constant_p(nbits) && nbits == 1) __set_bit(start, map); - else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) && - __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + else if (__builtin_constant_p(start & BITMAP_MEM_MASK) && + IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) && + __builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) memset((char *)map + start / 8, 0xff, nbits / 8); else __bitmap_set(map, start, nbits); @@ -330,8 +340,10 @@ static __always_inline void bitmap_clear { if (__builtin_constant_p(nbits) && nbits == 1) __clear_bit(start, map); - else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) && - __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8)) + else if (__builtin_constant_p(start & BITMAP_MEM_MASK) && + IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) && + __builtin_constant_p(nbits & BITMAP_MEM_MASK) && + IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT)) memset((char *)map + start / 8, 0, nbits / 8); else __bitmap_clear(map, start, nbits); Patches currently in stable-queue which might be from osandov(a)fb.com are queue-4.14/bitmap-fix-memset-optimization-on-big-endian-systems.patch

7 years, 5 months

1
0
0 0

[PATCH] scsi: Fix failed request error code

by Damien Le Moal

With the introduction of commit e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking additional sense information will have a return code set to BLK_STS_OK. This results in the request issuer to see successful request execution despite the failure. An example of such case is an unaligned write on a host managed ZAC disk connected to a SAS HBA with a malfunctioning SAT. The unaligned write command gets aborted but has no additional sense information. sd 10:0:0:0: [sde] tag#3905 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 10:0:0:0: [sde] tag#3905 Sense Key : Aborted Command [current] sd 10:0:0:0: [sde] tag#3905 Add. Sense: No additional sense information sd 10:0:0:0: [sde] tag#3905 CDB: Write(16) 8a 00 00 00 00 00 02 0c 00 01 00 00 00 01 00 00 print_req_error: I/O error, dev sde, sector 274726920 In scsi_io_completion(), sense key handling to not change the request error code and success being reported to the issuer. Fix this by making sure that the error code always indicates an error if scsi_io_completion() decide that the action to be taken for a failed command is to not retry it and terminate it immediately (ACTION_FAIL) . Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Cc: Hannes Reinecke <hare(a)suse.com> Cc: <stable(a)vger.kernel.org> --- drivers/scsi/scsi_lib.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index c84f931388f2..87579bfcc186 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1002,6 +1002,15 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes) scsi_print_command(cmd); } } + /* + * The command failed and should not be retried. If the host + * byte is DID_OK, then __scsi_error_from_host_byte() returned + * BLK_STS_OK and error indicates a success. Make sure to not + * use that as the completion code and always return an + * I/O error. + */ + if (error == BLK_STS_OK) + error = BLK_STS_IOERR; if (!scsi_end_request(req, error, blk_rq_err_bytes(req), 0)) return; /*FALLTHRU*/ -- 2.14.3

7 years, 5 months

3
5
0 0

[PATCH RT 6/7] Revert "memcontrol: Prevent scheduling while atomic in cgroup code"

by Daniel Wagner

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> The commit "memcontrol: Prevent scheduling while atomic in cgroup code" fixed this issue: refill_stock() get_cpu_var() drain_stock() res_counter_uncharge() res_counter_uncharge_until() spin_lock() <== boom But commit 3e32cb2e0a12b ("mm: memcontrol: lockless page counters") replaced the calls to res_counter_uncharge() in drain_stock() to the lockless function page_counter_uncharge(). There is no more spin lock there and no more reason to have that local lock. Cc: <stable(a)vger.kernel.org> Reported-by: Haiyang HY1 Tan <tanhy1(a)lenovo.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> [bigeasy: That upstream commit appeared in v3.19 and the patch in question in v3.18.7-rt2 and v3.18 seems still to be maintained. So I guess that v3.18 would need the locallocks that we are about to remove here. I am not sure if any earlier versions have the patch backported. The stable tag here is because Haiyang reported (and debugged) a crash in 4.4-RT with this patch applied (which has get_cpu_light() instead the locallocks it gained in v4.9-RT). https://lkml.kernel.org/r/05AA4EC5C6EC1D48BE2CDCFF3AE0B8A637F78A15@CNMAILEX… ] Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> --- mm/memcontrol.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 493b4986d5dc..56f67a15937b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1925,17 +1925,14 @@ static void drain_local_stock(struct work_struct *dummy) */ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages) { - struct memcg_stock_pcp *stock; - int cpu = get_cpu_light(); - - stock = &per_cpu(memcg_stock, cpu); + struct memcg_stock_pcp *stock = &get_cpu_var(memcg_stock); if (stock->cached != memcg) { /* reset if necessary */ drain_stock(stock); stock->cached = memcg; } stock->nr_pages += nr_pages; - put_cpu_light(); + put_cpu_var(memcg_stock); } /* -- 2.14.3

7 years, 5 months

1
0
0 0

[PATCH RT 2/7] timer: Invoke timer_start_debug() where it makes sense

by Daniel Wagner

From: Thomas Gleixner <tglx(a)linutronix.de> The timer start debug function is called before the proper timer base is set. As a consequence the trace data contains the stale CPU and flags values. Call the debug function after setting the new base and flags. Fixes: 500462a9de65 ("timers: Switch to a non-cascading wheel") Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: rt(a)linutronix.de Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> --- kernel/time/timer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index a8246d79cb5a..6b322aea1c46 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -838,8 +838,6 @@ __mod_timer(struct timer_list *timer, unsigned long expires, if (!ret && pending_only) goto out_unlock; - debug_activate(timer, expires); - new_base = get_target_base(base, pinned); if (base != new_base) { @@ -854,6 +852,8 @@ __mod_timer(struct timer_list *timer, unsigned long expires, base = switch_timer_base(timer, base, new_base); } + debug_activate(timer, expires); + timer->expires = expires; internal_add_timer(base, timer); -- 2.14.3

7 years, 5 months

1
0
0 0

[PATCH RESEND 2/2] btrfs: Ensure btrfs_trim_fs can trim the whole fs

by Qu Wenruo

[BUG] fstrim on some btrfs only trims the unallocated space, not trimming any space in existing block groups. [CAUSE] Before fstrim_range passed to btrfs_trim_fs(), it get truncated to range [0, super->total_bytes). So later btrfs_trim_fs() will only be able to trim block groups in range [0, super->total_bytes). While for btrfs, any bytenr aligned to sector size is valid, since btrfs use its logical address space, there is nothing limiting the location where we put block groups. For btrfs with routine balance, it's quite easy to relocate all block groups and bytenr of block groups will start beyond super->total_bytes. In that case, btrfs will not trim existing block groups. [FIX] Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs() can get the unmodified range, which is normally set to [0, U64_MAX]. Reported-by: Chris Murphy <lists(a)colorremedies.com> Fixes: f4c697e6406d ("btrfs: return EINVAL if start > total_bytes in fitrim ioctl") Cc: <stable(a)vger.kernel.org> # v4.0+ Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/extent-tree.c | 10 +--------- fs/btrfs/ioctl.c | 11 +++++++---- 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index f3b088665b7a..647691fc16e8 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -10994,19 +10994,11 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range) u64 start; u64 end; u64 trimmed = 0; - u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy); int bg_ret = 0; int dev_ret = 0; int ret = 0; - /* - * try to trim all FS space, our block group may start from non-zero. - */ - if (range->len == total_bytes) - cache = btrfs_lookup_first_block_group(fs_info, range->start); - else - cache = btrfs_lookup_block_group(fs_info, range->start); - + cache = btrfs_lookup_first_block_group(fs_info, range->start); for (; cache; cache = next_block_group(fs_info, cache)) { if (cache->key.objectid >= (range->start + range->len)) { btrfs_put_block_group(cache); diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index ac85e07f567b..761fba8d8f75 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -364,7 +364,6 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, void __user *arg) struct fstrim_range range; u64 minlen = ULLONG_MAX; u64 num_devices = 0; - u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy); int ret; if (!capable(CAP_SYS_ADMIN)) @@ -388,11 +387,15 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, void __user *arg) return -EOPNOTSUPP; if (copy_from_user(&range, arg, sizeof(range))) return -EFAULT; - if (range.start > total_bytes || - range.len < fs_info->sb->s_blocksize) + + /* + * NOTE: Don't truncate the range using super->total_bytes. + * Bytenr of btrfs block group is in btrfs logical address space, + * which can be any sector size aligned bytenr in [0, U64_MAX]. + */ + if (range.len < fs_info->sb->s_blocksize) return -EINVAL; - range.len = min(range.len, total_bytes - range.start); range.minlen = max(range.minlen, minlen); ret = btrfs_trim_fs(fs_info, &range); if (ret < 0) -- 2.16.3

7 years, 5 months

1
0
0 0

Please add 21035965f60b ("bitmap: fix memset optimization on big-endian systems") to the stable tree

by Omar Sandoval

Just wanted to make sure this doesn't get missed because I misspelled the stable email address in the patch. It applies to v4.13+.

7 years, 5 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror