- Kernel - mailweb.openeuler.org

[openeuler:openEuler-1.0-LTS 1291/1291] drivers/char/svm.c:312:17-38: WARNING: atomic_dec_and_test variation before object free at line 335.
by kernel test robot 14 Nov '24

14 Nov '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: d5c3ef07e625af7ba8aded2f507f092bceab3cbc commit: 4cdb60f56180d6ef7c10bd0e50ddda96ebc9f783 [1291/1291] svm: implement unpin pages to dec refcount config: arm64-randconfig-r063-20241113 (https://download.01.org/0day-ci/archive/20241114/202411141631.Gm0CdUvq-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.2.0 If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202411141631.Gm0CdUvq-lkp@intel.com/ cocci warnings: (new ones prefixed by >>) >> drivers/char/svm.c:312:17-38: WARNING: atomic_dec_and_test variation before object free at line 335. vim +312 drivers/char/svm.c 304 305 static void svm_remove_sdma(struct svm_process *process, 306 struct svm_sdma *sdma, bool try_rm) 307 { 308 int null_count = 0; 309 310 mutex_lock(&process->mutex); 311 > 312 if (try_rm && (!atomic64_dec_and_test(&sdma->ref))) { 313 mutex_unlock(&process->mutex); 314 return; 315 } 316 317 rb_erase(&sdma->node, &process->sdma_list); 318 RB_CLEAR_NODE(&sdma->node); 319 mutex_unlock(&process->mutex); 320 321 while (sdma->nr_pages--) { 322 if (sdma->pages[sdma->nr_pages] == NULL) { 323 pr_err("null pointer, nr_pages:%d.\n", sdma->nr_pages); 324 null_count++; 325 continue; 326 } 327 328 put_page(sdma->pages[sdma->nr_pages]); 329 } 330 331 if (null_count) 332 dump_stack(); 333 334 kfree(sdma->pages); > 335 kfree(sdma); 336 } 337 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] sched/dynamic_affinity: fix preffered_cpu offline problem
by He Yujie 14 Nov '24

14 Nov '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB42TC CVE: NA -------------------------------- After the preferred_cpu goes offline, the core selection of dynamic affinity does not check whether the preferred_cpu is valid. As a result, related dynamic affinity processes are concentrated on a shared_cpu. This patch resolves this problem to checks whether the preferred_cpu is valid and compares only the usage threshold of the valid preferred_cpu. Fixes: 70a232a564cf ("sched: Adjust wakeup cpu range according CPU util dynamicly") Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- kernel/sched/fair.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 63f4344ac344..41b339c5b671 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7248,6 +7248,7 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, struct task_group *tg; long spare; int cpu, mode; + int nr_cpus_valid = 0; rcu_read_lock(); mode = dynamic_affinity_mode(p); @@ -7265,7 +7266,7 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, /* manual mode */ tg = task_group(p); - for_each_cpu(cpu, p->prefer_cpus) { + for_each_cpu_and(cpu, p->prefer_cpus, cpu_online_mask) { if (unlikely(!tg->se[cpu])) continue; @@ -7289,10 +7290,18 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, util_avg_sum += tg->se[cpu]->avg.util_avg; tg_capacity += capacity_of(cpu); + nr_cpus_valid++; } rcu_read_unlock(); - if (tg_capacity > cpumask_weight(p->prefer_cpus) && + /* + * Follow cases should select cpus_ptr, checking by condition of + * tg_capacity > nr_cpus_valid: + * 1. all prefer_cpus offline; + * 2. all prefer_cpus has no cfs capaicity(tg_capacity = + * nr_cpus_valid * 1) + */ + if (tg_capacity > nr_cpus_valid && util_avg_sum * 100 <= tg_capacity * sysctl_sched_util_low_pct) { p->select_cpus = p->prefer_cpus; if (sd_flag & SD_BALANCE_WAKE) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/7] CVE-2022-48878
by Yuan Can 14 Nov '24

14 Nov '24

