profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/asheplyakov/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Alexey Sheplyakov asheplyakov BaseALT Saratov

asheplyakov/astftpd 5

a stupid/async tftp daemon

asheplyakov/dsoabivers 5

Talk on shared libraries versioning in Linux and Solaris

asheplyakov/dhcpflooder 3

Stress load your DHCP server

altlinux/linux-be-m1000 1

BE-M1000 SoC support patches for Linux kernel

asheplyakov/c10k-talk 1

Talk on c10k, epoll, SO_REUSE_PORT, and all that

asheplyakov/cosmology-not-so-news 1

Talk on cosmology for non-experts

push eventaltlinux/linux-be-m1000

Vadim V. Vlasov

commit sha 2613eabdc79ed9ff0652e5d00281da2867c2e430

Baikal-M: Add serio PS/2 emulator driver This provides support for PS/2 devices connected to the mitx embedded controller. I2C or SPI link is used as a transport between EC and kernel. (cherry picked from commit 0633a3f2002ac9c413fa53ea59eb74d0d2bedc68)

view details

Alexey Sheplyakov

commit sha cacc8f17c1a9c3dc6940d36abdfffa2712d6c43c

baikal: enabled serio emulation and PS/2 keyboard/mouse drivers

view details

push time in 2 days

push eventaltlinux/linux-be-m1000

Alexey Sheplyakov

commit sha 0406ab32aaa4b51072f85d9b49e1ecff92b3588c

pm: disable all sleep states on BE-M1000 based boards These days desktop environments try to put computer into a sleep state after a certain period of inactivity. TF307 board is able to enter a sleep state, however it does *NOT* wakeup via power button or keyboard/mouse. Apparently the only wakeup sources on TF307 board are - Real time clock (RTC) - Ethernet Surprisingly BMC (board management controller) is NOT a wakeup source. Also tp_bmc driver does not use interrupts, and polls the device instead. Perhaps BMC is unable to generate interrupts at all? To avoid the problem disable all sleep states (including s2idle) on Baikal-M systems

view details

push time in 20 days

push eventaltlinux/linux-be-m1000

Geert Uytterhoeven

commit sha 1435f82689e1d195e56ce8b19c81aa7b1a3bd0b0

reset: RESET_MCHP_SPARX5 should depend on ARCH_SPARX5 The Microchip Sparx5 switch reset block is only present on Microchip Sparx5 SoCs. Hence add a dependency on ARCH_SPARX5, to prevent asking the user about this driver when configuring a kernel without Sparx5 support. Fixes: 453ed4283bebd077 ("reset: mchp: sparx5: add switch reset driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/6e08f6f46123d0712397e901716b48f13fa5dc48.1624627657.git.geert@linux-m68k.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

view details

Linus Walleij

commit sha 463dbba4d189750c2f576449d0bbb11c5413712e

ARM: 9104/2: Fix Keystone 2 kernel mapping regression This fixes a Keystone 2 regression discovered as a side effect of defining an passing the physical start/end sections of the kernel to the MMU remapping code. As the Keystone applies an offset to all physical addresses, including those identified and patches by phys2virt, we fail to account for this offset in the kernel_sec_start and kernel_sec_end variables. Further these offsets can extend into the 64bit range on LPAE systems such as the Keystone 2. Fix it like this: - Extend kernel_sec_start and kernel_sec_end to be 64bit - Add the offset also to kernel_sec_start and kernel_sec_end As passing kernel_sec_start and kernel_sec_end as 64bit invariably incurs BE8 endianness issues I have attempted to dry-code around these. Tested on the Vexpress QEMU model both with and without LPAE enabled. Fixes: 6e121df14ccd ("ARM: 9090/1: Map the lowmem and kernel separately") Reported-by: Nishanth Menon <nmenon@kernel.org> Suggested-by: Russell King <rmk+kernel@armlinux.org.uk> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> Tested-by: Nishanth Menon <nmenon@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

view details

Lukas Bulwahn

commit sha 310d2e83cb9b7f1e7232319880e3fcb57592fa10

powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK Commit 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK") broke PMD split page table lock for powerpc. It selects the non-existent config ARCH_ENABLE_PMD_SPLIT_PTLOCK in arch/powerpc/platforms/Kconfig.cputype, but clearly intended to select ARCH_ENABLE_SPLIT_PMD_PTLOCK (notice the word swapping!), as that commit did for all other architectures. Fix it by selecting the correct symbol ARCH_ENABLE_SPLIT_PMD_PTLOCK. Fixes: 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK") Cc: stable@vger.kernel.org # v5.13+ Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Daniel Axtens <dja@axtens.net> [mpe: Reword change log to make it clear this is a bug fix] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210819113954.17515-3-lukas.bulwahn@gmail.com

view details

Peter Zijlstra

commit sha 3c474b3239f12fe0b00d7e82481f36a1f31e79ab

sched: Fix Core-wide rq->lock for uninitialized CPUs Eugene tripped over the case where rq_lock(), as called in a for_each_possible_cpu() loop came apart because rq->core hadn't been setup yet. This is a somewhat unusual, but valid case. Rework things such that rq->core is initialized to point at itself. IOW initialize each CPU as a single threaded Core. CPU online will then join the new CPU (thread) to an existing Core where needed. For completeness sake, have CPU offline fully undo the state so as to not presume the topology will match the next time it comes online. Fixes: 9edeaea1bc45 ("sched: Core-wide rq->lock") Reported-by: Eugene Syromiatnikov <esyr@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Josh Don <joshdon@google.com> Tested-by: Eugene Syromiatnikov <esyr@redhat.com> Link: https://lkml.kernel.org/r/YR473ZGeKqMs6kw+@hirez.programming.kicks-ass.net

view details

Nicholas Piggin

commit sha 787c70f2f9990b5a197320152d2fc32cd8a6ad1a

powerpc/64s: Fix scv implicit soft-mask table for relocated kernels The implict soft-mask table addresses get relocated if they use a relative symbol like a label. This is right for code that runs relocated but not for unrelocated. The scv interrupt vectors run unrelocated, so absolute addresses are required for their soft-mask table entry. This fixes crashing with relocated kernels, usually an asynchronous interrupt hitting in the scv handler, then hitting the trap that checks whether r1 is in userspace. Fixes: 325678fd0522 ("powerpc/64s: add a table of implicit soft-masked addresses") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210820103431.1701240-1-npiggin@gmail.com

view details

Joerg Roedel

commit sha 22aa45cb465be474e97666b3f7587ccb06ee411b

x86/efi: Restore Firmware IDT before calling ExitBootServices() Commit 79419e13e808 ("x86/boot/compressed/64: Setup IDT in startup_32 boot path") introduced an IDT into the 32-bit boot path of the decompressor stub. But the IDT is set up before ExitBootServices() is called, and some UEFI firmwares rely on their own IDT. Save the firmware IDT on boot and restore it before calling into EFI functions to fix boot failures introduced by above commit. Fixes: 79419e13e808 ("x86/boot/compressed/64: Setup IDT in startup_32 boot path") Reported-by: Fabio Aiuto <fabioaiuto83@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Cc: stable@vger.kernel.org # 5.13+ Link: https://lkml.kernel.org/r/20210820125703.32410-1-joro@8bytes.org

view details

Babu Moger

commit sha 527f721478bce3f49b513a733bacd19d6f34b08c

x86/resctrl: Fix a maybe-uninitialized build warning treated as error The recent commit 064855a69003 ("x86/resctrl: Fix default monitoring groups reporting") caused a RHEL build failure with an uninitialized variable warning treated as an error because it removed the default case snippet. The RHEL Makefile uses '-Werror=maybe-uninitialized' to force possibly uninitialized variable warnings to be treated as errors. This is also reported by smatch via the 0day robot. The error from the RHEL build is: arch/x86/kernel/cpu/resctrl/monitor.c: In function ‘__mon_event_count’: arch/x86/kernel/cpu/resctrl/monitor.c:261:12: error: ‘m’ may be used uninitialized in this function [-Werror=maybe-uninitialized] m->chunks += chunks; ^~ The upstream Makefile does not build using '-Werror=maybe-uninitialized'. So, the problem is not seen there. Fix the problem by putting back the default case snippet. [ bp: note that there's nothing wrong with the code and other compilers do not trigger this warning - this is being done just so the RHEL compiler is happy. ] Fixes: 064855a69003 ("x86/resctrl: Fix default monitoring groups reporting") Reported-by: Terry Bowman <Terry.Bowman@amd.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/162949631908.23903.17090272726012848523.stgit@bmoger-ubuntu

view details

Marijn Suijten

commit sha 19526d092ceb32d619fce73fe0bdca4370890124

opp: core: Check for pending links before reading required_opp pointers Commit 4fa82a87ba55 ("opp: Allow required-opps to be used for non genpd use cases") dereferences the pointers in required_opp_tables but these might be set to an ERR_PTR if the list still has lazy links pending, resulting in segfaults. Prior to this patch IS_ERR was also checked on required_opp_tables[i] before reading ->is_genpd inside _opp_table_alloc_required_tables, which is at the same time the predicate to add this table to the lazy list. This segfault is solved by reordering the checks to bail on lazy pending tables before reading ->is_genpd. Fixes: 4fa82a87ba55 ("opp: Allow required-opps to be used for non genpd use cases") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

view details

Sai Krishna Potthuri

commit sha ed104ca4bd9c405b41e968ad4ece51f6462e90b6

reset: reset-zynqmp: Fixed the argument data type This patch changes the data type of the variable 'val' from int to u32. Addresses-Coverity: argument of type "int *" is incompatible with parameter of type "u32 *" Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/925cebbe4eb73c7d0a536da204748d33c7100d8c.1624448778.git.michal.simek@xilinx.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

view details

Rafael J. Wysocki

commit sha 1f8b66d9654b21ec227a7884bcf739c70d9d27a7

Merge branch 'opp/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm into pm-opp Pull regression fix for the operating performance points (OPP) framework for v5.15 from Viresh Kumar: "This fixes regression in the OPP core for a corner case." * 'opp/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: opp: core: Check for pending links before reading required_opp pointers

view details

Zhengjun Zhang

commit sha 2829a4e3cf3a6ac2fa3cdb681b37574630fb9c1a

USB: serial: option: add new VID/PID to support Fibocom FG150 Fibocom FG150 is a 5G module based on Qualcomm SDX55 platform, support Sub-6G band. Here are the outputs of lsusb -v and usb-devices: > T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 > D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 > P: Vendor=2cb7 ProdID=010b Rev=04.14 > S: Manufacturer=Fibocom > S: Product=Fibocom Modem_SN:XXXXXXXX > S: SerialNumber=XXXXXXXX > C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA > I: If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host > I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host > I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) > I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) > I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) > Bus 002 Device 002: ID 2cb7:010b Fibocom Fibocom Modem_SN:XXXXXXXX > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 3.20 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 9 > idVendor 0x2cb7 Fibocom > idProduct 0x010b > bcdDevice 4.14 > iManufacturer 1 Fibocom > iProduct 2 Fibocom Modem_SN:XXXXXXXX > iSerial 3 XXXXXXXX > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x00e6 > bNumInterfaces 5 > bConfigurationValue 1 > iConfiguration 4 RNDIS_DUN_DIAG_ADB > bmAttributes 0xa0 > (Bus Powered) > Remote Wakeup > MaxPower 896mA > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 0 > bInterfaceCount 2 > bFunctionClass 239 Miscellaneous Device > bFunctionSubClass 4 > bFunctionProtocol 1 > iFunction 7 RNDIS > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 239 Miscellaneous Device > bInterfaceSubClass 4 > bInterfaceProtocol 1 > iInterface 0 > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 01 > ** UNRECOGNIZED: 04 24 02 00 > ** UNRECOGNIZED: 05 24 06 00 01 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 9 > bMaxBurst 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 10 CDC Data > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x8e EP 14 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 6 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x0f EP 15 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 6 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 00 > ** UNRECOGNIZED: 04 24 02 02 > ** UNRECOGNIZED: 05 24 06 00 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x000a 1x 10 bytes > bInterval 9 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 48 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 4 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 66 > bInterfaceProtocol 1 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Binary Object Store Descriptor: > bLength 5 > bDescriptorType 15 > wTotalLength 0x0016 > bNumDeviceCaps 2 > USB 2.0 Extension Device Capability: > bLength 7 > bDescriptorType 16 > bDevCapabilityType 2 > bmAttributes 0x00000006 > BESL Link Power Management (LPM) Supported > SuperSpeed USB Device Capability: > bLength 10 > bDescriptorType 16 > bDevCapabilityType 3 > bmAttributes 0x00 > wSpeedsSupported 0x000f > Device can operate at Low Speed (1Mbps) > Device can operate at Full Speed (12Mbps) > Device can operate at High Speed (480Mbps) > Device can operate at SuperSpeed (5Gbps) > bFunctionalitySupport 1 > Lowest fully-functional device speed is Full Speed (12Mbps) > bU1DevExitLat 1 micro seconds > bU2DevExitLat 500 micro seconds > Device Status: 0x0000 > (Bus Powered) Signed-off-by: Zhengjun Zhang <zhangzhengjun@aicrobo.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>

view details

Bart Van Assche

commit sha b6d2b054e8baaee53fd2d4854c63cbf0f2c6262a

mq-deadline: Fix request accounting The block layer may call the I/O scheduler .finish_request() callback without having called the .insert_requests() callback. Make sure that the mq-deadline I/O statistics are correct if the block layer inserts an I/O request that bypasses the I/O scheduler. This patch prevents that lower priority I/O is delayed longer than necessary for mixed I/O priority workloads. Cc: Niklas Cassel <Niklas.Cassel@wdc.com> Cc: Damien Le Moal <damien.lemoal@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Reported-by: Niklas Cassel <Niklas.Cassel@wdc.com> Fixes: 08a9ad8bf607 ("block/mq-deadline: Add cgroup support") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20210824170520.1659173-1-bvanassche@acm.org Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com> Tested-by: Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>

view details

Li Jinlin

commit sha 02c6dcd543f8f051973ee18bfbc4dc3bd595c558

scsi: core: Fix hang of freezing queue between blocking and running device We found a hang, the steps to reproduce are as follows: 1. blocking device via scsi_device_set_state() 2. dd if=/dev/sda of=/mnt/t.log bs=1M count=10 3. echo none > /sys/block/sda/queue/scheduler 4. echo "running" >/sys/block/sda/device/state Step 3 and 4 should complete after step 4, but they hang. CPU#0 CPU#1 CPU#2 --------------- ---------------- ---------------- Step 1: blocking device Step 2: dd xxxx ^^^^^^ get request q_usage_counter++ Step 3: switching scheculer elv_iosched_store elevator_switch blk_mq_freeze_queue blk_freeze_queue > blk_freeze_queue_start ^^^^^^ mq_freeze_depth++ > blk_mq_run_hw_queues ^^^^^^ can't run queue when dev blocked > blk_mq_freeze_queue_wait ^^^^^^ Hang here!!! wait q_usage_counter==0 Step 4: running device store_state_field scsi_rescan_device scsi_attach_vpd scsi_vpd_inquiry __scsi_execute blk_get_request blk_mq_alloc_request blk_queue_enter ^^^^^^ Hang here!!! wait mq_freeze_depth==0 blk_mq_run_hw_queues ^^^^^^ dispatch IO, q_usage_counter will reduce to zero blk_mq_unfreeze_queue ^^^^^ mq_freeze_depth-- To fix this, we need to run queue before rescanning device when the device state changes to SDEV_RUNNING. Link: https://lore.kernel.org/r/20210824025921.3277629-1-lijinlin3@huawei.com Fixes: f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Li Jinlin <lijinlin3@huawei.com> Signed-off-by: Qiu Laibin <qiulaibin@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

view details

Vincent Chen

commit sha 379eb01c21795edb4ca8d342503bd2183a19ec3a

riscv: Ensure the value of FP registers in the core dump file is up to date The value of FP registers in the core dump file comes from the thread.fstate. However, kernel saves the FP registers to the thread.fstate only before scheduling out the process. If no process switch happens during the exception handling process, kernel will not have a chance to save the latest value of FP registers to thread.fstate. It will cause the value of FP registers in the core dump file may be incorrect. To solve this problem, this patch force lets kernel save the FP register into the thread.fstate if the target task_struct equals the current. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Jisheng Zhang <jszhang@kernel.org> Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>

view details

Bin Meng

commit sha 719588dee26bac0d5979c122bc530c43dc5d07c7

riscv: dts: microchip: Use 'local-mac-address' for emac1 Per the DT spec, 'local-mac-address' is used to specify MAC address that was assigned to the network device, while 'mac-address' is used to specify the MAC address that was last used by the boot program, and shall be used only if the value differs from 'local-mac-address' property value. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: conor dooley <conor.dooley@microchip.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>

view details

Bin Meng

commit sha 417166ddec020c4e969aea064e23822591ad54df

riscv: dts: microchip: Add ethernet0 to the aliases node U-Boot expects this alias to be in place in order to fix up the mac address of the ethernet node. Note on the Icicle Kit board, currently only emac1 is enabled so it becomes the 'ethernet0'. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>

view details

Johan Hovold

commit sha df7b16d1c00ecb3da3a30c999cdb39f273c99a2f

Revert "USB: serial: ch341: fix character loss at high transfer rates" This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b. These devices do not appear to send a zero-length packet when the transfer size is a multiple of the bulk-endpoint max-packet size. This means that incoming data may not be processed by the driver until a short packet is received or the receive buffer is full. Revert back to using endpoint-sized receive buffers to avoid stalled reads. Reported-by: Paul Größel <pb.g@gmx.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131 Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates") Cc: stable@vger.kernel.org Cc: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>

view details

Xiaoyao Li

commit sha c53c6b7409f4cd9e542991b53d597fbe2751d7db

perf/x86/intel/pt: Fix mask of num_address_ranges Per SDM, bit 2:0 of CPUID(0x14,1).EAX[2:0] reports the number of configurable address ranges for filtering, not bit 1:0. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Link: https://lkml.kernel.org/r/20210824040622.4081502-1-xiaoyao.li@intel.com

view details

Dmitry Osipenko

commit sha 3c5a272202c28c1f9309566f206ba40787246149

PM: domains: Improve runtime PM performance state handling GENPD core doesn't support handling performance state changes while consumer device is runtime-suspended or when runtime PM is disabled. GENPD core may override performance state that was configured by device driver while RPM of the device was disabled or device was RPM-suspended. Let's close that gap by allowing drivers to control performance state while RPM of a consumer device is disabled and to set up performance state of RPM-suspended device that will be applied by GENPD core on RPM-resume of the device. Fixes: 5937c3ce2122 ("PM: domains: Drop/restore performance state votes for devices at runtime PM") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

view details

Colin Ian King

commit sha 0b3a8738b76fe2087f7bc2bd59f4c78504c79180

perf/x86/intel/uncore: Fix integer overflow on 23 bit left shift of a u32 The u32 variable pci_dword is being masked with 0x1fffffff and then left shifted 23 places. The shift is a u32 operation,so a value of 0x200 or more in pci_dword will overflow the u32 and only the bottow 32 bits are assigned to addr. I don't believe this was the original intent. Fix this by casting pci_dword to a resource_size_t to ensure no overflow occurs. Note that the mask and 12 bit left shift operation does not need this because the mask SNR_IMC_MMIO_MEM0_MASK and shift is always a 32 bit value. Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Addresses-Coverity: ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20210706114553.28249-1-colin.king@canonical.com

view details

push time in 24 days

PR opened distcc/distcc

Restrict number of retries when backoff is disabled

Since the commit a7dd5cf90e8c ("Try a new host after failing to connect instead of immediately falling back to localhost") distcc tries to choose a different host on connection/protocol errors. However when backoff is disabled (DISTCC_BACKOFF_PERIOD=0) distcc keeps retrying forever.

To avoid the problem limit the number of retries (currently to 3) when backoff is disabled.

Closes: #434

+41 -17

0 comment

3 changed files

pr created time in 24 days

create barnchasheplyakov/distcc

branch : fix-434

created branch time in 24 days

issue commentdistcc/distcc

DISTCC_SSH regression in v3.4

Using git bisect I traced this change in behavior to commit a7dd5cf using the following command: DISTCC_BACKOFF_PERIOD=0 DISTCC_FALLBACK=0 DISTCC_VERBOSE=1 DISTCC_HOSTS='@localhost' ./distcc gcc -c test.c -o test.o

With DISTCC_BACKOFF_PERIOD=0 distcc won't mark failed connection attempts. As a result when no hosts can be reached distcc will retry forever. Before a7dd5cf distcc would fallback to the local compilation after the first failed connection attempt (which might be a bit annoying).

KSmanis

comment created time in 24 days

push eventaltlinux/linux-be-m1000

Krzysztof Hałasa

commit sha 7cca7c8096e2c8a4149405438329b5035d0744f0

gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats Video captured in 1400x1050 resolution (bytesperline aka stride = 1408 bytes) is invalid. Fix it. Signed-off-by: Krzysztof Halasa <khalasa@piap.pl> Link: https://lore.kernel.org/r/m3y2bmq7a4.fsf@t19.piap.pl [p.zabel@pengutronix.de: added "gpu: ipu-v3:" prefix to commit description] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

view details

Philipp Zabel

commit sha 72fc2752f91b40312e493afe0a72e7c76ae27990

drm/imx: ipuv3-plane: fix accidental partial revert of 8 pixel alignment fix This fixes an accidental partial revert of commit 94dfec48fca7 ("drm/imx: Add 8 pixel alignment fix") during a rebase of commit fc1e985b67f9 ("drm/imx: ipuv3-plane: add color encoding and range properties"). Fixes: fc1e985b67f9 ("drm/imx: ipuv3-plane: add color encoding and range properties") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20210816131728.30987-1-p.zabel@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

view details

Jacob Keller

commit sha a8f89fa27773a8c96fd09fb4e2f4892d794f21f6

