linux-kernel - RE: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Sep 2015 02:50: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 v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram

On Fri, Sep 25, 2015 at 7:30 AM +0800, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, September 25, 2015 7: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 v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
> 
> On Wed, 2015-09-23 at 00:28 -0500, Zhao Qiang-B45475 wrote:
> > On Wen, Sep 23, 2015 at 12:03 AM +0800, Wood Scott-B07421 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 23, 2015 12:03 PM
> > > 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 v10 3/5] CPM/QE: use genalloc to manage CPM/QE
> > > muram
> > >
> > > On Tue, 2015-09-22 at 21:20 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wen, Sep 23, 2015 at 8:19 AM +0800, Wood Scott-B07421 wrote:
> > > >
> > > > > > > >  {
> > > > > > > > - int ret;
> > > > > > > > +
> > > > > > > > + unsigned long start;
> > > > > > > >   unsigned long flags;
> > > > > > > > + unsigned long size_alloc = size; struct muram_block
> > > > > > > > + *entry; int end_bit; int order =
> > > > > > > > + muram_pool->min_alloc_order;
> > > > > > > >
> > > > > > > >   spin_lock_irqsave(&cpm_muram_lock, flags);
> > > > > > > > - ret = rh_free(&cpm_muram_info, offset);
> > > > > > > > + end_bit = (offset >> order) + ((size + (1UL << order) -
> > > > > > > > + 1)
> > > > > > > > + >>
> > > > > > > order);
> > > > > > > > + if ((offset + size) > (end_bit << order))
> > > > > > > > +         size_alloc = size + (1UL << order);
> > > > > > >
> > > > > > > Why do you need to do all these calculations here?
> > > > > >
> > > > > > So do it in gen_pool_fixed_alloc?
> > > > >
> > > > > Could you explain why they're needed at all?
> > > >
> > > > Why it does the calculations?
> > > > If the min block of gen_pool is 8 bytes, and I want to allocate a
> > > > Region with offset=7, size=8bytes, I actually need block 0 and
> > > > block 1, And the allocation will give me block 0.
> > >
> > > How can you have offset 7 if the minimum order is 2 bytes?
> >
> > Offset has no relationship with minimum order, it is not decided by
> > minimum order.
> 
> All allocations begin and end on a multiple of the minimum order.

So it is the problem. CPM require to allocate a specific region,
who can ensure that the specific is just the begin of minimum order.
So the algo will find the first block covering the specific region's 
Start address, then because my specific region's start address is not equal
To the address returned by algo, the end address is not equal to my 
specific region's end address, so the calculation is to keep the end 
address larger than specific region's end address.

> 
> > I want to allocate a specific region with offset=7, then algo to
> > calculate the block bit.
> > And I just take it for example, it is not I really need to region
> offset=7.
> 
> Do you really need any fixed allocations that begin on an odd address?

Maybe I don’t need an odd address, but the calculation is needed in case.

> 
> > So, now minimum order is 2 bytes. If offset=7, size=4bytes needed, it
> > actually allocate 6-12 to me.
> 
> Why 6-12 and not 6-10?

It is just a example

-Zhao