Fix patch of CVE-2022-48878 and its pre requests and new fix patches. Krzysztof Kozlowski (1): Bluetooth: hci_qca: Fix driver shutdown on closed serdev Venkata Lakshmi Narayana Gubba (4): Bluetooth: hci_qca: Wait for timeout during suspend Bluetooth: hci_qca: Wait for SSR completion during suspend Bluetooth: hci_qca: check for SSR triggered flag while suspend Bluetooth: hci_qca: Fixed issue during suspend Yang Yingliang (1): Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave() Zijun Hu (1): Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot drivers/bluetooth/hci_qca.c | 82 ++++++++++++++++++++++++++++++++----- 1 file changed, 72 insertions(+), 10 deletions(-) -- 2.17.1

2 8

[PATCH openEuler-1.0-LTS] sched/dynamic_affinity: fix preffered_cpu offline problem
by He Yujie 14 Nov '24

14 Nov '24

Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB42TC -------------------------------- After the preferred_cpu goes offline, the core selection of dynamic affinity does not check whether the preferred_cpu is valid. As a result, related dynamic affinity processes are concentrated on a shared_cpu. This patch resolves this problem to checks whether the preferred_cpu is valid and compares only the usage threshold of the valid preferred_cpu. Fixes: 70a232a564cf ("sched: Adjust wakeup cpu range according CPU util dynamicly") Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- kernel/sched/fair.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 63f4344ac344..41b339c5b671 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7248,6 +7248,7 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, struct task_group *tg; long spare; int cpu, mode; + int nr_cpus_valid = 0; rcu_read_lock(); mode = dynamic_affinity_mode(p); @@ -7265,7 +7266,7 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, /* manual mode */ tg = task_group(p); - for_each_cpu(cpu, p->prefer_cpus) { + for_each_cpu_and(cpu, p->prefer_cpus, cpu_online_mask) { if (unlikely(!tg->se[cpu])) continue; @@ -7289,10 +7290,18 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, util_avg_sum += tg->se[cpu]->avg.util_avg; tg_capacity += capacity_of(cpu); + nr_cpus_valid++; } rcu_read_unlock(); - if (tg_capacity > cpumask_weight(p->prefer_cpus) && + /* + * Follow cases should select cpus_ptr, checking by condition of + * tg_capacity > nr_cpus_valid: + * 1. all prefer_cpus offline; + * 2. all prefer_cpus has no cfs capaicity(tg_capacity = + * nr_cpus_valid * 1) + */ + if (tg_capacity > nr_cpus_valid && util_avg_sum * 100 <= tg_capacity * sysctl_sched_util_low_pct) { p->select_cpus = p->prefer_cpus; if (sd_flag & SD_BALANCE_WAKE) -- 2.34.1

2 1

[PATCH OLK-5.10 V1] scsi: pm80xx: Set phy->enable_completion only when we wait for it
by Zicheng Qu 14 Nov '24

14 Nov '24

From: Igor Pylypiv <ipylypiv(a)google.com> stable inclusion from stable-v6.6.51 commit 7b1d779647afaea9185fa2f150b1721e7c1aae89 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAVU94 CVE: CVE-2024-47666 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e4f949ef1516c0d74745ee54a0f4882c1f6c7aea ] pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. Signed-off-by: Igor Pylypiv <ipylypiv(a)google.com> Signed-off-by: Terrence Adams <tadamsjr(a)google.com> Link: https://lore.kernel.org/r/20240627155924.2361370-2-tadamsjr@google.com Acked-by: Jack Wang <jinpu.wang(a)ionos.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/scsi/pm8001/pm8001_sas.c [The 5.10 stable version lacks this patch 7b1d779647afaea9185fa2f150b1721e7c1aae89, which was pulled from 6.6. Missing commits a961ea0afd632cc570b71e455fe4328ee2fd9348 and 4851c39aae3a917d09983e1c6948fa9d749b5448 in 5.10 led to manually removing the if (PM8001_CHIP_DISP->fatal_errors(pm8001_ha)) code.] Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/scsi/pm8001/pm8001_sas.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c index f77061396871..2d5f2ab0a0f7 100644 --- a/drivers/scsi/pm8001/pm8001_sas.c +++ b/drivers/scsi/pm8001/pm8001_sas.c @@ -163,7 +163,6 @@ int pm8001_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, unsigned long flags; pm8001_ha = sas_phy->ha->lldd_ha; phy = &pm8001_ha->phy[phy_id]; - pm8001_ha->phy[phy_id].enable_completion = &completion; switch (func) { case PHY_FUNC_SET_LINK_RATE: rates = funcdata; @@ -176,6 +175,7 @@ int pm8001_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, rates->maximum_linkrate; } if (pm8001_ha->phy[phy_id].phy_state == PHY_LINK_DISABLE) { + pm8001_ha->phy[phy_id].enable_completion = &completion; PM8001_CHIP_DISP->phy_start_req(pm8001_ha, phy_id); wait_for_completion(&completion); } @@ -184,6 +184,7 @@ int pm8001_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, break; case PHY_FUNC_HARD_RESET: if (pm8001_ha->phy[phy_id].phy_state == PHY_LINK_DISABLE) { + pm8001_ha->phy[phy_id].enable_completion = &completion; PM8001_CHIP_DISP->phy_start_req(pm8001_ha, phy_id); wait_for_completion(&completion); } @@ -192,6 +193,7 @@ int pm8001_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, break; case PHY_FUNC_LINK_RESET: if (pm8001_ha->phy[phy_id].phy_state == PHY_LINK_DISABLE) { + pm8001_ha->phy[phy_id].enable_completion = &completion; PM8001_CHIP_DISP->phy_start_req(pm8001_ha, phy_id); wait_for_completion(&completion); } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 V1] staging: iio: frequency: ad9834: Validate frequency parameter value
by Zicheng Qu 14 Nov '24

14 Nov '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v5.10.226 commit 41cc91e3138fe52f8da92a81bebcd0e6cf488c53 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAVU8A CVE: CVE-2024-47663 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b48aa991758999d4e8f9296c5bbe388f293ef465 upstream. In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://patch.msgid.link/20240703154506.25584-1-amishin@t-argos.ru Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/staging/iio/frequency/ad9834.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/frequency/ad9834.c b/drivers/staging/iio/frequency/ad9834.c index 262c3590e64e..fa0a7056dea4 100644 --- a/drivers/staging/iio/frequency/ad9834.c +++ b/drivers/staging/iio/frequency/ad9834.c @@ -115,7 +115,7 @@ static int ad9834_write_frequency(struct ad9834_state *st, clk_freq = clk_get_rate(st->mclk); - if (fout > (clk_freq / 2)) + if (!clk_freq || fout > (clk_freq / 2)) return -EINVAL; regval = ad9834_calc_freqreg(clk_freq, fout); -- 2.34.1

2 1

[PATCH OLK-5.10 V1] staging: iio: frequency: ad9834: Validate frequency parameter value
by Zicheng Qu 14 Nov '24

14 Nov '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v5.10.226 commit 41cc91e3138fe52f8da92a81bebcd0e6cf488c53 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAVU8A CVE: CVE-2024-47663 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b48aa991758999d4e8f9296c5bbe388f293ef465 upstream. In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://patch.msgid.link/20240703154506.25584-1-amishin@t-argos.ru Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/staging/iio/frequency/ad9834.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/frequency/ad9834.c b/drivers/staging/iio/frequency/ad9834.c index 262c3590e64e..fa0a7056dea4 100644 --- a/drivers/staging/iio/frequency/ad9834.c +++ b/drivers/staging/iio/frequency/ad9834.c @@ -115,7 +115,7 @@ static int ad9834_write_frequency(struct ad9834_state *st, clk_freq = clk_get_rate(st->mclk); - if (fout > (clk_freq / 2)) + if (!clk_freq || fout > (clk_freq / 2)) return -EINVAL; regval = ad9834_calc_freqreg(clk_freq, fout); -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] Some bug fix patches for OLK-5.10 perf
by Yushan Wang 14 Nov '24

14 Nov '24

From: zhangqz <14294317+zhangqizhi3(a)user.noreply.gitee.com> Some bug fix patches for OLK-5.10 perf John Garry (2): perf metricgroup: Fix for metrics containing duration_time perf metricgroup: Fix system PMU metrics tools/perf/util/metricgroup.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) -- 2.33.0

2 3

[PATCH OLK-6.6] nvmet-auth: assign dh_key to NULL after kfree_sensitive
by Li Huafei 14 Nov '24

14 Nov '24

From: Vitaliy Shevtsov <v.shevtsov(a)maxima.ru> stable inclusion from stable-v6.6.60 commit c60af16e1d6cc2237d58336546d6adfc067b6b8f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB37AJ CVE: CVE-2024-50215 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d2f551b1f72b4c508ab9298419f6feadc3b5d791 ] ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 7a277c37d352 ("nvmet-auth: Diffie-Hellman key exchange support") Cc: stable(a)vger.kernel.org Signed-off-by: Vitaliy Shevtsov <v.shevtsov(a)maxima.ru> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/nvme/target/auth.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvme/target/auth.c b/drivers/nvme/target/auth.c index aacc05ec00c2..74791078fdeb 100644 --- a/drivers/nvme/target/auth.c +++ b/drivers/nvme/target/auth.c @@ -101,6 +101,7 @@ int nvmet_setup_dhgroup(struct nvmet_ctrl *ctrl, u8 dhgroup_id) pr_debug("%s: ctrl %d failed to generate private key, err %d\n", __func__, ctrl->cntlid, ret); kfree_sensitive(ctrl->dh_key); + ctrl->dh_key = NULL; return ret; } ctrl->dh_keysize = crypto_kpp_maxsize(ctrl->dh_tfm); -- 2.25.1

