summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-18ksmbd: set unique value to volume serial field in FS_VOLUME_INFORMATIONNamjae Jeon3-1/+10
commit 5d2f0b1083eb158bdff01dd557e2c25046c0a7d2 upstream. Steve French reported ksmbd set fixed value to volume serial field in FS_VOLUME_INFORMATION. Volume serial value needs to be set to a unique value for client fscache. This patch set crc value that is generated with share name, path name and netbios name to volume serial. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org # v5.15 Reported-by: Steve French <smfrench@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18serial: 8250: fix racy uartclk updateJohan Hovold1-4/+17
commit 211cde4f5817dc88ef7f8f2fa286e57fbf14c8ee upstream. Commit 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") added a hack to support SoCs where the UART reference clock can change behind the back of the driver but failed to add the proper locking. First, make sure to take a reference to the tty struct to avoid dereferencing a NULL pointer if the clock change races with a hangup. Second, the termios semaphore must be held during the update to prevent a racing termios change. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Fixes: c8dff3aa8241 ("serial: 8250: Skip uninitialized TTY port baud rate update") Cc: stable@vger.kernel.org # 5.9 Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> Tested-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211015111422.1027-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18USB: serial: keyspan: fix memleak on probe errorsWang Hai1-8/+7
commit 910c996335c37552ee30fcb837375b808bb4f33b upstream. I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888258228440 (size 64): comm "kworker/7:2", pid 2005, jiffies 4294989509 (age 824.540s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490 [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470 [<ffffffffa02ac0e4>] keyspan_port_probe+0xa4/0x5d0 [keyspan] [<ffffffffa0294c07>] usb_serial_device_probe+0x97/0x1d0 [usbserial] [<ffffffff82b50ca7>] really_probe+0x167/0x460 [<ffffffff82b51099>] __driver_probe_device+0xf9/0x180 [<ffffffff82b51173>] driver_probe_device+0x53/0x130 [<ffffffff82b516f5>] __device_attach_driver+0x105/0x130 [<ffffffff82b4cfe9>] bus_for_each_drv+0x129/0x190 [<ffffffff82b50a69>] __device_attach+0x1c9/0x270 [<ffffffff82b518d0>] device_initial_probe+0x20/0x30 [<ffffffff82b4f062>] bus_probe_device+0x142/0x160 [<ffffffff82b4a4e9>] device_add+0x829/0x1300 [<ffffffffa0295fda>] usb_serial_probe.cold+0xc9b/0x14ac [usbserial] [<ffffffffa02266aa>] usb_probe_interface+0x1aa/0x3c0 [usbcore] [<ffffffff82b50ca7>] really_probe+0x167/0x460 If keyspan_port_probe() fails to allocate memory for an out_buffer[i] or in_buffer[i], the previously allocated memory for out_buffer or in_buffer needs to be freed on the error handling path, otherwise a memory leak will result. Fixes: bad41a5bf177 ("USB: keyspan: fix port DMA-buffer allocations") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20211015085543.1203011-1-wanghai38@huawei.com Cc: stable@vger.kernel.org # 3.12 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18Documentation:devicetree:bindings:iio:dac: Fix valMihail Chindris1-1/+1
commit 8fc4f038fa832ec3543907fdcbe1334e1b0a8950 upstream. A correct value for output-range-microvolts is -5 to 5 Volts not -5 to 5 milivolts Fixes: e904cc899293f ("dt-bindings: iio: dac: AD5766 yaml documentation") Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211007080035.2531-6-mihail.chindris@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: ad5770r: make devicetree property reading consistentNuno Sá1-1/+1
commit 26df977a909f818b7d346b3990735513e7e0bf93 upstream. The bindings file for this driver is defining the property as 'reg' but the driver was reading it with the 'num' name. The bindings actually had the 'num' property when added in commit ea52c21268e6 ("dt-bindings: iio: dac: Add docs for AD5770R DAC") and then changed it to 'reg' in commit 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors"). However, both these commits landed in v5.7 so the assumption is that either 'num' is not being used or if it is, the validations were not done. Anyways, if someone comes back yelling about this, we might just support both of the properties in the future. Not ideal, but that's life... Fixes: 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210818080525.62790-1-nuno.sa@analog.com Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: dac: ad5446: Fix ad5622_write() return valuePekka Korpinen1-1/+8
commit 558df982d4ead9cac628153d0d7b60feae05ddc8 upstream. On success i2c_master_send() returns the number of bytes written. The call from iio_write_channel_info(), however, expects the return value to be zero on success. This bug causes incorrect consumption of the sysfs buffer in iio_write_channel_info(). When writing more than two characters to out_voltage0_raw, the ad5446 write handler is called multiple times causing unexpected behavior. Fixes: 3ec36a2cf0d5 ("iio:ad5446: Add support for I2C based DACs") Signed-off-by: Pekka Korpinen <pekka.korpinen@iki.fi> Link: https://lore.kernel.org/r/20210929185755.2384-1-pekka.korpinen@iki.fi Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18drivers: iio: dac: ad5766: Fix dt property nameMihail Chindris1-3/+3
commit d9de0fbdeb0103a204055efb69cb5cc8f5f12a6a upstream. In the documentation the name for the property is output-range-microvolts which is a standard name, therefore this name must be used. Fixes: fd9373e41b9ba ("iio: dac: ad5766: add driver support for AD5766") Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211007080035.2531-5-mihail.chindris@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups()Yang Yingliang1-2/+2
commit 604faf9a2ecd1addcc0c10a47e5aaef3c4d4fd6b upstream. If the second iio_device_register_sysfs_group() fails, 'legacy_buffer_group.attrs' need be freed too or it will cause memory leak: unreferenced object 0xffff888003618280 (size 64): comm "xrun", pid 357, jiffies 4294907259 (age 22.296s) hex dump (first 32 bytes): 80 f6 8c 03 80 88 ff ff 80 fb 8c 03 80 88 ff ff ................ 00 f9 8c 03 80 88 ff ff 80 fc 8c 03 80 88 ff ff ................ backtrace: [<00000000076bfd43>] __kmalloc+0x1a3/0x2f0 [<00000000c32e4886>] iio_buffers_alloc_sysfs_and_mask+0xc31/0x1290 [industrialio] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013144242.1685060-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask()Yang Yingliang1-3/+2
commit 9a2ff8009e53296e47de72d5af0bc31cd53274ff upstream. When iio_buffer_wrap_attr() returns NULL or buffer->buffer_group.name alloc fails, the 'attr' which is allocated in __iio_buffer_alloc_sysfs_and_mask() is not freed, and cause memory leak. unreferenced object 0xffff888014882a00 (size 64): comm "i2c-adjd_s311-8", pid 424, jiffies 4294907737 (age 44.396s) hex dump (first 32 bytes): 00 0f 8a 15 80 88 ff ff 00 0e 8a 15 80 88 ff ff ................ 80 04 8a 15 80 88 ff ff 80 05 8a 15 80 88 ff ff ................ backtrace: [<0000000021752e67>] __kmalloc+0x1af/0x3c0 [<0000000043e8305c>] iio_buffers_alloc_sysfs_and_mask+0xe73/0x1570 [industrialio] [<00000000b7aa5a17>] __iio_device_register+0x483/0x1a30 [industrialio] [<000000003fa0fb2f>] __devm_iio_device_register+0x23/0x90 [industrialio] [<000000003ab040cf>] adjd_s311_probe+0x19c/0x200 [adjd_s311] [<0000000080458969>] i2c_device_probe+0xa31/0xbe0 [<00000000e20678ad>] really_probe+0x299/0xc30 [<000000006bea9b27>] __driver_probe_device+0x357/0x500 [<00000000e1df10d4>] driver_probe_device+0x4e/0x140 [<0000000003661beb>] __device_attach_driver+0x257/0x340 [<000000005bb4aa26>] bus_for_each_drv+0x166/0x1e0 [<00000000272c5236>] __device_attach+0x272/0x420 [<00000000d52a96ae>] bus_probe_device+0x1eb/0x2a0 [<00000000129f7737>] device_add+0xbf0/0x1f90 [<000000005eed4e52>] i2c_new_client_device+0x622/0xb20 [<00000000b85a9c43>] new_device_store+0x1fa/0x420 This patch fix to free it before the error return. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013094343.315275-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: Fix memory leak in iio_buffers_alloc_sysfs_and_mask()Yang Yingliang1-5/+7
commit 486a25084155bf633768c26f022201c051d6fd95 upstream. When 'iio_dev_opaque->buffer_ioctl_handler' alloc fails in iio_buffers_alloc_sysfs_and_mask(), the 'attrs' allocated in iio_buffer_register_legacy_sysfs_groups() will be leaked: unreferenced object 0xffff888108568d00 (size 128): comm "88", pid 2014, jiffies 4294963294 (age 26.920s) hex dump (first 32 bytes): 80 3e da 02 80 88 ff ff 00 3a da 02 80 88 ff ff .>.......:...... 00 35 da 02 80 88 ff ff 00 38 da 02 80 88 ff ff .5.......8...... backtrace: [<0000000095a9e51e>] __kmalloc+0x1a3/0x2f0 [<00000000faa3735e>] iio_buffers_alloc_sysfs_and_mask+0xfa3/0x1480 [industrialio] [<00000000a46384dc>] __iio_device_register+0x52e/0x1b40 [industrialio] [<00000000210af05e>] __devm_iio_device_register+0x22/0x80 [industrialio] [<00000000730d7b41>] adjd_s311_probe+0x195/0x200 [adjd_s311] [<00000000c0f70eb9>] i2c_device_probe+0xa07/0xbb0 The iio_buffer_register_legacy_sysfs_groups() is called in __iio_buffer_alloc_sysfs_and_mask(), so move the iio_buffer_unregister_legacy_sysfs_groups() into __iio_buffer_free_sysfs_and_mask(), then the memory will be freed. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211018063718.1971240-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: check return value of kstrdup_const()Yang Yingliang1-0/+5
commit 2c0ad3f0cc04dec489552a21b80cd6d708bea96d upstream. Check return value of kstrdup_const() in iio_buffer_wrap_attr(), or it will cause null-ptr-deref in kernfs_name_hash() when calling device_add() as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: kernfs_name_hash+0x22/0x110 kernfs_find_ns+0x11d/0x390 kernfs_remove_by_name_ns+0x3b/0xb0 remove_files.isra.1+0x7b/0x190 internal_create_group+0x7f1/0xbb0 internal_create_groups+0xa3/0x150 device_add+0x8f0/0x2020 cdev_device_add+0xc3/0x160 __iio_device_register+0x1427/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] adjd_s311_probe+0x195/0x200 [adjd_s311] i2c_device_probe+0xa07/0xbb0 Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013040438.1689277-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18coresight: trbe: Defer the probe on offline CPUsSuzuki K Poulose1-1/+7
commit a08025b3fe56185290a1ea476581f03ca733f967 upstream. If a CPU is offline during the driver init, we could end up causing a kernel crash trying to register the coresight device for the TRBE instance. The trbe_cpudata for the TRBE instance is initialized only when it is probed. Otherwise, we could end up dereferencing a NULL cpudata->drvdata. e.g: [ 0.149999] coresight ete0: CPU0: ete v1.1 initialized [ 0.149999] coresight-etm4x ete_1: ETM arch init failed [ 0.149999] coresight-etm4x: probe of ete_1 failed with error -22 [ 0.150085] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 [ 0.150085] Mem abort info: [ 0.150085] ESR = 0x96000005 [ 0.150085] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.150085] SET = 0, FnV = 0 [ 0.150085] EA = 0, S1PTW = 0 [ 0.150085] Data abort info: [ 0.150085] ISV = 0, ISS = 0x00000005 [ 0.150085] CM = 0, WnR = 0 [ 0.150085] [0000000000000050] user address but active_mm is swapper [ 0.150085] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 0.150085] Modules linked in: [ 0.150085] Hardware name: FVP Base RevC (DT) [ 0.150085] pstate: 00800009 (nzcv daif -PAN +UAO -TCO BTYPE=--) [ 0.150155] pc : arm_trbe_register_coresight_cpu+0x74/0x144 [ 0.150155] lr : arm_trbe_register_coresight_cpu+0x48/0x144 ... [ 0.150237] Call trace: [ 0.150237] arm_trbe_register_coresight_cpu+0x74/0x144 [ 0.150237] arm_trbe_device_probe+0x1c0/0x2d8 [ 0.150259] platform_drv_probe+0x94/0xbc [ 0.150259] really_probe+0x1bc/0x4a8 [ 0.150266] driver_probe_device+0x7c/0xb8 [ 0.150266] device_driver_attach+0x6c/0xac [ 0.150266] __driver_attach+0xc4/0x148 [ 0.150266] bus_for_each_dev+0x7c/0xc8 [ 0.150266] driver_attach+0x24/0x30 [ 0.150266] bus_add_driver+0x100/0x1e0 [ 0.150266] driver_register+0x78/0x110 [ 0.150266] __platform_driver_register+0x44/0x50 [ 0.150266] arm_trbe_init+0x28/0x84 [ 0.150266] do_one_initcall+0x94/0x2bc [ 0.150266] do_initcall_level+0xa4/0x158 [ 0.150266] do_initcalls+0x54/0x94 [ 0.150319] do_basic_setup+0x24/0x30 [ 0.150319] kernel_init_freeable+0xe8/0x14c [ 0.150319] kernel_init+0x14/0x18c [ 0.150319] ret_from_fork+0x10/0x30 [ 0.150319] Code: f94012c8 b0004ce2 9134a442 52819801 (f9402917) [ 0.150319] ---[ end trace d23e0cfe5098535e ]--- [ 0.150346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix this by skipping the step, if we are unable to probe the CPU. Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Reported-by: Bransilav Rankov <branislav.rankov@arm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Leo Yan <leo.yan@linaro.org> Cc: stable <stable@vger.kernel.org> Tested-by: Branislav Rankov <branislav.rankov@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20211014142238.2221248-1-suzuki.poulose@arm.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18coresight: trbe: Fix incorrect access of the sink specific dataSuzuki K Poulose1-1/+1
commit bb5293e334af51b19b62d8bef1852ea13e935e9b upstream. The TRBE driver wrongly treats the aux private data as the TRBE driver specific buffer for a given perf handle, while it is the ETM PMU's event specific data. Fix this by correcting the instance to use appropriate helper. Cc: stable <stable@vger.kernel.org> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20210921134121.2423546-2-suzuki.poulose@arm.com [Fixed 13 character SHA down to 12] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18coresight: cti: Correct the parameter for pm_runtime_putTao Zhang1-1/+1
commit 692c9a499b286ea478f41b23a91fe3873b9e1326 upstream. The input parameter of the function pm_runtime_put should be the same in the function cti_enable_hw and cti_disable_hw. The correct parameter to use here should be dev->parent. Signed-off-by: Tao Zhang <quic_taozha@quicinc.com> Reviewed-by: Leo Yan <leo.yan@linaro.org> Fixes: 835d722ba10a ("coresight: cti: Initial CoreSight CTI Driver") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1629365377-5937-1-git-send-email-quic_taozha@quicinc.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18pinctrl: core: fix possible memory leak in pinctrl_enable()Yang Yingliang1-0/+2
commit c7892ae13e461ed20154321eb792e07ebe38f5b3 upstream. I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888020a7a680 (size 64): comm "i2c-mcp23018-41", pid 23090, jiffies 4295160544 (age 8.680s) hex dump (first 32 bytes): 00 48 d3 1e 80 88 ff ff 00 1a 56 c1 ff ff ff ff .H........V..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000083c79b35>] kmem_cache_alloc_trace+0x16d/0x360 [<0000000051803c95>] pinctrl_init_controller+0x6ed/0xb70 [<0000000064346707>] pinctrl_register+0x27/0x80 [<0000000029b0e186>] devm_pinctrl_register+0x5b/0xe0 [<00000000391f5a3e>] mcp23s08_probe_one+0x968/0x118a [pinctrl_mcp23s08] [<000000006112c039>] mcp230xx_probe+0x266/0x560 [pinctrl_mcp23s08_i2c] If pinctrl_claim_hogs() fails, the 'pindesc' allocated in pinctrl_register_one_pin() need be freed. Cc: stable@vger.kernel.org Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 950b0d91dc10 ("pinctrl: core: Fix regression caused by delayed work for hogs") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211022014323.1156924-1-yangyingliang@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18mfd: simple-mfd-i2c: Select MFD_CORE to fix build errorRobert Marko1-0/+1
commit 5dc6dafe62099ade0e7232ce9db4013b7673d860 upstream. MFD_SIMPLE_MFD_I2C should select the MFD_CORE to a prevent build error: aarch64-linux-ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe': drivers/mfd/simple-mfd-i2c.c:55: undefined reference to `devm_mfd_add_devices' Cc: <stable@vger.kernel.org> Fixes: c753ea31781aa ("mfd: simple-mfd-i2c: Add support for registering devices via MFD cells") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211102100420.112215-1-robert.marko@sartura.hr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18cifs: set a minimum of 120s for next dns resolutionPaulo Alcantara2-2/+3
commit 4ac0536f8874a903a72bddc57eb88db774261e3a upstream. With commit 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution") and after triggering the first reconnect, the next async dns resolution of tcp server's hostname would be scheduled based on dns_resolver's key expiry default, which happens to default to 5s on most systems that use key.dns_resolver for upcall. As per key.dns_resolver.conf(5): default_ttl=<number> The number of seconds to set as the expiration on a cached record. This will be overridden if the program manages to re- trieve TTL information along with the addresses (if, for exam- ple, it accesses the DNS directly). The default is 5 seconds. The value must be in the range 1 to INT_MAX. Make the next async dns resolution no shorter than 120s as we do not want to be upcalling too often. Cc: stable@vger.kernel.org Fixes: 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution") Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18cifs: To match file servers, make sure the server hostname matchesShyam Prasad N3-8/+20
commit 7be3248f313930ff3d3436d4e9ddbe9fccc1f541 upstream. We generally rely on a bunch of factors to differentiate between servers. For example, IP address, port etc. For certain server types (like Azure), it is important to make sure that the server hostname matches too, even if the both hostnames currently resolve to the same IP address. Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Cc: stable@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18quota: correct error number in free_dqentry()Zhang Yi1-0/+1
commit d0e36a62bd4c60c09acc40e06ba4831a4d0bc75b upstream. Fix the error path in free_dqentry(), pass out the error number if the block to free is not correct. Fixes: 1ccd14b9c271 ("quota: Split off quota tree handling into a separate file") Link: https://lore.kernel.org/r/20211008093821.1001186-3-yi.zhang@huawei.com Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Cc: stable@kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18quota: check block number when reading the block in quota fileZhang Yi1-0/+14
commit 9bf3d20331295b1ecb81f4ed9ef358c51699a050 upstream. The block number in the quota tree on disk should be smaller than the v2_disk_dqinfo.dqi_blocks. If the quota file was corrupted, we may be allocating an 'allocated' block and that would lead to a loop in a tree, which will probably trigger oops later. This patch adds a check for the block number in the quota tree to prevent such potential issue. Link: https://lore.kernel.org/r/20211008093821.1001186-2-yi.zhang@huawei.com Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Cc: stable@kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridgePali Rohár1-0/+9
commit 239edf686c14a9ff926dec2f350289ed7adfefe2 upstream. This register is exported at address offset 0x30. Link: https://lore.kernel.org/r/20211028185659.20329-8-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Set PCI Bridge Class Code to PCI BridgePali Rohár1-0/+20
commit 84e1b4045dc887b78bdc87d92927093dc3a465aa upstream. Aardvark controller has something like config space of a Root Port available at offset 0x0 of internal registers - these registers are used for implementation of the emulated bridge. The default value of Class Code of this bridge corresponds to a RAID Mass storage controller, though. (This is probably intended for when the controller is used as Endpoint.) Change the Class Code to correspond to a PCI Bridge. Add comment explaining this change. Link: https://lore.kernel.org/r/20211028185659.20329-6-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix support for PCI_BRIDGE_CTL_BUS_RESET on emulated bridgePali Rohár1-0/+27
commit bc4fac42e5f8460af09c0a7f2f1915be09e20c71 upstream. Aardvark supports PCIe Hot Reset via PCIE_CORE_CTRL1_REG. Use it for implementing PCI_BRIDGE_CTL_BUS_RESET bit of PCI_BRIDGE_CONTROL register on emulated bridge. With this, the function pci_reset_secondary_bus() starts working and can reset connected PCIe card. Custom userspace script [1] which uses setpci can trigger PCIe Hot Reset and reset the card manually. [1] https://alexforencich.com/wiki/en/pcie/hot-reset-linux Link: https://lore.kernel.org/r/20211028185659.20329-7-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix support for bus mastering and PCI_COMMAND on emulated bridgePali Rohár1-16/+38
commit 771153fc884f566a89af2d30033b7f3bc6e24e84 upstream. From very vague, ambiguous and incomplete information from Marvell we deduced that the 32-bit Aardvark register at address 0x4 (PCIE_CORE_CMD_STATUS_REG), which is not documented for Root Complex mode in the Functional Specification (only for Endpoint mode), controls two 16-bit PCIe registers: Command Register and Status Registers of PCIe Root Port. This means that bit 2 controls bus mastering and forwarding of memory and I/O requests in the upstream direction. According to PCI specifications bits [0:2] of Command Register, this should be by default disabled on reset. So explicitly disable these bits at early setup of the Aardvark driver. Remove code which unconditionally enables all 3 bits and let kernel code (via pci_set_master() function) to handle bus mastering of Root PCIe Bridge via emulated PCI_COMMAND on emulated bridge. Link: https://lore.kernel.org/r/20211028185659.20329-5-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org # b2a56469d550 ("PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Read all 16-bits from PCIE_MSI_PAYLOAD_REGMarek Behún1-1/+6
commit 95997723b6402cd6c53e0f9e7ac640ec64eaaff8 upstream. The PCIE_MSI_PAYLOAD_REG contains 16-bit MSI number, not only lower 8 bits. Fix reading content of this register and add a comment describing the access to this register. Link: https://lore.kernel.org/r/20211028185659.20329-4-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix return value of MSI domain .alloc() methodMarek Behún1-1/+1
commit e4313be1599d397625c14fb7826996813622decf upstream. MSI domain callback .alloc() (implemented by advk_msi_irq_domain_alloc() function) should return zero on success, since non-zero value indicates failure. When the driver was converted to generic MSI API in commit f21a8b1b6837 ("PCI: aardvark: Move to MSI handling using generic MSI support"), it was converted so that it returns hwirq number. Fix this. Link: https://lore.kernel.org/r/20211028185659.20329-3-kabel@kernel.org Fixes: f21a8b1b6837 ("PCI: aardvark: Move to MSI handling using generic MSI support") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix configuring Reference clockPali Rohár1-1/+8
commit 46ef6090dbf590711cb12680b6eafde5fa21fe87 upstream. Commit 366697018c9a ("PCI: aardvark: Add PHY support") introduced configuration of PCIe Reference clock via PCIE_CORE_REF_CLK_REG register, but did it incorrectly. PCIe Reference clock differential pair is routed from system board to endpoint card, so on CPU side it has output direction. Therefore it is required to enable transmitting and disable receiving. Default configuration according to Armada 3700 Functional Specifications is enabled receiver part and disabled transmitter. We need this change because otherwise PCIe Reference clock is configured to some undefined state when differential pair is used for both transmitting and receiving. Fix this by disabling receiver part. Link: https://lore.kernel.org/r/20211005180952.6812-6-kabel@kernel.org Fixes: 366697018c9a ("PCI: aardvark: Add PHY support") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix reporting Data Link Layer Link ActivePali Rohár1-1/+28
commit 2b650b7ff20eb7ea8ef9031d20fb657286ab90cc upstream. Add support for reporting PCI_EXP_LNKSTA_DLLLA bit in Link Control register on emulated bridge via current LTSSM state. Also correctly indicate DLLLA capability via PCI_EXP_LNKCAP_DLLLARC bit in Link Control Capability register. Link: https://lore.kernel.org/r/20211005180952.6812-14-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Do not unmask unused interruptsPali Rohár1-3/+3
commit 1fb95d7d3c7a926b002fe8a6bd27a1cb428b46dc upstream. There are lot of undocumented interrupt bits. To prevent unwanted spurious interrupts, fix all *_ALL_MASK macros to define all interrupt bits, so that driver can properly mask all interrupts, including those which are undocumented. Link: https://lore.kernel.org/r/20211005180952.6812-8-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Fix checking for link up via LTSSM statePali Rohár1-6/+70
commit 661c399a651c11aaf83c45cbfe0b4a1fb7bc3179 upstream. Current implementation of advk_pcie_link_up() is wrong as it marks also link disabled or hot reset states as link up. Fix it by marking link up only to those states which are defined in PCIe Base specification 3.0, Table 4-14: Link Status Mapped to the LTSSM. To simplify implementation, Define macros for every LTSSM state which aardvark hardware can return in CFG_REG register. Fix also checking for link training according to the same Table 4-14. Define a new function advk_pcie_link_training() for this purpose. Link: https://lore.kernel.org/r/20211005180952.6812-13-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Cc: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: aardvark: Do not clear status bits of masked interruptsPali Rohár1-6/+0
commit a7ca6d7fa3c02c032db5440ff392d96c04684c21 upstream. The PCIE_ISR1_REG says which interrupts are currently set / active, including those which are masked. The driver currently reads this register and looks if some unmasked interrupts are active, and if not, it clears status bits of _all_ interrupts, including the masked ones. This is incorrect, since, for example, some drivers may poll these bits. Remove this clearing, and also remove this early return statement completely, since it does not change functionality in any way. Link: https://lore.kernel.org/r/20211005180952.6812-7-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18cxl/pci: Fix NULL vs ERR_PTR confusionDan Williams1-1/+1
commit ca76a3a8052b71c0334d5c094859cfa340c290a8 upstream. cxl_pci_map_regblock() may return an ERR_PTR(), but cxl_pci_setup_regs() is only prepared for NULL as the error case. Pick the minimal fix for -stable backport purposes and just have cxl_pci_map_regblock() return NULL for errors. Fixes: f8a7e8c29be8 ("cxl/pci: Reserve all device regions at once") Cc: <stable@vger.kernel.org> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163433325724.834522.17809774578178224149.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: cadence: Add cdns_plat_pcie_probe() missing returnLi Chen1-0/+2
commit 27cd7e3c9bb1ae13bc16f08138edd6e4df3cd211 upstream. When cdns_plat_pcie_probe() succeeds, return success instead of falling into the error handling code. Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library") Link: https://lore.kernel.org/r/DM6PR19MB40271B93057D949310F0B0EDA0BF9@DM6PR19MB4027.namprd19.prod.outlook.com Signed-off-by: Xuliang Zhang <xlzhanga@ambarella.com> Signed-off-by: Li Chen <lchen@ambarella.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18PCI: pci-bridge-emul: Fix emulation of W1C bitsMarek Behún1-0/+13
commit 7a41ae80bdcb17e14dd7d83239b8a0cf368f18be upstream. The pci_bridge_emul_conf_write() function correctly clears W1C bits in cfgspace cache, but it does not inform the underlying implementation about the clear request: the .write_op() method is given the value with these bits cleared. This is wrong if the .write_op() needs to know which bits were requested to be cleared. Fix the value to be passed into the .write_op() method to have requested W1C bits set, so that it can clear them. Both pci-bridge-emul users (mvebu and aardvark) are compatible with this change. Link: https://lore.kernel.org/r/20211028185659.20329-2-kabel@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ovl: fix filattr copy-up failureMiklos Szeredi2-6/+22
commit 5b0a414d06c3ed2097e32ef7944a4abb644b89bd upstream. This regression can be reproduced with ntfs-3g and overlayfs: mkdir lower upper work overlay dd if=/dev/zero of=ntfs.raw bs=1M count=2 mkntfs -F ntfs.raw mount ntfs.raw lower touch lower/file.txt mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work - overlay mv overlay/file.txt overlay/file2.txt mv fails and (misleadingly) prints mv: cannot move 'overlay/file.txt' to a subdirectory of itself, 'overlay/file2.txt' The reason is that ovl_copy_fileattr() is triggered due to S_NOATIME being set on all inodes (by fuse) regardless of fileattr. ovl_copy_fileattr() tries to retrieve file attributes from lower file, but that fails because filesystem does not support this ioctl (this should fail with ENOTTY, but ntfs-3g return EINVAL instead). This failure is propagated to origial operation (in this case rename) that triggered the copy-up. The fix is to ignore ENOTTY and EINVAL errors from fileattr_get() in copy up. This also requires turning the internal ENOIOCTLCMD into ENOTTY. As a further measure to prevent unnecessary failures, only try the fileattr_get/set on upper if there are any flags to copy up. Side note: a number of filesystems set S_NOATIME (and sometimes other inode flags) irrespective of fileattr flags. This causes unnecessary calls during copy up, which might lead to a performance issue, especially if latency is high. To fix this, the kernel would need to differentiate between the two cases. E.g. introduce SB_NOATIME_UPDATE, a per-sb variant of S_NOATIME. SB_NOATIME doesn't work, because that's interpreted as "filesystem doesn't store an atime attribute" Reported-and-tested-by: Kevin Locke <kevin@kevinlocke.name> Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags") Cc: <stable@vger.kernel.org> # v5.15 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ovl: fix use after free in struct ovl_aio_reqyangerkun1-2/+14
commit 9a254403760041528bc8f69fe2f5e1ef86950991 upstream. Example for triggering use after free in a overlay on ext4 setup: aio_read ovl_read_iter vfs_iter_read ext4_file_read_iter ext4_dio_read_iter iomap_dio_rw -> -EIOCBQUEUED /* * Here IO is completed in a separate thread, * ovl_aio_cleanup_handler() frees aio_req which has iocb embedded */ file_accessed(iocb->ki_filp); /**BOOM**/ Fix by introducing a refcount in ovl_aio_req similarly to aio_kiocb. This guarantees that iocb is only freed after vfs_read/write_iter() returns on underlying fs. Fixes: 2406a307ac7d ("ovl: implement async IO routines") Signed-off-by: yangerkun <yangerkun@huawei.com> Link: https://lore.kernel.org/r/20210930032228.3199690-3-yangerkun@huawei.com/ Cc: <stable@vger.kernel.org> # v5.6 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18xen/balloon: add late_initcall_sync() for initial ballooning doneJuergen Gross2-23/+70
commit 40fdea0284bb20814399da0484a658a96c735d90 upstream. When running as PVH or HVM guest with actual memory < max memory the hypervisor is using "populate on demand" in order to allow the guest to balloon down from its maximum memory size. For this to work correctly the guest must not touch more memory pages than its target memory size as otherwise the PoD cache will be exhausted and the guest is crashed as a result of that. In extreme cases ballooning down might not be finished today before the init process is started, which can consume lots of memory. In order to avoid random boot crashes in such cases, add a late init call to wait for ballooning down having finished for PVH/HVM guests. Warn on console if initial ballooning fails, panic() after stalling for more than 3 minutes per default. Add a module parameter for changing this timeout. [boris: replaced pr_info() with pr_notice()] Cc: <stable@vger.kernel.org> Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20211102091944.17487-1-jgross@suse.com Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ifb: fix building without CONFIG_NET_CLS_ACTArnd Bergmann1-0/+2
commit 7444d706be31753f65052c7f6325fc8470cc1789 upstream. The driver no longer depends on this option, but it fails to build if it's disabled because the skb->tc_skip_classify is hidden behind an #ifdef: drivers/net/ifb.c:81:8: error: no member named 'tc_skip_classify' in 'struct sk_buff' skb->tc_skip_classify = 1; Use the same #ifdef around the assignment. Fixes: 046178e726c2 ("ifb: Depend on netfilter alternatively to tc") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18serial: core: Fix initializing and restoring termios speedPali Rohár2-2/+16
commit 027b57170bf8bb6999a28e4a5f3d78bf1db0f90c upstream. Since commit edc6afc54968 ("tty: switch to ktermios and new framework") termios speed is no longer stored only in c_cflag member but also in new additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag then termios speed is stored only in these new members. Therefore to correctly restore termios speed it is required to store also ispeed and ospeed members, not only cflag member. In case only cflag member with BOTHER flag is restored then functions tty_termios_baud_rate() and tty_termios_input_baud_rate() returns baudrate stored in c_ospeed / c_ispeed member, which is zero as it was not restored too. If reported baudrate is invalid (e.g. zero) then serial core functions report fallback baudrate value 9600. So it means that in this case original baudrate is lost and kernel changes it to value 9600. Simple reproducer of this issue is to boot kernel with following command line argument: "console=ttyXXX,86400" (where ttyXXX is the device name). For speed 86400 there is no Bnnn constant and therefore kernel has to represent this speed via BOTHER c_cflag. Which means that speed is stored only in c_ospeed and c_ispeed members, not in c_cflag anymore. If bootloader correctly configures serial device to speed 86400 then kernel prints boot log to early console at speed speed 86400 without any issue. But after kernel starts initializing real console device ttyXXX then speed is changed to fallback value 9600 because information about speed was lost. This patch fixes above issue by storing and restoring also ispeed and ospeed members, which are required for BOTHER flag. Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework") Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20211002130900.9518-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ring-buffer: Protect ring_buffer_reset() from reentrancySteven Rostedt (VMware)1-0/+5
commit 51d157946666382e779f94c39891e8e9a020da78 upstream. The resetting of the entire ring buffer use to simply go through and reset each individual CPU buffer that had its own protection and synchronization. But this was very slow, due to performing a synchronization for each CPU. The code was reshuffled to do one disabling of all CPU buffers, followed by a single RCU synchronization, and then the resetting of each of the CPU buffers. But unfortunately, the mutex that prevented multiple occurrences of resetting the buffer was not moved to the upper function, and there is nothing to protect from it. Take the ring buffer mutex around the global reset. Cc: stable@vger.kernel.org Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU") Reported-by: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18io_uring: honour zeroes as io-wq worker limitsPavel Begunkov1-1/+3
commit bad119b9a00019054f0c9e2045f312ed63ace4f4 upstream. When we pass in zero as an io-wq worker number limit it shouldn't actually change the limits but return the old value, follow that behaviour with deferred limits setup as well. Cc: stable@kernel.org # 5.15 Reported-by: Beld Zhang <beldzhang@gmail.com> Fixes: e139a1ec92f8d ("io_uring: apply max_workers limit to all future users") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/1b222a92f7a78a24b042763805e891a4cdd4b544.1636384034.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18powerpc/85xx: Fix oops when mpc85xx_smp_guts_ids node cannot be foundXiaoming Ni1-2/+1
commit 3c2172c1c47b4079c29f0e6637d764a99355ebcd upstream. When the field described in mpc85xx_smp_guts_ids[] is not configured in dtb, the mpc85xx_setup_pmc() does not assign a value to the "guts" variable. As a result, the oops is triggered when mpc85xx_freeze_time_base() is executed. Fixes: 56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210929033646.39630-2-nixiaoming@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: adc: tsc2046: fix scan interval warningOleksij Rempel1-1/+1
commit 69b31fd7a61784692db6433c05d46915b1b1a680 upstream. Sync if statement with the actual warning. Fixes: 9504db5765e8 ("iio: adc: tsc2046: fix a warning message in tsc2046_adc_update_scan_mode()") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20211007093007.1466-2-o.rempel@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18can: j1939: j1939_tp_cmd_recv(): check the dst address of TP.CM_BAMZhang Changzhong1-0/+5
commit 164051a6ab5445bd97f719f50b16db8b32174269 upstream. The TP.CM_BAM message must be sent to the global address [1], so add a check to drop TP.CM_BAM sent to a non-global address. Without this patch, the receiver will treat the following packets as normal RTS/CTS transport: 18EC0102#20090002FF002301 18EB0102#0100000000000000 18EB0102#020000FFFFFFFFFF [1] SAE-J1939-82 2015 A.3.3 Row 1. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/all/1635431907-15617-4-git-send-email-zhangchangzhong@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18can: j1939: j1939_can_recv(): ignore messages with invalid source addressZhang Changzhong1-0/+7
commit a79305e156db3d24fcd8eb649cdb3c3b2350e5c2 upstream. According to SAE-J1939-82 2015 (A.3.6 Row 2), a receiver should never send TP.CM_CTS to the global address, so we can add a check in j1939_can_recv() to drop messages with invalid source address. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/all/1635431907-15617-3-git-send-email-zhangchangzhong@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18can: j1939: j1939_tp_cmd_recv(): ignore abort message in the BAM transportZhang Changzhong1-0/+6
commit c0f49d98006f2db3333b917caac65bce2af9865c upstream. This patch prevents BAM transport from being closed by receiving abort message, as specified in SAE-J1939-82 2015 (A.3.3 Row 4). Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/all/1635431907-15617-2-git-send-email-zhangchangzhong@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18can: mcp251xfd: mcp251xfd_irq(): add missing ↵Marc Kleine-Budde1-1/+3
can_rx_offload_threaded_irq_finish() in case of bus off commit 691204bd66b34ba982e19988e6eba9f6321dfe6c upstream. The function can_rx_offload_threaded_irq_finish() is needed to trigger the NAPI thread to deliver read CAN frames to the networking stack. This patch adds the missing call to can_rx_offload_threaded_irq_finish() in case of a bus off, before leaving the interrupt handler to avoid packet starvation. Link: https://lore.kernel.org/all/20211106201526.44292-1-mkl@pengutronix.de Fixes: 30bfec4fec59 ("can: rx-offload: can_rx_offload_threaded_irq_finish(): add new function to be called from threaded interrupt") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18can: peak_usb: always ask for BERR reporting for PCAN-USB devicesStephane Grosjean1-9/+8
commit 3f1c7aa28498e52a5e6aa2f1b89bf35c63352cfd upstream. Since for the PCAN-USB, the management of the transition to the ERROR_WARNING or ERROR_PASSIVE state is done according to the error counters, these must be requested unconditionally. Link: https://lore.kernel.org/all/20211021081505.18223-2-s.grosjean@peak-system.com Fixes: c11dcee75830 ("can: peak_usb: pcan_usb_decode_error(): upgrade handling of bus state changes") Cc: stable@vger.kernel.org Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18KVM: nVMX: Handle dynamic MSR intercept togglingSean Christopherson3-110/+111
commit 67f4b9969c305be515e47f809ecacfd86bd20a9c upstream. Always check vmcs01's MSR bitmap when merging L0 and L1 bitmaps for L2, and always update the relevant bits in vmcs02. This fixes two distinct, but intertwined bugs related to dynamic MSR bitmap modifications. The first issue is that KVM fails to enable MSR interception in vmcs02 for the FS/GS base MSRs if L1 first runs L2 with interception disabled, and later enables interception. The second issue is that KVM fails to honor userspace MSR filtering when preparing vmcs02. Fix both issues simultaneous as fixing only one of the issues (doesn't matter which) would create a mess that no one should have to bisect. Fixing only the first bug would exacerbate the MSR filtering issue as userspace would see inconsistent behavior depending on the whims of L1. Fixing only the second bug (MSR filtering) effectively requires fixing the first, as the nVMX code only knows how to transition vmcs02's bitmap from 1->0. Move the various accessor/mutators that are currently buried in vmx.c into vmx.h so that they can be shared by the nested code. Fixes: 1a155254ff93 ("KVM: x86: Introduce MSR filtering") Fixes: d69129b4e46a ("KVM: nVMX: Disable intercept for FS/GS base MSRs in vmcs02 when possible") Cc: stable@vger.kernel.org Cc: Alexander Graf <graf@amazon.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20211109013047.2041518-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18KVM: nVMX: Query current VMCS when determining if MSR bitmaps are in useSean Christopherson1-4/+4
commit 7dfbc624eb5726367900c8d86deff50836240361 upstream. Check the current VMCS controls to determine if an MSR write will be intercepted due to MSR bitmaps being disabled. In the nested VMX case, KVM will disable MSR bitmaps in vmcs02 if they're disabled in vmcs12 or if KVM can't map L1's bitmaps for whatever reason. Note, the bad behavior is relatively benign in the current code base as KVM sets all bits in vmcs02's MSR bitmap by default, clears bits if and only if L0 KVM also disables interception of an MSR, and only uses the buggy helper for MSR_IA32_SPEC_CTRL. Because KVM explicitly tests WRMSR before disabling interception of MSR_IA32_SPEC_CTRL, the flawed check will only result in KVM reading MSR_IA32_SPEC_CTRL from hardware when it isn't strictly necessary. Tag the fix for stable in case a future fix wants to use msr_write_intercepted(), in which case a buggy implementation in older kernels could prove subtly problematic. Fixes: d28b387fb74d ("KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20211109013047.2041518-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-10-01 13:19:54 +0300