The denylist is blocking the 32 bit version of the call but is allowing
the 64 bit version of it. There is no reason for blocking only one of
them and the hypervisor should support these calls.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20240411135700.2140550-1-sebastianene@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Adding new entries to our system register tables is a painful exercise,
as we require them to be ordered by Op0,Op1,CRn,CRm,Op2.
If an entry is misordered, we output an error that indicates the
pointer to the entry and the number *of the last valid one*.
That's not very helpful, and would be much better if we printed the
number of the *offending* entry as well as its name (which is present
in the vast majority of the cases).
This makes debugging new additions to the tables much easier.
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Link: https://lore.kernel.org/r/20240410152503.3593890-1-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
There are two issues here:
1) The get_device() needs a matching put_device() on error paths.
2) The "if (!ret)" was supposed to be "if (ret)".
I re-arranged the code a bit to do the allocation before the
get_device().
Fixes: ef7784e41d ("ASoC: soc-card: Add KUnit test case for snd_soc_card_get_kcontrol")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/450dd21a-b24b-48ba-9aa4-c02e4617852f@moroto.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Document fsl,imx25-pdk-sgtl5000 to fix the following dt-schema warning:
imx25-pdk.dtb: sound: compatible: 'oneOf' conditional failed, one must be fixed:
['fsl,imx25-pdk-sgtl5000', 'fsl,imx-audio-sgtl5000'] is too long
Fixes: 4189b54220 ("ASoC: dt-bindings: fsl-asoc-card: convert to YAML")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240412121410.2948048-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When 96KHz sample rate is used, and MCLK is 24.576MHz, we will need
pll_in = 24576000 and pll_out = 49152000 which is not supported by
RT5682S_PLL2. Use RT5682S_PLL1 in this case.
We don't test sample rate because RT5682S_PLL2 doesn't support 24.576MHz
input and in the MCLK = 24.576MHz, sample rate = 48KHz case, i.e.
pll_in == pll_out, PLL will not be used at all.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-13-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Delete this driver and use sof_rt5682 machine driver instead.
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Signed-off-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-12-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For cml boards, ALC1011 speaker amplifier is supported by machine
driver cml_rt1011_rt5682. Use same driver name for backward
compatibility with existing devices on market.
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Signed-off-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-11-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for boards with four ALC1011 amplifiers. Configuration is
copied from cml_rt1011_rt5682 machine driver for backward
compatibility with existing cml devices.
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Signed-off-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the board config mtl_da7219_def to da7219 machine driver for all
mtl boards using default SSP port allocation (headphone codec on SSP2,
speaker amplifiers on SSP0, and BT offload on SSP1).
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a common entry in enumeration table for all da7219 boards
with/without speaker amplifier. All other rpl_da7219_def entries
become redundant so get removed.
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a common entry in enumeration table for all da7219 boards
with/without speaker amplifier. All other adl_da7219_def entries
become redundant so get removed.
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch removes a confusion between speakers and amplifiers.
The existing code keeps track of the number of amplifiers and reports
it in the 'cfg-amp' component string.
The number of speakers is defined with quirks, but those quirks are
not consistently added: in the MeteorLake case, none of the supported
platforms used such a quirk, and UCM does not use the values reported
anyways. The notion of 'FOUR_SPEAKERS' is also obsolete now with some
platforms having more than four speakers.
Let's just remove all this and only report the number of amplifiers.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20240411220347.131267-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The version format string in the AXI SPI Engine driver was probably
intended to print the version number in the same format as the DT
compatible string (e.g. 1.00.a). However, the version just uses
semantic versioning so formatting the patch number as a character
is not correct and would result in printing control characters for
patch numbers less than 32.
Fixes: b1353d1c1d ("spi: Add Analog Devices AXI SPI Engine controller support")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20240412-axi-spi-engine-version-printf-v1-1-95e1e842c1a6@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The btree write buffer flush fastpath that avoids the main transaction
commit path had the unfortunate side effect of not doing btree node
merging.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
There's been a bug in the btree write buffer where it wasn't triggering
btree node merges - and leaving behind a bunch of nearly empty btree
nodes.
Then during journal replay, when updates to the backpointers btree
aren't using the btree write buffer (because we require synchronization
with journal replay), we end up doing those merges all at once.
Then if it's the interior update path running them, we deadlock because
those run with the highest watermark.
There's no real need for the interior update path to be doing btree node
merges; other code paths can handle that at lower watermarks.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This fixes a deadlock where the interior update path during journal
replay ends up doing a ton of merges on the backpointers btree, and
deadlocking.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
btree_key_can_insert_cached() should be checking the watermark -
BCH_TRANS_COMMIT_journal_replay really means nonblocking mode when
watermark < reclaim, it was being used incorrectly.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This fixes a bug where we fail to start when upgrading/downgrading
because we forgot we needed to go rw.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The btree paths array is now dynamically resizable - and as well the
btree_insert_entries array, as it needs to be the same size.
The merge path (and interior update path) allocates new btree paths,
thus can trigger a resize; thus we need to not retain direct pointers
after invoking merge; similarly when running btree node triggers.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
- Add the mask_port_map parameter to the ahci driver. This is a
follow-up to the recent snafu with the ASMedia controller and its
virtual port hidding port-multiplier devices. As ASMedia confirmed
that there is no way to determine if these slow-to-probe virtual
ports are actually representing the ports of a port-multiplier
devices, this new parameter allow masking ports to significantly
speed up probing during system boot, resulting in shorter boot times.
- A fix for an incorrect handling of a port unlock in
ata_scsi_dev_rescan().
- Allow command duration limits to be detected for ACS-4 devices are
there are such devices out in the field.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCZho+/AAKCRDdoc3SxdoY
dhm2AP49p/aAmpTGKYQjXwiQWH4JMR/ey9rZgdw0jjGtMYkdRQEA+aCLtWFKnENr
1E+lnTO+ef01BhJlk/FCK2VyOqCNxwM=
=pDw+
-----END PGP SIGNATURE-----
Merge tag 'ata-6.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fixes from Damien Le Moal:
- Add the mask_port_map parameter to the ahci driver. This is a
follow-up to the recent snafu with the ASMedia controller and its
virtual port hidding port-multiplier devices. As ASMedia confirmed
that there is no way to determine if these slow-to-probe virtual
ports are actually representing the ports of a port-multiplier
devices, this new parameter allow masking ports to significantly
speed up probing during system boot, resulting in shorter boot times.
- A fix for an incorrect handling of a port unlock in
ata_scsi_dev_rescan().
- Allow command duration limits to be detected for ACS-4 devices are
there are such devices out in the field.
* tag 'ata-6.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: libata-core: Allow command duration limits detection for ACS-4 drives
ata: libata-scsi: Fix ata_scsi_dev_rescan() error path
ata: ahci: Add mask_port_map module parameter
- Suppress a coccicheck warning using str_plural().
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCZhnikwAKCRDdoc3SxdoY
ditrAP9s/r36Dl4c8BZxpoUyCmf44ww6oTMxGzjwi/4gA8Ry2gEA766WGVsDyJf2
G0qjl7+bVneaOG6Xayzce69OjvZGZws=
=U6kP
-----END PGP SIGNATURE-----
Merge tag 'zonefs-6.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs
Pull zonefs fix from Damien Le Moal:
- Suppress a coccicheck warning using str_plural()
* tag 'zonefs-6.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs:
zonefs: Use str_plural() to fix Coccinelle warning
Store pointers to chip info (struct ad5755_chip_info) in driver match
data, instead of enum, so every value will be != 0, populate the
of_device_id table and use it in driver. Even though it is one change,
it gives multiple benefits:
1. Allows to use spi_get_device_match_data() dropping local 'type'
variable.
2. Makes both ID tables usable, so kernel can match via any of these
methods.
3. Code is more obvious as both tables are properly filled.
4. Fixes W=1 warning:
ad5755.c:866:34: error: unused variable 'ad5755_of_match' [-Werror,-Wunused-const-variable]
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240413154511.52576-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmYaS/8ACgkQiiy9cAdy
T1G3OAwAjRyhi2XHb0QtA0YpZN0FLFghoY/+hgAYaS20WokdqbdyPfZeievRn6Jq
zgoRYmPF9ihEAZ/UnNIu5ficHoFFsNTxPodQKOTMKxtYg7RCWv7ZF87+/OafuG/k
FbYue7LQ1CvloEBMsNg088uFQsCp4u8k/9IaHHf+wEDmti42JTqoLjg5YsgbcotI
Qt8VtxTVL+FzPax/qQkXtBvHggxTfs7VWvwRkv21NsotQzBoPGxHxv3bUV9G54Ez
56w6Qg+R4ZSwIGgrRGAIjTZ0E6lPuIBanmePJlFwFB0em7Ajl3K2BBJUXpTsxgEd
aDgJKFZ+ZmDpp5GWlYRccmy/jm6uOiLdCxPye/EQk5KK/oUNpFUUQ95OJ1clH6Su
pR8LLk1yPQH+e8eyx0Exq7H8l0lsy4pHzerVyUgdgd9E1IZ3+MIN261vTu2TTfGq
CtML0WNcZFnQdYbMnkADAZ7zYgr32U0UiWr6WS+V0rugyguDrPIEiIneFl3rSZsq
MQaOHyS5
=AHB9
-----END PGP SIGNATURE-----
Merge tag 'v6.9-rc3-SMB3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull smb client fixes from Steve French:
- fix for oops in cifs_get_fattr of deleted files
- fix for the remote open counter going negative in some directory
lease cases
- fix for mkfifo to instantiate dentry to avoid possible crash
- important fix to allow handling key rotation for mount and remount
(ie cases that are becoming more common when password that was used
for the mount will expire soon but will be replaced by new password)
* tag 'v6.9-rc3-SMB3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
smb3: fix broken reconnect when password changing on the server by allowing password rotation
smb: client: instantiate when creating SFU files
smb3: fix Open files on server counter going negative
smb: client: fix NULL ptr deref in cifs_mark_open_handles_for_deleted_file()
Since commit 6020ca4de8 ("iio: adc: ad7944: use spi_optimize_message()"),
The helper functions wrapping spi_sync() for 3-wire and 4-wire modes are
virtually identical. Since gpiod_set_value_cansleep() does a NULL check
internally, we can consolidate the two functions into one and avoid
switch statements at the call sites.
The default cases of the removed switch statement were just to make the
compiler happy and are not reachable since the mode is validated in the
probe function. So removing those should be safe.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20240412-ad7944-consolidate-msg-v1-1-7fdeff89172f@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Before all supported sensors except for MPU{9150,9250,9255} were not
allowed to use i2c-gate in the bindings which excluded quite a few
supported sensors where this functionality is supported.
Switch the list of sensors to ones where the Linux driver explicitly
disallows support for the auxiliary bus ("inv_mpu_i2c_aux_bus"). Since
the driver is also based on "default: return true" this should scale
better into the future.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240408-mpu6050-i2c-gate-v1-1-621f051ce7de@z3ntu.xyz
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Nipun Gupta <nipun.gupta@amd.com>
Link: https://lore.kernel.org/r/5d40f57e978bcce003133306712ec96439e93595.1709886922.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Three key updates of note herein:
- Introduction of the COUNTER_COMP_FREQUENCY() macro to simplify
creation of "frequency" Counter extensions
- Three additional Signals (Clock, Channel 3, and Channel 4) are
supported for the stm32-timer-cnt
- Counter events support added for the stm32-timer-cnt
There are also some miscellaneous cleanups and improvements, such as
constifying Counter structures, resolving a kernel-doc description
warning, and converting platform_driver remove callbacks to remove_new.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCZho6sQAKCRC1SFbKvhIj
K13xAQDyn1p8SorzK92ZE7c/n3woDW+AdrphnrRFarbqi1AuQAD+OOO1PZsMvjRW
wS8J0eAPP4Zk1mOj6WQ6ou71KF5xhAA=
=mQ4V
-----END PGP SIGNATURE-----
Merge tag 'counter-updates-for-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-next
William writes:
Counter updates for 6.10
Three key updates of note herein:
- Introduction of the COUNTER_COMP_FREQUENCY() macro to simplify
creation of "frequency" Counter extensions
- Three additional Signals (Clock, Channel 3, and Channel 4) are
supported for the stm32-timer-cnt
- Counter events support added for the stm32-timer-cnt
There are also some miscellaneous cleanups and improvements, such as
constifying Counter structures, resolving a kernel-doc description
warning, and converting platform_driver remove callbacks to remove_new.
* tag 'counter-updates-for-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter:
counter: ti-ecap-capture: Utilize COUNTER_COMP_FREQUENCY macro
counter: ti-eqep: Convert to platform remove callback returning void
counter: ti-ecap-capture: Convert to platform remove callback returning void
MAINTAINERS: Update email addresses for William Breathitt Gray
counter: stm32-timer-cnt: add support for capture events
counter: stm32-timer-cnt: add support for overflow events
counter: stm32-timer-cnt: probe number of channels from registers
counter: stm32-timer-cnt: introduce channels
counter: stm32-timer-cnt: add checks on quadrature encoder capability
counter: stm32-timer-cnt: add counter prescaler extension
counter: stm32-timer-cnt: introduce clock signal
counter: stm32-timer-cnt: adopt signal definitions
counter: stm32-timer-cnt: rename counter
counter: stm32-timer-cnt: rename quadrature signal
counter: Introduce the COUNTER_COMP_FREQUENCY() macro
counter: constify the struct device_type usage
counter: make counter_bus_type const
counter: linux/counter.h: fix Excess kernel-doc description warning
Switching to the _scoped() version removes the need for manual
calling of fwnode_handle_put() in the paths where the code
exits the loop early. In this case that's all in error paths.
A slightly less convincing usecase than many as all the failure paths
are wrapped up in a call to a per fwnode_handle utility function.
The complexity in that function is sufficient that it makes sense to
factor it out even if it this new auto cleanup would enable simpler
returns if the code was inline at the call site. Hence I've left it alone.
Cc: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240330185305.1319844-3-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Switching to the _scoped() version removes the need for manual
calling of fwnode_handle_put() in the paths where the code
exits the loop early. In this case that's all in error paths.
Note this would have made the bug fixed in the previous path much
less likely as it allows for direct returns.
Took advantage of dev_err_probe() to futher simplify things given no
longer a need for the goto err.
Cc: Olivier Moysan <olivier.moysan@foss.st.com>
Tested-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20240330185305.1319844-5-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This path would result in returning 0 / success on an error path.
Cc: Olivier Moysan <olivier.moysan@foss.st.com>
Fixes: 95bc818404 ("iio: adc: stm32-adc: add support of generic channels binding")
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20240330185305.1319844-4-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
"The definition of insanity is doing the same thing over and over
again and expecting different results”
We've tried to do this before, most recently with commit bb2314b479
("fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink") about a
decade ago.
But the effort goes back even further than that, eg this thread back
from 1998 that is so old that we don't even have it archived in lore:
https://lkml.org/lkml/1998/3/10/108
which also points out some of the reasons why it's dangerous.
Or, how about then in 2003:
https://lkml.org/lkml/2003/4/6/112
where we went through some of the same arguments, just wirh different
people involved.
In particular, having access to a file descriptor does not necessarily
mean that you have access to the path that was used for lookup, and
there may be very good reasons why you absolutely must not have access
to a path to said file.
For example, if we were passed a file descriptor from the outside into
some limited environment (think chroot, but also user namespaces etc) a
'flink()' system call could now make that file visible inside a context
where it's not supposed to be visible.
In the process the user may also be able to re-open it with permissions
that the original file descriptor did not have (eg a read-only file
descriptor may be associated with an underlying file that is writable).
Another variation on this is if somebody else (typically root) opens a
file in a directory that is not accessible to others, and passes the
file descriptor on as a read-only file. Again, the access to the file
descriptor does not imply that you should have access to a path to the
file in the filesystem.
So while we have tried this several times in the past, it never works.
The last time we did this, that commit bb2314b479 quickly got reverted
again in commit f0cc6ffb8c (Revert "fs: Allow unprivileged linkat(...,
AT_EMPTY_PATH) aka flink"), with a note saying "We may re-do this once
the whole discussion about the interface is done".
Well, the discussion is long done, and didn't come to any resolution.
There's no question that 'flink()' would be a useful operation, but it's
a dangerous one.
However, it does turn out that since 2008 (commit d76b0d9b2d: "CRED:
Use creds in file structs") we have had a fairly straightforward way to
check whether the file descriptor was opened by the same credentials as
the credentials of the flink().
That allows the most common patterns that people want to use, which tend
to be to either open the source carefully (ie using the openat2()
RESOLVE_xyz flags, and/or checking ownership with fstat() before
linking), or to use O_TMPFILE and fill in the file contents before it's
exposed to the world with linkat().
But it also means that if the file descriptor was opened by somebody
else, or we've gone through a credentials change since, the operation no
longer works (unless we have CAP_DAC_READ_SEARCH capabilities in the
opener's user namespace, as before).
Note that the credential equality check is done by using pointer
equality, which means that it's not enough that you have effectively the
same user - they have to be literally identical, since our credentials
are using copy-on-write semantics.
So you can't change your credentials to something else and try to change
it back to the same ones between the open() and the linkat(). This is
not meant to be some kind of generic permission check, this is literally
meant as a "the open and link calls are 'atomic' wrt user credentials"
check.
It also means that you can't just move things between namespaces,
because the credentials aren't just a list of uid's and gid's: they
includes the pointer to the user_ns that the capabilities are relative
to.
So let's try this one more time and see if maybe this approach ends up
being workable after all.
Cc: Andrew Lutomirski <luto@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20240411001012.12513-1-torvalds@linux-foundation.org
[brauner: relax capability check to opener of the file]
Link: https://lore.kernel.org/all/20231113-undenkbar-gediegen-efde5f1c34bc@brauner
Signed-off-by: Christian Brauner <brauner@kernel.org>
The UEFI specification does not make any mention of a maximum variable
name size, so the headers and implementation shouldn't claim that one
exists either.
Comments referring to this limit have been removed or rewritten, as this
is an implementation detail local to the Linux kernel.
Where appropriate, the magic value of 1024 has been replaced with
EFI_VAR_NAME_LEN, as this is used for the efi_variable struct
definition. This in itself does not change any behavior, but should
serve as points of interest when making future changes in the same area.
A related build-time check has been added to ensure that the special
512 byte sized buffer will not overflow with a potentially decreased
EFI_VAR_NAME_LEN.
Signed-off-by: Tim Schumacher <timschumi@gmx.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The structure was moved to the efivarfs internals in commit 2d82e6227e
("efi: vars: Move efivar caching layer into efivarfs") after previously
being used as the data ABI for efivars until its removal in commit
0f5b2c69a4 ("efi: vars: Remove deprecated 'efivars' sysfs interface").
As efivarfs only uses the structure for the variable name caching layer,
the data-related members were never in use. Remove them to avoid
implying that efivarfs is bound by the same restrictions that efivars
once had. While at it, remove the packed attribute, since we no longer
have to guarantee a stable layout.
Signed-off-by: Tim Schumacher <timschumi@gmx.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
