[dm-devel] [PATCH 4/7] dm: introduce dm_kvmalloc

[Mikulas Patocka]

On Mon, 6 Jul 2015, Vivek Goyal wrote:

> On Mon, Jul 06, 2015 at 09:04:34AM -0400, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 6 Jul 2015, Vivek Goyal wrote:
> > 
> > > On Fri, Jul 03, 2015 at 04:59:54PM -0400, Mikulas Patocka wrote:
> > > [..]
> > > > Index: linux-4.1/drivers/md/dm-table.c
> > > > ===================================================================
> > > > --- linux-4.1.orig/drivers/md/dm-table.c	2015-07-02 19:21:16.000000000 +0200
> > > > +++ linux-4.1/drivers/md/dm-table.c	2015-07-02 19:28:18.000000000 +0200
> > > > @@ -131,6 +131,43 @@ static int setup_btree_index(unsigned in
> > > >  	return 0;
> > > >  }
> > > >  
> > > > +void *dm_kvmalloc_node(size_t size, gfp_t gfp, int node)
> > > > +{
> > > > +	void *p;
> > > > +	unsigned uninitialized_var(noio_flag);
> > > > +
> > > > +	/* vmalloc doesn't support no-wait allocations */
> > > > +	WARN_ON(!(gfp & __GFP_WAIT));
> > > > +
> > > 
> > > Should this WARN_ON() be moved after kmalloc(). This should be triggered
> > > only if we use vmalloc().
> > > 
> > > Thanks
> > > Vivek
> > 
> > I think not - it would just hide the problematic usage. Warning always is 
> > better than warning with some low probability when kmalloc fails.
> 
> Ok, so you don't want this function to be used if __GFP_WAIT is not
> specified and caller needs to call kmalloc() directly in that case. If
> that's the intent, it is fine.

Yes, if the caller doesn't specify __GFP_WAIT, he should use kmalloc 
directly.

Mikulas

> Thanks
> Vivek
>