Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp49704imu; Mon, 19 Nov 2018 17:30:49 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vu7CSBcy/mIIVwmyjQS5M7WLPvAtsi83j6YI+GKxOOjVYhtPxrP21tAkTlqT1WFLtee18m X-Received: by 2002:a63:9845:: with SMTP id l5mr67207pgo.142.1542677448994; Mon, 19 Nov 2018 17:30:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542677448; cv=none; d=google.com; s=arc-20160816; b=V+TBpgNTGixTUaQEsIyvYsMd/JxlytEKn6319yJziq+2e1nQu4rd/vIldRqHwe+Zk8 vQFhEAW4CCgaHxqFUzyi2XUcj9Y0xodQITBv+CaImcj6fJfE4v5x23cNhLiSoirUwPG3 dyK+UVJhatVTvc94r6NWEx12aZC9j8YXnp5kbMBLJ00CT8l6FGXfD1LHTinKI2fH8Ptj Ea3HINXvlqkzeNuUx/ECKkP2gz+SlvRAcpQerD/PrvxCQjNRWEEYco6CDtjAjBH8mI7J wFvbOzn6FaOVJpRxWwKbobtfb0qMr8JDRASE6iUc+rTX1GZWVH0qKD5iJh0m0jAHIPPv sFIQ== 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; bh=V3m6gtQ1iRlWcRSMq0w2qWBRsEA6IUH9wDb9KBQbc1w=; b=cgeSxt0YEYnoB7Y/7jqG58JmdV0ERQw0J7Nf5A1+UYQEbbJjCR18in5oNx10t/48w8 TcLBe0r0V2XTIaJ9sfnwVABgxlepbtjmPdzpmtl8H7aAH6woBaLzLu/ERZ0Smzeko5TH vzXG5G0AVAb9YEj3Nk/OBeHurH9PfDanrq/j83f/Ngr5+dDIVZBv4BC3oD9iF28B+bW8 YlhtIHhLvpwZurGJ7HMjv4O/XdxSeqj1u9MLKlN1YlcoAjPQANkMXXVB+fr6n7E4ke7U YQqvt8x6oo64IG1CuO0oR0OzduBNRNOH/Ov00fcFiGVhhiD367OS9Th+GJfyIq4Xakmj RVww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RQ22EFOG; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f13si11974396pln.368.2018.11.19.17.30.32; Mon, 19 Nov 2018 17:30:48 -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=@google.com header.s=20161025 header.b=RQ22EFOG; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730276AbeKTL41 (ORCPT + 99 others); Tue, 20 Nov 2018 06:56:27 -0500 Received: from mail-it1-f196.google.com ([209.85.166.196]:35121 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726119AbeKTL41 (ORCPT ); Tue, 20 Nov 2018 06:56:27 -0500 Received: by mail-it1-f196.google.com with SMTP id v11so1148548itj.0 for ; Mon, 19 Nov 2018 17:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=V3m6gtQ1iRlWcRSMq0w2qWBRsEA6IUH9wDb9KBQbc1w=; b=RQ22EFOGMlzy4jAQwMHeVgHN7RcelmsF4D/OEYzl1jUdfCnv/tHR60j/BG//zRs98L pd1d+KQNo0EiNOINb1Ilr5Euvl0AQTVgjMu8ERtKiWyVDIYkl/1KWRpbucUnuS10OeH0 lTHSwR5vWBO2LhvbjarXqFcliL8Yp7elGW9jccCK/TEhCPs2ihu47N6GgwQCHhgaZ7dU gdOzR8WcmCs9lhCFAQZIWgZWikJNmf1c1SAKjuO0TI3ntaoAzTnCkHfDfOH+DnBDr+hy Fb+2wtvVpEGhCEWTKfQ9iOCwELpsdCvTIcGyklVwIm8H4hSIy5wDVnx09/4IJm5RkueQ 3Mog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=V3m6gtQ1iRlWcRSMq0w2qWBRsEA6IUH9wDb9KBQbc1w=; b=dRfr8/pqmCVOcxz5OUxfD8wwLh26SoqeH0e7bdKNhMHp0vOQgh3OQ2ULt1vg5lClmP 8i8TSua/ZBv5Lbtri0jqb4jSINQbEKNPJzjtOK8rllARf2sVJdY78O4x/5IMPv0TAQrV DlyJ6UM4ftRbpDVzP+6kSH5FQAnMOcuigJoN52sFXyBekJ1fVPRwp5uwpwfCKw/aU6q8 IX0YQeQPIfguvp/a/2iVlfPuY3Ms9O//jRg8RnFBSWQy4s55+W19XmBfunNH/ZOIwQPl AeTScnQ3pRNhQnFeRn4mYBCt89HWpr/NjeN8+Ywz4uz6OmPi49b5NmoIHfhP7E5XMMvj 1KPg== X-Gm-Message-State: AA+aEWYQpJln1uw3LlAOu+IxTEvgGMpzJreFMiwwuIk2GSa4uQVmlN8t ye/8vNQTY5YL7FwCT/vBnIu11g== X-Received: by 2002:a24:55d4:: with SMTP id e203mr484324itb.36.1542677394424; Mon, 19 Nov 2018 17:29:54 -0800 (PST) Received: from google.com ([2620:15c:183:0:a0c3:519e:9276:fc96]) by smtp.gmail.com with ESMTPSA id p10-v6sm13209106ioh.20.2018.11.19.17.29.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Nov 2018 17:29:53 -0800 (PST) Date: Mon, 19 Nov 2018 18:29:50 -0700 From: Yu Zhao To: Hugh Dickins Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: fix swap offset when replacing shmem page Message-ID: <20181120012950.GA94981@google.com> References: <20181119004719.156411-1-yuzhao@google.com> <20181119010924.177177-1-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote: > On Sun, 18 Nov 2018, Yu Zhao wrote: > > > We used to have a single swap address space with swp_entry_t.val > > as its radix tree index. This is not the case anymore. Now Each > > swp_type() has its own address space and should use swp_offset() > > as radix tree index. > > > > Signed-off-by: Yu Zhao > > This fix is a great find, thank you! But completely mis-described! Yes, now I remember making swap offset as key was done long after per swap device radix tree. > And could you do a smaller patch, keeping swap_index, that can go to > stable without getting into trouble with the recent xarrifications? > > Fixes: bde05d1ccd51 ("shmem: replace page if mapping excludes its zone") > Cc: stable@vger.kernel.org # 3.5+ > > Seems shmem_replace_page() has been wrong since the day I wrote it: > good enough to work on swap "type" 0, which is all most people ever use > (especially those few who need shmem_replace_page() at all), but broken > once there are any non-0 swp_type bits set in the higher order bits. But you did get it right when you wrote the function, which was before the per swap device radix tree. so Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap cache") looks good? > > --- > > mm/shmem.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index d44991ea5ed4..685faa3e0191 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -1509,11 +1509,13 @@ static int shmem_replace_page(struct page **pagep, gfp_t gfp, > > { > > struct page *oldpage, *newpage; > > struct address_space *swap_mapping; > > - pgoff_t swap_index; > > + swp_entry_t entry; > > Please keep swap_index as well as adding entry. Ack. > > int error; > > > > + VM_BUG_ON(!PageSwapCache(*pagep)); > > + > > I'd prefer you to drop that, it has no bearing on this patch; > we used to have it, along with lots of other VM_BUG_ONs in here, > but they outlived their usefulness, and don't need reintroducing - > they didn't help at all to prevent the actual bug you've found. > > > oldpage = *pagep; > > - swap_index = page_private(oldpage); > > + entry.val = page_private(oldpage); > > entry.val = page_private(oldpage); > swap_index = swp_offset(entry); > > > swap_mapping = page_mapping(oldpage); > > > > /* > > @@ -1532,7 +1534,7 @@ static int shmem_replace_page(struct page **pagep, gfp_t gfp, > > __SetPageLocked(newpage); > > __SetPageSwapBacked(newpage); > > SetPageUptodate(newpage); > > - set_page_private(newpage, swap_index); > > + set_page_private(newpage, entry.val); > > Yes. > > > SetPageSwapCache(newpage); > > > > /* > > @@ -1540,7 +1542,8 @@ static int shmem_replace_page(struct page **pagep, gfp_t gfp, > > * a nice clean interface for us to replace oldpage by newpage there. > > */ > > xa_lock_irq(&swap_mapping->i_pages); > > - error = shmem_replace_entry(swap_mapping, swap_index, oldpage, newpage); > > + error = shmem_replace_entry(swap_mapping, swp_offset(entry), > > + oldpage, newpage); > > I'd prefer to omit that hunk, to avoid the xa_lock_irq() in the context; > the patch is just as good if we keep the swap_index variable. > > > if (!error) { > > __inc_node_page_state(newpage, NR_FILE_PAGES); > > __dec_node_page_state(oldpage, NR_FILE_PAGES); > > -- > > 2.19.1.1215.g8438c0b245-goog > > Thanks, > Hugh