commit b9a023d8c8ab07d360fd4b67cc6d1c1087de2a7e Author: Greg Kroah-Hartman Date: Wed Jul 28 09:12:37 2021 +0200 Linux 4.4.277 Link: https://lore.kernel.org/r/20210726153822.980271128@linuxfoundation.org Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20210727061334.372078412@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing commit 065fd04f45bcb25ad568d97247775a7455ec8a72 Author: David Sterba Date: Mon Jun 14 12:45:18 2021 +0200 btrfs: compression: don't try to compress if we don't have enough pages commit f2165627319ffd33a6217275e5690b1ab5c45763 upstream The early check if we should attempt compression does not take into account the number of input pages. It can happen that there's only one page, eg. a tail page after some ranges of the BTRFS_MAX_UNCOMPRESSED have been processed, or an isolated page that won't be converted to an inline extent. The single page would be compressed but a later check would drop it again because the result size must be at least one block shorter than the input. That can never work with just one page. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: David Sterba [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 3da5c27c809f226b20bfc11f22713581f7261418 Author: Stephan Gerhold Date: Wed May 26 11:44:07 2021 +0200 iio: accel: bma180: Fix BMA25x bandwidth register values commit 8090d67421ddab0ae932abab5a60200598bf0bbb upstream According to the BMA253 datasheet [1] and BMA250 datasheet [2] the bandwidth value for BMA25x should be set as 01xxx: "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] It is recommended [...] to use the range from ´01000b´ to ´01111b´ only in order to be compatible with future products." However, at the moment the drivers sets bandwidth values from 0 to 6, which is not recommended and always results into 7.81 Hz bandwidth according to the datasheet. Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, so the additional bit is always set for BMA25x. [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma253-ds000.pdf [2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf Cc: Peter Meerwald Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net Cc: Signed-off-by: Jonathan Cameron [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit a7014c6404fe28bf19f3065cab3f1589483b3aa0 Author: Linus Walleij Date: Wed Dec 11 22:38:18 2019 +0100 iio: accel: bma180: Use explicit member assignment commit 9436abc40139503a7cea22a96437697d048f31c0 upstream This uses the C99 explicit .member assignment for the variant data in struct bma180_part_info. This makes it easier to understand and add new variants. Cc: Peter Meerwald Cc: Oleksandr Kravchenko Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit a36ce1d5586215567a81048e8beb6210964325c8 Author: Doug Berger Date: Tue Jun 29 17:14:19 2021 -0700 net: bcmgenet: ensure EXT_ENERGY_DET_MASK is clear commit 5a3c680aa2c12c90c44af383fe6882a39875ab81 upstream. Setting the EXT_ENERGY_DET_MASK bit allows the port energy detection logic of the internal PHY to prevent the system from sleeping. Some internal PHYs will report that energy is detected when the network interface is closed which can prevent the system from going to sleep if WoL is enabled when the interface is brought down. Since the driver does not support waking the system on this logic, this commit clears the bit whenever the internal PHY is powered up and the other logic for manipulating the bit is removed since it serves no useful function. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4487b968e5eacd02c493303dc2b61150bb7fe4b2 Author: Gustavo A. R. Silva Date: Mon Apr 19 18:43:32 2021 -0500 media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Fixes: dae52d009fc9 ("V4L/DVB: ngene: Initial check-in") Cc: stable@vger.kernel.org Reported-by: kernel test robot Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman commit afa091792525dfa6c3c854069ec6b8a5ccc62c11 Author: Haoran Luo Date: Wed Jul 21 14:12:07 2021 +0000 tracing: Fix bug in rb_per_cpu_empty() that might cause deadloop. commit 67f0d6d9883c13174669f88adac4f0ee656cc16a upstream. The "rb_per_cpu_empty()" misinterpret the condition (as not-empty) when "head_page" and "commit_page" of "struct ring_buffer_per_cpu" points to the same buffer page, whose "buffer_data_page" is empty and "read" field is non-zero. An error scenario could be constructed as followed (kernel perspective): 1. All pages in the buffer has been accessed by reader(s) so that all of them will have non-zero "read" field. 2. Read and clear all buffer pages so that "rb_num_of_entries()" will return 0 rendering there's no more data to read. It is also required that the "read_page", "commit_page" and "tail_page" points to the same page, while "head_page" is the next page of them. 3. Invoke "ring_buffer_lock_reserve()" with large enough "length" so that it shot pass the end of current tail buffer page. Now the "head_page", "commit_page" and "tail_page" points to the same page. 4. Discard current event with "ring_buffer_discard_commit()", so that "head_page", "commit_page" and "tail_page" points to a page whose buffer data page is now empty. When the error scenario has been constructed, "tracing_read_pipe" will be trapped inside a deadloop: "trace_empty()" returns 0 since "rb_per_cpu_empty()" returns 0 when it hits the CPU containing such constructed ring buffer. Then "trace_find_next_entry_inc()" always return NULL since "rb_num_of_entries()" reports there's no more entry to read. Finally "trace_seq_to_user()" returns "-EBUSY" spanking "tracing_read_pipe" back to the start of the "waitagain" loop. I've also written a proof-of-concept script to construct the scenario and trigger the bug automatically, you can use it to trace and validate my reasoning above: https://github.com/aegistudio/RingBufferDetonator.git Tests has been carried out on linux kernel 5.14-rc2 (2734d6c1b1a089fb593ef6a23d4b70903526fe0c), my fixed version of kernel (for testing whether my update fixes the bug) and some older kernels (for range of affected kernels). Test result is also attached to the proof-of-concept repository. Link: https://lore.kernel.org/linux-trace-devel/YPaNxsIlb2yjSi5Y@aegistudio/ Link: https://lore.kernel.org/linux-trace-devel/YPgrN85WL9VyrZ55@aegistudio Cc: stable@vger.kernel.org Fixes: bf41a158cacba ("ring-buffer: make reentrant") Suggested-by: Linus Torvalds Signed-off-by: Haoran Luo Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 968028994b673ebbcd07b5da1e1896ad8f2eed05 Author: John Keeping Date: Wed Jul 21 17:17:45 2021 +0100 USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick commit d6a206e60124a9759dd7f6dfb86b0e1d3b1df82e upstream. Add the USB serial device ID for the CEL ZigBee EM3588 radio stick. Signed-off-by: John Keeping Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d69b94720ed780c85762f216f42210fe040ec2b1 Author: Ian Ray Date: Mon Jul 19 18:43:49 2021 +0200 USB: serial: cp210x: fix comments for GE CS1000 commit e9db418d4b828dd049caaf5ed65dc86f93bb1a0c upstream. Fix comments for GE CS1000 CP210x USB ID assignments. Fixes: 42213a0190b5 ("USB: serial: cp210x: add some more GE USB IDs") Signed-off-by: Ian Ray Signed-off-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 094a3f3b0ca36e9a6b2a09f9103c19fb80368e24 Author: Marco De Marco Date: Mon Jul 5 19:44:21 2021 +0000 USB: serial: option: add support for u-blox LARA-R6 family commit 94b619a07655805a1622484967754f5848640456 upstream. The patch is meant to support LARA-R6 Cat 1 module family. Module USB ID: Vendor ID: 0x05c6 Product ID: 0x90fA Interface layout: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: QMI wwan (not available in all versions) Signed-off-by: Marco De Marco Link: https://lore.kernel.org/r/49260184.kfMIbaSn9k@mars Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 56bb2d23094ce32f7b8abbc4c0dc205a8b427bda Author: Yoshihiro Shimoda Date: Thu Jun 24 21:20:39 2021 +0900 usb: renesas_usbhs: Fix superfluous irqs happen after usb_pkt_pop() commit 5719df243e118fb343725e8b2afb1637e1af1373 upstream. This driver has a potential issue which this driver is possible to cause superfluous irqs after usb_pkt_pop() is called. So, after the commit 3af32605289e ("usb: renesas_usbhs: fix error return code of usbhsf_pkt_handler()") had been applied, we could observe the following error happened when we used g_audio. renesas_usbhs e6590000.usb: irq_ready run_error 1 : -22 To fix the issue, disable the tx or rx interrupt in usb_pkt_pop(). Fixes: 2743e7f90dc0 ("usb: renesas_usbhs: fix the usb_pkt_pop()") Cc: # v4.4+ Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210624122039.596528-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman commit fc2a7c2280fa2be8ff9b5af702368fcd49a0acdb Author: Mark Tomlinson Date: Fri Jun 25 15:14:56 2021 +1200 usb: max-3421: Prevent corruption of freed memory commit b5fdf5c6e6bee35837e160c00ac89327bdad031b upstream. The MAX-3421 USB driver remembers the state of the USB toggles for a device/endpoint. To save SPI writes, this was only done when a new device/endpoint was being used. Unfortunately, if the old device was removed, this would cause writes to freed memory. To fix this, a simpler scheme is used. The toggles are read from hardware when a URB is completed, and the toggles are always written to hardware when any URB transaction is started. This will cause a few more SPI transactions, but no causes kernel panics. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Cc: stable Signed-off-by: Mark Tomlinson Link: https://lore.kernel.org/r/20210625031456.8632-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Greg Kroah-Hartman commit 171f02a8d1654ef7473bd1cccedbd271ec43ef9b Author: Julian Sikorski Date: Tue Jul 20 19:19:10 2021 +0200 USB: usb-storage: Add LaCie Rugged USB3-FW to IGNORE_UAS commit 6abf2fe6b4bf6e5256b80c5817908151d2d33e9f upstream. LaCie Rugged USB3-FW appears to be incompatible with UAS. It generates errors like: [ 1151.582598] sd 14:0:0:0: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN [ 1151.582602] sd 14:0:0:0: tag#16 CDB: Report supported operation codes a3 0c 01 12 00 00 00 00 02 00 00 00 [ 1151.588594] scsi host14: uas_eh_device_reset_handler start [ 1151.710482] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 1151.741398] scsi host14: uas_eh_device_reset_handler success [ 1181.785534] scsi host14: uas_eh_device_reset_handler start Signed-off-by: Julian Sikorski Cc: stable Link: https://lore.kernel.org/r/20210720171910.36497-1-belegdol+github@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3520d92bf8e955249fd12b5ae64fe50c0d079151 Author: Mathias Nyman Date: Thu Jul 15 18:01:22 2021 +0300 usb: hub: Disable USB 3 device initiated lpm if exit latency is too high commit 1b7f56fbc7a1b66967b6114d1b5f5a257c3abae6 upstream. The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman Cc: stable Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1e90a673f6ee09c668fe01aa1b94924f972c9811 Author: Nicholas Piggin Date: Tue Jul 20 20:43:09 2021 +1000 KVM: PPC: Book3S: Fix H_RTAS rets buffer overflow commit f62f3c20647ebd5fb6ecb8f0b477b9281c44c10a upstream. The kvmppc_rtas_hcall() sets the host rtas_args.rets pointer based on the rtas_args.nargs that was provided by the guest. That guest nargs value is not range checked, so the guest can cause the host rets pointer to be pointed outside the args array. The individual rtas function handlers check the nargs and nrets values to ensure they are correct, but if they are not, the handlers store a -3 (0xfffffffd) failure indication in rets[0] which corrupts host memory. Fix this by testing up front whether the guest supplied nargs and nret would exceed the array size, and fail the hcall directly without storing a failure indication to rets[0]. Also expand on a comment about why we kill the guest and try not to return errors directly if we have a valid rets[0] pointer. Fixes: 8e591cb72047 ("KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls") Cc: stable@vger.kernel.org # v3.10+ Reported-by: Alexey Kardashevskiy Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 881d67d762db38e95399dfdab321778378f77090 Author: Mathias Nyman Date: Thu Jul 15 18:06:51 2021 +0300 xhci: Fix lost USB 2 remote wake commit 72f68bf5c756f5ce1139b31daae2684501383ad5 upstream. There's a small window where a USB 2 remote wake may be left unhandled due to a race between hub thread and xhci port event interrupt handler. When the resume event is detected in the xhci interrupt handler it kicks the hub timer, which should move the port from resume to U0 once resume has been signalled for long enough. To keep the hub "thread" running we set a bus_state->resuming_ports flag. This flag makes sure hub timer function kicks itself. checking this flag was not properly protected by the spinlock. Flag was copied to a local variable before lock was taken. The local variable was then checked later with spinlock held. If interrupt is handled right after copying the flag to the local variable we end up stopping the hub thread before it can handle the USB 2 resume. CPU0 CPU1 (hub thread) (xhci event handler) xhci_hub_status_data() status = bus_state->resuming_ports; handle_port_status() spin_lock() bus_state->resuming_ports = 1 set_flag(HCD_FLAG_POLL_RH) spin_unlock() spin_lock() if (!status) clear_flag(HCD_FLAG_POLL_RH) spin_unlock() Fix this by taking the lock a bit earlier so that it covers the resuming_ports flag copy in the hub thread Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210715150651.1996099-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f98b3c3ccf85f99f623369050864df55369fcd08 Author: Takashi Iwai Date: Fri Jul 16 15:27:23 2021 +0200 ALSA: sb: Fix potential ABBA deadlock in CSP driver commit 1c2b9519159b470ef24b2638f4794e86e2952ab7 upstream. SB16 CSP driver may hit potentially a typical ABBA deadlock in two code paths: In snd_sb_csp_stop(): spin_lock_irqsave(&p->chip->mixer_lock, flags); spin_lock(&p->chip->reg_lock); In snd_sb_csp_load(): spin_lock_irqsave(&p->chip->reg_lock, flags); spin_lock(&p->chip->mixer_lock); Also the similar pattern is seen in snd_sb_csp_start(). Although the practical impact is very small (those states aren't triggered in the same running state and this happens only on a real hardware, decades old ISA sound boards -- which must be very difficult to find nowadays), it's a real scenario and has to be fixed. This patch addresses those deadlocks by splitting the locks in snd_sb_csp_start() and snd_sb_csp_stop() for avoiding the nested locks. Reported-by: Jia-Ju Bai Cc: Link: https://lore.kernel.org/r/7b0fcdaf-cd4f-4728-2eae-48c151a92e10@gmail.com Link: https://lore.kernel.org/r/20210716132723.13216-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8dc4b671af32162084962699ab12b498447ec891 Author: Vasily Gorbik Date: Fri Jun 25 23:50:07 2021 +0200 s390/ftrace: fix ftrace_update_ftrace_func implementation commit f8c2602733c953ed7a16e060640b8e96f9d94b9b upstream. s390 enforces DYNAMIC_FTRACE if FUNCTION_TRACER is selected. At the same time implementation of ftrace_caller is not compliant with HAVE_DYNAMIC_FTRACE since it doesn't provide implementation of ftrace_update_ftrace_func() and calls ftrace_trace_function() directly. The subtle difference is that during ftrace code patching ftrace replaces function tracer via ftrace_update_ftrace_func() and activates it back afterwards. Unexpected direct calls to ftrace_trace_function() during ftrace code patching leads to nullptr-dereferences when tracing is activated for one of functions which are used during code patching. Those function currently are: copy_from_kernel_nofault() copy_from_kernel_nofault_allowed() preempt_count_sub() [with debug_defconfig] preempt_count_add() [with debug_defconfig] Corresponding KASAN report: BUG: KASAN: nullptr-dereference in function_trace_call+0x316/0x3b0 Read of size 4 at addr 0000000000001e08 by task migration/0/15 CPU: 0 PID: 15 Comm: migration/0 Tainted: G B 5.13.0-41423-g08316af3644d Hardware name: IBM 3906 M04 704 (LPAR) Stopper: multi_cpu_stop+0x0/0x3e0 <- stop_machine_cpuslocked+0x1e4/0x218 Call Trace: [<0000000001f77caa>] show_stack+0x16a/0x1d0 [<0000000001f8de42>] dump_stack+0x15a/0x1b0 [<0000000001f81d56>] print_address_description.constprop.0+0x66/0x2e0 [<000000000082b0ca>] kasan_report+0x152/0x1c0 [<00000000004cfd8e>] function_trace_call+0x316/0x3b0 [<0000000001fb7082>] ftrace_caller+0x7a/0x7e [<00000000006bb3e6>] copy_from_kernel_nofault_allowed+0x6/0x10 [<00000000006bb42e>] copy_from_kernel_nofault+0x3e/0xd0 [<000000000014605c>] ftrace_make_call+0xb4/0x1f8 [<000000000047a1b4>] ftrace_replace_code+0x134/0x1d8 [<000000000047a6e0>] ftrace_modify_all_code+0x120/0x1d0 [<000000000047a7ec>] __ftrace_modify_code+0x5c/0x78 [<000000000042395c>] multi_cpu_stop+0x224/0x3e0 [<0000000000423212>] cpu_stopper_thread+0x33a/0x5a0 [<0000000000243ff2>] smpboot_thread_fn+0x302/0x708 [<00000000002329ea>] kthread+0x342/0x408 [<00000000001066b2>] __ret_from_fork+0x92/0xf0 [<0000000001fb57fa>] ret_from_fork+0xa/0x30 The buggy address belongs to the page: page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1 flags: 0x1ffff00000001000(reserved|node=0|zone=0|lastcpupid=0x1ffff) raw: 1ffff00000001000 0000040000000048 0000040000000048 0000000000000000 raw: 0000000000000000 0000000000000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 0000000000001d00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0000000000001d80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 >0000000000001e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 ^ 0000000000001e80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0000000000001f00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 ================================================================== To fix that introduce ftrace_func callback to be called from ftrace_caller and update it in ftrace_update_ftrace_func(). Fixes: 4cc9bed034d1 ("[S390] cleanup ftrace backend functions") Cc: stable@vger.kernel.org Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit cb0fc2a32a10375ca07c2ad067fc2c1e74585035 Author: Marcelo Henrique Cerri Date: Wed Jun 30 18:54:38 2021 -0700 proc: Avoid mixing integer types in mem_rw() [ Upstream commit d238692b4b9f2c36e35af4c6e6f6da36184aeb3e ] Use size_t when capping the count argument received by mem_rw(). Since count is size_t, using min_t(int, ...) can lead to a negative value that will later be passed to access_remote_vm(), which can cause unexpected behavior. Since we are capping the value to at maximum PAGE_SIZE, the conversion from size_t to int when passing it to access_remote_vm() as "len" shouldn't be a problem. Link: https://lkml.kernel.org/r/20210512125215.3348316-1-marcelo.cerri@canonical.com Reviewed-by: David Disseldorp Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Marcelo Henrique Cerri Cc: Alexey Dobriyan Cc: Souza Cascardo Cc: Christian Brauner Cc: Michel Lespinasse Cc: Helge Deller Cc: Oleg Nesterov Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fe6b2deca355bd5ab554eb0c6ce50bc91cc0f92e Author: Vincent Palatin Date: Wed Jul 21 11:25:16 2021 +0200 Revert "USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem" [ Upstream commit f3a1a937f7b240be623d989c8553a6d01465d04f ] This reverts commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd. While the patch was working as stated,ie preventing the L850-GL LTE modem from crashing on some U3 wake-ups due to a race condition between the host wake-up and the modem-side wake-up, when using the MBIM interface, this would force disabling the USB runtime PM on the device. The increased power consumption is significant for LTE laptops, and given that with decently recent modem firmwares, when the modem hits the bug, it automatically recovers (ie it drops from the bus, but automatically re-enumerates after less than half a second, rather than being stuck until a power cycle as it was doing with ancient firmware), for most people, the trade-off now seems in favor of re-enabling it by default. For people with access to the platform code, the bug can also be worked-around successfully by changing the USB3 LFPM polling off-time for the XHCI controller in the BIOS code. Signed-off-by: Vincent Palatin Link: https://lore.kernel.org/r/20210721092516.2775971-1-vpalatin@chromium.org Fixes: 0bd860493f81 ("USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65b0b68126b618d5abb9472511c127450eb33d09 Author: Dmitry Bogdanov Date: Fri Jul 2 12:16:55 2021 +0300 scsi: target: Fix protect handling in WRITE SAME(32) [ Upstream commit 6d8e7e7c932162bccd06872362751b0e1d76f5af ] WRITE SAME(32) command handling reads WRPROTECT at the wrong offset in 1st byte instead of 10th byte. Link: https://lore.kernel.org/r/20210702091655.22818-1-d.bogdanov@yadro.com Fixes: afd73f1b60fc ("target: Perform PROTECT sanity checks for WRITE_SAME") Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e3a2536319326b5df4c6f1d23e6f363a35abed8f Author: Mike Christie Date: Wed Jun 30 19:25:59 2021 -0500 scsi: iscsi: Fix iface sysfs attr detection [ Upstream commit e746f3451ec7f91dcc9fd67a631239c715850a34 ] A ISCSI_IFACE_PARAM can have the same value as a ISCSI_NET_PARAM so when iscsi_iface_attr_is_visible tries to figure out the type by just checking the value, we can collide and return the wrong type. When we call into the driver we might not match and return that we don't want attr visible in sysfs. The patch fixes this by setting the type when we figure out what the param is. Link: https://lore.kernel.org/r/20210701002559.89533-1-michael.christie@oracle.com Fixes: 3e0f65b34cc9 ("[SCSI] iscsi_transport: Additional parameters for network settings") Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 853262355518cd1247515b74e83fabf038aa6c29 Author: Nguyen Dinh Phi Date: Sun Jul 18 22:40:13 2021 +0800 netrom: Decrease sock refcount when sock timers expire [ Upstream commit 517a16b1a88bdb6b530f48d5d153478b2552d9a8 ] Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use sock timer API. It replaces mod_timer() by sk_reset_timer(), and del_timer() by sk_stop_timer(). Function sk_reset_timer() will increase the refcount of sock if it is called on an inactive timer, hence, in case the timer expires, we need to decrease the refcount ourselves in the handler, otherwise, the sock refcount will be unbalanced and the sock will never be freed. Signed-off-by: Nguyen Dinh Phi Reported-by: syzbot+10f1194569953b72f1ae@syzkaller.appspotmail.com Fixes: 63346650c1a9 ("netrom: switch to sock timer API") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 96151704247b61d5d61f6b842e11d8a96fe996ee Author: Yajun Deng Date: Wed Jul 14 17:13:20 2021 +0800 net: decnet: Fix sleeping inside in af_decnet [ Upstream commit 5f119ba1d5771bbf46d57cff7417dcd84d3084ba ] The release_sock() is blocking function, it would change the state after sleeping. use wait_woken() instead. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yajun Deng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d9d646acad2c3590e189bb5d5c86ab8bd8a2dfc3 Author: Ziyang Xuan Date: Thu Jul 15 20:22:04 2021 +0800 net: fix uninit-value in caif_seqpkt_sendmsg [ Upstream commit 991e634360f2622a683b48dfe44fe6d9cb765a09 ] When nr_segs equal to zero in iovec_from_user, the object msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg which is defined in ___sys_sendmsg. So we cann't just judge msg->msg_iter.iov->base directlly. We can use nr_segs to judge msg in caif_seqpkt_sendmsg whether has data buffers. ===================================================== BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmmsg+0x808/0xc90 net/socket.c:2480 __compat_sys_sendmmsg net/compat.c:656 [inline] Reported-by: syzbot+09a5d591c1f98cf5efcb@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=1ace85e8fc9b0d5a45c08c2656c3e91762daa9b8 Fixes: bece7b2398d0 ("caif: Rewritten socket implementation") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d54e9ac1d84b7c722e69506ae17a30cd0a51623 Author: Colin Ian King Date: Thu Jul 15 13:57:12 2021 +0100 s390/bpf: Perform r1 range checking before accessing jit->seen_reg[r1] [ Upstream commit 91091656252f5d6d8c476e0c92776ce9fae7b445 ] Currently array jit->seen_reg[r1] is being accessed before the range checking of index r1. The range changing on r1 should be performed first since it will avoid any potential out-of-range accesses on the array seen_reg[] and also it is more optimal to perform checks on r1 before fetching data from the array. Fix this by swapping the order of the checks before the array access. Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by: Colin Ian King Signed-off-by: Daniel Borkmann Tested-by: Ilya Leoshkevich Acked-by: Ilya Leoshkevich Link: https://lore.kernel.org/bpf/20210715125712.24690-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 3fbd744fc19578d3b196dd031742c2542ab9c959 Author: Riccardo Mancini Date: Thu Jul 15 18:07:25 2021 +0200 perf probe-file: Delete namelist in del_events() on the error path [ Upstream commit e0fa7ab42232e742dcb3de9f3c1f6127b5adc019 ] ASan reports some memory leaks when running: # perf test "42: BPF filter" This second leak is caused by a strlist not being dellocated on error inside probe_file__del_events. This patch adds a goto label before the deallocation and makes the error path jump to it. Signed-off-by: Riccardo Mancini Fixes: e7895e422e4da63d ("perf probe: Split del_perf_probe_events()") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/174963c587ae77fa108af794669998e4ae558338.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 19110f8b042d61475c060909a06d0b539d4c78c9 Author: Riccardo Mancini Date: Thu Jul 15 18:07:24 2021 +0200 perf test bpf: Free obj_buf [ Upstream commit 937654ce497fb6e977a8c52baee5f7d9616302d9 ] ASan reports some memory leaks when running: # perf test "42: BPF filter" The first of these leaks is caused by obj_buf never being deallocated in __test__bpf. This patch adds the missing free. Signed-off-by: Riccardo Mancini Fixes: ba1fae431e74bb42 ("perf test: Add 'perf test BPF'") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: http://lore.kernel.org/lkml/60f3ca935fe6672e7e866276ce6264c9e26e4c87.1626343282.git.rickyman7@gmail.com [ Added missing stdlib.h include ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 16f68e52f62fae0d5147afd50f3c5bf51c68f454 Author: Aleksandr Loktionov Date: Thu Apr 22 10:19:23 2021 +0000 igb: Check if num of q_vectors is smaller than max before array access [ Upstream commit 6c19d772618fea40d9681f259368f284a330fd90 ] Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed beyond its size. It was fixed by using a local variable num_q_vectors as a limit for loop index, and ensure that num_q_vectors is not bigger than MAX_Q_VECTORS. Fixes: 047e0030f1e6 ("igb: add new data structure for handling interrupts and NAPI") Signed-off-by: Aleksandr Loktionov Reviewed-by: Grzegorz Siwik Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Slawomir Laba Reviewed-by: Sylwester Dziedziuch Reviewed-by: Mateusz Palczewski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e471ac5ac85452139ccabac7fa130768c4459739 Author: Christophe JAILLET Date: Wed Jun 16 07:53:02 2021 +0200 iavf: Fix an error handling path in 'iavf_probe()' [ Upstream commit af30cbd2f4d6d66a9b6094e0aa32420bc8b20e08 ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 5eae00c57f5e ("i40evf: main driver core") Signed-off-by: Christophe JAILLET Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4074ca460e9fcf2cca4a1716b365b004a3258a3c Author: Eric Dumazet Date: Thu Jul 8 00:21:09 2021 -0700 ipv6: tcp: drop silly ICMPv6 packet too big messages commit c7bb4b89033b764eb07db4e060548a6311d801ee upstream. While TCP stack scales reasonably well, there is still one part that can be used to DDOS it. IPv6 Packet too big messages have to lookup/insert a new route, and if abused by attackers, can easily put hosts under high stress, with many cpus contending on a spinlock while one is stuck in fib6_run_gc() ip6_protocol_deliver_rcu() icmpv6_rcv() icmpv6_notify() tcp_v6_err() tcp_v6_mtu_reduced() inet6_csk_update_pmtu() ip6_rt_update_pmtu() __ip6_rt_update_pmtu() ip6_rt_cache_alloc() ip6_dst_alloc() dst_alloc() ip6_dst_gc() fib6_run_gc() spin_lock_bh() ... Some of our servers have been hit by malicious ICMPv6 packets trying to _increase_ the MTU/MSS of TCP flows. We believe these ICMPv6 packets are a result of a bug in one ISP stack, since they were blindly sent back for _every_ (small) packet sent to them. These packets are for one TCP flow: 09:24:36.266491 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.266509 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.316688 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.316704 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.608151 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 TCP stack can filter some silly requests : 1) MTU below IPV6_MIN_MTU can be filtered early in tcp_v6_err() 2) tcp_v6_mtu_reduced() can drop requests trying to increase current MSS. This tests happen before the IPv6 routing stack is entered, thus removing the potential contention and route exhaustion. Note that IPv6 stack was performing these checks, but too late (ie : after the route has been added, and after the potential garbage collect war) v2: fix typo caught by Martin, thanks ! v3: exports tcp_mtu_to_mss(), caught by David, thanks ! Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Maciej Żenczykowski Cc: Martin KaFai Lau Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 474bfaacd080d1d15fe0dd4552dd2a496db54385 Author: Eric Dumazet Date: Fri Jul 2 13:09:03 2021 -0700 tcp: annotate data races around tp->mtu_info commit 561022acb1ce62e50f7a8258687a21b84282a4cb upstream. While tp->mtu_info is read while socket is owned, the write sides happen from err handlers (tcp_v[46]_mtu_reduced) which only own the socket spinlock. Fixes: 563d34d05786 ("tcp: dont drop MTU reduction indications") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7f3c9df40515a6c6b46f36c4c94cf48a043f887 Author: Taehee Yoo Date: Fri Jul 9 17:35:18 2021 +0000 net: validate lwtstate->data before returning from skb_tunnel_info() commit 67a9c94317402b826fc3db32afc8f39336803d97 upstream. skb_tunnel_info() returns pointer of lwtstate->data as ip_tunnel_info type without validation. lwtstate->data can have various types such as mpls_iptunnel_encap, etc and these are not compatible. So skb_tunnel_info() should validate before returning that pointer. Splat looks like: BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan] Read of size 2 at addr ffff888106ec2698 by task ping/811 CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195 Call Trace: dump_stack_lvl+0x56/0x7b print_address_description.constprop.8.cold.13+0x13/0x2ee ? vxlan_get_route+0x418/0x4b0 [vxlan] ? vxlan_get_route+0x418/0x4b0 [vxlan] kasan_report.cold.14+0x83/0xdf ? vxlan_get_route+0x418/0x4b0 [vxlan] vxlan_get_route+0x418/0x4b0 [vxlan] [ ... ] vxlan_xmit_one+0x148b/0x32b0 [vxlan] [ ... ] vxlan_xmit+0x25c5/0x4780 [vxlan] [ ... ] dev_hard_start_xmit+0x1ae/0x6e0 __dev_queue_xmit+0x1f39/0x31a0 [ ... ] neigh_xmit+0x2f9/0x940 mpls_xmit+0x911/0x1600 [mpls_iptunnel] lwtunnel_xmit+0x18f/0x450 ip_finish_output2+0x867/0x2040 [ ... ] Fixes: 61adedf3e3f1 ("route: move lwtunnel state to dst_entry") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a18a8d9cfbb112ad72e625372849adc3986fd6bf Author: Pavel Skripkin Date: Fri Jul 9 17:58:29 2021 +0300 net: ti: fix UAF in tlan_remove_one commit 0336f8ffece62f882ab3012820965a786a983f70 upstream. priv is netdev private data and it cannot be used after free_netdev() call. Using priv after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. Fixes: 1e0a8b13d355 ("tlan: cancel work at remove path") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 001e04bd5d48444917e7c3261d01e391803fcb55 Author: Pavel Skripkin Date: Fri Jul 9 17:09:53 2021 +0300 net: moxa: fix UAF in moxart_mac_probe commit c78eaeebe855fd93f2e77142ffd0404a54070d84 upstream. In case of netdev registration failure the code path will jump to init_fail label: init_fail: netdev_err(ndev, "init failed\n"); moxart_mac_free_memory(ndev); irq_map_fail: free_netdev(ndev); return ret; So, there is no need to call free_netdev() before jumping to error handling path, since it can cause UAF or double-free bug. Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5a37be80709cc038189b7cfc4324693b48f09520 Author: Florian Fainelli Date: Thu Jul 8 18:55:32 2021 -0700 net: bcmgenet: Ensure all TX/RX queues DMAs are disabled commit 2b452550a203d88112eaf0ba9fc4b750a000b496 upstream. Make sure that we disable each of the TX and RX queues in the TDMA and RDMA control registers. This is a correctness change to be symmetrical with the code that enables the TX and RX queues. Tested-by: Maxime Ripard Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6afc5fc7114e80e453bf156fb4bf4d1dc1a31d3a Author: Vadim Fedorenko Date: Fri Jul 2 02:47:00 2021 +0300 net: ipv6: fix return value of ip6_skb_dst_mtu commit 40fc3054b45820c28ea3c65e2c86d041dc244a8a upstream. Commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE") introduced ip6_skb_dst_mtu with return value of signed int which is inconsistent with actually returned values. Also 2 users of this function actually assign its value to unsigned int variable and only __xfrm6_output assigns result of this function to signed variable but actually uses as unsigned in further comparisons and calls. Change this function to return unsigned int value. Fixes: 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE") Reviewed-by: David Ahern Signed-off-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8906626a37623f84b581cca2ffae45748f489eab Author: Thomas Gleixner Date: Fri Jun 18 16:18:25 2021 +0200 x86/fpu: Make init_fpstate correct with optimized XSAVE commit f9dfb5e390fab2df9f7944bb91e7705aba14cd26 upstream. The XSAVE init code initializes all enabled and supported components with XRSTOR(S) to init state. Then it XSAVEs the state of the components back into init_fpstate which is used in several places to fill in the init state of components. This works correctly with XSAVE, but not with XSAVEOPT and XSAVES because those use the init optimization and skip writing state of components which are in init state. So init_fpstate.xsave still contains all zeroes after this operation. There are two ways to solve that: 1) Use XSAVE unconditionally, but that requires to reshuffle the buffer when XSAVES is enabled because XSAVES uses compacted format. 2) Save the components which are known to have a non-zero init state by other means. Looking deeper, #2 is the right thing to do because all components the kernel supports have all-zeroes init state except the legacy features (FP, SSE). Those cannot be hard coded because the states are not identical on all CPUs, but they can be saved with FXSAVE which avoids all conditionals. Use FXSAVE to save the legacy FP/SSE components in init_fpstate along with a BUILD_BUG_ON() which reminds developers to validate that a newly added component has all zeroes init state. As a bonus remove the now unused copy_xregs_to_kernel_booting() crutch. The XSAVE and reshuffle method can still be implemented in the unlikely case that components are added which have a non-zero init state and no other means to save them. For now, FXSAVE is just simple and good enough. [ bp: Fix a typo or two in the text. ] Fixes: 6bad06b76892 ("x86, xsave: Use xsaveopt in context-switch path when supported") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Reviewed-by: Borislav Petkov Cc: stable@vger.kernel.org [ bp: 4.4 backport: Drop XFEATURE_MASK_{PKRU,PASID} which are not there yet. ] Link: https://lkml.kernel.org/r/20210618143444.587311343@linutronix.de Signed-off-by: Greg Kroah-Hartman commit bd051b3e184fa56eeb6276ee913ba4d48069024b Author: Greg Kroah-Hartman Date: Thu Jul 22 15:35:47 2021 +0200 Revert "memory: fsl_ifc: fix leak of IO mapping on probe failure" This reverts commit b7a2bcb4a3731d68f938207f75ed3e1d41774510 which is commit 3b132ab67fc7a358fff35e808fa65d4bea452521 upstream. As reported, it breaks the build, the 'gregs' field is not in the 4.4.y kernel tree. Reported-by: Guenter Roeck Link: https://lore.kernel.org/r/20210721144845.GA3445926@roeck-us.net Cc: Dan Carpenter Cc: Krzysztof Kozlowski Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 70e95b0d4657a5b1b8e45c86bc46953c305d9ff9 Author: Odin Ugedal Date: Tue Jun 29 14:14:52 2021 +0200 sched/fair: Fix CFS bandwidth hrtimer expiry type [ Upstream commit 72d0ad7cb5bad265adb2014dbe46c4ccb11afaba ] The time remaining until expiry of the refresh_timer can be negative. Casting the type to an unsigned 64-bit value will cause integer underflow, making the runtime_refresh_within return false instead of true. These situations are rare, but they do happen. This does not cause user-facing issues or errors; other than possibly unthrottling cfs_rq's using runtime from the previous period(s), making the CFS bandwidth enforcement less strict in those (special) situations. Signed-off-by: Odin Ugedal Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ben Segall Link: https://lore.kernel.org/r/20210629121452.18429-1-odin@uged.al Signed-off-by: Sasha Levin commit 165717ea4660a5ac5b992cf79779542b12e13aa6 Author: Colin Ian King Date: Mon Jun 21 16:17:27 2021 +0100 scsi: aic7xxx: Fix unintentional sign extension issue on left shift of u8 [ Upstream commit 332a9dd1d86f1e7203fc7f0fd7e82f0b304200fe ] The shifting of the u8 integer returned fom ahc_inb(ahc, port+3) by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift. [ This dates back to 2002, I found the offending commit from the git history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git, commit f58eb66c0b0a ("Update aic7xxx driver to 6.2.10...") ] Link: https://lore.kernel.org/r/20210621151727.20667-1-colin.king@canonical.com Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Addresses-Coverity: ("Unintended sign extension") Signed-off-by: Sasha Levin commit 64796795bc9fbcbb2878808bc462cbe43339e48c Author: Matthias Maennich Date: Sat Jun 12 15:18:38 2021 +0100 kbuild: mkcompile_h: consider timestamp if KBUILD_BUILD_TIMESTAMP is set [ Upstream commit a979522a1a88556e42a22ce61bccc58e304cb361 ] To avoid unnecessary recompilations, mkcompile_h does not regenerate compile.h if just the timestamp changed. Though, if KBUILD_BUILD_TIMESTAMP is set, an explicit timestamp for the build was requested, in which case we should not ignore it. If a user follows the documentation for reproducible builds [1] and defines KBUILD_BUILD_TIMESTAMP as the git commit timestamp, a clean build will have the correct timestamp. A subsequent cherry-pick (or amend) changes the commit timestamp and if an incremental build is done with a different KBUILD_BUILD_TIMESTAMP now, that new value is not taken into consideration. But it should for reproducibility. Hence, whenever KBUILD_BUILD_TIMESTAMP is explicitly set, do not ignore UTS_VERSION when making a decision about whether the regenerated version of compile.h should be moved into place. [1] https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html Signed-off-by: Matthias Maennich Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit cb50f4a1f490c9f33916ff8285100c0595c6220f Author: Yang Yingliang Date: Mon May 17 13:10:20 2021 +0800 thermal/core: Correct function name thermal_zone_device_unregister() [ Upstream commit a052b5118f13febac1bd901fe0b7a807b9d6b51c ] Fix the following make W=1 kernel build warning: drivers/thermal/thermal_core.c:1376: warning: expecting prototype for thermal_device_unregister(). Prototype was for thermal_zone_device_unregister() instead Signed-off-by: Yang Yingliang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210517051020.3463536-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit b79b56b7ee548e6ee6e63b258ebbc89971574742 Author: Jonathan Neuschäfer Date: Sat Apr 24 14:37:28 2021 +0200 ARM: imx: pm-imx5: Fix references to imx5_cpu_suspend_info [ Upstream commit 89b759469d525f4d5f9c29cd3b1f490311c67f85 ] The name of the struct, as defined in arch/arm/mach-imx/pm-imx5.c, is imx5_cpu_suspend_info. Signed-off-by: Jonathan Neuschäfer Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 977e00ae601ac0598806320c6fe988ea0a8f3d87 Author: Primoz Fiser Date: Mon Apr 12 08:24:50 2021 +0200 ARM: dts: imx6: phyFLEX: Fix UART hardware flow control [ Upstream commit 14cdc1f243d79e0b46be150502b7dba9c5a6bdfd ] Serial interface uart3 on phyFLEX board is capable of 5-wire connection including signals RTS and CTS for hardware flow control. Fix signals UART3_CTS_B and UART3_RTS_B padmux assignments and add missing property "uart-has-rtscts" to allow serial interface to be configured and used with the hardware flow control. Signed-off-by: Primoz Fiser Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit b88eb17a7cae19ff9fc854cf83594b5cfc160386 Author: Rafał Miłecki Date: Fri Apr 16 15:37:52 2021 +0200 ARM: dts: BCM63xx: Fix NAND nodes names [ Upstream commit 75e2f012f6e34b93124d1d86eaa8f27df48e9ea0 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 8a0c9047585f1ec0b4f2be7d0c04f76379e330f0 Author: Rafał Miłecki Date: Fri Apr 16 15:37:49 2021 +0200 ARM: brcmstb: dts: fix NAND nodes names [ Upstream commit 9a800ce1aada6e0f56b78e4713f4858c8990c1f7 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin