lkml.org 
[lkml]   [2009]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: fix hugetlb bug due to user_shm_unlock call
On Fri, 11 Sep 2009, Mike Frysinger wrote:
> On Mon, Aug 24, 2009 at 11:30, Hugh Dickins wrote:
> >
> >  no_id:
> > +       if (shp->mlock_user)    /* shmflg & SHM_HUGETLB case */
> > +               user_shm_unlock(size, shp->mlock_user);
> >        fput(file);
> >  no_file:
> >        security_shm_free(shp);
>
> this breaks on no-mmu systems due to user_shm_unlock() being
> mmu-specific. normally gcc is smart enough to do dead code culling so
> it hasnt caused problems, but not here. hugetlb support is not
> available on no-mmu systems, so the stubbed hugepage functions prevent
> calls to user_shm_unlock() and such, but here gcc cant figure it out:
>
...
>
> hugetlb_file_setup() expands to nothing and so mlock_user will never
> come back from NULL, but gcc still emits a reference to
> user_shm_unlock() in the error path. perhaps the best thing here is
> to just add an #ifdef ?
> no_id:
> +#ifdef CONFIG_HUGETLB_PAGE
> + /* gcc isn't smart enough to see that mlock_user goes non-NULL
> only by hugetlb */
> if (shp->mlock_user) /* shmflg & SHM_HUGETLB case */
> user_shm_unlock(size, shp->mlock_user);
> +#endif

Many thanks for reporting that, Mike.
Sorry, I've messed up both 2.6.31 final and 2.6.30.6 stable.
My preference is to avoid the #ifdef and use precisely the same
optimization technique as is working for it elsewhere.
Patch follows immediately in separate mail.

Hugh
\
 
 \ /
  Last update: 2009-09-12 13:21    [W:0.079 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site