summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-06-20Merge tag 'imx-dt-6.5' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/dt i.MX ARM device tree for 6.5: - New board support: Marantec Maveo Box. - Add HDMI support for TQMa6x/MBa6 board. - A series from Andrew Lunn to add phy-mode and fixed links for Ethernet devices on imx51, imx6qdl and vf610. - A bunch of changes from Fabio Estevam to clean up deprecated and invalid properies, fix up node names to remove dt-schema warnings. - A series of maintenance updates for Protonic Holland boards, mostly on the USB subsystem configuration, thermal zones, and the naming of GPIO keys. - Update dma-apbh device node name to remove dtbs_check warnings. - Remove invalid nodes from fan-controller for a couple of Gateworks boards. - Small random updates and clean-ups on various boards. * tag 'imx-dt-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (53 commits) ARM: dts: imx6qdl: vicut1: rename power to power-button ARM: dts: imx6dl: prtrvt, prtvt7, prti6q, prtwd2: fix USB related warnings ARM: dts: imx6dl: plybas: fix USB over-current detection on USB OTG port ARM: dts: imx6ul: prti6g: fix USB over-current detection on USB OTG port ARM: dts: imx6qp: prtwd3: Enable USB over current detection on USB OTG port ARM: dts: imx6dl: prtmvt: fix different USB related warnings ARM: dts: imx6dl: alti6p: fix different USB related warnings ARM: dts: imx6dl: vicut1: Address USB related warnings ARM: dts: imx6dl: Add trip points to thermal zones on several devices ARM: dts: imx6dl: lanmcu: Configure over-current polarity for USB OTG node ARM: dts: imx6dl: lanmcu: Disable unused USB PHY nodes ARM: dts: imx6q: prtwd2: Correct iomux configuration for ENET MDIO and MDC ARM: dts: imx6dl: prtvt7: Remove touchscreen inversion ARM: dts: imx6dl: prtvt7: Adjust default backlight brightness to 65 ARM: dts: imx6qdl: vicut1: The sgtl5000 uses i2s not ac97 ARM: dts: imx: Use 'eeprom' as node name ARM: dts: imx6ul-ccimx6ulsom: Fix the "coin" regulator name ARM: dts: imx: Use 'pmic' as node name ARM: dts: imx6: Use the mux- prefix ARM: dts: imx7d-sdb: Allow UHS modes ... Link: https://lore.kernel.org/r/20230610072530.418847-2-shawnguo@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20Merge tag 'imx-bindings-6.5' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/dt i.MX dt-bindings for 6.5: - Add vendor prefix for Emtop - Compatibles for Marantec Maveo Box, i.MX8MM-EVKB and GW7905-2x board. - Replace tab indent with spaces in fsl.yaml. * tag 'imx-bindings-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: dt-bindings: arm: Add Gateworks i.MX8M GW7905-2x board dt-bindings: arm: fsl: Fix syntax error dt-bindings: vendor-prefixes: Add Emtop dt-bindings: arm: fsl: Add Emtop SoM & Baseboard dt-bindings: arm: fsl: Add i.MX8MM-EVKB dt-bindings: arm: fsl: Add Marantec maveo box as a DHCOR i.MX6ULL SoM based board Link: https://lore.kernel.org/r/20230610072530.418847-1-shawnguo@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20Merge tag 'sunxi-dt-for-6.5-1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt - fix DCLK clock names - new board ICnova A20 ADB4006 - add D1 SPI node - add bluetooth node for chip board - add extra mmc2 pinmux to sun5i - add axp209 iio-hwmon node * tag 'sunxi-dt-for-6.5-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: dts: axp209: Add iio-hwmon node for internal temperature ARM: dts: sun5i: Add port E pinmux settings for mmc2 ARM: dts: sun5i: chip: Enable bluetooth riscv: dts: allwinner: d1: Add SPI controllers node arm: dts: sunxi: Add ICnova A20 ADB4006 board dt-bindings: arm: sunxi: add ICnova A20 ADB4006 binding ARM: dts: sunxi: rename tcon's clock output Link: https://lore.kernel.org/r/20230609210452.GA17638@jernej-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20netfilter: ipset: Replace strlcpy with strscpyAzeem Shaikh
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). Direct replacement is safe here since return value from all callers of STRLCPY macro were ignored. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com> Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230613003437.3538694-1-azeemshaikh38@gmail.com
2023-06-20uml: Replace strlcpy with strscpyAzeem Shaikh
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230614003604.1021205-1-azeemshaikh38@gmail.com
2023-06-20Merge tag 'tegra-for-6.5-arm64-dt' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt arm64: tegra: Device tree changes for v6.5-rc1 This introduces support for the IGX Orin and Jetson Orin Nano devices and enables various additional features on the Jetson AGX Orin and Jetson Orin NX. This also enables some basic thermal support to prevent the devices from overheating. Support for the GPU on the Google Pixel C is enabled and various minor issues are fixed and cleaned up. * tag 'tegra-for-6.5-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: arm64: tegra: Enable thermal support on Jetson Orin Nano arm64: tegra: Enable thermal support on Jetson Orin NX arm64: tegra: Enable thermal support on Jetson AGX Orin arm64: tegra: Add Tegra234 thermal support arm64: tegra: Add a few blank lines for better readability arm64: tegra: Sort properties more logically arm64: tegra: Enable GPU on Smaug arm64: tegra: Add GPU power rail regulator on Smaug arm64: tegra: Update USB phy-name for Jetson Orin NX arm64: tegra: Enable USB device for Jetson AGX Orin arm64: tegra: Add Tegra234 pin controllers arm64: tegra: Support Jetson Orin Nano Developer Kit arm64: tegra: Add missing cache properties on Tegra210 arm64: tegra: Fix PCIe regulator for Orin Jetson AGX arm64: tegra: Add CPU OPP tables and interconnects property arm64: tegra: Add support for IGX Orin Link: https://lore.kernel.org/r/20230609193620.2275240-6-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20Merge tag 'tegra-for-6.5-dt-bindings' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt dt-bindings: Changes for v6.5-rc1 Several new modules and devices are documented and fixes incorporated for the Tegra234 GPIO controller pin mappings as well as the possible Tegra XUDC PHY connections. * tag 'tegra-for-6.5-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: dt-bindings: tegra: Document Jetson Orin Nano Developer Kit dt-bindings: tegra: Document Jetson Orin Nano dt-bindings: gpio: Remove FSI domain ports on Tegra234 dt-bindings: usb: tegra-xudc: Remove extraneous PHYs dt-bindings: tegra: Add ICC IDs for dummy memory clients dt-bindings: tegra: Document compatible for IGX Link: https://lore.kernel.org/r/20230609193620.2275240-3-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20Merge tag 'stm32-dt-for-v6.5-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/dt STM32 DT for v6.5, round 1 Highlights: ---------- - MCU/MPU: - Replace deprecated st,hw-flow-ctrl by uart-has-rtscts. - Fix LTDC/DSI warnings. - MPU: - STMP32MP15: - Add OTP part number and Vrefint calibration in bsec. - M4 hold management updated. As SMC call is deprecated, the service is moved on a SCMI service. - Add ADC internal channels (VREFINT/VDDCORE). - ST: - Enable ADC1&2 on STM32MP15 DKx boards. - Adopt generic IIO bindings on STM32MP157C ED1 - Add supplies for OV5640 in STM32MP157C EV1 to fix yaml validation. - Fix i2s bindings to match with the YAML validation (DKx boards). - DH: - Rearrange MAC EEPROM. - Rename AV96 sound card. - Adopt generic IIo bindings. - Fix audio routing. -PHYTEC: - Add PHYTEC STM32MP1-3 Dev board based on STM32MP15 PHYTEC SOM. This SOM embeds up to 1GB DDR3LP RAM, up to 1GB eMMC, up to 16 MB QSPI and up to 128 GB NAND flash. * tag 'stm32-dt-for-v6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (34 commits) ARM: dts: stm32: fix i2s endpoint format property for stm32mp15xx-dkx ARM: dts: stm32: Fix audio routing on STM32MP15xx DHCOM PDK2 ARM: dts: stm32: add required supplies of ov5640 in stm32mp157c-ev1 ARM: dts: stm32: Update to generic ADC channel binding on DHSOM systems ARM: dts: stm32: adopt generic iio bindings for adc channels on dhcor-testbench ARM: dts: stm32: adopt generic iio bindings for adc channels on dhcor-drc ARM: dts: stm32: adopt generic iio bindings for adc channels on emstamp-argon ARM: dts: stm32: adopt generic iio bindings for adc channels on stm32mp157c-ed1 ARM: dts: stm32: enable adc on stm32mp15xx-dkx boards ARM: dts: stm32: add vrefint support to adc2 on stm32mp15 ARM: dts: stm32: add vrefint calibration on stm32mp15 ARM: dts: stm32: add adc internal channels to stm32mp15 ARM: dts: stm32: fix ltdc warnings in stm32mp15 boards ARM: dts: stm32: fix dsi warnings on stm32mp15 boards dt-bindings: display: st,stm32-dsi: Remove unnecessary fields ARM: dts: stm32: fix warnings on stm32f469-disco board ARM: dts: stm32: Shorten the AV96 HDMI sound card name ARM: dts: stm32: fix m4_rproc references to use SCMI for stm32mp15 ARM: dts: stm32: Update Cortex-M4 reset declarations on stm32mp15 ARM: dts: stm32: add STM32MP1-based Phytec board ... Link: https://lore.kernel.org/r/08d711de-bb6d-a976-735b-5e18b19818ea@foss.st.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20regmap: spi-avmm: Fix regmap_bus max_raw_writeRuss Weight
The max_raw_write member of the regmap_spi_avmm_bus structure is defined as: .max_raw_write = SPI_AVMM_VAL_SIZE * MAX_WRITE_CNT SPI_AVMM_VAL_SIZE == 4 and MAX_WRITE_CNT == 1 so this results in a maximum write transfer size of 4 bytes which provides only enough space to transfer the address of the target register. It provides no space for the value to be transferred. This bug became an issue (divide-by-zero in _regmap_raw_write()) after the following was accepted into mainline: commit 3981514180c9 ("regmap: Account for register length when chunking") Change max_raw_write to include space (4 additional bytes) for both the register address and value: .max_raw_write = SPI_AVMM_REG_SIZE + SPI_AVMM_VAL_SIZE * MAX_WRITE_CNT Fixes: 7f9fb67358a2 ("regmap: add Intel SPI Slave to AVMM Bus Bridge support") Reviewed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Link: https://lore.kernel.org/r/20230620202824.380313-1-russell.h.weight@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-20Merge tag 'stm32-mp25-for-v6.5-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/newsoc STM32 STM32MP25 for v6.5, round 1 Highlights: ---------- STM32MP25 family is composed of 4 SoCs defined as following: -STM32MP251: common part composed of 1*Cortex-A35, common peripherals like SDMMC, UART, SPI, I2C, PCIe, USB3, parallel and DSI display, 1*ETH ... -STM32MP253: STM32MP251 + 1*Cortex-A35 (dual CPU), a second ETH, CAN-FD and LVDS display. -STM32MP255: STM32MP253 + GPU/AI and video encode/decode. -STM32MP257: STM32MP255 + ETH TSN switch (2+1 ports). A second diversity layer exists for security features/A35 frequency: -STM32MP25xY, "Y" gives information: -Y = A means A35@1.2GHz + no cryp IP and no secure boot. -Y = C means A35@1.2GHz + cryp IP and secure boot. -Y = D means A35@1.5GHz + no cryp IP and no secure boot. -Y = F means A35@1.5GHz + cryp IP and secure boot. This PR adds the STM32MP257F EV1 board support. This board embeds a STM32MP257FAI SoC, with 4GB of DDR4, TSN switch (2+1 ports), 2*USB typeA, 1*USB2 typeC, SNOR OctoSPI, mini PCIe, STPMIC2 for power distribution ... * tag 'stm32-mp25-for-v6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (44 commits) MAINTAINERS: add entry for ARM/STM32 ARCHITECTURE arm64: defconfig: enable ARCH_STM32 and STM32 serial driver arm64: dts: st: add stm32mp257f-ev1 board support dt-bindings: stm32: document stm32mp257f-ev1 board arm64: dts: st: introduce stm32mp25 pinctrl files arm64: dts: st: introduce stm32mp25 SoCs family arm64: introduce STM32 family on Armv8 architecture dt-bindings: stm32: add st,stm32mp25-syscfg compatible for syscon pinctrl: stm32: add stm32mp257 pinctrl support dt-bindings: pinctrl: stm32: support for stm32mp257 and additional packages ARM: dts: stm32: fix i2s endpoint format property for stm32mp15xx-dkx ARM: dts: stm32: Fix audio routing on STM32MP15xx DHCOM PDK2 ARM: dts: stm32: add required supplies of ov5640 in stm32mp157c-ev1 ARM: dts: stm32: Update to generic ADC channel binding on DHSOM systems ARM: dts: stm32: adopt generic iio bindings for adc channels on dhcor-testbench ARM: dts: stm32: adopt generic iio bindings for adc channels on dhcor-drc ARM: dts: stm32: adopt generic iio bindings for adc channels on emstamp-argon ARM: dts: stm32: adopt generic iio bindings for adc channels on stm32mp157c-ed1 ARM: dts: stm32: enable adc on stm32mp15xx-dkx boards ARM: dts: stm32: add vrefint support to adc2 on stm32mp15 ... Link: https://lore.kernel.org/r/080fc303-45c1-6cc0-4c5e-694e730896a6@foss.st.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-06-20block: add overflow checks for Amiga partition supportMichael Schmitz
The Amiga partition parser module uses signed int for partition sector address and count, which will overflow for disks larger than 1 TB. Use u64 as type for sector address and size to allow using disks up to 2 TB without LBD support, and disks larger than 2 TB with LBD. The RBD format allows to specify disk sizes up to 2^128 bytes (though native OS limitations reduce this somewhat, to max 2^68 bytes), so check for u64 overflow carefully to protect against overflowing sector_t. Bail out if sector addresses overflow 32 bits on kernels without LBD support. This bug was reported originally in 2012, and the fix was created by the RDB author, Joanne Dow <jdow@earthlink.net>. A patch had been discussed and reviewed on linux-m68k at that time but never officially submitted (now resubmitted as patch 1 in this series). This patch adds additional error checking and warning messages. Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=43511 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Message-ID: <201206192146.09327.Martin@lichtvoll.de> Cc: <stable@vger.kernel.org> # 5.2 Signed-off-by: Michael Schmitz <schmitzmic@gmail.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Christoph Hellwig <hch@infradead.org> Link: https://lore.kernel.org/r/20230620201725.7020-4-schmitzmic@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20block: change all __u32 annotations to __be32 in affs_hardblocks.hMichael Schmitz
The Amiga partition parser module uses signed int for partition sector address and count, which will overflow for disks larger than 1 TB. Use u64 as type for sector address and size to allow using disks up to 2 TB without LBD support, and disks larger than 2 TB with LBD. The RBD format allows to specify disk sizes up to 2^128 bytes (though native OS limitations reduce this somewhat, to max 2^68 bytes), so check for u64 overflow carefully to protect against overflowing sector_t. This bug was reported originally in 2012, and the fix was created by the RDB author, Joanne Dow <jdow@earthlink.net>. A patch had been discussed and reviewed on linux-m68k at that time but never officially submitted (now resubmitted as patch 1 of this series). Patch 3 (this series) adds additional error checking and warning messages. One of the error checks now makes use of the previously unused rdb_CylBlocks field, which causes a 'sparse' warning (cast to restricted __be32). Annotate all 32 bit fields in affs_hardblocks.h as __be32, as the on-disk format of RDB and partition blocks is always big endian. Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=43511 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Message-ID: <201206192146.09327.Martin@lichtvoll.de> Cc: <stable@vger.kernel.org> # 5.2 Signed-off-by: Michael Schmitz <schmitzmic@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20230620201725.7020-3-schmitzmic@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20block: fix signed int overflow in Amiga partition supportMichael Schmitz
The Amiga partition parser module uses signed int for partition sector address and count, which will overflow for disks larger than 1 TB. Use sector_t as type for sector address and size to allow using disks up to 2 TB without LBD support, and disks larger than 2 TB with LBD. This bug was reported originally in 2012, and the fix was created by the RDB author, Joanne Dow <jdow@earthlink.net>. A patch had been discussed and reviewed on linux-m68k at that time but never officially submitted. This patch differs from Joanne's patch only in its use of sector_t instead of unsigned int. No checking for overflows is done (see patch 3 of this series for that). Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=43511 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Message-ID: <201206192146.09327.Martin@lichtvoll.de> Cc: <stable@vger.kernel.org> # 5.2 Signed-off-by: Michael Schmitz <schmitzmic@gmail.com> Tested-by: Martin Steigerwald <Martin@lichtvoll.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620201725.7020-2-schmitzmic@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2Jeff Layton
I've been experiencing some intermittent crashes down in the display driver code. The symptoms are ususally a line like this in dmesg: amdgpu 0000:30:00.0: [drm] Failed to create MST payload for port 000000006d3a3885: -5 ...followed by an Oops due to a NULL pointer dereference. Switch to using mgr->dev instead of state->dev since "state" can be NULL in some cases. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855 Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230419112447.18471-1-jlayton@kernel.org
2023-06-20fs: jfs: (trivial) Fix typo in dbInitTree functionWonguk Lee
While trying to fix the jfs UBSAN problem reported in syzkaller, (https://syzkaller.appspot.com/bug?id=01abadbd6ae6a08b1f1987aa61554c6b3ac19ff2) I found the typo in the comment of dbInitTree function and fix it. Signed-off-by: Wonguk Lee <wonguk.lee1023@gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
2023-06-20clk: fix typo in clk_hw_register_fixed_rate_parent_data() macroClaudiu Beznea
clk_hw_register_fixed_rate_parent_data() 3rd parameter is parent_data not parent_hw. Inner function (__clk_hw_register_fixed_rate()) is called with parent_data parameter as valid. To have this parameter taken into account update the name of the 3rd parameter of clk_hw_register_fixed_rate_parent_data() macro to parent_data. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230615101931.581060-1-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-20wifi: iwlwifi: pcie: Handle SO-F device for PCI id 0x7AF0Mukesh Sisodiya
Add support for AX1690i and AX1690s devices with PCIE id 0x7AF0. Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20230619150233.461290-2-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-20be2net: Extend xmit workaround to BE3 chipRoss Lagerwall
We have seen a bug where the NIC incorrectly changes the length in the IP header of a padded packet to include the padding bytes. The driver already has a workaround for this so do the workaround for this NIC too. This resolves the issue. The NIC in question identifies itself as follows: [ 8.828494] be2net 0000:02:00.0: FW version is 10.7.110.31 [ 8.834759] be2net 0000:02:00.0: Emulex OneConnect(be3): PF FLEX10 port 1 02:00.0 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01) Fixes: ca34fe38f06d ("be2net: fix wrong usage of adapter->generation") Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Link: https://lore.kernel.org/r/20230616164549.2863037-1-ross.lagerwall@citrix.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-20net: fec: allow to build without PAGE_POOL_STATSLucas Stach
Commit 6970ef27ff7f ("net: fec: add xdp and page pool statistics") selected CONFIG_PAGE_POOL_STATS from the FEC driver symbol, making it impossible to build without the page pool statistics when this driver is enabled. The help text of those statistics mentions increased overhead. Allow the user to choose between usefulness of the statistics and the added overhead. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230616191832.2944130-1-l.stach@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-20crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE)David Howells
If an AF_ALG socket bound to a hashing algorithm is sent a zero-length message with MSG_MORE set and then recvmsg() is called without first sending another message without MSG_MORE set to end the operation, an oops will occur because the crypto context and result doesn't now get set up in advance because hash_sendmsg() now defers that as long as possible in the hope that it can use crypto_ahash_digest() - and then because the message is zero-length, it the data wrangling loop is skipped. Fix this by handling zero-length sends at the top of the hash_sendmsg() function. If we're not continuing the previous sendmsg(), then just ignore the send (hash_recvmsg() will invent something when called); if we are continuing, then we finalise the request at this point if MSG_MORE is not set to get any error here, otherwise the send is of no effect and can be ignored. Whilst we're at it, remove the code to create a kvmalloc'd scatterlist if we get more than ALG_MAX_PAGES - this shouldn't happen. Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") Reported-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000b928f705fdeb873a@google.com/ Reported-by: syzbot+14234ccf6d0ef629ec1a@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000c047db05fdeb8790@google.com/ Reported-by: syzbot+4e2e47f32607d0f72d43@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000bcca3205fdeb87fb@google.com/ Reported-by: syzbot+472626bb5e7c59fb768f@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000b55d8805fdeb8385@google.com/ Signed-off-by: David Howells <dhowells@redhat.com> Reported-and-tested-by: syzbot+6efc50cc1f8d718d6cb7@syzkaller.appspotmail.com cc: Jens Axboe <axboe@kernel.dk> cc: Matthew Wilcox <willy@infradead.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://lore.kernel.org/r/427646.1686913832@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-20clk: Fix memory leak in devm_clk_notifier_register()Fei Shao
devm_clk_notifier_register() allocates a devres resource for clk notifier but didn't register that to the device, so the notifier didn't get unregistered on device detach and the allocated resource was leaked. Fix the issue by registering the resource through devres_add(). This issue was found with kmemleak on a Chromebook. Fixes: 6d30d50d037d ("clk: add devm variant of clk_notifier_register") Signed-off-by: Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20230619112253.v2.1.I13f060c10549ef181603e921291bdea95f83033c@changeid Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-20net: phy: mediatek: fix compile-test dependenciesArnd Bergmann
The new phy driver attempts to select a driver from another subsystem, but that fails when the NVMEM subsystem is disabled: WARNING: unmet direct dependencies detected for NVMEM_MTK_EFUSE Depends on [n]: NVMEM [=n] && (ARCH_MEDIATEK [=n] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] Selected by [y]: - MEDIATEK_GE_SOC_PHY [=y] && NETDEVICES [=y] && PHYLIB [=y] && (ARM64 && ARCH_MEDIATEK [=n] || COMPILE_TEST [=y]) I could not see an actual compile time dependency, so presumably this is only needed for for working correctly but not technically a dependency on that particular nvmem driver implementation, so it would likely be safe to remove the select for compile testing. To keep the spirit of the original 'select', just replace this with a 'depends on' that ensures that the driver will work but does not get in the way of build testing. Fixes: 98c485eaf509b ("net: phy: add driver for MediaTek SoC built-in GE PHYs") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20230616093009.3511692-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-20clk: mvebu: Iterate over possible CPUs instead of DT CPU nodesRob Herring
Rework iterating over DT CPU nodes to iterate over possible CPUs instead. There's no need to walk the DT CPU nodes again. Possible CPUs is equal to the number of CPUs defined in the DT. Using the "reg" value for an array index is fragile as it assumes "reg" is 0-N which often is not the case. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230327-mvebu-clk-fixes-v2-3-8333729ee45d@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-20clk: mvebu: Use of_get_cpu_hwid() to read CPU IDRob Herring
Use of_get_cpu_hwid() rather than the open coded reading of the CPU nodes "reg" property. The existing code is in fact wrong as the "reg" address cells size is 2 cells for arm64. The existing code happens to work because the DTS files are wrong as well. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230327-mvebu-clk-fixes-v2-2-8333729ee45d@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-20MAINTAINERS: Add Marvell mvebu clock driversRob Herring
drivers/clk/mvebu/ is missing a maintainers entry. Add it to the existing entry for the Marvell mvebu platforms. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230327-mvebu-clk-fixes-v2-1-8333729ee45d@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-20block: add capacity validation in bdev_add_partition()Min Li
In the function bdev_add_partition(),there is no check that the start and end sectors exceed the size of the disk before calling add_partition. When we call the block's ioctl interface directly to add a partition, and the capacity of the disk is set to 0 by driver,the command will continue to execute. Signed-off-by: Min Li <min15.li@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20230619091214.31615-1-min15.li@samsung.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20Merge tag '6.4-rc6-smb3-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull smb server fixes from Steve French: "Four smb3 server fixes, all also for stable: - fix potential oops in parsing compounded requests - fix various paths (mkdir, create etc) where mnt_want_write was not checked first - fix slab out of bounds in check_message and write" * tag '6.4-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd: ksmbd: validate session id and tree id in the compound request ksmbd: fix out-of-bound read in smb2_write ksmbd: add mnt_want_write to ksmbd vfs functions ksmbd: validate command payload size
2023-06-20block: fine-granular CAP_SYS_ADMIN for Persistent ReservationJingbo Xu
Allow of unprivileged Persistent Reservation operations on devices if the write permission check on the device node has passed. brw-rw---- 1 root disk 259, 0 Jun 13 07:09 /dev/nvme0n1 In the example above, the "disk" group of nvme0n1 is also allowed to make reservations on the device even without CAP_SYS_ADMIN. Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230613084008.93795-3-jefflexu@linux.alibaba.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20block: disallow Persistent Reservation on partitionsJingbo Xu
Refuse Persistent Reservation operations on partitions as reservation on partitions doesn't make sense. Besides, introduce blkdev_pr_allowed() helper, where more policies could be placed here later. Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230613084008.93795-2-jefflexu@linux.alibaba.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20s390/cpum_cf: open access to hwctr device for CAP_PERFMON privileged processThomas Richter
The device /dev/hwctr was introduced to access complete CPU Measurement facility counter sets via an ioctl system call. The access the to device is limited to privileged processes running as root or superuser. The capability CAP_SYS_ADMIN is required. The device permissions are read/write for the device owner root. There is no need for this restriction. Make the device access permission read/write for all and reduce the capabilities to CAP_PERFMON. Any user space program with the CAP_PERFMON capability assigned to it can now read and display the CPU Measurement facility counter sets. For more details on perf tool usage and security, see linux documentation in Documentation/admin-guide/perf-security.rst. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-06-20s390/module: fix rela calculation for R_390_GOTENTSumanth Korikkar
During module load, module layout allocation occurs by initially allowing the architecture to frob the sections. This is performed via module_frob_arch_sections(). However, the size of each module memory types like text,data,rodata etc are updated correctly only after layout_sections(). After calculation of required module memory sizes for each types, move_module() is responsible for allocating the module memory for each type from modules vaddr range. Considering the sequence above, module_frob_arch_sections() updates the module mod_arch_specific got_offset before module memory text type size is fully updated in layout_sections(). Hence mod_arch_specific got_offset points to currently zero. As per s390 ABI, R_390_GOTENT : (G + O + A - P) >> 1 where G=me->mem[MOD_TEXT].base+me->arch.got_offset O=info->got_offset A=rela->r_addend P=loc fix R_390_GOTENT calculation in apply_rela(). Note: currently this doesn't break anything because me->arch.got_offset is zero. However, reordering of functions in the future could break it. Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-06-20s390/boot: fix physmem_info virtual vs physical address confusionAlexander Gordeev
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-06-20s390/kasan: avoid short by one page shadow memoryAlexander Gordeev
Kernel Address Sanitizer uses 3 bits per byte to encode memory. That is the number of bits the start and end address of a memory range is shifted right when the corresponding shadow memory is created for that memory range. The used memory mapping routine expects page-aligned addresses, while the above described 3-bit shift might turn the shadow memory range start and end boundaries into non-page-aligned in case the size of the original memory range is less than (PAGE_SIZE << 3). As result, the resulting shadow memory range could be short on one page. Align on page boundary the start and end addresses when mapping a shadow memory range and avoid the described issue in the future. Note, that does not fix a real problem, since currently no virtual regions of size less than (PAGE_SIZE << 3) exist. Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-06-20s390/kasan: fix insecure W+X mapping warningAlexander Gordeev
Since commit 3b5c3f000c2e ("s390/kasan: move shadow mapping to decompressor") the decompressor establishes mappings for the shadow memory and sets initial protection attributes to RWX. The decompressed kernel resets protection to RW+NX later on. In case a shadow memory range is not aligned on page boundary (e.g. as result of mem= kernel command line parameter use), the "Checked W+X mappings: FAILED, 1 W+X pages found" warning hits. Reported-by: Vasily Gorbik <gor@linux.ibm.com> Fixes: 557b19709da9 ("s390/kasan: move shadow mapping to decompressor") Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-06-20s390/crash: use the correct type for memory allocationChristophe JAILLET
get_elfcorehdr_size() returns a size_t, so there is no real point to store it in a u32. Turn 'alloc_size' into a size_t. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/0756118c9058338f3040edb91971d0bfd100027b.1686688212.git.christophe.jaillet@wanadoo.fr Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-06-20jfs: jfs_dmap: Validate db_l2nbperpage while mountingSiddh Raman Pant
In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block number inside dbFree(). db_l2nbperpage, which is the log2 number of blocks per page, is passed as an argument to BLKTODMAP which uses it for shifting. Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is too big. This happens because the large value is set without any validation in dbMount() at line 181. Thus, make sure that db_l2nbperpage is correct while mounting. Max number of blocks per page = Page size / Min block size => log2(Max num_block per page) = log2(Page size / Min block size) = log2(Page size) - log2(Min block size) => Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE Reported-and-tested-by: syzbot+d2cd27dcf8e04b232eb2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=2a70a453331db32ed491f5cbb07e81bf2d225715 Cc: stable@vger.kernel.org Suggested-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Siddh Raman Pant <code@siddh.me> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
2023-06-20btrfs: fix u32 overflows when left shifting stripe_nrQu Wenruo
[BUG] David reported an ASSERT() get triggered during fio load on 8 devices with data/raid6 and metadata/raid1c3: fio --rw=randrw --randrepeat=1 --size=3000m \ --bsrange=512b-64k --bs_unaligned \ --ioengine=libaio --fsync=1024 \ --name=job0 --name=job1 \ The ASSERT() is from rbio_add_bio() of raid56.c: ASSERT(orig_logical >= full_stripe_start && orig_logical + orig_len <= full_stripe_start + rbio->nr_data * BTRFS_STRIPE_LEN); Which is checking if the target rbio is crossing the full stripe boundary. [100.789] assertion failed: orig_logical >= full_stripe_start && orig_logical + orig_len <= full_stripe_start + rbio->nr_data * BTRFS_STRIPE_LEN, in fs/btrfs/raid56.c:1622 [100.795] ------------[ cut here ]------------ [100.796] kernel BUG at fs/btrfs/raid56.c:1622! [100.797] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [100.798] CPU: 1 PID: 100 Comm: kworker/u8:4 Not tainted 6.4.0-rc6-default+ #124 [100.799] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014 [100.802] Workqueue: writeback wb_workfn (flush-btrfs-1) [100.803] RIP: 0010:rbio_add_bio+0x204/0x210 [btrfs] [100.806] RSP: 0018:ffff888104a8f300 EFLAGS: 00010246 [100.808] RAX: 00000000000000a1 RBX: ffff8881075907e0 RCX: ffffed1020951e01 [100.809] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000001 [100.811] RBP: 0000000141d20000 R08: 0000000000000001 R09: ffff888104a8f04f [100.813] R10: ffffed1020951e09 R11: 0000000000000003 R12: ffff88810e87f400 [100.815] R13: 0000000041d20000 R14: 0000000144529000 R15: ffff888101524000 [100.817] FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 [100.821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [100.822] CR2: 000055d54e44c270 CR3: 000000010a9a1006 CR4: 00000000003706a0 [100.824] Call Trace: [100.825] <TASK> [100.825] ? die+0x32/0x80 [100.826] ? do_trap+0x12d/0x160 [100.827] ? rbio_add_bio+0x204/0x210 [btrfs] [100.827] ? rbio_add_bio+0x204/0x210 [btrfs] [100.829] ? do_error_trap+0x90/0x130 [100.830] ? rbio_add_bio+0x204/0x210 [btrfs] [100.831] ? handle_invalid_op+0x2c/0x30 [100.833] ? rbio_add_bio+0x204/0x210 [btrfs] [100.835] ? exc_invalid_op+0x29/0x40 [100.836] ? asm_exc_invalid_op+0x16/0x20 [100.837] ? rbio_add_bio+0x204/0x210 [btrfs] [100.837] raid56_parity_write+0x64/0x270 [btrfs] [100.838] btrfs_submit_chunk+0x26e/0x800 [btrfs] [100.840] ? btrfs_bio_init+0x80/0x80 [btrfs] [100.841] ? release_pages+0x503/0x6d0 [100.842] ? folio_unlock+0x2f/0x60 [100.844] ? __folio_put+0x60/0x60 [100.845] ? btrfs_do_readpage+0xae0/0xae0 [btrfs] [100.847] btrfs_submit_bio+0x21/0x60 [btrfs] [100.847] submit_one_bio+0x6a/0xb0 [btrfs] [100.849] extent_write_cache_pages+0x395/0x680 [btrfs] [100.850] ? __extent_writepage+0x520/0x520 [btrfs] [100.851] ? mark_usage+0x190/0x190 [100.852] extent_writepages+0xdb/0x130 [btrfs] [100.853] ? extent_write_locked_range+0x480/0x480 [btrfs] [100.854] ? mark_usage+0x190/0x190 [100.854] ? attach_extent_buffer_page+0x220/0x220 [btrfs] [100.855] ? reacquire_held_locks+0x178/0x280 [100.856] ? writeback_sb_inodes+0x245/0x7f0 [100.857] do_writepages+0x102/0x2e0 [100.858] ? page_writeback_cpu_online+0x10/0x10 [100.859] ? __lock_release.isra.0+0x14a/0x4d0 [100.860] ? reacquire_held_locks+0x280/0x280 [100.861] ? __lock_acquired+0x1e9/0x3d0 [100.862] ? do_raw_spin_lock+0x1b0/0x1b0 [100.863] __writeback_single_inode+0x94/0x450 [100.864] writeback_sb_inodes+0x372/0x7f0 [100.864] ? lock_sync+0xd0/0xd0 [100.865] ? do_raw_spin_unlock+0x93/0xf0 [100.866] ? sync_inode_metadata+0xc0/0xc0 [100.867] ? rwsem_optimistic_spin+0x340/0x340 [100.868] __writeback_inodes_wb+0x70/0x130 [100.869] wb_writeback+0x2d1/0x530 [100.869] ? __writeback_inodes_wb+0x130/0x130 [100.870] ? lockdep_hardirqs_on_prepare.part.0+0xf1/0x1c0 [100.870] wb_do_writeback+0x3eb/0x480 [100.871] ? wb_writeback+0x530/0x530 [100.871] ? mark_lock_irq+0xcd0/0xcd0 [100.872] wb_workfn+0xe0/0x3f0< [CAUSE] Commit a97699d1d610 ("btrfs: replace map_lookup->stripe_len by BTRFS_STRIPE_LEN") changes how we calculate the map length, to reduce u64 division. Function btrfs_max_io_len() is to get the length to the stripe boundary. It calculates the full stripe start offset (inside the chunk) by the following code: *full_stripe_start = rounddown(*stripe_nr, nr_data_stripes(map)) << BTRFS_STRIPE_LEN_SHIFT; The calculation itself is fine, but the value returned by rounddown() is dependent on both @stripe_nr (which is u32) and nr_data_stripes() (which returned int). Thus the result is also u32, then we do the left shift, which can overflow u32. If such overflow happens, @full_stripe_start will be a value way smaller than @offset, causing later "full_stripe_len - (offset - *full_stripe_start)" to underflow, thus make later length calculation to have no stripe boundary limit, resulting a write bio to exceed stripe boundary. There are some other locations like this, with a u32 @stripe_nr got left shift, which can lead to a similar overflow. [FIX] Fix all @stripe_nr with left shift with a type cast to u64 before the left shift. Those involved @stripe_nr or similar variables are recording the stripe number inside the chunk, which is small enough to be contained by u32, but their offset inside the chunk can not fit into u32. Thus for those specific left shifts, a type cast to u64 is necessary so this patch does not touch them and the code will be cleaned up in the future to keep the fix minimal. Reported-by: David Sterba <dsterba@suse.com> Fixes: a97699d1d610 ("btrfs: replace map_lookup->stripe_len by BTRFS_STRIPE_LEN") Tested-by: David Sterba <dsterba@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2023-06-20io_uring: add helpers to decode the fixed file file_ptrChristoph Hellwig
Remove all the open coded magic on slot->file_ptr by introducing two helpers that return the file pointer and the flags instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-9-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: use io_file_from_index in io_msg_grab_fileChristoph Hellwig
Use io_file_from_index instead of open coding it. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-8-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: use io_file_from_index in __io_sync_cancelChristoph Hellwig
Use io_file_from_index instead of open coding it. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-7-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: return REQ_F_ flags from io_file_get_flagsChristoph Hellwig
Two of the three callers want them, so return the more usual format, and shift into the FFS_ form only for the fixed file table. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-6-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: remove io_req_ffs_setChristoph Hellwig
Just checking the flag directly makes it a lot more obvious what is going on here. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-5-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: remove a confusing comment above io_file_get_flagsChristoph Hellwig
The SCM inflight mechanism has nothing to do with the fact that a file might be a regular file or not and if it supports non-blocking operations. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: remove the mode variable in io_file_get_flagsChristoph Hellwig
The variable is only once now, so don't bother with it. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20io_uring: remove __io_file_supports_nowaitChristoph Hellwig
Now that this only checks O_NONBLOCK and FMODE_NOWAIT, the helper is complete overkilļ, and the comments are confusing bordering to wrong. Just inline the check into the caller. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620113235.920399-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20of: reserved_mem: Use stable allocation orderStephan Gerhold
sort() in Linux is based on heapsort which is not a stable sort algorithm - equal elements are being reordered. For reserved memory in the device tree this happens mainly for dynamic allocations: They do not have an address to sort with, so they are reordered somewhat randomly when adding/removing other unrelated reserved memory nodes. Functionally this is not a big problem, but it's confusing during development when all the addresses change after adding unrelated reserved memory nodes. Make the order stable by sorting dynamic allocations according to the node order in the device tree. Static allocations are not affected by this because they are still sorted by their (fixed) address. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230510-dt-resv-bottom-up-v2-2-aeb2afc8ac25@gerhold.net Signed-off-by: Rob Herring <robh@kernel.org>
2023-06-20of: reserved_mem: Try to keep range allocations contiguousStephan Gerhold
Right now dynamic reserved memory regions are allocated either bottom-up or top-down, depending on the memblock setting of the architecture. This is fine when the address is arbitrary. However, when using "alloc-ranges" the regions are often placed somewhere in the middle of (free) RAM, even if the range starts or ends next to another (static) reservation. Try to detect this situation, and choose explicitly between bottom-up or top-down to allocate the memory close to the other reservations: 1. If the "alloc-range" starts at the end or inside an existing reservation, use bottom-up. 2. If the "alloc-range" ends at the start or inside an existing reservation, use top-down. 3. If both or none is the case, keep the current (architecture-specific) behavior. There are plenty of edge cases where only a more complex algorithm would help, but even this simple approach helps in many cases to keep the reserved memory (and therefore also the free memory) contiguous. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230510-dt-resv-bottom-up-v2-1-aeb2afc8ac25@gerhold.net Signed-off-by: Rob Herring <robh@kernel.org>
2023-06-20ovl: add Amir as co-maintainerMiklos Szeredi
Amir has implemented lots of features in overlayfs and is very active in maintenance. Make this official in the MAINTAINERS file. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
2023-06-20ovl: reserve ability to reconfigure mount options with new mount apiChristian Brauner
Using the old mount api to remount an overlayfs superblock via mount(MS_REMOUNT) all mount options will be silently ignored. For example, if you create an overlayfs mount: mount -t overlay overlay -o lowerdir=/mnt/a:/mnt/b,upperdir=/mnt/upper,workdir=/mnt/work /mnt/merged and then issue a remount via: # force mount(8) to use mount(2) export LIBMOUNT_FORCE_MOUNT2=always mount -t overlay overlay -o remount,WOOTWOOT,lowerdir=/DOESNT-EXIST /mnt/merged with completely nonsensical mount options whatsoever it will succeed nonetheless. This prevents us from every changing any mount options we might introduce in the future that could reasonably be changed during a remount. We don't need to carry this issue into the new mount api port. Similar to FUSE we can use the fs_context::oldapi member to figure out that this is a request coming through the legacy mount api. If we detect it we continue silently ignoring all mount options. But for the new mount api we simply report that mount options cannot currently be changed. This will allow us to potentially alter mount properties for new or even old properties. It any case, silently ignoring everything is not something new apis should do. Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
2023-06-20dt-bindings: arm: drop unneeded quotes and use absolute /schemas pathKrzysztof Kozlowski
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Also absolute path starting with /schemas is preferred. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230609140754.65158-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>