Received: by 10.223.176.5 with SMTP id f5csp2026210wra; Thu, 8 Feb 2018 07:18:44 -0800 (PST) X-Google-Smtp-Source: AH8x227/oPMytGgxfH4WFxSrqpHXRvH/6I7lS5uoHoRl3Q5l1T0R5bWXWO2fNyUg/dbJO6yRGhz4 X-Received: by 10.98.160.142 with SMTP id p14mr976198pfl.151.1518103124508; Thu, 08 Feb 2018 07:18:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518103124; cv=none; d=google.com; s=arc-20160816; b=wlz5EV543IZ5iHQ0+X1WaGtGMjmg0kt4WOZq/6XQB2bKQKv26Ud1EhpAYgykhv+mGF F741d7HXM3Jn/LbAsXfwOWzyqWclUkgbrf3XHtPsxZ3oxdV/qp6/CIZmB6ZuZZn5ENYz +FPavpzSWGs7IlCpFW92+MMJknI0uHmFsiUqWJNZXfoCcAOit6SpZAFBP+GB+kdsV4iY fW4FLuDZpLM167ukrU7CWKnH0kdpzs8OBJkwt/hw79HMxOLJsjdGN6b/ruRBhXkqAIgQ /5kPOtW1NIrW/8Zwwh6ZcjP0vP2Cj96TqWKaBLrEG62yOU8dfWTSe+fQu5y/43QjwCZV RjwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=zG0M4pgyoilRSJbKsubNYS+S/r7olUhr/M6tiZ31BgE=; b=HmXCgpwnUyzVEnNyO/Rvj/u6nym+kjSxe9mtzzPI8btUfxH44FVPd0zF1O4AMs788o c0v9js5x6Ndr9RW2P0VPKGqgsYHYDYAV4geRXLs9WZcI3036BsA0CDq0Kiq4eoAkJEln O6JW9/XXny36HnOsl810xPYg0f1trM8tMchL53nYvZrFAY5MVtbOi/FhMlSApjIWpS0i XUPnD5+BQYzqCLqX6Uv93opQEu6osTquKxzIRJk3F/or/GgRR1Zfpz540RjbyyuwGhdz oT8btn+zHfS+LWLycsutcM+57gXX4ZVD686rWtplmO3hYQ8Z8sGJHnjNyYBt5Zsob/xA 2BtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FB+AM45V; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t29si78170pfa.359.2018.02.08.07.18.28; Thu, 08 Feb 2018 07:18:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FB+AM45V; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752046AbeBHPRO (ORCPT + 99 others); Thu, 8 Feb 2018 10:17:14 -0500 Received: from mail-qk0-f194.google.com ([209.85.220.194]:42040 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750847AbeBHPRM (ORCPT ); Thu, 8 Feb 2018 10:17:12 -0500 Received: by mail-qk0-f194.google.com with SMTP id f68so6005880qke.9; Thu, 08 Feb 2018 07:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zG0M4pgyoilRSJbKsubNYS+S/r7olUhr/M6tiZ31BgE=; b=FB+AM45V86N1yOh/F+/Bdf/Wdo1uuQceNDLPNTAs9gamztrNoUPNzZMpUz8Ix//gnu I2zBipv/rHKd4x3ZORGvUAlacyK5cKNni0lQBjKdWCuuTJCezqj+Hztydcy6aWqW2RQ5 SjNJj8rUKzVVPaWUyF7PApAaqSMcr+Q/6t9/zyXu38LONXwYxtiq//JrqAA2C/6AiH3p WVjLcJRooofAkKn5gROeMsLUV6daS26iqPiIO3Wd63R8XsYIjMHELpiQQjs4izK3PCWG yuDNmtGly16+cnSv2UesYXdkn1qPV0SzH76hPWJAENkqbL/chSsvGe9HCIwgPjDXvgsE iD3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zG0M4pgyoilRSJbKsubNYS+S/r7olUhr/M6tiZ31BgE=; b=PLLWtURDe9PtoywiONPoaOgGiNWi7rCSSMEVkLY1yDpxlJE/75C6s8nhFm9ZeqMWHl p1u60OLXqUGpgqJcwcPZH1Cr8eJGkZpKFGNML1N3tcmnTxhYdOaaps0Uzv9N7guzixLE jMZ23KKGS3P/bKoxcaJ0kp2mkwzTBjGYHjJMK/gtu+lxKst6xZv43GEDYRhHJUJOv219 5BXJgMuj94UDs00immu8HrqxD9+Sv5xzoOi2lrWte6d2+7ug2v39T8NxmZ8KXv6hG1nk dAYSHwxwV98Bm/+9yYNjpmRtruqz5mNLrGSd6ThSWuJv/wlSbqFhDioLeGrupCpnGgOh 0bZg== X-Gm-Message-State: APf1xPBMSg6fve3TKy2V4oEbCs8lEgqzLG64BQYAMwWm5kg5ZRVo1D9z DNIxcfo3AxeSuevUK6Pwln46ctJ7d5p7pRYIg9Q= X-Received: by 10.55.74.142 with SMTP id x136mr1416051qka.223.1518103031894; Thu, 08 Feb 2018 07:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.23.216 with HTTP; Thu, 8 Feb 2018 07:17:11 -0800 (PST) In-Reply-To: <20180208101752.GA74192@eng-minchan1.roam.corp.google.com> References: <20180207070035.30302-1-ying.huang@intel.com> <20180208101752.GA74192@eng-minchan1.roam.corp.google.com> From: huang ying Date: Thu, 8 Feb 2018 23:17:11 +0800 Message-ID: Subject: Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled To: Minchan Kim Cc: "Huang, Ying" , Andrew Morton , linux-mm@kvack.org, LKML , Konrad Rzeszutek Wilk , Dan Streetman , Seth Jennings , Tetsuo Handa , Shaohua Li , Michal Hocko , Johannes Weiner , Mel Gorman , Shakeel Butt , stable@vger.kernel.org, Sergey Senozhatsky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 8, 2018 at 6:17 PM, Minchan Kim wrote: > On Wed, Feb 07, 2018 at 03:00:35PM +0800, Huang, Ying wrote: >> From: Huang Ying >> >> It was reported by Sergey Senozhatsky that if THP (Transparent Huge >> Page) and frontswap (via zswap) are both enabled, when memory goes low >> so that swap is triggered, segfault and memory corruption will occur >> in random user space applications as follow, >> >> kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000] >> #0 0x00007fc08889ae0d _int_malloc (libc.so.6) >> #1 0x00007fc08889c2f3 malloc (libc.so.6) >> #2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt) >> #3 0x0000560e6005e75c n/a (urxvt) >> #4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt) >> #5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt) >> #6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt) >> #7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt) >> #8 0x0000560e6005cb55 ev_run (urxvt) >> #9 0x0000560e6003b9b9 main (urxvt) >> #10 0x00007fc08883af4a __libc_start_main (libc.so.6) >> #11 0x0000560e6003f9da _start (urxvt) >> >> After bisection, it was found the first bad commit is >> bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped >> out"). >> >> The root cause is as follow. >> >> When the pages are written to swap device during swapping out in >> swap_writepage(), zswap (fontswap) is tried to compress the pages >> instead to improve the performance. But zswap (frontswap) will treat >> THP as normal page, so only the head page is saved. After swapping >> in, tail pages will not be restored to its original contents, so cause >> the memory corruption in the applications. >> >> This is fixed via splitting THP before writing the page to swap device >> if frontswap is enabled. To deal with the situation where frontswap >> is enabled at runtime, whether the page is THP is checked before using >> frontswap during swapping out too. >> >> Reported-and-tested-by: Sergey Senozhatsky >> Signed-off-by: "Huang, Ying" >> Cc: Konrad Rzeszutek Wilk >> Cc: Dan Streetman >> Cc: Seth Jennings >> Cc: Minchan Kim >> Cc: Tetsuo Handa >> Cc: Shaohua Li >> Cc: Michal Hocko >> Cc: Johannes Weiner >> Cc: Mel Gorman >> Cc: Shakeel Butt >> Cc: stable@vger.kernel.org # 4.14 >> Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out") >> >> Changelog: >> >> v2: >> >> - Move frontswap check into swapfile.c to avoid to make vmscan.c >> depends on frontswap. >> --- >> mm/page_io.c | 2 +- >> mm/swapfile.c | 3 +++ >> 2 files changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/mm/page_io.c b/mm/page_io.c >> index b41cf9644585..6dca817ae7a0 100644 >> --- a/mm/page_io.c >> +++ b/mm/page_io.c >> @@ -250,7 +250,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc) >> unlock_page(page); >> goto out; >> } >> - if (frontswap_store(page) == 0) { >> + if (!PageTransHuge(page) && frontswap_store(page) == 0) { > > Why do we need this? > > If frontswap_enabled is enabled but it doesn't support THP, it doesn't allow > cluster allocation by below logic so any THP page shouldn't come this path. > What do I missing now? If frontswap_enabled() becomes true at runtime after swap cluster allocation but before swap_writepage(), this can prevent memory corruption. I know this isn't true now. Because frontswap isn't very dynamic now. But I still think this is good thing to do. Best Regards, Huang, Ying >> set_page_writeback(page); >> unlock_page(page); >> end_page_writeback(page); >> diff --git a/mm/swapfile.c b/mm/swapfile.c >> index 006047b16814..0b7c7883ce64 100644 >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -934,6 +934,9 @@ int get_swap_pages(int n_goal, bool cluster, swp_entry_t swp_entries[]) >> >> /* Only single cluster request supported */ >> WARN_ON_ONCE(n_goal > 1 && cluster); >> + /* Frontswap doesn't support THP */ >> + if (frontswap_enabled() && cluster) >> + goto noswap; >> >> avail_pgs = atomic_long_read(&nr_swap_pages) / nr_pages; >> if (avail_pgs <= 0) >> -- >> 2.15.1 >>