On Tue, Aug 25, 2015 at 04:03:22PM +0200, Michal Hocko wrote:
> On Tue 25-08-15 21:26:30, Yaowei Bai wrote:
> [...]
> > static inline int check_new_page(struct page *page)
> > {
> > - const char *bad_reason = NULL;
> > - unsigned long bad_flags = 0;
> > -
> > - if (unlikely(page_mapcount(page)))
> > - bad_reason = "nonzero mapcount";
> > - if (unlikely(page->mapping != NULL))
> > - bad_reason = "non-NULL mapping";
> > - if (unlikely(atomic_read(&page->_count) != 0))
> > - bad_reason = "nonzero _count";
> > - if (unlikely(page->flags & __PG_HWPOISON)) {
> > - bad_reason = "HWPoisoned (hardware-corrupted)";
> > - bad_flags = __PG_HWPOISON;
> > - }
>
> You have removed this check AFAICS. Now looking at 39ad4f19671d ("mm:
I missed that check mistakenly, it should be there.
> check __PG_HWPOISON separately from PAGE_FLAGS_CHECK_AT_*") I am not
> sure it is correct to check it in the free path as it was removed from
> the mask by this commit.
I investigated the commit you mentioned above. AFAICS, that commit assumes
that __PG_HWPOISON check should be performed in the alloc path, while in
the free path it doesn't need to. So there is a bit different in alloc/free
paths.
So Michal, do you think there is any obvious points to refactor these
two functions still? Anyway, appreciate your reviewing.
>
> > - if (unlikely(page->flags & PAGE_FLAGS_CHECK_AT_PREP)) {
> > - bad_reason = "PAGE_FLAGS_CHECK_AT_PREP flag set";
> > - bad_flags = PAGE_FLAGS_CHECK_AT_PREP;
> > - }
> > -#ifdef CONFIG_MEMCG
> > - if (unlikely(page->mem_cgroup))
> > - bad_reason = "page still charged to cgroup";
> > -#endif
> > - if (unlikely(bad_reason)) {
> > - bad_page(page, bad_reason, bad_flags);
> > - return 1;
> > - }
> > - return 0;
> > + return check_one_page(page, PAGE_FLAGS_CHECK_AT_PREP);
> > }
> >
> > static int prep_new_page(struct page *page, unsigned int order, gfp_t
> > gfp_flags,
> > --
> > 1.9.1
> >
>
> --
> Michal Hocko
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
