March 2024 - Linux-stable-mirror

[merged mm-hotfixes-stable] mm-cachestat-fix-two-shmem-bugs.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: cachestat: fix two shmem bugs has been removed from the -mm tree. Its filename was mm-cachestat-fix-two-shmem-bugs.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Johannes Weiner <hannes(a)cmpxchg.org> Subject: mm: cachestat: fix two shmem bugs Date: Fri, 15 Mar 2024 05:55:56 -0400 When cachestat on shmem races with swapping and invalidation, there are two possible bugs: 1) A swapin error can have resulted in a poisoned swap entry in the shmem inode's xarray. Calling get_shadow_from_swap_cache() on it will result in an out-of-bounds access to swapper_spaces[]. Validate the entry with non_swap_entry() before going further. 2) When we find a valid swap entry in the shmem's inode, the shadow entry in the swapcache might not exist yet: swap IO is still in progress and we're before __remove_mapping; swapin, invalidation, or swapoff have removed the shadow from swapcache after we saw the shmem swap entry. This will send a NULL to workingset_test_recent(). The latter purely operates on pointer bits, so it won't crash - node 0, memcg ID 0, eviction timestamp 0, etc. are all valid inputs - but it's a bogus test. In theory that could result in a false "recently evicted" count. Such a false positive wouldn't be the end of the world. But for code clarity and (future) robustness, be explicit about this case. Bail on get_shadow_from_swap_cache() returning NULL. Link: https://lkml.kernel.org/r/20240315095556.GC581298@cmpxchg.org Fixes: cf264e1329fb ("cachestat: implement cachestat syscall") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reported-by: Chengming Zhou <chengming.zhou(a)linux.dev> [Bug #1] Reported-by: Jann Horn <jannh(a)google.com> [Bug #2] Reviewed-by: Chengming Zhou <chengming.zhou(a)linux.dev> Reviewed-by: Nhat Pham <nphamcs(a)gmail.com> Cc: <stable(a)vger.kernel.org> [v6.5+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/filemap.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/mm/filemap.c~mm-cachestat-fix-two-shmem-bugs +++ a/mm/filemap.c @@ -4197,7 +4197,23 @@ static void filemap_cachestat(struct add /* shmem file - in swap cache */ swp_entry_t swp = radix_to_swp_entry(folio); + /* swapin error results in poisoned entry */ + if (non_swap_entry(swp)) + goto resched; + + /* + * Getting a swap entry from the shmem + * inode means we beat + * shmem_unuse(). rcu_read_lock() + * ensures swapoff waits for us before + * freeing the swapper space. However, + * we can race with swapping and + * invalidation, so there might not be + * a shadow in the swapcache (yet). + */ shadow = get_shadow_from_swap_cache(swp); + if (!shadow) + goto resched; } #endif if (workingset_test_recent(shadow, true, &workingset)) _ Patches currently in -mm which might be from hannes(a)cmpxchg.org are mm-zswap-optimize-zswap-pool-size-tracking.patch mm-zpool-return-pool-size-in-pages.patch mm-page_alloc-remove-pcppage-migratetype-caching.patch mm-page_alloc-optimize-free_unref_folios.patch mm-page_alloc-fix-up-block-types-when-merging-compatible-blocks.patch mm-page_alloc-move-free-pages-when-converting-block-during-isolation.patch mm-page_alloc-fix-move_freepages_block-range-error.patch mm-page_alloc-fix-freelist-movement-during-block-conversion.patch mm-page_alloc-close-migratetype-race-between-freeing-and-stealing.patch mm-page_isolation-prepare-for-hygienic-freelists.patch mm-page_isolation-prepare-for-hygienic-freelists-fix.patch mm-page_alloc-consolidate-free-page-accounting.patch

9 months, 2 weeks

1
0
0 0