2 1

[PATCH OLK-5.10] xfs: Fix missing interval for missing_owner in xfs fsmap
by Zizhi Wo 14 Nov '24

14 Nov '24

mainline inclusion from mainline-v6.11-rc6 commit ca6448aed4f10ad88eba79055f181eb9a589a7b3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB42M2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In the fsmap query of xfs, there is an interval missing problem: [root@fedora ~]# xfs_io -c 'fsmap -vvvv' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [0..7]: static fs metadata 0 (0..7) 8 1: 253:16 [8..23]: per-AG metadata 0 (8..23) 16 2: 253:16 [24..39]: inode btree 0 (24..39) 16 3: 253:16 [40..47]: per-AG metadata 0 (40..47) 8 4: 253:16 [48..55]: refcount btree 0 (48..55) 8 5: 253:16 [56..103]: per-AG metadata 0 (56..103) 48 6: 253:16 [104..127]: free space 0 (104..127) 24 ...... BUG: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 104 107' /mnt [root@fedora ~]# Normally, we should be able to get [104, 107), but we got nothing. The problem is caused by shifting. The query for the problem-triggered scenario is for the missing_owner interval (e.g. freespace in rmapbt/ unknown space in bnobt), which is obtained by subtraction (gap). For this scenario, the interval is obtained by info->last. However, rec_daddr is calculated based on the start_block recorded in key[1], which is converted by calling XFS_BB_TO_FSBT. Then if rec_daddr does not exceed info->next_daddr, which means keys[1].fmr_physical >> (mp)->m_blkbb_log <= info->next_daddr, no records will be displayed. In the above example, 104 >> (mp)->m_blkbb_log = 12 and 107 >> (mp)->m_blkbb_log = 12, so the two are reduced to 0 and the gap is ignored: before calculate ----------------> after shifting 104(st) 107(ed) 12(st/ed) |---------| | sector size block size Resolve this issue by introducing the "end_daddr" field in xfs_getfsmap_info. This records |key[1].fmr_physical + key[1].length| at the granularity of sector. If the current query is the last, the rec_daddr is end_daddr to prevent missing interval problems caused by shifting. We only need to focus on the last query, because xfs disks are internally aligned with disk blocksize that are powers of two and minimum 512, so there is no problem with shifting in previous queries. After applying this patch, the above problem have been solved: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 104 107' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [104..106]: free space 0 (104..106) 3 Fixes: e89c041338ed ("xfs: implement the GETFSMAP ioctl") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> [djwong: limit the range of end_addr correctly] Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Conflicts: fs/xfs/xfs_fsmap.c [Simple context conflicts in the xfs_getfsmap_info structure.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/xfs/xfs_fsmap.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c index 595450a99ae2..001dbc68cf90 100644 --- a/fs/xfs/xfs_fsmap.c +++ b/fs/xfs/xfs_fsmap.c @@ -158,6 +158,7 @@ struct xfs_getfsmap_info { struct fsmap *fsmap_recs; /* mapping records */ struct xfs_buf *agf_bp; /* AGF, for refcount queries */ xfs_daddr_t next_daddr; /* next daddr we expect */ + xfs_daddr_t end_daddr; /* daddr of high fsmap key */ u64 missing_owner; /* owner of holes */ u32 dev; /* device id */ xfs_agnumber_t agno; /* AG number, if applicable */ @@ -172,6 +173,7 @@ struct xfs_getfsmap_dev { int (*fn)(struct xfs_trans *tp, const struct xfs_fsmap *keys, struct xfs_getfsmap_info *info); + sector_t nr_sectors; }; /* Compare two getfsmap device handlers. */ @@ -267,6 +269,18 @@ xfs_getfsmap_helper( return 0; } + /* + * For an info->last query, we're looking for a gap between the last + * mapping emitted and the high key specified by userspace. If the + * user's query spans less than 1 fsblock, then info->high and + * info->low will have the same rm_startblock, which causes rec_daddr + * and next_daddr to be the same. Therefore, use the end_daddr that + * we calculated from userspace's high key to synthesize the record. + * Note that if the btree query found a mapping, there won't be a gap. + */ + if (info->last && info->end_daddr != XFS_BUF_DADDR_NULL) + rec_daddr = info->end_daddr; + /* Are we just counting mappings? */ if (info->head->fmh_count == 0) { if (info->head->fmh_entries == UINT_MAX) @@ -855,17 +869,21 @@ xfs_getfsmap( /* Set up our device handlers. */ memset(handlers, 0, sizeof(handlers)); + handlers[0].nr_sectors = XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks); handlers[0].dev = new_encode_dev(mp->m_ddev_targp->bt_dev); if (use_rmap) handlers[0].fn = xfs_getfsmap_datadev_rmapbt; else handlers[0].fn = xfs_getfsmap_datadev_bnobt; if (mp->m_logdev_targp != mp->m_ddev_targp) { + handlers[1].nr_sectors = XFS_FSB_TO_BB(mp, + mp->m_sb.sb_logblocks); handlers[1].dev = new_encode_dev(mp->m_logdev_targp->bt_dev); handlers[1].fn = xfs_getfsmap_logdev; } #ifdef CONFIG_XFS_RT if (mp->m_rtdev_targp) { + handlers[2].nr_sectors = XFS_FSB_TO_BB(mp, mp->m_sb.sb_rblocks); handlers[2].dev = new_encode_dev(mp->m_rtdev_targp->bt_dev); handlers[2].fn = xfs_getfsmap_rtdev_rtbitmap; } @@ -908,6 +926,7 @@ xfs_getfsmap( info.next_daddr = head->fmh_keys[0].fmr_physical + head->fmh_keys[0].fmr_length; + info.end_daddr = XFS_BUF_DADDR_NULL; info.fsmap_recs = fsmap_recs; info.head = head; @@ -936,8 +955,11 @@ xfs_getfsmap( * low key, zero out the low key so that we get * everything from the beginning. */ - if (handlers[i].dev == head->fmh_keys[1].fmr_device) + if (handlers[i].dev == head->fmh_keys[1].fmr_device) { dkeys[1] = head->fmh_keys[1]; + info.end_daddr = min(handlers[i].nr_sectors - 1, + dkeys[1].fmr_physical); + } if (handlers[i].dev > head->fmh_keys[0].fmr_device) memset(&dkeys[0], 0, sizeof(struct xfs_fsmap)); -- 2.46.1

2 1