July 2024 - Linux-stable-mirror

[PATCH AUTOSEL 5.10 1/4] spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ] While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective device trees don't add DMA channels. The Reference manuals of i.MX31 and i.MX25 also don't mention the CSPI core being DMA capable. (I didn't check the others.) Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed DMA channel requests") this results in an error message spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel! during boot. However that isn't fatal and the driver gets loaded just fine, just without using DMA. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutron… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 21297cc62571a..8566da12d15e3 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1001,7 +1001,7 @@ static struct spi_imx_devtype_data imx35_cspi_devtype_data = { .rx_available = mx31_rx_available, .reset = mx31_reset, .fifo_size = 8, - .has_dmamode = true, + .has_dmamode = false, .dynamic_burst = false, .has_slavemode = false, .devtype = IMX35_CSPI, -- 2.43.0

5 months, 3 weeks

1
3
0 0

[PATCH AUTOSEL 5.15 1/4] spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ] While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective device trees don't add DMA channels. The Reference manuals of i.MX31 and i.MX25 also don't mention the CSPI core being DMA capable. (I didn't check the others.) Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed DMA channel requests") this results in an error message spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel! during boot. However that isn't fatal and the driver gets loaded just fine, just without using DMA. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutron… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index f201653931d89..c806ee8070e5a 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1016,7 +1016,7 @@ static struct spi_imx_devtype_data imx35_cspi_devtype_data = { .rx_available = mx31_rx_available, .reset = mx31_reset, .fifo_size = 8, - .has_dmamode = true, + .has_dmamode = false, .dynamic_burst = false, .has_slavemode = false, .devtype = IMX35_CSPI, -- 2.43.0

5 months, 3 weeks

1
3
0 0

[PATCH AUTOSEL 6.1 1/5] spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ] While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective device trees don't add DMA channels. The Reference manuals of i.MX31 and i.MX25 also don't mention the CSPI core being DMA capable. (I didn't check the others.) Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed DMA channel requests") this results in an error message spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel! during boot. However that isn't fatal and the driver gets loaded just fine, just without using DMA. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutron… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 2c660a95c17e7..93e83fbc3403f 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1040,7 +1040,7 @@ static struct spi_imx_devtype_data imx35_cspi_devtype_data = { .rx_available = mx31_rx_available, .reset = mx31_reset, .fifo_size = 8, - .has_dmamode = true, + .has_dmamode = false, .dynamic_burst = false, .has_slavemode = false, .devtype = IMX35_CSPI, -- 2.43.0

5 months, 3 weeks

1
4
0 0

[PATCH AUTOSEL 6.6 1/8] spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ] While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective device trees don't add DMA channels. The Reference manuals of i.MX31 and i.MX25 also don't mention the CSPI core being DMA capable. (I didn't check the others.) Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed DMA channel requests") this results in an error message spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel! during boot. However that isn't fatal and the driver gets loaded just fine, just without using DMA. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutron… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index d323b37723929..006860ee03ca0 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1050,7 +1050,7 @@ static struct spi_imx_devtype_data imx35_cspi_devtype_data = { .rx_available = mx31_rx_available, .reset = mx31_reset, .fifo_size = 8, - .has_dmamode = true, + .has_dmamode = false, .dynamic_burst = false, .has_targetmode = false, .devtype = IMX35_CSPI, -- 2.43.0

5 months, 3 weeks

1
7
0 0

[PATCH AUTOSEL 6.9 01/11] spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ] While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective device trees don't add DMA channels. The Reference manuals of i.MX31 and i.MX25 also don't mention the CSPI core being DMA capable. (I didn't check the others.) Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed DMA channel requests") this results in an error message spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel! during boot. However that isn't fatal and the driver gets loaded just fine, just without using DMA. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutron… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 09b6c1b45f1a1..09c676e50fe0e 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1050,7 +1050,7 @@ static struct spi_imx_devtype_data imx35_cspi_devtype_data = { .rx_available = mx31_rx_available, .reset = mx31_reset, .fifo_size = 8, - .has_dmamode = true, + .has_dmamode = false, .dynamic_burst = false, .has_targetmode = false, .devtype = IMX35_CSPI, -- 2.43.0

5 months, 3 weeks

1
10
0 0

FAILED: patch "[PATCH] mm/damon/core: merge regions aggressively when max_nr_regions" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024071547-slum-anemic-a0cc@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6 Mon Sep 17 00:00:00 2001 From: SeongJae Park <sj(a)kernel.org> Date: Mon, 24 Jun 2024 10:58:14 -0700 Subject: [PATCH] mm/damon/core: merge regions aggressively when max_nr_regions is unmet DAMON keeps the number of regions under max_nr_regions by skipping regions split operations when doing so can make the number higher than the limit. It works well for preventing violation of the limit. But, if somehow the violation happens, it cannot recovery well depending on the situation. In detail, if the real number of regions having different access pattern is higher than the limit, the mechanism cannot reduce the number below the limit. In such a case, the system could suffer from high monitoring overhead of DAMON. The violation can actually happen. For an example, the user could reduce max_nr_regions while DAMON is running, to be lower than the current number of regions. Fix the problem by repeating the merge operations with increasing aggressiveness in kdamond_merge_regions() for the case, until the limit is met. [sj(a)kernel.org: increase regions merge aggressiveness while respecting min_nr_regions] Link: https://lkml.kernel.org/r/20240626164753.46270-1-sj@kernel.org [sj(a)kernel.org: ensure max threshold attempt for max_nr_regions violation] Link: https://lkml.kernel.org/r/20240627163153.75969-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240624175814.89611-1-sj@kernel.org Fixes: b9a6ac4e4ede ("mm/damon: adaptively adjust regions") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [5.15+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/damon/core.c b/mm/damon/core.c index 6392f1cc97a3..e66823d6b10b 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -1358,14 +1358,31 @@ static void damon_merge_regions_of(struct damon_target *t, unsigned int thres, * access frequencies are similar. This is for minimizing the monitoring * overhead under the dynamically changeable access pattern. If a merge was * unnecessarily made, later 'kdamond_split_regions()' will revert it. + * + * The total number of regions could be higher than the user-defined limit, + * max_nr_regions for some cases. For example, the user can update + * max_nr_regions to a number that lower than the current number of regions + * while DAMON is running. For such a case, repeat merging until the limit is + * met while increasing @threshold up to possible maximum level. */ static void kdamond_merge_regions(struct damon_ctx *c, unsigned int threshold, unsigned long sz_limit) { struct damon_target *t; + unsigned int nr_regions; + unsigned int max_thres; - damon_for_each_target(t, c) - damon_merge_regions_of(t, threshold, sz_limit); + max_thres = c->attrs.aggr_interval / + (c->attrs.sample_interval ? c->attrs.sample_interval : 1); + do { + nr_regions = 0; + damon_for_each_target(t, c) { + damon_merge_regions_of(t, threshold, sz_limit); + nr_regions += damon_nr_regions(t); + } + threshold = max(1, threshold * 2); + } while (nr_regions > c->attrs.max_nr_regions && + threshold / 2 < max_thres); } /*

5 months, 3 weeks

3
5
0 0

[PATCH v2] tpm: Relocate buf->handles to appropriate place

by Jarkko Sakkinen

tpm_buf_append_name() has the following snippet in the beginning: if (!tpm2_chip_auth(chip)) { tpm_buf_append_u32(buf, handle); /* count the number of handles in the upper bits of flags */ buf->handles++; return; } The claim in the comment is wrong, and the comment is in the wrong place as alignment in this case should not anyway be a concern of the call site. In essence the comment is lying about the code, and thus needs to be adressed. Further, 'handles' was incorrectly place to struct tpm_buf, as tpm-buf.c does manage its state. It is easy to grep that only piece of code that actually uses the field is tpm2-sessions.c. Address the issues by moving the variable to struct tpm_chip. Cc: stable(a)vger.kernel.org # v6.10+ Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v2: * Was a bit more broken than I first thought, as 'handles' is only useful for tpm2-sessions.c and has zero relation to tpm-buf.c. --- drivers/char/tpm/tpm-buf.c | 1 - drivers/char/tpm/tpm2-sessions.c | 11 +++++------ include/linux/tpm.h | 8 ++++---- 3 files changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/char/tpm/tpm-buf.c b/drivers/char/tpm/tpm-buf.c index cad0048bcc3c..d06e8e063151 100644 --- a/drivers/char/tpm/tpm-buf.c +++ b/drivers/char/tpm/tpm-buf.c @@ -44,7 +44,6 @@ void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal) head->tag = cpu_to_be16(tag); head->length = cpu_to_be32(sizeof(*head)); head->ordinal = cpu_to_be32(ordinal); - buf->handles = 0; } EXPORT_SYMBOL_GPL(tpm_buf_reset); diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c index d3521aadd43e..a4ff5bca61dd 100644 --- a/drivers/char/tpm/tpm2-sessions.c +++ b/drivers/char/tpm/tpm2-sessions.c @@ -238,8 +238,7 @@ void tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf, if (!tpm2_chip_auth(chip)) { tpm_buf_append_u32(buf, handle); - /* count the number of handles in the upper bits of flags */ - buf->handles++; + chip->handles++; return; } @@ -310,7 +309,7 @@ void tpm_buf_append_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf, if (!tpm2_chip_auth(chip)) { /* offset tells us where the sessions area begins */ - int offset = buf->handles * 4 + TPM_HEADER_SIZE; + int offset = chip->handles * 4 + TPM_HEADER_SIZE; u32 len = 9 + passphrase_len; if (tpm_buf_length(buf) != offset) { @@ -1010,10 +1009,10 @@ int tpm2_start_auth_session(struct tpm_chip *chip) tpm_buf_destroy(&buf); - if (rc) - goto out; + if (!rc) + chip->handles = 0; - out: +out: return rc; } EXPORT_SYMBOL(tpm2_start_auth_session); diff --git a/include/linux/tpm.h b/include/linux/tpm.h index e93ee8d936a9..b664f7556494 100644 --- a/include/linux/tpm.h +++ b/include/linux/tpm.h @@ -202,9 +202,9 @@ struct tpm_chip { /* active locality */ int locality; + /* handle count for session: */ + u8 handles; #ifdef CONFIG_TCG_TPM2_HMAC - /* details for communication security via sessions */ - /* saved context for NULL seed */ u8 null_key_context[TPM2_MAX_CONTEXT_SIZE]; /* name of NULL seed */ @@ -377,7 +377,6 @@ struct tpm_buf { u32 flags; u32 length; u8 *data; - u8 handles; }; enum tpm2_object_attributes { @@ -517,7 +516,7 @@ static inline void tpm_buf_append_hmac_session_opt(struct tpm_chip *chip, if (tpm2_chip_auth(chip)) { tpm_buf_append_hmac_session(chip, buf, attributes, passphrase, passphraselen); } else { - offset = buf->handles * 4 + TPM_HEADER_SIZE; + offset = chip->handles * 4 + TPM_HEADER_SIZE; head = (struct tpm_header *)buf->data; /* @@ -541,6 +540,7 @@ void tpm2_end_auth_session(struct tpm_chip *chip); static inline int tpm2_start_auth_session(struct tpm_chip *chip) { + chip->handles = 0; return 0; } static inline void tpm2_end_auth_session(struct tpm_chip *chip) -- 2.45.2

5 months, 3 weeks

1
0
0 0

[PATCH 6.6] fork: defer linking file vma until vma is fully initialized

by Leah Rumancik

From: Miaohe Lin <linmiaohe(a)huawei.com> commit 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 upstream. Thorvald reported a WARNING [1]. And the root cause is below race: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping); hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping); hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used. Backport notes: The first backport attempt (cec11fa2e) was reverted (dd782da4707). This is the new backport of the original fix (35e351780fa9). 35e351780f ("fork: defer linking file vma until vma is fully initialized") fixed a hugetlb locking race by moving a bunch of intialization code to earlier in the function. The call to open() was included in the move but the call to copy_page_range was not, effectively inverting their relative ordering. This created an issue for the vfio code which assumes copy_page_range happens before the call to open() - vfio's open zaps the vma so that the fault handler is invoked later, but when we inverted the ordering, copy_page_range can set up mappings post-zap which would prevent the fault handler from being invoked later. This patch moves the call to copy_page_range to earlier than the call to open() to restore the original ordering of the two functions while keeping the fix for hugetlb intact. Commit aac6db75a9 made several changes to vfio_pci_core.c, including removing the vfio-pci custom open function. This resolves the issue on the main branch and so we only need to apply these changes when backporting to stable branches. 35e351780f ("fork: defer linking file vma until vma is fully initialized")-> v6.9-rc5 aac6db75a9 ("vfio/pci: Use unmap_mapping_range()") -> v6.10-rc4 Link: https://lkml.kernel.org/r/20240410091441.3539905-1-linmiaohe@huawei.com Fixes: 8d9bfb260814 ("hugetlb: add vma based lock for pmd sharing") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Reported-by: Thorvald Natvig <thorvald(a)google.com> Closes: https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/ [1] Reviewed-by: Jane Chu <jane.chu(a)oracle.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Peng Zhang <zhangpeng.00(a)bytedance.com> Cc: Tycho Andersen <tandersen(a)netflix.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Leah Rumancik <leah.rumancik(a)gmail.com> --- kernel/fork.c | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 177ce7438db6..122d2cd124d5 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -727,6 +727,19 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, } else if (anon_vma_fork(tmp, mpnt)) goto fail_nomem_anon_vma_fork; vm_flags_clear(tmp, VM_LOCKED_MASK); + /* + * Copy/update hugetlb private vma information. + */ + if (is_vm_hugetlb_page(tmp)) + hugetlb_dup_vma_private(tmp); + + if (!(tmp->vm_flags & VM_WIPEONFORK) && + copy_page_range(tmp, mpnt)) + goto fail_nomem_vmi_store; + + if (tmp->vm_ops && tmp->vm_ops->open) + tmp->vm_ops->open(tmp); + file = tmp->vm_file; if (file) { struct address_space *mapping = file->f_mapping; @@ -743,25 +756,11 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, i_mmap_unlock_write(mapping); } - /* - * Copy/update hugetlb private vma information. - */ - if (is_vm_hugetlb_page(tmp)) - hugetlb_dup_vma_private(tmp); - /* Link the vma into the MT */ if (vma_iter_bulk_store(&vmi, tmp)) goto fail_nomem_vmi_store; mm->map_count++; - if (!(tmp->vm_flags & VM_WIPEONFORK)) - retval = copy_page_range(tmp, mpnt); - - if (tmp->vm_ops && tmp->vm_ops->open) - tmp->vm_ops->open(tmp); - - if (retval) - goto loop_out; } /* a new mm has just been created */ retval = arch_dup_mmap(oldmm, mm); -- 2.45.2.803.g4e1b14247a-goog

5 months, 3 weeks

5
9
0 0

[PATCH] tpm: Fix alignment of buf->handles

by Jarkko Sakkinen

tpm_buf_append_name() has the following snippet in the beginning: if (!tpm2_chip_auth(chip)) { tpm_buf_append_u32(buf, handle); /* count the number of handles in the upper bits of flags */ buf->handles++; return; } The claim in the comment is wrong, and the comment is in the wrong place as it should not be anyway a concern of the "call site". So in essence it is lying about the code. Fix the alignment to be aligned with the claim in the comment and remove the comment. Cc: stable(a)vger.kernel.org # v6.10+ Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- drivers/char/tpm/tpm2-sessions.c | 1 - include/linux/tpm.h | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c index d3521aadd43e..02fc5d4ff535 100644 --- a/drivers/char/tpm/tpm2-sessions.c +++ b/drivers/char/tpm/tpm2-sessions.c @@ -238,7 +238,6 @@ void tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf, if (!tpm2_chip_auth(chip)) { tpm_buf_append_u32(buf, handle); - /* count the number of handles in the upper bits of flags */ buf->handles++; return; } diff --git a/include/linux/tpm.h b/include/linux/tpm.h index e93ee8d936a9..4b55298520b5 100644 --- a/include/linux/tpm.h +++ b/include/linux/tpm.h @@ -374,10 +374,10 @@ enum tpm_buf_flags { * A string buffer type for constructing TPM commands. */ struct tpm_buf { - u32 flags; + u16 flags; + u16 handles; u32 length; u8 *data; - u8 handles; }; enum tpm2_object_attributes { -- 2.45.2

5 months, 3 weeks

1
0
0 0

[PATCH 5.15.y] ACPI: processor_idle: Fix invalid comparison with insertion sort for latency

by Kuan-Wei Chiu

The acpi_cst_latency_cmp() comparison function currently used for sorting C-state latencies does not satisfy transitivity, causing incorrect sorting results. Specifically, if there are two valid acpi_processor_cx elements A and B and one invalid element C, it may occur that A < B, A = C, and B = C. Sorting algorithms assume that if A < B and A = C, then C < B, leading to incorrect ordering. Given the small size of the array (<=8), we replace the library sort function with a simple insertion sort that properly ignores invalid elements and sorts valid ones based on latency. This change ensures correct ordering of the C-state latencies. Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered") Reported-by: Julian Sikorski <belegdol(a)gmail.com> Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> Tested-by: Julian Sikorski <belegdol(a)gmail.com> Cc: All applicable <stable(a)vger.kernel.org> Link: https://patch.msgid.link/20240701205639.117194-1-visitorckw@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> (cherry picked from commit 233323f9b9f828cd7cd5145ad811c1990b692542) Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> --- drivers/acpi/processor_idle.c | 40 ++++++++++++++--------------------- 1 file changed, 16 insertions(+), 24 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index 4cb44d80bf52..5289c344de90 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -16,7 +16,6 @@ #include <linux/acpi.h> #include <linux/dmi.h> #include <linux/sched.h> /* need_resched() */ -#include <linux/sort.h> #include <linux/tick.h> #include <linux/cpuidle.h> #include <linux/cpu.h> @@ -385,28 +384,24 @@ static void acpi_processor_power_verify_c3(struct acpi_processor *pr, return; } -static int acpi_cst_latency_cmp(const void *a, const void *b) +static void acpi_cst_latency_sort(struct acpi_processor_cx *states, size_t length) { - const struct acpi_processor_cx *x = a, *y = b; + int i, j, k; - if (!(x->valid && y->valid)) - return 0; - if (x->latency > y->latency) - return 1; - if (x->latency < y->latency) - return -1; - return 0; -} -static void acpi_cst_latency_swap(void *a, void *b, int n) -{ - struct acpi_processor_cx *x = a, *y = b; - u32 tmp; + for (i = 1; i < length; i++) { + if (!states[i].valid) + continue; - if (!(x->valid && y->valid)) - return; - tmp = x->latency; - x->latency = y->latency; - y->latency = tmp; + for (j = i - 1, k = i; j >= 0; j--) { + if (!states[j].valid) + continue; + + if (states[j].latency > states[k].latency) + swap(states[j].latency, states[k].latency); + + k = j; + } + } } static int acpi_processor_power_verify(struct acpi_processor *pr) @@ -451,10 +446,7 @@ static int acpi_processor_power_verify(struct acpi_processor *pr) if (buggy_latency) { pr_notice("FW issue: working around C-state latencies out of order\n"); - sort(&pr->power.states[1], max_cstate, - sizeof(struct acpi_processor_cx), - acpi_cst_latency_cmp, - acpi_cst_latency_swap); + acpi_cst_latency_sort(&pr->power.states[1], max_cstate); } lapic_timer_propagate_broadcast(pr); -- 2.34.1

5 months, 3 weeks

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024