Re: [PATCH v13 03/12] bcache: initialization of the buddy

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

 



On 12/16/21 12:20 AM, Dan Carpenter wrote:
On Mon, Dec 13, 2021 at 01:05:43AM +0800, Coly Li wrote:
+	/*
+	 * parameters of bitmap_set/clear are unsigned int.
+	 * Given currently size of nvm is far from exceeding this limit,
+	 * so only add a WARN_ON message.
+	 */
+	WARN_ON(BITS_TO_LONGS(ns->pages_total) > UINT_MAX);
+	ns->pages_bitmap = kvcalloc(BITS_TO_LONGS(ns->pages_total),
+				    sizeof(unsigned long), GFP_KERNEL);
BITS_TO_LONGS() has a potential integer overflow if we're talking about
truly giant numbers.  It will return zero if ns->pages_total is more
than U64_MAX - 64.  In that case kvcalloc() will return ZERO_SIZE_PTR.

Btw, kvcalloc() will never let you allocate more than INT_MAX.  It will
trigger a WARN_ONCE().  If people want to allocate more than 2GB of RAM
then they have to plan ahead of time and use vmalloc().


Hi Dan,

Thanks for the informative hint. I discussed with Qiaowen and Jianpeng, we plan to use an extent tree to replace current bitmap to record the free and allocated areas on the NVDIMM namespace. Which may have more efficient memory usage and avoid such size limitation.

Sorry for replying late, I was in travel and followed a sick for whole week. Again, thank you for taking time to look into this, and please continue next time :-)

Coly Li



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux