Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Aug 2023 06:01:58 -0700
From:   Yury Norov <yury.norov@gmail.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     linux-kernel@vger.kernel.org,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH v2 2/6] bitmap: replace _reg_op(REG_OP_ALLOC) with
 bitmap_set()
Message-ID: <ZNYxRtjrxLFJRzyt@yury-ThinkPad>
References: <20230811005732.107718-1-yury.norov@gmail.com>
 <20230811005732.107718-3-yury.norov@gmail.com>
 <ZNX+bponlicM3AFL@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZNX+bponlicM3AFL@smile.fi.intel.com>
Precedence: bulk

On Fri, Aug 11, 2023 at 12:25:02PM +0300, Andy Shevchenko wrote:
> On Thu, Aug 10, 2023 at 05:57:28PM -0700, Yury Norov wrote:
> > _reg_op(REG_OP_ALLOC) duplicates bitmap_set(). Fix it.
> 
> ...
> 
> >  int bitmap_allocate_region(unsigned long *bitmap, unsigned int pos, int order)
> >  {
> > +	unsigned int nbits = pos + BIT(order);
> 
> Shouldn't this be unsigned long?
> As the prototype of the used later unsigned long find_next_bit().

Linux doesn't support bitmaps longer than 2^32 bits. I really doubt
such huge bitmaps would ever exist, but if that will happen, too many
bitmap functions will have to be revisited.

For the reference, check the code of __reg_op(), which I remove in the
series - all indexes and offsets are int's there.

Thanks,
Yury
 
> >  	if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
> >  		return -EBUSY;
> > -	return __reg_op(bitmap, pos, order, REG_OP_ALLOC);
> > +	bitmap_set(bitmap, pos, nbits);
> > +	return 0;
> >  }
> 
> -- 
> With Best Regards,
> Andy Shevchenko
>