ice: do not abort devlink info if board identifier can't be found The devlink dev info command reports version information about the device and firmware running on the board. This includes the "board.id" field which is supposed to represent an identifier of the board design. The ice driver uses the Product Board Assembly identifier for this. In some cases, the PBA is not present in the NVM. If this happens, devlink dev info will fail with an error. Instead, modify the ice_info_pba function to just exit without filling in the context buffer. This will cause the board.id field to be skipped. Log a dev_dbg message in case someone wants to confirm why board.id is not showing up for them. Fixes: e961b679fb0b ("ice: add board identifier info to devlink .info_get") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20210819223451.245613-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>

view details

Xiaolong Huang

commit sha 7e78c597c3ebfd0cb329aa09a838734147e4f117

net: qrtr: fix another OOB Read in qrtr_endpoint_post This check was incomplete, did not consider size is 0: if (len != ALIGN(size, 4) + hdrlen) goto err; if size from qrtr_hdr is 0, the result of ALIGN(size, 4) will be 0, In case of len == hdrlen and size == 0 in header this check won't fail and if (cb->type == QRTR_TYPE_NEW_SERVER) { /* Remote node endpoint can bridge other distant nodes */ const struct qrtr_ctrl_pkt *pkt = data + hdrlen; qrtr_node_assign(node, le32_to_cpu(pkt->server.node)); } will also read out of bound from data, which is hdrlen allocated block. Fixes: 194ccc88297a ("net: qrtr: Support decoding incoming v2 packets") Fixes: ad9d24c9429e ("net: qrtr: fix OOB Read in qrtr_endpoint_post") Signed-off-by: Xiaolong Huang <butterflyhuangxx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Petko Manolov

commit sha ffc9c3ebb4af870a121da99826e9ccb63dc8b3d7

net: usb: pegasus: fixes of set_register(s) return value evaluation; - restore the behavior in enable_net_traffic() to avoid regressions - Jakub Kicinski; - hurried up and removed redundant assignment in pegasus_open() before yet another checker complains; Fixes: 8a160e2e9aeb ("net: usb: pegasus: Check the return value of get_geristers() and friends;") Reported-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Petko Manolov <petko.manolov@konsulko.com> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Aaron Ma

commit sha 4b79959510e6612d80f8d86022e0cb44eee6f4a2

