Messages in this thread | | | Date | Sat, 12 Sep 2009 12:17:49 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [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 | |