[merged mm-hotfixes-stable] init-open-initrdimage-with-o_largefile.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: init: open /initrd.image with O_LARGEFILE has been removed from the -mm tree. Its filename was init-open-initrdimage-with-o_largefile.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: John Sperbeck <jsperbeck(a)google.com> Subject: init: open /initrd.image with O_LARGEFILE Date: Sun, 17 Mar 2024 15:15:22 -0700 If initrd data is larger than 2Gb, we'll eventually fail to write to the /initrd.image file when we hit that limit, unless O_LARGEFILE is set. Link: https://lkml.kernel.org/r/20240317221522.896040-1-jsperbeck@google.com Signed-off-by: John Sperbeck <jsperbeck(a)google.com> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- init/initramfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/init/initramfs.c~init-open-initrdimage-with-o_largefile +++ a/init/initramfs.c @@ -682,7 +682,7 @@ static void __init populate_initrd_image printk(KERN_INFO "rootfs image is not initramfs (%s); looks like an initrd\n", err); - file = filp_open("/initrd.image", O_WRONLY | O_CREAT, 0700); + file = filp_open("/initrd.image", O_WRONLY|O_CREAT|O_LARGEFILE, 0700); if (IS_ERR(file)) return; _ Patches currently in -mm which might be from jsperbeck(a)google.com are

9 months, 2 weeks

1
0
0 0

[PATCH v2 2/4] ALSA: hda/tas2781: add locks to kcontrols

by Gergo Koteles

The rcabin.profile_cfg_id, cur_prog, cur_conf, force_fwload_status variables are acccessible from multiple threads and therefore require locking. Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") CC: stable(a)vger.kernel.org Signed-off-by: Gergo Koteles <soyer(a)irl.hu> --- sound/pci/hda/tas2781_hda_i2c.c | 50 +++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/tas2781_hda_i2c.c b/sound/pci/hda/tas2781_hda_i2c.c index 5acb475c10a7..9a43f563bb9e 100644 --- a/sound/pci/hda/tas2781_hda_i2c.c +++ b/sound/pci/hda/tas2781_hda_i2c.c @@ -185,8 +185,12 @@ static int tasdevice_get_profile_id(struct snd_kcontrol *kcontrol, { struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); + mutex_lock(&tas_priv->codec_lock); + ucontrol->value.integer.value[0] = tas_priv->rcabin.profile_cfg_id; + mutex_unlock(&tas_priv->codec_lock); + return 0; } @@ -200,11 +204,15 @@ static int tasdevice_set_profile_id(struct snd_kcontrol *kcontrol, val = clamp(nr_profile, 0, max); + mutex_lock(&tas_priv->codec_lock); + if (tas_priv->rcabin.profile_cfg_id != val) { tas_priv->rcabin.profile_cfg_id = val; ret = 1; } + mutex_unlock(&tas_priv->codec_lock); + return ret; } @@ -241,8 +249,12 @@ static int tasdevice_program_get(struct snd_kcontrol *kcontrol, { struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); + mutex_lock(&tas_priv->codec_lock); + ucontrol->value.integer.value[0] = tas_priv->cur_prog; + mutex_unlock(&tas_priv->codec_lock); + return 0; } @@ -257,11 +269,15 @@ static int tasdevice_program_put(struct snd_kcontrol *kcontrol, val = clamp(nr_program, 0, max); + mutex_lock(&tas_priv->codec_lock); + if (tas_priv->cur_prog != val) { tas_priv->cur_prog = val; ret = 1; } + mutex_unlock(&tas_priv->codec_lock); + return ret; } @@ -270,8 +286,12 @@ static int tasdevice_config_get(struct snd_kcontrol *kcontrol, { struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); + mutex_lock(&tas_priv->codec_lock); + ucontrol->value.integer.value[0] = tas_priv->cur_conf; + mutex_unlock(&tas_priv->codec_lock); + return 0; } @@ -286,11 +306,15 @@ static int tasdevice_config_put(struct snd_kcontrol *kcontrol, val = clamp(nr_config, 0, max); + mutex_lock(&tas_priv->codec_lock); + if (tas_priv->cur_conf != val) { tas_priv->cur_conf = val; ret = 1; } + mutex_unlock(&tas_priv->codec_lock); + return ret; } @@ -300,8 +324,15 @@ static int tas2781_amp_getvol(struct snd_kcontrol *kcontrol, struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); struct soc_mixer_control *mc = (struct soc_mixer_control *)kcontrol->private_value; + int ret; + + mutex_lock(&tas_priv->codec_lock); + + ret = tasdevice_amp_getvol(tas_priv, ucontrol, mc); + + mutex_unlock(&tas_priv->codec_lock); - return tasdevice_amp_getvol(tas_priv, ucontrol, mc); + return ret; } static int tas2781_amp_putvol(struct snd_kcontrol *kcontrol, @@ -310,9 +341,16 @@ static int tas2781_amp_putvol(struct snd_kcontrol *kcontrol, struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); struct soc_mixer_control *mc = (struct soc_mixer_control *)kcontrol->private_value; + int ret; + + mutex_lock(&tas_priv->codec_lock); /* The check of the given value is in tasdevice_amp_putvol. */ - return tasdevice_amp_putvol(tas_priv, ucontrol, mc); + ret = tasdevice_amp_putvol(tas_priv, ucontrol, mc); + + mutex_unlock(&tas_priv->codec_lock); + + return ret; } static int tas2781_force_fwload_get(struct snd_kcontrol *kcontrol, @@ -320,10 +358,14 @@ static int tas2781_force_fwload_get(struct snd_kcontrol *kcontrol, { struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); + mutex_lock(&tas_priv->codec_lock); + ucontrol->value.integer.value[0] = (int)tas_priv->force_fwload_status; dev_dbg(tas_priv->dev, "%s : Force FWload %s\n", __func__, tas_priv->force_fwload_status ? "ON" : "OFF"); + mutex_unlock(&tas_priv->codec_lock); + return 0; } @@ -333,6 +375,8 @@ static int tas2781_force_fwload_put(struct snd_kcontrol *kcontrol, struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); bool change, val = (bool)ucontrol->value.integer.value[0]; + mutex_lock(&tas_priv->codec_lock); + if (tas_priv->force_fwload_status == val) change = false; else { @@ -342,6 +386,8 @@ static int tas2781_force_fwload_put(struct snd_kcontrol *kcontrol, dev_dbg(tas_priv->dev, "%s : Force FWload %s\n", __func__, tas_priv->force_fwload_status ? "ON" : "OFF"); + mutex_unlock(&tas_priv->codec_lock); + return change; } -- 2.44.0