igc: fix page fault when thunderbolt is unplugged After unplug thunderbolt dock with i225, pciehp interrupt is triggered, remove call will read/write mmio address which is already disconnected, then cause page fault and make system hang. Check PCI state to remove device safely. Trace: BUG: unable to handle page fault for address: 000000000000b604 Oops: 0000 [#1] SMP NOPTI RIP: 0010:igc_rd32+0x1c/0x90 [igc] Call Trace: igc_ptp_suspend+0x6c/0xa0 [igc] igc_ptp_stop+0x12/0x50 [igc] igc_remove+0x7f/0x1c0 [igc] pci_device_remove+0x3e/0xb0 __device_release_driver+0x181/0x240 Fixes: 13b5b7fd6a4a ("igc: Add support for Tx/Rx rings") Fixes: b03c49cde61f ("igc: Save PTP time before a reset") Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>

view details

Toshiki Nishioka

commit sha 691bd4d7761992914a0e83c27a4ce57d01474cda

igc: Use num_tx_queues when iterating over tx_ring queue Use num_tx_queues rather than the IGC_MAX_TX_QUEUES fixed number 4 when iterating over tx_ring queue since instantiated queue count could be less than 4 where on-line cpu count is less than 4. Fixes: ec50a9d437f0 ("igc: Add support for taprio offloading") Signed-off-by: Toshiki Nishioka <toshiki.nishioka@intel.com> Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Tested-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Acked-by: Sasha Neftin <sasha.neftin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>

view details

Sasha Neftin

commit sha 44a13a5d99c71bf9e1676d9e51679daf4d7b3d73

e1000e: Fix the max snoop/no-snoop latency for 10M We should decode the latency and the max_latency before directly compare. The latency should be presented as lat_enc = scale x value: lat_enc_d = (lat_enc & 0x0x3ff) x (1U << (5*((max_ltr_enc & 0x1c00) >> 10))) Fixes: cf8fb73c23aa ("e1000e: add support for LTR on I217/I218") Suggested-by: Yee Li <seven.yi.lee@gmail.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>

view details

Sasha Neftin

commit sha 4051f68318ca9f3d3becef3b54e70ad2c146df97

e1000e: Do not take care about recovery NVM checksum On new platforms, the NVM is read-only. Attempting to update the NVM is causing a lockup to occur. Do not attempt to write to the NVM on platforms where it's not supported. Emit an error message when the NVM checksum is invalid. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213667 Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake") Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Suggested-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>

view details

Christian König

commit sha 2a7b9a8437130fd328001f4edfac8eec98dfe298

drm/amdgpu: use the preferred pin domain after the check For some reason we run into an use case where a BO is already pinned into GTT, but should be pinned into VRAM|GTT again. Handle that case gracefully as well. Reviewed-by: Shashank Sharma <Shashank.sharma@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org

view details

Michel Dänzer

commit sha 32bc8f8373d2d6a681c96e4b25dca60d4d1c6016

drm/amdgpu: Cancel delayed work when GFXOFF is disabled schedule_delayed_work does not push back the work if it was already scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms after the first time GFXOFF was disabled and re-enabled, even if GFXOFF was disabled and re-enabled again during those 100 ms. This resulted in frame drops / stutter with the upcoming mutter 41 release on Navi 14, due to constantly enabling GFXOFF in the HW and disabling it again (for getting the GPU clock counter). To fix this, call cancel_delayed_work_sync when the disable count transitions from 0 to 1, and only schedule the delayed work on the reverse transition, not if the disable count was already 0. This makes sure the delayed work doesn't run at unexpected times, and allows it to be lock-free. v2: * Use cancel_delayed_work_sync & mutex_trylock instead of mod_delayed_work. v3: * Make amdgpu_device_delay_enable_gfx_off lock-free (Christian König) v4: * Fix race condition between amdgpu_gfx_off_ctrl incrementing adev->gfx.gfx_off_req_count and amdgpu_device_delay_enable_gfx_off checking for it to be 0 (Evan Quan) Cc: stable@vger.kernel.org Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> # v3 Acked-by: Christian König <christian.koenig@amd.com> # v3 Signed-off-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

view details

Marc Zyngier

commit sha 12d125b4574bd7f602802d94d7b4a55d85aa8e25

stmmac: Revert "stmmac: align RX buffers" This reverts commit a955318fe67e ("stmmac: align RX buffers"), which breaks at least one platform (Nvidia Jetson-X1), causing packet corruption. This is 100% reproducible, and reverting the patch results in a working system again. Given that it is "only" a performance optimisation, let's return to a known working configuration until we can have a good understanding of what is happening here. Fixes: a955318fe67e ("stmmac: align RX buffers") Cc: Matteo Croce <mcroce@linux.microsoft.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Link: https://lore.kernel.org/netdev/871r71azjw.wl-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210820183002.457226-1-maz@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>

view details

Shreyansh Chouhan

commit sha 1d011c4803c72f3907eccfc1ec63caefb852fcbf

ip_gre: add validation for csum_start Validate csum_start in gre_handle_offloads before we call _gre_xmit so that we do not crash later when the csum_start value is used in the lco_csum function call. This patch deals with ipv4 code. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Reported-by: syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Shreyansh Chouhan

commit sha 9cf448c200ba9935baa94e7a0964598ce947db9d

ip6_gre: add validation for csum_start Validate csum_start in gre_handle_offloads before we call _gre_xmit so that we do not crash later when the csum_start value is used in the lco_csum function call. This patch deals with ipv6 code. Fixes: Fixes: b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions") Reported-by: syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Christophe JAILLET

commit sha 5ed74b03eb4d08f5dd281dcb5f1c9bb92b363a8d

xgene-v2: Fix a resource leak in the error handling path of 'xge_probe()' A successful 'xge_mdio_config()' call should be balanced by a corresponding 'xge_mdio_remove()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: ea8ab16ab225 ("drivers: net: xgene-v2: Add MDIO support") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

David S. Miller

commit sha 46002bf3007ce0387be73d0c9640ee7cd2de4788

Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2021-08-20 This series contains updates to igc and e1000e drivers. Aaron Ma resolves a page fault which occurs when thunderbolt is unplugged for igc. Toshiki Nishioka fixes Tx queue looping to use actual number of queues instead of max value for igc. Sasha fixes an incorrect latency comparison by decoding the values before comparing and prevents attempted writes to read-only NVMs for e1000e. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Wong Vee Khee

commit sha 82a44ae113b7b35850f4542f0443fcab221e376a

net: stmmac: fix kernel panic due to NULL pointer dereference of plat->est In the case of taprio offload is not enabled, the error handling path causes a kernel crash due to kernel NULL pointer deference. Fix this by adding check for NULL before attempt to access 'plat->est' on the mutex_lock() call. The following kernel panic is observed without this patch: RIP: 0010:mutex_lock+0x10/0x20 Call Trace: tc_setup_taprio+0x482/0x560 [stmmac] kmem_cache_alloc_trace+0x13f/0x490 taprio_disable_offload.isra.0+0x9d/0x180 [sch_taprio] taprio_destroy+0x6c/0x100 [sch_taprio] qdisc_create+0x2e5/0x4f0 tc_modify_qdisc+0x126/0x740 rtnetlink_rcv_msg+0x12b/0x380 _raw_spin_lock_irqsave+0x19/0x40 _raw_spin_unlock_irqrestore+0x18/0x30 create_object+0x212/0x340 rtnl_calcit.isra.0+0x110/0x110 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x191/0x230 netlink_sendmsg+0x243/0x470 sock_sendmsg+0x5e/0x60 ____sys_sendmsg+0x20b/0x280 copy_msghdr_from_user+0x5c/0x90 __mod_memcg_state+0x87/0xf0 ___sys_sendmsg+0x7c/0xc0 lru_cache_add+0x7f/0xa0 _raw_spin_unlock+0x16/0x30 wp_page_copy+0x449/0x890 handle_mm_fault+0x921/0xfc0 __sys_sendmsg+0x59/0xa0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ---[ end trace b1f19b24368a96aa ]--- Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Maxim Kiselev

commit sha 359f4cdd7d78fdf8c098713b05fee950a730f131

net: marvell: fix MVNETA_TX_IN_PRGRS bit number According to Armada XP datasheet bit at 0 position is corresponding for TxInProg indication. Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Oleksij Rempel

commit sha 7a141e64cf14099d84e530db0e86fcb2c489e341

net: usb: asix: ax88772: move embedded PHY detection as early as possible Some HW revisions need additional MAC configuration before the embedded PHY can be enabled. If this is not done, we won't be able to get response from the internal PHY. This issue was detected on chipcode == AX_AX88772_CHIPCODE variant, where ax88772_hw_reset() was executed with missing embd_phy flag. Fixes: e532a096be0e ("net: usb: asix: ax88772: add phylib support") Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

Oleksij Rempel

commit sha 1406e8cb4b05fdc67692b1af2da39d7ca5278713

net: usb: asix: do not call phy_disconnect() for ax88178 Fix crash on reboot on a system with ASIX AX88178 USB adapter attached to it: | asix 1-1.4:1.0 eth0: unregister 'asix' usb-ci_hdrc.0-1.4, ASIX AX88178 USB 2.0 Ethernet | 8<--- cut here --- | Unable to handle kernel NULL pointer dereference at virtual address 0000028c | pgd = 5ec93aee | [0000028c] *pgd=00000000 | Internal error: Oops: 5 [#1] PREEMPT SMP ARM | Modules linked in: | CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 5.14.0-rc1-20210811-1 #4 | Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) | PC is at phy_disconnect+0x8/0x48 | LR is at ax88772_unbind+0x14/0x20 | [<80650d04>] (phy_disconnect) from [<80741aa4>] (ax88772_unbind+0x14/0x20) | [<80741aa4>] (ax88772_unbind) from [<8074e250>] (usbnet_disconnect+0x48/0xd8) | [<8074e250>] (usbnet_disconnect) from [<807655e0>] (usb_unbind_interface+0x78/0x25c) | [<807655e0>] (usb_unbind_interface) from [<805b03a0>] (__device_release_driver+0x154/0x20c) | [<805b03a0>] (__device_release_driver) from [<805b0478>] (device_release_driver+0x20/0x2c) | [<805b0478>] (device_release_driver) from [<805af944>] (bus_remove_device+0xcc/0xf8) | [<805af944>] (bus_remove_device) from [<805ab26c>] (device_del+0x178/0x4b0) | [<805ab26c>] (device_del) from [<807634a4>] (usb_disable_device+0xcc/0x178) | [<807634a4>] (usb_disable_device) from [<8075a060>] (usb_disconnect+0xd8/0x238) | [<8075a060>] (usb_disconnect) from [<8075a02c>] (usb_disconnect+0xa4/0x238) | [<8075a02c>] (usb_disconnect) from [<8075a02c>] (usb_disconnect+0xa4/0x238) | [<8075a02c>] (usb_disconnect) from [<80af3520>] (usb_remove_hcd+0xa0/0x198) | [<80af3520>] (usb_remove_hcd) from [<807902e0>] (host_stop+0x38/0xa8) | [<807902e0>] (host_stop) from [<8078d9e4>] (ci_hdrc_remove+0x3c/0x118) | [<8078d9e4>] (ci_hdrc_remove) from [<805b27ec>] (platform_remove+0x20/0x50) | [<805b27ec>] (platform_remove) from [<805b03a0>] (__device_release_driver+0x154/0x20c) | [<805b03a0>] (__device_release_driver) from [<805b0478>] (device_release_driver+0x20/0x2c) | [<805b0478>] (device_release_driver) from [<805af944>] (bus_remove_device+0xcc/0xf8) | [<805af944>] (bus_remove_device) from [<805ab26c>] (device_del+0x178/0x4b0) For this adapter we call ax88178_bind() and ax88772_unbind(), which is related to different chip version and different counter part *bind() function. Since this chip is currently not ported to the PHYLIB, we do not need to call phy_disconnect() here. So, to fix this crash, we need to add ax88178_unbind(). Fixes: e532a096be0e ("net: usb: asix: ax88772: add phylib support") Reported-by: Robin van der Gracht <robin@protonic.nl> Tested-by: Robin van der Gracht <robin@protonic.nl> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>

view details

push time in a month

push eventaltlinux/linux-be-m1000

J. Bruce Fields

commit sha 1e8c6f23b183f40fcb4e8fbc4e558b6f125db967

nfsd: move fsnotify on client creation outside spinlock [ Upstream commit 934bd07fae7e55232845f909f78873ab8678ca74 ] This was causing a "sleeping function called from invalid context" warning. I don't think we need the set_and_test_bit() here; clients move from unconfirmed to confirmed only once, under the client_lock. The (conf == unconf) is a way to check whether we're in that confirming case, hopefully that's not too obscure. Fixes: 472d155a0631 "nfsd: report client confirmation status in "info" file" Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Trond Myklebust

commit sha e8a8bb8dca84a8f590f0293b5d42c62e370ab931

nfsd: Reduce contention for the nfsd_file nf_rwsem [ Upstream commit 474bc334698df98ce07c890f1898c7e7f389b0c7 ] When flushing out the unstable file writes as part of a COMMIT call, try to perform most of of the data writes and waits outside the semaphore. This means that if the client is sending the COMMIT as part of a memory reclaim operation, then it can continue performing I/O, with contention for the lock occurring only once the data sync is finished. Fixes: 5011af4c698a ("nfsd: Fix stable writes") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Tested-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Chuck Lever

commit sha 7605bff387a9972038b217b6c60998778dbae931

NFSD: Prevent a possible oops in the nfs_dirent() tracepoint [ Upstream commit 7b08cf62b1239a4322427d677ea9363f0ab677c6 ] The double copy of the string is a mistake, plus __assign_str() uses strlen(), which is wrong to do on a string that isn't guaranteed to be NUL-terminated. Fixes: 6019ce0742ca ("NFSD: Add a tracepoint to record directory entry encoding") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

J. Bruce Fields

commit sha 650e6f383a6eb40f7c0a010982a74ab4b6893870

nfsd: fix NULL dereference in nfs3svc_encode_getaclres [ Upstream commit ab1016d39cc052064e32f25ad18ef8767a0ee3b8 ] In error cases the dentry may be NULL. Before 20798dfe249a, the encoder also checked dentry and d_really_is_positive(dentry), but that looks like overkill to me--zero status should be enough to guarantee a positive dentry. This isn't the first time we've seen an error-case NULL dereference hidden in the initialization of a local variable in an xdr encoder. But I went back through the other recent rewrites and didn't spot any similar bugs. Reported-by: JianHong Yin <jiyin@redhat.com> Reviewed-by: Chuck Lever III <chuck.lever@oracle.com> Fixes: 20798dfe249a ("NFSD: Update the NFSv3 GETACL result encoder...") Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Zhen Lei

commit sha eaa0eb7020f7c71ae37b1bc51ffc435e0cfcdb69

ALSA: isa: Fix error return code in snd_cmi8330_probe() [ Upstream commit 31028cbed26a8afa25533a10425ffa2ab794c76c ] When 'SB_HW_16' check fails, the error code -ENODEV instead of 0 should be returned, which is the same as that returned when 'WSS_HW_CMI8330' check fails. Fixes: 43bcd973d6d0 ("[ALSA] Add snd_card_set_generic_dev() call to ISA drivers") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210707074051.2663-1-thunder.leizhen@huawei.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Eli Cohen

commit sha 8e0bfe5edb790d24728017942242137399e01485

vdpa/mlx5: Clear vq ready indication upon device reset [ Upstream commit e3aadf2e1614174dc81d52cbb9dabb77913b11c6 ] After device reset, the virtqueues are not ready so clear the ready field. Failing to do so can result in virtio_vdpa failing to load if the device was previously used by vhost_vdpa and the old values are ready. virtio_vdpa expects to find VQs in "not ready" state. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen <elic@nvidia.com> Link: https://lore.kernel.org/r/20210606053128.170399-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

David Hildenbrand

commit sha 382f21675997ce101f13d7d635b3fbc5aceeed11

virtio-mem: don't read big block size in Sub Block Mode [ Upstream commit 500817bf5e110ad9b7138bc582971bb7ee77d6f7 ] We are reading a Big Block Mode value while in Sub Block Mode when initializing. Fortunately, vm->bbm.bb_size maps to some counter in the vm->sbm.mb_count array, which is 0 at that point in time. No harm done; still, this was unintended and is not future-proof. Fixes: 4ba50cd3355d ("virtio-mem: Big Block Mode (BBM) memory hotplug") Signed-off-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20210602185720.31821-2-david@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Dave Wysochanski

commit sha 9d94a3f255da41c6a3d17a2378b7e5f3a64f6186

NFS: Ensure nfs_readpage returns promptly when internal error occurs commit e0340f16a08d031de54ed91d26f57c9a966a776a upstream. A previous refactoring of nfs_readpage() might end up calling wait_on_page_locked_killable() even if readpage_async_filler() failed with an internal error and pg_error was non-zero (for example, if nfs_create_request() failed). In the case of an internal error, skip over wait_on_page_locked_killable() as this is only needed when the read is sent and an error occurs during completion handling. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Dave Wysochanski

commit sha 65d105e0014c171381aef276192c0a61604be961

NFS: Fix fscache read from NFS after cache error [ Upstream commit ba512c1bc3232124567a59a3995c773dc79716e8 ] Earlier commits refactored some NFS read code and removed nfs_readpage_async(), but neglected to properly fixup nfs_readpage_from_fscache_complete(). The code path is only hit when something unusual occurs with the cachefiles backing filesystem, such as an IO error or while a cookie is being invalidated. Mark page with PG_checked if fscache IO completes in error, unlock the page, and let the VM decide to re-issue based on PG_uptodate. When the VM reissues the readpage, PG_checked allows us to skip over fscache and read from the server. Link: https://marc.info/?l=linux-nfs&m=162498209518739 Fixes: 1e83b173b266 ("NFS: Add nfs_pageio_complete_read() and remove nfs_readpage_async()") Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Trond Myklebust

commit sha f90295b4b64189ac12c90615fcf8f1356ac2fa8b

NFSv4/pnfs: Fix the layout barrier update [ Upstream commit aa95edf309ef31e2df4a37ebf0e5c2ca2a6772ab ] If we have multiple outstanding layoutget requests, the current code to update the layout barrier assumes that the outstanding layout stateids are updated in order. That's not necessarily the case. Instead of using the value of lo->plh_outstanding as a guesstimate for the window of values we need to accept, just wait to update the window until we're processing the last one. The intention here is just to ensure that we don't process 2^31 seqid updates without also updating the barrier. Fixes: 1bcf34fdac5f ("pNFS/NFSv4: Update the layout barrier when we schedule a layoutreturn") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Trond Myklebust

commit sha a43389b7df966d23d595ba34ed43f8c322562f92

NFSv4/pnfs: Fix layoutget behaviour after invalidation [ Upstream commit 0b77f97a7e42adc72bd566ff8cb733ea426f74f6 ] If the layout gets invalidated, we should wait for any outstanding layoutget requests for that layout to complete, and we should resend them only after re-establishing the layout stateid. Fixes: d29b468da4f9 ("pNFS/NFSv4: Improve rejection of out-of-order layouts") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Trond Myklebust

commit sha a5d3913911f12b1cc35471c7a357c7cb0668f8e5

NFSv4/pNFS: Don't call _nfs4_pnfs_v3_ds_connect multiple times [ Upstream commit f46f84931a0aa344678efe412d4b071d84d8a805 ] After we grab the lock in nfs4_pnfs_ds_connect(), there is no check for whether or not ds->ds_clp has already been initialised, so we can end up adding the same transports multiple times. Fixes: fc821d59209d ("pnfs/NFSv4.1: Add multipath capabilities to pNFS flexfiles servers over NFSv3") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Nathan Chancellor

commit sha 91a711977033168e7a7abe06637558169ee7ab7d

hexagon: handle {,SOFT}IRQENTRY_TEXT in linker script [ Upstream commit 6fef087d0d37ba7dba8f3d75566eb4c256cd6742 ] Patch series "hexagon: Fix build error with CONFIG_STACKDEPOT and select CONFIG_ARCH_WANT_LD_ORPHAN_WARN". This series fixes an error with ARCH=hexagon that was pointed out by the patch "mm/slub: use stackdepot to save stack trace in objects". The first patch fixes that error by handling the '.irqentry.text' and '.softirqentry.text' sections. The second patch switches Hexagon over to the common DISCARDS macro, which should have been done when Hexagon was merged into the tree to match commit 023bf6f1b8bf ("linker script: unify usage of discard definition"). The third patch selects CONFIG_ARCH_WANT_LD_ORPHAN_WARN so that something like this does not happen again. This patch (of 3): Patch "mm/slub: use stackdepot to save stack trace in objects" in -mm selects CONFIG_STACKDEPOT when CONFIG_STACKTRACE_SUPPORT is selected and CONFIG_STACKDEPOT requires IRQENTRY_TEXT and SOFTIRQENTRY_TEXT to be handled after commit 505a0ef15f96 ("kasan: stackdepot: move filter_irq_stacks() to stackdepot.c") due to the use of the __{,soft}irqentry_text_{start,end} section symbols. If those sections are not handled, the build is broken. $ make ARCH=hexagon CROSS_COMPILE=hexagon-linux- LLVM=1 LLVM_IAS=1 defconfig all ... ld.lld: error: undefined symbol: __irqentry_text_start >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a ld.lld: error: undefined symbol: __irqentry_text_end >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a ld.lld: error: undefined symbol: __softirqentry_text_start >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a ld.lld: error: undefined symbol: __softirqentry_text_end >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a >>> referenced by stackdepot.c >>> stackdepot.o:(filter_irq_stacks) in archive lib/built-in.a ... Add these sections to the Hexagon linker script so the build continues to work. ld.lld's orphan section warning would have caught this prior to the -mm commit mentioned above: ld.lld: warning: kernel/built-in.a(softirq.o):(.softirqentry.text) is being placed in '.softirqentry.text' ld.lld: warning: kernel/built-in.a(softirq.o):(.softirqentry.text) is being placed in '.softirqentry.text' ld.lld: warning: kernel/built-in.a(softirq.o):(.softirqentry.text) is being placed in '.softirqentry.text' Link: https://lkml.kernel.org/r/20210521011239.1332345-1-nathan@kernel.org Link: https://lkml.kernel.org/r/20210521011239.1332345-2-nathan@kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1381 Fixes: 505a0ef15f96 ("kasan: stackdepot: move filter_irq_stacks() to stackdepot.c") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Brian Cain <bcain@codeaurora.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Nathan Chancellor

commit sha 700ecdcb3e057a3e17ba921cda91bb8940232278

hexagon: use common DISCARDS macro [ Upstream commit 681ba73c72302214686401e707e2087ed11a6556 ] ld.lld warns that the '.modinfo' section is not currently handled: ld.lld: warning: kernel/built-in.a(workqueue.o):(.modinfo) is being placed in '.modinfo' ld.lld: warning: kernel/built-in.a(printk/printk.o):(.modinfo) is being placed in '.modinfo' ld.lld: warning: kernel/built-in.a(irq/spurious.o):(.modinfo) is being placed in '.modinfo' ld.lld: warning: kernel/built-in.a(rcu/update.o):(.modinfo) is being placed in '.modinfo' The '.modinfo' section was added in commit 898490c010b5 ("moduleparam: Save information about built-in modules in separate file") to the DISCARDS macro but Hexagon has never used that macro. The unification of DISCARDS happened in commit 023bf6f1b8bf ("linker script: unify usage of discard definition") in 2009, prior to Hexagon being added in 2011. Switch Hexagon over to the DISCARDS macro so that anything that is expected to be discarded gets discarded. Link: https://lkml.kernel.org/r/20210521011239.1332345-3-nathan@kernel.org Fixes: e95bf452a9e2 ("Hexagon: Add configuration and makefiles for the Hexagon architecture.") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Brian Cain <bcain@codeaurora.org> Cc: David Rientjes <rientjes@google.com> Cc: Oliver Glitta <glittao@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Corentin Labbe

commit sha f499d706e21e478a76eed210fdc4cf88c23ae671

ARM: dts: gemini-rut1xx: remove duplicate ethernet node [ Upstream commit 3d3bb3d27cd371d3edb43eeb1beb8ae4e92a356d ] Two ethernet node was added by commit 95220046a62c ("ARM: dts: Add ethernet to a bunch of platforms") and commit d6d0cef55e5b ("ARM: dts: Add the FOTG210 USB host to Gemini boards") This patch removes the duplicate one. Fixes: d6d0cef55e5b ("ARM: dts: Add the FOTG210 USB host to Gemini boards") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Tianling Shen

commit sha 62ace4c8a6fcdb98f98562579ab7f35fe36cbccb

arm64: dts: rockchip: rename LED label for NanoPi R4S [ Upstream commit 6a11ffc2cc54d89719d5b2f3ca44244cebd7ed2e ] However "sys" is not a valid function, and it is always on. Let's keep existing functions. Fixes: db792e9adbf85f ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S") Suggested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tianling Shen <cnsztl@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20210426114652.29542-1-cnsztl@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Chen-Yu Tsai

commit sha 3b5eb8cd04a2c061a207796cd547a058cbf97cee

arm64: dts: rockchip: Drop fephy pinctrl from gmac2phy on rk3328 rock-pi-e [ Upstream commit e6526f90696e6a7d722d04b958f15b97d6fd9ce6 ] Turns out the fephy pins are already claimed in the phy node, which is rightfully where they should be claimed. Drop the pinctrl properties from the gmac2phy node for the ROCK Pi E. Fixes: b918e81f2145 ("arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20210426095916.14574-1-wens@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Geert Uytterhoeven

commit sha 1347d04d66f7bb201a24a7d1b7560174ad8cdefd

reset: RESET_BRCMSTB_RESCAL should depend on ARCH_BRCMSTB [ Upstream commit 42f6a76fbe85e5243f83a3ed76809b1ebbb7087e ] The Broadcom STB RESCAL reset controller is only present on Broadcom BCM7216 platforms. Hence add a dependency on ARCH_BRCMSTB, to prevent asking the user about this driver when configuring a kernel without BCM7216 support. Also, merely enabling CONFIG_COMPILE_TEST should not enable additional code, and thus should not enable this driver by default. Fixes: 4cf176e52397853e ("reset: Add Broadcom STB RESCAL reset controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Geert Uytterhoeven

commit sha 6cf18d4e190b2c51ca555bd6666000c7f96a3b4e

reset: RESET_INTEL_GW should depend on X86 [ Upstream commit 6ab9d6219f86f0db916105444813aafce626a2f4 ] The Intel Gateway reset controller is only present on Intel Gateway platforms. Hence add a dependency on X86, to prevent asking the user about this driver when configuring a kernel without Intel Gateway support. Fixes: c9aef213e38cde27 ("reset: intel: Add system reset controller driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Krzysztof Kozlowski

commit sha 7a91d9c6753190672288537a078689ffc5ea61e9

reset: a10sr: add missing of_match_table reference [ Upstream commit 466ba3c8ff4fae39e455ff8d080b3d5503302765 ] The driver defined of_device_id table but did not use it with of_match_table. This prevents usual matching via devicetree and causes a W=1 warning: drivers/reset/reset-a10sr.c:111:34: warning: ‘a10sr_reset_of_match’ defined but not used [-Wunused-const-variable=] Reported-by: kernel test robot <lkp@intel.com> Fixes: 627006820268 ("reset: Add Altera Arria10 SR Reset Controller") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210507112803.20012-1-krzysztof.kozlowski@canonical.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

push time in a month

push eventaltlinux/linux-be-m1000

Kees Cook

commit sha af092ec16e06c179632ee69e1e1713308b1e8d7d

selftests/lkdtm: Fix expected text for CR4 pinning commit c2eb472bbe25b3f360990f23b293b3fbadfa4bc0 upstream. The error text for CR4 pinning changed. Update the test to match. Fixes: a13b9d0b9721 ("x86/cpu: Use pinning mask for CR4 bits needing to be 0") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210623203936.3151093-3-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Ferry Toth

commit sha 418b333afbd55e67f7911868515051e0a7a37658

extcon: intel-mrfld: Sync hardware and software state on init commit ecb5bdff901139850fb3ca3ae2d0cccac045bc52 upstream. extcon driver for Basin Cove PMIC shadows the switch status used for dwc3 DRD to detect a change in the switch position. This change initializes the status at probe time. Cc: stable@vger.kernel.org Fixes: 492929c54791 ("extcon: mrfld: Introduce extcon driver for Basin Cove PMIC") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Yun Zhou

commit sha f9fb4986f4d81182f938d16beb4f983fe71212aa

seq_buf: Fix overflow in seq_buf_putmem_hex() commit d3b16034a24a112bb83aeb669ac5b9b01f744bb7 upstream. There's two variables being increased in that loop (i and j), and i follows the raw data, and j follows what is being written into the buffer. We should compare 'i' to MAX_MEMHEX_BYTES or compare 'j' to HEX_CHARS. Otherwise, if 'j' goes bigger than HEX_CHARS, it will overflow the destination buffer. Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/ Link: https://lkml.kernel.org/r/20210626032156.47889-1-yun.zhou@windriver.com Cc: stable@vger.kernel.org Fixes: 5e3ca0ec76fce ("ftrace: introduce the "hex" output method") Signed-off-by: Yun Zhou <yun.zhou@windriver.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Jan Kara

commit sha 8cc58a6e2c394aa48aa05f600be7d279efbafcd7

rq-qos: fix missed wake-ups in rq_qos_throttle try two commit 11c7aa0ddea8611007768d3e6b58d45dc60a19e1 upstream. Commit 545fbd0775ba ("rq-qos: fix missed wake-ups in rq_qos_throttle") tried to fix a problem that a process could be sleeping in rq_qos_wait() without anyone to wake it up. However the fix is not complete and the following can still happen: CPU1 (waiter1) CPU2 (waiter2) CPU3 (waker) rq_qos_wait() rq_qos_wait() acquire_inflight_cb() -> fails acquire_inflight_cb() -> fails completes IOs, inflight decreased prepare_to_wait_exclusive() prepare_to_wait_exclusive() has_sleeper = !wq_has_single_sleeper() -> true as there are two sleepers has_sleeper = !wq_has_single_sleeper() -> true io_schedule() io_schedule() Deadlock as now there's nobody to wakeup the two waiters. The logic automatically blocking when there are already sleepers is really subtle and the only way to make it work reliably is that we check whether there are some waiters in the queue when adding ourselves there. That way, we are guaranteed that at least the first process to enter the wait queue will recheck the waiting condition before going to sleep and thus guarantee forward progress. Fixes: 545fbd0775ba ("rq-qos: fix missed wake-ups in rq_qos_throttle") CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210607112613.25344-1-jack@suse.cz Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Paul Burton

commit sha 3cda5b7f4e29701b8e55de6bf53173b593429145

tracing: Simplify & fix saved_tgids logic commit b81b3e959adb107cd5b36c7dc5ba1364bbd31eb2 upstream. The tgid_map array records a mapping from pid to tgid, where the index of an entry within the array is the pid & the value stored at that index is the tgid. The saved_tgids_next() function iterates over pointers into the tgid_map array & dereferences the pointers which results in the tgid, but then it passes that dereferenced value to trace_find_tgid() which treats it as a pid & does a further lookup within the tgid_map array. It seems likely that the intent here was to skip over entries in tgid_map for which the recorded tgid is zero, but instead we end up skipping over entries for which the thread group leader hasn't yet had its own tgid recorded in tgid_map. A minimal fix would be to remove the call to trace_find_tgid, turning: if (trace_find_tgid(*ptr)) into: if (*ptr) ..but it seems like this logic can be much simpler if we simply let seq_read() iterate over the whole tgid_map array & filter out empty entries by returning SEQ_SKIP from saved_tgids_show(). Here we take that approach, removing the incorrect logic here entirely. Link: https://lkml.kernel.org/r/20210630003406.4013668-1-paulburton@google.com Fixes: d914ba37d714 ("tracing: Add support for recording tgid of tasks") Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Fernandes <joelaf@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Paul Burton <paulburton@google.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Paul Burton

commit sha eb81b5a37dc55e8d8042c81672bf7b0e24ff89e1

tracing: Resize tgid_map to pid_max, not PID_MAX_DEFAULT commit 4030a6e6a6a4a42ff8c18414c9e0c93e24cc70b8 upstream. Currently tgid_map is sized at PID_MAX_DEFAULT entries, which means that on systems where pid_max is configured higher than PID_MAX_DEFAULT the ftrace record-tgid option doesn't work so well. Any tasks with PIDs higher than PID_MAX_DEFAULT are simply not recorded in tgid_map, and don't show up in the saved_tgids file. In particular since systemd v243 & above configure pid_max to its highest possible 1<<22 value by default on 64 bit systems this renders the record-tgids option of little use. Increase the size of tgid_map to the configured pid_max instead, allowing it to cover the full range of PIDs up to the maximum value of PID_MAX_LIMIT if the system is configured that way. On 64 bit systems with pid_max == PID_MAX_LIMIT this will increase the size of tgid_map from 256KiB to 16MiB. Whilst this 64x increase in memory overhead sounds significant 64 bit systems are presumably best placed to accommodate it, and since tgid_map is only allocated when the record-tgid option is actually used presumably the user would rather it spends sufficient memory to actually record the tgids they expect. The size of tgid_map could also increase for CONFIG_BASE_SMALL=y configurations, but these seem unlikely to be systems upon which people are both configuring a large pid_max and running ftrace with record-tgid anyway. Of note is that we only allocate tgid_map once, the first time that the record-tgid option is enabled. Therefore its size is only set once, to the value of pid_max at the time the record-tgid option is first enabled. If a user increases pid_max after that point, the saved_tgids file will not contain entries for any tasks with pids beyond the earlier value of pid_max. Link: https://lkml.kernel.org/r/20210701172407.889626-2-paulburton@google.com Fixes: d914ba37d714 ("tracing: Add support for recording tgid of tasks") Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Fernandes <joelaf@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Paul Burton <paulburton@google.com> [ Fixed comment coding style ] Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Lv Yunlong

commit sha 0c2bc1489104abcc738b5762a3de6238fd23ffa5

ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe commit 9272e5d0028d45a3b45b58c9255e6e0df53f7ad9 upstream. In the out_err_bus_register error branch of tpci200_pci_probe, tpci200->info->cfg_regs is freed by tpci200_uninstall()-> tpci200_unregister()->pci_iounmap(..,tpci200->info->cfg_regs) in the first time. But later, iounmap() is called to free tpci200->info->cfg_regs again. My patch sets tpci200->info->cfg_regs to NULL after tpci200_uninstall() to avoid the double free. Fixes: cea2f7cdff2af ("Staging: ipack/bridges/tpci200: Use the TPCI200 in big endian mode") Cc: stable <stable@vger.kernel.org> Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Link: https://lore.kernel.org/r/20210524093205.8333-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Jeremy Linton

commit sha 048624ad564cb2b52ad4552a7e87942acefe0b3e

coresight: Propagate symlink failure commit 51dd19a7e9f8fbbb7cd92b8a357091911eae7f78 upstream. If the symlink is unable to be created, the driver goes ahead and continues device creation. Instead lets propagate the failure, and fail the probe. Link: https://lore.kernel.org/r/20210526204042.2681700-1-jeremy.linton@arm.com Fixes: 8a7365c2d418 ("coresight: Expose device connections via sysfs") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20210614175901.532683-7-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Sai Prakash Ranjan

commit sha 35c1c4bd2d59ad734129d4e232af9d1098023918

coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer() commit 5fae8a946ac2df879caf3f79a193d4766d00239b upstream. commit 6f755e85c332 ("coresight: Add helper for inserting synchronization packets") removed trailing '\0' from barrier_pkt array and updated the call sites like etb_update_buffer() to have proper checks for barrier_pkt size before read but missed updating tmc_update_etf_buffer() which still reads barrier_pkt past the array size resulting in KASAN out-of-bounds bug. Fix this by adding a check for barrier_pkt size before accessing like it is done in etb_update_buffer(). BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698 Read of size 4 at addr ffffffd05b7d1030 by task perf/2629 Call trace: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 print_address_description+0x3c/0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc/0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x400 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c/0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 el0_svc_compat+0x10/0x50 The buggy address belongs to the variable: barrier_pkt+0x10/0x40 Memory state around the buggy address: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ================================================================== Link: https://lore.kernel.org/r/20210505093430.18445-1-saiprakash.ranjan@codeaurora.org Fixes: 0c3fc4d5fa26 ("coresight: Add barrier packet for synchronisation") Cc: stable@vger.kernel.org Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20210614175901.532683-6-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Damien Le Moal

commit sha cbc03ffec260c28cd177fee143f2fe74cc36ba00

dm zoned: check zone capacity commit bab68499428ed934f0493ac74197ed6f36204260 upstream. The dm-zoned target cannot support zoned block devices with zones that have a capacity smaller than the zone size (e.g. NVMe zoned namespaces) due to the current chunk zone mapping implementation as it is assumed that zones and chunks have the same size with all blocks usable. If a zoned drive is found to have zones with a capacity different from the zone size, fail the target initialization. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Mikulas Patocka

commit sha 1b5918b087b1dd7bf193340f25ca63c50a277638

dm writecache: flush origin device when writing and cache is full commit ee55b92a7391bf871939330f662651b54be51b73 upstream. Commit d53f1fafec9d086f1c5166436abefdaef30e0363 ("dm writecache: do direct write if the cache is full") changed dm-writecache, so that it writes directly to the origin device if the cache is full. Unfortunately, it doesn't forward flush requests to the origin device, so that there is a bug where flushes are being ignored. Fix this by adding missing flush forwarding. For PMEM mode, we fix this bug by disabling direct writes to the origin device, because it performs better. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: d53f1fafec9d ("dm writecache: do direct write if the cache is full") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Hou Tao

commit sha ba47e65a5de3e0e8270301a409fc63d3129fdb9e

dm btree remove: assign new_root only when removal succeeds commit b6e58b5466b2959f83034bead2e2e1395cca8aeb upstream. remove_raw() in dm_btree_remove() may fail due to IO read error (e.g. read the content of origin block fails during shadowing), and the value of shadow_spine::root is uninitialized, but the uninitialized value is still assign to new_root in the end of dm_btree_remove(). For dm-thin, the value of pmd->details_root or pmd->root will become an uninitialized value, so if trying to read details_info tree again out-of-bound memory may occur as showed below: general protection fault, probably for non-canonical address 0x3fdcb14c8d7520 CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6 Hardware name: QEMU Standard PC RIP: 0010:metadata_ll_load_ie+0x14/0x30 Call Trace: sm_metadata_count_is_more_than_one+0xb9/0xe0 dm_tm_shadow_block+0x52/0x1c0 shadow_step+0x59/0xf0 remove_raw+0xb2/0x170 dm_btree_remove+0xf4/0x1c0 dm_pool_delete_thin_device+0xc3/0x140 pool_message+0x218/0x2b0 target_message+0x251/0x290 ctl_ioctl+0x1c4/0x4d0 dm_ctl_ioctl+0xe/0x20 __x64_sys_ioctl+0x7b/0xb0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixing it by only assign new_root when removal succeeds Signed-off-by: Hou Tao <houtao1@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Konstantin Kharlamov

commit sha f147115018aabe71e25a9fd85b1212b81b7ab622

PCI: Leave Apple Thunderbolt controllers on for s2idle or standby commit 4694ae373dc2114f9a82f6ae15737e65af0c6dea upstream. On Macbook 2013, resuming from suspend-to-idle or standby resulted in the external monitor no longer being detected, a stacktrace, and errors like this in dmesg: pcieport 0000:06:00.0: can't change power state from D3hot to D0 (config space inaccessible) The reason is that we know how to turn power to the Thunderbolt controller *off* via the SXIO/SXFP/SXLF methods, but we don't know how to turn power back on. We have to rely on firmware to turn the power back on. When going to the "suspend-to-idle" or "standby" system sleep states, firmware is not involved either on the suspend side or the resume side, so we can't use SXIO/SXFP/SXLF to turn the power off. Skip SXIO/SXFP/SXLF when firmware isn't involved in suspend, e.g., when we're going to the "suspend-to-idle" or "standby" system sleep states. Fixes: 1df5172c5c25 ("PCI: Suspend/resume quirks for Apple thunderbolt") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212767 Link: https://lore.kernel.org/r/20210520235501.917397-1-Hi-Angel@yandex.ru Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Pali Rohár

commit sha 130919708990b1718dea512a5954c7170706a87e

PCI: aardvark: Fix checking for PIO Non-posted Request commit 8ceeac307a79f68c0d0c72d6e48b82fa424204ec upstream. PIO_NON_POSTED_REQ for PIO_STAT register is incorrectly defined. Bit 10 in register PIO_STAT indicates the response is to a non-posted request. Link: https://lore.kernel.org/r/20210624213345.3617-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Pali Rohár

commit sha e2c1218ddc5f97031159be0bc835a5190893d29d

PCI: aardvark: Implement workaround for the readback value of VEND_ID commit 7f71a409fe3d9358da07c77f15bb5b7960f12253 upstream. Marvell Armada 3700 Functional Errata, Guidelines, and Restrictions document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243): The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it should read 11ABh. The firmware can write the correct value, 11ABh, through VEND_ID (RD0076044h [15:0]). Implement this workaround in aardvark driver for both PCI vendor id and PCI subsystem vendor id. This change affects and fixes PCI vendor id of emulated PCIe root bridge. After this change emulated PCIe root bridge has correct vendor id. Link: https://lore.kernel.org/r/20210624222621.4776-5-pali@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Arnd Bergmann

commit sha db317a37229b2dd338c4b9348310ca47e462ca67

media: subdev: disallow ioctl for saa6588/davinci commit 0a7790be182d32b9b332a37cb4206e24fe94b728 upstream. The saa6588_ioctl() function expects to get called from other kernel functions with a 'saa6588_command' pointer, but I found nothing stops it from getting called from user space instead, which seems rather dangerous. The same thing happens in the davinci vpbe driver with its VENC_GET_FLD command. As a quick fix, add a separate .command() callback pointer for this driver and change the two callers over to that. This change can easily get backported to stable kernels if necessary, but since there are only two drivers, we may want to eventually replace this with a set of more specialized callbacks in the long run. Fixes: c3fda7f835b0 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Johan Hovold

commit sha dbd58d39784451abab29ee624f0f6055e42d8766

media: dtv5100: fix control-request directions commit 8c8b9a9be2afa8bd6a72ad1130532baab9fab89d upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the control requests which erroneously used usb_rcvctrlpipe(). Fixes: 8466028be792 ("V4L/DVB (8734): Initial support for AME DTV-5100 USB2.0 DVB-T") Cc: stable@vger.kernel.org # 2.6.28 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Pavel Skripkin

commit sha c57bfd8000d7677bf435873b440eec0c47f73a08

media: zr364xx: fix memory leak in zr364xx_start_readpipe commit 0a045eac8d0427b64577a24d74bb8347c905ac65 upstream. syzbot reported memory leak in zr364xx driver. The problem was in non-freed urb in case of usb_submit_urb() fail. backtrace: [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline] [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576 Fixes: ccbf035ae5de ("V4L/DVB (12278): zr364xx: implement V4L2_CAP_STREAMING") Cc: stable@vger.kernel.org Reported-by: syzbot+af4fa391ef18efdd5f69@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Johan Hovold

commit sha de95c0bd797ac384441b3a5760022886e63e1545

media: gspca/sq905: fix control-request direction commit 53ae298fde7adcc4b1432bce2dbdf8dac54dfa72 upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the USB_REQ_SYNCH_FRAME request which erroneously used usb_sndctrlpipe(). Fixes: 27d35fc3fb06 ("V4L/DVB (10639): gspca - sq905: New subdriver.") Cc: stable@vger.kernel.org # 2.6.30 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Johan Hovold

commit sha 31874b6b63dd83eb6d5e58264bd6b08c5b39eca6

media: gspca/sunplus: fix zero-length control requests commit b4bb4d425b7b02424afea2dfdcd77b3b4794175e upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the single zero-length control request which was using the read-register helper, and update the helper so that zero-length reads fail with an error message instead. Fixes: 6a7eba24e4f0 ("V4L/DVB (8157): gspca: all subdrivers") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

push time in a month

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha d7d542dd0d81b5536c03771b55ab2b0fafa6c0b4

altinstall: serve ISOs via anonymous FTP

view details

push time in a month

push eventaltlinux/linux-be-m1000

Maor Gottlieb

commit sha da78fe5fb35737058de52364484ffed74e7d329b

RDMA/mlx5: Fix crash when unbind multiport slave Fix the below crash when deleting a slave from the unaffiliated list twice. First time when the slave is bound to the master and the second when the slave is unloaded. Fix it by checking if slave is unaffiliated (doesn't have ib device) before removing from the list. RIP: 0010:mlx5r_mp_remove+0x4e/0xa0 [mlx5_ib] Call Trace: auxiliary_bus_remove+0x18/0x30 __device_release_driver+0x177/x220 device_release_driver+0x24/0x30 bus_remove_device+0xd8/0x140 device_del+0x18a/0x3e0 mlx5_rescan_drivers_locked+0xa9/0x210 [mlx5_core] mlx5_unregister_device+0x34/0x60 [mlx5_core] mlx5_uninit_one+0x32/0x100 [mlx5_core] remove_one+0x6e/0xe0 [mlx5_core] pci_device_remove+0x36/0xa0 __device_release_driver+0x177/0x220 device_driver_detach+0x3c/0xa0 unbind_store+0x113/0x130 kernfs_fop_write_iter+0x110/0x1a0 new_sync_write+0x116/0x1a0 vfs_write+0x1ba/0x260 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 93f8244431ad ("RDMA/mlx5: Convert mlx5_ib to use auxiliary bus") Link: https://lore.kernel.org/r/17ec98989b0ba88f7adfbad68eb20bce8d567b44.1628587493.git.leonro@nvidia.com Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Gal Pressman

commit sha f6018cc4602659e0e608849529704f3f41276c28

RDMA/uverbs: Track dmabuf memory regions The dmabuf memory registrations are missing the restrack handling and hence do not appear in rdma tool. Fixes: bfe0cc6eb249 ("RDMA/uverbs: Add uverbs command for dma-buf based MR registration") Link: https://lore.kernel.org/r/20210812135607.6228-1-galpress@amazon.com Signed-off-by: Gal Pressman <galpress@amazon.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Naresh Kumar PBS

commit sha 17f2569dce1848080825b8336e6b7c6900193b44

RDMA/bnxt_re: Add missing spin lock initialization Add the missing initialization of srq lock. Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Link: https://lore.kernel.org/r/1629343553-5843-3-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Naresh Kumar PBS <nareshkumar.pbs@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Lukas Bulwahn

commit sha 0032640204a7d73bef163638c34a4642f8c9ed07

RDMA/irdma: Use correct kconfig symbol for AUXILIARY_BUS In Kconfig, references to config symbols do not use the prefix "CONFIG_". Commit fa0cf568fd76 ("RDMA/irdma: Add irdma Kconfig/Makefile and remove i40iw") selects config CONFIG_AUXILIARY_BUS in config INFINIBAND_IRDMA, but intended to select config AUXILIARY_BUS. Fixes: fa0cf568fd76 ("RDMA/irdma: Add irdma Kconfig/Makefile and remove i40iw") Link: https://lore.kernel.org/r/20210817084158.10095-1-lukas.bulwahn@gmail.com Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Tuo Li

commit sha cbe71c61992c38f72c2b625b2ef25916b9f0d060

IB/hfi1: Fix possible null-pointer dereference in _extend_sdma_tx_descs() kmalloc_array() is called to allocate memory for tx->descp. If it fails, the function __sdma_txclean() is called: __sdma_txclean(dd, tx); However, in the function __sdma_txclean(), tx-descp is dereferenced if tx->num_desc is not zero: sdma_unmap_desc(dd, &tx->descp[0]); To fix this possible null-pointer dereference, assign the return value of kmalloc_array() to a local variable descp, and then assign it to tx->descp if it is not NULL. Otherwise, go to enomem. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210806133029.194964-1-islituo@gmail.com Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo@gmail.com> Tested-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Acked-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Dinghao Liu

commit sha a036ad088306a88de87e973981f2b9224e466c3f

RDMA/bnxt_re: Remove unpaired rtnl unlock in bnxt_re_dev_init() The fixed commit removes all rtnl_lock() and rtnl_unlock() calls in function bnxt_re_dev_init(), but forgets to remove a rtnl_unlock() in the error handling path of bnxt_re_register_netdev(), which may cause a deadlock. This bug is suggested by a static analysis tool. Fixes: c2b777a95923 ("RDMA/bnxt_re: Refactor device add/remove functionalities") Link: https://lore.kernel.org/r/20210816085531.12167-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Acked-by: Selvin Xavier <selvin.xavier@broadcom.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Bob Pearson

commit sha 65a81b61d8c5e96748671824cc46339afbd831d0

RDMA/rxe: Fix memory allocation while in a spin lock rxe_mcast_add_grp_elem() in rxe_mcast.c calls rxe_alloc() while holding spinlocks which in turn calls kzalloc(size, GFP_KERNEL) which is incorrect. This patch replaces rxe_alloc() by rxe_alloc_locked() which uses GFP_ATOMIC. This bug was caused by the below mentioned commit and failing to handle the need for the atomic allocate. Fixes: 4276fd0dddc9 ("RDMA/rxe: Remove RXE_POOL_ATOMIC") Link: https://lore.kernel.org/r/20210813210625.4484-1-rpearsonhpe@gmail.com Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Gal Pressman

commit sha dbe986bdfd6dfe6ef24b833767fff4151e024357

RDMA/efa: Free IRQ vectors on error flow Make sure to free the IRQ vectors in case the allocation doesn't return the expected number of IRQs. Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module") Link: https://lore.kernel.org/r/20210811151131.39138-2-galpress@amazon.com Reviewed-by: Firas JahJah <firasj@amazon.com> Reviewed-by: Yossi Leybovich <sleybo@amazon.com> Signed-off-by: Gal Pressman <galpress@amazon.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Xiao Yang

commit sha cc4f596cf85e97ca6606e1bd10b3b9851ef52ddf

RDMA/rxe: Zero out index member of struct rxe_queue 1) New index member of struct rxe_queue was introduced but not zeroed so the initial value of index may be random. 2) The current index is not masked off to index_mask. In this case producer_addr() and consumer_addr() will get an invalid address by the random index and then accessing the invalid address triggers the following panic: "BUG: unable to handle page fault for address: ffff9ae2c07a1414" Fix the issue by using kzalloc() to zero out index member. Fixes: 5bcf5a59c41e ("RDMA/rxe: Protext kernel index from user space") Link: https://lore.kernel.org/r/20210820111509.172500-1-yangx.jy@fujitsu.com Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

view details

Linus Torvalds

commit sha d5ae8d7f85b7f6f6e60f1af8ff4be52b0926fde1

Revert "media: dvb header files: move some headers to staging" This reverts commit 819fbd3d8ef36c09576c2a0ffea503f5c46e9177. It turns out that some user-space applications use these uapi header files, so even though the only user of the interface is an old driver that was moved to staging, moving the header files causes unnecessary pain. Generally, we really don't want user space to use kernel headers directly (exactly because it causes pain when we re-organize), and instead copy them as needed. But these things happen, and the headers were in the uapi directory, so I guess it's not entirely unreasonable. Link: https://lore.kernel.org/lkml/4e3e0d40-df4a-94f8-7c2d-85010b0873c4@web.de/ Reported-by: Soeren Moch <smoch@web.de> Cc: stable@kernel.org # 5.13 Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

view details

Linus Torvalds

commit sha 6e764bcd1cf72a2846c0e53d3975a09b242c04c9

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Pull rdma fixes from Jason Gunthorpe: "Several small fixes, the first three are significant: - mlx5 crash unloading drivers with a rare HW config - missing userspace reporting for the new dmabuf objects - random rxe failure due to missing memory zeroing - static checker/etc reports: missing spin lock init, null pointer deref on error, extra unlock on error path, memory allocation under spinlock, missing IRQ vector cleanup - kconfig typo in the new irdma driver" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/rxe: Zero out index member of struct rxe_queue RDMA/efa: Free IRQ vectors on error flow RDMA/rxe: Fix memory allocation while in a spin lock RDMA/bnxt_re: Remove unpaired rtnl unlock in bnxt_re_dev_init() IB/hfi1: Fix possible null-pointer dereference in _extend_sdma_tx_descs() RDMA/irdma: Use correct kconfig symbol for AUXILIARY_BUS RDMA/bnxt_re: Add missing spin lock initialization RDMA/uverbs: Track dmabuf memory regions RDMA/mlx5: Fix crash when unbind multiport slave

view details

Alexey Sheplyakov

commit sha 1949f6763f68d0bf755b576b06f084cbf84a2efe

BE-M1000: Kconfig, defconfig

view details

Alexey Sheplyakov

commit sha 24913ecf5000893535c1d5cd2f655b8608bfe513

BE-M1000: clock driver This version works with firmware from SDK-M 4.4, 5.1, and 5.2

view details

Alexey Sheplyakov

commit sha 8f08413e7a1d0707f878908fa29ce6e15c3113ec

cpufreq-dt: don't load on BE-M1000 SoC Apparently the driver deadlocks the kernel in a few minutes: [ 454.690508] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 454.696839] (detected by 4, t=26002 jiffies, g=22561, q=15) [ 454.703017] rcu: All QSes seen, last rcu_preempt kthread activity 25992 (4295121102-4295095110), jiffies_till_next_fqs=3, root ->qsmask 0x0 [ 454.715570] rcu: rcu_preempt kthread starved for 25992 jiffies! g22561 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=1 [ 454.726117] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. [ 454.735273] rcu: RCU grace-period kthread stack dump: [ 454.740344] task:rcu_preempt state:R stack: 0 pid: 13 ppid: 2 flags:0x00000028 [ 454.748731] Call trace: [ 454.751204] __switch_to+0x114/0x170 [ 454.754803] __schedule+0x370/0xa3c [ 454.758310] schedule+0x50/0x104 [ 454.761557] schedule_timeout+0x9c/0x114 [ 454.765503] rcu_gp_kthread+0x598/0xb50 [ 454.769360] kthread+0x150/0x160 [ 454.772607] ret_from_fork+0x10/0x38 [ 454.778130] [ 454.779631] ================================ [ 454.783912] WARNING: inconsistent lock state [ 454.788196] 5.10.17-00041-g454ed3004040-dirty #1 Not tainted [ 454.793867] -------------------------------- [ 454.798147] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 454.804168] swapper/4/0 [HC0[0]:SC1[1]:HE0:SE0] takes: [ 454.809319] ffff800011198498 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x480/0xce0 [ 454.817615] {IN-HARDIRQ-W} state was registered at: [ 454.822508] __lock_acquire+0xad8/0x2094 [ 454.826530] lock_acquire.part.0+0xfc/0x360 [ 454.830813] lock_acquire+0x68/0x84 [ 454.834399] _raw_spin_lock_irqsave+0x84/0x158 [ 454.838941] rcu_exp_handler+0xcc/0x140 [ 454.842878] flush_smp_call_function_queue+0xec/0x304 [ 454.848029] generic_smp_call_function_single_interrupt+0x20/0x2c [ 454.854225] ipi_handler+0x1d8/0x39c [ 454.857899] handle_percpu_devid_fasteoi_ipi+0xb0/0xe0 [ 454.863137] __handle_domain_irq+0xbc/0x13c [ 454.867419] gic_handle_irq+0xcc/0x14c [ 454.871265] el1_irq+0xc4/0x180 [ 454.874504] lock_acquire.part.0+0x120/0x360 [ 454.878873] lock_acquire+0x68/0x84 [ 454.882461] lock_page_memcg+0x5c/0x150 [ 454.886399] page_add_file_rmap+0x28/0x27c [ 454.890595] alloc_set_pte+0xb8/0x5c0 [ 454.894356] filemap_map_pages+0x4a4/0x4c0 [ 454.898551] handle_mm_fault+0xbcc/0xf50 [ 454.902572] do_page_fault+0x14c/0x404 [ 454.906418] do_translation_fault+0xbc/0xd8 [ 454.910701] do_mem_abort+0x4c/0xac [ 454.914287] el0_ia+0x68/0xcc [ 454.917351] el0_sync_handler+0x180/0x1b0 [ 454.921458] el0_sync+0x174/0x180 [ 454.924868] irq event stamp: 449729 [ 454.928368] hardirqs last enabled at (449725): [<ffff8000109fcf74>] default_idle_call+0x24/0xdc [ 454.937171] hardirqs last disabled at (449726): [<ffff8000109f27a0>] enter_el1_irq_or_nmi+0x10/0x20 [ 454.946237] softirqs last enabled at (449728): [<ffff8000100532f0>] _local_bh_enable+0x30/0x54 [ 454.954952] softirqs last disabled at (449729): [<ffff8000100534c4>] __irq_exit_rcu+0x1b0/0x1bc [ 454.963665] [ 454.963665] other info that might help us debug this: [ 454.970206] Possible unsafe locking scenario: [ 454.970206] [ 454.976136] CPU0 [ 454.978590] ---- [ 454.981043] lock(rcu_node_0); [ 454.984198] <Interrupt> [ 454.986825] lock(rcu_node_0); [ 454.990155] [ 454.990155] *** DEADLOCK *** [ 454.990155] [ 454.996087] 1 lock held by swapper/4/0: [ 454.999932] #0: ffff800011198498 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x480/0xce0 [ 455.008662] [ 455.008662] stack backtrace: [ 455.013033] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.10.17-00041-g454ed3004040-dirty #1 [ 455.021313] Hardware name: Baikal Electronics Baikal-M mitx board (DT) [ 455.027854] Call trace: [ 455.030311] dump_backtrace+0x0/0x1e4 [ 455.033985] show_stack+0x24/0x80 [ 455.037312] dump_stack+0xec/0x154 [ 455.040723] print_usage_bug.part.0+0x208/0x22c [ 455.045265] mark_lock+0x88c/0x934 [ 455.048677] mark_held_locks+0x58/0x90 [ 455.052437] lockdep_hardirqs_on_prepare+0xe4/0x23c [ 455.057330] trace_hardirqs_on+0x78/0x2e0 [ 455.061350] __do_softirq+0x114/0x6d0 [ 455.065022] __irq_exit_rcu+0x1b0/0x1bc [ 455.068868] irq_exit+0x1c/0x54 [ 455.072020] __handle_domain_irq+0xc0/0x13c [ 455.076214] gic_handle_irq+0xcc/0x14c [ 455.079972] el1_irq+0xc4/0x180 [ 455.083124] arch_cpu_idle+0x18/0x30 [ 455.086710] default_idle_call+0x5c/0xdc [ 455.090645] do_idle+0x260/0x2e0 [ 455.093883] cpu_startup_entry+0x30/0x8c [ 455.097818] secondary_start_kernel+0x138/0x184 [ 455.102410] BUG: scheduling while atomic: swapper/4/0/0x00000002 [ 455.108449] INFO: lockdep is turned off. [ 455.112399] Modules linked in: dm_mod designware_i2s sdhci_of_dwcmshc snd_soc_core sdhci_pltfm dw_hdmi_ahb_audio snd_pcm_dmaengine ac97_bus evdev sdhci snd_pcm at24 panfrost mmc_core snd_timer pcie_baikal_v44 snd pcie_baikal bt1_pvt gpu_sched soundcore cpufreq_dt fuse configfs efivarfs ipv6 [ 455.138295] Preemption disabled at: [ 455.138305] [<ffff800010028c64>] secondary_start_kernel+0xb4/0x184 [ 455.148020] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.10.17-00041-g454ed3004040-dirty #1 [ 455.156299] Hardware name: Baikal Electronics Baikal-M mitx board (DT) [ 455.162840] Call trace: [ 455.165296] dump_backtrace+0x0/0x1e4 [ 455.168969] show_stack+0x24/0x80 [ 455.172295] dump_stack+0xec/0x154 [ 455.175711] __schedule_bug+0xcc/0xe0 [ 455.179383] __schedule+0x928/0xa3c [ 455.182881] schedule_idle+0x34/0x5c [ 455.186467] do_idle+0x1dc/0x2e0 [ 455.189706] cpu_startup_entry+0x30/0x8c [ 455.193640] secondary_start_kernel+0x138/0x184

view details

Alexey Sheplyakov

commit sha d88354e8ffb4340807d4a1d7de1bc10ca1c60de9

efi-rtc: avoid calling efi.get_time on BE-M1000 SoC UEFI does NOT provide get_time at the runtime, hence calling it results in an Oops.

view details

Vadim V. Vlasov

commit sha b592355f60cc7844e22f9924509f4d3c2f731fd5

Serial: 82550_dw: Fix clock rate setting in dw8250_set_termios() If clk_round_rate() returns rate out of 1/16 precision range from the desired rate, then do not change clock rate. This usually happens if the desired rate is below the minimum supported by the clk. Fixes UART console on BE-M1000 SoC (without this patch the console gets garbled after loading the driver)

view details

Alexey Sheplyakov

commit sha d08017dbf3ceef24267e49033e9bf646be38abaf

Fixed secondary CPUs boot on BE-M1000 SoC The secure world on BE-M1000 SoC denies execution attempts outside of the ranges [0x80000000, 0x8FFFFFFF] [0xA0000000, 0xBFFFFFFF]. Thus PSCI calls to boot secondary CPUs fail unless the kernel image resides in one of these (physical) address ranges. However BE-M1000's UEFI PE/COFF loader puts the kernel into the forbidden range. Since the alignment is good enough EFI stub does not try to relocate the kernel. As a result secondary CPUs fail to boot. Relocation to a random address is not going to work either. Therefore automatically disable kaslr on "known bad" systems (for now only BE-M1000 ones) and forcibly relocate the kernel to a low(er) address.

view details

Alexey Sheplyakov

commit sha 152e9843424e6ee4f385d761bb785ca69f64bdad

BE-M1000: USB glue driver

view details

Alexey Sheplyakov

commit sha 42d01efdf51ba4c4bbadad456f6ae04f072eea3e

net: fwnode_get_phy_id: consider all compatible strings Commit cf99686072a1b7037a1d782b66037b2b722bf2c9 ("of: mdio: Refactor of_get_phy_id()") has broken Ethernet on TF307 board (and possibly other boards based on BE-M1000/BE-T1000 SoCs). That commit replaces `of_get_phy_id` with `fwnode_get_phy_id`. And `fwnode_get_phy_id` considers only the 1st compatible string to find out phy_id. This works well for all in-tree DTBs, since PHY nodes in those DTBs either 1) have "ethernet-phy-idNNNN.MMMM" as the first compatible string 2) don't have any "compatible" strings at all However DTB embedded in TF307 firmware describes PHY like this: gmac0_phy: ethernet-phy@3 { compatible = "micrel,ksz9031", "ethernet-phy-id0022.1620", "ethernet-phy-ieee802.3-c22"; reg = <0x3>; }; That is, the 1st compatible string is "micrel,ksz9031". Thus `fwnode_get_phy_id` is unable to parse phy_id, and `stmmac_mdio_register` fails. As a result Ethernet driver is unable to attach to PHY, and can't send/receive anything. To avoid the problem this patch adjusts `fwnode_get_phy_id` to consider *all* compatible strings. Signed-off-by: Alexey Sheplyakov <asheplyakov@altlinux.org>

view details

Alexey Sheplyakov

commit sha 206d5c7096d2af316fa6137be41765ec69ef3f38

ethernet: stmmac: made dwmac1000_* DMA functions available for reuse Some variants of dwmac hardware (in particular the one in the BE-M1000 SoC) need custom DMA reset, and can reuse other dwmac1000 DMA functions. (cherry picked from commit f8e6ec3642eb28e7b74c0a7875310d7354895c8a)

view details

push time in a month

push eventaltlinux/linux-be-m1000

Rahul Tanwar

commit sha e2f55370b42205bda2f8b02c5933b9df2456bd53

MAINTAINERS: Add Rahul Tanwar as Intel LGM Gateway PCIe maintainer Add Rahul Tanwar as maintainer for PCIe RC controller driver for the Intel Lightning Mountain (LGM) Gateway SoC. Link: https://lore.kernel.org/r/b3249e08155e04ac08d820be3b8da29a913c472a.1625559158.git.rtanwar@maxlinear.com Signed-off-by: Rahul Tanwar <rtanwar@maxlinear.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

view details

Bjorn Andersson

commit sha d66cd5dea551e974580a64bf80b337b9a09ce63e

cpufreq: blacklist Qualcomm sc8180x in cpufreq-dt-platdev The Qualcomm SC8180x platform uses the qcom-cpufreq-hw driver, so it in the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

view details

Ezequiel Garcia

commit sha 0fbea680540108b09db7b26d9f4d24236d58a6ad

iommu/dma: Fix leak in non-contiguous API Currently, iommu_dma_alloc_noncontiguous() allocates a struct dma_sgt_handle object to hold some state needed for iommu_dma_free_noncontiguous(). However, the handle is neither freed nor returned explicitly by the ->alloc_noncontiguous method, and therefore seems leaked. This was found by code inspection, so please review carefully and test. As a side note, it appears the struct dma_sgt_handle type is exposed to users of the DMA-API by linux/dma-map-ops.h, but is has no users or functions returning the type explicitly. This may indicate it's a good idea to move the struct dma_sgt_handle type to drivers/iommu/dma-iommu.c. The decision is left to maintainers :-) Cc: stable@vger.kernel.org Fixes: e817ee5f2f95c ("dma-iommu: implement ->alloc_noncontiguous") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210723010552.50969-1-ezequiel@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>

view details

Frank Wunderlich

commit sha 5aa95d8834e07907e64937d792c12ffef7fb271f

iommu: Check if group is NULL before remove device If probe_device is failing, iommu_group is not initialized because iommu_group_add_device is not reached, so freeing it will result in NULL pointer access. iommu_bus_init ->bus_iommu_probe ->probe_iommu_group in for each:/* return -22 in fail case */ ->iommu_probe_device ->__iommu_probe_device /* return -22 here.*/ -> ops->probe_device /* return -22 here.*/ -> iommu_group_get_for_dev -> ops->device_group -> iommu_group_add_device //good case ->remove_iommu_group //in fail case, it will remove group ->iommu_release_device ->iommu_group_remove_device // here we don't have group In my case ops->probe_device (mtk_iommu_probe_device from mtk_iommu_v1.c) is due to failing fwspec->ops mismatch. Fixes: d72e31c93746 ("iommu: IOMMU Groups") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Link: https://lore.kernel.org/r/20210731074737.4573-1-linux@fw-web.de Signed-off-by: Joerg Roedel <jroedel@suse.de>

view details

Michał Mirosław

commit sha 335ffab3ef864539e814b9a2903b0ae420c1c067

opp: remove WARN when no valid OPPs remain This WARN can be triggered per-core and the stack trace is not useful. Replace it with plain dev_err(). Fix a comment while at it. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

view details

Lukasz Luba

commit sha f7d635883fb73414c7c4e2648b42adc296c5d40d

cpufreq: arm_scmi: Fix error path when allocation failed Stop the initialization when cpumask allocation failed and return an error. Fixes: 80a064dbd556 ("scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

view details

Vincent Whitchurch

commit sha 25f8203b4be1937c4939bb98623e67dcfd7da4d1

mmc: dw_mmc: Fix hang on data CRC error When a Data CRC interrupt is received, the driver disables the DMA, then sends the stop/abort command and then waits for Data Transfer Over. However, sometimes, when a data CRC error is received in the middle of a multi-block write transfer, the Data Transfer Over interrupt is never received, and the driver hangs and never completes the request. The driver sets the BMOD.SWR bit (SDMMC_IDMAC_SWRESET) when stopping the DMA, but according to the manual CMD.STOP_ABORT_CMD should be programmed "before assertion of SWR". Do these operations in the recommended order. With this change the Data Transfer Over is always received correctly in my tests. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

view details

Christophe Kerello

commit sha d8e193f13b07e6c0ffaa1a999386f1989f2b4c5e

mmc: mmci: stm32: Check when the voltage switch procedure should be done If the card has not been power cycled, it may still be using 1.8V signaling. This situation is detected in mmc_sd_init_card function and should be handled in mmci stm32 variant. The host->pwr_reg variable is also correctly protected with spin locks. Fixes: 94b94a93e355 ("mmc: mmci_sdmmc: Implement signal voltage callbacks") Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210701143353.13188-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

view details

Shaik Sajida Bhanu

commit sha 67b13f3e221ed81b46a657e2b499bf8b20162476

mmc: sdhci-msm: Update the software timeout value for sdhc Whenever SDHC run at clock rate 50MHZ or below, the hardware data timeout value will be 21.47secs, which is approx. 22secs and we have a current software timeout value as 10secs. We have to set software timeout value more than the hardware data timeout value to avioid seeing the below register dumps. [ 332.953670] mmc2: Timeout waiting for hardware interrupt. [ 332.959608] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 332.966450] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 [ 332.973256] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 [ 332.980054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000027 [ 332.986864] mmc2: sdhci: Present: 0x01f801f6 | Host ctl: 0x0000001f [ 332.993671] mmc2: sdhci: Power: 0x00000001 | Blk gap: 0x00000000 [ 333.000583] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 [ 333.007386] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 [ 333.014182] mmc2: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b [ 333.020976] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 333.027771] mmc2: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x0000808f [ 333.034561] mmc2: sdhci: Cmd: 0x0000183a | Max curr: 0x00000000 [ 333.041359] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000 [ 333.048157] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 333.054945] mmc2: sdhci: Host ctl2: 0x00000000 [ 333.059657] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000ffffff218 [ 333.067178] mmc2: sdhci_msm: ----------- VENDOR REGISTER DUMP ----------- [ 333.074343] mmc2: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 [ 333.083417] mmc2: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x80040873 [ 333.092850] mmc2: sdhci_msm: Vndr func: 0x00008a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040 [ 333.102371] mmc2: sdhci: ============================================ So, set software timeout value more than hardware timeout value. Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1626435974-14462-1-git-send-email-sbhanu@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

view details

Thara Gopinath

commit sha 5d79e5ce5489b489cbc4c327305be9dfca0fc9ce

cpufreq: blocklist Qualcomm sm8150 in cpufreq-dt-platdev The Qualcomm sm8150 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

view details

Dong Aisheng

commit sha 283f1b9a0401859c53fdd6483ab66f1c4fadaea5

clk: imx6q: fix uart earlycon unwork The earlycon depends on the bootloader setup UART clocks being retained. There're actually two uart clocks (ipg, per) on MX6QDL, but the 'Fixes' commit change to register only one which means another clock may be disabled during booting phase and result in the earlycon unwork. Cc: stable@vger.kernel.org # v5.10+ Fixes: 379c9a24cc23 ("clk: imx: Fix reparenting of UARTs not associated with stdout") Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20210702085438.1988087-1-aisheng.dong@nxp.com Reviewed-by: Abel Vesa <abel.vesa@nxp.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>

view details

Bjorn Andersson

commit sha 9711759a87a041705148161b937ec847048d882e

clk: qcom: gdsc: Ensure regulator init state matches GDSC state As GDSCs are registered and found to be already enabled gdsc_init() ensures that 1) the kernel state matches the hardware state, and 2) votable GDSCs are properly enabled from this master as well. But as the (optional) supply regulator is enabled deep into gdsc_toggle_logic(), which is only executed for votable GDSCs, the kernel's state of the regulator might not match the hardware. The regulator might be automatically turned off if no other users are present or the next call to gdsc_disable() would cause an unbalanced regulator_disable(). Given that the votable case deals with an already enabled GDSC, most of gdsc_enable() and gdsc_toggle_logic() can be skipped. Reduce it to just clearing the SW_COLLAPSE_MASK and enabling hardware control to simply call regulator_enable() in both cases. The enablement of hardware control seems to be an independent property from the GDSC being enabled, so this is moved outside that conditional segment. Lastly, as the propagation of ALWAYS_ON to GENPD_FLAG_ALWAYS_ON needs to happen regardless of the initial state this is grouped together with the other sc->pd updates at the end of the function. Cc: stable@vger.kernel.org Fixes: 37416e554961 ("clk: qcom: gdsc: Handle GDSC regulator supplies") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210721224056.3035016-1-bjorn.andersson@linaro.org [sboyd@kernel.org: Rephrase commit text] Signed-off-by: Stephen Boyd <sboyd@kernel.org>

