lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7c001e77-de13-e2e2-83b1-ccfdec6cef98@huawei.com>
Date: Thu, 1 Aug 2024 09:59:52 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Nikhil Kashyap H R <nikhil.kashyap@...ve-global.com>,
	<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Investigation Request - Strange PEB Reservation Behavior in UBI

在 2024/7/31 17:53, Nikhil Kashyap H R 写道:
> Dear Team,
> I am writing to request an investigation into a strange issue we have 
> observed regarding PEB reservation for bad block management in UBI. For 
> context, our system uses MT29FxxG NAND flash chips with a minimum of 
> 4016 valid blocks (NVB) per LUN out of a total of 4096 blocks.
> We have noticed that when using the CONFIG_MTD_UBI_BEB_LIMIT parameter, 
> which is typically calculated as 1024 * (1 - MinNVB / TotalNVB) = 20 
> PEBs, UBI is reserving significantly more PEBs than expected. Instead of 
> the expected 20 PEBs, UBI is reserving around 160 PEBs per LUN, which is 
> approximately 8 times more than it should be.
> To work around this issue, we have set the CONFIG_MTD_UBI_BEB_LIMIT 
> parameter to 3, which corresponds to ~91 reserved PEBs per LUN. However, 
> this strange 8x multiplier effect is concerning and requires further 
> investigation. Additionally, we have observed crashes in our system and 
> suspect that the over-reservation of PEBs for bad block handling may be 
> related to these issues.
> We would like to understand the root cause of the crashes and how the 
> excessive PEB reservation might be contributing to the problem. We have 
> some similar questions related to the PEB's usage in UBI operations:
> Why is UBI reserving significantly more PEBs for bad block handling than 
> expected when using the CONFIG_MTD_UBI_BEB_LIMIT parameter?

Just like the description in drivers/mtd/ubi/Kconfig, 
CONFIG_MTD_UBI_BEB_LIMIT specifies the maximum bad physical eraseblocks 
UBI expects on the MTD device (per 1024 eraseblocks). For example, if we 
attach an UBI device to a mtd partition(from a nandchip with 8192 PEBs), 
UBI will keep 8192/1024 * CONFIG_MTD_UBI_BEB_LIMIT[default val is 20] = 
160 PEBs for bad block reservation.

config MTD_UBI_BEB_LIMIT 

         int "Maximum expected bad eraseblock count per 1024 
eraseblocks"
         default 20 

         range 0 768 

         help 

           This option specifies the maximum bad physical eraseblocks 
UBI
           expects on the MTD device (per 1024 eraseblocks). If the 
underlying
           flash does not admit of bad eraseblocks (e.g. NOR flash), 
this value
           is ignored. 

 

           NAND datasheets often specify the minimum and maximum NVM 
(Number of
           Valid Blocks) for the flashes' endurance lifetime. The 
maximum
           expected bad eraseblocks per 1024 eraseblocks then can be 
calculated
           as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most 
NANDs
           (MaxNVB is basically the total count of eraseblocks on the 
chip).
 

           To put it differently, if this value is 20, UBI will try to 
reserve
           about 1.9% of physical eraseblocks for bad blocks handling. 
And that
           will be 1.9% of eraseblocks on the entire NAND chip, not just 
the MTD
           partition UBI attaches. This means that if you have, say, a 
NAND
           flash chip admits maximum 40 bad eraseblocks, and it is split 
on two
           MTD partitions of the same size, UBI will reserve 40 
eraseblocks when
           attaching a partition.

> 1A) The typical calculation suggests reserving 20 PEBs, but UBI is 
> reserving 8 times more, around 160 PEBs per LUN. What is causing this 8x 
> multiplier effect?
> Does the issue of over-reserving PEBs only occur when multiple NAND 
> partitions are grouped under the same parent MTD device, as is the case 
> with the custom driver? Or can it also happen with a single NAND 
> partition per MTD device?
> Is the over-reservation of PEBs for bad block handling related to the 
> crashes observed in the system? If so, what is the root cause of the 
> crashes and how does the excessive PEB reservation contribute to the issue?
> What is the expected behavior of UBI when reserving PEBs for bad block 
> management based on the CONFIG_MTD_UBI_BEB_LIMIT parameter? Why is UBI 
> not following the typical calculation in this case?
> Are there any known bugs, issues or unexpected behaviors in the UBI 
> subsystem or NAND flash drivers that could explain the observed PEB 
> reservation problem? If so, are there any workarounds or fixes available?
> We would greatly appreciate if you could investigate this issue and 
> provide us with your findings and recommendations.
> Thank you for your assistance.
> Best regards,
> Nikhil Kashyap H R
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> .


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