9 months, 2 weeks

1
0
0 0

[PATCH v2 1/4] ALSA: hda/tas2781: remove digital gain kcontrol

by Gergo Koteles

The "Speaker Digital Gain" kcontrol controls the TAS2781_DVC_LVL (0x1A) register. Unfortunately the tas2563 does not have DVC_LVL, but has INT_MASK0 in 0x1A, which has been misused so far. Since commit c1947ce61ff4 ("ALSA: hda/realtek: tas2781: enable subwoofer volume control") the volume of the tas2781 amplifiers can be controlled by the master volume, so this digital gain kcontrol is not needed. Remove it. Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") CC: stable(a)vger.kernel.org Signed-off-by: Gergo Koteles <soyer(a)irl.hu> --- sound/pci/hda/tas2781_hda_i2c.c | 37 +-------------------------------- 1 file changed, 1 insertion(+), 36 deletions(-) diff --git a/sound/pci/hda/tas2781_hda_i2c.c b/sound/pci/hda/tas2781_hda_i2c.c index 4475cea8e9f7..5acb475c10a7 100644 --- a/sound/pci/hda/tas2781_hda_i2c.c +++ b/sound/pci/hda/tas2781_hda_i2c.c @@ -89,7 +89,7 @@ struct tas2781_hda { struct snd_kcontrol *dsp_prog_ctl; struct snd_kcontrol *dsp_conf_ctl; struct snd_kcontrol *prof_ctl; - struct snd_kcontrol *snd_ctls[3]; + struct snd_kcontrol *snd_ctls[2]; }; static int tas2781_get_i2c_res(struct acpi_resource *ares, void *data) @@ -294,27 +294,6 @@ static int tasdevice_config_put(struct snd_kcontrol *kcontrol, return ret; } -/* - * tas2781_digital_getvol - get the volum control - * @kcontrol: control pointer - * @ucontrol: User data - * Customer Kcontrol for tas2781 is primarily for regmap booking, paging - * depends on internal regmap mechanism. - * tas2781 contains book and page two-level register map, especially - * book switching will set the register BXXP00R7F, after switching to the - * correct book, then leverage the mechanism for paging to access the - * register. - */ -static int tas2781_digital_getvol(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol) -{ - struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); - struct soc_mixer_control *mc = - (struct soc_mixer_control *)kcontrol->private_value; - - return tasdevice_digital_getvol(tas_priv, ucontrol, mc); -} - static int tas2781_amp_getvol(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -325,17 +304,6 @@ static int tas2781_amp_getvol(struct snd_kcontrol *kcontrol, return tasdevice_amp_getvol(tas_priv, ucontrol, mc); } -static int tas2781_digital_putvol(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol) -{ - struct tasdevice_priv *tas_priv = snd_kcontrol_chip(kcontrol); - struct soc_mixer_control *mc = - (struct soc_mixer_control *)kcontrol->private_value; - - /* The check of the given value is in tasdevice_digital_putvol. */ - return tasdevice_digital_putvol(tas_priv, ucontrol, mc); -} - static int tas2781_amp_putvol(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -381,9 +349,6 @@ static const struct snd_kcontrol_new tas2781_snd_controls[] = { ACARD_SINGLE_RANGE_EXT_TLV("Speaker Analog Gain", TAS2781_AMP_LEVEL, 1, 0, 20, 0, tas2781_amp_getvol, tas2781_amp_putvol, amp_vol_tlv), - ACARD_SINGLE_RANGE_EXT_TLV("Speaker Digital Gain", TAS2781_DVC_LVL, - 0, 0, 200, 1, tas2781_digital_getvol, - tas2781_digital_putvol, dvc_tlv), ACARD_SINGLE_BOOL_EXT("Speaker Force Firmware Load", 0, tas2781_force_fwload_get, tas2781_force_fwload_put), }; -- 2.44.0