view details

Marek Behún

commit sha 484f2b7c61b9ae58cc00c5127bcbcd9177af8dfe

cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when the SOC boots, the WTMI firmware sets clocks and AVS values that work correctly with 1.2 GHz CPU frequency, but random crashes occur once cpufreq driver starts scaling. We do not know currently what is the reason: - it may be that the voltage value for L0 for 1.2 GHz variant provided by the vendor in the OTP is simply incorrect when scaling is used, - it may be that some delay is needed somewhere, - it may be something else. The most sane solution now seems to be to simply forbid the cpufreq driver on 1.2 GHz variant. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

view details

Andrew Delgadillo

commit sha 017f5fb9ce793e3558db94ee72068622bc0b79db

arm64: clean vdso & vdso32 files commit a5b8ca97fbf8 ("arm64: do not descend to vdso directories twice") changes the cleaning behavior of arm64's vdso files, in that vdso.lds, vdso.so, and vdso.so.dbg are not removed upon a 'make clean/mrproper': $ make defconfig ARCH=arm64 $ make ARCH=arm64 $ make mrproper ARCH=arm64 $ git clean -nxdf Would remove arch/arm64/kernel/vdso/vdso.lds Would remove arch/arm64/kernel/vdso/vdso.so Would remove arch/arm64/kernel/vdso/vdso.so.dbg To remedy this, manually descend into arch/arm64/kernel/vdso upon cleaning. After this commit: $ make defconfig ARCH=arm64 $ make ARCH=arm64 $ make mrproper ARCH=arm64 $ git clean -nxdf <empty> Similar results are obtained for the vdso32 equivalent. Signed-off-by: Andrew Delgadillo <adelg@google.com> Cc: stable@vger.kernel.org Fixes: a5b8ca97fbf8 ("arm64: do not descend to vdso directories twice") Link: https://lore.kernel.org/r/20210810231755.1743524-1-adelg@google.com Signed-off-by: Will Deacon <will@kernel.org>

view details

jason-jh.lin

commit sha 71ac6f390f6a3017f58d05d677b961bb1f851338

drm/mediatek: Add AAL output size configuration To avoid the output width and height is incorrect, AAL_OUTPUT_SIZE configuration should be set. Fixes: 0664d1392c26 ("drm/mediatek: Add AAL engine basic function") Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

view details

jason-jh.lin

commit sha da4d4517ba70216799e3eb3b9bd71aa9dca065da

drm/mediatek: Add component_del in OVL and COLOR remove function Add component_del in OVL and COLOR remove function. Fixes: ff1395609e20 ("drm/mediatek: Move mtk_ddp_comp_init() from sub driver to DRM driver") Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

view details

Georgi Djakov

commit sha f753067494c2726d7a09ffca351d9b2599fee876

Revert "interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate" This reverts commit f84f5b6f72e68bbaeb850b58ac167e4a3a47532a, which is causing regressions on some platforms, preventing them to boot or do a clean reboot. This is because the above commit is sending also all the zero bandwidth requests to turn off any resources that might be enabled unnecessarily, but currently this may turn off interconnects that are enabled by default, but with no consumer to keep them on. Let's revert this for now as some platforms are not ready for such change yet. In the future we can introduce some _ignore_unused option that could keep also the unused resources on platforms that have only partial interconnect support and also add .shutdown callbacks to deal with disabling the resources in the right order. Reported-by: Stephen Boyd <swboyd@chromium.org> Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/CAE-0n52iVgX0JjjnYi=NDg49xP961p=+W5R2bmO+2xwRceFhfA@mail.gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>

view details

Srinivas Kandagatla

commit sha 9659281ce78de0f15a4aa124da8f7450b1399c09

slimbus: messaging: start transaction ids from 1 instead of zero As tid is unsigned its hard to figure out if the tid is valid or invalid. So Start the transaction ids from 1 instead of zero so that we could differentiate between a valid tid and invalid tids This is useful in cases where controller would add a tid for controller specific transfers. Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: <stable@vger.kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Srinivas Kandagatla

commit sha a263c1ff6abe0e66712f40d595bbddc7a35907f8

slimbus: messaging: check for valid transaction id In some usecases transaction ids are dynamically allocated inside the controller driver after sending the messages which have generic acknowledge responses. So check for this before refcounting pm_runtime. Without this we would end up imbalancing runtime pm count by doing pm_runtime_put() in both slim_do_transfer() and slim_msg_response() for a single pm_runtime_get() in slim_do_transfer() Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: <stable@vger.kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Srinivas Kandagatla

commit sha c0e38eaa8d5102c138e4f16658ea762417d42a8f

slimbus: ngd: set correct device for pm For some reason we ended up using wrong device in some places for pm_runtime calls. Fix this so that NGG driver can do runtime pm correctly. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: <stable@vger.kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210809082428.11236-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

push time in a month

push eventaltlinux/linux-be-m1000

Srinivas Kandagatla

commit sha 9a253bb42f190efd1a1c156939ad7298b3529dca

arm64: dts: qcom: c630: fix correct powerdown pin for WSA881x WSA881x powerdown pin is connected to GPIO1, GPIO2 not GPIO2 and GPIO3, so correct this. This was working so far due to a shift bug in gpio driver, however once that is fixed this will stop working, so fix this! For some reason we forgot to add this dts change in last merge cycle so currently audio is broken in 5.13 as the gpio driver fix already landed in 5.13. Reported-by: Shawn Guo <shawnguo@kernel.org> Fixes: 45021d35fcb2 ("arm64: dts: qcom: c630: Enable audio support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Shawn Guo <shawnguo@kernel.org> Link: https://lore.kernel.org/r/20210706083523.10601-1-srinivas.kandagatla@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

view details

Petr Vorel

commit sha 9d1fc2e4f5a94a492c7dd1ca577c66fdb7571c84

arm64: dts: qcom: msm8992-bullhead: Remove PSCI Bullhead firmware obviously doesn't support PSCI as it fails to boot with this definition. Fixes: 329e16d5f8fc ("arm64: dts: qcom: msm8992: Add PSCI support.") Signed-off-by: Petr Vorel <petr.vorel@gmail.com> Link: https://lore.kernel.org/r/20210713185734.380-2-petr.vorel@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

view details

Petr Vorel

commit sha 3cb6a271f4b04f11270111638c24fa5c0b846dec

arm64: dts: qcom: msm8992-bullhead: Fix cont_splash_mem mapping cont_splash_mem has different memory mapping than generic from msm8994.dtsi: [ 0.000000] cma: Found cont_splash_mem@0, memory base 0x0000000003400000, size 12 MiB, limit 0xffffffffffffffff [ 0.000000] cma: CMA: reserved 12 MiB at 0x0000000003400000 for cont_splash_mem This fixes boot. Fixes: 976d321f32dc ("arm64: dts: qcom: msm8992: Make the DT an overlay on top of 8994") Signed-off-by: Petr Vorel <petr.vorel@gmail.com> Link: https://lore.kernel.org/r/20210713185734.380-3-petr.vorel@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

view details

Sibi Sankar

commit sha 4cbb02fa76de4bbada0af9409fcce3aa747880ea

arm64: dts: qcom: sc7280: Fixup cpufreq domain info for cpu7 The SC7280 SoC supports a 4-Silver/3-Gold/1-Gold+ configuration and hence the cpu7 node should point to cpufreq domain 2 instead. Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node") Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1626800953-613-1-git-send-email-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

view details

Johannes Berg

commit sha 0f673c16c850250db386537a422c11d248fb123c

iwlwifi: pnvm: accept multiple HW-type TLVs Some products (So) may have two different types of products with different mac-type that are otherwise equivalent, and have the same PNVM data, so the PNVM file will contain two (or perhaps later more) HW-type TLVs. Accept the file and use the data section that contains any matching entry. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210719140154.a6a86e903035.Ic0b1b75c45d386698859f251518e8a5144431938@changeid

view details

Yaara Baruch

commit sha a5bf1d4434b93394fa37494d78fe9f3513557185

iwlwifi: add new SoF with JF devices Add new SoF JF devices to the driver. Signed-off-by: Yaara Baruch <yaara.baruch@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210719144523.0545d8964ff2.I3498879d8c184e42b1578a64aa7b7c99a18b75fb@changeid

view details

Yaara Baruch

commit sha 891332f697e14bfb2002f56e21d9bbd4800a7098

iwlwifi: add new so-jf devices Add new so-jf devices to the driver. Signed-off-by: Yaara Baruch <yaara.baruch@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210719144523.1c9a59fd2760.If5aef1942007828210f0f2c4a17985f63050bb45@changeid

view details

Petr Vorel

commit sha 0e5ded926f2a0f8b57dfa7f0d69a30767e1ea2ce

arm64: dts: qcom: msm8994-angler: Disable cont_splash_mem As the default definition breaks booting angler: [ 1.862561] printk: console [ttyMSM0] enabled [ 1.872260] msm_serial: driver initialized D - 15524 - pm_driver_init, Delta cont_splash_mem was introduced in 74d6d0a145835, but the problem manifested after commit '86588296acbf ("fdt: Properly handle "no-map" field in the memory region")'. Disabling it because Angler's firmware does not report where the memory is allocated (dmesg from downstream kernel): [ 0.000000] cma: Found cont_splash_mem@0, memory base 0x0000000000000000, size 16 MiB, limit 0x0000000000000000 [ 0.000000] cma: CMA: reserved 16 MiB at 0x0000000000000000 for cont_splash_mem Similar issue might be on Google Nexus 5X (lg-bullhead). Other MSM8992/4 are known to report correct address. Fixes: 74d6d0a145835 ("arm64: dts: qcom: msm8994/8994-kitakami: Fix up the memory map") Suggested-by: Konrad Dybcio <konradybcio@gmail.com> Signed-off-by: Petr Vorel <petr.vorel@gmail.com> Link: https://lore.kernel.org/r/20210622191019.23771-1-petr.vorel@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

view details

Caleb Connolly

commit sha d77c95bf9a64d8620662151b2b10efd8221f4bcc

arm64: dts: qcom: sdm845-oneplus: fix reserved-mem Fix the upper guard and the "removed_region", this fixes the random crashes which used to occur in memory intensive loads. I'm not sure WHY the upper guard being 0x2000 instead of 0x1000 doesn't fix this, but it HAS to be 0x1000. Fixes: e60fd5ac1f68 ("arm64: dts: qcom: sdm845-oneplus-common: guard rmtfs-mem") Signed-off-by: Caleb Connolly <caleb@connolly.tech> Link: https://lore.kernel.org/r/20210720153125.43389-2-caleb@connolly.tech Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

view details

Arnd Bergmann

commit sha abf3d98dee7c4038152ce88833ddc2189f68cbd4

mt76: fix enum type mismatch There is no 'NONE' version of 'enum mcu_cipher_type', and returning 'MT_CIPHER_NONE' causes a warning: drivers/net/wireless/mediatek/mt76/mt7921/mcu.c: In function 'mt7921_mcu_get_cipher': drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:114:24: error: implicit conversion from 'enum mt76_cipher_type' to 'enum mcu_cipher_type' [-Werror=enum-conversion] 114 | return MT_CIPHER_NONE; | ^~~~~~~~~~~~~~ Add the missing MCU_CIPHER_NONE defintion that fits in here with the same value. Fixes: c368362c36d3 ("mt76: fix iv and CCMP header insertion") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210721150745.1914829-1-arnd@kernel.org

view details

Maxim Kochetkov

commit sha be7ecbd240b2f9ec544d3ce6fccf4cec3cd15dca

soc: fsl: qe: convert QE interrupt controller to platform_device Since 5.13 QE's ucc nodes can't get interrupts from devicetree: ucc@2000 { cell-index = <1>; reg = <0x2000 0x200>; interrupts = <32>; interrupt-parent = <&qeic>; }; Now fw_devlink expects driver to create and probe a struct device for interrupt controller. So lets convert this driver to simple platform_device with probe(). Also use platform_get_ and devm_ family function to get/allocate resources and drop unused .compatible = "qeic". [1] - https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default") Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>

view details

Tony Lindgren

commit sha 06a089ef644934372a3062528244fca3417d3430

bus: ti-sysc: Fix error handling for sysc_check_active_timer() We have changed the return type for sysc_check_active_timer() from -EBUSY to -ENXIO, but the gpt12 system timer fix still checks for -EBUSY. We are also not returning on other errors like we did earlier as noted by Pavel Machek <pavel@denx.de>. Commit 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") should have been updated for commit 65fb73676112 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source"). Let's fix the issue by checking for -ENXIO and returning on any other errors as suggested by Pavel Machek <pavel@denx.de>. Fixes: 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") Depends-on: 65fb73676112 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source") Reported-by: Pavel Machek <pavel@denx.de> Reviewed-by: Pavel Machek (CIP) <pavel@denx.de> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Tony Lindgren <tony@atomide.com>

view details

Yonghong Song

commit sha 2d3a1e3615c5449a4583010f41a6f824a4ffa03e

bpf: Add rcu_read_lock in bpf_get_current_[ancestor_]cgroup_id() helpers Currently, if bpf_get_current_cgroup_id() or bpf_get_current_ancestor_cgroup_id() helper is called with sleepable programs e.g., sleepable fentry/fmod_ret/fexit/lsm programs, a rcu warning may appear. For example, if I added the following hack to test_progs/test_lsm sleepable fentry program test_sys_setdomainname: --- a/tools/testing/selftests/bpf/progs/lsm.c +++ b/tools/testing/selftests/bpf/progs/lsm.c @@ -168,6 +168,10 @@ int BPF_PROG(test_sys_setdomainname, struct pt_regs *regs) int buf = 0; long ret; + __u64 cg_id = bpf_get_current_cgroup_id(); + if (cg_id == 1000) + copy_test++; + ret = bpf_copy_from_user(&buf, sizeof(buf), ptr); if (len == -2 && ret == 0 && buf == 1234) copy_test++; I will hit the following rcu warning: include/linux/cgroup.h:481 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by test_progs/260: #0: ffffffffa5173360 (rcu_read_lock_trace){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x0/0xa0 stack backtrace: CPU: 1 PID: 260 Comm: test_progs Tainted: G O 5.14.0-rc2+ #176 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x56/0x7b bpf_get_current_cgroup_id+0x9c/0xb1 bpf_prog_a29888d1c6706e09_test_sys_setdomainname+0x3e/0x89c bpf_trampoline_6442469132_0+0x2d/0x1000 __x64_sys_setdomainname+0x5/0x110 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae I can get similar warning using bpf_get_current_ancestor_cgroup_id() helper. syzbot reported a similar issue in [1] for syscall program. Helper bpf_get_current_cgroup_id() or bpf_get_current_ancestor_cgroup_id() has the following callchain: task_dfl_cgroup task_css_set task_css_set_check and we have #define task_css_set_check(task, __c) \ rcu_dereference_check((task)->cgroups, \ lockdep_is_held(&cgroup_mutex) || \ lockdep_is_held(&css_set_lock) || \ ((task)->flags & PF_EXITING) || (__c)) Since cgroup_mutex/css_set_lock is not held and the task is not existing and rcu read_lock is not held, a warning will be issued. Note that bpf sleepable program is protected by rcu_read_lock_trace(). The above sleepable bpf programs are already protected by migrate_disable(). Adding rcu_read_lock() in these two helpers will silence the above warning. I marked the patch fixing 95b861a7935b ("bpf: Allow bpf_get_current_ancestor_cgroup_id for tracing") which added bpf_get_current_ancestor_cgroup_id() to tracing programs in 5.14. I think backporting 5.14 is probably good enough as sleepable progrems are not widely used. This patch should fix [1] as well since syscall program is a sleepable program protected with migrate_disable(). [1] https://lore.kernel.org/bpf/0000000000006d5cab05c7d9bb87@google.com/ Fixes: 95b861a7935b ("bpf: Allow bpf_get_current_ancestor_cgroup_id for tracing") Reported-by: syzbot+7ee5c2c09c284495371f@syzkaller.appspotmail.com Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210810230537.2864668-1-yhs@fb.com

view details

Hans de Goede

commit sha 7f45621c14a209b986cd636447bb53b7f6f881c3

platform/x86: asus-nb-wmi: Allow configuring SW_TABLET_MODE method with a module option Unfortunately we have been unable to find a reliable way to detect if and how SW_TABLET_MODE reporting is supported, so we are relying on DMI quirks for this. Add a module-option to specify the SW_TABLET_MODE method so that this can be easily tested without needing to rebuild the kernel. BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210812145513.39117-1-hdegoede@redhat.com

view details

Hans de Goede

commit sha 73fcbad691110ece47a487c9e584822070e3626f

platform/x86: asus-nb-wmi: Add tablet_mode_sw=lid-flip quirk for the TP200s The Asus TP200s / E205SA 360 degree hinges 2-in-1 supports reporting SW_TABLET_MODE info through the ASUS_WMI_DEVID_LID_FLIP WMI device-id. Add a quirk to enable this. BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210812145513.39117-2-hdegoede@redhat.com

view details

Linus Walleij

commit sha 813bacf4109802926d86f2d7c6583c6c0a0fddb5

ARM: configs: Update the nhk8815_defconfig The platform lost the framebuffer due to a commit solving a circular dependency in v5.14-rc1, so add it back in by explicitly selecting the framebuffer. Also fix up some Kconfig options that got dropped or moved around while we're at it. Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210807225518.3607126-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>

view details

Arnd Bergmann

commit sha cbfece75186d6dae6e0fe2b3492ac76eb380afdb

ARM: ixp4xx: fix building both pci drivers When both the old and the new PCI drivers are enabled in the same kernel, there are a couple of namespace conflicts that cause a build failure: drivers/pci/controller/pci-ixp4xx.c:38: error: "IXP4XX_PCI_CSR" redefined [-Werror] 38 | #define IXP4XX_PCI_CSR 0x1c | In file included from arch/arm/mach-ixp4xx/include/mach/hardware.h:23, from arch/arm/mach-ixp4xx/include/mach/io.h:15, from arch/arm/include/asm/io.h:198, from include/linux/io.h:13, from drivers/pci/controller/pci-ixp4xx.c:20: arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:221: note: this is the location of the previous definition 221 | #define IXP4XX_PCI_CSR(x) ((volatile u32 *)(IXP4XX_PCI_CFG_BASE_VIRT+(x))) | drivers/pci/controller/pci-ixp4xx.c:148:12: error: 'ixp4xx_pci_read' redeclared as different kind of symbol 148 | static int ixp4xx_pci_read(struct ixp4xx_pci *p, u32 addr, u32 cmd, u32 *data) | ^~~~~~~~~~~~~~~ Rename both the ixp4xx_pci_read/ixp4xx_pci_write functions and the IXP4XX_PCI_CSR macro. In each case, I went with the version that has fewer callers to keep the change small. Fixes: f7821b493458 ("PCI: ixp4xx: Add a new driver for IXP4xx") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: soc@kernel.org Link: https://lore.kernel.org/r/20210721151546.2325937-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>

view details

Ilya Leoshkevich

commit sha 45c709f8c71b525b51988e782febe84ce933e7e0

bpf: Clear zext_dst of dead insns "access skb fields ok" verifier test fails on s390 with the "verifier bug. zext_dst is set, but no reg is defined" message. The first insns of the test prog are ... 0: 61 01 00 00 00 00 00 00 ldxw %r0,[%r1+0] 8: 35 00 00 01 00 00 00 00 jge %r0,0,1 10: 61 01 00 08 00 00 00 00 ldxw %r0,[%r1+8] ... and the 3rd one is dead (this does not look intentional to me, but this is a separate topic). sanitize_dead_code() converts dead insns into "ja -1", but keeps zext_dst. When opt_subreg_zext_lo32_rnd_hi32() tries to parse such an insn, it sees this discrepancy and bails. This problem can be seen only with JITs whose bpf_jit_needs_zext() returns true. Fix by clearning dead insns' zext_dst. The commits that contributed to this problem are: 1. 5aa5bd14c5f8 ("bpf: add initial suite for selftests"), which introduced the test with the dead code. 2. 5327ed3d44b7 ("bpf: verifier: mark verified-insn with sub-register zext flag"), which introduced the zext_dst flag. 3. 83a2881903f3 ("bpf: Account for BPF_FETCH in insn_has_def32()"), which introduced the sanity check. 4. 9183671af6db ("bpf: Fix leakage under speculation on mispredicted branches"), which bisect points to. It's best to fix this on stable branches that contain the second one, since that's the point where the inconsistency was introduced. Fixes: 5327ed3d44b7 ("bpf: verifier: mark verified-insn with sub-register zext flag") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210812151811.184086-2-iii@linux.ibm.com

view details

Ilya Leoshkevich

commit sha 3776f3517ed94d40ff0e3851d7ce2ce17b63099f

selftests, bpf: Test that dead ldx_w insns are accepted Prevent regressions related to zero-extension metadata handling during dead code sanitization. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210812151811.184086-3-iii@linux.ibm.com

view details

Jakub Kicinski

commit sha 3c603136c9f82833813af77185618de5af67676c

bnxt: don't lock the tx queue from napi poll We can't take the tx lock from the napi poll routine, because netpoll can poll napi at any moment, including with the tx lock already held. The tx lock is protecting against two paths - the disable path, and (as Michael points out) the NETDEV_TX_BUSY case which may occur if NAPI completions race with start_xmit and both decide to re-enable the queue. For the disable/ifdown path use synchronize_net() to make sure closing the device does not race we restarting the queues. Annotate accesses to dev_state against data races. For the NAPI cleanup vs start_xmit path - appropriate barriers are already in place in the main spot where Tx queue is stopped but we need to do the same careful dance in the TX_BUSY case. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

view details

push time in a month

push eventaltlinux/linux-be-m1000

Elliot Berman

commit sha 14c4c8e41511aa8fba7fb239b20b6539b5bce201

cfi: Use rcu_read_{un}lock_sched_notrace If rcu_read_lock_sched tracing is enabled, the tracing subsystem can perform a jump which needs to be checked by CFI. For example, stm_ftrace source is enabled as a module and hooks into enabled ftrace events. This can cause an recursive loop where find_shadow_check_fn -> rcu_read_lock_sched -> (call to stm_ftrace generates cfi slowpath) -> find_shadow_check_fn -> rcu_read_lock_sched -> ... To avoid the recursion, either the ftrace codes needs to be marked with __no_cfi or CFI should not trace. Use the "_notrace" in CFI to avoid tracing so that CFI can guard ftrace. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Cc: stable@vger.kernel.org Fixes: cf68fffb66d6 ("add support for Clang CFI") Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210811155914.19550-1-quic_eberman@quicinc.com

view details

Jaroslav Kysela

commit sha a2befe9380dd04ee76c871568deca00eedf89134

ALSA: hda - fix the 'Capture Switch' value change notifications The original code in the cap_put_caller() function does not handle correctly the positive values returned from the passed function for multiple iterations. It means that the change notifications may be lost. Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851 Cc: <stable@kernel.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>

view details

Takashi Sakamoto

commit sha 67bb66d32905627e29400e2cb7f87a7c4c8cf667

ALSA: oxfw: fix functioal regression for silence in Apogee Duet FireWire OXFW 971 has no function to use the value in syt field of received isochronous packet for playback timing generation. In kernel prepatch for v5.14, ALSA OXFW driver got change to send NO_INFO value in the field instead of actual timing value. The change brings Apogee Duet FireWire to generate no playback sound, while output meter moves. As long as I investigate, _any_ value in the syt field takes the device to generate sound. It's reasonable to think that the device just ignores data blocks in packet with NO_INFO value in its syt field for audio data processing. This commit adds a new flag for the quirk to fix regression. Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210812022839.42043-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>

view details

Kristin Paget

commit sha da94692001ea45ffa1f5e9f17ecdef7aecd90c27

ALSA: hda/realtek: Enable 4-speaker output for Dell XPS 15 9510 laptop The 2021-model XPS 15 appears to use the same 4-speakers-on-ALC289 audio setup as the Precision models, so requires the same quirk to enable woofer output. Tested on my own 9510. Signed-off-by: Kristin Paget <kristin@tombom.co.uk> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/e1fc95c5-c10a-1f98-a5c2-dd6e336157e1@tombom.co.uk Signed-off-by: Takashi Iwai <tiwai@suse.de>

view details

NeilBrown

commit sha 3f79f6f6247c83f448c8026c3ee16d4636ef8d4f

btrfs: prevent rename2 from exchanging a subvol with a directory from different parents Cross-rename lacks a check when that would prevent exchanging a directory and subvolume from different parent subvolume. This causes data inconsistencies and is caught before commit by tree-checker, turning the filesystem to read-only. Calling the renameat2 with RENAME_EXCHANGE flags like renameat2(AT_FDCWD, namesrc, AT_FDCWD, namedest, (1 << 1)) on two paths: namesrc = dir1/subvol1/dir2 namedest = subvol2/subvol3 will cause key order problem with following write time tree-checker report: [1194842.307890] BTRFS critical (device loop1): corrupt leaf: root=5 block=27574272 slot=10 ino=258, invalid previous key objectid, have 257 expect 258 [1194842.322221] BTRFS info (device loop1): leaf 27574272 gen 8 total ptrs 11 free space 15444 owner 5 [1194842.331562] BTRFS info (device loop1): refs 2 lock_owner 0 current 26561 [1194842.338772] item 0 key (256 1 0) itemoff 16123 itemsize 160 [1194842.338793] inode generation 3 size 16 mode 40755 [1194842.338801] item 1 key (256 12 256) itemoff 16111 itemsize 12 [1194842.338809] item 2 key (256 84 2248503653) itemoff 16077 itemsize 34 [1194842.338817] dir oid 258 type 2 [1194842.338823] item 3 key (256 84 2363071922) itemoff 16043 itemsize 34 [1194842.338830] dir oid 257 type 2 [1194842.338836] item 4 key (256 96 2) itemoff 16009 itemsize 34 [1194842.338843] item 5 key (256 96 3) itemoff 15975 itemsize 34 [1194842.338852] item 6 key (257 1 0) itemoff 15815 itemsize 160 [1194842.338863] inode generation 6 size 8 mode 40755 [1194842.338869] item 7 key (257 12 256) itemoff 15801 itemsize 14 [1194842.338876] item 8 key (257 84 2505409169) itemoff 15767 itemsize 34 [1194842.338883] dir oid 256 type 2 [1194842.338888] item 9 key (257 96 2) itemoff 15733 itemsize 34 [1194842.338895] item 10 key (258 12 256) itemoff 15719 itemsize 14 [1194842.339163] BTRFS error (device loop1): block=27574272 write time tree block corruption detected [1194842.339245] ------------[ cut here ]------------ [1194842.443422] WARNING: CPU: 6 PID: 26561 at fs/btrfs/disk-io.c:449 csum_one_extent_buffer+0xed/0x100 [btrfs] [1194842.511863] CPU: 6 PID: 26561 Comm: kworker/u17:2 Not tainted 5.14.0-rc3-git+ #793 [1194842.511870] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 [1194842.511876] Workqueue: btrfs-worker-high btrfs_work_helper [btrfs] [1194842.511976] RIP: 0010:csum_one_extent_buffer+0xed/0x100 [btrfs] [1194842.512068] RSP: 0018:ffffa2c284d77da0 EFLAGS: 00010282 [1194842.512074] RAX: 0000000000000000 RBX: 0000000000001000 RCX: ffff928867bd9978 [1194842.512078] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff928867bd9970 [1194842.512081] RBP: ffff92876b958000 R08: 0000000000000001 R09: 00000000000c0003 [1194842.512085] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 [1194842.512088] R13: ffff92875f989f98 R14: 0000000000000000 R15: 0000000000000000 [1194842.512092] FS: 0000000000000000(0000) GS:ffff928867a00000(0000) knlGS:0000000000000000 [1194842.512095] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1194842.512099] CR2: 000055f5384da1f0 CR3: 0000000102fe4000 CR4: 00000000000006e0 [1194842.512103] Call Trace: [1194842.512128] ? run_one_async_free+0x10/0x10 [btrfs] [1194842.631729] btree_csum_one_bio+0x1ac/0x1d0 [btrfs] [1194842.631837] run_one_async_start+0x18/0x30 [btrfs] [1194842.631938] btrfs_work_helper+0xd5/0x1d0 [btrfs] [1194842.647482] process_one_work+0x262/0x5e0 [1194842.647520] worker_thread+0x4c/0x320 [1194842.655935] ? process_one_work+0x5e0/0x5e0 [1194842.655946] kthread+0x135/0x160 [1194842.655953] ? set_kthread_struct+0x40/0x40 [1194842.655965] ret_from_fork+0x1f/0x30 [1194842.672465] irq event stamp: 1729 [1194842.672469] hardirqs last enabled at (1735): [<ffffffffbd1104f5>] console_trylock_spinning+0x185/0x1a0 [1194842.672477] hardirqs last disabled at (1740): [<ffffffffbd1104cc>] console_trylock_spinning+0x15c/0x1a0 [1194842.672482] softirqs last enabled at (1666): [<ffffffffbdc002e1>] __do_softirq+0x2e1/0x50a [1194842.672491] softirqs last disabled at (1651): [<ffffffffbd08aab7>] __irq_exit_rcu+0xa7/0xd0 The corrupted data will not be written, and filesystem can be unmounted and mounted again (all changes since the last commit will be lost). Add the missing check for new_ino so that all non-subvolumes must reside under the same parent subvolume. There's an exception allowing to exchange two subvolumes from any parents as the directory representing a subvolume is only a logical link and does not have any other structures related to the parent subvolume, unlike files, directories etc, that are always in the inode namespace of the parent subvolume. Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.7+ Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: NeilBrown <neilb@suse.de> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

view details

Pingfan Liu

commit sha 6c34df6f350df9579ce99d887a2b5fa14cc13b32

tracing: Apply trace filters on all output channels The event filters are not applied on all of the output, which results in the flood of printk when using tp_printk. Unfolding event_trigger_unlock_commit_regs() into trace_event_buffer_commit(), so the filters can be applied on every output. Link: https://lkml.kernel.org/r/20210814034538.8428-1-kernelfans@gmail.com Cc: stable@vger.kernel.org Fixes: 0daa2302968c1 ("tracing: Add tp_printk cmdline to have tracepoints go to printk()") Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

view details

Imre Deak

commit sha 0165c4e19f6ec76b535de090e4bd145c73810c51

ALSA: hda: Fix hang during shutdown due to link reset During system shutdown codecs may be still active, and resetting the controller->codec HW link in this state - based on the bug reporter's tests - leads to the shutdown sequence to get stuck. This happens at least on the reporter's KBL system with an ALC662 codec. For now fix the issue by skipping the link reset step. Fixes: 472e18f63c42 ("ALSA: hda: Release controller display power during shutdown/reboot") References: https://bugzilla.kernel.org/show_bug.cgi?id=214045 References: https://gitlab.freedesktop.org/drm/intel/-/issues/3618#note_1024665 Reported-and-tested-by: youling257@gmail.com Cc: youling257@gmail.com Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20210816174259.2759103-1-imre.deak@intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>

view details

Takashi Iwai

commit sha 4bf61ad5f0204b67ba570da6e5c052c2095e29df

ALSA: hda/via: Apply runtime PM workaround for ASUS B23E ASUS B23E requires the same workaround like other machines with VT1802, otherwise it looses the codec power on a few nodes and the sound kept silence. Fixes: a0645daf1610 ("ALSA: HDA: Early Forbid of runtime PM") Link: https://lore.kernel.org/r/ac2232f142efcd67fe6ac38897f704f7176bd200.camel@gmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210817052432.14751-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>

view details

Linus Torvalds

commit sha 614cb2751d3150850d459bee596c397f344a7936

Merge tag 'trace-v5.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fix from Steven Rostedt: "Limit the shooting in the foot of tp_printk The "tp_printk" option redirects the trace event output to printk at boot up. This is useful when a machine crashes before boot where the trace events can not be retrieved by the in kernel ring buffer. But it can be "dangerous" because trace events can be located in high frequency locations such as interrupts and the scheduler, where a printk can slow it down that it live locks the machine (because by the time the printk finishes, the next event is triggered). Thus tp_printk must be used with care. It was discovered that the filter logic to trace events does not apply to the tp_printk events. This can cause a surprise and live lock when the user expects it to be filtered to limit the amount of events printed to the console when in fact it still prints everything" * tag 'trace-v5.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Apply trace filters on all output channels

view details

Linus Torvalds

commit sha 3b844826b6c6affa80755254da322b017358a2f4

pipe: avoid unnecessary EPOLLET wakeups under normal loads I had forgotten just how sensitive hackbench is to extra pipe wakeups, and commit 3a34b13a88ca ("pipe: make pipe writes always wake up readers") ended up causing a quite noticeable regression on larger machines. Now, hackbench isn't necessarily a hugely meaningful benchmark, and it's not clear that this matters in real life all that much, but as Mel points out, it's used often enough when comparing kernels and so the performance regression shows up like a sore thumb. It's easy enough to fix at least for the common cases where pipes are used purely for data transfer, and you never have any exciting poll usage at all. So set a special 'poll_usage' flag when there is polling activity, and make the ugly "EPOLLET has crazy legacy expectations" semantics explicit to only that case. I would love to limit it to just the broken EPOLLET case, but the pipe code can't see the difference between epoll and regular select/poll, so any non-read/write waiting will trigger the extra wakeup behavior. That is sufficient for at least the hackbench case. Apart from making the odd extra wakeup cases more explicitly about EPOLLET, this also makes the extra wakeup be at the _end_ of the pipe write, not at the first write chunk. That is actually much saner semantics (as much as you can call any of the legacy edge-triggered expectations for EPOLLET "sane") since it means that you know the wakeup will happen once the write is done, rather than possibly in the middle of one. [ For stable people: I'm putting a "Fixes" tag on this, but I leave it up to you to decide whether you actually want to backport it or not. It likely has no impact outside of synthetic benchmarks - Linus ] Link: https://lore.kernel.org/lkml/20210802024945.GA8372@xsang-OptiPlex-9020/ Fixes: 3a34b13a88ca ("pipe: make pipe writes always wake up readers") Reported-by: kernel test robot <oliver.sang@intel.com> Tested-by: Sandeep Patil <sspatil@android.com> Tested-by: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

view details

Linus Torvalds

commit sha a83955bdad3ee1c8d29f345252dcb1806fe22365

Merge tag 'cfi-v5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull clang cfi fix from Kees Cook: - Use rcu_read_{un}lock_sched_notrace to avoid recursion (Elliot Berman) * tag 'cfi-v5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: cfi: Use rcu_read_{un}lock_sched_notrace

