commit 1cd6e30b83d741562b55bf5b7763b1238a91150c Author: Greg Kroah-Hartman Date: Sun Aug 8 09:05:24 2021 +0200 Linux 5.10.57 Link: https://lore.kernel.org/r/20210806081113.126861800@linuxfoundation.org Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum Tested-by: Salvatore Bonaccorso Tested-by: Sudip Mukherjee Tested-by: Linux Kernel Functional Testing Tested-by: Aakash Hemadri Signed-off-by: Greg Kroah-Hartman commit 9c645a020bab2ea91e9fab46d0c5a11810dc4b95 Author: Guenter Roeck Date: Sun Aug 1 20:00:23 2021 -0700 spi: mediatek: Fix fifo transfer commit 0d5c3954b35eddff0da0436c31e8d721eceb7dc2 upstream. Commit 3a70dd2d0503 ("spi: mediatek: fix fifo rx mode") claims that fifo RX mode was never handled, and adds the presumably missing code to the FIFO transfer function. However, the claim that receive data was not handled is incorrect. It was handled as part of interrupt handling after the transfer was complete. The code added with the above mentioned commit reads data from the receive FIFO before the transfer is started, which is wrong. This results in an actual transfer error on a Hayato Chromebook. Remove the code trying to handle receive data before the transfer is started to fix the problem. Fixes: 3a70dd2d0503 ("spi: mediatek: fix fifo rx mode") Cc: Peter Hess Cc: Frank Wunderlich Cc: Tzung-Bi Shih Cc: Hsin-Yi Wang Signed-off-by: Guenter Roeck Tested-by: Hsin-Yi Wang Tested-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20210802030023.1748777-1-linux@roeck-us.net Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7254e2d9eb416fdfd57473c7e1d6393cdb1321a1 Author: Andrei Matei Date: Wed Aug 4 20:09:17 2021 +0300 selftest/bpf: Verifier tests for var-off access commit 7a22930c4179b51352f2ec9feb35167cbe79afd9 upstream Add tests for the new functionality - reading and writing to the stack through a variable-offset pointer. Signed-off-by: Andrei Matei Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210207011027.676572-4-andreimatei1@gmail.com Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 30ea1c535291e88e41413464277fcf98a95cf8c6 Author: Daniel Borkmann Date: Wed Aug 4 20:09:16 2021 +0300 bpf, selftests: Adjust few selftest outcomes wrt unreachable code commit 973377ffe8148180b2651825b92ae91988141b05 upstream In almost all cases from test_verifier that have been changed in here, we've had an unreachable path with a load from a register which has an invalid address on purpose. This was basically to make sure that we never walk this path and to have the verifier complain if it would otherwise. Change it to match on the right error for unprivileged given we now test these paths under speculative execution. There's one case where we match on exact # of insns_processed. Due to the extra path, this will of course mismatch on unprivileged. Thus, restrict the test->insn_processed check to privileged-only. In one other case, we result in a 'pointer comparison prohibited' error. This is similarly due to verifying an 'invalid' branch where we end up with a value pointer on one side of the comparison. Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 98bf2906d3beabb5ec817b6f5b798722c6c7cf94 Author: Daniel Borkmann Date: Wed Aug 4 20:09:15 2021 +0300 bpf: Update selftests to reflect new error states commit d7a5091351756d0ae8e63134313c455624e36a13 upstream Update various selftest error messages: * The 'Rx tried to sub from different maps, paths, or prohibited types' is reworked into more specific/differentiated error messages for better guidance. * The change into 'value -4294967168 makes map_value pointer be out of bounds' is due to moving the mixed bounds check into the speculation handling and thus occuring slightly later than above mentioned sanity check. * The change into 'math between map_value pointer and register with unbounded min value' is similarly due to register sanity check coming before the mixed bounds check. * The case of 'map access: known scalar += value_ptr from different maps' now loads fine given masks are the same from the different paths (despite max map value size being different). Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 360e5b7af65313c19dce7fa49e4ec4e8f100916a Author: Daniel Borkmann Date: Wed Aug 4 20:09:14 2021 +0300 bpf, selftests: Adjust few selftest result_unpriv outcomes commit 1bad6fd52be4ce12d207e2820ceb0f29ab31fc53 upstream Given we don't need to simulate the speculative domain for registers with immediates anymore since the verifier uses direct imm-based rewrites instead of having to mask, we can also lift a few cases that were previously rejected. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 5abcd138cbd82587b4f99f40a89e8db09ac2aa90 Author: Andrei Matei Date: Wed Aug 4 20:09:13 2021 +0300 selftest/bpf: Adjust expected verifier errors commit a680cb3d8e3f4f84205720b90c926579d04eedb6 upstream The verifier errors around stack accesses have changed slightly in the previous commit (generally for the better). Signed-off-by: Andrei Matei Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210207011027.676572-3-andreimatei1@gmail.com Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 83bbf953f66c10494666d38d5159bd17969ab9d7 Author: Yonghong Song Date: Wed Aug 4 20:09:12 2021 +0300 selftests/bpf: Add a test for ptr_to_map_value on stack for helper access commit b4b638c36b7e7acd847b9c4b9c80f268e45ea30c upstream Change bpf_iter_task.c such that pointer to map_value may appear on the stack for bpf_seq_printf() to access. Without previous verifier patch, the bpf_iter test will fail. Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20201210013350.943985-1-yhs@fb.com Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit e2b7a4ccbf7cc7c0ed98d1fb02b4f860f2e14814 Author: Greg Kroah-Hartman Date: Fri Aug 6 08:28:48 2021 +0200 Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout" This reverts commit 39ed17de8c6ff54c7ed4605a4a8e04a2e2f0b82e which is commit cb011044e34c293e139570ce5c01aed66a34345c upstream. It is reported to cause problems with systems and probably should not have been backported in the first place :( Link: https://lore.kernel.org/r/20210803165108.4154cd52@endymion Reported-by: Jean Delvare Cc: Jan Kiszka Cc: Guenter Roeck Cc: Guenter Roeck Cc: Wim Van Sebroeck Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1b1a00b13c34b0dd1ef3de6eed25f7cb1c2dfd35 Author: Cristian Marussi Date: Tue Jun 8 11:30:56 2021 +0100 firmware: arm_scmi: Add delayed response status check commit f1748b1ee1fa0fd1a074504045b530b62f949188 upstream. A successfully received delayed response could anyway report a failure at the protocol layer in the message status field. Add a check also for this error condition. Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit 93ef561406a712b32e9a2203b406877081fa0df7 Author: Sudeep Holla Date: Thu Jun 24 10:50:59 2021 +0100 firmware: arm_scmi: Ensure drivers provide a probe function commit 5e469dac326555d2038d199a6329458cc82a34e5 upstream. The bus probe callback calls the driver callback without further checking. Better be safe than sorry and refuse registration of a driver without a probe function to prevent a NULL pointer exception. Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices") Reported-by: Uwe Kleine-König Tested-by: Cristian Marussi Reviewed-by: Cristian Marussi Acked-by: Uwe Kleine-König Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit 1812895f17e18fc2a2ce199df99bdcad2ef883f0 Author: Greg Kroah-Hartman Date: Thu Aug 5 20:58:57 2021 +0200 Revert "Bluetooth: Shutdown controller after workqueues are flushed or cancelled" This reverts commit 60789afc02f592b8d91217b60930e7a76271ae07 which is commit 0ea9fd001a14ebc294f112b0361a4e601551d508 upstream. It has been reported to have problems: https://lore.kernel.org/linux-bluetooth/8735ryk0o7.fsf@baylibre.com/ Reported-by: Guenter Roeck Cc: Kai-Heng Feng Cc: Marcel Holtmann Cc: Sasha Levin Link: https://lore.kernel.org/r/efee3a58-a4d2-af22-0931-e81b877ab539@roeck-us.net Signed-off-by: Greg Kroah-Hartman commit cae3fa3d8165761f3000f523b11cfa1cd35206bc Author: Linus Torvalds Date: Sat Jul 24 15:25:54 2021 -0700 ACPI: fix NULL pointer dereference [ Upstream commit fc68f42aa737dc15e7665a4101d4168aadb8e4c4 ] Commit 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer that was possibly NULL. That fails miserably, because that helper inline function is not set up to handle that case. Just make acpi_dev_put() silently accept a NULL pointer, rather than calling down to put_device() with an invalid offset off that NULL pointer. Link: https://lore.kernel.org/lkml/a607c149-6bf6-0fd0-0e31-100378504da2@kernel.dk/ Reported-and-tested-by: Jens Axboe Tested-by: Daniel Scally Cc: Andy Shevchenko Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 98b070694f4570908a0e8ea5afb68d81b0aa2051 Author: Nicholas Kazlauskas Date: Wed Jul 7 13:19:14 2021 -0400 drm/amd/display: Fix max vstartup calculation for modes with borders [ Upstream commit d7940911fc0754d99b208f0e3098762d39f403a0 ] [Why] Vertical and horizontal borders in timings are treated as increasing the active area - vblank and hblank actually shrink. Our input into DML does not include these borders so it incorrectly assumes it has more time than available for vstartup and tmdl calculations for some modes with borders. An example of such a timing would be 640x480@72Hz: h_total: 832 h_border_left: 8 h_addressable: 640 h_border_right: 8 h_front_porch: 16 h_sync_width: 40 v_total: 520 v_border_top: 8 v_addressable: 480 v_border_bottom: 8 v_front_porch: 1 v_sync_width: 3 pix_clk_100hz: 315000 [How] Include borders as part of destination vactive/hactive. This change DCN20+ so it has wide impact, but the destination vactive and hactive are only really used for vstartup calculation anyway. Most modes do not have vertical or horizontal borders. Reviewed-by: Dmytro Laktyushkin Acked-by: Rodrigo Siqueira Signed-off-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f9d875c8c92f1bdaeeb3eeccbf8402974f20cd31 Author: Victor Lu Date: Thu Jun 24 11:05:42 2021 -0400 drm/amd/display: Fix comparison error in dcn21 DML [ Upstream commit ec3102dc6b36c692104c4a0546d4119de59a3bc1 ] [why] A comparison error made it possible to not iterate through all the specified prefetch modes. [how] Correct "<" to "<=" Reviewed-by: Dmytro Laktyushkin Reviewed-by: Yongqiang Sun Acked-by: Rodrigo Siqueira Signed-off-by: Victor Lu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 91865b458eddf61c447e55226d856bcf25f0c607 Author: Keith Busch Date: Mon Jul 19 09:44:39 2021 -0700 nvme: fix nvme_setup_command metadata trace event [ Upstream commit 234211b8dd161fa25f192c78d5a8d2dd6bf920a0 ] The metadata address is set after the trace event, so the trace is not capturing anything useful. Rather than logging the memory address, it's useful to know if the command carries a metadata payload, so change the trace event to log that true/false state instead. Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 06a9092f6647e180bd738f6a862235de9b0adf56 Author: Borislav Petkov Date: Tue Jul 20 09:28:09 2021 +0200 efi/mokvar: Reserve the table only if it is in boot services data [ Upstream commit 47e1e233e9d822dfda068383fb9a616451bda703 ] One of the SUSE QA tests triggered: localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000 which comes from x86's version of efi_arch_mem_reserve() trying to reserve a memory region. Usually, that function expects EFI_BOOT_SERVICES_DATA memory descriptors but the above case is for the MOKvar table which is allocated in the EFI shim as runtime services. That lead to a fix changing the allocation of that table to boot services. However, that fix broke booting SEV guests with that shim leading to this kernel fix 8d651ee9c71b ("x86/ioremap: Map EFI-reserved memory as encrypted for SEV") which extended the ioremap hint to map reserved EFI boot services as decrypted too. However, all that wasn't needed, IMO, because that error message in efi_arch_mem_reserve() was innocuous in this case - if the MOKvar table is not in boot services, then it doesn't need to be reserved in the first place because it is, well, in runtime services which *should* be reserved anyway. So do that reservation for the MOKvar table only if it is allocated in boot services data. I couldn't find any requirement about where that table should be allocated in, unlike the ESRT which allocation is mandated to be done in boot services data by the UEFI spec. Signed-off-by: Borislav Petkov Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 27ff30c8b3f3a82fa6a766f0be517206889f2c09 Author: Peter Ujfalusi Date: Sat Jul 17 15:28:19 2021 +0300 ASoC: ti: j721e-evm: Check for not initialized parent_clk_id [ Upstream commit 82d28b67f780910f816fe1cfb0f676fc38c4cbb3 ] During probe the parent_clk_id is set to -1 which should not be used to array index within hsdiv_rates[]. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210717122820.1467-3-peter.ujfalusi@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a00bcc5298beeceae18b0a84d267c72354c19fb5 Author: Peter Ujfalusi Date: Sat Jul 17 15:28:18 2021 +0300 ASoC: ti: j721e-evm: Fix unbalanced domain activity tracking during startup [ Upstream commit 78d2a05ef22e7b5863b01e073dd6a06b3979bb00 ] In case of an error within j721e_audio_startup() the domain->active must be decremented to avoid unbalanced counter. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210717122820.1467-2-peter.ujfalusi@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e8b287e783811959ea7e5b6ac7841ff7e8180a55 Author: Pravin B Shelar Date: Thu Jul 15 16:59:00 2021 -0700 net: Fix zero-copy head len calculation. [ Upstream commit a17ad0961706244dce48ec941f7e476a38c0e727 ] In some cases skb head could be locked and entire header data is pulled from skb. When skb_zerocopy() called in such cases, following BUG is triggered. This patch fixes it by copying entire skb in such cases. This could be optimized incase this is performance bottleneck. ---8<--- kernel BUG at net/core/skbuff.c:2961! invalid opcode: 0000 [#1] SMP PTI CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 5.4.0-77-generic #86-Ubuntu Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:skb_zerocopy+0x37a/0x3a0 RSP: 0018:ffffbcc70013ca38 EFLAGS: 00010246 Call Trace: queue_userspace_packet+0x2af/0x5e0 [openvswitch] ovs_dp_upcall+0x3d/0x60 [openvswitch] ovs_dp_process_packet+0x125/0x150 [openvswitch] ovs_vport_receive+0x77/0xd0 [openvswitch] netdev_port_receive+0x87/0x130 [openvswitch] netdev_frame_hook+0x4b/0x60 [openvswitch] __netif_receive_skb_core+0x2b4/0xc90 __netif_receive_skb_one_core+0x3f/0xa0 __netif_receive_skb+0x18/0x60 process_backlog+0xa9/0x160 net_rx_action+0x142/0x390 __do_softirq+0xe1/0x2d6 irq_exit+0xae/0xb0 do_IRQ+0x5a/0xf0 common_interrupt+0xf/0xf Code that triggered BUG: int skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) { int i, j = 0; int plen = 0; /* length of skb->head fragment */ int ret; struct page *page; unsigned int offset; BUG_ON(!from->head_frag && !hlen); Signed-off-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c6bdf7d97d5fd4101c752d4b81a441d6cd43851a Author: Oder Chiou Date: Fri Jul 16 16:58:53 2021 +0800 ASoC: rt5682: Fix the issue of garbled recording after powerd_dbus_suspend [ Upstream commit 6a503e1c455316fd0bfd8188c0a62cce7c5525ca ] While using the DMIC recording, the garbled data will be captured by the DMIC. It is caused by the critical power of PLL closed in the jack detect function. Signed-off-by: Oder Chiou Link: https://lore.kernel.org/r/20210716085853.20170-1-oder_chiou@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 74b53ee4b89ea7d3553652c78ba49f5a4e523595 Author: Jia He Date: Thu Jul 15 16:08:21 2021 +0800 qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union() [ Upstream commit 6206b7981a36476f4695d661ae139f7db36a802d ] Liajian reported a bug_on hit on a ThunderX2 arm64 server with FastLinQ QL41000 ethernet controller: BUG: scheduling while atomic: kworker/0:4/531/0x00000200 [qed_probe:488()]hw prepare failed kernel BUG at mm/vmalloc.c:2355! Internal error: Oops - BUG: 0 [#1] SMP CPU: 0 PID: 531 Comm: kworker/0:4 Tainted: G W 5.4.0-77-generic #86-Ubuntu pstate: 00400009 (nzcv daif +PAN -UAO) Call trace: vunmap+0x4c/0x50 iounmap+0x48/0x58 qed_free_pci+0x60/0x80 [qed] qed_probe+0x35c/0x688 [qed] __qede_probe+0x88/0x5c8 [qede] qede_probe+0x60/0xe0 [qede] local_pci_probe+0x48/0xa0 work_for_cpu_fn+0x24/0x38 process_one_work+0x1d0/0x468 worker_thread+0x238/0x4e0 kthread+0xf0/0x118 ret_from_fork+0x10/0x18 In this case, qed_hw_prepare() returns error due to hw/fw error, but in theory work queue should be in process context instead of interrupt. The root cause might be the unpaired spin_{un}lock_bh() in _qed_mcp_cmd_and_union(), which causes botton half is disabled incorrectly. Reported-by: Lijian Zhang Signed-off-by: Jia He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6a2ff040b5c80658d3a7032defc8270ea1bd49b Author: Takashi Iwai Date: Wed Jul 14 19:00:21 2021 +0200 r8152: Fix potential PM refcount imbalance [ Upstream commit 9c23aa51477a37f8b56c3c40192248db0663c196 ] rtl8152_close() takes the refcount via usb_autopm_get_interface() but it doesn't release when RTL8152_UNPLUG test hits. This may lead to the imbalance of PM refcount. This patch addresses it. Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 Signed-off-by: Takashi Iwai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c98a7916cd37ce2e8fe7a36321d9c2314a4f26c4 Author: Kyle Russell Date: Mon Jun 21 21:09:41 2021 -0400 ASoC: tlv320aic31xx: fix reversed bclk/wclk master bits [ Upstream commit 9cf76a72af6ab81030dea6481b1d7bdd814fbdaf ] These are backwards from Table 7-71 of the TLV320AIC3100 spec [1]. This was broken in 12eb4d66ba2e when BCLK_MASTER and WCLK_MASTER were converted from 0x08 and 0x04 to BIT(2) and BIT(3), respectively. -#define AIC31XX_BCLK_MASTER 0x08 -#define AIC31XX_WCLK_MASTER 0x04 +#define AIC31XX_BCLK_MASTER BIT(2) +#define AIC31XX_WCLK_MASTER BIT(3) Probably just a typo since the defines were not listed in bit order. [1] https://www.ti.com/lit/gpn/tlv320aic3100 Signed-off-by: Kyle Russell Link: https://lore.kernel.org/r/20210622010941.241386-1-bkylerussell@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 03258515c9eb305954ffaf4cfd8b506311511d94 Author: Alain Volmat Date: Wed Jun 30 10:45:19 2021 +0200 spi: stm32h7: fix full duplex irq handler handling [ Upstream commit e4a5c19888a5f8a9390860ca493e643be58c8791 ] In case of Full-Duplex mode, DXP flag is set when RXP and TXP flags are set. But to avoid 2 different handlings, just add TXP and RXP flag in the mask instead of DXP, and then keep the initial handling of TXP and RXP events. Also rephrase comment about EOTIE which is one of the interrupt enable bits. It is not triggered by any event. Signed-off-by: Amelie Delaunay Signed-off-by: Alain Volmat Reviewed-by: Amelie Delaunay Link: https://lore.kernel.org/r/1625042723-661-3-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cfb8173a23cf2942a54cb57351b961032b77eb5b Author: Axel Lin Date: Sun Jun 27 16:04:18 2021 +0800 regulator: rt5033: Fix n_voltages settings for BUCK and LDO [ Upstream commit 6549c46af8551b346bcc0b9043f93848319acd5c ] For linear regulators, the n_voltages should be (max - min) / step + 1. Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f. If value is from 20 to 31, the voltage will all be fixed to 3V. And LDO also, just vout range is different from 1.2v to 3v, step is the same. If value is from 18 to 31, the voltage will also be fixed to 3v. Signed-off-by: Axel Lin Reviewed-by: ChiYuan Huang Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 81dc9a4868a912d1c3fab09cd8945be345153734 Author: ChiYuan Huang Date: Sat Jun 26 23:58:32 2021 +0800 regulator: rtmv20: Fix wrong mask for strobe-polarity-high [ Upstream commit 2b6a761be079f9fa8abf3157b5679a6f38885db4 ] Fix wrong mask for strobe-polarity-high. Signed-off-by: ChiYuan Huang In-reply-to: Reviewed-by: Axel Lin Link: https://lore.kernel.org/r/1624723112-26653-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9e55b9278c47ded8508fbb436a8a7e9148e4faed Author: Filipe Manana Date: Tue Jul 27 11:24:43 2021 +0100 btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction [ Upstream commit ecc64fab7d49c678e70bd4c35fe64d2ab3e3d212 ] When checking if we need to log the new name of a renamed inode, we are checking if the inode and its parent inode have been logged before, and if not we don't log the new name. The check however is buggy, as it directly compares the logged_trans field of the inodes versus the ID of the current transaction. The problem is that logged_trans is a transient field, only stored in memory and never persisted in the inode item, so if an inode was logged before, evicted and reloaded, its logged_trans field is set to a value of 0, meaning the check will return false and the new name of the renamed inode is not logged. If the old parent directory was previously fsynced and we deleted the logged directory entries corresponding to the old name, we end up with a log that when replayed will delete the renamed inode. The following example triggers the problem: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/A $ mkdir /mnt/B $ echo -n "hello world" > /mnt/A/foo $ sync # Add some new file to A and fsync directory A. $ touch /mnt/A/bar $ xfs_io -c "fsync" /mnt/A # Now trigger inode eviction. We are only interested in triggering # eviction for the inode of directory A. $ echo 2 > /proc/sys/vm/drop_caches # Move foo from directory A to directory B. # This deletes the directory entries for foo in A from the log, and # does not add the new name for foo in directory B to the log, because # logged_trans of A is 0, which is less than the current transaction ID. $ mv /mnt/A/foo /mnt/B/foo # Now make an fsync to anything except A, B or any file inside them, # like for example create a file at the root directory and fsync this # new file. This syncs the log that contains all the changes done by # previous rename operation. $ touch /mnt/baz $ xfs_io -c "fsync" /mnt/baz # Mount the filesystem and replay the log. $ mount /dev/sdc /mnt # Check the filesystem content. $ ls -1R /mnt /mnt/: A B baz /mnt/A: bar /mnt/B: $ # File foo is gone, it's neither in A/ nor in B/. Fix this by using the inode_logged() helper at btrfs_log_new_name(), which safely checks if an inode was logged before in the current transaction. A test case for fstests will follow soon. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e2419c570986fe374b01a6db4ddd7a3b2483ab49 Author: Filipe Manana Date: Wed Nov 25 12:19:23 2020 +0000 btrfs: fix race causing unnecessary inode logging during link and rename [ Upstream commit de53d892e5c51dfa0a158e812575a75a6c991f39 ] When we are doing a rename or a link operation for an inode that was logged in the previous transaction and that transaction is still committing, we have a time window where we incorrectly consider that the inode was logged previously in the current transaction and therefore decide to log it to update it in the log. The following steps give an example on how this happens during a link operation: 1) Inode X is logged in transaction 1000, so its logged_trans field is set to 1000; 2) Task A starts to commit transaction 1000; 3) The state of transaction 1000 is changed to TRANS_STATE_UNBLOCKED; 4) Task B starts a link operation for inode X, and as a consequence it starts transaction 1001; 5) Task A is still committing transaction 1000, therefore the value stored at fs_info->last_trans_committed is still 999; 6) Task B calls btrfs_log_new_name(), it reads a value of 999 from fs_info->last_trans_committed and because the logged_trans field of inode X has a value of 1000, the function does not return immediately, instead it proceeds to logging the inode, which should not happen because the inode was logged in the previous transaction (1000) and not in the current one (1001). This is not a functional problem, just wasted time and space logging an inode that does not need to be logged, contributing to higher latency for link and rename operations. So fix this by comparing the inodes' logged_trans field with the generation of the current transaction instead of comparing with the value stored in fs_info->last_trans_committed. This case is often hit when running dbench for a long enough duration, as it does lots of rename operations. This patch belongs to a patch set that is comprised of the following patches: btrfs: fix race causing unnecessary inode logging during link and rename btrfs: fix race that results in logging old extents during a fast fsync btrfs: fix race that causes unnecessary logging of ancestor inodes btrfs: fix race that makes inode logging fallback to transaction commit btrfs: fix race leading to unnecessary transaction commit when logging inode btrfs: do not block inode logging for so long during transaction commit Performance results are mentioned in the change log of the last patch. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 118b070bf415eb6c0fa39e5fa1b1ef6b83e80cee Author: Jason Ekstrand Date: Mon Aug 2 13:48:02 2021 -0500 Revert "drm/i915: Propagate errors on awaiting already signaled fences" commit 3761baae908a7b5012be08d70fa553cc2eb82305 upstream. This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here. For backporters: Please note that you _must_ have a backport of https://lore.kernel.org/dri-devel/20210602164149.391653-2-jason@jlekstrand.net/ for otherwise backporting just this patch opens up a security bug. v2: Augment commit message. Also restore Jason's sob that I accidentally lost. v3: Add a note for backporters Signed-off-by: Jason Ekstrand Reported-by: Marcin Slusarz Cc: # v5.6+ Cc: Jason Ekstrand Cc: Marcin Slusarz Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Acked-by: Daniel Vetter Reviewed-by: Jon Bloomfield Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-3-jason@jlekstrand.net (cherry picked from commit 93a2711cddd5760e2f0f901817d71c93183c3b87) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 6976f3cf34a1a8b791c048bbaa411ebfe48666b1 Author: Jason Ekstrand Date: Mon Aug 2 13:48:01 2021 -0500 drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" commit c9d9fdbc108af8915d3f497bbdf3898bf8f321b8 upstream. This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The justification for this commit in the git history was a vague comment about getting it out from under the struct_mutex. While this may improve perf for some workloads on Gen7 platforms where we rely on the command parser for features such as indirect rendering, no numbers were provided to prove such an improvement. It claims to closed two gitlab/bugzilla issues but with no explanation whatsoever as to why or what bug it's fixing. Meanwhile, by moving command parsing off to an async callback, it leaves us with a problem of what to do on error. When things were synchronous, EXECBUFFER2 would fail with an error code if parsing failed. When moving it to async, we needed another way to handle that error and the solution employed was to set an error on the dma_fence and then trust that said error gets propagated to the client eventually. Moving back to synchronous will help us untangle the fence error propagation mess. This also reverts most of 0edbb9ba1bfe ("drm/i915: Move cmd parser pinning to execbuffer") which is a refactor of some of our allocation paths for asynchronous parsing. Now that everything is synchronous, we don't need it. v2 (Daniel Vetter): - Add stabel Cc and Fixes tag Signed-off-by: Jason Ekstrand Cc: # v5.6+ Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Cc: Maarten Lankhorst Reviewed-by: Jon Bloomfield Acked-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-2-jason@jlekstrand.net Signed-off-by: Sasha Levin