summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* cpufreq: Introduce cpufreq_driver_test_flags()Rafael J. Wysocki2020-11-052-0/+13
| | | | | | | | | | | | | | | commit a62f68f5ca53ab61cba2f0a410d0add7a6d54a52 upstream. Add a helper function to test the flags of the cpufreq driver in use againt a given flags mask. In particular, this will be needed to test the CPUFREQ_NEED_UPDATE_LIMITS cpufreq driver flag in the schedutil governor. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: octeon: Drop on uncorrectable alignment or FCS errorAlexander Sverdlin2020-11-051-15/+19
| | | | | | | | | | | | | | | commit 49d28ebdf1e30d806410eefc7de0a7a1ca5d747c upstream. Currently in case of alignment or FCS error if the packet cannot be corrected it's still not dropped. Report the error properly and drop the packet while making the code around a little bit more readable. Fixes: 80ff0fd3ab64 ("Staging: Add octeon-ethernet driver files.") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201016145630.41852-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: octeon: repair "fixed-link" supportAlexander Sverdlin2020-11-052-6/+9
| | | | | | | | | | | | | | commit 179f5dc36b0a1aa31538d7d8823deb65c39847b3 upstream. The PHYs must be registered once in device probe function, not in device open callback because it's only possible to register them once. Fixes: a25e278020bf ("staging: octeon: support fixed-link phys") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201016101858.11374-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: comedi: cb_pcidas: Allow 2-channel commands for AO subdeviceIan Abbott2020-11-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | commit 647a6002cb41d358d9ac5de101a8a6dc74748a59 upstream. The "cb_pcidas" driver supports asynchronous commands on the analog output (AO) subdevice for those boards that have an AO FIFO. The code (in `cb_pcidas_ao_check_chanlist()` and `cb_pcidas_ao_cmd()`) to validate and set up the command supports output to a single channel or to two channels simultaneously (the boards have two AO channels). However, the code in `cb_pcidas_auto_attach()` that initializes the subdevices neglects to initialize the AO subdevice's `len_chanlist` member, leaving it set to 0, but the Comedi core will "correct" it to 1 if the driver neglected to set it. This limits commands to use a single channel (either channel 0 or 1), but the limit should be two channels. Set the AO subdevice's `len_chanlist` member to be the same value as the `n_chan` member, which will be 2. Cc: <stable@vger.kernel.org> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20201021122142.81628-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: fieldbus: anybuss: jump to correct label in an error pathJing Xiangfeng2020-11-051-1/+1
| | | | | | | | | | | | | | | | commit 7e97e4cbf30026b49b0145c3bfe06087958382c5 upstream. In current code, controller_probe() misses to call ida_simple_remove() in an error path. Jump to correct label to fix it. Fixes: 17614978ed34 ("staging: fieldbus: anybus-s: support the Arcx anybus controller") Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201012132404.113031-1-jingxiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* stop_machine, rcu: Mark functions as notraceZong Li2020-11-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4230e2deaa484b385aa01d598b2aea8e7f2660a6 upstream. Some architectures assume that the stopped CPUs don't make function calls to traceable functions when they are in the stopped state. See also commit cb9d7fd51d9f ("watchdog: Mark watchdog touch functions as notrace"). Violating this assumption causes kernel crashes when switching tracer on RISC-V. Mark rcu_momentary_dyntick_idle() and stop_machine_yield() notrace to prevent this. Fixes: 4ecf0a43e729 ("processor: get rid of cpu_relax_yield") Fixes: 366237e7b083 ("stop_machine: Provide RCU quiescent state in multi_cpu_stop()") Signed-off-by: Zong Li <zong.li@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Atish Patra <atish.patra@wdc.com> Tested-by: Colin Ian King <colin.king@canonical.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Acked-by: Paul E. McKenney <paulmck@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201021073839.43935-1-zong.li@sifive.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* KVM: arm64: Fix AArch32 handling of DBGD{CCINT,SCRext} and DBGVCRMarc Zyngier2020-11-052-3/+4
| | | | | | | | | | | | | | | | | commit 4a1c2c7f63c52ccb11770b5ae25920a6b79d3548 upstream. The DBGD{CCINT,SCRext} and DBGVCR register entries in the cp14 array are missing their target register, resulting in all accesses being targetted at the guard sysreg (indexed by __INVALID_SYSREG__). Point the emulation code at the actual register entries. Fixes: bdfb4b389c8d ("arm64: KVM: add trap handlers for AArch32 debug registers") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201029172409.2768336-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* KVM: x86: Fix NULL dereference at kvm_msr_ignored_check()Takashi Iwai2020-11-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | commit d383b3146d805a743658225c8973f5d38c6fedf4 upstream. The newly introduced kvm_msr_ignored_check() tries to print error or debug messages via vcpu_*() macros, but those may cause Oops when NULL vcpu is passed for KVM_GET_MSRS ioctl. Fix it by replacing the print calls with kvm_*() macros. (Note that this will leave vcpu argument completely unused in the function, but I didn't touch it to make the fix as small as possible. A clean up may be applied later.) Fixes: 12bc2132b15e ("KVM: X86: Do the same ignore_msrs check for feature msrs") BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178280 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-Id: <20201030151414.20165-1-tiwai@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* device property: Don't clear secondary pointer for shared primary firmware nodeAndy Shevchenko2020-11-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | commit 99aed9227073fb34ce2880cbc7063e04185a65e1 upstream. It appears that firmware nodes can be shared between devices. In such case when a (child) device is about to be deleted, its firmware node may be shared and ACPI_COMPANION_SET(..., NULL) call for it breaks the secondary link of the shared primary firmware node. In order to prevent that, check, if the device has a parent and parent's firmware node is shared with its child, and avoid crashing the link. Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") Reported-by: Ferry Toth <fntoth@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* device property: Keep secondary firmware node secondary by typeAndy Shevchenko2020-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d5dcce0c414fcbfe4c2037b66ac69ea5f9b3f75c upstream. Behind primary and secondary we understand the type of the nodes which might define their ordering. However, if primary node gone, we can't maintain the ordering by definition of the linked list. Thus, by ordering secondary node becomes first in the list. But in this case the meaning of it is still secondary (or auxiliary). The type of the node is maintained by the secondary pointer in it: secondary pointer Meaning NULL or valid primary node ERR_PTR(-ENODEV) secondary node So, if by some reason we do the following sequence of calls set_primary_fwnode(dev, NULL); set_primary_fwnode(dev, primary); we should preserve secondary node. This concept is supported by the description of set_primary_fwnode() along with implementation of set_secondary_fwnode(). Hence, fix the commit c15e1bdda436 to follow this as well. Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") Cc: Ferry Toth <fntoth@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* coresight: cti: Initialize dynamic sysfs attributesSuzuki K Poulose2020-11-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 80624263fa289b3416f7ca309491f1b75e579477 upstream. With LOCKDEP enabled, CTI driver triggers the following splat due to uninitialized lock class for dynamically allocated attribute objects. [ 5.372901] coresight etm0: CPU0: ETM v4.0 initialized [ 5.376694] coresight etm1: CPU1: ETM v4.0 initialized [ 5.380785] coresight etm2: CPU2: ETM v4.0 initialized [ 5.385851] coresight etm3: CPU3: ETM v4.0 initialized [ 5.389808] BUG: key ffff00000564a798 has not been registered! [ 5.392456] ------------[ cut here ]------------ [ 5.398195] DEBUG_LOCKS_WARN_ON(1) [ 5.398233] WARNING: CPU: 1 PID: 32 at kernel/locking/lockdep.c:4623 lockdep_init_map_waits+0x14c/0x260 [ 5.406149] Modules linked in: [ 5.415411] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.9.0-12034-gbbe85027ce80 #51 [ 5.418553] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 5.426453] Workqueue: events amba_deferred_retry_func [ 5.433299] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 5.438252] pc : lockdep_init_map_waits+0x14c/0x260 [ 5.444410] lr : lockdep_init_map_waits+0x14c/0x260 [ 5.449007] sp : ffff800012bbb720 ... [ 5.531561] Call trace: [ 5.536847] lockdep_init_map_waits+0x14c/0x260 [ 5.539027] __kernfs_create_file+0xa8/0x1c8 [ 5.543539] sysfs_add_file_mode_ns+0xd0/0x208 [ 5.548054] internal_create_group+0x118/0x3c8 [ 5.552307] internal_create_groups+0x58/0xb8 [ 5.556733] sysfs_create_groups+0x2c/0x38 [ 5.561160] device_add+0x2d8/0x768 [ 5.565148] device_register+0x28/0x38 [ 5.568537] coresight_register+0xf8/0x320 [ 5.572358] cti_probe+0x1b0/0x3f0 ... Fix this by initializing the attributes when they are allocated. Fixes: 3c5597e39812 ("coresight: cti: Add connection information to sysfs") Reported-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201029164559.1268531-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* null_blk: synchronization fix for zoned deviceKanchan Joshi2020-11-052-4/+19
| | | | | | | | | | | | | | | | | | commit 35bc10b2eafbb701064b94f283b77c54d3304842 upstream. Parallel write,read,zone-mgmt operations accessing/altering zone state and write-pointer may get into race. Avoid the situation by using a new spinlock for zoned device. Concurrent zone-appends (on a zone) returning same write-pointer issue is also avoided using this lock. Cc: stable@vger.kernel.org Fixes: e0489ed5daeb ("null_blk: Support REQ_OP_ZONE_APPEND") Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: marvell: espressobin: Add ethernet switch aliasesPali Rohár2020-11-053-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b64d814257b027e29a474bcd660f6372490138c7 upstream. Espressobin boards have 3 ethernet ports and some of them got assigned more then one MAC address. MAC addresses are stored in U-Boot environment. Since commit a2c7023f7075c ("net: dsa: read mac address from DT for slave device") kernel can use MAC addresses from DT for particular DSA port. Currently Espressobin DTS file contains alias just for ethernet0. This patch defines additional ethernet aliases in Espressobin DTS files, so bootloader can fill correct MAC address for DSA switch ports if more MAC addresses were specified. DT alias ethernet1 is used for wan port, DT aliases ethernet2 and ethernet3 are used for lan ports for both Espressobin revisions (V5 and V7). Fixes: 5253cb8c00a6f ("arm64: dts: marvell: espressobin: add ethernet alias") Cc: <stable@vger.kernel.org> # a2c7023f7075c: dsa: read mac address Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: Change .weak to SYM_FUNC_START_WEAK_PI for arch/arm64/lib/mem*.SFangrui Song2020-11-053-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | commit ec9d78070de986ecf581ea204fd322af4d2477ec upstream. Commit 39d114ddc682 ("arm64: add KASAN support") added .weak directives to arch/arm64/lib/mem*.S instead of changing the existing SYM_FUNC_START_PI macros. This can lead to the assembly snippet `.weak memcpy ... .globl memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Use the appropriate SYM_FUNC_START_WEAK_PI instead. Fixes: 39d114ddc682 ("arm64: add KASAN support") Reported-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Fangrui Song <maskray@google.com> Tested-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201029181951.1866093-1-maskray@google.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: s3c24xx: fix missing system resetKrzysztof Kozlowski2020-11-051-0/+2
| | | | | | | | | | | | | | | commit f6d7cde84f6c5551586c8b9b68d70f8e6dc9a000 upstream. Commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart code") removed usage of the watchdog reset platform code in favor of the Samsung SoC watchdog driver. However the latter was not selected thus S3C24xx platforms lost reset abilities. Cc: <stable@vger.kernel.org> Fixes: f6361c6b3880 ("ARM: S3C24XX: remove separate restart code") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: samsung: fix PM debug build with DEBUG_LL but !MMUKrzysztof Kozlowski2020-11-051-0/+1
| | | | | | | | | | | | | | | | | | | commit 7be0d19c751b02db778ca95e3274d5ea7f31891c upstream. Selecting CONFIG_SAMSUNG_PM_DEBUG (depending on CONFIG_DEBUG_LL) but without CONFIG_MMU leads to build errors: arch/arm/plat-samsung/pm-debug.c: In function ‘s3c_pm_uart_base’: arch/arm/plat-samsung/pm-debug.c:57:2: error: implicit declaration of function ‘debug_ll_addr’ [-Werror=implicit-function-declaration] Fixes: 99b2fc2b8b40 ("ARM: SAMSUNG: Use debug_ll_addr() to get UART base address") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200910154150.3318-1-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: config: aspeed: Fix selection of media driversJoel Stanley2020-11-052-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | commit 98c3f0a1b3ef83f6be6b212c970bee795e1a0467 upstream. In the 5.7 merge window the media kconfig was restructued. For most platforms these changes set CONFIG_MEDIA_SUPPORT_FILTER=y which keeps unwanted drivers disabled. The exception is if a config sets EMBEDDED or EXPERT (see b0cd4fb27665). In that case the filter is set to =n, causing a bunch of DVB tuner drivers (MEDIA_TUNER_*) to be accidentally enabled. This was noticed as it blew out the build time for the Aspeed defconfigs. Enabling the filter means the Aspeed config also needs to set CONFIG_MEDIA_PLATFORM_SUPPORT=y in order to have the CONFIG_VIDEO_ASPEED driver enabled. Fixes: 06b93644f4d1 ("media: Kconfig: add an option to filter in/out platform drivers") Fixes: b0cd4fb27665 ("media: Kconfig: on !EMBEDDED && !EXPERT, enable driver filtering") Signed-off-by: Joel Stanley <joel@jms.id.au> Cc: stable@vger.kernel.org CC: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: dts: s5pv210: fix pinctrl property of "vibrator-en" regulator in AriesKrzysztof Kozlowski2020-11-051-1/+1
| | | | | | | | | | | | | | | commit 2c6658c607a3af2ed7bd41dc57a3dd31537d023e upstream. Fix typo in pinctrl property of "vibrator-en" fixed regulator in Aries family of boards. The error caused lack of pin configuration for the GPIO used in vibrator. Fixes: 04568cb58a43 ("ARM: dts: s5pv210: Disable pull for vibrator enable GPIO on Aries boards") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200907161141.31034-5-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: aspeed: g5: Do not set sirq polarityJoel Stanley2020-11-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit c82bf6e133d30e0f9172a20807814fa28aef0f67 upstream. A feature was added to the aspeed vuart driver to configure the vuart interrupt (sirq) polarity according to the LPC/eSPI strapping register. Systems that depend on a active low behaviour (sirq_polarity set to 0) such as OpenPower boxes also use LPC, so this relationship does not hold. Jeremy confirms that the s2600st which is strapped for eSPI also does not have this relationship. The property was added for a Tyan S7106 system which is not supported in the kernel tree. Should this or other systems wish to use this feature of the driver they should add it to the machine specific device tree. Fixes: c791fc76bc72 ("arm: dts: aspeed: Add vuart aspeed,sirq-polarity-sense...") Signed-off-by: Joel Stanley <joel@jms.id.au> Tested-by: Jeremy Kerr <jk@ozlabs.org> Reviewed-by: Jeremy Kerr <jk@ozlabs.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200812112400.2406734-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm: dts: mt7623: add missing pause for switchportFrank Wunderlich2020-11-051-0/+1
| | | | | | | | | | | | | | | commit 36f0a5fc5284838c544218666c63ee8cfa46a9c3 upstream. port6 of mt7530 switch (= cpu port 0) on bananapi-r2 misses pause option which causes rx drops on running iperf. Fixes: f4ff257cd160 ("arm: dts: mt7623: add support for Bananapi R2 (BPI-R2) board") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200907070517.51715-1-linux@fw-web.de Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* hil/parisc: Disable HIL driver when it gets stuckHelge Deller2020-11-053-8/+23
| | | | | | | | | | | | | | | | | | | | | | | commit 879bc2d27904354b98ca295b6168718e045c4aa2 upstream. When starting a HP machine with HIL driver but without an HIL keyboard or HIL mouse attached, it may happen that data written to the HIL loop gets stuck (e.g. because the transaction queue is full). Usually one will then have to reboot the machine because all you see is and endless output of: Transaction add failed: transaction already queued? In the higher layers hp_sdc_enqueue_transaction() is called to queued up a HIL packet. This function returns an error code, and this patch adds the necessary checks for this return code and disables the HIL driver if further packets can't be sent. Tested on a HP 730 and a HP 715/64 machine. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cachefiles: Handle readpage error correctlyMatthew Wilcox (Oracle)2020-11-051-1/+2
| | | | | | | | | | | | | | commit 9480b4e75b7108ee68ecf5bc6b4bd68e8031c521 upstream. If ->readpage returns an error, it has already unlocked the page. Fixes: 5e929b33c393 ("CacheFiles: Handle truncate unlocking the page we're reading") Cc: stable@vger.kernel.org Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: berlin: Select DW_APB_TIMER_OFJisheng Zhang2020-11-051-0/+1
| | | | | | | | | | | | | | commit b0fc70ce1f028e14a37c186d9f7a55e51439b83a upstream. Berlin SoCs always contain some DW APB timers which can be used as an always-on broadcast timer. Link: https://lore.kernel.org/r/20201009150536.214181fb@xhacker.debian Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: make FONTX ioctl use the tty pointer they were actually passedLinus Torvalds2020-11-051-17/+19
| | | | | | | | | | | | | | | | | | | | | | | | | commit 90bfdeef83f1d6c696039b6a917190dcbbad3220 upstream. Some of the font tty ioctl's always used the current foreground VC for their operations. Don't do that then. This fixes a data race on fg_console. Side note: both Michael Ellerman and Jiri Slaby point out that all these ioctls are deprecated, and should probably have been removed long ago, and everything seems to be using the KDFONTOP ioctl instead. In fact, Michael points out that it looks like busybox's loadfont program seems to have switched over to using KDFONTOP exactly _because_ of this bug (ahem.. 12 years ago ;-). Reported-by: Minh Yuan <yuanmingbuaa@gmail.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Jiri Slaby <jirislaby@kernel.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: correct the cu and rb info for sienna cichlidLikun Gao2020-11-051-0/+9
| | | | | | | | | | | | | | commit 687e79c0feb4243b141b1e9a20adba3c0ec66f7f upstream. Skip disabled sa to correct the cu_info and active_rbs for sienna cichlid. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amd/psp: Fix sysfs: cannot create duplicate filenameAndrey Grodzovsky2020-11-051-1/+2
| | | | | | | | | | | | | | | commit f1bcddffe46b349a82445a8d9efd5f5fcb72557f upstream. psp sysfs not cleaned up on driver unload for sienna_cichlid Fixes: ce87c98db428e7 ("drm/amdgpu: Include sienna_cichlid in USBC PD FW support.") Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amd/swsmu: add missing feature map for sienna_cichlidKevin Wang2020-11-052-0/+4
| | | | | | | | | | | | | | commit d48d7484d8dca1d4577fc53f1f826e68420d00eb upstream. it will cause smu sysfs node of "pp_features" show error. Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amd/pm: fix pp_dpm_fclkKenneth Feng2020-11-051-0/+3
| | | | | | | | | | | | | | commit 392d256fa26d943fb0a019fea4be80382780d3b1 upstream. fclk value is missing in pp_dpm_fclk. add this to correctly show the current value. Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amd/pm: increase mclk switch threshold to 200 usEvan Quan2020-11-051-1/+1
| | | | | | | | | | | | | | | | commit 83da6eea3af669ee0b1f1bc05ffd6150af984994 upstream. To avoid underflow seen on Polaris10 with some 3440x1440 144Hz displays. As the threshold of 190 us cuts too close to minVBlankTime of 192 us. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu/swsmu: drop smu i2c bus on navi1xAlex Deucher2020-11-051-26/+0
| | | | | | | | | | | | | | | | commit 10105d0c9763f058f6a9a09f78397d5bf94dc94c upstream. Stop registering the SMU i2c bus on navi1x. This leads to instability issues when userspace processes mess with the bus and also seems to cause display stability issues in some cases. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1314 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1341 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* futex: Adjust absolute futex timeouts with per time namespace offsetAndrei Vagin2020-11-051-0/+5
| | | | | | | | | | | | | | | | | | commit c2f7d08cccf4af2ce6992feaabb9e68e4ae0bff3 upstream. For all commands except FUTEX_WAIT, the timeout is interpreted as an absolute value. This absolute value is inside the task's time namespace and has to be converted to the host's time. Fixes: 5a590f35add9 ("posix-clocks: Wire up clock_gettime() with timens offsets") Reported-by: Hans van der Laan <j.h.vanderlaan@student.utwente.nl> Signed-off-by: Andrei Vagin <avagin@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015160020.293748-1-avagin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* memory: brcmstb_dpfe: Fix memory leakAlex Dewar2020-11-051-6/+10
| | | | | | | | | | | | | | | | | | commit 4da1edcf8f226d53c02c6b0e3077d581115b30d0 upstream. In brcmstb_dpfe_download_firmware(), memory is allocated to variable fw by firmware_request_nowarn(), but never released. Fix up to release fw on all return paths. Cc: <stable@vger.kernel.org> Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Alex Dewar <alex.dewar90@gmail.com> Acked-by: Markus Mayer <mmayer@broadcom.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200820172118.781324-1-alex.dewar90@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* memory: tegra: Remove GPU from DRM IOMMU groupThierry Reding2020-11-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | commit ea90f66f2a8629dde07328df0b8314aae5e54a47 upstream. Commit 63a613fdb16c ("memory: tegra: Add gr2d and gr3d to DRM IOMMU group") added the GPU to the DRM IOMMU group, which doesn't make any sense. This causes problems when Nouveau tries to attach to the SMMU and causes it to fall back to using the DMA API. Remove the GPU from the DRM groups to restore the old behaviour. The GPU should always have its own IOMMU domain to make sure it can map buffers into contiguous chunks (for big page support) without getting in the way of mappings from the DRM group. Cc: <stable@vger.kernel.org> Fixes: 63a613fdb16c ("memory: tegra: Add gr2d and gr3d to DRM IOMMU group") Reported-by: Matias Zuniga <matias.nicolas.zc@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20200901153248.1831263-1-thierry.reding@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mmc: sdhci: Use Auto CMD Auto Select only when v4_mode is trueJisheng Zhang2020-11-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | commit b3e1ea16fb39fb6e1a1cf1dbdd6738531de3dc7d upstream. sdhci-of-dwcmshc meets an eMMC read performance regression with below command after commit 427b6514d095 ("mmc: sdhci: Add Auto CMD Auto Select support"): dd if=/dev/mmcblk0 of=/dev/null bs=8192 count=100000 Before the commit, the above command gives 120MB/s After the commit, the above command gives 51.3 MB/s So it looks like sdhci-of-dwcmshc expects Version 4 Mode for Auto CMD Auto Select. Fix the performance degradation by ensuring v4_mode is true to use Auto CMD Auto Select. Fixes: 427b6514d095 ("mmc: sdhci: Add Auto CMD Auto Select support") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201015174115.4cf2c19a@xhacker.debian Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mmc: sdhci-of-esdhc: set timeout to max before tuningMichael Walle2020-11-051-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0add6e9b88d0632a25323aaf4987dbacb0e4ae64 upstream. On rare occations there is the following error: mmc0: Tuning timeout, falling back to fixed sampling clock There are SD cards which takes a significant longer time to reply to the first CMD19 command. The eSDHC takes the data timeout value into account during the tuning period. The SDHCI core doesn't explicitly set this timeout for the tuning procedure. Thus on the slow cards, there might be a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong sequence of events. In the end this will lead to an unsuccessful tuning procedure and to the above error. To workaround this, set the timeout to the maximum value (which is the best we can do) and the SDHCI core will take care of the proper timeout handling. Fixes: ba49cbd0936e ("mmc: sdhci-of-esdhc: add tuning support") Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201022222337.19857-1-michael@walle.cc Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mmc: sdhci-of-esdhc: make sure delay chain locked for HS400Yangbo Lu2020-11-052-0/+19
| | | | | | | | | | | | | | | | | | | | | commit 011fde48394b7dc8dfd6660d1013b26a00157b80 upstream. For eMMC HS400 mode initialization, the DLL reset is a required step if DLL is enabled to use previously, like in bootloader. This step has not been documented in reference manual, but the RM will be fixed sooner or later. This patch is to add the step of DLL reset, and make sure delay chain locked for HS400. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20201020081116.20918-1-yangbo.lu@nxp.com Fixes: 54e08d9a95ca ("mmc: sdhci-of-esdhc: add hs400 mode support") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/ttm: fix eviction valuable range check.Dave Airlie2020-11-051-1/+1
| | | | | | | | | | | | | | | | | commit fea456d82c19d201c21313864105876deabe148b upstream. This was adding size to start, but pfn and start are in pages, so it should be using num_pages. Not sure this fixes anything in the real world, just noticed it during refactoring. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20201019222257.1684769-2-airlied@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: do not use extent after put_bhyangerkun2020-11-051-15/+15
| | | | | | | | | | | | | | | | commit d7dce9e08595e80bf8039a81794809c66fe26431 upstream. ext4_ext_search_right() will read more extent blocks and call put_bh after we get the information we need. However, ret_ex will break this and may cause use-after-free once pagecache has been freed. Fix it by copying the extent structure if needed. Signed-off-by: yangerkun <yangerkun@huawei.com> Link: https://lore.kernel.org/r/20201028055617.2569255-1-yangerkun@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix bs < ps issue reported with dioread_nolock mount optRitesh Harjani2020-11-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | commit d1e18b8824dd50cff255e6cecf515ea598eaf9f0 upstream. left shifting m_lblk by blkbits was causing value overflow and hence it was not able to convert unwritten to written extent. So, make sure we typecast it to loff_t before do left shift operation. Also in func ext4_convert_unwritten_io_end_vec(), make sure to initialize ret variable to avoid accidentally returning an uninitialized ret. This patch fixes the issue reported in ext4 for bs < ps with dioread_nolock mount option. Fixes: c8cc88163f40df39e50c ("ext4: Add support for blocksize < pagesize in dioread_nolock") Cc: stable@kernel.org Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/af902b5db99e8b73980c795d84ad7bb417487e76.1602168865.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix bdev write error check failed when mount fs with roZhang Xiaoxu2020-11-051-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | commit 9704a322ea67fdb05fc66cf431fdd01c2424bbd9 upstream. Consider a situation when a filesystem was uncleanly shutdown and the orphan list is not empty and a read-only mount is attempted. The orphan list cleanup during mount will fail with: ext4_check_bdev_write_error:193: comm mount: Error while async write back metadata This happens because sbi->s_bdev_wb_err is not initialized when mounting the filesystem in read only mode and so ext4_check_bdev_write_error() falsely triggers. Initialize sbi->s_bdev_wb_err unconditionally to avoid this problem. Fixes: bc71726c7257 ("ext4: abort the filesystem if failed to async write metadata buffer") Cc: stable@kernel.org Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20200928020556.710971-1-zhangxiaoxu5@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: clear buffer verified flag if read meta block from diskzhangyi (F)2020-11-055-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d9befedaafcf3a111428baa7c45b02923eab2d87 upstream. The metadata buffer is no longer trusted after we read it from disk again because it is not uptodate for some reasons (e.g. failed to write back). Otherwise we may get below memory corruption problem in ext4_ext_split()->memset() if we read stale data from the newly allocated extent block on disk which has been failed to async write out but miss verify again since the verified bit has already been set on the buffer. [ 29.774674] BUG: unable to handle kernel paging request at ffff88841949d000 ... [ 29.783317] Oops: 0002 [#2] SMP [ 29.784219] R10: 00000000000f4240 R11: 0000000000002e28 R12: ffff88842fa1c800 [ 29.784627] CPU: 1 PID: 126 Comm: kworker/u4:3 Tainted: G D W [ 29.785546] R13: ffffffff9cddcc20 R14: ffffffff9cddd420 R15: ffff88842fa1c2f8 [ 29.786679] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS ?-20190727_0738364 [ 29.787588] FS: 0000000000000000(0000) GS:ffff88842fa00000(0000) knlGS:0000000000000000 [ 29.789288] Workqueue: writeback wb_workfn [ 29.790319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.790321] (flush-8:0) [ 29.790844] CR2: 0000000000000008 CR3: 00000004234f2000 CR4: 00000000000006f0 [ 29.791924] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 29.792839] RIP: 0010:__memset+0x24/0x30 [ 29.793739] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 29.794256] Code: 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 033 [ 29.795161] Kernel panic - not syncing: Fatal exception in interrupt ... [ 29.808149] Call Trace: [ 29.808475] ext4_ext_insert_extent+0x102e/0x1be0 [ 29.809085] ext4_ext_map_blocks+0xa89/0x1bb0 [ 29.809652] ext4_map_blocks+0x290/0x8a0 [ 29.809085] ext4_ext_map_blocks+0xa89/0x1bb0 [ 29.809652] ext4_map_blocks+0x290/0x8a0 [ 29.810161] ext4_writepages+0xc85/0x17c0 ... Fix this by clearing buffer's verified bit if we read meta block from disk again. Signed-off-by: zhangyi (F) <yi.zhang@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200924073337.861472-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix invalid inode checksumLuo Meng2020-11-051-5/+6
| | | | | | | | | | | | | | | | | | | | | | commit 1322181170bb01bce3c228b82ae3d5c6b793164f upstream. During the stability test, there are some errors: ext4_lookup:1590: inode #6967: comm fsstress: iget: checksum invalid. If the inode->i_iblocks too big and doesn't set huge file flag, checksum will not be recalculated when update the inode information to it's buffer. If other inode marks the buffer dirty, then the inconsistent inode will be flushed to disk. Fix this problem by checking i_blocks in advance. Cc: stable@kernel.org Signed-off-by: Luo Meng <luomeng12@huawei.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Link: https://lore.kernel.org/r/20201020013631.3796673-1-luomeng12@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: implement swap_activate aops using iomapRitesh Harjani2020-11-051-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | commit 0e6895ba00b7be45f3ab0d2107dda3ef1245f5b4 upstream. After moving ext4's bmap to iomap interface, swapon functionality on files created using fallocate (which creates unwritten extents) are failing. This is since iomap_bmap interface returns 0 for unwritten extents and thus generic_swapfile_activate considers this as holes and hence bail out with below kernel msg :- [340.915835] swapon: swapfile has holes To fix this we need to implement ->swap_activate aops in ext4 which will use ext4_iomap_report_ops. Since we only need to return the list of extents so ext4_iomap_report_ops should be enough. Cc: stable@kernel.org Reported-by: Yuxuan Shui <yshuiv7@gmail.com> Fixes: ac58e4fb03f ("ext4: move ext4 bmap to use iomap infrastructure") Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/20200904091653.1014334-1-riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix error handling code in add_new_gdbDinghao Liu2020-11-051-1/+3
| | | | | | | | | | | | | | | | commit c9e87161cc621cbdcfc472fa0b2d81c63780c8f5 upstream. When ext4_journal_get_write_access() fails, we should terminate the execution flow and release n_group_desc, iloc.bh, dind and gdb_bh. Cc: stable@kernel.org Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/20200829025403.3139-1-dinghao.liu@zju.edu.cn Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix leaking sysfs kobject after failed mountEric Biggers2020-11-051-0/+1
| | | | | | | | | | | | | | | | | | | | | commit cb8d53d2c97369029cc638c9274ac7be0a316c75 upstream. ext4_unregister_sysfs() only deletes the kobject. The reference to it needs to be put separately, like ext4_put_super() does. This addresses the syzbot report "memory leak in kobject_set_name_vargs (3)" (https://syzkaller.appspot.com/bug?extid=9f864abad79fae7c17e1). Reported-by: syzbot+9f864abad79fae7c17e1@syzkaller.appspotmail.com Fixes: 72ba74508b28 ("ext4: release sysfs kobject when failing to enable quotas on mount") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20200922162456.93657-1-ebiggers@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* vringh: fix __vringh_iov() when riov and wiov are differentStefano Garzarella2020-11-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5745bcfbbf89b158416075374254d3c013488f21 upstream. If riov and wiov are both defined and they point to different objects, only riov is initialized. If the wiov is not initialized by the caller, the function fails returning -EINVAL and printing "Readable desc 0x... after writable" error message. This issue happens when descriptors have both readable and writable buffers (eg. virtio-blk devices has virtio_blk_outhdr in the readable buffer and status as last byte of writable buffer) and we call __vringh_iov() to get both type of buffers in two different iovecs. Let's replace the 'else if' clause with 'if' to initialize both riov and wiov if they are not NULL. As checkpatch pointed out, we also avoid crashing the kernel when riov and wiov are both NULL, replacing BUG() with WARN_ON() and returning -EINVAL. Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20201008204256.162292-1-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: intel_pstate: Avoid missing HWP max updates in passive modeRafael J. Wysocki2020-11-051-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e0be38ed4ab413ddd492118cf146369b86ee0ab5 upstream. If the cpufreq policy max limit is changed when intel_pstate operates in the passive mode with HWP enabled and the "powersave" governor is used on top of it, the HWP max limit is not updated as appropriate. Namely, in the "powersave" governor case, the target P-state is always equal to the policy min limit, so if the latter does not change, intel_cpufreq_adjust_hwp() is not invoked to update the HWP Request MSR due to the "target_pstate != old_pstate" check in intel_cpufreq_update_pstate(), so the HWP max limit is not updated as a result. Also, if the CPUFREQ_NEED_UPDATE_LIMITS flag is not set for the driver and the target frequency does not change along with the policy max limit, the "target_freq == policy->cur" check in __cpufreq_driver_target() prevents the driver's ->target() callback from being invoked at all, so the HWP max limit is not updated. To prevent that occurring, set the CPUFREQ_NEED_UPDATE_LIMITS flag in the intel_cpufreq driver structure if HWP is enabled and modify intel_cpufreq_update_pstate() to do the "target_pstate != old_pstate" check only in the non-HWP case and let intel_cpufreq_adjust_hwp() always run in the HWP case (it will update HWP Request only if the cached value of the register is different from the new one including the limits, so if neither the target P-state value nor the max limit changes, the register write will still be avoided). Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Reported-by: Zhang Rui <rui.zhang@intel.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+: 1c534352f47f cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS ... Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flagRafael J. Wysocki2020-11-052-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1c534352f47fd83eb08075ac2474f707e74bf7f7 upstream. Generally, a cpufreq driver may need to update some internal upper and lower frequency boundaries on policy max and min changes, respectively, but currently this does not work if the target frequency does not change along with the policy limit. Namely, if the target frequency does not change along with the policy min or max, the "target_freq == policy->cur" check in __cpufreq_driver_target() prevents driver callbacks from being invoked and they do not even have a chance to update the corresponding internal boundary. This particularly affects the "powersave" and "performance" governors that always set the target frequency to one of the policy limits and it never changes when the other limit is updated. To allow cpufreq the drivers needing to update internal frequency boundaries on policy limits changes to avoid this issue, introduce a new driver flag, CPUFREQ_NEED_UPDATE_LIMITS, that (when set) will neutralize the check mentioned above. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Avoid configuring old governors as default with intel_pstateRafael J. Wysocki2020-11-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit db865272d9c4687520dc29f77e701a1b2669872f upstream. Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") was meant to cause intel_pstate to be used in the passive mode with the schedutil governor on top of it, but it missed the case in which either "ondemand" or "conservative" was selected as the default governor in the existing kernel config, in which case the previous old governor configuration would be used, causing the default legacy governor to be used on top of intel_pstate instead of schedutil. Address this by preventing "ondemand" and "conservative" from being configured as the default cpufreq governor in the case when schedutil is the default choice for the default governor setting. [Note that the default cpufreq governor can still be set via the kernel command line if need be and that choice is not limited, so if anyone really wants to use one of the legacy governors by default, it can be achieved this way.] Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") Reported-by: Julia Lawall <julia.lawall@inria.fr> Cc: 5.8+ <stable@vger.kernel.org> # 5.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* intel_idle: Fix max_cstate for processor models without C-state tablesChen Yu2020-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4e0ba5577dba686f96c1c10ef4166380667fdec7 upstream. Currently intel_idle driver gets the c-state information from ACPI _CST if the processor model is not recognized by it. However the c-state in _CST starts with index 1 which is different from the index in intel_idle driver's internal c-state table. While intel_idle_max_cstate_reached() was previously introduced to deal with intel_idle driver's internal c-state table, re-using this function directly on _CST is incorrect. Fix this by subtracting 1 from the index when checking max_cstate in the _CST case. For example, append intel_idle.max_cstate=1 in boot command line, Before the patch: grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name POLL After the patch: grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name /sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1_ACPI Fixes: 18734958e9bf ("intel_idle: Use ACPI _CST for processor models without C-state tables") Reported-by: Pengfei Xu <pengfei.xu@intel.com> Cc: 5.6+ <stable@vger.kernel.org> # 5.6+ Signed-off-by: Chen Yu <yu.c.chen@intel.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-25 03:15:22 +0000