[pull] master from torvalds:master#603
Merged
pull[bot] merged 36 commits intobergwolf:masterfrom Jun 8, 2021
Merged
Conversation
Show proper error code instead of 0. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210512075824.620580-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
The TCS4525 has 128 voltage steps. With the calculation set to 127 the most significant bit is disregarded which leads to a miscalculation of the voltage by about 200mv. Fix the calculation to end deadlock on the rk3566-quartz64 which uses this as the cpu regulator. Fixes: 914df8f ("regulator: fan53555: Add TCS4525 DCDC support") Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20210511211335.2935163-2-pgwipeout@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
…r Geis <pgwipeout@gmail.com>: The tcs4525 voltage calculation is incorrect, which leads to a deadlock on the rk3566-quartz64 board when loading cpufreq. Fix the voltage calculation to correct the deadlock. While we are at it, add a safety check and clean up the function names to be more accurate. Peter Geis (3): regulator: fan53555: fix TCS4525 voltage calulation regulator: fan53555: only bind tcs4525 to correct chip id regulator: fan53555: fix tcs4525 function names drivers/regulator/fan53555.c | 44 ++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 17 deletions(-) -- 2.25.1
-EINVAL is not a valid return value for .of_map_mode, return REGULATOR_MODE_INVALID instead. Fixes: 65ac970 ("regulator: da9121: add mode support") Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/20210517052721.1063375-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
Fixes: e6dea51 ("regulator: fan53880: Add initial support") Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Christoph Fritz <chf.fritz@googlemail.com> Link: https://lore.kernel.org/r/20210517105325.1227393-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
Return -EINVAL if ramp_delay_table is NULL. Also add WARN_ON since the driver code needs fix if this happened. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210519132255.1683863-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
…ble fails dev_pm_genpd_set_performance_state() may fail, so had better to check it's return value before decreasing priv->enable_counter. Fixes: bf3a28c ("regulator: fixed: support using power domain for enable/disable") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210520111811.1806293-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb9 ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
…ting For linear regulators, the .n_voltages is (max_uv - min_uv) / uv_step + 1. Fixes: 0fbeae7 ("regulator: add SCMI driver") Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20210521073020.1944981-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
The MAX77620 driver fails to re-probe on deferred probe because driver core tries to claim resources that are already claimed by the PINCTRL device. Use device_set_of_node_from_dev() helper which marks OF node as reused, skipping erroneous execution of pinctrl_bind_pins() for the PMIC device on the re-probe. Fixes: aea6cb9 ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210523224243.13219-2-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
One of previous changes to regulator core causes PMIC regulators to re-probe until supply regulator is registered. Silence noisy error message about the deferred probe. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210523224243.13219-3-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
The valid selectors for bd70528 bucks are 0 ~ 0xf, so the .n_voltages should be 16 (0x10). Use 0x10 to make it consistent with BD70528_LDO_VOLTS. Also remove redundant defines for BD70528_BUCK_VOLTS. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210523071045.2168904-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
Current .n_voltages settings do not cover the latest 2 valid selectors, so it fails to set voltage for the hightest voltage support. The latest linear range has step_uV = 0, so it does not matter if we count the .n_voltages to maximum selector + 1 or the first selector of latest linear range + 1. To simplify calculating the n_voltages, let's just set the .n_voltages to maximum selector + 1. Fixes: 522498f ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators") Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210523071045.2168904-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
s/Hisilicon/HiSilicon/. It should use capital S, according to the official website https://www.hisilicon.com/en. Signed-off-by: Hao Fang <fanghao11@huawei.com> Link: https://lore.kernel.org/r/1621679151-15617-1-git-send-email-fanghao11@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 571e31f ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[] in the driver private data which contains a per-slave register value. The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device(). However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[]. As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves. Fixes: 571e31f ("spi: bcm2835: Cache CS register value for ->prepare_message()") Reported-by: Joe Burmeister <joe.burmeister@devtank.co.uk> Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v5.4+ Cc: Phil Elwell <phil@raspberrypi.com> Link: https://lore.kernel.org/r/75854affc1923309fde05e47494263bde73e5592.1621703210.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
…sipenko <digetx@gmail.com>: Hi, The next-20210521 started to fail on Nexus 7 because of the change to regulator core that caused regression of the MAX77620 regulator driver. The regulator driver is now getting a deferred probe and turned out driver wasn't ready for this. The root of the problem is that OF node of the PMIC MFD sub-device is shared with the PINCTRL sub-device and we need to convey this information to the driver core, otherwise it will try to claim GPIO pin that is already claimed by PINCTRL and fail the probe. Dmitry Osipenko (2): regulator: max77620: Use device_set_of_node_from_dev() regulator: max77620: Silence deferred probe error drivers/regulator/max77620-regulator.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) -- 2.30.2
Current code does not set .curr_table and .n_linear_ranges settings, so it cannot use the regulator_get/set_current_limit_regmap helpers. If we setup the curr_table, it will has 200 entries. Implement customized .set_current_limit/.get_current_limit callbacks instead. Fixes: b8c054a ("regulator: rtmv20: Adds support for Richtek RTMV20 load switch regulator") Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/20210530124101.477727-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
The other Richtek drivers has Richtek prefix, make it consistent. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210530124101.477727-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
The .of_map_mode should has below function prototype: unsigned int (*of_map_mode)(unsigned int mode); Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210530022109.425054-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
- Fix to make regcache value first reading back from HW. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1622542155-6373-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
…nges The .n_voltages was missed for pickable linear ranges, fix it. The min_sel for each pickable range should be starting from 0. Also fix atc260x_ldo_voltage_range_sel setting (bit 5 - LDO<N>_VOL_SEL in datasheet). Fixes: 3b15cca ("regulator: Add regulator driver for ATC260x PMICs") Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Link: https://lore.kernel.org/r/20210528230147.363974-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
Commit c7299fe ("spi: Fix spi device unregister flow") changed the SPI core's behavior if the ->setup() hook returns an error upon adding an spi_device: Before, the ->cleanup() hook was invoked to free any allocations that were made by ->setup(). With the commit, that's no longer the case, so the ->setup() hook is expected to free the allocations itself. I've identified 5 drivers which depend on the old behavior and am fixing them up hereinafter: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c spi-omap2-mcspi.c spi-pxa2xx.c Importantly, ->setup() is not only invoked on spi_device *addition*: It may subsequently be called to *change* SPI parameters. If changing these SPI parameters fails, freeing memory allocations would be wrong. That should only be done if the spi_device is finally destroyed. I am therefore using a bool "initial_setup" in 4 of the affected drivers to differentiate between the invocation on *adding* the spi_device and any subsequent invocations: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c spi-omap2-mcspi.c In spi-pxa2xx.c, it seems the ->setup() hook can only fail on spi_device addition, not any subsequent calls. It therefore doesn't need the bool. It's worth noting that 5 other drivers already perform a cleanup if the ->setup() hook fails. Before c7299fe, they caused a double-free if ->setup() failed on spi_device addition. Since the commit, they're fine. These drivers are: spi-mpc512x-psc.c spi-pl022.c spi-s3c64xx.c spi-st-ssc4.c spi-tegra114.c (spi-pxa2xx.c also already performs a cleanup, but only in one of several error paths.) Fixes: c7299fe ("spi: Fix spi device unregister flow") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: Saravana Kannan <saravanak@google.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # pxa2xx Link: https://lore.kernel.org/r/f76a0599469f265b69c371538794101fa37b5536.1622149321.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
Changing the BD71837 voltages for other regulators except the first 4 BUCKs should be forbidden when the regulator is enabled. There may be out-of-spec voltage spikes if the voltage of these "non DVS" bucks is changed when enabled. This restriction was accidentally removed when the LDO voltage change was allowed for BD71847. (It was not noticed that the BD71837 BUCK7 used same voltage setting function as LDOs). Additionally this bug causes incorrect voltage monitoring register access. The voltage change function accidentally used for bd71837 BUCK7 is intended to only handle LDO voltage changes. A BD71847 LDO specific voltage monitoring disabling code gets executed on BD71837 and register offsets are wrongly calculated as regulator is assumed to be an LDO. Prevent the BD71837 BUCK7 voltage change when BUCK7 is enabled by using the correct voltage setting operation. Fixes: 9bcbaba ("regulator: bd718x7: remove voltage change restriction from BD71847 LDOs") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/bd8c00931421fafa57e3fdf46557a83075b7cc17.1622610103.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
In zynq_qspi_probe function, when enable the device clock is done, the return of all the functions should goto the clk_dis_all label. If num_cs is not right then this should return a negative error code but currently it returns success. Signed-off-by: zpershuai <zpershuai@gmail.com> Link: https://lore.kernel.org/r/1622110857-21812-1-git-send-email-zpershuai@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 83109d5 ("x86/build: Warn on orphan section placement"), we get a warning for objects in orphan sections. The cpuidle implementation for OMAP causes this when CONFIG_CPU_IDLE is disabled: arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table' arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table' arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table' Change the definition of CPUIDLE_METHOD_OF_DECLARE() to silently drop the table and all code referenced from it when CONFIG_CPU_IDLE is disabled. Fixes: 06ee7a9 ("ARM: OMAP2+: pm33xx-core: Add cpuidle_ops for am335x/am437x") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201230155506.1085689-1-arnd@kernel.org
With x86_64_defconfig and the following configs, there is an orphan section warning: CONFIG_SMP=n CONFIG_AMD_MEM_ENCRYPT=y CONFIG_HYPERVISOR_GUEST=y CONFIG_KVM=y CONFIG_PARAVIRT=y ld: warning: orphan section `.data..decrypted' from `arch/x86/kernel/cpu/vmware.o' being placed in section `.data..decrypted' ld: warning: orphan section `.data..decrypted' from `arch/x86/kernel/kvm.o' being placed in section `.data..decrypted' These sections are created with DEFINE_PER_CPU_DECRYPTED, which ultimately turns into __PCPU_ATTRS, which in turn has a section attribute with a value of PER_CPU_BASE_SECTION + the section name. When CONFIG_SMP is not set, the base section is .data and that is not currently handled in any linker script. Add .data..decrypted to PERCPU_DECRYPTED_SECTION, which is included in PERCPU_INPUT -> PERCPU_SECTION, which is include in the x86 linker script when either CONFIG_X86_64 or CONFIG_SMP is unset, taking care of the warning. Fixes: ac26963 ("percpu: Introduce DEFINE_PER_CPU_DECRYPTED") Link: ClangBuiltLinux#1360 Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210506001410.1026691-1-nathan@kernel.org
Take ldo3_voltages as example, the ARRAY_SIZE(ldo3_voltages) is 16. i.e. the valid selector is 0 ~ 0xF. But in current code the vsel_mask is "(1 << 15) - 1", i.e. 0x7FFF. Fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210529013236.373847-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
…t_cmd() In U-boot side, an issue has been encountered when QSPI source clock is running at low frequency (24 MHz for example), waiting for TCF bit to be set didn't ensure that all data has been send out the FIFO, we should also wait that BUSY bit is cleared. To prevent similar issue in kernel driver, we implement similar behavior by always waiting BUSY bit to be cleared. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://lore.kernel.org/r/20210603073421.8441-1-patrice.chotard@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
… is NULL devm_gpiod_get_array_optional may return NULL if no GPIO was assigned. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210603094944.1114156-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
Do this in order to prevent the task from being freed if the thread returns (which can be triggered by the frontend) before the call to kthread_stop done as part of the backend tear down. Not taking the reference will lead to a use-after-free in that scenario. Such reference was taken before but dropped as part of the rework done in 2ac061c. Reintroduce the reference taking and add a comment this time explaining why it's needed. This is XSA-374 / CVE-2021-28691. Fixes: 2ac061c ('xen/netback: cleanup init and deinit code') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: stable@vger.kernel.org Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
In commit e87b03f ("afs: Prepare for use of THPs"), the return value for afs_write_back_from_locked_page was changed from a number of pages to a length in bytes. The loop in afs_writepages_region uses the return value to compute the index that will be used to find dirty pages in the next iteration, but treats it as a number of pages and wrongly multiplies it by PAGE_SIZE. This gives a very large index value, potentially skipping any dirty data that was not covered in the first pass, which is limited to 256M. This causes fsync(), and indirectly close(), to only do a partial writeback of a large file's dirty data. The rest is eventually written back by background threads after dirty_expire_centisecs. Fixes: e87b03f ("afs: Prepare for use of THPs") Signed-off-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeffrey Altman <jaltman@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20210604175504.4055-1-marc.c.dionne@gmail.com/ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
…inux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A collection of fixes for the regulator API that have come up since the merge window, including a big batch of fixes from Axel Lin's usual careful and detailed review. The one stand out fix here is Dmitry Baryshkov's fix for an issue where we fail to power on the parents of always on regulators during system startup if they weren't already powered on" * tag 'regulator-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (21 commits) regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL regulator: hi6421v600: Fix .vsel_mask setting regulator: bd718x7: Fix the BUCK7 voltage setting on BD71837 regulator: atc260x: Fix n_voltages and min_sel for pickable linear ranges regulator: rtmv20: Fix to make regcache value first reading back from HW regulator: mt6315: Fix function prototype for mt6315_map_mode regulator: rtmv20: Add Richtek to Kconfig text regulator: rtmv20: Fix .set_current_limit/.get_current_limit callbacks regulator: hisilicon: use the correct HiSilicon copyright regulator: bd71828: Fix .n_voltages settings regulator: bd70528: Fix off-by-one for buck123 .n_voltages setting regulator: max77620: Silence deferred probe error regulator: max77620: Use device_set_of_node_from_dev() regulator: scmi: Fix off-by-one for linear regulators .n_voltages setting regulator: core: resolve supply for boot-on/always-on regulators regulator: fixed: Ensure enable_counter is correct if reg_domain_disable fails regulator: Check ramp_delay_table for regulator_set_ramp_delay_regmap regulator: fan53880: Fix missing n_voltages setting regulator: da9121: Return REGULATOR_MODE_INVALID for invalid mode regulator: fan53555: fix TCS4525 voltage calulation ...
…ernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small set of SPI fixes that have come up since the merge window, all fairly small fixes for rare cases" * tag 'spi-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: stm32-qspi: Always wait BUSY bit to be cleared in stm32_qspi_wait_cmd() spi: spi-zynq-qspi: Fix some wrong goto jumps & missing error code spi: Cleanup on failure of initial setup spi: bcm2835: Fix out-of-bounds access with more than 4 slaves
Commit bfb819e ("proc: Check /proc/$pid/attr/ writes against file opener") tried to make sure that there could not be a confusion between the opener of a /proc/$pid/attr/ file and the writer. It used struct cred to make sure the privileges didn't change. However, there were existing cases where a more privileged thread was passing the opened fd to a differently privileged thread (during container setup). Instead, use mm_struct to track whether the opener and writer are still the same process. (This is what several other proc files already do, though for different reasons.) Reported-by: Christian Brauner <christian.brauner@ubuntu.com> Reported-by: Andrea Righi <andrea.righi@canonical.com> Tested-by: Andrea Righi <andrea.righi@canonical.com> Fixes: bfb819e ("proc: Check /proc/$pid/attr/ writes against file opener") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
…ernel/git/kees/linux Pull orphan section fixes from Kees Cook: "These two corner case fixes have been in -next for about a week: - Avoid orphan section in ARM cpuidle (Arnd Bergmann) - Avoid orphan section with !SMP (Nathan Chancellor)" * tag 'orphans-v5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: vmlinux.lds.h: Avoid orphan section with !SMP ARM: cpuidle: Avoid orphan section warning
…inux/kernel/git/xen/tip Pull xen fix from Juergen Gross: "A single patch fixing a Xen related security bug: a malicious guest might be able to trigger a 'use after free' issue in the xen-netback driver" * tag 'for-linus-5.13b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen-netback: take a reference to the RX task thread
pull bot
pushed a commit
that referenced
this pull request
Jul 10, 2021
Fixes checkpatch issues: CHECK: Alignment should match open parenthesis #87: FILE: drivers/reset/core.c:87: +static int of_reset_simple_xlate(struct reset_controller_dev *rcdev, + const struct of_phandle_args *reset_spec) CHECK: Lines should not end with a '(' #540: FILE: drivers/reset/core.c:540: +static struct reset_control *__reset_control_get_internal( CHECK: Alignment should match open parenthesis #603: FILE: drivers/reset/core.c:603: +struct reset_control *__of_reset_control_get(struct device_node *node, + const char *id, int index, bool shared, CHECK: Alignment should match open parenthesis #781: FILE: drivers/reset/core.c:781: +struct reset_control *__devm_reset_control_get(struct device *dev, + const char *id, int index, bool shared, Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
pull bot
pushed a commit
that referenced
this pull request
Jul 6, 2023
According to the synchronization rules for .ndo_get_stats() as seen in Documentation/networking/netdevices.rst, acquiring a plain spin_lock() should not be illegal, but the bridge driver implementation makes it so. After running these commands, I am being faced with the following lockdep splat: $ ip link add link swp0 name macsec0 type macsec encrypt on && ip link set swp0 up $ ip link add dev br0 type bridge vlan_filtering 1 && ip link set br0 up $ ip link set macsec0 master br0 && ip link set macsec0 up ======================================================== WARNING: possible irq lock inversion dependency detected 6.4.0-04295-g31b577b4bd4a #603 Not tainted -------------------------------------------------------- swapper/1/0 just changed the state of lock: ffff6bd348724cd8 (&br->lock){+.-.}-{3:3}, at: br_forward_delay_timer_expired+0x34/0x198 but this lock took another, SOFTIRQ-unsafe lock in the past: (&ocelot->stats_lock){+.+.}-{3:3} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Chain exists of: &br->lock --> &br->hash_lock --> &ocelot->stats_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ocelot->stats_lock); local_irq_disable(); lock(&br->lock); lock(&br->hash_lock); <Interrupt> lock(&br->lock); *** DEADLOCK *** (details about the 3 locks skipped) swp0 is instantiated by drivers/net/dsa/ocelot/felix.c, and this only matters to the extent that its .ndo_get_stats64() method calls spin_lock(&ocelot->stats_lock). Documentation/locking/lockdep-design.rst says: | A lock is irq-safe means it was ever used in an irq context, while a lock | is irq-unsafe means it was ever acquired with irq enabled. (...) | Furthermore, the following usage based lock dependencies are not allowed | between any two lock-classes:: | | <hardirq-safe> -> <hardirq-unsafe> | <softirq-safe> -> <softirq-unsafe> Lockdep marks br->hash_lock as softirq-safe, because it is sometimes taken in softirq context (for example br_fdb_update() which runs in NET_RX softirq), and when it's not in softirq context it blocks softirqs by using spin_lock_bh(). Lockdep marks ocelot->stats_lock as softirq-unsafe, because it never blocks softirqs from running, and it is never taken from softirq context. So it can always be interrupted by softirqs. There is a call path through which a function that holds br->hash_lock: fdb_add_hw_addr() will call a function that acquires ocelot->stats_lock: ocelot_port_get_stats64(). This can be seen below: ocelot_port_get_stats64+0x3c/0x1e0 felix_get_stats64+0x20/0x38 dsa_slave_get_stats64+0x3c/0x60 dev_get_stats+0x74/0x2c8 rtnl_fill_stats+0x4c/0x150 rtnl_fill_ifinfo+0x5cc/0x7b8 rtmsg_ifinfo_build_skb+0xe4/0x150 rtmsg_ifinfo+0x5c/0xb0 __dev_notify_flags+0x58/0x200 __dev_set_promiscuity+0xa0/0x1f8 dev_set_promiscuity+0x30/0x70 macsec_dev_change_rx_flags+0x68/0x88 __dev_set_promiscuity+0x1a8/0x1f8 __dev_set_rx_mode+0x74/0xa8 dev_uc_add+0x74/0xa0 fdb_add_hw_addr+0x68/0xd8 fdb_add_local+0xc4/0x110 br_fdb_add_local+0x54/0x88 br_add_if+0x338/0x4a0 br_add_slave+0x20/0x38 do_setlink+0x3a4/0xcb8 rtnl_newlink+0x758/0x9d0 rtnetlink_rcv_msg+0x2f0/0x550 netlink_rcv_skb+0x128/0x148 rtnetlink_rcv+0x24/0x38 the plain English explanation for it is: The macsec0 bridge port is created without p->flags & BR_PROMISC, because it is what br_manage_promisc() decides for a VLAN filtering bridge with a single auto port. As part of the br_add_if() procedure, br_fdb_add_local() is called for the MAC address of the device, and this results in a call to dev_uc_add() for macsec0 while the softirq-safe br->hash_lock is taken. Because macsec0 does not have IFF_UNICAST_FLT, dev_uc_add() ends up calling __dev_set_promiscuity() for macsec0, which is propagated by its implementation, macsec_dev_change_rx_flags(), to the lower device: swp0. This triggers the call path: dev_set_promiscuity(swp0) -> rtmsg_ifinfo() -> dev_get_stats() -> ocelot_port_get_stats64() with a calling context that lockdep doesn't like (br->hash_lock held). Normally we don't see this, because even though many drivers that can be bridge ports don't support IFF_UNICAST_FLT, we need a driver that (a) doesn't support IFF_UNICAST_FLT, *and* (b) it forwards the IFF_PROMISC flag to another driver, and (c) *that* driver implements ndo_get_stats64() using a softirq-unsafe spinlock. Condition (b) is necessary because the first __dev_set_rx_mode() calls __dev_set_promiscuity() with "bool notify=false", and thus, the rtmsg_ifinfo() code path won't be entered. The same criteria also hold true for DSA switches which don't report IFF_UNICAST_FLT. When the DSA master uses a spin_lock() in its ndo_get_stats64() method, the same lockdep splat can be seen. I think the deadlock possibility is real, even though I didn't reproduce it, and I'm thinking of the following situation to support that claim: fdb_add_hw_addr() runs on a CPU A, in a context with softirqs locally disabled and br->hash_lock held, and may end up attempting to acquire ocelot->stats_lock. In parallel, ocelot->stats_lock is currently held by a thread B (say, ocelot_check_stats_work()), which is interrupted while holding it by a softirq which attempts to lock br->hash_lock. Thread B cannot make progress because br->hash_lock is held by A. Whereas thread A cannot make progress because ocelot->stats_lock is held by B. When taking the issue at face value, the bridge can avoid that problem by simply making the ports promiscuous from a code path with a saner calling context (br->hash_lock not held). A bridge port without IFF_UNICAST_FLT is going to become promiscuous as soon as we call dev_uc_add() on it (which we do unconditionally), so why not be preemptive and make it promiscuous right from the beginning, so as to not be taken by surprise. With this, we've broken the links between code that holds br->hash_lock or br->lock and code that calls into the ndo_change_rx_flags() or ndo_get_stats64() ops of the bridge port. Fixes: 2796d0c ("bridge: Automatically manage port promiscuous mode.") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )