Re: [PATCH 1/2] bcache: avoid nr_stripes overflow in bcache_device_init()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux