commit 70b225d0a8ca1242e8a75ded86b806070ec71b2f Author: Greg Kroah-Hartman Date: Wed Oct 7 08:02:55 2020 +0200 Linux 5.8.14 Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Jeffrin Jose T Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20201005142114.732094228@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 8eec10e1335dc3a009f4fd94f23baa6ac8373d0b Author: Al Viro Date: Thu Sep 24 19:41:58 2020 -0400 ep_create_wakeup_source(): dentry name can change under you... commit 3701cb59d892b88d569427586f01491552f377b1 upstream. or get freed, for that matter, if it's a long (separately stored) name. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 4306cae1d98aeb05e85f8ccdb245b5acf96868f8 Author: Al Viro Date: Thu Sep 10 08:33:27 2020 -0400 epoll: EPOLL_CTL_ADD: close the race in decision to take fast path commit fe0a916c1eae8e17e86c3753d13919177d63ed7e upstream. Checking for the lack of epitems refering to the epoll we want to insert into is not enough; we might have an insertion of that epoll into another one that has already collected the set of files to recheck for excessive reverse paths, but hasn't gotten to creating/inserting the epitem for it. However, any such insertion in progress can be detected - it will update the generation count in our epoll when it's done looking through it for files to check. That gets done under ->mtx of our epoll and that allows us to detect that safely. We are *not* holding epmutex here, so the generation count is not stable. However, since both the update of ep->gen by loop check and (later) insertion into ->f_ep_link are done with ep->mtx held, we are fine - the sequence is grab epmutex bump loop_check_gen ... grab tep->mtx // 1 tep->gen = loop_check_gen ... drop tep->mtx // 2 ... grab tep->mtx // 3 ... insert into ->f_ep_link ... drop tep->mtx // 4 bump loop_check_gen drop epmutex and if the fastpath check in another thread happens for that eventpoll, it can come * before (1) - in that case fastpath is just fine * after (4) - we'll see non-empty ->f_ep_link, slow path taken * between (2) and (3) - loop_check_gen is stable, with ->mtx providing barriers and we end up taking slow path. Note that ->f_ep_link emptiness check is slightly racy - we are protected against insertions into that list, but removals can happen right under us. Not a problem - in the worst case we'll end up taking a slow path for no good reason. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit a6a47119b527f894409fb3dc6177e05c89085c64 Author: Al Viro Date: Thu Sep 10 08:30:05 2020 -0400 epoll: replace ->visited/visited_list with generation count commit 18306c404abe18a0972587a6266830583c60c928 upstream. removes the need to clear it, along with the races. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit bdb43b31e65d418008a7f6718bbd2ca5ee04669a Author: Al Viro Date: Wed Sep 9 22:25:06 2020 -0400 epoll: do not insert into poll queues until all sanity checks are done commit f8d4f44df056c5b504b0d49683fb7279218fd207 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 5e6bc9b1f1aef66fc4bae1a40afad33a8458e368 Author: Damien Le Moal Date: Tue Sep 15 16:33:47 2020 +0900 scsi: sd: sd_zbc: Fix ZBC disk initialization commit 6c5dee18756b4721ac8518c69b22ee8ac0c9c442 upstream. Make sure to call sd_zbc_init_disk() when the sdkp->zoned field is known, that is, once sd_read_block_characteristics() is executed in sd_revalidate_disk(), so that host-aware disks also get initialized. To do so, move sd_zbc_init_disk() call in sd_zbc_revalidate_zones() and make sure to execute it for all zoned disks, including for host-aware disks used as regular disks as these disk zoned model may be changed back to BLK_ZONED_HA when partitions are deleted. Link: https://lore.kernel.org/r/20200915073347.832424-3-damien.lemoal@wdc.com Fixes: 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND commands") Cc: # v5.8+ Reported-by: Borislav Petkov Tested-by: Borislav Petkov Reviewed-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a12f67b5477199ddd483052761f1cb2998aa5eea Author: Damien Le Moal Date: Tue Sep 15 16:33:46 2020 +0900 scsi: sd: sd_zbc: Fix handling of host-aware ZBC disks commit 27ba3e8ff3ab86449e63d38a8d623053591e65fa upstream. When CONFIG_BLK_DEV_ZONED is disabled, allow using host-aware ZBC disks as regular disks. In this case, ensure that command completion is correctly executed by changing sd_zbc_complete() to return good_bytes instead of 0 and causing a hang during device probe (endless retries). When CONFIG_BLK_DEV_ZONED is enabled and a host-aware disk is detected to have partitions, it will be used as a regular disk. In this case, make sure to not do anything in sd_zbc_revalidate_zones() as that triggers warnings. Since all these different cases result in subtle settings of the disk queue zoned model, introduce the block layer helper function blk_queue_set_zoned() to generically implement setting up the effective zoned model according to the disk type, the presence of partitions on the disk and CONFIG_BLK_DEV_ZONED configuration. Link: https://lore.kernel.org/r/20200915073347.832424-2-damien.lemoal@wdc.com Fixes: b72053072c0b ("block: allow partitions on host aware zone devices") Cc: Reported-by: Borislav Petkov Suggested-by: Christoph Hellwig Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ecd72c95c2786d4eb73786922964ec0b707f1c3e Author: Zhenyu Wang Date: Mon Sep 14 11:03:02 2020 +0800 drm/i915/gvt: Fix port number for BDW on EDID region setup commit 28284943ac94014767ecc2f7b3c5747c4a5617a0 upstream. Current BDW virtual display port is initialized as PORT_B, so need to use same port for VFIO EDID region, otherwise invalid EDID blob pointer is assigned which caused kernel null pointer reference. We might evaluate actual display hotplug for BDW to make this function work as expected, anyway this is always required to be fixed first. Reported-by: Alejandro Sior Cc: Alejandro Sior Fixes: 0178f4ce3c3b ("drm/i915/gvt: Enable vfio edid for all GVT supported platform") Reviewed-by: Hang Yuan Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20200914030302.2775505-1-zhenyuw@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 115b0aed8b749e9435210d5b1d23ac16fa6658ef Author: Andy Shevchenko Date: Tue Sep 15 15:58:16 2020 +0300 gpiolib: Fix line event handling in syscall compatible mode [ Upstream commit 5ad284ab3a01e2d6a89be2a8663ae76f4e617549 ] The introduced line event handling ABI in the commit 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") missed the fact that 64-bit kernel may serve for 32-bit applications. In such case the very first check in the lineevent_read() will fail due to alignment differences. To workaround this introduce lineevent_get_size() helper which returns actual size of the structure in user space. Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Suggested-by: Arnd Bergmann Signed-off-by: Andy Shevchenko Acked-by: Arnd Bergmann Tested-by: Kent Gibson Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit b4b93f8c92bbd870594c8e0a5b99c2c0640577dd Author: Thibaut Sautereau Date: Fri Oct 2 17:16:11 2020 +0200 random32: Restore __latent_entropy attribute on net_rand_state [ Upstream commit 09a6b0bc3be793ca8cba580b7992d73e9f68f15d ] Commit f227e3ec3b5c ("random32: update the net random state on interrupt and activity") broke compilation and was temporarily fixed by Linus in 83bdc7275e62 ("random32: remove net_rand_state from the latent entropy gcc plugin") by entirely moving net_rand_state out of the things handled by the latent_entropy GCC plugin. From what I understand when reading the plugin code, using the __latent_entropy attribute on a declaration was the wrong part and simply keeping the __latent_entropy attribute on the variable definition was the correct fix. Fixes: 83bdc7275e62 ("random32: remove net_rand_state from the latent entropy gcc plugin") Acked-by: Willy Tarreau Cc: Emese Revfy Signed-off-by: Thibaut Sautereau Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d4ff049a3463924e51ab715ebb2b9de3280eca60 Author: Linus Torvalds Date: Thu Oct 1 19:14:36 2020 -0700 pipe: remove pipe_wait() and fix wakeup race with splice [ Upstream commit 472e5b056f000a778abb41f1e443de58eb259783 ] The pipe splice code still used the old model of waiting for pipe IO by using a non-specific "pipe_wait()" that waited for any pipe event to happen, which depended on all pipe IO being entirely serialized by the pipe lock. So by checking the state you were waiting for, and then adding yourself to the wait queue before dropping the lock, you were guaranteed to see all the wakeups. Strictly speaking, the actual wakeups were not done under the lock, but the pipe_wait() model still worked, because since the waiter held the lock when checking whether it should sleep, it would always see the current state, and the wakeup was always done after updating the state. However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing") split the single wait-queue into two, and in the process also made the "wait for event" code wait for _two_ wait queues, and that then showed a race with the wakers that were not serialized by the pipe lock. It's only splice that used that "pipe_wait()" model, so the problem wasn't obvious, but Josef Bacik reports: "I hit a hang with fstest btrfs/187, which does a btrfs send into /dev/null. This works by creating a pipe, the write side is given to the kernel to write into, and the read side is handed to a thread that splices into a file, in this case /dev/null. The box that was hung had the write side stuck here [pipe_write] and the read side stuck here [splice_from_pipe_next -> pipe_wait]. [ more details about pipe_wait() scenario ] The problem is we're doing the prepare_to_wait, which sets our state each time, however we can be woken up either with reads or writes. In the case above we race with the WRITER waking us up, and re-set our state to INTERRUPTIBLE, and thus never break out of schedule" Josef had a patch that avoided the issue in pipe_wait() by just making it set the state only once, but the deeper problem is that pipe_wait() depends on a level of synchonization by the pipe mutex that it really shouldn't. And the whole "wait for any pipe state change" model really isn't very good to begin with. So rather than trying to work around things in pipe_wait(), remove that legacy model of "wait for arbitrary pipe event" entirely, and actually create functions that wait for the pipe actually being readable or writable, and can do so without depending on the pipe lock serializing everything. Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing") Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/ Reported-by: Josef Bacik Reviewed-and-tested-by: Josef Bacik Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f6e5c604d67b37a88ea5393c397b061151187afe Author: Adrian Huang Date: Sat Sep 26 18:26:02 2020 +0800 iommu/amd: Fix the overwritten field in IVMD header [ Upstream commit 0bbe4ced53e36786eafc2ecbf9a1761f55b4a82e ] Commit 387caf0b759a ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions") accidentally overwrites the 'flags' field in IVMD (struct ivmd_header) when the I/O virtualization memory definition is associated with the exclusion range entry. This leads to the corrupted IVMD table (incorrect checksum). The kdump kernel reports the invalid checksum: ACPI BIOS Warning (bug): Incorrect checksum in table [IVRS] - 0x5C, should be 0x60 (20200717/tbprint-177) AMD-Vi: [Firmware Bug]: IVRS invalid checksum Fix the above-mentioned issue by modifying the 'struct unity_map_entry' member instead of the IVMD header. Cleanup: The *exclusion_range* functions are not used anymore, so get rid of them. Fixes: 387caf0b759a ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions") Reported-and-tested-by: Baoquan He Signed-off-by: Adrian Huang Cc: Jerry Snitselaar Link: https://lore.kernel.org/r/20200926102602.19177-1-adrianhuang0701@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7af706248ce2319292a634a94a18a0e380fc4975 Author: Andy Shevchenko Date: Wed Sep 30 17:20:13 2020 +0300 gpio: pca953x: Correctly initialize registers 6 and 7 for PCA957x [ Upstream commit 8c1f1c34777bddb633d4a068a9c812d29974c6bd ] When driver has been converted to the bitmap API the non-bitmap functions started behaving differently on 32-bit BE architectures since the bytes in two consequent unsigned longs are in different order in comparison to byte array. Hence if the chip had had more than 32 lines the memset() call over it would have not set up upper lines correctly. Although it's currently a theoretical case (no supported chips of this type has 32+ lines), it's better to provide a clean code to avoid people thinking this is okay and potentially producing not fully working things. Fixes: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Signed-off-by: Andy Shevchenko Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20200930142013.59247-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b7d42304148585a388d6516c87e1462282e7ebf6 Author: Hanks Chen Date: Thu Aug 20 19:22:25 2020 +0800 pinctrl: mediatek: check mtk_is_virt_gpio input parameter [ Upstream commit 39c4dbe4cc363accd676162c24b264f44c581490 ] check mtk_is_virt_gpio input parameter, virtual gpio need to support eint mode. add error handler for the ko case to fix this boot fail: pc : mtk_is_virt_gpio+0x20/0x38 [pinctrl_mtk_common_v2] lr : mtk_gpio_get_direction+0x44/0xb0 [pinctrl_paris] Fixes: edd546465002 ("pinctrl: mediatek: avoid virtual gpio trying to set reg") Signed-off-by: Hanks Chen Acked-by: Sean Wang Singed-off-by: Jie Yang Link: https://lore.kernel.org/r/1597922546-29633-1-git-send-email-hanks.chen@mediatek.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1b62e4935b0cce18cafba105dac4c6eb93ae2e02 Author: Dmitry Baryshkov Date: Mon Sep 14 12:18:46 2020 +0300 pinctrl: qcom: sm8250: correct sdc2_clk [ Upstream commit 5d8ff95a52c36740bf4e61202d08549e7a9caf20 ] Correct sdc2_clk pin definition (register offset is wrong, verified by the msm-4.19 driver). Fixes: 4e3ec9e407ad ("pinctrl: qcom: Add sm8250 pinctrl driver.") Signed-off-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Acked-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20200914091846.55204-1-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5f040ac168f3e680c429a2a68b2f7a46e2c5f4a3 Author: Linus Torvalds Date: Tue Sep 29 17:18:34 2020 -0700 autofs: use __kernel_write() for the autofs pipe writing [ Upstream commit 90fb702791bf99b959006972e8ee7bb4609f441b ] autofs got broken in some configurations by commit 13c164b1a186 ("autofs: switch to kernel_write") because there is now an extra LSM permission check done by security_file_permission() in rw_verify_area(). autofs is one if the few places that really does want the much more limited __kernel_write(), because the write is an internal kernel one that shouldn't do any user permission checks (it also doesn't need the file_start_write/file_end_write logic, since it's just a pipe). There are a couple of other cases like that - accounting, core dumping, and splice - but autofs stands out because it can be built as a module. As a result, we need to export this internal __kernel_write() function again. We really don't want any other module to use this, but we don't have a "EXPORT_SYMBOL_FOR_AUTOFS_ONLY()". But we can mark it GPL-only to at least approximate that "internal use only" for licensing. While in this area, make autofs pass in NULL for the file position pointer, since it's always a pipe, and we now use a NULL file pointer for streaming file descriptors (see file_ppos() and commit 438ab720c675: "vfs: pass ppos=NULL to .read()/.write() of FMODE_STREAM files") This effectively reverts commits 9db977522449 ("fs: unexport __kernel_write") and 13c164b1a186 ("autofs: switch to kernel_write"). Fixes: 13c164b1a186 ("autofs: switch to kernel_write") Reported-by: Ondrej Mosnacek Acked-by: Christoph Hellwig Acked-by: Acked-by: Ian Kent Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b06582ae50525d06dfe2888692166ae12f5ff281 Author: Uwe Kleine-König Date: Sat Sep 19 16:39:22 2020 +0200 scripts/dtc: only append to HOST_EXTRACFLAGS instead of overwriting [ Upstream commit efe84d408bf41975db8506d3a1cc02e794e2309c ] When building with $ HOST_EXTRACFLAGS=-g make the expectation is that host tools are built with debug informations. This however doesn't happen if the Makefile assigns a new value to the HOST_EXTRACFLAGS instead of appending to it. So use += instead of := for the first assignment. Fixes: e3fd9b5384f3 ("scripts/dtc: consolidate include path options in Makefile") Signed-off-by: Uwe Kleine-König Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit c53cd18774060d53babe8bd754f5f9dfdc022609 Author: yangerkun Date: Sat Sep 5 19:25:56 2020 +0800 blk-mq: call commit_rqs while list empty but error happen [ Upstream commit 632bfb6323799c087fcb4108dfe59518609667a7 ] Blk-mq should call commit_rqs once 'bd.last != true' and no more request will come(so virtscsi can kick the virtqueue, e.g.). We already do that in 'blk_mq_dispatch_rq_list/blk_mq_try_issue_list_directly' while list not empty and 'queued > 0'. However, we can seen the same scene once the last request in list call queue_rq and return error like BLK_STS_IOERR which will not requeue the request, and lead that list empty but need call commit_rqs too(Or the request for virtscsi will stay timeout until other request kick virtqueue). We found this problem by do fsstress test with offline/online virtscsi device repeat quickly. Fixes: d666ba98f849 ("blk-mq: add mq_ops->commit_rqs()") Reported-by: zhangyi (F) Signed-off-by: yangerkun Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a6141f191d830f5437eff08816187ae077e377d7 Author: Vincent Huang Date: Mon Sep 28 16:19:05 2020 -0700 Input: trackpoint - enable Synaptics trackpoints [ Upstream commit 996d585b079ad494a30cac10e08585bcd5345125 ] Add Synaptics IDs in trackpoint_start_protocol() to mark them as valid. Signed-off-by: Vincent Huang Fixes: 6c77545af100 ("Input: trackpoint - add new trackpoint variant IDs") Reviewed-by: Harry Cutts Tested-by: Harry Cutts Link: https://lore.kernel.org/r/20200924053013.1056953-1-vincent.huang@tw.synaptics.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 83884333497fb58f1d96dada1e9995d868e4d38c Author: Tali Perry Date: Sun Sep 20 23:48:09 2020 +0300 i2c: npcm7xx: Clear LAST bit after a failed transaction. [ Upstream commit 8947efc077168c53b84d039881a7c967086a248a ] Due to a HW issue, in some scenarios the LAST bit might remain set. This will cause an unexpected NACK after reading 16 bytes on the next read. Example: if user tries to read from a missing device, get a NACK, then if the next command is a long read ( > 16 bytes), the master will stop reading after 16 bytes. To solve this, if a command fails, check if LAST bit is still set. If it does, reset the module. Fixes: 56a1485b102e (i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver) Signed-off-by: Tali Perry Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 95b874d021f62febafa4c74c611b38c2b2c14c82 Author: Nicolas VINCENT Date: Wed Sep 23 16:08:40 2020 +0200 i2c: cpm: Fix i2c_ram structure [ Upstream commit a2bd970aa62f2f7f80fd0d212b1d4ccea5df4aed ] the i2c_ram structure is missing the sdmatmp field mentionned in datasheet for MPC8272 at paragraph 36.5. With this field missing, the hardware would write past the allocated memory done through cpm_muram_alloc for the i2c_ram structure and land in memory allocated for the buffers descriptors corrupting the cbd_bufaddr field. Since this field is only set during setup(), the first i2c transaction would work and the following would send data read from an arbitrary memory location. Fixes: 61045dbe9d8d ("i2c: Add support for I2C bus on Freescale CPM1/CPM2 controllers") Signed-off-by: Nicolas VINCENT Acked-by: Jochen Friedrich Acked-by: Christophe Leroy Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit f6ae5ac641a886c90164a865bf56edd7c7013537 Author: Tao Ren Date: Wed Sep 16 13:42:16 2020 -0700 gpio: aspeed: fix ast2600 bank properties [ Upstream commit 3e640b1eec38e4c8eba160f26cba4f592e657f3d ] GPIO_U is mapped to the least significant byte of input/output mask, and the byte in "output" mask should be 0 because GPIO_U is input only. All the other bits need to be 1 because GPIO_V/W/X support both input and output modes. Similarly, GPIO_Y/Z are mapped to the 2 least significant bytes, and the according bits need to be 1 because GPIO_Y/Z support both input and output modes. Fixes: ab4a85534c3e ("gpio: aspeed: Add in ast2600 details to Aspeed driver") Signed-off-by: Tao Ren Reviewed-by: Andrew Jeffery Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit cf7f69852717a58dbb50fa20ddf8b5e424647703 Author: Jeremy Kerr Date: Fri Sep 11 09:51:05 2020 +0800 gpio/aspeed-sgpio: don't enable all interrupts by default [ Upstream commit bf0d394e885015941ed2d5724c0a6ed8d42dd95e ] Currently, the IRQ setup for the SGPIO driver enables all interrupts in dual-edge trigger mode. Since the default handler is handle_bad_irq, any state change on input GPIOs will trigger bad IRQ warnings. This change applies sensible IRQ defaults: single-edge trigger, and all IRQs disabled. Signed-off-by: Jeremy Kerr Fixes: 7db47faae79b ("gpio: aspeed: Add SGPIO driver") Reviewed-by: Joel Stanley Acked-by: Andrew Jeffery Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 7dc4222171ce25da56e3d23e9e5b19bb060d48f3 Author: Jeremy Kerr Date: Fri Sep 11 09:51:04 2020 +0800 gpio/aspeed-sgpio: enable access to all 80 input & output sgpios [ Upstream commit ac67b07e268d46eba675a60c37051bb3e59fd201 ] Currently, the aspeed-sgpio driver exposes up to 80 GPIO lines, corresponding to the 80 status bits available in hardware. Each of these lines can be configured as either an input or an output. However, each of these GPIOs is actually an input *and* an output; we actually have 80 inputs plus 80 outputs. This change expands the maximum number of GPIOs to 160; the lower half of this range are the input-only GPIOs, the upper half are the outputs. We fix the GPIO directions to correspond to this mapping. This also fixes a bug when setting GPIOs - we were reading from the input register, making it impossible to set more than one output GPIO. Signed-off-by: Jeremy Kerr Fixes: 7db47faae79b ("gpio: aspeed: Add SGPIO driver") Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Acked-by: Rob Herring Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 20d7a2cbc3390a4abcde81357ca622875f1bc02a Author: Ye Li Date: Wed Sep 23 02:03:44 2020 -0700 gpio: pca953x: Fix uninitialized pending variable [ Upstream commit e43c26e12dd49a41cf5a4cd5c5b59a1eb98ed11e ] When pca953x_irq_pending returns false, the pending parameter won't be set. But pca953x_irq_handler continues using this uninitialized variable as pending irqs and will cause problem. Fix the issue by initializing pending to 0. Fixes: 064c73afe738 ("gpio: pca953x: Synchronize interrupt handler properly") Signed-off-by: Ye Li Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c8a8adc7df57e9f228e855545f4fa613f6f03364 Author: Yu Kuai Date: Fri Sep 18 09:13:35 2020 +0800 iommu/exynos: add missing put_device() call in exynos_iommu_of_xlate() [ Upstream commit 1a26044954a6d1f4d375d5e62392446af663be7a ] if of_find_device_by_node() succeed, exynos_iommu_of_xlate() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: aa759fd376fb ("iommu/exynos: Add callback for initializing devices from device tree") Signed-off-by: Yu Kuai Acked-by: Marek Szyprowski Link: https://lore.kernel.org/r/20200918011335.909141-1-yukuai3@huawei.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 32b462c501ee5428573fc54fec69e3e2795c6a41 Author: Sudhakar Panneerselvam Date: Wed Sep 16 23:54:31 2020 +0000 scsi: target: Fix lun lookup for TARGET_SCF_LOOKUP_LUN_FROM_TAG case [ Upstream commit 149415586243bd0ea729760fb6dd7b3c50601871 ] transport_lookup_tmr_lun() uses "orig_fe_lun" member of struct se_cmd for the lookup. Hence, update this field directly for the TARGET_SCF_LOOKUP_LUN_FROM_TAG case. Link: https://lore.kernel.org/r/1600300471-26135-1-git-send-email-sudhakar.panneerselvam@oracle.com Fixes: a36840d80027 ("target: Initialize LUN in transport_init_se_cmd()") Reported-by: Martin Wilck Reviewed-by: Mike Christie Signed-off-by: Sudhakar Panneerselvam Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 40e2e6c71ac13ffd03d46493eaacb6dfc6944cda Author: Marek Szyprowski Date: Tue Sep 22 14:40:46 2020 +0200 clk: samsung: exynos4: mark 'chipid' clock as CLK_IGNORE_UNUSED [ Upstream commit f3bb0f796f5ffe32f0fbdce5b1b12eb85511158f ] The ChipID IO region has it's own clock, which is being disabled while scanning for unused clocks. It turned out that some CPU hotplug, CPU idle or even SOC firmware code depends on the reads from that area. Fix the mysterious hang caused by entering deep CPU idle state by ignoring the 'chipid' clock during unused clocks scan, as there are no direct clients for it which will keep it enabled. Fixes: e062b571777f ("clk: exynos4: register clocks using common clock framework") Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20200922124046.10496-1-m.szyprowski@samsung.com Reviewed-by: Krzysztof Kozlowski Acked-by: Sylwester Nawrocki Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f6e9c4310f5a73531311fcceff98a6b4a2b5f6fb Author: Vladimir Murzin Date: Tue Sep 22 14:58:45 2020 +0300 dmaengine: dmatest: Prevent to run on misconfigured channel [ Upstream commit ce65d55f92a67e247f4d799e581cf9fed677871c ] Andy reported that commit 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel") broke his scripts for the case where "busy" channel is used for configuration with expectation that run command would do nothing. Instead, behavior was (unintentionally) changed to treat such case as under-configuration and progress with defaults, i.e. run command would start a test with default setting for channel (which would use all channels). Restore original behavior with tracking status of channel setter so we can distinguish between misconfigured and under-configured cases in run command and act accordingly. Fixes: 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel") Reported-by: Andy Shevchenko Tested-by: Andy Shevchenko Signed-off-by: Vladimir Murzin Tested-by: Peter Ujfalusi Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200922115847.30100-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ec9002ead04bb94e78c94e78bed9bb794c14dc31 Author: Thierry Reding Date: Mon Jun 22 08:08:26 2020 +0200 clk: tegra: Fix missing prototype for tegra210_clk_register_emc() [ Upstream commit 2f878d04218c8b26f6d0ab26955ca6b03848a1ad ] Include the Tegra driver's clk.h to pull in the prototype definition for this function so that compilers don't warn about it being missing. Fixes: 0ac65fc946d3 ("clk: tegra: Implement Tegra210 EMC clock") Reported-by: kernel test robot Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ef3f3611b4620846690a3ab6dad047de3ecf4be7 Author: Thierry Reding Date: Wed Jun 3 13:13:07 2020 +0200 clk: tegra: Always program PLL_E when enabled [ Upstream commit 5105660ee80862b85f7769626d0f936c18ce1885 ] Commit bff1cef5f23a ("clk: tegra: Don't enable already enabled PLLs") added checks to avoid enabling PLLs that have already been enabled by the bootloader. However, the PLL_E configuration inherited from the bootloader isn't necessarily the one that is needed for the kernel. This can cause SATA to fail like this: [ 5.310270] phy phy-sata.6: phy poweron failed --> -110 [ 5.315604] tegra-ahci 70027000.sata: failed to power on AHCI controller: -110 [ 5.323022] tegra-ahci: probe of 70027000.sata failed with error -110 Fix this by always programming the PLL_E. This ensures that any mis- configuration by the bootloader will be overwritten by the kernel. Fixes: bff1cef5f23a ("clk: tegra: Don't enable already enabled PLLs") Reported-by: LABBE Corentin Tested-by: Corentin Labbe Reviewed-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 63cd394fa3f04eab24b9d8cfbad38b2b1da4cca2 Author: Trond Myklebust Date: Fri Sep 18 08:58:58 2020 -0400 pNFS/flexfiles: Ensure we initialise the mirror bsizes correctly on read [ Upstream commit ee15c7b53e52fb04583f734461244c4dcca828fa ] While it is true that reading from an unmirrored source always uses index 0, that is no longer true for mirrored sources when we fail over. Fixes: 563c53e73b8b ("NFS: Fix flexfiles read failover") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ac376f2245bb790472112154b7f87ffb613e65f5 Author: Olga Kornievskaia Date: Wed Sep 16 09:07:54 2020 -0400 NFSv4.2: fix client's attribute cache management for copy_file_range [ Upstream commit 16abd2a0c124a6c3543c88ca4c53c997c9fb4114 ] After client is done with the COPY operation, it needs to invalidate its pagecache (as it did no reading or writing of the data locally) and it needs to invalidate it's attributes just like it would have for a read on the source file and write on the destination file. Once the linux server started giving out read delegations to read+write opens, the destination file of the copy_file range started having delegations and not doing syncup on close of the file leading to xfstest failures for generic/430,431,432,433,565. v2: changing cache_validity needs to be protected by the i_lock. Reported-by: Murphy Zhou Fixes: 2e72448b07dc ("NFS: Add COPY nfs operation") Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit a98e3583bd8d4ed8c5cab6a154a645aff8ea5873 Author: Jeffrey Mitchell Date: Tue Sep 15 16:42:52 2020 -0500 nfs: Fix security label length not being reset [ Upstream commit d33030e2ee3508d65db5644551435310df86010e ] nfs_readdir_page_filler() iterates over entries in a directory, reusing the same security label buffer, but does not reset the buffer's length. This causes decode_attr_security_label() to return -ERANGE if an entry's security label is longer than the previous one's. This error, in nfs4_decode_dirent(), only gets passed up as -EAGAIN, which causes another failed attempt to copy into the buffer. The second error is ignored and the remaining entries do not show up in ls, specifically the getdents64() syscall. Reproduce by creating multiple files in NFS and giving one of the later files a longer security label. ls will not see that file nor any that are added afterwards, though they will exist on the backend. In nfs_readdir_page_filler(), reset security label buffer length before every reuse Signed-off-by: Jeffrey Mitchell Fixes: b4487b935452 ("nfs: Fix getxattr kernel panic and memory overflow") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 6846eb76234461c498be72c3d27c641cd245ca40 Author: Chris Packham Date: Tue Sep 8 09:17:10 2020 +1200 pinctrl: mvebu: Fix i2c sda definition for 98DX3236 [ Upstream commit 63c3212e7a37d68c89a13bdaebce869f4e064e67 ] Per the datasheet the i2c functions use MPP_Sel=0x1. They are documented as using MPP_Sel=0x4 as well but mixing 0x1 and 0x4 is clearly wrong. On the board tested 0x4 resulted in a non-functioning i2c bus so stick with 0x1 which works. Fixes: d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC") Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20200907211712.9697-2-chris.packham@alliedtelesis.co.nz Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fdf8212f0260a27590aa7356b8da026943630548 Author: Dan Carpenter Date: Sat Sep 5 15:46:48 2020 +0300 phy: ti: am654: Fix a leak in serdes_am654_probe() [ Upstream commit 850280156f6421a404f2351bee07a0e7bedfd4c6 ] If devm_phy_create() fails then we need to call of_clk_del_provider(node) to undo the call to of_clk_add_provider(). Fixes: 71e2f5c5c224 ("phy: ti: Add a new SERDES driver for TI's AM654x SoC") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200905124648.GA183976@mwanda Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9f6c717ffa4716ecdd02b7f913d663af317da2a4 Author: Taiping Lai Date: Mon Aug 31 17:09:47 2020 +0800 gpio: sprd: Clear interrupt when setting the type as edge [ Upstream commit 5fcface659aab7eac4bd65dd116d98b8f7bb88d5 ] The raw interrupt status of GPIO maybe set before the interrupt is enabled, which would trigger the interrupt event once enabled it from user side. This is the case for edge interrupts only. Adding a clear operation when setting interrupt type can avoid that. There're a few considerations for the solution: 1) This issue is for edge interrupt only; The interrupts requested by users are IRQ_TYPE_LEVEL_HIGH as default, so clearing interrupt when request is useless. 2) The interrupt type can be set to edge when request and following up with clearing it though, but the problem is still there once users set the interrupt type to level trggier. 3) We can add a clear operation after each time of setting interrupt enable bit, but it is redundant for level trigger interrupt. Therefore, the solution is this patch seems the best for now. Fixes: 9a3821c2bb47 ("gpio: Add GPIO driver for Spreadtrum SC9860 platform") Signed-off-by: Taiping Lai Signed-off-by: Chunyan Zhang Reviewed-by: Baolin Wang Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 6bef7d4b4770c42bb4abd5215801121672f7acd9 Author: Masahiro Yamada Date: Wed Sep 23 02:48:56 2020 +0900 scripts/kallsyms: skip ppc compiler stub *.long_branch.* / *.plt_branch.* [ Upstream commit 516d980f85415d76ae3d0d2a871eb20243f46c95 ] PowerPC allmodconfig often fails to build as follows: LD .tmp_vmlinux.kallsyms1 KSYM .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 KSYM .tmp_vmlinux.kallsyms2.o LD .tmp_vmlinux.kallsyms3 KSYM .tmp_vmlinux.kallsyms3.o LD vmlinux SORTTAB vmlinux SYSMAP System.map Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround make[2]: *** [../Makefile:1162: vmlinux] Error 1 Setting KALLSYMS_EXTRA_PASS=1 does not help. This is caused by the compiler inserting stubs such as *.long_branch.* and *.plt_branch.* $ powerpc-linux-nm -n .tmp_vmlinux.kallsyms2 [ snip ] c00000000210c010 t 00000075.plt_branch.da9:19 c00000000210c020 t 00000075.plt_branch.1677:5 c00000000210c030 t 00000075.long_branch.memmove c00000000210c034 t 00000075.plt_branch.9e0:5 c00000000210c044 t 00000075.plt_branch.free_initrd_mem ... Actually, the problem mentioned in scripts/link-vmlinux.sh comments; "In theory it's possible this results in even more stubs, but unlikely" is happening here, and ends up with another kallsyms step required. scripts/kallsyms.c already ignores various compiler stubs. Let's do similar to make kallsysms for PowerPC always succeed in 2 steps. Reported-by: Guenter Roeck Signed-off-by: Masahiro Yamada Tested-by: Guenter Roeck Signed-off-by: Sasha Levin commit a50ea89d1ae546bcd28a7afb0be45cdb1a1138ba Author: James Smart Date: Thu Sep 17 13:33:22 2020 -0700 nvme-fc: fail new connections to a deleted host or remote port [ Upstream commit 9e0e8dac985d4bd07d9e62922b9d189d3ca2fccf ] The lldd may have made calls to delete a remote port or local port and the delete is in progress when the cli then attempts to create a new controller. Currently, this proceeds without error although it can't be very successful. Fix this by validating that both the host port and remote port are present when a new controller is to be created. Signed-off-by: James Smart Reviewed-by: Himanshu Madhani Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7d2120bc38b94381f04c18b4ad49b62ecd83c882 Author: Xianting Tian Date: Tue Sep 22 14:25:17 2020 +0800 nvme-pci: fix NULL req in completion handler [ Upstream commit 50b7c24390a53c78de546215282fb52980f1d7b7 ] Currently, we use nvmeq->q_depth as the upper limit for a valid tag in nvme_handle_cqe(), it is not correct. Because the available tag number is recorded in tagset, which is not equal to nvmeq->q_depth. The nvme driver registers interrupts for queues before initializing the tagset, because it uses the number of successful request_irq() calls to configure the tagset parameters. This allows a race condition with the current tag validity check if the controller happens to produce an interrupt with a corrupted CQE before the tagset is initialized. Replace the driver's indirect tag check with the one already provided by the block layer. Signed-off-by: Xianting Tian Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 189c154bc593f6fe592f322fee5dd2ff4c0613b0 Author: Xiaoliang Yang Date: Tue Sep 22 01:56:36 2020 +0300 net: dsa: felix: fix some key offsets for IP4_TCP_UDP VCAP IS2 entries [ Upstream commit 8b9e03cd08250c60409099c791e858157838d9eb ] Some of the IS2 IP4_TCP_UDP keys are not correct, like L4_DPORT, L4_SPORT and other L4 keys. This prevents offloaded tc-flower rules from matching on src_port and dst_port for TCP and UDP packets. Signed-off-by: Xiaoliang Yang Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b23f9f0dc930e415eaa011a6a68ee061466ea92b Author: Chris Packham Date: Fri Sep 4 12:28:12 2020 +1200 spi: fsl-espi: Only process interrupts for expected events [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ] The SPIE register contains counts for the TX FIFO so any time the irq handler was invoked we would attempt to process the RX/TX fifos. Use the SPIM value to mask the events so that we only process interrupts that were expected. This was a latent issue exposed by commit 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C"). Signed-off-by: Chris Packham Link: https://lore.kernel.org/r/20200904002812.7300-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cbbc927e0e62bc373f066a9c5dc3e96f8e5e7b30 Author: Ulf Hansson Date: Fri Sep 4 08:47:05 2020 +0200 cpuidle: psci: Fix suspicious RCU usage [ Upstream commit 36050d8984ab743f9990a2eb97a0062fdc3d7bbd ] The commit eb1f00237aca ("lockdep,trace: Expose tracepoints"), started to expose us for tracepoints. This lead to the following RCU splat on an ARM64 Qcom board. [ 5.529634] WARNING: suspicious RCU usage [ 5.537307] sdhci-pltfm: SDHCI platform and OF driver helper [ 5.541092] 5.9.0-rc3 #86 Not tainted [ 5.541098] ----------------------------- [ 5.541105] ../include/trace/events/lock.h:37 suspicious rcu_dereference_check() usage! [ 5.541110] [ 5.541110] other info that might help us debug this: [ 5.541110] [ 5.541116] [ 5.541116] rcu_scheduler_active = 2, debug_locks = 1 [ 5.541122] RCU used illegally from extended quiescent state! [ 5.541129] no locks held by swapper/0/0. [ 5.541134] [ 5.541134] stack backtrace: [ 5.541143] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.0-rc3 #86 [ 5.541149] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 5.541157] Call trace: [ 5.568185] sdhci_msm 7864900.sdhci: Got CD GPIO [ 5.574186] dump_backtrace+0x0/0x1c8 [ 5.574206] show_stack+0x14/0x20 [ 5.574229] dump_stack+0xe8/0x154 [ 5.574250] lockdep_rcu_suspicious+0xd4/0xf8 [ 5.574269] lock_acquire+0x3f0/0x460 [ 5.574292] _raw_spin_lock_irqsave+0x80/0xb0 [ 5.574314] __pm_runtime_suspend+0x4c/0x188 [ 5.574341] psci_enter_domain_idle_state+0x40/0xa0 [ 5.574362] cpuidle_enter_state+0xc0/0x610 [ 5.646487] cpuidle_enter+0x38/0x50 [ 5.650651] call_cpuidle+0x18/0x40 [ 5.654467] do_idle+0x228/0x278 [ 5.657678] cpu_startup_entry+0x24/0x70 [ 5.661153] rest_init+0x1a4/0x278 [ 5.665061] arch_call_rest_init+0xc/0x14 [ 5.668272] start_kernel+0x508/0x540 Following the path in pm_runtime_put_sync_suspend() from psci_enter_domain_idle_state(), it seems like we end up using the RCU. Therefore, let's simply silence the splat by informing the RCU about it with RCU_NONIDLE. Note that, this is a temporary solution. Instead we should strive to avoid using RCU_NONIDLE (and similar), but rather push rcu_idle_enter|exit() further down, closer to the arch specific code. However, as the CPU PM notifiers are also using the RCU, additional rework is needed. Reported-by: Naresh Kamboju Signed-off-by: Ulf Hansson Acked-by: Paul E. McKenney Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f833ed7a202b4b8c059409a20430cd234140a486 Author: Jens Axboe Date: Fri Sep 18 16:51:19 2020 -0600 io_uring: mark statx/files_update/epoll_ctl as non-SQPOLL [ Upstream commit 6ca56f845955e325033758f90a2cffe150f31bc8 ] These will naturally fail when attempted through SQPOLL, but either with -EFAULT or -EBADF. Make it explicit that these are not workable through SQPOLL and return -EINVAL, just like other ops that need to use ->files. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fc4b56ae9e76b59f8db5a38eaf8e771e03fc9ead Author: Douglas Gilbert Date: Mon Sep 14 17:36:09 2020 -0400 tools/io_uring: fix compile breakage [ Upstream commit 72f04da48a9828ba3ae8ac77bea648bda8b7d0ff ] It would seem none of the kernel continuous integration does this: $ cd tools/io_uring $ make Otherwise it may have noticed: cc -Wall -Wextra -g -D_GNU_SOURCE -c -o io_uring-bench.o io_uring-bench.c io_uring-bench.c:133:12: error: static declaration of ‘gettid’ follows non-static declaration 133 | static int gettid(void) | ^~~~~~ In file included from /usr/include/unistd.h:1170, from io_uring-bench.c:27: /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ make: *** [: io_uring-bench.o] Error 1 The problem on Ubuntu 20.04 (with lk 5.9.0-rc5) is that unistd.h already defines gettid(). So prefix the local definition with "lk_". Signed-off-by: Douglas Gilbert Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4ff709d00af400e3ba4d4221834074460e4230a4 Author: Sebastian Andrzej Siewior Date: Fri Sep 4 10:23:31 2020 +0200 tracing: Make the space reserved for the pid wider [ Upstream commit 795d6379a47bcbb88bd95a69920e4acc52849f88 ] For 64bit CONFIG_BASE_SMALL=0 systems PID_MAX_LIMIT is set by default to 4194304. During boot the kernel sets a new value based on number of CPUs but no lower than 32768. It is 1024 per CPU so with 128 CPUs the default becomes 131072 which needs six digits. This value can be increased during run time but must not exceed the initial upper limit. Systemd sometime after v241 sets it to the upper limit during boot. The result is that when the pid exceeds five digits, the trace output is a little hard to read because it is no longer properly padded (same like on big iron with 98+ CPUs). Increase the pid padding to seven digits. Link: https://lkml.kernel.org/r/20200904082331.dcdkrr3bkn3e4qlg@linutronix.de Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit f2465c7d069c12627948456ba3438af87eb0a14f Author: Felix Fietkau Date: Thu Sep 17 14:50:31 2020 +0200 mac80211: do not allow bigger VHT MPDUs than the hardware supports [ Upstream commit 3bd5c7a28a7c3aba07a2d300d43f8e988809e147 ] Limit maximum VHT MPDU size by local capability. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20200917125031.45009-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9c72951f9e9706efd7965b8fd9eddd908de0398b Author: Aloka Dixit Date: Fri Sep 11 01:11:35 2020 +0000 mac80211: Fix radiotap header channel flag for 6GHz band [ Upstream commit 412a84b5714af56f3eb648bba155107b5edddfdf ] Radiotap header field 'Channel flags' has '2 GHz spectrum' set to 'true' for 6GHz packet. Change it to 5GHz as there isn't a separate option available for 6GHz. Signed-off-by: Aloka Dixit Link: https://lore.kernel.org/r/010101747ab7b703-1d7c9851-1594-43bf-81f7-f79ce7a67cc6-000000@us-west-2.amazonses.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2dd5f2a99bf380d90363e9408563c5153a8a1f0d Author: Xie He Date: Wed Sep 16 14:25:07 2020 -0700 drivers/net/wan/hdlc: Set skb->protocol before transmitting [ Upstream commit 9fb030a70431a2a2a1b292dbf0b2f399cc072c16 ] This patch sets skb->protocol before transmitting frames on the HDLC device, so that a user listening on the HDLC device with an AF_PACKET socket will see outgoing frames' sll_protocol field correctly set and consistent with that of incoming frames. 1. Control frames in hdlc_cisco and hdlc_ppp When these drivers send control frames, skb->protocol is not set. This value should be set to htons(ETH_P_HDLC), because when receiving control frames, their skb->protocol is set to htons(ETH_P_HDLC). When receiving, hdlc_type_trans in hdlc.h is called, which then calls cisco_type_trans or ppp_type_trans. The skb->protocol of control frames is set to htons(ETH_P_HDLC) so that the control frames can be received by hdlc_rcv in hdlc.c, which calls cisco_rx or ppp_rx to process the control frames. 2. hdlc_fr When this driver sends control frames, skb->protocol is set to internal values used in this driver. When this driver sends data frames (from upper stacked PVC devices), skb->protocol is the same as that of the user data packet being sent on the upper PVC device (for normal PVC devices), or is htons(ETH_P_802_3) (for Ethernet-emulating PVC devices). However, skb->protocol for both control frames and data frames should be set to htons(ETH_P_HDLC), because when receiving, all frames received on the HDLC device will have their skb->protocol set to htons(ETH_P_HDLC). When receiving, hdlc_type_trans in hdlc.h is called, and because this driver doesn't provide a type_trans function in struct hdlc_proto, all frames will have their skb->protocol set to htons(ETH_P_HDLC). The frames are then received by hdlc_rcv in hdlc.c, which calls fr_rx to process the frames (control frames are consumed and data frames are re-received on upper PVC devices). Cc: Krzysztof Halasa Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3074634461c5d2744b8c8dcbc86135a9f77e7c42 Author: Xie He Date: Wed Sep 16 09:49:18 2020 -0700 drivers/net/wan/lapbether: Make skb->protocol consistent with the header [ Upstream commit 83f9a9c8c1edc222846dc1bde6e3479703e8e5a3 ] This driver is a virtual driver stacked on top of Ethernet interfaces. When this driver transmits data on the Ethernet device, the skb->protocol setting is inconsistent with the Ethernet header prepended to the skb. This causes a user listening on the Ethernet interface with an AF_PACKET socket, to see different sll_protocol values for incoming and outgoing frames, because incoming frames would have this value set by parsing the Ethernet header. This patch changes the skb->protocol value for outgoing Ethernet frames, making it consistent with the Ethernet header prepended. This makes a user listening on the Ethernet device with an AF_PACKET socket, to see the same sll_protocol value for incoming and outgoing frames. Cc: Martin Schiller Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 74e81de01e496ce07d7819cc80aeed50c35e9fbe Author: Al Viro Date: Thu Sep 17 17:26:56 2020 -0400 fuse: fix the ->direct_IO() treatment of iov_iter [ Upstream commit 933a3752babcf6513117d5773d2b70782d6ad149 ] the callers rely upon having any iov_iter_truncate() done inside ->direct_IO() countered by iov_iter_reexpand(). Reported-by: Qian Cai Tested-by: Qian Cai Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 72adaf9348028a18ee9f775233465de9c937a96e Author: Chaitanya Kulkarni Date: Tue Sep 15 20:53:25 2020 -0700 nvme-core: get/put ctrl and transport module in nvme_dev_open/release() [ Upstream commit 52a3974feb1a3eec25d8836d37a508b67b0a9cd0 ] Get and put the reference to the ctrl in the nvme_dev_open() and nvme_dev_release() before and after module get/put for ctrl in char device file operations. Introduce char_dev relase function, get/put the controller and module which allows us to fix the potential Oops which can be easily reproduced with a passthru ctrl (although the problem also exists with pure user access): Entering kdb (current=0xffff8887f8290000, pid 3128) on processor 30 Oops: (null) due to oops @ 0xffffffffa01019ad CPU: 30 PID: 3128 Comm: bash Tainted: G W OE 5.8.0-rc4nvme-5.9+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.4 RIP: 0010:nvme_free_ctrl+0x234/0x285 [nvme_core] Code: 57 10 a0 e8 73 bf 02 e1 ba 3d 11 00 00 48 c7 c6 98 33 10 a0 48 c7 c7 1d 57 10 a0 e8 5b bf 02 e1 8 RSP: 0018:ffffc90001d63de0 EFLAGS: 00010246 RAX: ffffffffa05c0440 RBX: ffff8888119e45a0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8888177e9550 RDI: ffff8888119e43b0 RBP: ffff8887d4768000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: ffffc90001d63c90 R12: ffff8888119e43b0 R13: ffff8888119e5108 R14: dead000000000100 R15: ffff8888119e5108 FS: 00007f1ef27b0740(0000) GS:ffff888817600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa05c0470 CR3: 00000007f6bee000 CR4: 00000000003406e0 Call Trace: device_release+0x27/0x80 kobject_put+0x98/0x170 nvmet_passthru_ctrl_disable+0x4a/0x70 [nvmet] nvmet_passthru_enable_store+0x4c/0x90 [nvmet] configfs_write_file+0xe6/0x150 vfs_write+0xba/0x1e0 ksys_write+0x5f/0xe0 do_syscall_64+0x52/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f1ef1eb2840 Code: Bad RIP value. RSP: 002b:00007fffdbff0eb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1ef1eb2840 RDX: 0000000000000002 RSI: 00007f1ef27d2000 RDI: 0000000000000001 RBP: 00007f1ef27d2000 R08: 000000000000000a R09: 00007f1ef27b0740 R10: 0000000000000001 R11: 0000000000000246 R12: 00007f1ef2186400 R13: 0000000000000002 R14: 0000000000000001 R15: 0000000000000000 With this patch fix we take the module ref count in nvme_dev_open() and release that ref count in newly introduced nvme_dev_release(). Signed-off-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f3f3da8c1ff92ebd949a8fc0797527f7040d3470 Author: David Milburn Date: Thu Sep 10 16:18:50 2020 -0500 nvme-pci: disable the write zeros command for Intel 600P/P3100 [ Upstream commit ce4cc3133dc72c31bd49ddcf22d0f9eeff47a761 ] The write zeros command does not work with 4k range. bash-4.4# ./blkdiscard /dev/nvme0n1p2 bash-4.4# strace -efallocate xfs_io -c "fzero 536895488 2048" /dev/nvme0n1p2 fallocate(3, FALLOC_FL_ZERO_RANGE, 536895488, 2048) = 0 +++ exited with 0 +++ bash-4.4# dd bs=1 if=/dev/nvme0n1p2 skip=536895488 count=512 | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 bash-4.4# ./blkdiscard /dev/nvme0n1p2 bash-4.4# strace -efallocate xfs_io -c "fzero 536895488 4096" /dev/nvme0n1p2 fallocate(3, FALLOC_FL_ZERO_RANGE, 536895488, 4096) = 0 +++ exited with 0 +++ bash-4.4# dd bs=1 if=/dev/nvme0n1p2 skip=536895488 count=512 | hexdump -C 00000000 5c 61 5c b0 96 21 1b 5e 85 0c 07 32 9c 8c eb 3c |\a\..!.^...2...<| 00000010 4a a2 06 ca 67 15 2d 8e 29 8d a8 a0 7e 46 8c 62 |J...g.-.)...~F.b| 00000020 bb 4c 6c c1 6b f5 ae a5 e4 a9 bc 93 4f 60 ff 7a |.Ll.k.......O`.z| Reported-by: Eric Sandeen Signed-off-by: David Milburn Tested-by: Eric Sandeen Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 33701f04a59a3a96166973e5d1947c9567496671 Author: Olympia Giannou Date: Fri Sep 11 14:17:24 2020 +0000 rndis_host: increase sleep time in the query-response loop [ Upstream commit 4202c9fdf03d79dedaa94b2c4cf574f25793d669 ] Some WinCE devices face connectivity issues via the NDIS interface. They fail to register, resulting in -110 timeout errors and failures during the probe procedure. In this kind of WinCE devices, the Windows-side ndis driver needs quite more time to be loaded and configured, so that the linux rndis host queries to them fail to be responded correctly on time. More specifically, when INIT is called on the WinCE side - no other requests can be served by the Client and this results in a failed QUERY afterwards. The increase of the waiting time on the side of the linux rndis host in the command-response loop leaves the INIT process to complete and respond to a QUERY, which comes afterwards. The WinCE devices with this special "feature" in their ndis driver are satisfied by this fix. Signed-off-by: Olympia Giannou Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 21f41dd7e8839aa66844740cfbf81b2c69a62d58 Author: Lucy Yan Date: Thu Sep 10 12:05:09 2020 -0700 net: dec: de2104x: Increase receive ring size for Tulip [ Upstream commit ee460417d254d941dfea5fb7cff841f589643992 ] Increase Rx ring size to address issue where hardware is reaching the receive work limit. Before: [ 102.223342] de2104x 0000:17:00.0 eth0: rx work limit reached [ 102.245695] de2104x 0000:17:00.0 eth0: rx work limit reached [ 102.251387] de2104x 0000:17:00.0 eth0: rx work limit reached [ 102.267444] de2104x 0000:17:00.0 eth0: rx work limit reached Signed-off-by: Lucy Yan Reviewed-by: Moritz Fischer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c524f9df9c7afec25995f4f973b7aa742412cdd Author: Dexuan Cui Date: Tue Sep 8 21:08:19 2020 -0700 hv_netvsc: Cache the current data path to avoid duplicate call and message [ Upstream commit da26658c3d7005aa67a706dceff7b2807b59e123 ] The previous change "hv_netvsc: Switch the data path at the right time during hibernation" adds the call of netvsc_vf_changed() upon NETDEV_CHANGE, so it's necessary to avoid the duplicate call and message when the VF is brought UP or DOWN. Signed-off-by: Dexuan Cui Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit caac35688ac1d33e597a51f39e00c9fde1668a37 Author: Martin Cerveny Date: Sun Sep 6 18:21:40 2020 +0200 drm/sun4i: mixer: Extend regmap max_register [ Upstream commit 74ea06164cda81dc80e97790164ca533fd7e3087 ] Better guess. Secondary CSC registers are from 0xF0000. Signed-off-by: Martin Cerveny Reviewed-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200906162140.5584-3-m.cerveny@computer.org Signed-off-by: Sasha Levin commit b92f98f9307c344a14fe6ad7010327c4b658a517 Author: Mauro Carvalho Chehab Date: Wed Aug 26 07:49:34 2020 +0200 Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver" [ Upstream commit 1264c1e0cfe55e2d6c35e869244093195529af37 ] This patch causes a regression betwen Kernel 5.7 and 5.8 at wlcore: with it applied, WiFi stops working, and the Kernel starts printing this message every second: wlcore: PHY firmware version: Rev 8.2.0.0.242 wlcore: firmware booted (Rev 8.9.0.0.79) wlcore: ERROR command execute failure 14 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 133 at drivers/net/wireless/ti/wlcore/main.c:795 wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore] Modules linked in: wl18xx wlcore mac80211 libarc4 cfg80211 rfkill snd_soc_hdmi_codec crct10dif_ce wlcore_sdio adv7511 cec kirin9xx_drm(C) kirin9xx_dw_drm_dsi(C) drm_kms_helper drm ip_tables x_tables ipv6 nf_defrag_ipv6 CPU: 0 PID: 133 Comm: kworker/0:1 Tainted: G WC 5.8.0+ #186 Hardware name: HiKey970 (DT) Workqueue: events_freezable ieee80211_restart_work [mac80211] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) pc : wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore] lr : wl12xx_queue_recovery_work+0x24/0x30 [wlcore] sp : ffff8000126c3a60 x29: ffff8000126c3a60 x28: 00000000000025de x27: 0000000000000010 x26: 0000000000000005 x25: ffff0001a5d49e80 x24: ffff8000092cf580 x23: ffff0001b7c12623 x22: ffff0001b6fcf2e8 x21: ffff0001b7e46200 x20: 00000000fffffffb x19: ffff0001a78e6400 x18: 0000000000000030 x17: 0000000000000001 x16: 0000000000000001 x15: ffff0001b7e46670 x14: ffffffffffffffff x13: ffff8000926c37d7 x12: ffff8000126c37e0 x11: ffff800011e01000 x10: ffff8000120526d0 x9 : 0000000000000000 x8 : 3431206572756c69 x7 : 6166206574756365 x6 : 0000000000000c2c x5 : 0000000000000000 x4 : ffff0001bf1361e8 x3 : ffff0001bf1790b0 x2 : 0000000000000000 x1 : ffff0001a5d49e80 x0 : 0000000000000001 Call trace: wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore] wl12xx_queue_recovery_work+0x24/0x30 [wlcore] wl1271_cmd_set_sta_key+0x258/0x25c [wlcore] wl1271_set_key+0x7c/0x2dc [wlcore] wlcore_set_key+0xe4/0x360 [wlcore] wl18xx_set_key+0x48/0x1d0 [wl18xx] wlcore_op_set_key+0xa4/0x180 [wlcore] ieee80211_key_enable_hw_accel+0xb0/0x2d0 [mac80211] ieee80211_reenable_keys+0x70/0x110 [mac80211] ieee80211_reconfig+0xa00/0xca0 [mac80211] ieee80211_restart_work+0xc4/0xfc [mac80211] process_one_work+0x1cc/0x350 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x30 ---[ end trace b1f722abf9af5919 ]--- wlcore: WARNING could not set keys wlcore: ERROR Could not add or replace key wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-5) wlcore: Hardware recovery in progress. FW ver: Rev 8.9.0.0.79 wlcore: pc: 0x0, hint_sts: 0x00000040 count: 39 wlcore: down wlcore: down ieee80211 phy0: Hardware restart was requested mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) mmc_host mmc0: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0) wlcore: PHY firmware version: Rev 8.2.0.0.242 wlcore: firmware booted (Rev 8.9.0.0.79) wlcore: ERROR command execute failure 14 ------------[ cut here ]------------ Tested on Hikey 970. This reverts commit 2b7aadd3b9e17e8b81eeb8d9cc46756ae4658265. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/f0a2cb7ea606f1a284d4c23cbf983da2954ce9b6.1598420968.git.mchehab+huawei@kernel.org Signed-off-by: Sasha Levin commit 73fadce8c80b90187a547202b981bf5852a60a73 Author: Xie He Date: Wed Sep 2 17:06:58 2020 -0700 drivers/net/wan/hdlc_fr: Add needed_headroom for PVC devices [ Upstream commit 44a049c42681de71c783d75cd6e56b4e339488b0 ] PVC devices are virtual devices in this driver stacked on top of the actual HDLC device. They are the devices normal users would use. PVC devices have two types: normal PVC devices and Ethernet-emulating PVC devices. When transmitting data with PVC devices, the ndo_start_xmit function will prepend a header of 4 or 10 bytes. Currently this driver requests this headroom to be reserved for normal PVC devices by setting their hard_header_len to 10. However, this does not work when these devices are used with AF_PACKET/RAW sockets. Also, this driver does not request this headroom for Ethernet-emulating PVC devices (but deals with this problem by reallocating the skb when needed, which is not optimal). This patch replaces hard_header_len with needed_headroom, and set needed_headroom for Ethernet-emulating PVC devices, too. This makes the driver to request headroom for all PVC devices in all cases. Cc: Krzysztof Halasa Cc: Martin Schiller Signed-off-by: Xie He Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1017b151fb4a37d48ec7abd0fbdb9285b92e5d0b Author: Naveen N. Rao Date: Wed Sep 2 14:12:46 2020 +0530 libbpf: Remove arch-specific include path in Makefile [ Upstream commit 21e9ba5373fc2cec608fd68301a1dbfd14df3172 ] Ubuntu mainline builds for ppc64le are failing with the below error (*): CALL /home/kernel/COD/linux/scripts/atomic/check-atomics.sh DESCEND bpf/resolve_btfids Auto-detecting system features: ... libelf: [ [32mon[m ] ... zlib: [ [32mon[m ] ... bpf: [ [31mOFF[m ] BPF API too old make[6]: *** [Makefile:295: bpfdep] Error 1 make[5]: *** [Makefile:54: /home/kernel/COD/linux/debian/build/build-generic/tools/bpf/resolve_btfids//libbpf.a] Error 2 make[4]: *** [Makefile:71: bpf/resolve_btfids] Error 2 make[3]: *** [/home/kernel/COD/linux/Makefile:1890: tools/bpf/resolve_btfids] Error 2 make[2]: *** [/home/kernel/COD/linux/Makefile:335: __build_one_by_one] Error 2 make[2]: Leaving directory '/home/kernel/COD/linux/debian/build/build-generic' make[1]: *** [Makefile:185: __sub-make] Error 2 make[1]: Leaving directory '/home/kernel/COD/linux' resolve_btfids needs to be build as a host binary and it needs libbpf. However, libbpf Makefile hardcodes an include path utilizing $(ARCH). This results in mixing of cross-architecture headers resulting in a build failure. The specific header include path doesn't seem necessary for a libbpf build. Hence, remove the same. (*) https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.9-rc3/ppc64el/log Reported-by: Vaidyanathan Srinivasan Signed-off-by: Naveen N. Rao Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200902084246.1513055-1-naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 9f183485e888a59260e3ea4314818be727a25a9f Author: Felix Fietkau Date: Wed Aug 12 16:49:43 2020 +0200 mt76: mt7915: use ieee80211_free_txskb to free tx skbs [ Upstream commit b4be5a53ebf478ffcfb4c98c0ccc4a8d922b9a02 ] Using dev_kfree_skb for tx skbs breaks AQL. This worked until now only by accident, because a mac80211 issue breaks AQL on drivers with firmware rate control that report the rate via ieee80211_tx_status_ext as struct rate_info. Signed-off-by: Felix Fietkau Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200812144943.91974-1-nbd@nbd.name Signed-off-by: Sasha Levin commit 057c9ed4565b42bb51a6636e9aa11963122d895a Author: Hans de Goede Date: Tue Aug 25 13:12:57 2020 +0200 vboxsf: Fix the check for the old binary mount-arguments struct [ Upstream commit 9d682ea6bcc76b8b2691c79add59f7d99c881635 ] Fix the check for the mainline vboxsf code being used with the old mount.vboxsf mount binary from the out-of-tree vboxsf version doing a comparison between signed and unsigned data types. This fixes the following smatch warnings: fs/vboxsf/super.c:390 vboxsf_parse_monolithic() warn: impossible condition '(options[1] == (255)) => ((-128)-127 == 255)' fs/vboxsf/super.c:391 vboxsf_parse_monolithic() warn: impossible condition '(options[2] == (254)) => ((-128)-127 == 254)' fs/vboxsf/super.c:392 vboxsf_parse_monolithic() warn: impossible condition '(options[3] == (253)) => ((-128)-127 == 253)' Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Hans de Goede Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 4a1db91e697a2cb2eb5061a08560f884221f915c Author: Guo Ren Date: Tue Aug 18 07:31:17 2020 +0000 clocksource/drivers/timer-gx6605s: Fixup counter reload [ Upstream commit bc6717d55d07110d8f3c6d31ec2af50c11b07091 ] When the timer counts to the upper limit, an overflow interrupt is generated, and the count is reset with the value in the TIME_INI register. But the software expects to start counting from 0 when the count overflows, so it forces TIME_INI to 0 to solve the potential interrupt storm problem. Signed-off-by: Guo Ren Tested-by: Xu Kai Cc: Daniel Lezcano Cc: Thomas Gleixner Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/1597735877-71115-1-git-send-email-guoren@kernel.org Signed-off-by: Sasha Levin commit 5d48f7b0ed06ef1610551bb1bd66c587bf4dbca4 Author: Juergen Gross Date: Wed Sep 30 11:16:14 2020 +0200 xen/events: don't use chip_data for legacy IRQs commit 0891fb39ba67bd7ae023ea0d367297ffff010781 upstream. Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.") Xen is using the chip_data pointer for storing IRQ specific data. When running as a HVM domain this can result in problems for legacy IRQs, as those might use chip_data for their own purposes. Use a local array for this purpose in case of legacy IRQs, avoiding the double use. Cc: stable@vger.kernel.org Fixes: c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.") Signed-off-by: Juergen Gross Tested-by: Stefan Bader Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20200930091614.13660-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit e99ecd62bb9c868ab81ab234d384006b04288b81 Author: Jean Delvare Date: Mon Sep 28 11:10:37 2020 +0200 drm/amdgpu: restore proper ref count in amdgpu_display_crtc_set_config commit a39d0d7bdf8c21ac7645c02e9676b5cb2b804c31 upstream. A recent attempt to fix a ref count leak in amdgpu_display_crtc_set_config() turned out to be doing too much and "fixed" an intended decrease as if it were a leak. Undo that part to restore the proper balance. This is the very nature of this function to increase or decrease the power reference count depending on the situation. Consequences of this bug is that the power reference would eventually get down to 0 while the display was still in use, resulting in that display switching off unexpectedly. Signed-off-by: Jean Delvare Fixes: e008fa6fb415 ("drm/amdgpu: fix ref count leak in amdgpu_display_crtc_set_config") Cc: stable@vger.kernel.org Cc: Navid Emamdoost Cc: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b64a43b072c76f553b2dae9f105733bb97d9bc00 Author: Kai-Heng Feng Date: Fri Sep 25 16:49:51 2020 +0800 memstick: Skip allocating card when removing host commit 62c59a8786e6bb75569cee91dab66e9da3ff4b68 upstream. After commit 6827ca573c03 ("memstick: rtsx_usb_ms: Support runtime power management"), removing module rtsx_usb_ms will be stuck. The deadlock is caused by powering on and powering off at the same time, the former one is when memstick_check() is flushed, and the later is called by memstick_remove_host(). Soe let's skip allocating card to prevent this issue. Fixes: 6827ca573c03 ("memstick: rtsx_usb_ms: Support runtime power management") Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20200925084952.13220-1-kai.heng.feng@canonical.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 13cee195a18083173c757f6af3bb23271cc22144 Author: Steven Rostedt (VMware) Date: Tue Sep 29 12:27:23 2020 -0400 tracing: Fix trace_find_next_entry() accounting of temp buffer size commit 851e6f61cd076954f9d521e0d79b173ad3a2453b upstream. The temp buffer size variable for trace_find_next_entry() was incorrectly being updated when the size did not change. The temp buffer size should only be updated when it is reallocated. This is mostly an issue when used with ftrace_dump(). That's because ftrace_dump() can not allocate a new buffer, and instead uses a temporary buffer with a fix size. But the variable that keeps track of that size is incorrectly updated with each call, and it could fall into the path that would try to reallocate the buffer and produce a warning. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1601 at kernel/trace/trace.c:3548 trace_find_next_entry+0xd0/0xe0 Modules linked in [..] CPU: 1 PID: 1601 Comm: bash Not tainted 5.9.0-rc5-test+ #521 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:trace_find_next_entry+0xd0/0xe0 Code: 40 21 00 00 4c 89 e1 31 d2 4c 89 ee 48 89 df e8 c6 9e ff ff 89 ab 54 21 00 00 5b 5d 41 5c 41 5d c3 48 63 d5 eb bf 31 c0 eb f0 <0f> 0b 48 63 d5 eb b4 66 0f 1f 84 00 00 00 00 00 53 48 8d 8f 60 21 RSP: 0018:ffff95a4f2e8bd70 EFLAGS: 00010046 RAX: ffffffff96679fc0 RBX: ffffffff97910de0 RCX: ffffffff96679fc0 RDX: ffff95a4f2e8bd98 RSI: ffff95a4ee321098 RDI: ffffffff97913000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000046 R12: ffff95a4f2e8bd98 R13: 0000000000000000 R14: ffff95a4ee321098 R15: 00000000009aa301 FS: 00007f8565484740(0000) GS:ffff95a55aa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055876bd43d90 CR3: 00000000b76e6003 CR4: 00000000001706e0 Call Trace: trace_print_lat_context+0x58/0x2d0 ? cpumask_next+0x16/0x20 print_trace_line+0x1a4/0x4f0 ftrace_dump.cold+0xad/0x12c __handle_sysrq.cold+0x51/0x126 write_sysrq_trigger+0x3f/0x4a proc_reg_write+0x53/0x80 vfs_write+0xca/0x210 ksys_write+0x70/0xf0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f8565579487 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffd40707948 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f8565579487 RDX: 0000000000000002 RSI: 000055876bd74de0 RDI: 0000000000000001 RBP: 000055876bd74de0 R08: 000000000000000a R09: 0000000000000001 R10: 000055876bdec280 R11: 0000000000000246 R12: 0000000000000002 R13: 00007f856564a500 R14: 0000000000000002 R15: 00007f856564a700 irq event stamp: 109958 ---[ end trace 7aab5b7e51484b00 ]--- Not only fix the updating of the temp buffer, but also do not free the temp buffer before a new buffer is allocated (there's no reason to not continue to use the current temp buffer if an allocation fails). Cc: stable@vger.kernel.org Fixes: 8e99cf91b99bb ("tracing: Do not allocate buffer in trace_find_next_entry() in atomic") Reported-by: Anna-Maria Behnsen Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 7f5d5928b9ccae44432e542c48e04a37c060c0b7 Author: Steven Rostedt (VMware) Date: Tue Sep 29 12:40:31 2020 -0400 ftrace: Move RCU is watching check after recursion check commit b40341fad6cc2daa195f8090fd3348f18fff640a upstream. The first thing that the ftrace function callback helper functions should do is to check for recursion. Peter Zijlstra found that when "rcu_is_watching()" had its notrace removed, it caused perf function tracing to crash. This is because the call of rcu_is_watching() is tested before function recursion is checked and and if it is traced, it will cause an infinite recursion loop. rcu_is_watching() should still stay notrace, but to prevent this should never had crashed in the first place. The recursion prevention must be the first thing done in callback functions. Link: https://lore.kernel.org/r/20200929112541.GM2628@hirez.programming.kicks-ass.net Cc: stable@vger.kernel.org Cc: Paul McKenney Fixes: c68c0fa293417 ("ftrace: Have ftrace_ops_get_func() handle RCU and PER_CPU flags too") Acked-by: Peter Zijlstra (Intel) Reported-by: Peter Zijlstra (Intel) Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 1f0038ad6eed2f7b81951342e98d83aff0618abe Author: Dmitry Baryshkov Date: Thu Sep 10 16:59:51 2020 +0300 iio: adc: qcom-spmi-adc5: fix driver name commit fdb29f4de1374483291232ae7515e5e7bb464762 upstream. Remove superfluous '.c' from qcom-spmi-adc5 device driver name. Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver") Signed-off-by: Dmitry Baryshkov Acked-by: Manivannan Sadhasivam Cc: Link: https://lore.kernel.org/r/20200910140000.324091-2-dmitry.baryshkov@linaro.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 14f6276e202ff8f1d381f9dc91402350755d6d8f Author: Jiri Kosina Date: Mon Sep 28 16:21:17 2020 -0700 Input: i8042 - add nopnp quirk for Acer Aspire 5 A515 commit 5fc27b098dafb8e30794a9db0705074c7d766179 upstream. Touchpad on this laptop is not detected properly during boot, as PNP enumerates (wrongly) AUX port as disabled on this machine. Fix that by adding this board (with admittedly quite funny DMI identifiers) to nopnp quirk list. Reported-by: Andrés Barrantes Silman Signed-off-by: Jiri Kosina Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2009252337340.3336@cbobk.fhfr.pm Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 6901d792bc35c02aa4627c1f0512974c9fd8a0e7 Author: Jean Delvare Date: Thu Sep 10 11:57:08 2020 +0200 i2c: i801: Exclude device from suspend direct complete optimization commit 845b89127bc5458d0152a4d63f165c62a22fcb70 upstream. By default, PCI drivers with runtime PM enabled will skip the calls to suspend and resume on system PM. For this driver, we don't want that, as we need to perform additional steps for system PM to work properly on all systems. So instruct the PM core to not skip these calls. Fixes: a9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM") Reported-by: Volker Rümelin Signed-off-by: Jean Delvare Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 7d29e950766327f658cb92722b9445ac3b3ae023 Author: Mark Mielke Date: Mon Sep 28 00:33:29 2020 -0400 scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername() commit bcf3a2953d36bbfb9bd44ccb3db0897d935cc485 upstream. The kernel may fail to boot or devices may fail to come up when initializing iscsi_tcp devices starting with Linux 5.8. Commit a79af8a64d39 ("[SCSI] iscsi_tcp: use iscsi_conn_get_addr_param libiscsi function") introduced getpeername() within the session spinlock. Commit 1b66d253610c ("bpf: Add get{peer, sock}name attach types for sock_addr") introduced BPF_CGROUP_RUN_SA_PROG_LOCK() within getpeername(), which acquires a mutex and when used from iscsi_tcp devices can now lead to "BUG: scheduling while atomic:" and subsequent damage. Ensure that the spinlock is released before calling getpeername() or getsockname(). sock_hold() and sock_put() are used to ensure that the socket reference is preserved until after the getpeername() or getsockname() complete. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1877345 Link: https://lkml.org/lkml/2020/7/28/1085 Link: https://lkml.org/lkml/2020/8/31/459 Link: https://lore.kernel.org/r/20200928043329.606781-1-mark.mielke@gmail.com Fixes: a79af8a64d39 ("[SCSI] iscsi_tcp: use iscsi_conn_get_addr_param libiscsi function") Fixes: 1b66d253610c ("bpf: Add get{peer, sock}name attach types for sock_addr") Cc: stable@vger.kernel.org Reported-by: Marc Dionne Tested-by: Marc Dionne Reviewed-by: Mike Christie Signed-off-by: Mark Mielke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c32f1ee1d6d08e21123e93981a2e22eb6b3555c6 Author: Dinh Nguyen Date: Mon Aug 31 15:26:57 2020 -0500 clk: socfpga: stratix10: fix the divider for the emac_ptp_free_clk commit b02cf0c4736c65c6667f396efaae6b5521e82abf upstream. The fixed divider the emac_ptp_free_clk should be 2, not 4. Fixes: 07afb8db7340 ("clk: socfpga: stratix10: add clock driver for Stratix10 platform") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20200831202657.8224-1-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a77ae2f6d900311ac96e0247f74bb7acf510a68c Author: Marek Szyprowski Date: Fri Aug 7 15:31:43 2020 +0200 clk: samsung: Keep top BPLL mux on Exynos542x enabled commit 0212a0483b0a36cc94cfab882b3edbb41fcfe1cd upstream. BPLL clock must not be disabled because it is needed for proper DRAM operation. This is normally handled by respective memory devfreq driver, but when that driver is not yet probed or its probe has been deferred the clock might get disabled what causes board hang. Fix this by calling clk_prepare_enable() directly from the clock provider driver. Cc: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200807133143.22748-1-m.szyprowski@samsung.com Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422") Signed-off-by: Sylwester Nawrocki Signed-off-by: Greg Kroah-Hartman commit 9705d89518aec66e9defe990d913cdd4814fff91 Author: Ed Wildgoose Date: Mon Sep 28 10:44:52 2020 +0100 gpio: amd-fch: correct logic of GPIO_LINE_DIRECTION commit d25e8fdebdad84219b498873300b7f11dd915b88 upstream. The original commit appears to have the logic reversed in amd_fch_gpio_get_direction. Also confirmed by observing the value of "direction" in the sys tree. Signed-off-by: Ed Wildgoose Fixes: e09d168f13f0 ("gpio: AMD G-Series PCH gpio driver") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit f67837215194d2d7b82400470255254f70f48f98 Author: dillon min Date: Thu Sep 3 15:30:21 2020 +0800 gpio: tc35894: fix up tc35894 interrupt configuration commit 214b0e1ad01abf4c1f6d8d28fa096bf167e47cef upstream. The offset of regmap is incorrect, j * 8 is move to the wrong register. for example: asume i = 0, j = 1. we want to set KPY5 as interrupt falling edge mode, regmap[0][1] should be TC3589x_GPIOIBE1 0xcd but, regmap[i] + j * 8 = TC3589x_GPIOIBE0 + 8 ,point to 0xd4, this is TC3589x_GPIOIE2 not TC3589x_GPIOIBE1. Fixes: d88b25be3584 ("gpio: Add TC35892 GPIO driver") Cc: Cc: stable@vger.kernel.org Signed-off-by: dillon min Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit baeac67ee6e29f2202eaddbec8dc23d78a8447d9 Author: Bartosz Golaszewski Date: Tue Sep 8 15:07:49 2020 +0200 gpio: mockup: fix resource leak in error path commit 1b02d9e770cd7087f34c743f85ccf5ea8372b047 upstream. If the module init function fails after creating the debugs directory, it's never removed. Add proper cleanup calls to avoid this resource leak. Fixes: 9202ba2397d1 ("gpio: mockup: implement event injecting over debugfs") Cc: Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit cb2480639590cdf6afd07f03c766ca66bcd240c9 Author: Ahmad Fatoum Date: Mon Sep 7 17:31:35 2020 +0200 gpio: siox: explicitly support only threaded irqs commit 45ccf6556720293323c20cda717756014ff63007 upstream. The gpio-siox driver uses handle_nested_irq() to implement its interrupt support. This is only capable of handling threaded irq actions. For a hardirq action it triggers a NULL pointer oops. (It calls action->thread_fn which is NULL then.) Prevent registration of a hardirq action by setting gpio_irq_chip::threaded to true. Cc: u.kleine-koenig@pengutronix.de Fixes: be8c8facc707 ("gpio: new driver to work with a 8x12 siox") Cc: stable@vger.kernel.org Signed-off-by: Ahmad Fatoum Acked-by: Uwe Kleine-König Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 5ae75e1e510db80b956d5433495ec32adf06adac Author: M. Vefa Bicakci Date: Tue Sep 22 14:07:03 2020 +0300 usbcore/driver: Accommodate usbip commit 3fce39601a1a34d940cf62858ee01ed9dac5d459 upstream. Commit 88b7381a939d ("USB: Select better matching USB drivers when available") inadvertently broke usbip functionality. The commit in question allows USB device drivers to be explicitly matched with USB devices via the use of driver-provided identifier tables and match functions, which is useful for a specialised device driver to be chosen for a device that can also be handled by another, more generic, device driver. Prior, the USB device section of usb_device_match() had an unconditional "return 1" statement, which allowed user-space to bind USB devices to the usbip_host device driver, if desired. However, the aforementioned commit changed the default/fallback return value to zero. This breaks device drivers such as usbip_host, so this commit restores the legacy behaviour, but only if a device driver does not have an id_table and a match() function. In addition, if usb_device_match is called for a device driver and device pair where the device does not match the id_table of the device driver in question, then the device driver will be disqualified for the device. This allows avoiding the default case of "return 1", which prevents undesirable probe() calls to a driver even though its id_table did not match the device. Finally, this commit changes the specialised-driver-to-generic-driver transition code so that when a device driver returns -ENODEV, a more generic device driver is only considered if the current device driver does not have an id_table and a match() function. This ensures that "generic" drivers such as usbip_host will not be considered specialised device drivers and will not cause the device to be locked in to the generic device driver, when a more specialised device driver could be tried. All of these changes restore usbip functionality without regressions, ensure that the specialised/generic device driver selection logic works as expected with the usb and apple-mfi-fastcharge drivers, and do not negatively affect the use of devices provided by dummy_hcd. Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available") Cc: # 5.8 Cc: Bastien Nocera Cc: Valentina Manea Cc: Shuah Khan Cc: Greg Kroah-Hartman Cc: Alan Stern Cc: Tested-by: Andrey Konovalov Acked-by: Shuah Khan Signed-off-by: M. Vefa Bicakci Link: https://lore.kernel.org/r/20200922110703.720960-5-m.v.b@runbox.com Signed-off-by: Greg Kroah-Hartman commit ab3edda370ee45bfaf38b1ed601029817b9c8b7f Author: M. Vefa Bicakci Date: Tue Sep 22 14:07:02 2020 +0300 usbcore/driver: Fix incorrect downcast commit 4df30e7603432704380b12fe40a604ee7f66746d upstream. This commit resolves a minor bug in the selection/discovery of more specific USB device drivers for devices that are currently bound to generic USB device drivers. The bug is related to the way a candidate USB device driver is compared against the generic USB device driver. The code in is_dev_usb_generic_driver() assumes that the device driver in question is a USB device driver by calling to_usb_device_driver(dev->driver) to downcast; however I have observed that this assumption is not always true, through code instrumentation. This commit avoids the incorrect downcast altogether by comparing the USB device's driver (i.e., dev->driver) to the generic USB device driver directly. This method was suggested by Alan Stern. This bug was found while investigating Andrey Konovalov's report indicating usbip device driver misbehaviour with the recently merged generic USB device driver selection feature. The report is linked below. Fixes: d5643d2249b2 ("USB: Fix device driver race") Cc: # 5.8 Cc: Greg Kroah-Hartman Cc: Alan Stern Cc: Bastien Nocera Cc: Shuah Khan Cc: Valentina Manea Cc: Tested-by: Andrey Konovalov Signed-off-by: M. Vefa Bicakci Link: https://lore.kernel.org/r/20200922110703.720960-4-m.v.b@runbox.com Signed-off-by: Greg Kroah-Hartman commit dc1e84d05a96a5cfe5567dfdf6cbc91535f50eaa Author: M. Vefa Bicakci Date: Tue Sep 22 14:07:01 2020 +0300 usbcore/driver: Fix specific driver selection commit aea850cd35ae3d266fe6f93fb9edb25e4a555230 upstream. This commit resolves a bug in the selection/discovery of more specific USB device drivers for devices that are currently bound to generic USB device drivers. The bug is in the logic that determines whether a device currently bound to a generic USB device driver should be re-probed by a more specific USB device driver or not. The code in __usb_bus_reprobe_drivers() used to have the following lines: if (usb_device_match_id(udev, new_udriver->id_table) == NULL && (!new_udriver->match || new_udriver->match(udev) != 0)) return 0; ret = device_reprobe(dev); As the reader will notice, the code checks whether the USB device in consideration matches the identifier table (id_table) of a specific USB device_driver (new_udriver), followed by a similar check, but this time with the USB device driver's match function. However, the match function's return value is not checked correctly. When match() returns zero, it means that the specific USB device driver is *not* applicable to the USB device in question, but the code then goes on to reprobe the device with the new USB device driver under consideration. All this to say, the logic is inverted. This bug was found by code inspection and instrumentation while investigating the root cause of the issue reported by Andrey Konovalov, where usbip took over syzkaller's virtual USB devices in an undesired manner. The report is linked below. Fixes: d5643d2249b2 ("USB: Fix device driver race") Cc: # 5.8 Cc: Greg Kroah-Hartman Cc: Alan Stern Cc: Bastien Nocera Cc: Shuah Khan Cc: Valentina Manea Cc: Tested-by: Andrey Konovalov Signed-off-by: M. Vefa Bicakci Link: https://lore.kernel.org/r/20200922110703.720960-3-m.v.b@runbox.com Signed-off-by: Greg Kroah-Hartman commit 36ec30f02a001c4d692a9be23d6fda0c684996cc Author: M. Vefa Bicakci Date: Tue Sep 22 14:07:00 2020 +0300 Revert "usbip: Implement a match function to fix usbip" commit d6407613c1e2ef90213dee388aa16b6e1bd08cbc upstream. This commit reverts commit 7a2f2974f265 ("usbip: Implement a match function to fix usbip"). In summary, commit d5643d2249b2 ("USB: Fix device driver race") inadvertently broke usbip functionality, which I resolved in an incorrect manner by introducing a match function to usbip, usbip_match(), that unconditionally returns true. However, the usbip_match function, as is, causes usbip to take over virtual devices used by syzkaller for USB fuzzing, which is a regression reported by Andrey Konovalov. Furthermore, in conjunction with the fix of another bug, handled by another patch titled "usbcore/driver: Fix specific driver selection" in this patch set, the usbip_match function causes unexpected USB subsystem behaviour when the usbip_host driver is loaded. The unexpected behaviour can be qualified as follows: - If commit 41160802ab8e ("USB: Simplify USB ID table match") is included in the kernel, then all USB devices are bound to the usbip_host driver, which appears to the user as if all USB devices were disconnected. - If the same commit (41160802ab8e) is not in the kernel (as is the case with v5.8.10) then all USB devices are re-probed and re-bound to their original device drivers, which appears to the user as a disconnection and re-connection of USB devices. Please note that this commit will make usbip non-operational again, until yet another patch in this patch set is merged, titled "usbcore/driver: Accommodate usbip". Cc: # 5.8: 41160802ab8e: USB: Simplify USB ID table match Cc: # 5.8 Cc: Bastien Nocera Cc: Valentina Manea Cc: Shuah Khan Cc: Greg Kroah-Hartman Cc: Alan Stern Cc: Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Acked-by: Shuah Khan Signed-off-by: M. Vefa Bicakci Link: https://lore.kernel.org/r/20200922110703.720960-2-m.v.b@runbox.com Signed-off-by: Greg Kroah-Hartman commit 9c69e3a769db59b36a4eb7d4fb30c33763b773c0 Author: Bryan O'Donoghue Date: Sun Sep 20 18:01:58 2020 +0100 USB: gadget: f_ncm: Fix NDP16 datagram validation commit 2b405533c2560d7878199c57d95a39151351df72 upstream. commit 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") adds important bounds checking however it unfortunately also introduces a bug with respect to section 3.3.1 of the NCM specification. wDatagramIndex[1] : "Byte index, in little endian, of the second datagram described by this NDP16. If zero, then this marks the end of the sequence of datagrams in this NDP16." wDatagramLength[1]: "Byte length, in little endian, of the second datagram described by this NDP16. If zero, then this marks the end of the sequence of datagrams in this NDP16." wDatagramIndex[1] and wDatagramLength[1] respectively then may be zero but that does not mean we should throw away the data referenced by wDatagramIndex[0] and wDatagramLength[0] as is currently the case. Breaking the loop on (index2 == 0 || dg_len2 == 0) should come at the end as was previously the case and checks for index2 and dg_len2 should be removed since zero is valid. I'm not sure how much testing the above patch received but for me right now after enumeration ping doesn't work. Reverting the commit restores ping, scp, etc. The extra validation associated with wDatagramIndex[0] and wDatagramLength[0] appears to be valid so, this change removes the incorrect restriction on wDatagramIndex[1] and wDatagramLength[1] restoring data processing between host and device. Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") Cc: Ilja Van Sprundel Cc: Brooke Basile Cc: stable Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20200920170158.1217068-1-bryan.odonoghue@linaro.org Signed-off-by: Greg Kroah-Hartman commit 26be1c145cfe4af73c8b4db62fc6c508ab34d7ce Author: Hans de Goede Date: Sun Sep 27 12:48:21 2020 +0200 mmc: sdhci: Workaround broken command queuing on Intel GLK based IRBIS models commit afd7f30886b0b445a4240a99020458a9772f2b89 upstream. Commit bedf9fc01ff1 ("mmc: sdhci: Workaround broken command queuing on Intel GLK"), disabled command-queuing on Intel GLK based LENOVO models because of it being broken due to what is believed to be a bug in the BIOS. It seems that the BIOS of some IRBIS models, including the IRBIS NB111 model has the same issue, so disable command queuing there too. Fixes: bedf9fc01ff1 ("mmc: sdhci: Workaround broken command queuing on Intel GLK") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209397 Reported-and-tested-by: RussianNeuroMancer Signed-off-by: Hans de Goede Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20200927104821.5676-1-hdegoede@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a8183e677fc1aa80064e9e8f4081650d03984968 Author: Filipe Manana Date: Wed Sep 23 15:30:16 2020 +0100 btrfs: fix filesystem corruption after a device replace commit 4c8f353272dd1262013873990c0fafd0e3c8f274 upstream. We use a device's allocation state tree to track ranges in a device used for allocated chunks, and we set ranges in this tree when allocating a new chunk. However after a device replace operation, we were not setting the allocated ranges in the new device's allocation state tree, so that tree is empty after a device replace. This means that a fitrim operation after a device replace will trim the device ranges that have allocated chunks and extents, as we trim every range for which there is not a range marked in the device's allocation state tree. It is also important during chunk allocation, since the device's allocation state is used to determine if a range is already allocated when allocating a new chunk. This is trivial to reproduce and the following script triggers the bug: $ cat reproducer.sh #!/bin/bash DEV1="/dev/sdg" DEV2="/dev/sdh" DEV3="/dev/sdi" wipefs -a $DEV1 $DEV2 $DEV3 &> /dev/null # Create a raid1 test fs on 2 devices. mkfs.btrfs -f -m raid1 -d raid1 $DEV1 $DEV2 > /dev/null mount $DEV1 /mnt/btrfs xfs_io -f -c "pwrite -S 0xab 0 10M" /mnt/btrfs/foo echo "Starting to replace $DEV1 with $DEV3" btrfs replace start -B $DEV1 $DEV3 /mnt/btrfs echo echo "Running fstrim" fstrim /mnt/btrfs echo echo "Unmounting filesystem" umount /mnt/btrfs echo "Mounting filesystem in degraded mode using $DEV3 only" wipefs -a $DEV1 $DEV2 &> /dev/null mount -o degraded $DEV3 /mnt/btrfs if [ $? -ne 0 ]; then dmesg | tail echo echo "Failed to mount in degraded mode" exit 1 fi echo echo "File foo data (expected all bytes = 0xab):" od -A d -t x1 /mnt/btrfs/foo umount /mnt/btrfs When running the reproducer: $ ./replace-test.sh wrote 10485760/10485760 bytes at offset 0 10 MiB, 2560 ops; 0.0901 sec (110.877 MiB/sec and 28384.5216 ops/sec) Starting to replace /dev/sdg with /dev/sdi Running fstrim Unmounting filesystem Mounting filesystem in degraded mode using /dev/sdi only mount: /mnt/btrfs: wrong fs type, bad option, bad superblock on /dev/sdi, missing codepage or helper program, or other error. [19581.748641] BTRFS info (device sdg): dev_replace from /dev/sdg (devid 1) to /dev/sdi started [19581.803842] BTRFS info (device sdg): dev_replace from /dev/sdg (devid 1) to /dev/sdi finished [19582.208293] BTRFS info (device sdi): allowing degraded mounts [19582.208298] BTRFS info (device sdi): disk space caching is enabled [19582.208301] BTRFS info (device sdi): has skinny extents [19582.212853] BTRFS warning (device sdi): devid 2 uuid 1f731f47-e1bb-4f00-bfbb-9e5a0cb4ba9f is missing [19582.213904] btree_readpage_end_io_hook: 25839 callbacks suppressed [19582.213907] BTRFS error (device sdi): bad tree block start, want 30490624 have 0 [19582.214780] BTRFS warning (device sdi): failed to read root (objectid=7): -5 [19582.231576] BTRFS error (device sdi): open_ctree failed Failed to mount in degraded mode So fix by setting all allocated ranges in the replace target device when the replace operation is finishing, when we are holding the chunk mutex and we can not race with new chunk allocations. A test case for fstests follows soon. Fixes: 1c11b63eff2a67 ("btrfs: replace pending/pinned chunks lists with io tree") CC: stable@vger.kernel.org # 5.2+ Reviewed-by: Nikolay Borisov Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f2a5cb2f24ae3e89441314bb389831ed7d29ee84 Author: Jens Axboe Date: Mon Sep 28 08:38:54 2020 -0600 io_uring: always delete double poll wait entry on match commit 8706e04ed7d6c95004d42b22a4db97d5b2eb73b2 upstream. syzbot reports a crash with tty polling, which is using the double poll handling: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] CPU: 0 PID: 6874 Comm: syz-executor749 Not tainted 5.9.0-rc6-next-20200924-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:io_poll_get_single fs/io_uring.c:4778 [inline] RIP: 0010:io_poll_double_wake+0x51/0x510 fs/io_uring.c:4845 Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 9e 03 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 48 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 63 03 00 00 0f b6 6b 48 bf 06 00 00 RSP: 0018:ffffc90001c1fb70 EFLAGS: 00010006 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000004 RDX: 0000000000000009 RSI: ffffffff81d9b3ad RDI: 0000000000000048 RBP: dffffc0000000000 R08: ffff8880a3cac798 R09: ffffc90001c1fc60 R10: fffff52000383f73 R11: 0000000000000000 R12: 0000000000000004 R13: ffff8880a3cac798 R14: ffff8880a3cac7a0 R15: 0000000000000004 FS: 0000000001f98880(0000) GS:ffff8880ae400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f18886916c0 CR3: 0000000094c5a000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __wake_up_common+0x147/0x650 kernel/sched/wait.c:93 __wake_up_common_lock+0xd0/0x130 kernel/sched/wait.c:123 tty_ldisc_hangup+0x1cf/0x680 drivers/tty/tty_ldisc.c:735 __tty_hangup.part.0+0x403/0x870 drivers/tty/tty_io.c:625 __tty_hangup drivers/tty/tty_io.c:575 [inline] tty_vhangup+0x1d/0x30 drivers/tty/tty_io.c:698 pty_close+0x3f5/0x550 drivers/tty/pty.c:79 tty_release+0x455/0xf60 drivers/tty/tty_io.c:1679 __fput+0x285/0x920 fs/file_table.c:281 task_work_run+0xdd/0x190 kernel/task_work.c:141 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_user_mode_loop kernel/entry/common.c:165 [inline] exit_to_user_mode_prepare+0x1e2/0x1f0 kernel/entry/common.c:192 syscall_exit_to_user_mode+0x7a/0x2c0 kernel/entry/common.c:267 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x401210 which is due to a failure in removing the double poll wait entry if we hit a wakeup match. This can cause multiple invocations of the wakeup, which isn't safe. Cc: stable@vger.kernel.org # v5.8 Reported-by: syzbot+81b3883093f772addf6d@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman