[PATCH v2 2/2] ubi: Implement ioctl for detailed erase counters

Zhihao Cheng chengzhihao1 at huawei.com
Tue Dec 3 17:59:15 PST 2024


在 2024/12/4 3:09, Richard Weinberger 写道:
> Rickard,
> 
> ----- Ursprüngliche Mail -----
>> Von: "Rickard X Andersson" <rickard.andersson at axis.com>
>> An: "richard" <richard at nod.at>, "chengzhihao1" <chengzhihao1 at huawei.com>, "linux-mtd" <linux-mtd at lists.infradead.org>,
>> "rickard314 andersson" <rickard314.andersson at gmail.com>
>> CC: "Rickard X Andersson" <rickard.andersson at axis.com>, "kernel" <kernel at axis.com>
>> Gesendet: Mittwoch, 27. November 2024 10:10:50
>> Betreff: [PATCH v2 2/2] ubi: Implement ioctl for detailed erase counters
> 
>> Currently, "max_ec" can be read from sysfs, which provides a limited
>> view of the flash device’s wear. In certain cases, such as bugs in
>> the wear-leveling algorithm, specific blocks can be worn down more
>> than others, resulting in uneven wear distribution. Also some use cases
>> can wear the erase blocks of the fastmap area more heavily than other
>> parts of flash.
>> Providing detailed erase counter values give a better understanding of
>> the overall flash wear and is needed to be able to calculate for example
>> expected life time.
>> There exists more detailed info in debugfs, but this information is
>> only available for debug builds.
>>
>> Signed-off-by: Rickard Andersson <rickard.andersson at axis.com>
>> ---
>> drivers/mtd/ubi/cdev.c | 96 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 96 insertions(+)
>>
>> diff --git a/drivers/mtd/ubi/cdev.c b/drivers/mtd/ubi/cdev.c
>> index 0d8f04cf03c5..681cf8526e2f 100644
>> --- a/drivers/mtd/ubi/cdev.c
>> +++ b/drivers/mtd/ubi/cdev.c
>> @@ -828,6 +828,96 @@ static int rename_volumes(struct ubi_device *ubi,
>> 	return err;
>> }
>>
>> +
>> +static int ubi_get_ec_info(struct ubi_device *ubi, struct ubi_ecinfo_req __user
>> *ureq)
>> +{
>> +	struct ubi_ecinfo_req req;
>> +	struct ubi_wl_entry *wl;
>> +	int i;
>> +	int peb;
>> +	int end_peb;
>> +	int err = 0;
>> +	int max_elem;
>> +	int32_t *erase_counters;
>> +
>> +	/* Copy the input arguments */
>> +	err = copy_from_user(&req, ureq, sizeof(struct ubi_ecinfo_req));
>> +	if (err) {
>> +		err = -EFAULT;
>> +		goto out;

How about directly returning function?
>> +	}
>> +
>> +	/* Check input arguments */
>> +	if (req.length <= 0 || req.start < 0) {
>> +		err = -EINVAL;
>> +		goto out;
>> +	}
>> +
>> +	max_elem = req.length;
>> +
>> +	/* We can not read more than the total amount of PEBs */
>> +	if (max_elem > ubi->peb_count)
>> +		max_elem = ubi->peb_count;
>> +
>> +	/* Check for overflow */
>> +	if (req.start + max_elem < req.start) {
> 
> You can use check_add_overflow() or a similar helper.
> 
>> +		err = -EINVAL;
>> +		goto out;
>> +	}
>> +
>> +	erase_counters = kmalloc_array(max_elem,
>> +				       sizeof(int32_t),
>> +				       GFP_KERNEL);
> 
> I don't think this temporally buffer is needed.
> Especially since the allocation is userspace controlled and unbound,
> it can be a problem later.
> 
>> +	if (!erase_counters) {
>> +		err = -ENOMEM;
>> +		goto out;
>> +	}
>> +
>> +	end_peb = req.start + max_elem;
>> +	if (end_peb > ubi->peb_count)
>> +		end_peb = ubi->peb_count;
>> +
>> +	i = 0;
>> +	for (peb = req.start; peb < end_peb; i++, peb++) {
>> +		int ec;
>> +
>> +		if (ubi_io_is_bad(ubi, peb)) {
>> +			erase_counters[i] = UBI_UNKNOWN;
>> +			continue;
>> +		}
>> +
>> +		spin_lock(&ubi->wl_lock);
>> +
>> +		wl = ubi->lookuptbl[peb];
>> +		if (wl)
>> +			ec = wl->ec;
>> +		else
>> +			ec = UBI_UNKNOWN;
>> +
>> +		spin_unlock(&ubi->wl_lock);
>> +
>> +		erase_counters[i] = ec;
> 
> My idea way using there something like __put_user() to directly write the
> record to userspace memory.
> With an access_ok() check before you can make sure that the whole destination
> is within userspace.

Agree. Hi, Rickard. You can have a look at ioctl_fiemap -> ext4_fiemap 
-> iomap_fiemap -> iomap_to_fiemap -> fiemap_fill_next_extent, just like 
the suggestions from Richard. No extra memory allocations, copy results 
to userspace one by one.
> 
> Thanks,
> //richard
> 
> .
> 




More information about the linux-mtd mailing list