The LS1028ARDB board contains three EEPROM devices, for
storing boot code, DDR SPD and board information. Add the
missing entries to the devicetree.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
SODIMM 17 can be used as an edge triggered interrupt supplied from an
off board source.
Enable hysteresis on the pinmuxing to increase immunity against noise
on the signal.
Fixes: 60f01b5b5c ("arm64: dts: imx8mm-verdin: update iomux configuration")
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Similarly to other Lenovo laptops these also have a dual speaker
setup with a shared amplifier.
The model also seems to have a conflicting PCI SSID with the codec SSID for
the Legion Y9000X 2022 IAH7. Only tested on the Yoga Pro 7, as I don't have
access to the other laptop.
Signed-off-by: Gergely Meszaros <meszaros.gergely97@gmail.com>
Link: https://lore.kernel.org/r/20240616085233.16922-1-meszaros.gergely97@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
specifically ensuring that I2C_FUNC_SLAVE is reported when a
device operates solely as a slave interface.
-----BEGIN PGP SIGNATURE-----
iIwEABYIADQWIQScDfrjQa34uOld1VLaeAVmJtMtbgUCZmwimhYcYW5kaS5zaHl0
aUBrZXJuZWwub3JnAAoJENp4BWYm0y1uOLEA/AuwGjBQT+R3rtW4Rm2TEvbORBTJ
7J0946wYpYrMi8zcAP0e/f1Or4ih6BXKUK2zztHa5duPfCyaajBvA+ynbyMKDw==
=sDff
-----END PGP SIGNATURE-----
Merge tag 'i2c-host-fixes-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-current
Two fixes from Jean aim to correctly report i2c functionality,
specifically ensuring that I2C_FUNC_SLAVE is reported when a
device operates solely as a slave interface.
Lots of new device support and 3 entirely new drivers.
Early pull request this cycle to allow for clean picking up of fixes
that are dependencies for some queued patch sets.
Device support
==============
adi,ad3552r
- Add AD3541R and AD3551R - single output variants of already supported
DACs.
adi,ad7192
- Add support for ad7194 24-bit ADC with integrated PGA.
adi,ad7380
- New ADC driver built up in a number of steps. Supports
- 2 channel differential ADCs: AD7380, AD7381
- 4 channel differential ADCs: AD7380-4, AD7381-4
- 2 channel pseudo-differential ADCs: AD7383, AD7384
- 4 channel pseudo-differential ADCs: AD7383-4, AD7384-4
adi,adis16475
- Support ADS16501 variant - ID and some different scale factors from
parts already supported.
- Driver refactoring then enables support for 6 more IMUs:
- ADIS16575-[2,3]
- ADIS16576-[2,3]
- ADIS16577-[2,3]
adi,adsi16480
- Driver refactoring and feature additions leading to support for 6 more
IMUs - with new delta angle and delta velocity feature:
- ADIS16545-[1,2,3]
- ADIS16547-[1,2,3]
bosch,bmi160
- Support for the bmi120 IMU: ID only. Also relax ID checking to warn
only on mismatch allowing use of fallback compatibles for new devices.
sciosense,ens160
- New driver for this metal oxide multi-gas sensor for indoor
air quality monitoring.
sensortek,stk3110
- Support for stk3311a and stk3311s34 light sensor variants. Relax ID
checking to warn only on a mismatch allowing use of fallback compatibles
for new devices.
vishay,veml6040
- New driver for this RGBW light sensor. Note that whilst the register
interface is very different, the dt-binding similar enough that it is
shared with the existing vishay,veml6075 binding
x-powers,axp20x
- Add support for axp192, very similar to another supported PMIC ADC variant
but with a few more GPIO channels.
Dt-binding only
===============
ti,ads1015
- Add binding (no driver support yet) for ti,tla2021
New features
============
core
- Variable scan type support. We have papered over this for a long time
so good to finally resolve it.
Some devices will change their data output format (typically resolution)
dependent on settings such as oversampling. A new callback is added
to enable this. First used in the ad7380 driver.
- Harden the core against missing callback functions.
dt-binding:
- Add a single-channel property that can be used in per channel nodes
instead of reg to indicate which device channel. This is important
in devices with a mixture of differential and single ended channels
as reg already just acted as an index for the differential channels
making things inconsistent if it had more meaning for single ended
channels.
adi,ad7380
- Use spi_optimize_message() to reduce reading message setup overhead.
- Add oversampling support using the new core functionality to allow
a device support multiple scan types.
invense,icm42600
- Support for low-power accelerometer modes. When a given sampling
frequency is only supported at one power mode, use that. Otherwise
default to low power at the cost of some noise unless overridden
via a new sysfs attribute.
silicon-labs,si70720
- Add control of the heater.
Cleanups and minor fixes
========================
core
- Cleanup use of sizeof(struct xxxx) in favor of sizeof(*variable)
Makefile
- Resort the iio/adc/Makefile which has drifted away from alphabetical
order.
gts library
- Fix sorting of lists with a zero in the middle. Doesn't happen with
upstream drivers, but good to harden this code. Add a related unit test.
multiple drivers
- Add missing MODULE_DESCRIPTION()
- Drop some unused structure fields.
- Drop some entirely unused structure definitions.
- Stop pointless initialization of i2c_device_id::driver_data to 0 in drivers
where it isn't used.
- Use spi_get_device_match_data() to replace open-coded equivalent.
adi,ad3552r
- Fix dt gain parameter names to reflect what the driver does. Note
discussion in patch to justify fixing it in the binding not the
driver.
- Tidy up some naming.
adi,ad7192
- Use read_avail() callback to handle the low pass filter.
- Add an aincom supply for pseudo differential operation.
adi,ad7606
- Use iio_device_claim_direct_scoped() to simplify error paths.
adi,ad7944
- Drop an unused function parameter.
adi,adrf6780
- Drop unused header.
adi,ad9467
- Use a DMA safe buffer for SPI transfers.
- Stop using tabs to pad structure field names. It was creating a lot
of noise.
adi,axi-adc
- Prevent races between enable and disable calls.
- Ensure the DRP (dynamic reconfiguration port) is locked. Not used
in most real designs, but better safe than sorry.
- Limit build to COMPILE_TEST or platforms for which the IP exists.
adi,axi-dac
- Limit build to COMPILE_TEST or platforms for which the IP exists.
ams,iaq
- Use __packed instead of ___attribute__((__packed__))
bosch,bmp280
- White space cleanup.
- Use BME280 prefix for registers that do not exist on the BMP280.
- Add parameter names to callback function definitions.
- Rename measure function to better reflect what it does which is wait
for a measurement to happen.
- Drop a redundant error check.
- Improve error messages
- Make error checks consistent as if (ret)
- Use unsigned types for inherently unsigned data.
- Refactor reading functions to not rely on a hidden t_fine variable.
- Make use of cleanup.h
freescale,mma7660
- Add mount matrix support.
invense,icm42600
- Enable the regmap cache to reduce bus accesses.
amlogic,meson-saradc
- Add dt-binding support for power-domains.
ti,adc161s626
- Use iio_device_claim_direct_scoped() to simplify error handling.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmZtancRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FojwxRAAoRXl9zfoB4KWHaxVvh3t6JWY5Yt+oJzp
Ian4kBPYEj5xWWkeIpYphrZh3eBWdzmE1ATH0C5qS3w4oYzp9qdk6JWD2npS/76u
1s5iHsF36H1/LetE79m3ky9DDIEY0IfxP1VyQzRm+YghzA36GtsNdXbXTn8l7Nuz
6tFbhUoEdUXxVNLEzi/32rlce9sw2/FVak9A/d2AQp50gY7kGm4m+GUsfPLFTZ0M
5Y66HFdH859I2UHqbw/2Pp2xqqPLdxGscwnII02FAD7OvW5d5X9VVrurL56zAdeU
U/022Dh8df4FRs0S9ldB/LX3n6uqejYfpirQt7iRgXEevlR6lOI0bsk1kcNOxOWE
kl4u+kTr3dgx7MdaIYV1hvCCDlpbHRzSpMW/K5Q/3EytApvduNROHFhxBhh0j+18
4z7F48HDidKEvv4U7808OrFtGHIia0MTdeliDz7gPqOBUi2DYsSCnh/Y20/RhIDT
TU6YvWpFjt1GQtc9EOta58PkCwXDfbGHqqD6T/eE42gv19RgM7752vWY8lcWUZL1
cZI0NTXrrKVh6RDufW8nPYeAmGKtHvNFk0wLzT4ZVpz6qoT9x3wQW7GileEXvePr
x+lcuQGUmN7SSDqS3f9Krb0m75gI0P6dBT1yhzR6osm0yn6mKq7/25wHSNBsl1wp
WYVIF2Chm/0=
=HYU0
-----END PGP SIGNATURE-----
Merge tag 'iio-for-6.11a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-testing
Jonathan writes:
IIO: 1st set of new device support, cleanups etc for 6.11
Lots of new device support and 3 entirely new drivers.
Early pull request this cycle to allow for clean picking up of fixes
that are dependencies for some queued patch sets.
Device support
==============
adi,ad3552r
- Add AD3541R and AD3551R - single output variants of already supported
DACs.
adi,ad7192
- Add support for ad7194 24-bit ADC with integrated PGA.
adi,ad7380
- New ADC driver built up in a number of steps. Supports
- 2 channel differential ADCs: AD7380, AD7381
- 4 channel differential ADCs: AD7380-4, AD7381-4
- 2 channel pseudo-differential ADCs: AD7383, AD7384
- 4 channel pseudo-differential ADCs: AD7383-4, AD7384-4
adi,adis16475
- Support ADS16501 variant - ID and some different scale factors from
parts already supported.
- Driver refactoring then enables support for 6 more IMUs:
- ADIS16575-[2,3]
- ADIS16576-[2,3]
- ADIS16577-[2,3]
adi,adsi16480
- Driver refactoring and feature additions leading to support for 6 more
IMUs - with new delta angle and delta velocity feature:
- ADIS16545-[1,2,3]
- ADIS16547-[1,2,3]
bosch,bmi160
- Support for the bmi120 IMU: ID only. Also relax ID checking to warn
only on mismatch allowing use of fallback compatibles for new devices.
sciosense,ens160
- New driver for this metal oxide multi-gas sensor for indoor
air quality monitoring.
sensortek,stk3110
- Support for stk3311a and stk3311s34 light sensor variants. Relax ID
checking to warn only on a mismatch allowing use of fallback compatibles
for new devices.
vishay,veml6040
- New driver for this RGBW light sensor. Note that whilst the register
interface is very different, the dt-binding similar enough that it is
shared with the existing vishay,veml6075 binding
x-powers,axp20x
- Add support for axp192, very similar to another supported PMIC ADC variant
but with a few more GPIO channels.
Dt-binding only
===============
ti,ads1015
- Add binding (no driver support yet) for ti,tla2021
New features
============
core
- Variable scan type support. We have papered over this for a long time
so good to finally resolve it.
Some devices will change their data output format (typically resolution)
dependent on settings such as oversampling. A new callback is added
to enable this. First used in the ad7380 driver.
- Harden the core against missing callback functions.
dt-binding:
- Add a single-channel property that can be used in per channel nodes
instead of reg to indicate which device channel. This is important
in devices with a mixture of differential and single ended channels
as reg already just acted as an index for the differential channels
making things inconsistent if it had more meaning for single ended
channels.
adi,ad7380
- Use spi_optimize_message() to reduce reading message setup overhead.
- Add oversampling support using the new core functionality to allow
a device support multiple scan types.
invense,icm42600
- Support for low-power accelerometer modes. When a given sampling
frequency is only supported at one power mode, use that. Otherwise
default to low power at the cost of some noise unless overridden
via a new sysfs attribute.
silicon-labs,si70720
- Add control of the heater.
Cleanups and minor fixes
========================
core
- Cleanup use of sizeof(struct xxxx) in favor of sizeof(*variable)
Makefile
- Resort the iio/adc/Makefile which has drifted away from alphabetical
order.
gts library
- Fix sorting of lists with a zero in the middle. Doesn't happen with
upstream drivers, but good to harden this code. Add a related unit test.
multiple drivers
- Add missing MODULE_DESCRIPTION()
- Drop some unused structure fields.
- Drop some entirely unused structure definitions.
- Stop pointless initialization of i2c_device_id::driver_data to 0 in drivers
where it isn't used.
- Use spi_get_device_match_data() to replace open-coded equivalent.
adi,ad3552r
- Fix dt gain parameter names to reflect what the driver does. Note
discussion in patch to justify fixing it in the binding not the
driver.
- Tidy up some naming.
adi,ad7192
- Use read_avail() callback to handle the low pass filter.
- Add an aincom supply for pseudo differential operation.
adi,ad7606
- Use iio_device_claim_direct_scoped() to simplify error paths.
adi,ad7944
- Drop an unused function parameter.
adi,adrf6780
- Drop unused header.
adi,ad9467
- Use a DMA safe buffer for SPI transfers.
- Stop using tabs to pad structure field names. It was creating a lot
of noise.
adi,axi-adc
- Prevent races between enable and disable calls.
- Ensure the DRP (dynamic reconfiguration port) is locked. Not used
in most real designs, but better safe than sorry.
- Limit build to COMPILE_TEST or platforms for which the IP exists.
adi,axi-dac
- Limit build to COMPILE_TEST or platforms for which the IP exists.
ams,iaq
- Use __packed instead of ___attribute__((__packed__))
bosch,bmp280
- White space cleanup.
- Use BME280 prefix for registers that do not exist on the BMP280.
- Add parameter names to callback function definitions.
- Rename measure function to better reflect what it does which is wait
for a measurement to happen.
- Drop a redundant error check.
- Improve error messages
- Make error checks consistent as if (ret)
- Use unsigned types for inherently unsigned data.
- Refactor reading functions to not rely on a hidden t_fine variable.
- Make use of cleanup.h
freescale,mma7660
- Add mount matrix support.
invense,icm42600
- Enable the regmap cache to reduce bus accesses.
amlogic,meson-saradc
- Add dt-binding support for power-domains.
ti,adc161s626
- Use iio_device_claim_direct_scoped() to simplify error handling.
* tag 'iio-for-6.11a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (107 commits)
iio: imu: inv_icm42600: add support of accel low-power mode
iio: document inv_icm42600 driver private sysfs attributes
MAINTAINERS: Add ScioSense ENS160
iio: chemical: ens160: add power management support
iio: chemical: ens160: add triggered buffer support
iio: chemical: add driver for ENS160 sensor
dt-bindings: iio: chemical: add ENS160 sensor
dt-bindings: vendor-prefixes: add ScioSense
iio: temperature: mcp9600: add threshold events support
dt-bindings: iio: light: add VEML6040 RGBW-LS
iio: light: driver for Vishay VEML6040
dt-bindings: iio: adc: amlogic,meson-saradc: add optional power-domains
iio: dac: adi-axi-dac: add platform dependencies
iio: adc: adi-axi-adc: add platform dependencies
iio: imu: inv_icm42600: add register caching in the regmap
iio: adc: mcp3564: drop redundant open-coded spi_get_device_match_data()
iio: dac: max5522: simplify with spi_get_device_match_data()
iio: addac: ad74413r: simplify with spi_get_device_match_data()
iio: adc: ti-tsc2046: simplify with spi_get_device_match_data()
iio: adc: ti-ads131e08: simplify with spi_get_device_match_data()
...
The currently used normalized address format is not applicable to all
MI300 systems. This leads to incorrect results during address
translation.
Drop the fixed layout and construct the normalized address from system
settings.
Fixes: 87a6123753 ("RAS/AMD/ATL: Add MI300 DRAM to normalized address translation support")
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20240607-mi300-dram-xl-fix-v1-2-2f11547a178c@amd.com
Introduce numa_valid_node(nid) that verifies that nid is a valid node ID
and use that instead of comparing nid parameter with either NUMA_NO_NODE
or MAX_NUMNODES.
This makes the checks for valid node IDs consistent and more robust and
allows to get rid of multiple WARNings.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Enable the LVDS-to-HDMI bridge and the HDMI display connector drivers
used on the iMX53 QSB and QSRB boards with the HDMI mezzanine.
Cc: Chris Healy <cphealy@gmail.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Chris Healy <cphealy@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The adv7535 has some unnecessary entries which can be removed since
they were not setup properly anyway and the defaults work just fine.
Removing them and adding some required regulators make the errors
detected from CHECK_DTBS go away:
reg-names:1: 'edid' was expected
reg-names:2: 'cec' was expected
'avdd-supply' is a required property
'dvdd-supply' is a required property
'pvdd-supply' is a required property
'a2vdd-supply' is a required property
'v3p3-supply' is a required property
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
dt_binding require I2C's clock name is "ipg". Change it to "ipg" from "i2c"
to fix below DTB_CHECK warning.
arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dtb: i2c@2010000: clock-names:0: 'ipg' was expected
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
dt_binding require I2C's clock name is "ipg". Change it to "ipg" from "i2c"
to fix below DTB_CHECK warning.
arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dtb: i2c@2000000: clock-names:0: 'ipg' was expected
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
dt_binding require I2C's clock name is "ipg". Change it to "ipg" from "i2c"
to fix below DTB_CHECK warning.
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dtb: i2c@2190000: clock-names:0: 'ipg' was expecte
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Change order of sai's dma-names to clearn up below DTB_CHECK warning.
arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dtb: sai@2b50000: dma-names:1: 'tx' was expected
arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dtb: sai@2b60000: dma-names:1: 'tx' was expected
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Enable drivers for devices/features used on MBa7x.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Fix an off-by-one error where the most significant digit was not
initialized leading to signature verification failures by the testmgr.
Example: If a curve requires ndigits (=9) and diff (=2) indicates that
2 digits need to be set to zero then start with digit 'ndigits - diff' (=7)
and clear 'diff' digits starting from there, so 7 and 8.
Reported-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Closes: https://lore.kernel.org/linux-crypto/619bc2de-b18a-4939-a652-9ca886bf6349@linux.ibm.com/T/#m045d8812409ce233c17fcdb8b88b6629c671f9f4
Fixes: 2fd2a82ccb ("crypto: ecdsa - Use ecc_digits_from_bytes to create hash digits array")
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add comment to ecc_digits_from_bytes kdoc that the first byte is expected
to hold the most significant bits of the large integer that is converted
into an array of digits.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The 'struct list' type is defined in types.h, no need to include list.h
for that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
On newer SoCs, the random number generator can require a power-domain to
operate, add it as optional.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add the skip_empty flag to symbol_conf and set the value from the report
command to preserve the existing behavior. This makes the code simpler
and will be needed other code which is hard to add a new argument.
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240607202918.2357459-4-namhyung@kernel.org
The struct hpp_fmt_data is to keep the values for each group members so
it doesn't need to check the event index in the group.
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240607202918.2357459-3-namhyung@kernel.org
Split the logic to print the histogram values according to the format
string. This was used in 3 different places so it's better to move out
the logic into a function.
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240607202918.2357459-2-namhyung@kernel.org
perf sched map supports cpu filter.
However, even with cpu filters active, any context switch currently
corresponds to a separate line.
As result, context switches on irrelevant cpus result to redundant lines,
which makes the output particlularly difficult to read on wide
architectures.
Fix it by skipping printing for irrelevant CPUs.
Example snippet of output before fix:
*B0 1.461147 secs
B0
B0
B0
*G0 1.517139 secs
After fix:
*B0 1.461147 secs
*G0 1.517139 secs
Signed-off-by: Fernand Sieber <sieberf@amazon.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Reviewed-and-tested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240614073517.94974-1-sieberf@amazon.com
With the switch to using the zone append emulation of the block layer
zone write plugging, the macro DM_ZONE_INVALID_WP_OFST is no longer used
in dm-zone.c. Remove its definition.
Fixes: f211268ed1 ("dm: Use the block layer zone append emulation")
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240611023639.89277-5-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The generic stacking of limits implemented in the block layer cannot
correctly handle stacking of zone resource limits (max open zones and
max active zones) because these limits are for an entire device but the
stacking may be for a portion of that device (e.g. a dm-linear target
that does not cover an entire block device). As a result, when DM
devices are created on top of zoned block devices, the DM device never
has any zone resource limits advertized, which is only correct if all
underlying target devices also have no zone resource limits.
If at least one target device has resource limits, the user may see
either performance issues (if the max open zone limit of the device is
exceeded) or write I/O errors if the max active zone limit of one of
the underlying target devices is exceeded.
While it is very difficult to correctly and reliably stack zone resource
limits in general, cases where targets are not sharing zone resources of
the same device can be dealt with relatively easily. Such situation
happens when a target maps all sequential zones of a zoned block device:
for such mapping, other targets mapping other parts of the same zoned
block device can only contain conventional zones and thus will not
require any zone resource to correctly handle write operations.
For a mapped device constructed with such targets, which includes mapped
devices constructed with targets mapping entire zoned block devices, the
zone resource limits can be reliably determined using the non-zero
minimum of the zone resource limits of all targets.
For mapped devices that include targets partially mapping the set of
sequential write required zones of zoned block devices, instead of
advertizing no zone resource limits, it is also better to set the mapped
device limits to the non-zero minimum of the limits of all targets. In
this case the limits for a target depend on the number of sequential
zones being mapped: if this number of zone is larger than the limits,
then the limits of the device apply and can be used. If on the other
hand the target maps a number of zones smaller than the limits, then no
limits is needed and we can assume that the target has no limits (limits
set to 0).
This commit improves zone resource limits handling as described above
by modifying dm_set_zones_restrictions() to iterate the targets of a
mapped device to evaluate the max open and max active zone limits. This
relies on an internal "stacking" of the limits of the target devices
combined with a direct counting of the number of sequential zones
mapped by the targets.
1) For a target mapping an entire zoned block device, the limits for the
target are set to the limits of the device.
2) For a target partially mapping a zoned block device, the number of
mapped sequential zones is used to determine the limits: if the
target maps more sequential write required zones than the device
limits, then the limits of the device are used as-is. If the number
of mapped sequential zones is lower than the limits, then we assume
that the target has no limits (limits set to 0).
As this evaluation is done for each target, the zone resource limits
for the mapped device are evaluated as the non-zero minimum of the
limits of all the targets.
For configurations resulting in unreliable limits, i.e. a table
containing a target partially mapping a zoned device, a warning message
is issued.
The counting of mapped sequential zones for the target is done using the
new function dm_device_count_zones() which performs a report zones on
the entire block device with the callback dm_device_count_zones_cb().
This count of mapped sequential zones is also used to determine if the
mapped device contains only conventional zones. This allows simplifying
dm_set_zones_restrictions() to not do a report zones just for this.
For mapped devices mapping only conventional zones, as before, the
mapped device is changed to a regular device by setting its zoned limit
to false and clearing all its zone related limits.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240611023639.89277-4-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
dm_revalidate_zones() is called from dm_set_zone_restrictions() when the
mapped device queue limits are not yet set. However,
dm_revalidate_zones() calls blk_revalidate_disk_zones() and this
function consults and modifies the mapped device queue limits. Thus,
currently, blk_revalidate_disk_zones() operates on limits that are not
yet initialized.
Fix this by moving the call to dm_revalidate_zones() out of
dm_set_zone_restrictions() and into dm_table_set_restrictions() after
executing queue_limits_set().
To further cleanup dm_set_zones_restrictions(), the message about the
type of zone append (native or emulated) is also moved inside
dm_revalidate_zones().
Fixes: 1c0e720228 ("dm: use queue_limits_set")
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240611023639.89277-3-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Make sure that the zone resource limits of a zoned block device are
correct by checking that:
(a) If the device has a max active zones limit, make sure that the max
open zones limit is lower than the max active zones limit.
(b) If the device has zone resource limits, check that the limits
values are lower than the number of sequential zones of the device.
If it is not, assume that the zoned device has no limits by setting
the limits to 0.
For (a), a check is added to blk_validate_zoned_limits() and an error
returned if the max open zones limit exceeds the value of the max active
zone limit (if there is one).
For (b), given that we need the number of sequential zones of the zoned
device, this check is added to disk_update_zone_resources(). This is
safe to do as that function is executed with the disk queue frozen and
the check executed after queue_limits_start_update() which takes the
queue limits lock. Of note is that the early return in this function
for zoned devices that do not use zone write plugging (e.g. DM devices
using native zone append) is moved to after the new check and adjustment
of the zone resource limits so that the check applies to any zoned
device.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Link: https://lore.kernel.org/r/20240611023639.89277-2-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
i.MX8MP irqsteer has power-domain support, so use a dedicated compatible.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Verdin I2C2 may be used to access other I2C devices apart from serving
as an HDMI DDC channel.
Thus do not limit the used I2C clock frequency to 10kHz in the module
specific device tree part.
If an overlay configures i2c2 as DDC the overlay is also responsible
to cope with an appropriate I2C clock.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Verdin I2C2 may be used to access other I2C devices apart from serving
as an HDMI DDC channel.
Thus do not limit the used I2C clock frequency to 10kHz in the module
specific device tree part.
If an overlay configures i2c2 as DDC the overlay is also responsible
to cope with an appropriate I2C clock.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
UART2 and UART4 can used in following combination,
2 x RS232:
- UART2 and UART4 without flow control
- MUX selection GPIO3_20 must be held low
1 x RS232 + 1 x RS485:
- UART2 - RS232
- UART4 - RS485
- MUX selection GPIO3_20 must be held high
- RE/DE for RS485 controlled with GPIO3_25
1 x RS232 with flow control:
- UART2 - RS232
- MUX selection GPIO3_20 must be held low
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
I210 intel ethernet controller is connected to PCIe. Enable the PHY
to use the ethernet controller.
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
It looks up `stt` from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because `stt` is used outside the locked regions.
With an artifcial delay after the fdput() and a userspace program which
triggers the race, KASAN detects the UAF:
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
Call Trace:
dump_stack_lvl+0xb4/0x108 (unreliable)
print_report+0x2b4/0x6ec
kasan_report+0x118/0x2b0
__asan_load4+0xb8/0xd0
kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
kvm_vfio_set_attr+0x524/0xac0 [kvm]
kvm_device_ioctl+0x144/0x240 [kvm]
sys_ioctl+0x62c/0x1810
system_call_exception+0x190/0x440
system_call_vectored_common+0x15c/0x2ec
...
Freed by task 0:
...
kfree+0xec/0x3e0
release_spapr_tce_table+0xd4/0x11c [kvm]
rcu_core+0x568/0x16a0
handle_softirqs+0x23c/0x920
do_softirq_own_stack+0x6c/0x90
do_softirq_own_stack+0x58/0x90
__irq_exit_rcu+0x218/0x2d0
irq_exit+0x30/0x80
arch_local_irq_restore+0x128/0x230
arch_local_irq_enable+0x1c/0x30
cpuidle_enter_state+0x134/0x5cc
cpuidle_enter+0x6c/0xb0
call_cpuidle+0x7c/0x100
do_idle+0x394/0x410
cpu_startup_entry+0x60/0x70
start_secondary+0x3fc/0x410
start_secondary_prolog+0x10/0x14
Fix it by delaying the fdput() until `stt` is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.
With the fix in place the test case no longer triggers the UAF.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Closes: https://lore.kernel.org/all/20240610024437.GA1464458@ZenIV/
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240614122910.3499489-1-mpe@ellerman.id.au
* Ensure xfs incore superblock's
1. Allocated inode counter
2. Free inode counter
3. Free data block counter
are zero or positive when they are copied over from
xfs_mount->m_[icount,ifree,fdblocks] respectively.
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQjMC4mbgVeU7MxEIYH7y4RirJu9AUCZm20zAAKCRAH7y4RirJu
9KU+AQDbXY06rXotcoDqALGSKoGZddBnfJMhOiFgOzNDJ+Cy7AEAieixGN2COKoV
Xa3TzIO6fb0mbNg7RDySY6XideiJ7Qw=
=xnum
-----END PGP SIGNATURE-----
Merge tag 'xfs-6.10-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fix from Chandan Babu:
"Ensure xfs incore superblock's allocated inode counter, free inode
counter, and free data block counter are all zero or positive when
they are copied over from xfs_mount->m_[icount,ifree,fdblocks]
respectively"
* tag 'xfs-6.10-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: make sure sb_fdblocks is non-negative
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmZts6cACgkQiiy9cAdy
T1FGnQwAhUSxD4sWvJ8XL2Y+k8AL/Lh9sGpoj9vgBBgjt9W9nFLT0thEcGDqkpDO
n9U8OMxsP1+U86WuM28Yuz9+3WvVvX+ZYrG/LBD3DuyoZnpuIzkBst2XUCA+SpKB
XZ52lLsEQj0Apr0muM98kv+RqZrJwHjE0nrPv0BhQAxNzgaJPJ7RqjjIqBvnBT35
+OPckXbl3uda5mbnj/jPBYRU3asIkfLcAXh2Q6dwpFRtWLj4P+IOAEB7wfPlVr9O
rA7ASq7fPuwKSCHpCehWlNdkPItqV2JDN7uvoIZF+83Ob7I6U+Mm6vDJKmf2ap9T
JW3U2FwytAvvcCnlPj2xW+7fs227hDsLDbbnQGnV00W9LCCxi9t30PgCw5ISx2CP
XDSg3VvBt6TLzRkGQ44enHxQdNuQ8JGh99MWFl4U54N/j5smyXPfegph28QLi73f
Ksq+VnHJUMEppaoWO37G0lHfgodA1G4zLWqFeZnNHpC9cqgXm7TNxD7ZhAgQEKGL
EdtEH3rH
=6H3L
-----END PGP SIGNATURE-----
Merge tag '6.10-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd
Pull smb server fixes from Steve French:
"Two small smb3 server fixes:
- set xatttr fix
- pathname parsing check fix"
* tag '6.10-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd:
ksmbd: fix missing use of get_write in in smb2_set_ea()
ksmbd: move leading slash check to smb2_get_name()
In kcov_remote_start()/kcov_remote_stop(), we swap the previous KCOV
metadata of the current task into a per-CPU variable. However, the
kcov_mode_enabled(mode) check is not sufficient in the case of remote KCOV
coverage: current->kcov_mode always remains KCOV_MODE_DISABLED for remote
KCOV objects.
If the original task that has invoked the KCOV_REMOTE_ENABLE ioctl happens
to get interrupted and kcov_remote_start() is called, it ultimately leads
to kcov_remote_stop() NOT restoring the original KCOV reference. So when
the task exits, all registered remote KCOV handles remain active forever.
The most uncomfortable effect (at least for syzkaller) is that the bug
prevents the reuse of the same /sys/kernel/debug/kcov descriptor. If
we obtain it in the parent process and then e.g. drop some
capabilities and continuously fork to execute individual programs, at
some point current->kcov of the forked process is lost,
kcov_task_exit() takes no action, and all KCOV_REMOTE_ENABLE ioctls
calls from subsequent forks fail.
And, yes, the efficiency is also affected if we keep on losing remote
kcov objects.
a) kcov_remote_map keeps on growing forever.
b) (If I'm not mistaken), we're also not freeing the memory referenced
by kcov->area.
Fix it by introducing a special kcov_mode that is assigned to the task
that owns a KCOV remote object. It makes kcov_mode_enabled() return true
and yet does not trigger coverage collection in __sanitizer_cov_trace_pc()
and write_comp_data().
[nogikh@google.com: replace WRITE_ONCE() with an ordinary assignment]
Link: https://lkml.kernel.org/r/20240614171221.2837584-1-nogikh@google.com
Link: https://lkml.kernel.org/r/20240611133229.527822-1-nogikh@google.com
Fixes: 5ff3b30ab5 ("kcov: collect coverage from interrupts")
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Marco Elver <elver@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When testing shmem swapin, I encountered the warning below on my machine.
The reason is that replacing an old shmem folio with a new one causes
mem_cgroup_migrate() to clear the old folio's memcg data. As a result,
the old folio cannot get the correct memcg's lruvec needed to remove
itself from the LRU list when it is being freed. This could lead to
possible serious problems, such as LRU list crashes due to holding the
wrong LRU lock, and incorrect LRU statistics.
To fix this issue, we can fallback to use the mem_cgroup_replace_folio()
to replace the old shmem folio.
[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960
[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)
[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000
[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000
[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000
[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000
[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled())
[ 5241.100338] ------------[ cut here ]------------
[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150
[...]
[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150
[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150
[ 5241.100376] sp : ffff80008b38b930
[...]
[ 5241.100398] Call trace:
[ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150
[ 5241.100401] __page_cache_release+0x90/0x300
[ 5241.100404] __folio_put+0x50/0x108
[ 5241.100406] shmem_replace_folio+0x1b4/0x240
[ 5241.100409] shmem_swapin_folio+0x314/0x528
[ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930
[ 5241.100412] shmem_fault+0x74/0x160
[ 5241.100414] __do_fault+0x40/0x218
[ 5241.100417] do_shared_fault+0x34/0x1b0
[ 5241.100419] do_fault+0x40/0x168
[ 5241.100420] handle_pte_fault+0x80/0x228
[ 5241.100422] __handle_mm_fault+0x1c4/0x440
[ 5241.100424] handle_mm_fault+0x60/0x1f0
[ 5241.100426] do_page_fault+0x120/0x488
[ 5241.100429] do_translation_fault+0x4c/0x68
[ 5241.100431] do_mem_abort+0x48/0xa0
[ 5241.100434] el0_da+0x38/0xc0
[ 5241.100436] el0t_64_sync_handler+0x68/0xc0
[ 5241.100437] el0t_64_sync+0x14c/0x150
[ 5241.100439] ---[ end trace 0000000000000000 ]---
[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]
Link: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba.com
Link: https://lkml.kernel.org/r/3c11000dd6c1df83015a8321a859e9775ebbc23e.1718266112.git.baolin.wang@linux.alibaba.com
Fixes: 85ce2c517a ("memcontrol: only transfer the memcg data for migration")
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Macro RANDOM_ORVALUE was used to make sure the pgtable entry will be
populated with !none data in clear tests.
The RANDOM_ORVALUE tried to cover mostly all the bits in a pgtable entry,
even if there's no discussion on whether all the bits will be vaild. Both
S390 and PPC64 have their own masks to avoid touching some bits. Now it's
the turn for x86_64.
The issue is there's a recent report from Mikhail Gavrilov showing that
this can cause a warning with the newly added pte set check in commit
8430557fc5 on writable v.s. userfaultfd-wp bit, even though the check
itself was valid, the random pte is not. We can choose to mask more bits
out.
However the need to have such random bits setup is questionable, as now
it's already guaranteed to be true on below:
- For pte level, the pgtable entry will be installed with value from
pfn_pte(), where pfn points to a valid page. Hence the pte will be
!none already if populated with pfn_pte().
- For upper-than-pte level, the pgtable entry should contain a directory
entry always, which is also !none.
All the cases look like good enough to test a pxx_clear() helper. Instead
of extending the bitmask, drop the "set random bits" trick completely. Add
some warning guards to make sure the entries will be !none before clear().
Link: https://lkml.kernel.org/r/20240523132139.289719-1-peterx@redhat.com
Fixes: 8430557fc5 ("mm/page_table_check: support userfault wr-protect entries")
Signed-off-by: Peter Xu <peterx@redhat.com>
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Link: https://lore.kernel.org/r/CABXGCsMB9A8-X+Np_Q+fWLURYL_0t3Y-MdoNabDM-Lzk58-DGA@mail.gmail.com
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Gavin Shan <gshan@redhat.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
I hit the VM_BUG_ON(!list_empty(&cc->migratepages)) in compact_zone(); and
if DEBUG_VM were off, then pages would be lost on a local list.
Our convention is that if migrate_pages() reports complete success (0),
then the migratepages list will be empty; but if it reports an error or
some pages remaining, then its caller must putback_movable_pages().
There's a new case in which migrate_pages() has been reporting complete
success, but returning with pages left on the migratepages list: when
migrate_pages_batch() successfully split a folio on the deferred list, but
then the "Failure isn't counted" call does not dispose of them all.
Since that block is expecting the large folio to have been counted as 1
failure already, and since the return code is later adjusted to success
whenever the returned list is found empty, the simple way to fix this
safely is to count splitting the deferred folio as "a failure".
Link: https://lkml.kernel.org/r/46c948b4-4dd8-6e03-4c7b-ce4e81cfa536@google.com
Fixes: 7262f208ca ("mm/migrate: split source folio if it is on deferred split list")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
KTAP parsers interpret the output of ksft_test_result_*() as being the
name of the test. The map_fixed_noreplace test uses a dynamically
allocated base address for the mmap()s that it tests and currently
includes this in the test names that it logs so the test names that are
logged are not stable between runs. It also uses multiples of PAGE_SIZE
which mean that runs for kernels with different PAGE_SIZE configurations
can't be directly compared. Both these factors cause issues for CI
systems when interpreting and displaying results.
Fix this by replacing the current test names with fixed strings describing
the intent of the mappings that are logged, the existing messages with the
actual addresses and sizes are retained as diagnostic prints to aid in
debugging.
Link: https://lkml.kernel.org/r/20240605-kselftest-mm-fixed-noreplace-v1-1-a235db8b9be9@kernel.org
Fixes: 4838cf70e5 ("selftests/mm: map_fixed_noreplace: conform test to TAP format output")
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it didn't
have proper documentation. This led to a lot of confusion, especially
about whether or not memfd created with the MFD_NOEXEC_SEAL flag is
sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set
MFD_ALLOW_SEALING to be sealable, so it's a fair question.
As one might have noticed, unlike other flags in memfd_create,
MFD_NOEXEC_SEAL is actually a combination of multiple flags. The idea is
to make it easier to use memfd in the most common way, which is NOEXEC +
F_SEAL_EXEC + MFD_ALLOW_SEALING. This works with sysctl vm.noexec to help
existing applications move to a more secure way of using memfd.
Proposals have been made to put MFD_NOEXEC_SEAL non-sealable, unless
MFD_ALLOW_SEALING is set, to be consistent with other flags [1], Those
are based on the viewpoint that each flag is an atomic unit, which is a
reasonable assumption. However, MFD_NOEXEC_SEAL was designed with the
intent of promoting the most secure method of using memfd, therefore a
combination of multiple functionalities into one bit.
Furthermore, the MFD_NOEXEC_SEAL has been added for more than one year,
and multiple applications and distributions have backported and utilized
it. Altering ABI now presents a degree of risk and may lead to
disruption.
MFD_NOEXEC_SEAL is a new flag, and applications must change their code to
use it. There is no backward compatibility problem.
When sysctl vm.noexec == 1 or 2, applications that don't set
MFD_NOEXEC_SEAL or MFD_EXEC will get MFD_NOEXEC_SEAL memfd. And
old-application might break, that is by-design, in such a system vm.noexec
= 0 shall be used. Also no backward compatibility problem.
I propose to include this documentation patch to assist in clarifying the
semantics of MFD_NOEXEC_SEAL, thereby preventing any potential future
confusion.
Finally, I would like to express my gratitude to David Rheinsberg and
Barnabás Pőcze for initiating the discussion on the topic of sealability.
[1]
https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/
[jeffxu@chromium.org: updates per Randy]
Link: https://lkml.kernel.org/r/20240611034903.3456796-2-jeffxu@chromium.org
[jeffxu@chromium.org: v3]
Link: https://lkml.kernel.org/r/20240611231409.3899809-2-jeffxu@chromium.org
Link: https://lkml.kernel.org/r/20240607203543.2151433-2-jeffxu@google.com
Signed-off-by: Jeff Xu <jeffxu@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Barnabás Pőcze <pobrn@protonmail.com>
Cc: Daniel Verkamp <dverkamp@chromium.org>
Cc: David Rheinsberg <david@readahead.eu>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
