On Sat, Apr 18, 2015 at 06:12:56PM -0400, Linus Torvalds wrote: > On Sat, Apr 18, 2015 at 5:59 PM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Apr 18, 2015 at 5:56 PM, Kirill A. Shutemov > > <kirill@xxxxxxxxxxxxx> wrote: > >> > >> Andrea has already seen the bug and pointed to 8d63d99a5dfb as possible > >> cause. I don't see why the commit could broke anything, but it worth > >> trying to revert and test. > > > > Ahh, yes, that does look like a more likely culprit. > > That said, I do think we should likely also do that > > WARN_ON_ONCE(PageHuge(page)); > > in __put_compound_page() rather than just silently saying "no refcount > changes for this magical case that shouldn't even happen". If it > shouldn't happen, then we should warn about it, not try to ":handle" > some case that shouldn't happen and shouldn't matter. __put_compound_page() can be called for PageHuge, so I don't think that adding WARN_ON_ONCE(PageHuge) is good (, which makes every hugetlb user see the warning once in every boot.) What I thought when I suggested this code was that __page_cache_release() seems not to be intended for hugetlb, but I'm not sure. __put_compound_page() does work without this !PageHuge check which is only for potential change in __put_compound_page(). So if everyone thinks that __put_compound_page() is stable and will never change in the future, this !PageHuge check is totally unnecessary. > Let's not play games in this area. This code has been stable for many > years, why are we suddenly doing random things here? There's something > to be said for "if it ain't broke..", and there's *definitely* a lot > to be said for "let's not complicate this even more". OK, so could you please try simply reverting 822fc61367f0 ? Thanks, Naoya Horiguchi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href