Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1534786

Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted

Show all headers | View raw

On Fri 02-12-16 09:49:33, Mel Gorman wrote:
> On Fri, Dec 02, 2016 at 09:12:17AM +0100, Michal Hocko wrote:
> > On Fri 02-12-16 00:22:43, Mel Gorman wrote:
> > > Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
> > > defer debugging checks of pages allocated from the PCP") will allow the
> > > per-cpu list counter to be out of sync with the per-cpu list contents
> > > if a struct page is corrupted. This patch keeps the accounting in sync.
> > >
> > > Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from the PCP")
> > > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > > cc: stable@vger.kernel.org [4.7+]
> > 
> > I am trying to think about what would happen if we did go out of sync
> > and cannot spot a problem. Vlastimil has mentioned something about
> > free_pcppages_bulk looping for ever but I cannot see it happening right
> > now.
> 
> free_pcppages_bulk can infinite loop if the page count is positive and
> there are no pages. While I've only seen this during development, a
> corrupted count loops here
> 
>                 do {
>                         batch_free++;
>                         if (++pindex == NR_PCP_LISTS)
>                                 pindex = 0;
>                         list = &pcp->lists[pindex];
>                 } while (list_empty(list));
> 
> It would only be seen in a situation where struct page corruption was
> detected so it's rare.

OK, I was apparently sleeping when responding. I focused on t he outer
loop and that should just converge. But it is true that this inner loop
can just runaway... Could you add that to the changelog please? This
definitely warrants stable backport.

Thanks!

-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/2] High-order per-cpu cache v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 01:30 +0100
  [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 01:30 +0100
    Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-12-02 05:00 +0100
      Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Vlastimil Babka <vbabka@suse.cz> - 2016-12-02 07:20 +0100
        Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-12-02 10:40 +0100
          Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Michal Hocko <mhocko@kernel.org> - 2016-12-02 11:20 +0100
            Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 12:10 +0100
    Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Michal Hocko <mhocko@kernel.org> - 2016-12-02 09:20 +0100
      Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 10:50 +0100
        Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in  sync if struct page is corrupted Michal Hocko <mhocko@kernel.org> - 2016-12-02 11:10 +0100
  [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 01:30 +0100
    Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-02 07:10 +0100
      Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Michal Hocko <mhocko@kernel.org> - 2016-12-02 09:30 +0100
        Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-05 04:10 +0100
      Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-02 10:10 +0100
        Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-05 04:10 +0100
          Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-05 11:00 +0100
            Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-12-06 03:50 +0100
              Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Mel Gorman <mgorman@techsingularity.net> - 2016-12-06 15:00 +0100
    Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 Michal Hocko <mhocko@kernel.org> - 2016-12-02 09:30 +0100

csiph-web