On 2020/7/13 04:38, Ken Raeburn wrote: > > On 7/12/20 1:49 PM, Coly Li wrote: >> On 2020/7/13 01:47, Coly Li wrote: >>> For some block devices which large capacity (e.g. 8TB) but small io_opt >>> size (e.g. 8 sectors), in bcache_device_init() the stripes number calcu- >>> lated by, >>> DIV_ROUND_UP_ULL(sectors, d->stripe_size); >>> might be overflow to the unsigned int bcache_device->nr_stripes. >>> >>> This patch uses an unsigned long variable to store DIV_ROUND_UP_ULL() >>> and after the value is checked to be available in unsigned int range, >>> sets it to bache_device->nr_stripes. Then the overflow is avoided. >> Hi Ken, >> >> Could you please to try whether these two patches may avoid the kernel >> panic ? I will post the overwhelm stripe_size patch later. >> >> Thanks. >> >> Coly Li >> > I will. But, from inspection: On a 32-bit system, "unsigned long" will > still be 32 bits, but sector_t (u64) will still be 64 bits, so that > assignment will still discard high bits before validation in that > environment. I suggest "unsigned long long" or another specifically > 64-bit type. > > Also, the VDO driver I work on doesn't support 32-bit platforms > currently, so my own testing will be limited to 64-bit platforms. I will post a v2 for your test. Thanks :-) Coly Li
