lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SN1PR0301MB1550B50280B245F7CDE8BB069B500@SN1PR0301MB1550.namprd03.prod.outlook.com>
Date:	Fri, 11 Sep 2015 02:25:17 +0000
From:	Zhao Qiang <qiang.zhao@...escale.com>
To:	Scott Wood <scottwood@...escale.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"lauraa@...eaurora.org" <lauraa@...eaurora.org>,
	Xiaobo Xie <X.Xie@...escale.com>,
	"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
	Li Leo <LeoLi@...escale.com>,
	"paulus@...ba.org" <paulus@...ba.org>
Subject: RE: [PATCH V7 1/3] genalloc:support memory-allocation with
 bytes-alignment to genalloc

On Fri, 2015-09-11 at 10:15AM -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 10:15 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org;
> lauraa@...eaurora.org; Xie Xiaobo-R63061; benh@...nel.crashing.org; Li
> Yang-Leo-R58472; paulus@...ba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Thu, 2015-09-10 at 21:09 -0500, Zhao Qiang-B45475 wrote:
> > On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Friday, September 11, 2015 6:07 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org;
> > > lauraa@...eaurora.org; Xie Xiaobo-R63061; benh@...nel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@...ba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, September 10, 2015 12:38 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org;
> > > > > lauraa@...eaurora.org; Xie Xiaobo-R63061;
> > > > > benh@...nel.crashing.org; Li Yang-Leo-R58472; paulus@...ba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > > > To: Zhao Qiang-B45475
> > > > > > > Cc: linux-kernel@...r.kernel.org;
> > > > > > > linuxppc-dev@...ts.ozlabs.org; lauraa@...eaurora.org; Xie
> > > > > > > Xiaobo-R63061; benh@...nel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > paulus@...ba.org
> > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > >
> > > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421
> wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Wood Scott-B07421
> > > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > > > To: Zhao Qiang-B45475
> > > > > > > > > Cc: linux-kernel@...r.kernel.org;
> > > > > > > > > linuxppc-dev@...ts.ozlabs.org; lauraa@...eaurora.org;
> > > > > > > > > Xie Xiaobo-R63061; benh@...nel.crashing.org; Li
> > > > > > > > > Yang-Leo-R58472; paulus@...ba.org
> > > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > > > >
> > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > > > Bytes alignment is required to manage some special
> > > > > > > > > > RAM, so add gen_pool_first_fit_align to genalloc,
> > > > > > > > > > meanwhile add gen_pool_alloc_data to pass data to
> > > > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a
> > > > > > > > > > wrapper)
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Zhao Qiang <qiang.zhao@...escale.com>
> > > > > > > > > > ---
> > > > > > > > > > Changes for v6:
> > > > > > > > > >       - patches set v6 include a new patch because of
> using
> > > > > > > > > >       - genalloc to manage QE MURAM, patch 0001 is the
> new
> > > > > > > > > >       - patch, adding bytes alignment for allocation
> > > > > > > > > > for
> > > use.
> > > > > > > > > > Changes for v7:
> > > > > > > > > >       - cpm muram also need to use genalloc to manage,
> > > > > > > > > > it
> > > has
> > > > > > > > > >         a function to reserve a specific region of
> muram,
> > > > > > > > > >         add offset to genpool_data for start addr to
> > > > > > > > > > be
> > > > > allocated.
> > > > > > > > >
> > > > > > > > > This seems to be describing more than just the changes
> > > > > > > > > in this
> > > > > patch.
> > > > > > > > > What does also handling cpm have to do with this patch?
> > > > > > > > > Are you adding support for reserving a specific region
> > > > > > > > > in this patch?  I don't see it, and in any case it
> > > > > > > > > should go in a
> > > different patch.
> > > > > > > >
> > > > > > > > Yes, I added. The code below can support the function.
> > > > > > > >       offset_bit = (alignment->offset + (1UL << order) -
> > > > > > > > 1) >>
> > > > > order;
> > > > > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > > > > offset_bit,
> > > > > > > nr,
> > > > > > > >                         align_mask);
> > > > > > > >
> > > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to
> > > > > > > > allocate muram from a Specific offset. So I add the code
> > > > > > > > and add offset to
> > > > > struct data.
> > > > > > >
> > > > > > > I thought the offset was related to the previous discussion
> > > > > > > of checking for allocation failure.  Are you using it to
> > > > > > > implement alloc_fixed()?  If so, please don't.  Besides the
> > > > > > > awkward implementation (what does it logically have to do
> > > > > > > with gen_pool_first_fit_align?), it does not appear to be
> > > > > > > correct -
> > > > > > > - what happens with multiple chunks?  What happens if part
> > > > > > > of the region the caller is trying to reserve is already
> taken?
> > > > > > > Implement a proper function to reserve a fixed genalloc
> region.
> > > > > > >
> > > > > > The offset is which allocation block address need to be larger
> > > > > > than, Not equal to, it really like the parameter start of the
> > > > > > algo(the bitnumber To start searching at).
> > > > >
> > > > > cpm_muram_alloc_fixed() is not "search starting at this offset".
> > > > > It is "reserve this exact range or fail".
> > > >
> > > > Yes, you are right! How about to add a new algo into genalloc to
> > > > search At offset, then handle it in muram layer, if the address
> > > > return from genalloc Is not equal to offset, return negative number?
> > >
> > > If you're adding a new algorithm, why not make it actually do what
> > > you want rather than adding something different and fixing it up in
> > > the caller?
> >
> > Because I'm not sure whether it is proper to add a "offset searching
> at"
> > algo.
> 
> Again, "offset searching at" is not what we want anyway.  What we want is
> "allocate this range or fail".  Why would it be improper to have such an
> algorithm?

Yes, I mean "allocate this range or fail", just type wrong.
I will push another version and modify it.

> 
> -Scott

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