February 2025 - Linux-stable-mirror

[PATCH] partitions: mac: fix handling of bogus partition table

by Jann Horn

Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp(). Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> --- block/partitions/mac.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/block/partitions/mac.c b/block/partitions/mac.c index c80183156d68020e0e14974308ac751b3df84421..b02530d986297058de0db929fbf638a76fc44508 100644 --- a/block/partitions/mac.c +++ b/block/partitions/mac.c @@ -53,13 +53,25 @@ int mac_partition(struct parsed_partitions *state) } secsize = be16_to_cpu(md->block_size); put_dev_sector(sect); + + /* + * If the "block size" is not a power of 2, things get weird - we might + * end up with a partition straddling a sector boundary, so we wouldn't + * be able to read a partition entry with read_part_sector(). + * Real block sizes are probably (?) powers of two, so just require + * that. + */ + if (!is_power_of_2(secsize)) + return -1; datasize = round_down(secsize, 512); data = read_part_sector(state, datasize / 512, &sect); if (!data) return -1; partoffset = secsize % 512; - if (partoffset + sizeof(*part) > datasize) + if (partoffset + sizeof(*part) > datasize) { + put_dev_sector(sect); return -1; + } part = (struct mac_partition *) (data + partoffset); if (be16_to_cpu(part->signature) != MAC_PARTITION_MAGIC) { put_dev_sector(sect); @@ -112,8 +124,8 @@ int mac_partition(struct parsed_partitions *state) int i, l; goodness++; - l = strlen(part->name); - if (strcmp(part->name, "/") == 0) + l = strnlen(part->name, sizeof(part->name)); + if (strncmp(part->name, "/", sizeof(part->name)) == 0) goodness++; for (i = 0; i <= l - 4; ++i) { if (strncasecmp(part->name + i, "root", --- base-commit: ab68d7eb7b1a64f3f4710da46cc5f93c6c154942 change-id: 20250214-partition-mac-2e7114c62223 -- Jann Horn <jannh(a)google.com>

3 months, 3 weeks

2
1
0 0

[PATCH v2 0/4] soc: qcom: ice: fix dev reference leaked through of_qcom_ice_get

by Tudor Ambarus

Hi! Recently I've been pointed to this driver for an example on how consumers can get a pointer to the supplier's driver data and I noticed a leak. Callers of of_qcom_ice_get() leak the device reference taken by of_find_device_by_node(). Introduce devm_of_qcom_ice_get(). Exporting qcom_ice_put() is not done intentionally as the consumers need the ICE intance for the entire life of their device. Update the consumers to use the devm variant and make of_qcom_ice_get() static afterwards. This set touches mmc and scsi subsystems. Since the fix is trivial for them, I'd suggest taking everything through the SoC tree with Acked-by tags if people consider this fine. Note that the mmc and scsi patches depend on the first patch that introduces devm_of_qcom_ice_get(). Thanks! Signed-off-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> --- Changes in v2: - add kernel doc for newly introduced devm_of_qcom_ice_get(). - update cover letter and commit message of first patch. - collect R-b and A-b tags. - Link to v1: https://lore.kernel.org/r/20250116-qcom-ice-fix-dev-leak-v1-0-84d937683790@… --- Tudor Ambarus (4): soc: qcom: ice: introduce devm_of_qcom_ice_get mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get scsi: ufs: qcom: fix dev reference leaked through of_qcom_ice_get soc: qcom: ice: make of_qcom_ice_get() static drivers/mmc/host/sdhci-msm.c | 2 +- drivers/soc/qcom/ice.c | 51 ++++++++++++++++++++++++++++++++++++++++++-- drivers/ufs/host/ufs-qcom.c | 2 +- include/soc/qcom/ice.h | 3 ++- 4 files changed, 53 insertions(+), 5 deletions(-) --- base-commit: b323d8e7bc03d27dec646bfdccb7d1a92411f189 change-id: 20250110-qcom-ice-fix-dev-leak-bbff59a964fb Best regards, -- Tudor Ambarus <tudor.ambarus(a)linaro.org>

3 months, 3 weeks

5
7
0 0

[PATCH] clk: qcom: clk-branch: Fix invert halt status bit check for votable clocks

by Ajit Pandey

BRANCH_HALT_ENABLE and BRANCH_HALT_ENABLE_VOTED flags are used to check halt status of branch clocks, which have an inverted logic for the halt bit in CBCR register. However, the current logic in the _check_halt() method only compares the BRANCH_HALT_ENABLE flags, ignoring the votable branch clocks. Update the logic to correctly handle the invert logic for votable clocks using the BRANCH_HALT_ENABLE_VOTED flags. Fixes: 9092d1083a62 ("clk: qcom: branch: Extend the invert logic for branch2 clocks") Cc: stable(a)vger.kernel.org Signed-off-by: Ajit Pandey <quic_ajipan(a)quicinc.com> --- This patch update the logic to correctly handle the invert logic for votable clocks using the BRANCH_HALT_ENABLE_VOTED flags. --- drivers/clk/qcom/clk-branch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/qcom/clk-branch.c b/drivers/clk/qcom/clk-branch.c index 229480c5b075..0f10090d4ae6 100644 --- a/drivers/clk/qcom/clk-branch.c +++ b/drivers/clk/qcom/clk-branch.c @@ -28,7 +28,7 @@ static bool clk_branch_in_hwcg_mode(const struct clk_branch *br) static bool clk_branch_check_halt(const struct clk_branch *br, bool enabling) { - bool invert = (br->halt_check == BRANCH_HALT_ENABLE); + bool invert = (br->halt_check & BRANCH_HALT_ENABLE); u32 val; regmap_read(br->clkr.regmap, br->halt_reg, &val); @@ -44,7 +44,7 @@ static bool clk_branch2_check_halt(const struct clk_branch *br, bool enabling) { u32 val; u32 mask; - bool invert = (br->halt_check == BRANCH_HALT_ENABLE); + bool invert = (br->halt_check & BRANCH_HALT_ENABLE); mask = CBCR_NOC_FSM_STATUS; mask |= CBCR_CLK_OFF; --- base-commit: 9a87ce288fe30f268b3a598422fe76af9bb2c2d2 change-id: 20250128-push_fix-133e5e3c4529 Best regards, -- Ajit Pandey <quic_ajipan(a)quicinc.com>

3 months, 3 weeks

3
2
0 0

[PATCH v3] soc: qcom: pdr: Fix the potential deadlock

by Mukesh Ojha

From: Saranya R <quic_sarar(a)quicinc.com> When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1] Link: https://lore.kernel.org/lkml/Zqet8iInnDhnxkT9@hovoldconsulting.com/ # [1] Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") CC: stable(a)vger.kernel.org Reviewed-by: Bjorn Andersson <bjorn.andersson(a)oss.qualcomm.com> Tested-by: Bjorn Andersson <bjorn.andersson(a)oss.qualcomm.com> Tested-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Saranya R <quic_sarar(a)quicinc.com> Co-developed-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> --- Changes in v3: - Corrected author and added Co-developed-by for myself. - Added T-by and R-by tags. - Modified commit message updated with the link of the issue which also gets fixed by this commit. Changes in v2: - Added Fixes tag. drivers/soc/qcom/pdr_interface.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c index 328b6153b2be..71be378d2e43 100644 --- a/drivers/soc/qcom/pdr_interface.c +++ b/drivers/soc/qcom/pdr_interface.c @@ -75,7 +75,6 @@ static int pdr_locator_new_server(struct qmi_handle *qmi, { struct pdr_handle *pdr = container_of(qmi, struct pdr_handle, locator_hdl); - struct pdr_service *pds; mutex_lock(&pdr->lock); /* Create a local client port for QMI communication */ @@ -87,12 +86,7 @@ static int pdr_locator_new_server(struct qmi_handle *qmi, mutex_unlock(&pdr->lock); /* Service pending lookup requests */ - mutex_lock(&pdr->list_lock); - list_for_each_entry(pds, &pdr->lookups, node) { - if (pds->need_locator_lookup) - schedule_work(&pdr->locator_work); - } - mutex_unlock(&pdr->list_lock); + schedule_work(&pdr->locator_work); return 0; } -- 2.34.1

3 months, 3 weeks

2
1
0 0

[PATCH] firmware: qcom: uefisecapp: fix efivars registration race

by Johan Hovold

Since the conversion to using the TZ allocator, the efivars service is registered before the memory pool has been allocated, something which can lead to a NULL-pointer dereference in case of a racing EFI variable access. Make sure that all resources have been set up before registering the efivars. Fixes: 6612103ec35a ("firmware: qcom: qseecom: convert to using the TZ allocator") Cc: stable(a)vger.kernel.org # 6.11 Cc: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- Note that commit 40289e35ca52 ("firmware: qcom: scm: enable the TZ mem allocator") looks equally broken as it allocates the tzmem pool only after qcom_scm_is_available() returns true and other driver can start making SCM calls. That one appears to be a bit harder to fix as qcom_tzmem_enable() currently depends on SCM being available, but someone should definitely look into untangling that mess. Johan .../firmware/qcom/qcom_qseecom_uefisecapp.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c index 447246bd04be..98a463e9774b 100644 --- a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c +++ b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c @@ -814,15 +814,6 @@ static int qcom_uefisecapp_probe(struct auxiliary_device *aux_dev, qcuefi->client = container_of(aux_dev, struct qseecom_client, aux_dev); - auxiliary_set_drvdata(aux_dev, qcuefi); - status = qcuefi_set_reference(qcuefi); - if (status) - return status; - - status = efivars_register(&qcuefi->efivars, &qcom_efivar_ops); - if (status) - qcuefi_set_reference(NULL); - memset(&pool_config, 0, sizeof(pool_config)); pool_config.initial_size = SZ_4K; pool_config.policy = QCOM_TZMEM_POLICY_MULTIPLIER; @@ -833,6 +824,15 @@ static int qcom_uefisecapp_probe(struct auxiliary_device *aux_dev, if (IS_ERR(qcuefi->mempool)) return PTR_ERR(qcuefi->mempool); + auxiliary_set_drvdata(aux_dev, qcuefi); + status = qcuefi_set_reference(qcuefi); + if (status) + return status; + + status = efivars_register(&qcuefi->efivars, &qcom_efivar_ops); + if (status) + qcuefi_set_reference(NULL); + return status; } -- 2.45.2

3 months, 3 weeks

5
4
0 0

[PATCH v10 0/4] clk: qcom: Add support for multiple power-domains for a clock controller.

by Bryan O'Donoghue

Changes in v10: - Updated the commit log of patch #1 to make the reasoning - that it makes applying the subsequent patch cleaner/nicer clear - Bjorn - Substantially rewrites final patch commit to mostly reflect Bjorn's summation of my long and rambling previous paragraphs. Being a visual person, I've included some example pseudo-code which hopefully makes the intent clearer plus some ASCII art >= Klimt. - Link to v9: https://lore.kernel.org/r/20241230-b4-linux-next-24-11-18-clock-multiple-po… Changes in v9: - Added patch to unwind pm subdomains in reverse order. It would also be possible to squash this patch into patch#2 but, my own preference is for more granular patches like this instead of "slipping in" functional changes in larger patches like #2. - bod - Unwinding pm subdomain on error in patch #2. To facilitate this change patch #1 was created - Vlad - Drops Bjorn's RB on patch #2. There is a small churn in this patch but enough that a reviewer might reasonably expect RB to be given again. - Amends commit log for patch #3 further. v8 added a lot to the commit log to provide further information but, it is clear from the comments I received on the commit log that the added verbiage was occlusive not elucidative. Reduce down the commit log of patch #3 - especially Q&A item #1. Sometimes less is more. - Link to v8: https://lore.kernel.org/r/20241211-b4-linux-next-24-11-18-clock-multiple-po… Changes in v8: - Picks up change I agreed with Vlad but failed to cherry-pick into my b4 tree - Vlad/Bod - Rewords the commit log for patch #3. As I read it I decided I might translate bits of it from thought-stream into English - Bod - Link to v7: https://lore.kernel.org/r/20241211-b4-linux-next-24-11-18-clock-multiple-po… Changes in v7: - Expand commit log in patch #3 I've discussed with Bjorn on IRC and video what to put into the log here and captured most of what we discussed. Mostly the point here is voting for voltages in the power-domain list is up to the drivers to do with performance states/opp-tables not for the GDSC code. - Bjorn/Bryan - Link to v6: https://lore.kernel.org/r/20241129-b4-linux-next-24-11-18-clock-multiple-po… Changes in v6: - Passes NULL to second parameter of devm_pm_domain_attach_list - Vlad - Link to v5: https://lore.kernel.org/r/20241128-b4-linux-next-24-11-18-clock-multiple-po… Changes in v5: - In-lines devm_pm_domain_attach_list() in probe() directly - Vlad - Link to v4: https://lore.kernel.org/r/20241127-b4-linux-next-24-11-18-clock-multiple-po… v4: - Adds Bjorn's RB to first patch - Bjorn - Drops the 'd' in "and int" - Bjorn - Amends commit log of patch 3 to capture a number of open questions - Bjorn - Link to v3: https://lore.kernel.org/r/20241126-b4-linux-next-24-11-18-clock-multiple-po… v3: - Fixes commit log "per which" - Bryan - Link to v2: https://lore.kernel.org/r/20241125-b4-linux-next-24-11-18-clock-multiple-po… v2: The main change in this version is Bjorn's pointing out that pm_runtime_* inside of the gdsc_enable/gdsc_disable path would be recursive and cause a lockdep splat. Dmitry alluded to this too. Bjorn pointed to stuff being done lower in the gdsc_register() routine that might be a starting point. I iterated around that idea and came up with patch #3. When a gdsc has no parent and the pd_list is non-NULL then attach that orphan GDSC to the clock controller power-domain list. Existing subdomain code in gdsc_register() will connect the parent GDSCs in the clock-controller to the clock-controller subdomain, the new code here does that same job for a list of power-domains the clock controller depends on. To Dmitry's point about MMCX and MCX dependencies for the registers inside of the clock controller, I have switched off all references in a test dtsi and confirmed that accessing the clock-controller regs themselves isn't required. On the second point I also verified my test branch with lockdep on which was a concern with the pm_domain version of this solution but I wanted to cover it anyway with the new approach for completeness sake. Here's the item-by-item list of changes: - Adds a patch to capture pm_genpd_add_subdomain() result code - Bryan - Changes changelog of second patch to remove singleton and generally to make the commit log easier to understand - Bjorn - Uses demv_pm_domain_attach_list - Vlad - Changes error check to if (ret < 0 && ret != -EEXIST) - Vlad - Retains passing &pd_data instead of NULL - because NULL doesn't do the same thing - Bryan/Vlad - Retains standalone function qcom_cc_pds_attach() because the pd_data enumeration looks neater in a standalone function - Bryan/Vlad - Drops pm_runtime in favour of gdsc_add_subdomain_list() for each power-domain in the pd_list. The pd_list will be whatever is pointed to by power-domains = <> in the dtsi - Bjorn - Link to v1: https://lore.kernel.org/r/20241118-b4-linux-next-24-11-18-clock-multiple-po… v1: On x1e80100 and it's SKUs the Camera Clock Controller - CAMCC has multiple power-domains which power it. Usually with a single power-domain the core platform code will automatically switch on the singleton power-domain for you. If you have multiple power-domains for a device, in this case the clock controller, you need to switch those power-domains on/off yourself. The clock controllers can also contain Global Distributed Switch Controllers - GDSCs which themselves can be referenced from dtsi nodes ultimately triggering a gdsc_en() in drivers/clk/qcom/gdsc.c. As an example: cci0: cci@ac4a000 { power-domains = <&camcc TITAN_TOP_GDSC>; }; This series adds the support to attach a power-domain list to the clock-controllers and the GDSCs those controllers provide so that in the case of the above example gdsc_toggle_logic() will trigger the power-domain list with pm_runtime_resume_and_get() and pm_runtime_put_sync() respectively. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> --- Bryan O'Donoghue (4): clk: qcom: gdsc: Release pm subdomains in reverse add order clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code clk: qcom: common: Add support for power-domain attachment clk: qcom: Support attaching GDSCs to multiple parents drivers/clk/qcom/common.c | 6 ++++ drivers/clk/qcom/gdsc.c | 75 +++++++++++++++++++++++++++++++++++++++-------- drivers/clk/qcom/gdsc.h | 1 + 3 files changed, 69 insertions(+), 13 deletions(-) --- base-commit: 0907e7fb35756464aa34c35d6abb02998418164b change-id: 20241118-b4-linux-next-24-11-18-clock-multiple-power-domains-a5f994dc452a Best regards, -- Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>

3 months, 3 weeks

2
3
0 0

[PATCH v2] mtd: spinand: winbond: Fix oob_layout for W25N01JW

by Santhosh Kumar K

Fix the W25N01JW's oob_layout according to the datasheet. [1] [1] https://www.winbond.com/hq/product/code-storage-flash-memory/qspinand-flash… Fixes: 6a804fb72de5 ("mtd: spinand: winbond: add support for serial NAND flash") Cc: Sridharan S N <quic_sridsn(a)quicinc.com> Cc: stable(a)vger.kernel.org Signed-off-by: Santhosh Kumar K <s-k6(a)ti.com> --- Changes in v2: - Detach patch 3/3 from v1 - Rebase on next - Link to v1: https://lore.kernel.org/linux-mtd/20250102115110.1402440-1-s-k6@ti.com/ Repo: https://github.com/santhosh21/linux/tree/uL_next Test results: https://gist.github.com/santhosh21/71ab6646dccc238a0b3c47c0382f219a --- drivers/mtd/nand/spi/winbond.c | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c index ea11ae12423f..41cd0a51e450 100644 --- a/drivers/mtd/nand/spi/winbond.c +++ b/drivers/mtd/nand/spi/winbond.c @@ -134,6 +134,30 @@ static int w25n02kv_ooblayout_free(struct mtd_info *mtd, int section, return 0; } +static int w25n01jw_ooblayout_ecc(struct mtd_info *mtd, int section, + struct mtd_oob_region *region) +{ + if (section > 3) + return -ERANGE; + + region->offset = (16 * section) + 12; + region->length = 4; + + return 0; +} + +static int w25n01jw_ooblayout_free(struct mtd_info *mtd, int section, + struct mtd_oob_region *region) +{ + if (section > 3) + return -ERANGE; + + region->offset = (16 * section) + 2; + region->length = 10; + + return 0; +} + static int w35n01jw_ooblayout_ecc(struct mtd_info *mtd, int section, struct mtd_oob_region *region) { @@ -173,6 +197,11 @@ static const struct mtd_ooblayout_ops w35n01jw_ooblayout = { .free = w35n01jw_ooblayout_free, }; +static const struct mtd_ooblayout_ops w25n01jw_ooblayout = { + .ecc = w25n01jw_ooblayout_ecc, + .free = w25n01jw_ooblayout_free, +}; + static int w25n02kv_ecc_get_status(struct spinand_device *spinand, u8 status) { @@ -249,7 +278,7 @@ static const struct spinand_info winbond_spinand_table[] = { &write_cache_variants, &update_cache_variants), 0, - SPINAND_ECCINFO(&w25m02gv_ooblayout, NULL)), + SPINAND_ECCINFO(&w25n01jw_ooblayout, NULL)), SPINAND_INFO("W25N01KV", /* 3.3V */ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xae, 0x21), NAND_MEMORG(1, 2048, 96, 64, 1024, 20, 1, 1, 1), -- 2.34.1

3 months, 3 weeks

2
2
0 0

[PATCHSET 6.12] xfs: bug fixes from 6.13

by Darrick J. Wong

Hi all, Here's a bunch of hand-ported bug fixes for 6.12 LTS. Most of the patches fix a warning about dquot reclaim needing to read dquot buffers in from disk by pinning buffers at transaction commit time instead of during reclaim. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. With a bit of luck, this should all go splendidly. Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=ne… --- Commits in this patchset: * xfs: avoid nested calls to __xfs_trans_commit * xfs: don't lose solo superblock counter update transactions * xfs: don't lose solo dquot update transactions * xfs: separate dquot buffer reads from xfs_dqflush * xfs: clean up log item accesses in xfs_qm_dqflush{,_done} * xfs: attach dquot buffer to dquot log item buffer * xfs: convert quotacheck to attach dquot buffers * xfs: don't over-report free space or inodes in statvfs * xfs: release the dquot buf outside of qli_lock * xfs: lock dquot buffer before detaching dquot from b_li_list * xfs: fix mount hang during primary superblock recovery failure --- fs/xfs/xfs_dquot.h | 6 + fs/xfs/xfs_dquot_item.h | 7 + fs/xfs/xfs_quota.h | 7 + fs/xfs/xfs_buf_item_recover.c | 11 ++ fs/xfs/xfs_dquot.c | 199 +++++++++++++++++++++++++++++++++++------ fs/xfs/xfs_dquot_item.c | 51 ++++++++--- fs/xfs/xfs_qm.c | 48 ++++++++-- fs/xfs/xfs_qm_bhv.c | 27 ++++-- fs/xfs/xfs_trans.c | 39 ++++---- fs/xfs/xfs_trans_ail.c | 2 fs/xfs/xfs_trans_dquot.c | 31 +++++- 11 files changed, 338 insertions(+), 90 deletions(-)

3 months, 3 weeks

3
14
0 0

[PATCH v2 1/7] ceph: Do not look at the index of an encrypted page

by Matthew Wilcox (Oracle)

If the pages array contains encrypted pages, we cannot look at page->index because that field is uninitialised. Instead, use the new ceph_fscrypt_pagecache_folio() to get the pagecache folio and look at the index of that. Fixes: d55207717ded (ceph: add encryption support to writepage and writepages) Cc: stable(a)vger.kernel.org Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> --- fs/ceph/addr.c | 5 ++++- fs/ceph/crypto.h | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index f5224a566b69..80bc0cbacd7a 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1356,8 +1356,11 @@ static int ceph_writepages_start(struct address_space *mapping, memset(data_pages + i, 0, locked_pages * sizeof(*pages)); } else { + struct folio *folio; + BUG_ON(num_ops != req->r_num_ops); - index = pages[i - 1]->index + 1; + folio = ceph_fscrypt_pagecache_folio(pages[i - 1]); + index = folio->index + 1; /* request message now owns the pages array */ pages = NULL; } diff --git a/fs/ceph/crypto.h b/fs/ceph/crypto.h index d0768239a1c9..e4404ef589a1 100644 --- a/fs/ceph/crypto.h +++ b/fs/ceph/crypto.h @@ -280,6 +280,13 @@ static inline struct page *ceph_fscrypt_pagecache_page(struct page *page) } #endif /* CONFIG_FS_ENCRYPTION */ +static inline struct folio *ceph_fscrypt_pagecache_folio(struct page *page) +{ + if (fscrypt_is_bounce_page(page)) + page = fscrypt_pagecache_page(page); + return page_folio(page); +} + static inline loff_t ceph_fscrypt_page_offset(struct page *page) { return page_offset(ceph_fscrypt_pagecache_page(page)); -- 2.47.2

3 months, 3 weeks

1
0
0 0

[REGRESSION] usb: xhci port capability storage change broke fastboot android bootloader utility

by Forest

#regzbot introduced: 63a1f8454962 Dear maintainer, I think I have found a regression in kernels version 6.10 and newer, including the latest mainline v6.13-rc4: fastboot (the tool for communicating with Android bootloaders) now fails to perform various operations over USB. The problem manifests as an error when attempting to 'fastboot flash' an image (e.g. a new kernel containing security updates) to a LineageOS phone. It also manifests with simpler operations like reading a variable from the bootloader. For example: fastboot getvar kernel A typical error message when the failure occurs: getvar:kernel FAILED (remote: 'GetVar Variable Not found') I can reproduce this at will. It happens about 50% of the time when I run the above getvar command, and almost all the time when I try to push a new kernel to a device. A git bisect reveals this: 63a1f8454962a64746a59441687dc2401290326c is the first bad commit commit 63a1f8454962a64746a59441687dc2401290326c Author: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Mon Apr 29 17:02:28 2024 +0300 xhci: stored cached port capability values in one place

3 months, 3 weeks

4
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025