view details

Linus Torvalds

commit sha 01f15f3773bf3653a708e2c18c370beb16ca23c7

Merge tag 'sound-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Only a few regression fixes and trivial device quirks" * tag 'sound-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/via: Apply runtime PM workaround for ASUS B23E ALSA: hda: Fix hang during shutdown due to link reset ALSA: hda/realtek: Enable 4-speaker output for Dell XPS 15 9510 laptop ALSA: oxfw: fix functioal regression for silence in Apogee Duet FireWire ALSA: hda - fix the 'Capture Switch' value change notifications

view details

Linus Torvalds

commit sha d6d09a6942050f21b065a134169002b4d6b701ef

Merge tag 'for-5.14-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "One more fix for cross-rename, adding a missing check for directory and subvolume, this could lead to a crash" * tag 'for-5.14-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: prevent rename2 from exchanging a subvol with a directory from different parents

view details

Alexey Sheplyakov

commit sha 5d798299f566cbb1bc45946086ce2dccc354b64b

BE-M1000: Kconfig, defconfig

view details

Alexey Sheplyakov

commit sha 4d2a64faea1c7794948d58a290d24cad2e8eec2f

BE-M1000: clock driver This version works with firmware from SDK-M 4.4, 5.1, and 5.2

view details

Alexey Sheplyakov

commit sha 59b649c1d25dae2cf956c8e9c87a21938a93c62d

cpufreq-dt: don't load on BE-M1000 SoC Apparently the driver deadlocks the kernel in a few minutes: [ 454.690508] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 454.696839] (detected by 4, t=26002 jiffies, g=22561, q=15) [ 454.703017] rcu: All QSes seen, last rcu_preempt kthread activity 25992 (4295121102-4295095110), jiffies_till_next_fqs=3, root ->qsmask 0x0 [ 454.715570] rcu: rcu_preempt kthread starved for 25992 jiffies! g22561 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=1 [ 454.726117] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. [ 454.735273] rcu: RCU grace-period kthread stack dump: [ 454.740344] task:rcu_preempt state:R stack: 0 pid: 13 ppid: 2 flags:0x00000028 [ 454.748731] Call trace: [ 454.751204] __switch_to+0x114/0x170 [ 454.754803] __schedule+0x370/0xa3c [ 454.758310] schedule+0x50/0x104 [ 454.761557] schedule_timeout+0x9c/0x114 [ 454.765503] rcu_gp_kthread+0x598/0xb50 [ 454.769360] kthread+0x150/0x160 [ 454.772607] ret_from_fork+0x10/0x38 [ 454.778130] [ 454.779631] ================================ [ 454.783912] WARNING: inconsistent lock state [ 454.788196] 5.10.17-00041-g454ed3004040-dirty #1 Not tainted [ 454.793867] -------------------------------- [ 454.798147] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 454.804168] swapper/4/0 [HC0[0]:SC1[1]:HE0:SE0] takes: [ 454.809319] ffff800011198498 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x480/0xce0 [ 454.817615] {IN-HARDIRQ-W} state was registered at: [ 454.822508] __lock_acquire+0xad8/0x2094 [ 454.826530] lock_acquire.part.0+0xfc/0x360 [ 454.830813] lock_acquire+0x68/0x84 [ 454.834399] _raw_spin_lock_irqsave+0x84/0x158 [ 454.838941] rcu_exp_handler+0xcc/0x140 [ 454.842878] flush_smp_call_function_queue+0xec/0x304 [ 454.848029] generic_smp_call_function_single_interrupt+0x20/0x2c [ 454.854225] ipi_handler+0x1d8/0x39c [ 454.857899] handle_percpu_devid_fasteoi_ipi+0xb0/0xe0 [ 454.863137] __handle_domain_irq+0xbc/0x13c [ 454.867419] gic_handle_irq+0xcc/0x14c [ 454.871265] el1_irq+0xc4/0x180 [ 454.874504] lock_acquire.part.0+0x120/0x360 [ 454.878873] lock_acquire+0x68/0x84 [ 454.882461] lock_page_memcg+0x5c/0x150 [ 454.886399] page_add_file_rmap+0x28/0x27c [ 454.890595] alloc_set_pte+0xb8/0x5c0 [ 454.894356] filemap_map_pages+0x4a4/0x4c0 [ 454.898551] handle_mm_fault+0xbcc/0xf50 [ 454.902572] do_page_fault+0x14c/0x404 [ 454.906418] do_translation_fault+0xbc/0xd8 [ 454.910701] do_mem_abort+0x4c/0xac [ 454.914287] el0_ia+0x68/0xcc [ 454.917351] el0_sync_handler+0x180/0x1b0 [ 454.921458] el0_sync+0x174/0x180 [ 454.924868] irq event stamp: 449729 [ 454.928368] hardirqs last enabled at (449725): [<ffff8000109fcf74>] default_idle_call+0x24/0xdc [ 454.937171] hardirqs last disabled at (449726): [<ffff8000109f27a0>] enter_el1_irq_or_nmi+0x10/0x20 [ 454.946237] softirqs last enabled at (449728): [<ffff8000100532f0>] _local_bh_enable+0x30/0x54 [ 454.954952] softirqs last disabled at (449729): [<ffff8000100534c4>] __irq_exit_rcu+0x1b0/0x1bc [ 454.963665] [ 454.963665] other info that might help us debug this: [ 454.970206] Possible unsafe locking scenario: [ 454.970206] [ 454.976136] CPU0 [ 454.978590] ---- [ 454.981043] lock(rcu_node_0); [ 454.984198] <Interrupt> [ 454.986825] lock(rcu_node_0); [ 454.990155] [ 454.990155] *** DEADLOCK *** [ 454.990155] [ 454.996087] 1 lock held by swapper/4/0: [ 454.999932] #0: ffff800011198498 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x480/0xce0 [ 455.008662] [ 455.008662] stack backtrace: [ 455.013033] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.10.17-00041-g454ed3004040-dirty #1 [ 455.021313] Hardware name: Baikal Electronics Baikal-M mitx board (DT) [ 455.027854] Call trace: [ 455.030311] dump_backtrace+0x0/0x1e4 [ 455.033985] show_stack+0x24/0x80 [ 455.037312] dump_stack+0xec/0x154 [ 455.040723] print_usage_bug.part.0+0x208/0x22c [ 455.045265] mark_lock+0x88c/0x934 [ 455.048677] mark_held_locks+0x58/0x90 [ 455.052437] lockdep_hardirqs_on_prepare+0xe4/0x23c [ 455.057330] trace_hardirqs_on+0x78/0x2e0 [ 455.061350] __do_softirq+0x114/0x6d0 [ 455.065022] __irq_exit_rcu+0x1b0/0x1bc [ 455.068868] irq_exit+0x1c/0x54 [ 455.072020] __handle_domain_irq+0xc0/0x13c [ 455.076214] gic_handle_irq+0xcc/0x14c [ 455.079972] el1_irq+0xc4/0x180 [ 455.083124] arch_cpu_idle+0x18/0x30 [ 455.086710] default_idle_call+0x5c/0xdc [ 455.090645] do_idle+0x260/0x2e0 [ 455.093883] cpu_startup_entry+0x30/0x8c [ 455.097818] secondary_start_kernel+0x138/0x184 [ 455.102410] BUG: scheduling while atomic: swapper/4/0/0x00000002 [ 455.108449] INFO: lockdep is turned off. [ 455.112399] Modules linked in: dm_mod designware_i2s sdhci_of_dwcmshc snd_soc_core sdhci_pltfm dw_hdmi_ahb_audio snd_pcm_dmaengine ac97_bus evdev sdhci snd_pcm at24 panfrost mmc_core snd_timer pcie_baikal_v44 snd pcie_baikal bt1_pvt gpu_sched soundcore cpufreq_dt fuse configfs efivarfs ipv6 [ 455.138295] Preemption disabled at: [ 455.138305] [<ffff800010028c64>] secondary_start_kernel+0xb4/0x184 [ 455.148020] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.10.17-00041-g454ed3004040-dirty #1 [ 455.156299] Hardware name: Baikal Electronics Baikal-M mitx board (DT) [ 455.162840] Call trace: [ 455.165296] dump_backtrace+0x0/0x1e4 [ 455.168969] show_stack+0x24/0x80 [ 455.172295] dump_stack+0xec/0x154 [ 455.175711] __schedule_bug+0xcc/0xe0 [ 455.179383] __schedule+0x928/0xa3c [ 455.182881] schedule_idle+0x34/0x5c [ 455.186467] do_idle+0x1dc/0x2e0 [ 455.189706] cpu_startup_entry+0x30/0x8c [ 455.193640] secondary_start_kernel+0x138/0x184

view details

Alexey Sheplyakov

commit sha cff758c6a5cb86319c02554e980c023bdb5b44e4

efi-rtc: avoid calling efi.get_time on BE-M1000 SoC UEFI does NOT provide get_time at the runtime, hence calling it results in an Oops.

view details

Vadim V. Vlasov

commit sha df78baf9d966b4733c0f76a7a142c53df7eeb824

Serial: 82550_dw: Fix clock rate setting in dw8250_set_termios() If clk_round_rate() returns rate out of 1/16 precision range from the desired rate, then do not change clock rate. This usually happens if the desired rate is below the minimum supported by the clk. Fixes UART console on BE-M1000 SoC (without this patch the console gets garbled after loading the driver)

view details

Alexey Sheplyakov

commit sha 7ddc8f9ddf31d4ca9d1195cf0e3d3705102234e6

Fixed secondary CPUs boot on BE-M1000 SoC The secure world on BE-M1000 SoC denies execution attempts outside of the ranges [0x80000000, 0x8FFFFFFF] [0xA0000000, 0xBFFFFFFF]. Thus PSCI calls to boot secondary CPUs fail unless the kernel image resides in one of these (physical) address ranges. However BE-M1000's UEFI PE/COFF loader puts the kernel into the forbidden range. Since the alignment is good enough EFI stub does not try to relocate the kernel. As a result secondary CPUs fail to boot. Relocation to a random address is not going to work either. Therefore automatically disable kaslr on "known bad" systems (for now only BE-M1000 ones) and forcibly relocate the kernel to a low(er) address.

view details

Alexey Sheplyakov

commit sha 772245f6e8377197aa27417edcfd8a968306adf0

BE-M1000: USB glue driver

view details

push time in a month

push eventaltlinux/linux-be-m1000

Zhihao Cheng

commit sha 2b6d2833cd1d8a43a837a45da65860ef086443dc

mtd: mtd_blkdevs: Initialize rq.limits.discard_granularity Since commit b35fd7422c2f8("block: check queue's limits.discard_granularity in __blkdev_issue_discard()") checks rq.limits.discard_granularity in __blkdev_issue_discard(), we may get following warnings on formatted ftl: WARNING: CPU: 2 PID: 7313 at block/blk-lib.c:51 __blkdev_issue_discard+0x2a7/0x390 Reproducer: 1. ftl_format /dev/mtd0 2. modprobe ftl 3. mkfs.vfat /dev/ftla 4. mount -odiscard /dev/ftla temp 5. dd if=/dev/zero of=temp/tst bs=1M count=10 oflag=direct 6. dd if=/dev/zero of=temp/tst bs=1M count=10 oflag=direct Fix it by initializing rq.limits.discard_granularity if device supports discard operation. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210615093905.3473709-1-chengzhihao1@huawei.com

view details

Dan Carpenter

commit sha 14f97f0b8e2b9950c028d0cb7311ffe26a3cc1c0

mtd: rawnand: Add a check in of_get_nand_secure_regions() Check for whether of_property_count_elems_of_size() returns a negative error code. Fixes: 13b89768275d ("mtd: rawnand: Add support for secure regions in NAND memory") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/YMtQFXE0F1w7mUh+@mwanda

view details

Desmond Cheong Zhi Xi

commit sha 962bf783ef65d15b0f8ca9c33342cf3b20bf0d2e

mtd: break circular locks in register_mtd_blktrans Syzbot reported a circular locking dependency: https://syzkaller.appspot.com/bug?id=7bd106c28e846d1023d4ca915718b1a0905444cb This happens because of the following lock dependencies: 1. loop_ctl_mutex -> bdev->bd_mutex (when loop_control_ioctl calls loop_remove, which then calls del_gendisk; this also happens in loop_exit which eventually calls loop_remove) 2. bdev->bd_mutex -> mtd_table_mutex (when blkdev_get_by_dev calls __blkdev_get, which then calls blktrans_open) 3. mtd_table_mutex -> major_names_lock (when register_mtd_blktrans calls __register_blkdev) 4. major_names_lock -> loop_ctl_mutex (when blk_request_module calls loop_probe) Hence there's an overall dependency of: loop_ctl_mutex ----------> bdev->bd_mutex ^ | | | | v major_names_lock <--------- mtd_table_mutex We can break this circular dependency by holding mtd_table_mutex only for the required critical section in register_mtd_blktrans. This avoids the mtd_table_mutex -> major_names_lock dependency. Reported-and-tested-by: syzbot+6a8a0d93c91e8fbf2e80@syzkaller.appspotmail.com Co-developed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210617160904.570111-1-desmondcheongzx@gmail.com

view details

Dan Carpenter

commit sha e83862ee1b9b1668826683f432b041875ec0c819

mtd: mchp48l640: silence some uninitialized variable warnings Smatch complains that zero length read/writes will lead to an uninitalized return value. I don't know if that's possible, but it's nicer to return a zero literal anyway so let's do that. Fixes: 88d125026753 ("mtd: devices: add support for microchip 48l640 EERAM") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/YMyir961W28TX5dT@mwanda

view details

Michael Walle

commit sha 45bb1faa29effbd4ca4d581b32373f2eda309b95

mtd: core: handle flashes without OTP gracefully There are flash drivers which registers the OTP callbacks although the flash doesn't support OTP regions and return -ENODATA for these callbacks if there is no OTP. If this happens, the probe of the whole flash will fail. Fix it by handling the ENODATA return code and skip the OTP region nvmem setup. Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210707135359.32398-1-michael@walle.cc

view details

Andreas Persson

commit sha 2394e628738933aa014093d93093030f6232946d

mtd: cfi_cmdset_0002: fix crash when erasing/writing AMD cards Erasing an AMD linear flash card (AM29F016D) crashes after the first sector has been erased. Likewise, writing to it crashes after two bytes have been written. The reason is a missing check for a null pointer - the cmdset_priv field is not set for this type of card. Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register") Signed-off-by: Andreas Persson <andreasp56@outlook.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/DB6P189MB05830B3530B8087476C5CFE4C1159@DB6P189MB0583.EURP189.PROD.OUTLOOK.COM

view details

Stephan Mueller

commit sha 5261cdf457ce3635bf18d393a3c1991dcfaf9d02

crypto: drbg - select SHA512 With the swtich to use HMAC(SHA-512) as the default DRBG type, the configuration must now also select SHA-512. Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG as default DRBG" Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Signed-off-by: Stephan Mueller <smueller@chronox.com> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

view details

Colin Ian King

commit sha 99dc4ad992bf156692b088fab4d98deab7cbd3e6

mtd: devices: mchp48l640: Fix memory leak on cmd The allocation for cmd is not being kfree'd on the return leading to a memory leak. Fix this by kfree'ing it. Addresses-Coverity: ("Resource leak") Fixes: 88d125026753 ("mtd: devices: add support for microchip 48l640 EERAM") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210712145214.101377-1-colin.king@canonical.com

view details

Desmond Cheong Zhi Xi

commit sha b7abb051682263e51866bc78762fd0083d64c5ed

mtd: fix lock hierarchy in deregister_mtd_blktrans There is a lock hierarchy of major_names_lock --> mtd_table_mutex. One existing chain is as follows: 1. major_names_lock --> loop_ctl_mutex (when blk_request_module calls loop_probe) 2. loop_ctl_mutex --> bdev->bd_mutex (when loop_control_ioctl calls loop_remove, which then calls del_gendisk) 3. bdev->bd_mutex --> mtd_table_mutex (when blkdev_get_by_dev calls __blkdev_get, which then calls blktrans_open) Since unregister_blkdev grabs the major_names_lock, we need to call it outside the critical section for mtd_table_mutex, otherwise we invert the lock hierarchy. Reported-by: Hillf Danton <hdanton@sina.com> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210717100719.728829-1-desmondcheongzx@gmail.com

view details

Manivannan Sadhasivam

commit sha b48027083a78b13356695555a05b0e085e378687

mtd: rawnand: Fix probe failure due to of_get_nand_secure_regions() Due to 14f97f0b8e2b, the rawnand platforms without "secure-regions" property defined in DT fails to probe. The issue is, of_get_nand_secure_regions() errors out if of_property_count_elems_of_size() returns a negative error code. If the "secure-regions" property is not present in DT, then also we'll get -EINVAL from of_property_count_elems_of_size() but it should not be treated as an error for platforms not declaring "secure-regions" in DT. So fix this behaviour by checking for the existence of that property in DT and return 0 if it is not present. Fixes: 14f97f0b8e2b ("mtd: rawnand: Add a check in of_get_nand_secure_regions()") Reported-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Martin Kaiser <martin@kaiser.cx> Tested-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210727062813.32619-1-manivannan.sadhasivam@linaro.org

view details

Parav Pandit

commit sha 60f0779862e4ab943810187752c462e85f5fa371

virtio: Improve vq->broken access to avoid any compiler optimization Currently vq->broken field is read by virtqueue_is_broken() in busy loop in one context by virtnet_send_command(). vq->broken is set to true in other process context by virtio_break_device(). Reader and writer are accessing it without any synchronization. This may lead to a compiler optimization which may result to optimize reading vq->broken only once. Hence, force reading vq->broken on each invocation of virtqueue_is_broken() and also force writing it so that such update is visible to the readers. It is a theoretical fix that isn't yet encountered in the field. Signed-off-by: Parav Pandit <parav@nvidia.com> Link: https://lore.kernel.org/r/20210721142648.1525924-2-parav@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

view details

Parav Pandit

commit sha 249f255476328e597a598ccdbd4414e51a5b6d6e

virtio: Keep vring_del_virtqueue() mirror of VQ create Keep the vring_del_virtqueue() mirror of the create routines. i.e. to delete list entry first as it is added last during the create routine. Signed-off-by: Parav Pandit <parav@nvidia.com> Link: https://lore.kernel.org/r/20210721142648.1525924-3-parav@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

view details

Parav Pandit

commit sha 0e566c8f0f2e8325e35f6f97e13cde5356b41814

virtio: Protect vqs list access VQs may be accessed to mark the device broken while they are created/destroyed. Hence protect the access to the vqs list. Fixes: e2dcdfe95c0b ("virtio: virtio_break_device() to mark all virtqueues broken.") Signed-off-by: Parav Pandit <parav@nvidia.com> Link: https://lore.kernel.org/r/20210721142648.1525924-4-parav@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

view details

Parav Pandit

commit sha 43bb40c5b92659966bdf4bfe584fde0a3575a049

virtio_pci: Support surprise removal of virtio pci device When a virtio pci device undergo surprise removal (aka async removal in PCIe spec), mark the device as broken so that any upper layer drivers can abort any outstanding operation. When a virtio net pci device undergo surprise removal which is used by a NetworkManager, a below call trace was observed. kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:1:27059] watchdog: BUG: soft lockup - CPU#1 stuck for 52s! [kworker/1:1:27059] CPU: 1 PID: 27059 Comm: kworker/1:1 Tainted: G S W I L 5.13.0-hotplug+ #8 Hardware name: Dell Inc. PowerEdge R640/0H28RR, BIOS 2.9.4 11/06/2020 Workqueue: events linkwatch_event RIP: 0010:virtnet_send_command+0xfc/0x150 [virtio_net] Call Trace: virtnet_set_rx_mode+0xcf/0x2a7 [virtio_net] ? __hw_addr_create_ex+0x85/0xc0 __dev_mc_add+0x72/0x80 igmp6_group_added+0xa7/0xd0 ipv6_mc_up+0x3c/0x60 ipv6_find_idev+0x36/0x80 addrconf_add_dev+0x1e/0xa0 addrconf_dev_config+0x71/0x130 addrconf_notify+0x1f5/0xb40 ? rtnl_is_locked+0x11/0x20 ? __switch_to_asm+0x42/0x70 ? finish_task_switch+0xaf/0x2c0 ? raw_notifier_call_chain+0x3e/0x50 raw_notifier_call_chain+0x3e/0x50 netdev_state_change+0x67/0x90 linkwatch_do_dev+0x3c/0x50 __linkwatch_run_queue+0xd2/0x220 linkwatch_event+0x21/0x30 process_one_work+0x1c8/0x370 worker_thread+0x30/0x380 ? process_one_work+0x370/0x370 kthread+0x118/0x140 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 Hence, add the ability to abort the command on surprise removal which prevents infinite loop and system lockup. Signed-off-by: Parav Pandit <parav@nvidia.com> Link: https://lore.kernel.org/r/20210721142648.1525924-5-parav@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

view details

Xie Yongji

commit sha 0e398290cff997610b66e73573faaee70c9a700e

vhost-vdpa: Fix integer overflow in vhost_vdpa_process_iotlb_update() The "msg->iova + msg->size" addition can have an integer overflow if the iotlb message is from a malicious user space application. So let's fix it. Fixes: 1b48dc03e575 ("vhost: vdpa: report iova range") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20210728130756.97-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

view details

Xie Yongji

commit sha f7ad318ea0ad58ebe0e595e59aed270bb643b29b

vhost: Fix the calculation in vhost_overflow() This fixes the incorrect calculation for integer overflow when the last address of iova range is 0xffffffff. Fixes: ec33d031a14b ("vhost: detect 32 bit integer wrap around") Reported-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20210728130756.97-2-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

view details

Xie Yongji

commit sha 2b847f21145d84e2e1dde99d3e2c00a5468f02e4