9 months, 2 weeks

1
0
0 0

[PATCH v2 1/3] mm/secretmem: fix GUP-fast succeeding on secretmem folios

by David Hildenbrand

folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- include/linux/secretmem.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h index 35f3a4a8ceb1..acf7e1a3f3de 100644 --- a/include/linux/secretmem.h +++ b/include/linux/secretmem.h @@ -13,10 +13,10 @@ static inline bool folio_is_secretmem(struct folio *folio) /* * Using folio_mapping() is quite slow because of the actual call * instruction. - * We know that secretmem pages are not compound and LRU so we can + * We know that secretmem pages are not compound, so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio)) return false; mapping = (struct address_space *) -- 2.43.2

9 months, 2 weeks

2
1
0 0

[PATCH v1] usb: typec: tcpm: Correct the PDO counting in pd_set

by Kyle Tso

The index in the loop has already been added one and is equal to the number of PDOs to be updated when leaving the loop. Fixes: cd099cde4ed2 ("usb: typec: tcpm: Support multiple capabilities") Cc: stable(a)vger.kernel.org Signed-off-by: Kyle Tso <kyletso(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 3d505614bff1..566dad0cb9d3 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -6852,14 +6852,14 @@ static int tcpm_pd_set(struct typec_port *p, struct usb_power_delivery *pd) if (data->sink_desc.pdo[0]) { for (i = 0; i < PDO_MAX_OBJECTS && data->sink_desc.pdo[i]; i++) port->snk_pdo[i] = data->sink_desc.pdo[i]; - port->nr_snk_pdo = i + 1; + port->nr_snk_pdo = i; port->operating_snk_mw = data->operating_snk_mw; } if (data->source_desc.pdo[0]) { for (i = 0; i < PDO_MAX_OBJECTS && data->source_desc.pdo[i]; i++) port->snk_pdo[i] = data->source_desc.pdo[i]; - port->nr_src_pdo = i + 1; + port->nr_src_pdo = i; } switch (port->state) { -- 2.44.0.291.gc1ea87d7ee-goog

9 months, 2 weeks

2
2
0 0

[PATCH 00/17] ASoC: SOF: ipc4/Intel: Fix delay reporting (for 6.9 / 6.8)

by Peter Ujfalusi

Hi, The current version of delay reporting code can report incorrect values when paired with a firmware which enables this feature. Unfortunately there are several smaller issues that needed to be addressed to correct the behavior: Wrong information was used for the host side of counter For MTL/LNL used incorrect (in a sense that it was verified only on MTL) link side counter function. The link side counter needs compensation logic if pause/resume is used. The offset values were not refreshed from firmware. Finally, not strictly connected, but the ALSA buffer size needs to be constrained to avoid constant xrun from media players (like mpv) The series applies cleanly for 6.9 and 6.8.y stable, but older stable would need manual backport, but it is questionable if it is needed as MTL/LNL is missing features. Mark, can you pick these patches for the 6.9 cycle as fixes? Regards, Peter --- Peter Ujfalusi (17): ASoC: SOF: Add dsp_max_burst_size_in_ms member to snd_sof_pcm_stream ASoC: SOF: ipc4-topology: Save the DMA maximum burst size for PCMs ASoC: SOF: Intel: hda-pcm: Use dsp_max_burst_size_in_ms to place constraint ASoC: SOF: Intel: hda: Implement get_stream_position (Linear Link Position) ASoC: SOF: Intel: mtl/lnl: Use the generic get_stream_position callback ASoC: SOF: Introduce a new callback pair to be used for PCM delay reporting ASoC: SOF: Intel: Set the dai/host get frame/byte counter callbacks ASoC: SOF: ipc4-pcm: Use the snd_sof_pcm_get_dai_frame_counter() for pcm_delay ASoC: SOF: Intel: hda-common-ops: Do not set the get_stream_position callback ASoC: SOF: Remove the get_stream_position callback ASoC: SOF: ipc4-pcm: Move struct sof_ipc4_timestamp_info definition locally ASoC: SOF: ipc4-pcm: Combine the SOF_IPC4_PIPE_PAUSED cases in pcm_trigger ASoC: SOF: ipc4-pcm: Invalidate the stream_start_offset in PAUSED state ASoC: SOF: sof-pcm: Add pointer callback to sof_ipc_pcm_ops ASoC: SOF: ipc4-pcm: Correct the delay calculation ALSA: hda: Add pplcllpl/u members to hdac_ext_stream ASoC: SOF: Intel: hda: Compensate LLP in case it is not reset include/sound/hdaudio_ext.h | 3 + sound/soc/sof/intel/hda-common-ops.c | 3 + sound/soc/sof/intel/hda-dai-ops.c | 11 ++ sound/soc/sof/intel/hda-pcm.c | 29 ++++ sound/soc/sof/intel/hda-stream.c | 70 ++++++++++ sound/soc/sof/intel/hda.h | 6 + sound/soc/sof/intel/lnl.c | 2 - sound/soc/sof/intel/mtl.c | 14 -- sound/soc/sof/intel/mtl.h | 10 -- sound/soc/sof/ipc4-pcm.c | 191 ++++++++++++++++++++++----- sound/soc/sof/ipc4-priv.h | 14 -- sound/soc/sof/ipc4-topology.c | 22 ++- sound/soc/sof/ops.h | 24 +++- sound/soc/sof/pcm.c | 8 ++ sound/soc/sof/sof-audio.h | 9 +- sound/soc/sof/sof-priv.h | 24 +++- 16 files changed, 351 insertions(+), 89 deletions(-) -- 2.44.0

9 months, 2 weeks

2
18
0 0

[PATCH v1 1/3] mm/secretmem: fix GUP-fast succeeding on secretmem folios

by David Hildenbrand

folio_is_secretmem() states that secretmem folios cannot be LRU folios: so we may only exit early if we find an LRU folio. Yet, we exit early if we find a folio that is not a secretmem folio. Consequently, folio_is_secretmem() fails to detect secretmem folios and, therefore, we can succeed in grabbing a secretmem folio during GUP-fast, crashing the kernel when we later try reading/writing to the folio, because the folio has been unmapped from the directmap. Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- include/linux/secretmem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h index 35f3a4a8ceb1..6996f1f53f14 100644 --- a/include/linux/secretmem.h +++ b/include/linux/secretmem.h @@ -16,7 +16,7 @@ static inline bool folio_is_secretmem(struct folio *folio) * We know that secretmem pages are not compound and LRU so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio) || folio_test_lru(folio)) return false; mapping = (struct address_space *) -- 2.43.2

9 months, 2 weeks

2
2
0 0

[PATCH] drm/i915: Pre-populate the cursor physical dma address

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Calling i915_gem_object_get_dma_address() from the vblank evade critical section triggers might_sleep(). While we know that we've already pinned the framebuffer and thus i915_gem_object_get_dma_address() will in fact not sleep in this case, it seems reasonable to keep the unconditional might_sleep() for maximum coverage. So let's instead pre-populate the dma address during fb pinning, which all happens before we enter the vblank evade critical section. We can use u32 for the dma address as this class of hardware doesn't support >32bit addresses. Cc: stable(a)vger.kernel.org Fixes: 0225a90981c8 ("drm/i915: Make cursor plane registers unlocked") Link: https://lore.kernel.org/intel-gfx/20240227100342.GAZd2zfmYcPS_SndtO@fat_cra… Reported-by: Borislav Petkov <bp(a)alien8.de> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/display/intel_cursor.c | 4 +--- drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_fb_pin.c | 10 ++++++++++ 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c index f8b33999d43f..0d3da55e1c24 100644 --- a/drivers/gpu/drm/i915/display/intel_cursor.c +++ b/drivers/gpu/drm/i915/display/intel_cursor.c @@ -36,12 +36,10 @@ static u32 intel_cursor_base(const struct intel_plane_state *plane_state) { struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev); - const struct drm_framebuffer *fb = plane_state->hw.fb; - struct drm_i915_gem_object *obj = intel_fb_obj(fb); u32 base; if (DISPLAY_INFO(dev_priv)->cursor_needs_physical) - base = i915_gem_object_get_dma_address(obj, 0); + base = plane_state->phys_dma_addr; else base = intel_plane_ggtt_offset(plane_state); diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 8a35fb6b2ade..68f26a33870b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -728,6 +728,7 @@ struct intel_plane_state { #define PLANE_HAS_FENCE BIT(0) struct intel_fb_view view; + u32 phys_dma_addr; /* for cursor_needs_physical */ /* Plane pxp decryption state */ bool decrypt; diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c b/drivers/gpu/drm/i915/display/intel_fb_pin.c index 7b42aef37d2f..b6df9baf481b 100644 --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c @@ -255,6 +255,16 @@ int intel_plane_pin_fb(struct intel_plane_state *plane_state) return PTR_ERR(vma); plane_state->ggtt_vma = vma; + + /* + * Pre-populate the dma address before we enter the vblank + * evade critical section as i915_gem_object_get_dma_address() + * will trigger might_sleep() even if it won't actually sleep, + * which is the case when the fb has already been pinned. + */ + if (phys_cursor) + plane_state->phys_dma_addr = + i915_gem_object_get_dma_address(intel_fb_obj(fb), 0); } else { struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); -- 2.43.2

