From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFE8ECA9EC5 for ; Wed, 30 Oct 2019 10:24:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7664420874 for ; Wed, 30 Oct 2019 10:24:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7664420874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E0C9B6B0007; Wed, 30 Oct 2019 06:24:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBE7A6B0008; Wed, 30 Oct 2019 06:24:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD3E56B000A; Wed, 30 Oct 2019 06:24:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id A8A556B0007 for ; Wed, 30 Oct 2019 06:24:12 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 46343181AF5CA for ; Wed, 30 Oct 2019 10:24:12 +0000 (UTC) X-FDA: 76100065944.24.year94_78f95c43cb37 X-HE-Tag: year94_78f95c43cb37 X-Filterd-Recvd-Size: 2783 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 10:24:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 368FCAE65; Wed, 30 Oct 2019 10:24:10 +0000 (UTC) Date: Wed, 30 Oct 2019 11:24:09 +0100 From: Michal Hocko To: Minchan Kim Cc: Vinayak Menon , linux-mm@kvack.org, kernel-team@android.com Subject: Re: [PATCH] mm: do not free shared swap slots Message-ID: <20191030102409.GZ31513@dhcp22.suse.cz> References: <1571743294-14285-1-git-send-email-vinmenon@codeaurora.org> <20191030002447.GB175126@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030002447.GB175126@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 29-10-19 17:24:47, Minchan Kim wrote: > On Tue, Oct 22, 2019 at 04:51:34PM +0530, Vinayak Menon wrote: > > The following race is observed due to which a processes faulting > > on a swap entry, finds the page neither in swapcache nor swap. This > > causes zram to give a zero filled page that gets mapped to the > > process, resulting in a user space crash later. > > > > Consider parent and child processes Pa and Pb sharing the same swap > > slot with swap_count 2. Swap is on zram with SWP_SYNCHRONOUS_IO set. > > Virtual address 'VA' of Pa and Pb points to the shared swap entry. > > > > Pa Pb > > > > fault on VA fault on VA > > do_swap_page do_swap_page > > lookup_swap_cache fails lookup_swap_cache fails > > Pb scheduled out > > swapin_readahead (deletes zram entry) > > swap_free (makes swap_count 1) > > Pb scheduled in > > swap_readpage (swap_count == 1) > > Takes SWP_SYNCHRONOUS_IO path > > zram enrty absent > > zram gives a zero filled page > > > > Fix this by making sure that swap slot is freed only when swap count > > drops down to one. > > > > Signed-off-by: Vinayak Menon > > Suggested-by: Minchan Kim > > Cc: Michal Hocko > Acked-by: Minchan Kim > > -stable material from v4.15. Which commit does this fix? Fixes: tag would be highly appreciated. -- Michal Hocko SUSE Labs