aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2024-11-14ASoC: stm32: dfsdm: change rate upper limitsOlivier Moysan1-1/+1
Increase rate upper limit to 192kHz to reflect the rate range actually supported by the STM32 DFSDM peripheral. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20241114102851.2497942-1-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-14ASoC: sma1307: fix uninitialized variable refenceArnd Bergmann1-5/+5
When firmware loading is disabled, gcc warns that the local 'fw' variable fails to get initialized: sound/soc/codecs/sma1307.c: In function 'sma1307_setting_loaded.isra': sound/soc/codecs/sma1307.c:1717:12: error: 'fw' is used uninitialized [-Werror=uninitialized] 1717 | if (!fw) { | ^ sound/soc/codecs/sma1307.c:1712:32: note: 'fw' was declared here 1712 | const struct firmware *fw; Check the return code from request_firmware() to ensure that the firmware is correctly set, and drop the incorrect release_firmware() on that uninitialized data. Fixes: 576c57e6b4c1 ("ASoC: sma1307: Add driver for Iron Device SMA1307") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20241113175734.2443315-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-14ASoC: dt-bindings: simple-mux: add idle-state propertyHendrik v. Raven1-0/+5
simple-mux immediately activates the new output, even when it is powered down. This can be undesirable in some cases, for example when a mechanical relais is used. Adds "idle-state" property from the mux controller to select the output state to be used when the mux is powered down. Signed-off-by: Hendrik v. Raven <h.v.raven@merzmedtech.de> Link: https://patch.msgid.link/20241114-simple-mux-idle-state-v2-2-a30cb37d2be2@merzmedtech.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-14ASoc: simple-mux: add idle-state supportHendrik v. Raven1-1/+38
So far the mux changes it state immediately, even when not in use. Allow overriding this behaviour by specifying an optional idle-state. This state is used whenever the mux is powered down, only switching to the selected state on power up. If unspecified it defaults to as-is, maintaining the previous behaviour. Signed-off-by: Hendrik v. Raven <h.v.raven@merzmedtech.de> Link: https://patch.msgid.link/20241114-simple-mux-idle-state-v2-1-a30cb37d2be2@merzmedtech.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: sdca: test adev before calling acpi_dev_for_each_childBard Liao1-0/+4
sdca_lookup_functions may be called by a Peripheral that is not listed in the ACPI table. Testing adev is required to avoid kernel NULL pointer dereference. Fixes: 3a513da1ae33 ("ASoC: SDCA: add initial module") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20241113064133.162501-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: SOF: ipc4-topology: remove redundant assignment to variable retColin Ian King1-1/+0
The variable ret is being assigned a zero value however the value is never read because ret is being re-assigned later after the end of the switch statement. The assignment is redundant and can be removed. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20241113130807.1386754-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: amd: ps: fix the pcm device numbering for acp 6.3 platformVijendar Mukunda1-0/+2
Fixed PCM device numbering is required for defining common alsa ucm changes for generic soundwire machine driver for legacy(No DSP) stack. Ex: For Headphone playback use case, use PCM device number as 0. For Headset mic Capture use case, PCM device number as 1. Set the 'use_dai_pcm_id' flag true in soundwire dma driver for acp 6.3 platform. This will fix the pcm device numbering based on dai_link->id. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20241113115223.3274868-7-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: amd: acp: add soundwire machine driver for legacy stackVijendar Mukunda4-0/+512
Add SoundWire machine driver for legacy(No DSP) stack for ACP6.3 platform. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20241113115223.3274868-6-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: amd: acp: move get_acp63_cpu_pin_id() to common fileVijendar Mukunda5-48/+76
get_acp63_cpu_pin_id() is the common SoundWire machine driver helper function will be used for AMD Legacy(No DSP) generic SoundWire machine driver as well. Move get_acp63_cpu_pin_id() function to common place holder. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20241113115223.3274868-5-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: amd: ps: add soundwire machines for acp6.3 platformVijendar Mukunda1-0/+1
Add SoundWire machines for acp 6.3 platform for legacy(No DSP) stack. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20241113115223.3274868-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: amd: acp: add RT711, RT714 & RT1316 support for acp 6.3 platformVijendar Mukunda1-0/+5
This patch add supports for corresponding codecs on acp6.3 platform hardware configuration. SDW0: RT711 Jack SDW0: RT1316 Left Speaker SDW0: RT1316 Right Speaker SDW1: RT714 DMIC Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20241113115223.3274868-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-13ASoC: amd: acp: add rt722 based soundwire machinesVijendar Mukunda2-0/+50
Add RT722 based soundwire machines for legacy(NO DSP) stack for acp 6.3 platform. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20241113115223.3274868-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-12ASoC: max9768: Fix event generation for playback muteMark Brown1-2/+9
The max9768 has a custom control for playback mute which unconditionally returns 0 from the put() operation, rather than returning 1 on change to ensure notifications are generated to userspace. Check to see if the value has changed and return appropriately. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20241112-asoc-max9768-event-v1-1-ba5d50599787@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-12ASoC: simple-card-utils: care simple_util_dai for dummy DAIKuninori Morimoto1-0/+6
Simple Card Utils has simple_util_dai which is paired to snd_soc_dai, and assmus that CPU/Codec DAI and its paired simple_util_dai are same order for CPU/Codec simple_util_dai[0] <--> snd_soc_dai[0] simple_util_dai[1] <--> snd_soc_dai[1] ... So, it is using same index in for_each loop. (X) gets simple_util_dai (Y) gets snd_soc_dai (Y) for_each_rtd_cpu_dais(.., i, ..) { (X)(A) udai = simple_props_to_dai_cpu(.., i); } (X) for_each_prop_dai_cpu(.., i, ...) { (Y) dai = snd_soc_rtd_to_cpu(.., i); ... } But current Simple Card Utils didn't have simple_util_dai for dummy DAI. So above (A) will get NULL pointer in such case. This patch cares simple_util_dai for dummy DAI. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87msi5maz3.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-12ASoC: test-component: Support continuous rates for test componentJohn Watts1-1/+1
There's no reason to limit the supported rates of the test component to specific ones as if it's a real piece of hardware. Set the rates to continuous to aid in testing different rates. Signed-off-by: John Watts <contact@jookia.org> Link: https://patch.msgid.link/20241112-alsa_test_rates-v1-1-95cf529db871@jookia.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: max98088: Add headphone mixer switchMarek Vasut1-0/+3
Add enable/disable headphone output mixers knob. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patch.msgid.link/20241111165523.113142-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: max98088: Add left/right DAC volume controlMarek Vasut1-0/+3
Add left/right DAC digital volume control knob. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patch.msgid.link/20241111165435.113086-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoc: SOF: ipc4-pcm: fix uninit-value in sof_ipc4_pcm_dai_link_fixup_rateSuraj Sonawane1-0/+3
Fix an issue detected by the Smatch tool: sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate() error: uninitialized symbol 'be_rate'. The warning highlights a case where `be_rate` could remain uninitialized if `num_input_formats` is zero, which would cause undefined behavior when setting `rate->min` and `rate->max` based on `be_rate`. To address this issue, a `WARN_ON_ONCE(!num_input_formats)` check was added to ensure `num_input_formats` is greater than zero. If this condition fails, the function returns `-EINVAL`, preventing the use of an uninitialized `be_rate`. This change improves the robustness of the function by catching an invalid state early and providing better feedback during development. Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com> Link: https://patch.msgid.link/20241107063609.11627-1-surajsonawane0215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: dt-bindings: stm32: add missing port propertyOlivier Moysan1-0/+4
Add missing port property in STM32 SPDIFRX binding. This will prevent potential warning: Unevaluated properties are not allowed ('port' was unexpected) Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20241105135942.526624-1-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: add symmetric_ prefix for dai->rate/channels/sample_bitsKuninori Morimoto7-25/+26
snd_soc_dai has rate/channels/sample_bits parameter, but it is only valid if symmetry is being enforced by symmetric_xxx flag on driver. It is very difficult to know about it from current naming, and easy to misunderstand it. add symmetric_ prefix for it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87zfmd8bnf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: max98088: Remove duplicate DACsMarek Vasut1-54/+26
This codec only has one set of left and right DACs, remove the duplicate DACs with duplicated bits controlling them as the userspace can set those controls to mismatched value. This most likely does break userspace ABI, but there seem to be no in-kernel users. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patch.msgid.link/20241108235453.196289-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: machine: update documentationanish kumar1-0/+26
1. Added clocking details. 2. Updated ways to register the dai's 3. Bit more detail about card registration details. Signed-off-by: anish kumar <yesanishhere@gmail.com> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://patch.msgid.link/20241109192231.11623-1-yesanishhere@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: intel: sof_sdw: add quirk for Dell SKUDeep Harsora1-0/+8
This patch adds a quirk to include the codec amplifier function for this Dell SKU. Note: In this SKU '0CF1', the RT722 codec amplifier is excluded, and an external amplifier is used instead. Signed-off-by: Deep Harsora <deep_harsora@dell.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20241111070618.5414-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-11ASoC: audio-graph-card2: Purge absent supplies for device tree nodesJohn Watts1-0/+3
The audio graph card doesn't mark its subnodes such as multi {}, dpcm {} and c2c {} as not requiring any suppliers. This causes a hang as Linux waits for these phantom suppliers to show up on boot. Make it clear these nodes have no suppliers. Example error message: [ 15.208558] platform 2034000.i2s: deferred probe pending: platform: wait for supplier /sound/multi [ 15.208584] platform sound: deferred probe pending: asoc-audio-graph-card2: parse error Signed-off-by: John Watts <contact@jookia.org> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/20241108-graph_dt_fix-v1-1-173e2f9603d6@jookia.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-10Linux 6.12-rc7Linus Torvalds1-1/+1
2024-11-10filemap: Fix bounds checking in filemap_read()Trond Myklebust1-1/+1
If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. Reported-by: Mike Snitzer <snitzer@kernel.org> Fixes: c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()") Tested-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-09ASoC: qcom: sm8250: add handling of secondary MI2S clockAlexey Klimov1-0/+8
Add handling of clock related to secondary MI2S_RX in sm8250_snd_startup(). Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://patch.msgid.link/20241018025452.1362293-2-alexey.klimov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not setLiu Peibao2-2/+5
When the Tx FIFO is empty and the last command has no STOP bit set, the master holds SCL low. If I2C_DYNAMIC_TAR_UPDATE is not set, BIT(13) MST_ON_HOLD of IC_RAW_INTR_STAT is not enabled, causing the __i2c_dw_disable() timeout. This is quite similar to commit 2409205acd3c ("i2c: designware: fix __i2c_dw_disable() in case master is holding SCL low"). Also check BIT(7) MST_HOLD_TX_FIFO_EMPTY in IC_STATUS, which is available when IC_STAT_FOR_CLK_STRETCH is set. Fixes: 2409205acd3c ("i2c: designware: fix __i2c_dw_disable() in case master is holding SCL low") Co-developed-by: Xiaowu Ding <xiaowu.ding@jaguarmicro.com> Signed-off-by: Xiaowu Ding <xiaowu.ding@jaguarmicro.com> Co-developed-by: Angus Chen <angus.chen@jaguarmicro.com> Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com> Signed-off-by: Liu Peibao <loven.liu@jaguarmicro.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-08ASoC: Intel: Kconfig: Revert make SND_SOC_ACPI_INTEL_MATCH depend on ACPIPeter Ujfalusi1-2/+1
The acpi-intel-match should be compiled even if ACPI is not selected. The ACPI is not compile time requirement, but the exported symbols are needed for other modules. Fixes: b6bd3f3b6357 ("ASoC: Intel: Kconfig: make SND_SOC_ACPI_INTEL_MATCH depend on ACPI") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202411070806.UhCRpZok-lkp@intel.com/ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20241107100204.24952-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: Intel: Kconfig: Only select SND_SOC_SDCA if ACPI is enabledPeter Ujfalusi1-1/+1
The SDCA module have hard dependency to compile on ACPI, it can only be selected if ACPI is also enabled. The SDCA header provides inline prototypes for other modules to compile in case SND_SOC_SDCA is not enabled. Fixes: 845cb1ddf1fc ("ASoC: Intel: Kconfig: select SND_SOC_SDCA by SND_SOC_ACPI_INTEL_SDCA_QUIRKS") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202411070806.UhCRpZok-lkp@intel.com/ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20241107100204.24952-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: sma1307: Fix invalid logical judgementTang Bin1-3/+0
In the function sma1307_dai_hw_params_amp, the variable 'ret' has not been assigned a value, so the logical judgement is invalid, thus fix it. Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Link: https://patch.msgid.link/20241108011617.2284-1-tangbin@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: mediatek: mt8183: Remove unnecessary variable assignmentsTang Bin1-6/+1
In the function mt8183_dai_i2s_register, the variable 'ret' is redundant, thus remove it. Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Link: https://patch.msgid.link/20241025090938.3480-1-tangbin@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: stm32: i2s: add stm32mp25 supportOlivier Moysan1-22/+189
Add STM32MP25 support for STM32 I2S. On STM32MP25 the I2S driver does not manage I2S kernel clock rate by choosing its parent clock, depending on audio stream rate. The driver requests a rate change on I2S kernel clock instead. It tries to set the higher possible rate, which is a multiple of the audio stream rate and which gives an accuracy of at least 1000 ppm. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20241107144712.1305638-3-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: dt-bindings: add stm32mp25 support for i2sOlivier Moysan1-3/+33
Add STM32MP25 support for STM32 I2S peripheral, through "st,stm32mp25-i2s" compatible. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20241107144712.1305638-2-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: stm32: sai: add stm32mp25 supportOlivier Moysan3-17/+191
Add STM32MP25 support for STM32 SAI. On STM32MP25 the SAI driver does not manage SAI kernel clock rate by chosing its parent clock, dependending on audio stream rate. The driver requests a rate change on SAI kernel clock instead. This rate change is performed with the following guidelines: - Chose highest rate multiple of the audio stream (Try to get clock accuracy within 1000 ppm) - Ensure clock rate compatibility between SAI sub-blocks A&B and between instances sharing the same flexgen. Use clk_rate_exclusive API to fulfill this requirement. The STM32 SAI peripheral does not support the DMA burst mode on STM32MP25. Add a field in compatible structure to manage DMA burst support capability. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20241107155143.1340523-3-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08ASoC: dt-bindings: add stm32mp25 support for saiOlivier Moysan1-1/+25
Add STM32MP25 support for STM32 SAI peripheral, through "st,stm32mp25-sai" compatible. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20241107155143.1340523-2-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-07mailmap: add entry for Thorsten BlumThorsten Blum1-0/+1
Map my previously used email address to my @linux.dev address. Link: https://lkml.kernel.org/r/20241103234411.2522-2-thorsten.blum@linux.dev Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Cc: Alex Elder <elder@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Geliang Tang <geliang@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Mathieu Othacehe <m.othacehe@gmail.com> Cc: Matthieu Baerts (NGI0) <matttbe@kernel.org> Cc: Matt Ranostay <matt@ranostay.sg> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Neeraj Upadhyay <neeraj.upadhyay@kernel.org> Cc: Quentin Monnet <qmo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()Andrew Kanner1-2/+1
Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy. Link: https://lkml.kernel.org/r/20241103193845.2940988-1-andrew.kanner@gmail.com Fixes: 399ff3a748cf ("ocfs2: Handle errors while setting external xattr values.") Signed-off-by: Andrew Kanner <andrew.kanner@gmail.com> Reported-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/671e13ab.050a0220.2b8c0f.01d0.GAE@google.com/T/ Tested-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07signal: restore the override_rlimit logicRoman Gushchin3-4/+8
Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior. Link: https://lkml.kernel.org/r/20241104195419.3962584-1-roman.gushchin@linux.dev Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> Co-developed-by: Andrei Vagin <avagin@google.com> Signed-off-by: Andrei Vagin <avagin@google.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Alexey Gladkov <legion@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07fs/proc: fix compile warning about variable 'vmcore_mmap_ops'Qi Xi1-4/+5
When build with !CONFIG_MMU, the variable 'vmcore_mmap_ops' is defined but not used: >> fs/proc/vmcore.c:458:42: warning: unused variable 'vmcore_mmap_ops' 458 | static const struct vm_operations_struct vmcore_mmap_ops = { Fix this by only defining it when CONFIG_MMU is enabled. Link: https://lkml.kernel.org/r/20241101034803.9298-1-xiqi2@huawei.com Fixes: 9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()") Signed-off-by: Qi Xi <xiqi2@huawei.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/lkml/202410301936.GcE8yUos-lkp@intel.com/ Cc: Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Wang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07ucounts: fix counter leak in inc_rlimit_get_ucounts()Andrei Vagin1-2/+1
The inc_rlimit_get_ucounts() increments the specified rlimit counter and then checks its limit. If the value exceeds the limit, the function returns an error without decrementing the counter. Link: https://lkml.kernel.org/r/20241101191940.3211128-1-roman.gushchin@linux.dev Fixes: 15bc01effefe ("ucounts: Fix signal ucount refcounting") Signed-off-by: Andrei Vagin <avagin@google.com> Co-developed-by: Roman Gushchin <roman.gushchin@linux.dev> Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> Tested-by: Roman Gushchin <roman.gushchin@linux.dev> Acked-by: Alexey Gladkov <legion@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Andrei Vagin <avagin@google.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Alexey Gladkov <legion@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07selftests: hugetlb_dio: check for initial conditions to skip in the startMuhammad Usama Anjum1-7/+12
The test should be skipped if initial conditions aren't fulfilled in the start instead of failing and outputting non-compliant TAP logs. This kind of failure pollutes the results. The initial conditions are: - The test should only execute if /tmp file can be allocated. - The test should only execute if huge pages are free. Before: TAP version 13 1..4 Bail out! Error opening file : Read-only file system (30) # Planned tests != run tests (4 != 0) # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 After: TAP version 13 1..0 # SKIP Unable to allocate file: Read-only file system Link: https://lkml.kernel.org/r/20241101141557.3159432-1-usama.anjum@collabora.com Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Fixes: 3a103b5315b7 ("selftest: mm: Test if hugepage does not get leaked during __bio_release_pages()") Cc: Muhammad Usama Anjum <usama.anjum@collabora.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Donet Tom <donettom@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07mm: fix docs for the kernel parameter ``thp_anon=``Maíra Canal2-2/+2
If we add ``thp_anon=32,64K:always`` to the kernel command line, we will see the following error: [ 0.000000] huge_memory: thp_anon=32,64K:always: error parsing string, ignoring setting This happens because the correct format isn't ``thp_anon=<size>,<size>[KMG]:<state>```, as [KMG] must follow each number to especify its unit. So, the correct format is ``thp_anon=<size>[KMG],<size>[KMG]:<state>```. Therefore, adjust the documentation to reflect the correct format of the parameter ``thp_anon=``. Link: https://lkml.kernel.org/r/20241101165719.1074234-3-mcanal@igalia.com Fixes: dd4d30d1cdbe ("mm: override mTHP "enabled" defaults at kernel cmdline") Signed-off-by: Maíra Canal <mcanal@igalia.com> Acked-by: Barry Song <baohua@kernel.org> Acked-by: David Hildenbrand <david@redhat.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lance Yang <ioworker0@gmail.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07mm/damon/core: avoid overflow in damon_feed_loop_next_input()SeongJae Park1-7/+21
damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation. Link: https://lkml.kernel.org/r/20241031161203.47751-1-sj@kernel.org Fixes: 9294a037c015 ("mm/damon/core: implement goal-oriented feedback-driven quota auto-tuning") Signed-off-by: SeongJae Park <sj@kernel.org> Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/944f3d5b-9177-48e7-8ec9-7f1331a3fea3@roeck-us.net Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: <stable@vger.kernel.org> [6.8.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07mm/damon/core: handle zero schemes apply intervalSeongJae Park1-4/+4
DAMON's logics to determine if this is the time to apply damos schemes assumes next_apply_sis is always set larger than current passed_sample_intervals. And therefore assume continuously incrementing passed_sample_intervals will make it reaches to the next_apply_sis in future. The logic hence does apply the scheme and update next_apply_sis only if passed_sample_intervals is same to next_apply_sis. If Schemes apply interval is set as zero, however, next_apply_sis is set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_apply_sis check. Hence, next_apply_sis becomes larger than next_apply_sis, and the logic says it is not the time to apply schemes and update next_apply_sis. In other words, DAMON stops applying schemes until passed_sample_intervals overflows. Based on the documents and the common sense, a reasonable behavior for such inputs would be applying the schemes for every sampling interval. Handle the case by removing the assumption. Link: https://lkml.kernel.org/r/20241031183757.49610-3-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [6.7.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07mm/damon/core: handle zero {aggregation,ops_update} intervalsSeongJae Park1-3/+3
Patch series "mm/damon/core: fix handling of zero non-sampling intervals". DAMON's internal intervals accounting logic is not correctly handling non-sampling intervals of zero values for a wrong assumption. This could cause unexpected monitoring behavior, and even result in infinite hang of DAMON sysfs interface user threads in case of zero aggregation interval. Fix those by updating the intervals accounting logic. For details of the root case and solutions, please refer to commit messages of fixes. This patch (of 2): DAMON's logics to determine if this is the time to do aggregation and ops update assumes next_{aggregation,ops_update}_sis are always set larger than current passed_sample_intervals. And therefore it further assumes continuously incrementing passed_sample_intervals every sampling interval will make it reaches to the next_{aggregation,ops_update}_sis in future. The logic therefore make the action and update next_{aggregation,ops_updaste}_sis only if passed_sample_intervals is same to the counts, respectively. If Aggregation interval or Ops update interval are zero, however, next_aggregation_sis or next_ops_update_sis are set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_{aggregation,ops_update}_sis check. Hence, passed_sample_intervals becomes larger than next_{aggregation,ops_update}_sis, and the logic says it is not the time to do the action and update next_{aggregation,ops_update}_sis forever, until an overflow happens. In other words, DAMON stops doing aggregations or ops updates effectively forever, and users cannot get monitoring results. Based on the documents and the common sense, a reasonable behavior for such inputs is doing an aggregation and an ops update for every sampling interval. Handle the case by removing the assumption. Note that this could incur particular real issue for DAMON sysfs interface users, in case of zero Aggregation interval. When user starts DAMON with zero Aggregation interval and asks online DAMON parameter tuning via DAMON sysfs interface, the request is handled by the aggregation callback. Until the callback finishes the work, the user who requested the online tuning just waits. Hence, the user will be stuck until the passed_sample_intervals overflows. Link: https://lkml.kernel.org/r/20241031183757.49610-1-sj@kernel.org Link: https://lkml.kernel.org/r/20241031183757.49610-2-sj@kernel.org Fixes: 4472edf63d66 ("mm/damon/core: use number of passed access sampling as a timer") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [6.7.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07mm/mlock: set the correct prev on failureWei Yang1-3/+6
After commit 94d7d9233951 ("mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al."), if vma_modify_flags() return error, the vma is set to an error code. This will lead to an invalid prev be returned. Generally this shouldn't matter as the caller should treat an error as indicating state is now invalidated, however unfortunately apply_mlockall_flags() does not check for errors and assumes that mlock_fixup() correctly maintains prev even if an error were to occur. This patch fixes that assumption. [lorenzo.stoakes@oracle.com: provide a better fix and rephrase the log] Link: https://lkml.kernel.org/r/20241027123321.19511-1-richard.weiyang@gmail.com Fixes: 94d7d9233951 ("mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al.") Signed-off-by: Wei Yang <richard.weiyang@gmail.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07objpool: fix to make percpu slot allocation more robustMasami Hiramatsu (Google)1-6/+12
Since gfp & GFP_ATOMIC == GFP_ATOMIC is true for GFP_KERNEL | GFP_HIGH, it will use kmalloc if user specifies that combination. Here the reason why combining the __vmalloc_node() and kmalloc_node() is that the vmalloc does not support all GFP flag, especially GFP_ATOMIC. So we should check if gfp & (GFP_ATOMIC | GFP_KERNEL) != GFP_ATOMIC for vmalloc first. This ensures caller can sleep. And for the robustness, even if vmalloc fails, it should retry with kmalloc to allocate it. Link: https://lkml.kernel.org/r/173008598713.1262174.2959179484209897252.stgit@mhiramat.roam.corp.google.com Fixes: aff1871bfc81 ("objpool: fix choosing allocation for percpu slots") Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Closes: https://lore.kernel.org/all/CAHk-=whO+vSH+XVRio8byJU8idAWES0SPGVZ7KAVdc4qrV0VUA@mail.gmail.com/ Cc: Leo Yan <leo.yan@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Wu <wuqiang.matt@bytedance.com> Cc: Mikel Rychliski <mikel@mikelr.com> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Cc: Viktor Malik <vmalik@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07mm/page_alloc: keep track of free highatomicYu Zhao2-3/+8
OOM kills due to vastly overestimated free highatomic reserves were observed: ... invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0 ... Node 0 Normal free:1482936kB boost:0kB min:410416kB low:739404kB high:1068392kB reserved_highatomic:1073152KB ... Node 0 Normal: 1292*4kB (ME) 1920*8kB (E) 383*16kB (UE) 220*32kB (ME) 340*64kB (E) 2155*128kB (UE) 3243*256kB (UE) 615*512kB (U) 1*1024kB (M) 0*2048kB 0*4096kB = 1477408kB The second line above shows that the OOM kill was due to the following condition: free (1482936kB) - reserved_highatomic (1073152kB) = 409784KB < min (410416kB) And the third line shows there were no free pages in any MIGRATE_HIGHATOMIC pageblocks, which otherwise would show up as type 'H'. Therefore __zone_watermark_unusable_free() underestimated the usable free memory by over 1GB, which resulted in the unnecessary OOM kill above. The comments in __zone_watermark_unusable_free() warns about the potential risk, i.e., If the caller does not have rights to reserves below the min watermark then subtract the high-atomic reserves. This will over-estimate the size of the atomic reserve but it avoids a search. However, it is possible to keep track of free pages in reserved highatomic pageblocks with a new per-zone counter nr_free_highatomic protected by the zone lock, to avoid a search when calculating the usable free memory. And the cost would be minimal, i.e., simple arithmetics in the highatomic alloc/free/move paths. Note that since nr_free_highatomic can be relatively small, using a per-cpu counter might cause too much drift and defeat its purpose, in addition to the extra memory overhead. Dependson e0932b6c1f94 ("mm: page_alloc: consolidate free page accounting") - see [1] [akpm@linux-foundation.org: s/if/else if/, per Johannes, stealth whitespace tweak] Link: https://lkml.kernel.org/r/20241028182653.3420139-1-yuzhao@google.com Link: https://lkml.kernel.org/r/0d0ddb33-fcdc-43e2-801f-0c1df2031afb@suse.cz [1] Fixes: 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand") Signed-off-by: Yu Zhao <yuzhao@google.com> Reported-by: Link Lin <linkl@google.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-11-07bcachefs: Fix UAF in __promote_alloc() error pathKent Overstreet1-1/+2
If we error in data_update_init() after adding to the rhashtable of outstanding promotes, kfree_rcu() is required. Reported-by: Reed Riley <reed@riley.engineer> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>