From: Hugh Dickins <firstname.lastname@example.org> To: Mel Gorman <email@example.com> Cc: Andrew Morton <firstname.lastname@example.org>, Vlastimil Babka <email@example.com>, Li Wang <firstname.lastname@example.org>, Alex Shi <email@example.com>, firstname.lastname@example.org, email@example.com Subject: [PATCH] mm, page_alloc: capture page in task context only Date: Wed, 10 Jun 2020 13:48:59 -0700 (PDT) [thread overview] Message-ID: <alpine.LSU.firstname.lastname@example.org> (raw) While stressing compaction, one run oopsed on NULL capc->cc in __free_one_page()'s task_capc(zone): compact_zone_order() had been interrupted, and a page was being freed in the return from interrupt. Though you would not expect it from the source, both gccs I was using (a 4.8.1 and a 7.5.0) had chosen to compile compact_zone_order() with the ".cc = &cc" implemented by mov %rbx,-0xb0(%rbp) immediately before callq compact_zone - long after the "current->capture_control = &capc". An interrupt in between those finds capc->cc NULL (zeroed by an earlier rep stos). This could presumably be fixed by a barrier() before setting current->capture_control in compact_zone_order(); but would also need more care on return from compact_zone(), in order not to risk leaking a page captured by interrupt just before capture_control is reset. Maybe that is the preferable fix, but I felt safer for task_capc() to exclude the rather surprising possibility of capture at interrupt time. Fixes: 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction") Cc: email@example.com # 5.1+ Signed-off-by: Hugh Dickins <firstname.lastname@example.org> --- mm/page_alloc.c | 1 + 1 file changed, 1 insertion(+) --- 5.8-rc0/mm/page_alloc.c 2020-06-08 14:38:47.298625588 -0700 +++ linux/mm/page_alloc.c 2020-06-10 12:12:34.982950441 -0700 @@ -814,6 +814,7 @@ static inline struct capture_control *ta struct capture_control *capc = current->capture_control; return capc && + in_task() && !(current->flags & PF_KTHREAD) && !capc->page && capc->cc->zone == zone &&
next reply other threads:[~2020-06-10 20:49 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-10 20:48 Hugh Dickins [this message] 2020-06-11 15:43 ` Mel Gorman 2020-06-12 10:30 ` Vlastimil Babka 2020-06-15 21:03 ` Hugh Dickins 2020-06-16 7:45 ` Vlastimil Babka 2020-06-16 8:26 ` [PATCH 1/2] mm, compaction: make capture control handling safe wrt interrupts Vlastimil Babka 2020-06-16 8:26 ` [PATCH 2/2] mm, page_alloc: use unlikely() in task_capc() Vlastimil Babka 2020-06-16 20:29 ` Hugh Dickins 2020-06-17 9:55 ` Vlastimil Babka 2020-06-22 8:58 ` Mel Gorman 2020-06-16 20:18 ` [PATCH 1/2] mm, compaction: make capture control handling safe wrt interrupts Hugh Dickins
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LSU.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] mm, page_alloc: capture page in task context only' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).