vdpa_sim: Fix return value check for vdpa_alloc_device() The vdpa_alloc_device() returns an error pointer upon failure, not NULL. To handle the failure correctly, this replaces NULL check with IS_ERR() check and propagate the error upwards. Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210715080026.242-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

view details

Xie Yongji

commit sha 9632e78e82648aa98340df78eab9106f63da151e

vp_vdpa: Fix return value check for vdpa_alloc_device() The vdpa_alloc_device() returns an error pointer upon failure, not NULL. To handle the failure correctly, this replaces NULL check with IS_ERR() check and propagate the error upwards. Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210715080026.242-2-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

view details

Xie Yongji

commit sha 1057afa0121db8bd3ca4718c8e0ca12388ab7759

vDPA/ifcvf: Fix return value check for vdpa_alloc_device() The vdpa_alloc_device() returns an error pointer upon failure, not NULL. To handle the failure correctly, this replaces NULL check with IS_ERR() check and propagate the error upwards. Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210715080026.242-3-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

view details

Xie Yongji

commit sha c8d182bd387a09a8b95303c8086238e8bf61fcfc

vdpa: Add documentation for vdpa_alloc_device() macro The return value of vdpa_alloc_device() macro is not very clear, so that most of callers did the wrong check. Let's add some comments to better document it. Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210715080026.242-4-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

view details

push time in a month

create barnchaltlinux/linux-be-m1000

branch : baikalm-5.14.y

created branch time in a month

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha 473fe67810621f6fe305f12c57c73488b6292569

Unbreak downloading kernels via http

view details

push time in 2 months

push eventaltlinux/linux-be-m1000

Alexey Sheplyakov

commit sha 85af08cdfc99a69b521d1e8c6a9ffa1ba68eb8ac

baikal_minimal_defconfig: explicitly enabled EFI initrd loader

view details

push time in 2 months

push eventaltlinux/linux-be-m1000

Mauro Carvalho Chehab

commit sha 16e78cc41501dc934ccc14734a843fa03f2c365b

media: hantro: do a PM resume earlier [ Upstream commit 892bb6ecead9b834ba7ad1d07513e9eba1baa3a4 ] The device_run() first enables the clock and then tries to resume PM runtime, checking for errors. Well, if for some reason the pm_runtime can not resume, it would be better to detect it beforehand. So, change the order inside device_run(). Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Fixes: 775fec69008d ("media: add Rockchip VPU JPEG encoder driver") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Corentin Labbe

commit sha bd2a2b2511b10f9c2ae596ed69ff05e11c378e52

crypto: ixp4xx - dma_unmap the correct address [ Upstream commit 9395c58fdddd79cdd3882132cdd04e8ac7ad525f ] Testing ixp4xx_crypto with CONFIG_DMA_API_DEBUG lead to the following error: DMA-API: platform ixp4xx_crypto.0: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=24 bytes] This is due to dma_unmap using the wrong address. Fixes: 0d44dc59b2b4 ("crypto: ixp4xx - Fix handling of chained sg buffers") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Corentin Labbe

commit sha c4a3bc075a716eecdda665b996531e3148a1580f

crypto: ixp4xx - update IV after requests [ Upstream commit e8acf011f2e7e21a7e2fae47cbaa06598e533d40 ] Crypto selftests fail on ixp4xx since it do not update IV after skcipher requests. Fixes: 81bef0150074 ("crypto: ixp4xx - Hardware crypto support for IXP4xx CPUs") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Zhen Lei

commit sha 2d3650748f83eb9fb5121a52c8b53e436e1f349c

crypto: ux500 - Fix error return code in hash_hw_final() [ Upstream commit b01360384009ab066940b45f34880991ea7ccbfb ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 8a63b1994c50 ("crypto: ux500 - Add driver for HASH hardware") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Sergey Shtylyov

commit sha 076081f9c332a1faf135c16c93f71543181404eb

sata_highbank: fix deferred probing [ Upstream commit 4a24efa16e7db02306fb5db84518bb0a7ada5a46 ] The driver overrides the error codes returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Link: https://lore.kernel.org/r/105b456d-1199-f6e9-ceb7-ffc5ba551d1a@omprussia.ru Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Sergey Shtylyov

commit sha 9abb3adaf2982cb090ad15dc617586a0e9c8d774

pata_rb532_cf: fix deferred probing [ Upstream commit 2d3a62fbae8e5badc2342388f65ab2191c209cc0 ] The driver overrides the error codes returned by platform_get_irq() to -ENOENT, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Link: https://lore.kernel.org/r/771ced55-3efb-21f5-f21c-b99920aae611@omprussia.ru Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Randy Dunlap

commit sha 73d6021a93fafde457a3460609e2e0f7e25a2efe

media: I2C: change 'RST' to "RSET" to fix multiple build errors [ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ] The use of an enum named 'RST' conflicts with a #define macro named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h. The MIPS use of RST was there first (AFAICT), so change the media/i2c/ uses of RST to be named 'RSET'. 'git grep -w RSET' does not report any naming conflicts with the new name. This fixes multiple build errors: arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST' 356 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST' 180 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST' 238 | RST, | ^~~ and some others that I have trimmed. Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver") Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor") Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor") Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Sangwook Lee <sangwook.lee@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Qais Yousef

commit sha cdf0a10bf5f12a9a454772946c02409a90d18400

sched/uclamp: Fix wrong implementation of cpu.uclamp.min [ Upstream commit 0c18f2ecfcc274a4bcc1d122f79ebd4001c3b445 ] cpu.uclamp.min is a protection as described in cgroup-v2 Resource Distribution Model Documentation/admin-guide/cgroup-v2.rst which means we try our best to preserve the minimum performance point of tasks in this group. See full description of cpu.uclamp.min in the cgroup-v2.rst. But the current implementation makes it a limit, which is not what was intended. For example: tg->cpu.uclamp.min = 20% p0->uclamp[UCLAMP_MIN] = 0 p1->uclamp[UCLAMP_MIN] = 50% Previous Behavior (limit): p0->effective_uclamp = 0 p1->effective_uclamp = 20% New Behavior (Protection): p0->effective_uclamp = 20% p1->effective_uclamp = 50% Which is inline with how protections should work. With this change the cgroup and per-task behaviors are the same, as expected. Additionally, we remove the confusing relationship between cgroup and !user_defined flag. We don't want for example RT tasks that are boosted by default to max to change their boost value when they attach to a cgroup. If a cgroup wants to limit the max performance point of tasks attached to it, then cpu.uclamp.max must be set accordingly. Or if they want to set different boost value based on cgroup, then sysctl_sched_util_clamp_min_rt_default must be used to NOT boost to max and set the right cpu.uclamp.min for each group to let the RT tasks obtain the desired boost value when attached to that group. As it stands the dependency on !user_defined flag adds an extra layer of complexity that is not required now cpu.uclamp.min behaves properly as a protection. The propagation model of effective cpu.uclamp.min in child cgroups as implemented by cpu_util_update_eff() is still correct. The parent protection sets an upper limit of what the child cgroups will effectively get. Fixes: 3eac870a3247 (sched/uclamp: Use TG's clamps to restrict TASK's clamps) Signed-off-by: Qais Yousef <qais.yousef@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210510145032.1934078-2-qais.yousef@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Qais Yousef

commit sha 099451afd3a39deac2a4a7330c53c8e87701730b

sched/uclamp: Fix locking around cpu_util_update_eff() [ Upstream commit 93b73858701fd01de26a4a874eb95f9b7156fd4b ] cpu_cgroup_css_online() calls cpu_util_update_eff() without holding the uclamp_mutex or rcu_read_lock() like other call sites, which is a mistake. The uclamp_mutex is required to protect against concurrent reads and writes that could update the cgroup hierarchy. The rcu_read_lock() is required to traverse the cgroup data structures in cpu_util_update_eff(). Surround the caller with the required locks and add some asserts to better document the dependency in cpu_util_update_eff(). Fixes: 7226017ad37a ("sched/uclamp: Fix a bug in propagating uclamp value in new cgroups") Reported-by: Quentin Perret <qperret@google.com> Signed-off-by: Qais Yousef <qais.yousef@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210510145032.1934078-3-qais.yousef@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Josh Poimboeuf

commit sha 6b9c00b1ffb05bc525c8c62217169f1b0986bfca

kbuild: Fix objtool dependency for 'OBJECT_FILES_NON_STANDARD_<obj> := n' [ Upstream commit 8852c552402979508fdc395ae07aa8761aa46045 ] "OBJECT_FILES_NON_STANDARD_vma.o := n" has a dependency bug. When objtool source is updated, the affected object doesn't get re-analyzed by objtool. Peter's new variable-sized jump label feature relies on objtool rewriting the object file. Otherwise the system can fail to boot. That effectively upgrades this minor dependency issue to a major bug. The problem is that variables in prerequisites are expanded early, during the read-in phase. The '$(objtool_dep)' variable indirectly uses '$@', which isn't yet available when the target prerequisites are evaluated. Use '.SECONDEXPANSION:' which causes '$(objtool_dep)' to be expanded in a later phase, after the target-specific '$@' variable has been defined. Fixes: b9ab5ebb14ec ("objtool: Add CONFIG_STACK_VALIDATION option") Fixes: ab3257042c26 ("jump_label, x86: Allow short NOPs") Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Sergey Shtylyov

commit sha 185fe39b4f28748c4fbc4d1d8bb3ab52b4ed93ed

pata_octeon_cf: avoid WARN_ON() in ata_host_activate() [ Upstream commit bfc1f378c8953e68ccdbfe0a8c20748427488b80 ] Iff platform_get_irq() fails (or returns IRQ0) and thus the polling mode has to be used, ata_host_activate() hits the WARN_ON() due to 'irq_handler' parameter being non-NULL if the polling mode is selected. Let's only set the pointer to the driver's IRQ handler if platform_get_irq() returns a valid IRQ # -- this should avoid the unnecessary WARN_ON()... Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/3a241167-f84d-1d25-5b9b-be910afbe666@omp.ru Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Mimi Zohar

commit sha 0c436ecb3ae699644ca6a1a9468d6a2389234dc3

evm: fix writing <securityfs>/evm overflow [ Upstream commit 49219d9b8785ba712575c40e48ce0f7461254626 ] EVM_SETUP_COMPLETE is defined as 0x80000000, which is larger than INT_MAX. The "-fno-strict-overflow" compiler option properly prevents signaling EVM that the EVM policy setup is complete. Define and read an unsigned int. Fixes: f00d79750712 ("EVM: Allow userspace to signal an RSA key has been loaded") Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Joe Richey

commit sha 9d5db40cb53ca9812152e39d6688d717823bd5c8

x86/elf: Use _BITUL() macro in UAPI headers [ Upstream commit d06aca989c243dd9e5d3e20aa4e5c2ecfdd07050 ] Replace BIT() in x86's UAPI header with _BITUL(). BIT() is not defined in the UAPI headers and its usage may cause userspace build errors. Fixes: 742c45c3ecc9 ("x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2") Signed-off-by: Joe Richey <joerichey@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210521085849.37676-2-joerichey94@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Suman Anna

commit sha 918861ace4eebcb3eedcf5b1e994f50c5ce15cac

crypto: sa2ul - Fix leaks on failure paths with sa_dma_init() [ Upstream commit 4c0716ee1d973f6504d13f0e8d4d10350c85ad37 ] The sa_dma_init() function doesn't release the requested dma channels on all failure paths. Any failure in this function also ends up leaking the dma pool created in sa_init_mem() in the sa_ul_probe() function. Fix all of these issues. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Suman Anna

commit sha e31cf3960c3d1a6258c09ab92c7d6d2d6d0c2dc1

crypto: sa2ul - Fix pm_runtime enable in sa_ul_probe() [ Upstream commit 5c8552325e013cbdabc443cd1f1b4d03c4a2e64e ] The pm_runtime APIs added first in commit 7694b6ca649f ("crypto: sa2ul - Add crypto driver") are not unwound properly and was fixed up partially in commit 13343badae09 ("crypto: sa2ul - Fix PM reference leak in sa_ul_probe()"). This fixed up the pm_runtime usage count but not the state. Fix this properly. Fixes: 13343badae09 ("crypto: sa2ul - Fix PM reference leak in sa_ul_probe()") Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Christophe JAILLET

commit sha 0909d610f235d2e9ab466d1dbb7997d4a653d9db

crypto: ccp - Fix a resource leak in an error handling path [ Upstream commit a6f8e68e238a15bb15f1726b35c695136c64eaba ] If an error occurs after calling 'sp_get_irqs()', 'sp_free_irqs()' must be called as already done in the error handling path. Fixes: f4d18d656f88 ("crypto: ccp - Abstract interrupt registeration") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: John Allen <john.allen@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Christophe JAILLET

commit sha 96409164a6aceb71d02ea485398ec07a6e44f8d1

media: rc: i2c: Fix an error message [ Upstream commit 9c87ae1a0dbeb5794957421157fd266d38a869b4 ] 'ret' is known to be 1 here. In fact 'i' is expected instead. Store the return value of 'i2c_master_recv()' in 'ret' so that the error message print the correct error code. Fixes: acaa34bf06e9 ("media: rc: implement zilog transmitter") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Sergey Shtylyov

commit sha 91cec7994e0cd2affa3589b6fc3a366c27020be7

pata_ep93xx: fix deferred probing [ Upstream commit 5c8121262484d99bffb598f39a0df445cecd8efb ] The driver overrides the error codes returned by platform_get_irq() to -ENXIO, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Propagate the error code upstream, as it should have been done from the start... Fixes: 2fff27512600 ("PATA host controller driver for ep93xx") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Link: https://lore.kernel.org/r/509fda88-2e0d-2cc7-f411-695d7e94b136@omprussia.ru Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Randy Dunlap

commit sha f867ac6cf7917558143ac64b9ee0dcfc8f3b7a52

locking/lockdep: Reduce LOCKDEP dependency list [ Upstream commit b8e00abe7d9fe21dd13609e2e3a707e38902b105 ] Some arches (um, sparc64, riscv, xtensa) cause a Kconfig warning for LOCKDEP. These arch-es select LOCKDEP_SUPPORT but they are not listed as one of the arch-es that LOCKDEP depends on. Since (16) arch-es define the Kconfig symbol LOCKDEP_SUPPORT if they intend to have LOCKDEP support, replace the awkward list of arch-es that LOCKDEP depends on with the LOCKDEP_SUPPORT symbol. But wait. LOCKDEP_SUPPORT is included in LOCK_DEBUGGING_SUPPORT, which is already a dependency here, so LOCKDEP_SUPPORT is redundant and not needed. That leaves the FRAME_POINTER dependency, but it is part of an expression like this: depends on (A && B) && (FRAME_POINTER || B') where B' is a dependency of B so if B is true then B' is true and the value of FRAME_POINTER does not matter. Thus we can also delete the FRAME_POINTER dependency. Fixes this kconfig warning: (for um, sparc64, riscv, xtensa) WARNING: unmet direct dependencies detected for LOCKDEP Depends on [n]: DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] && (FRAME_POINTER [=n] || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86) Selected by [y]: - PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] - LOCK_STAT [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] - DEBUG_LOCK_ALLOC [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] Fixes: 7d37cb2c912d ("lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Waiman Long <longman@redhat.com> Link: https://lkml.kernel.org/r/20210524224150.8009-1-rdunlap@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

Valentin Schneider

commit sha 79321b67500911b8afc0c8e5adfe84e9b940b16d

sched: Don't defer CPU pick to migration_cpu_stop() [ Upstream commit 475ea6c60279e9f2ddf7e4cf2648cd8ae0608361 ] Will reported that the 'XXX __migrate_task() can fail' in migration_cpu_stop() can happen, and it *is* sort of a big deal. Looking at it some more, one will note there is a glaring hole in the deferred CPU selection: (w/ CONFIG_CPUSET=n, so that the affinity mask passed via taskset doesn't get AND'd with cpu_online_mask) $ taskset -pc 0-2 $PID # offline CPUs 3-4 $ taskset -pc 3-5 $PID `\ $PID may stay on 0-2 due to the cpumask_any_distribute() picking an offline CPU and __migrate_task() refusing to do anything due to cpu_is_allowed(). set_cpus_allowed_ptr() goes to some length to pick a dest_cpu that matches the right constraints vs affinity and the online/active state of the CPUs. Reuse that instead of discarding it in the affine_move_task() case. Fixes: 6d337eab041d ("sched: Fix migrate_disable() vs set_cpus_allowed_ptr()") Reported-by: Will Deacon <will@kernel.org> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210526205751.842360-2-valentin.schneider@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha ddfe2825a8cda2a8db7ec89b2ba2fb9c34539174

FIXUP: ALT p9-20210802: checksum

view details

Alexey Sheplyakov

commit sha 6e0c599eda69c7aadc6a4cea8bbdb7b7305f3e88

Added basic validation of alt_images yml Check if required properties are defined Check if image names are unique

view details

Alexey Sheplyakov

commit sha 6c1709be45b47efa4a15239be1b9a9b54980721d

Skip `install` entries for LiveCD-only images

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha e5fa3640bbab270b922b6f2b315a53d56d8b5ed5

parallelized check for out of date/missing ISOs Compute checksums in parallel

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha 70ed0ccc7127ed1324fa70281bb5ffe1bf70ffeb

new option: skip_iso_deploy Add the ISO in question to config.ipxe, but don't copy ISO to the server (presumably because ISO has been already deployed elsewhere)

view details

Alexey Sheplyakov

commit sha f18cd84b66d622ac4be8e06853506cf3578e4306

extra_ipxe_conf: per image ipxe configuration snippents I can blacklist panfrost modules on Baikal-M with "known bad" ISOs

view details

Alexey Sheplyakov

commit sha 0567b46134229f19e96bb2e2d32e202a0c5ee308

Added recent p9 aarch64 jeos image

view details

Alexey Sheplyakov

commit sha b92f740c17546077afd88f895ceed7e601f43d7b

Support per image kernel_url, initrd_url, stage2_http_url Useful in conjunction with skip_iso_deploy, so the entry is added to iPXE menu only (and downloaded from a different server)

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha 8fc290b13fc34573dbfe185e4189c1410baecd7b

Simplified config.ipxe template

view details

Alexey Sheplyakov

commit sha 6e07a4ad21b35f4f980c43eae2aad5049e52a29d

new option: skip_iso_deploy Add the ISO in question to config.ipxe, but don't copy ISO to the server (presumably because ISO has been already deployed elsewhere)

view details

Alexey Sheplyakov

commit sha 00a4e1de527c800b9c52a019efe91fe8fb17406c

extra_ipxe_conf: per image ipxe configuration snippents I can blacklist panfrost modules on Baikal-M with "known bad" ISOs

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha a71b0842cd55c921add0521032690bc8a683315d

config.ipxe: override settings per hostname, uuid, board model, etc For now I use this to enable UART console on TF307 boards.

view details

push time in 2 months

push eventasheplyakov/personal-devops

Alexey Sheplyakov

commit sha c115178fca9db5d6ccee057441798e5ba8074a1d

distccd, kerneldev: install cross-GCC specs correctly

view details

Alexey Sheplyakov

commit sha 2be679fdb326b903b8b8e37a0abb76ededd2cadb

distccd: made distccd log world-readable

view details

Alexey Sheplyakov

commit sha aae66b6a2ecadf54ef31dd9b96dd177b569bc58c

buildfarm: use distccd packages for real on ALT Linux

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha 657511df0c6e7bac1d33dac260ffdeec7c398d93

0wn: manage admin access to netinstall nodes

view details

Alexey Sheplyakov

commit sha 2776f8a2f1c670d5e888d905ff313bee8807169e

0wn: granted admin access to Alexey Sheplyakov

view details

push time in 2 months

push eventasheplyakov/netinstall-alt

Alexey Sheplyakov

commit sha 87c90c2f033163f61a60399db070c3abcaaf5b39

Install ipxe-bootimgs package with ARM64 UEFI support

view details

Alexey Sheplyakov

commit sha 5e0b8bf584aedfd806bff590168289aa8522b9bd

[cleanup] removed editor temporary file

view details

push time in 2 months

push eventasheplyakov/personal-devops

Alexey Sheplyakov

commit sha 4d2019e1cb2c610251798929b9abdf69b4133402

Added a licence (WTFPL)

view details

push time in 2 months

push eventasheplyakov/personal-devops

Alexey Sheplyakov

commit sha cdb9fae46e808a805fa9f966297d3cfa72db1be3

distccd, kerneldev: ALT Linux woes * Install `distcc`, `distcc-server` packages from distro * Generate specs for cross-compilers so they call correct assembler * Call `update-distcc-symlinks` after installing compilers * Create a stub /usr/lib64/distcc directory

view details

Alexey Sheplyakov

commit sha 2747de7039925ad920cef94c9b4ae8b72c267ec9

kerneldev: added forgotten file (handlers)

view details

Alexey Sheplyakov

commit sha e0bc54be27fac6e18647990cc3d185750ac19613

altpython: suppress bogus `changed`

view details

Alexey Sheplyakov

commit sha 2bb4f6866e6e7bbceff710a83c5cdc26437b6d36

buildfarm: update ALT repos with distcc and install-kernel fixes

view details

Alexey Sheplyakov

commit sha 85084f197d725a2c48d40f3c11e4b9823ea84a9c

mdns: added option to skip mdns NSS module NSS modules are tricky: they run directly in process which results in unexpected, difficult to debug failures

view details

Alexey Sheplyakov

commit sha f656f809cb305a6a2ebe77aaf29f6269eb614875

buildfarm: install only avahi daemon and skip mdns NSS module to avoid breaking static binaries (linked with a different glibc version).

view details

Alexey Sheplyakov

commit sha 06b40cada68986a946134b6e306daaca5c3ac5a8

buildfarm: allow root login into containers... ... and update package cache

view details

push time in 2 months

issue commentdistcc/distcc

DISTCC_SSH regression in v3.4

The SSH issue is expected, since the distcc server container is started at the same time as the client container.

Knock-knock! Race condition! Who's there?

KSmanis

comment created time in 2 months