linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Coly Li <colyli@suse.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: axboe@kernel.dk, linux-bcache@vger.kernel.org,
	linux-block@vger.kernel.org, Jianpeng Ma <jianpeng.ma@intel.com>,
	kernel test robot <lkp@intel.com>,
	Qiaowei Ren <qiaowei.ren@intel.com>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH v13 03/12] bcache: initialization of the buddy
Date: Tue, 28 Dec 2021 13:12:48 +0800	[thread overview]
Message-ID: <f713d122-07af-435f-5716-36351936695c@suse.de> (raw)
In-Reply-To: <20211215162005.GA1978@kadam>

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

  reply	other threads:[~2021-12-28  5:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-12 17:05 [PATCH v13 00/12] bcache for 5.17: enable NVDIMM for bcache journal Coly Li
2021-12-12 17:05 ` [PATCH v13 01/12] bcache: add initial data structures for nvm pages Coly Li
2021-12-12 17:05 ` [PATCH v13 02/12] bcache: initialize the nvm pages allocator Coly Li
2021-12-12 19:34   ` Jens Axboe
2021-12-28  5:29     ` Coly Li
2021-12-12 17:05 ` [PATCH v13 03/12] bcache: initialization of the buddy Coly Li
2021-12-12 20:10   ` Jens Axboe
2021-12-28  5:29     ` Coly Li
2021-12-15 16:20   ` Dan Carpenter
2021-12-28  5:12     ` Coly Li [this message]
2021-12-12 17:05 ` [PATCH v13 04/12] bcache: bch_nvmpg_alloc_pages() " Coly Li
2021-12-12 20:14   ` Jens Axboe
2021-12-28  5:29     ` Coly Li
2021-12-12 17:05 ` [PATCH v13 05/12] bcache: bch_nvmpg_free_pages() of the buddy allocator Coly Li
2021-12-12 20:16   ` Jens Axboe
2021-12-28  5:29     ` Coly Li
2022-02-21 12:36   ` yukuai (C)
2022-02-22  5:03     ` Ma, Jianpeng
2021-12-12 17:05 ` [PATCH v13 06/12] bcache: get recs list head for allocated pages by specific uuid Coly Li
2021-12-12 20:18   ` Jens Axboe
2021-12-12 17:05 ` [PATCH v13 07/12] bcache: use bucket index to set GC_MARK_METADATA for journal buckets in bch_btree_gc_finish() Coly Li
2021-12-12 17:05 ` [PATCH v13 08/12] bcache: add BCH_FEATURE_INCOMPAT_NVDIMM_META into incompat feature set Coly Li
2021-12-12 17:05 ` [PATCH v13 09/12] bcache: initialize bcache journal for NVDIMM meta device Coly Li
2021-12-12 17:05 ` [PATCH v13 10/12] bcache: support storing bcache journal into " Coly Li
2021-12-12 17:05 ` [PATCH v13 11/12] bcache: read jset from NVDIMM pages for journal replay Coly Li
2021-12-12 17:05 ` [PATCH v13 12/12] bcache: add sysfs interface register_nvdimm_meta to register NVDIMM meta device Coly Li
2021-12-12 20:20 ` [PATCH v13 00/12] bcache for 5.17: enable NVDIMM for bcache journal Jens Axboe
2021-12-28  5:29   ` Coly Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f713d122-07af-435f-5716-36351936695c@suse.de \
    --to=colyli@suse.de \
    --cc=axboe@kernel.dk \
    --cc=dan.carpenter@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jianpeng.ma@intel.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=qiaowei.ren@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).