Received: by 10.223.176.5 with SMTP id f5csp1720955wra; Thu, 8 Feb 2018 02:18:58 -0800 (PST) X-Google-Smtp-Source: AH8x226rV9YRWgXVTOPMfbVgu2HYxDYcz1WrVKwbRvzXliooCe6dPFPTeEUIfmJCaf+dT3JNdwI3 X-Received: by 10.101.97.165 with SMTP id i5mr128337pgv.55.1518085138306; Thu, 08 Feb 2018 02:18:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518085138; cv=none; d=google.com; s=arc-20160816; b=Qs8x5HYxbjvMSAizFTo0lpywIewg69BpFy3QGzBZdpm2rWEGTc/79kvEl+zaLEz7OT fCE22iolDJWNHlOFHYJzYVl3+BmyPEuirdbYfq9R6bj1j7PbtTXzrwE+cfkqXPaQv0Hk DipachITpwZLk++kIS7BPBGu0EnVzPmskB6G3eKIVKn4r+HqZWIB9OubtTmlFl4lBOfJ 27v4wqpp2p74jmeM51MM9OJ55k0laMvsOukiIu6b/WcLsW4W2XS46e5ety3mcfYhfUbo SsihS8G/ufaVx/leXiK7lUtPf/Ot6Cbep7oDBEMgZQFmXVMWyKhaAYAelIo3SaKSAQlT 6H1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=jChV1d4+s6ah2wHV1mvecDSJfTAmcGujZG3Bd0o1ozE=; b=YgLtlx17etRDBlI8TZq84pznvd2fkFhZY61lbJgb96QOCbi4ud9lJpk+YXnpA9eL9z bW+xgfRbANu3t7TC5jGelrRsPLzaUSClXGq6lvgzB0vDfet40A3JK/02icv8Pbe8X7G6 yR4Ia+2LkDkzTfbpoxMO1ZJPPe/77h23KsLXowMppTR0gYh5K427QeE66nnvu4mVxLPL i2fXxuaIHi5Q49tHgJ1BRHPTTzhSyWs+SFgxDARdln/fW+qwDXVd4bhagSnKqLIns/Lm 8VEEJXJdq+BAJK0jb6xuBY8ubYqOeqQEXW/nrszEWMIeJtStvIvKr6t01Wu94n61Mk0T +Hgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ebs6307Q; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j4si2219705pgf.585.2018.02.08.02.18.43; Thu, 08 Feb 2018 02:18:58 -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=fail header.i=@gmail.com header.s=20161025 header.b=ebs6307Q; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751706AbeBHKSB (ORCPT + 99 others); Thu, 8 Feb 2018 05:18:01 -0500 Received: from mail-oi0-f67.google.com ([209.85.218.67]:44890 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750877AbeBHKR6 (ORCPT ); Thu, 8 Feb 2018 05:17:58 -0500 Received: by mail-oi0-f67.google.com with SMTP id b3so3068631oib.11; Thu, 08 Feb 2018 02:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jChV1d4+s6ah2wHV1mvecDSJfTAmcGujZG3Bd0o1ozE=; b=ebs6307QgcELrI5ZtSqRWhDTc9cMijXap0DbekASAdkNxh2oCjb/dHGEmuMRs08+dL SsfkjkAiSbuPQYkEMcPr1LtXHPDA0QLkicca3Ssxfw79IyFaPETz6d2f1t+Q1DVKTKI7 JuJDyegi+OFIBwsf2K76hipPdfaPK/dTa/ZniDbpqQhUq4hRsHYl5ViY+0VzkGAS+55a 4tuytSQqMC0HF6228QLtJE18juI9soQn1hCdoyskM7F3P96Bp14H3BTSVrfLyPz/Yizm rVrAHdaVlWrga5tOS9h/oaoAZ9eV35PW2d2BADsfgSIBTdhlRKuNXgMO5HRrT3VpU8af 7SbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=jChV1d4+s6ah2wHV1mvecDSJfTAmcGujZG3Bd0o1ozE=; b=dSNhAavmedQC6iowujzTMOC61v0GH9zxKaT6FViQsLRbjEcTImR8Z6so/aYVn0CBX9 gG/UwHGsyVXVBLeAOMab/g90RuwCt7EE15fr9R9md825ynbiG3rxDMHjzryr0Vwhhvg6 vALlPDyjiUtIhev3c6BOMGGjjhL9Be3Saen74o88BZfReFzWu3ch083nmDXGH2Dwz/4V LXtMDmgQKMiWjVx2SUtrhs2+zKwHns+iI9ABxx2zPdNo8y6jaurtAKyrMey5o7ZU5R3P D3tDUb0lM2F5dMYRN+f/s7OARpe2zfYyFXUKS0OH8rqJvq+tzUdeXFnClG/blmnYYVD4 ydeA== X-Gm-Message-State: APf1xPAH4LTzdRBl4nBHoLr25TYQQ4UJylvsuLGWxJxEupR5F2CY3lqC OE1TX9loXAmncLmwiyiU2zU= X-Received: by 10.202.106.12 with SMTP id f12mr125960oic.92.1518085077671; Thu, 08 Feb 2018 02:17:57 -0800 (PST) Received: from eng-minchan1.roam.corp.google.com (70-90-167-36-CA.hfc.comcastbusiness.net. [70.90.167.36]) by smtp.gmail.com with ESMTPSA id w101sm1921282ota.45.2018.02.08.02.17.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Feb 2018 02:17:56 -0800 (PST) Date: Thu, 8 Feb 2018 02:17:52 -0800 From: Minchan Kim To: "Huang, Ying" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , 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 Subject: Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled Message-ID: <20180208101752.GA74192@eng-minchan1.roam.corp.google.com> References: <20180207070035.30302-1-ying.huang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207070035.30302-1-ying.huang@intel.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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 >