Re: [uClinux-dev] v3.15-rc1 slab allocator broken on m68knommu (coldfire)

[Joonsoo Kim <iamjoonsoo.kim@lge.com>]

On Wed, Apr 16, 2014 at 10:44:11AM -0700, Steven King wrote:
> On Wednesday 16 April 2014 9:06:57 am Geert Uytterhoeven wrote:
> > Hi Steven,
> >
> > On Wed, Apr 16, 2014 at 5:47 PM, Steven King <sfking@fdwdc.com> wrote:
> > > --- a/mm/slab.c
> > > +++ b/mm/slab.c
> > > @@ -2572,13 +2572,13 @@ static void *alloc_slabmgmt(struct kmem_cache
> > > *cachep, return freelist;
> > >  }
> > >
> > > -static inline freelist_idx_t get_free_obj(struct page *page, unsigned
> > > char idx) +static inline freelist_idx_t get_free_obj(struct page *page,
> > > unsigned int idx) {
> > >         return ((freelist_idx_t *)page->freelist)[idx];
> > >  }
> > >
> > >  static inline void set_free_obj(struct page *page,
> > > -                                       unsigned char idx, freelist_idx_t
> > > val) +                                       unsigned int idx,
> > > freelist_idx_t val) {
> > >         ((freelist_idx_t *)(page->freelist))[idx] = val;
> > >  }
> > >
> > >
> > > then v3.15-rc1 will boot using the slab allocator.
> >
> > Is "idx" ever larger than 255?
> >
> > Gr{oetje,eeting}s,
> 
> Yes.  If I stick
> 
>         if (idx > 255)
>                 pr_info("%s %d\n", __func__, idx);
> 
> in get_free_obj and set_free_obj and see values for idx up into the 400s.

Hello,

Yes, it's my mistake. idx can be larger than 255 if freelist_idx_t is
unsigned short. So unsigned char idx isn't appropriate here. Your
system's PAGE_SIZE may be 2^13, so freelist_idx_t would be unsigned short
and idx will be larger than 255.

Your fix looks good to me, so could you send it quickly to Pekka with
some description? If you don't have enough time to do it, I can handle it.

Really thanks for notifying this issue.

Thanks.