9 months, 2 weeks

4
5
0 0

[PATCH 0/7] usb: typec: ucsi: fix several issues manifesting on Qualcomm platforms

by Dmitry Baryshkov

Fix several issues discovered while debugging UCSI implementation on Qualcomm platforms (ucsi_glink). With these patches I was able to get a working Type-C port managament implementation. Tested on SC8280XP (Lenovo X13s laptop) and SM8350-HDK. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- Dmitry Baryshkov (7): usb: typec: ucsi: fix race condition in connection change ACK'ing usb: typec: ucsi: acknowledge the UCSI_CCI_NOT_SUPPORTED usb: typec: ucsi: make ACK_CC_CI rules more obvious usb: typec: ucsi: allow non-partner GET_PDOS for Qualcomm devices usb: typec: ucsi: limit the UCSI_NO_PARTNER_PDOS even further usb: typec: ucsi: properly register partner's PD device soc: qcom: pmic_glink: reenable UCSI on sc8280xp drivers/soc/qcom/pmic_glink.c | 1 - drivers/usb/typec/ucsi/ucsi.c | 51 +++++++++++++++++++++++++++++++++---------- 2 files changed, 39 insertions(+), 13 deletions(-) --- base-commit: ea86f16f605361af3779af0e0b4be18614282091 change-id: 20240312-qcom-ucsi-fixes-6578d236b60b Best regards, -- Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>

9 months, 2 weeks

3
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024