From patchwork Mon Jan 3 01:32:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 12702404 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9608EC433EF for ; Mon, 3 Jan 2022 01:32:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231322AbiACBcd (ORCPT ); Sun, 2 Jan 2022 20:32:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230110AbiACBcc (ORCPT ); Sun, 2 Jan 2022 20:32:32 -0500 Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26859C061761 for ; Sun, 2 Jan 2022 17:32:32 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id z9so29075760qtj.9 for ; Sun, 02 Jan 2022 17:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version; bh=asS1ao6kszozXWmZX1tUAjlHFyfy+Rk58KfLP/5PHqQ=; b=BjrOMM6CVIpHGjlWjLaI6P6vezPcNIYDCzfF0JSjI8sWNEVxT30ZRlunzGmKlsCQGc SWIM1EFvk93zzvKcotWFDpUtu4rMaA3DyJBYdITShfFfruweXf87Ub1qARP/IueTv1O6 QZXsZj8LcY36F9X+xhmtAw562WvtWQXBbWpO6kdB/HULQG+8H/jBuTEKlk38QDJxXJ// 9Wrm5Iy9DfWqoQyhfTY2hV3qI14A1Z/cY+Iz77X8uYgqOQohklsXnYVD1c9mkkHD83Bj h4zmEugf8NPqwBqimBAYFiSx03I/oP+5/2yviRBSUgtHyVA3ttEIPU4eLj1QDWBSmKkt SJTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version; bh=asS1ao6kszozXWmZX1tUAjlHFyfy+Rk58KfLP/5PHqQ=; b=bCLY0CO9IpHzx5rmRPo0XP6cI7yvOpa81qo1fkblmv/8wmbnQqiPPnK+IX/q6Sy+Jt Qs8nCLZFENgCnprqWI20F+ERVTMN37bR2XwQlGKdK7WlvEmWfteAvlCAuJ6agIPYyu1o xdvETBH7AC2pDzMfNcXi60XsZTp96FVyUjDIaCHipQQMYg2EYEIGR4Dt1+0zquvZGwIM MXJUPa9bw7MFdqG4BVgZm1kXudb0Aq7JQpKx+H1ZXhqgwpIB32H7ghcpsVmYjPjYNwXm yVffeeQIJA9+nriJ6IzpXTQLQxo7Aaq3FqOFXDAnxNxqeOTh4XZEOESMdYpbV+N6waLR PgHw== X-Gm-Message-State: AOAM5329p3CVxiafqm9MbXGVg6yndssVeOwEr14HPEyoZVn1jj9Fjl/i tW/rsqDhmsi0HkSYq4F9U7VtJQ== X-Google-Smtp-Source: ABdhPJxt7LbKzifdA3sqsQv1QbTSNHpJ8zAgofcXu7hxSP6zvtWwIFvpJKOtQjlpFJ5eoNjc0xEV2w== X-Received: by 2002:ac8:4e4d:: with SMTP id e13mr37845415qtw.293.1641173551110; Sun, 02 Jan 2022 17:32:31 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id f12sm27365602qtj.93.2022.01.02.17.32.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 17:32:30 -0800 (PST) Date: Sun, 2 Jan 2022 17:32:28 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Andrew Morton , Christoph Hellwig , Jan Kara , William Kucharski , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH next 1/3] truncate,shmem: Fix data loss when hole punched in folio Message-ID: <43bf0e3-6ad8-9f67-7296-786c7b3b852f@google.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org As reported before in https://lore.kernel.org/lkml/alpine.LSU.2.11.2011160128001.1206@eggly.anvils/ shmem_undo_range() mods sometimes caused good data to be zeroed when running my tmpfs swapping loads. Only the ext4-on-loop0-on-tmpfs mount was seen to suffer, and that is mounted with "-o discard": which punches holes in the underlying tmpfs file. shmem_undo_range() partial_end handling was wrong: if (lend + 1) aligned to page but not to folio, the second shmem_get_folio() could be skipped, then the whole of that folio punched out instead of treated partially. Rename same_page to same_folio (like in truncate.c), and rely on that instead of partial_end: fewer variables, less confusion. And considering an off-by-one in setting same_folio initially, pointed to an off-by-one in the second shmem_get_folio(): it should be on (lend >> PAGE_SHIFT) not end - which had caused no data loss, but could split folio unnecessarily. And apply these same fixes in truncate_inode_pages_range(). Fixes: 8842c9c23524 ("truncate,shmem: Handle truncates that split large folios") Signed-off-by: Hugh Dickins --- mm/shmem.c | 16 ++++++---------- mm/truncate.c | 15 +++++++-------- 2 files changed, 13 insertions(+), 18 deletions(-) --- next-20211224/mm/shmem.c +++ hughd1/mm/shmem.c @@ -908,10 +908,10 @@ static void shmem_undo_range(struct inod struct folio_batch fbatch; pgoff_t indices[PAGEVEC_SIZE]; struct folio *folio; + bool same_folio; long nr_swaps_freed = 0; pgoff_t index; int i; - bool partial_end; if (lend == -1) end = -1; /* unsigned, so actually very big */ @@ -947,18 +947,14 @@ static void shmem_undo_range(struct inod index++; } - partial_end = ((lend + 1) % PAGE_SIZE) > 0; + same_folio = (lstart >> PAGE_SHIFT) == (lend >> PAGE_SHIFT); shmem_get_folio(inode, lstart >> PAGE_SHIFT, &folio, SGP_READ); if (folio) { - bool same_page; - - same_page = lend < folio_pos(folio) + folio_size(folio); - if (same_page) - partial_end = false; + same_folio = lend < folio_pos(folio) + folio_size(folio); folio_mark_dirty(folio); if (!truncate_inode_partial_folio(folio, lstart, lend)) { start = folio->index + folio_nr_pages(folio); - if (same_page) + if (same_folio) end = folio->index; } folio_unlock(folio); @@ -966,8 +962,8 @@ static void shmem_undo_range(struct inod folio = NULL; } - if (partial_end) - shmem_get_folio(inode, end, &folio, SGP_READ); + if (!same_folio) + shmem_get_folio(inode, lend >> PAGE_SHIFT, &folio, SGP_READ); if (folio) { folio_mark_dirty(folio); if (!truncate_inode_partial_folio(folio, lstart, lend)) --- next-20211224/mm/truncate.c +++ hughd1/mm/truncate.c @@ -347,8 +347,8 @@ void truncate_inode_pages_range(struct a pgoff_t indices[PAGEVEC_SIZE]; pgoff_t index; int i; - struct folio * folio; - bool partial_end; + struct folio *folio; + bool same_folio; if (mapping_empty(mapping)) goto out; @@ -385,12 +385,10 @@ void truncate_inode_pages_range(struct a cond_resched(); } - partial_end = ((lend + 1) % PAGE_SIZE) > 0; + same_folio = (lstart >> PAGE_SHIFT) == (lend >> PAGE_SHIFT); folio = __filemap_get_folio(mapping, lstart >> PAGE_SHIFT, FGP_LOCK, 0); if (folio) { - bool same_folio = lend < folio_pos(folio) + folio_size(folio); - if (same_folio) - partial_end = false; + same_folio = lend < folio_pos(folio) + folio_size(folio); if (!truncate_inode_partial_folio(folio, lstart, lend)) { start = folio->index + folio_nr_pages(folio); if (same_folio) @@ -401,8 +399,9 @@ void truncate_inode_pages_range(struct a folio = NULL; } - if (partial_end) - folio = __filemap_get_folio(mapping, end, FGP_LOCK, 0); + if (!same_folio) + folio = __filemap_get_folio(mapping, lend >> PAGE_SHIFT, + FGP_LOCK, 0); if (folio) { if (!truncate_inode_partial_folio(folio, lstart, lend)) end = folio->index; From patchwork Mon Jan 3 01:34:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 12702406 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 256E8C433EF for ; Mon, 3 Jan 2022 01:34:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231324AbiACBeJ (ORCPT ); Sun, 2 Jan 2022 20:34:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230110AbiACBeJ (ORCPT ); Sun, 2 Jan 2022 20:34:09 -0500 Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D11BC061761 for ; Sun, 2 Jan 2022 17:34:08 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id de30so30049100qkb.0 for ; Sun, 02 Jan 2022 17:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version; bh=PiokhK5vm6t1FngCPHje/kH9JSRiznv1PXUqe2mn9nU=; b=ZZg5oPjU+IOX3lG0g19Q1tZ/0PUV0sB/r7uA/E3QanqmedTQ/Dt8JJWvGQz1aTlEkT yItEdtxxcBrehZmXoxAwfjc0ILD6eG9wzOZnIfGCDZ1iRiaZST9lItcVVxz0ufN+AXWU lCtNUV0WwRwO1qwI9ZEV3gdsvwUJCJKCcc9gwvDFQiL6be9tLtZTv5G4YmaFKKtFAjGM uPsZAsbfd4WgLYmKMqJ5j77P2aoeiJI5cIHUbY++IbUP/uM3HEmNP0CW5tmoJn/yUhdl hDHr+iXH6uhPxHFUrwnFsiZkyJBzX2EkmKQQmg29wjACI/MIXEcFyDQsoa0ThiNOJ/LX FEeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version; bh=PiokhK5vm6t1FngCPHje/kH9JSRiznv1PXUqe2mn9nU=; b=6ycs7ZNfvrH+6+dDVA/jmmAql6m/eFcjdr6YCUWHMUaRjREGoiKx3hg0etefXilZCp BhOHZn35FLpygpzovP7t6H/nhsP1tlN29ZDlRYwS2TJxOWtdlJiNuNArrdm+4ZvP4jqm AuL+FOCnkFmcihdw8kNyKOe1Vi213YZkyNVrmV5+uoXhFvb2c+J1GvKleRdlpY2FF+c3 j9Ln8LrodEbdK5H+61+Se/wFQ8FBAbn2eWnWPJ4Mrh4+Elg0GmQ1KO77Tu8Qk4ZuV8oS KTPJjocyTUujRs6V9V5CV9H+fE4vykaWhZU6Q0gNrzJP7poENP/ad2AOSCeTOWMYeXfM mueg== X-Gm-Message-State: AOAM532ghpsyucN+5l5OGjzdLb4VJWPlwV6MTE4hcA9yx/5eJRQP2f3c lKl1in+j/7BWIN5G31KfrbxDzA== X-Google-Smtp-Source: ABdhPJzDwiUdvEF84FGbRjFyOE63LRPTQzrSoXa5QXj+lO/f/TPMozsBrj0zcm4Brg0pzeMMK4vK4Q== X-Received: by 2002:a05:620a:2013:: with SMTP id c19mr30288941qka.700.1641173647399; Sun, 02 Jan 2022 17:34:07 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id bm25sm27152395qkb.4.2022.01.02.17.34.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 17:34:07 -0800 (PST) Date: Sun, 2 Jan 2022 17:34:05 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Andrew Morton , Christoph Hellwig , Jan Kara , William Kucharski , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH next 2/3] shmem: Fix data loss when folio truncated Message-ID: <24d53dac-d58d-6bb9-82af-c472922e4a31@google.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org xfstests generic 098 214 263 286 412 used to pass on huge tmpfs (well, three of those _require_odirect, enabled by a shmem_direct_IO() stub), but still fail even with the partial_end fix. generic/098 output mismatch shows actual data loss: --- tests/generic/098.out +++ /home/hughd/xfstests/results//generic/098.out.bad @@ -4,9 +4,7 @@ wrote 32768/32768 bytes at offset 262144 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) File content after remount: -0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa -* -0400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... The problem here is that shmem_getpage(,,,SGP_READ) intentionally supplies NULL page beyond EOF, and truncation and eviction intentionally lower i_size before shmem_undo_range() is called: so a whole folio got truncated instead of being treated partially. That could be solved by adding yet another SGP_mode to select the required behaviour, but it's cleaner just to handle cache and then swap in shmem_get_folio() - renamed here to shmem_get_partial_folio(), given an easier interface, and moved next to its sole user, shmem_undo_range(). We certainly do not want to read data back from swap when evicting an inode: i_size preset to 0 still ensures that. Nor do we want to zero folio data when evicting: truncate_inode_partial_folio()'s check for length == folio_size(folio) already ensures that. Fixes: 8842c9c23524 ("truncate,shmem: Handle truncates that split large folios") Signed-off-by: Hugh Dickins --- mm/shmem.c | 39 ++++++++++++++++++++++++--------------- 1 file changed, 24 insertions(+), 15 deletions(-) --- hughd1/mm/shmem.c +++ hughd2/mm/shmem.c @@ -151,19 +151,6 @@ int shmem_getpage(struct inode *inode, p mapping_gfp_mask(inode->i_mapping), NULL, NULL, NULL); } -static int shmem_get_folio(struct inode *inode, pgoff_t index, - struct folio **foliop, enum sgp_type sgp) -{ - struct page *page = NULL; - int ret = shmem_getpage(inode, index, &page, sgp); - - if (page) - *foliop = page_folio(page); - else - *foliop = NULL; - return ret; -} - static inline struct shmem_sb_info *SHMEM_SB(struct super_block *sb) { return sb->s_fs_info; @@ -894,6 +881,28 @@ void shmem_unlock_mapping(struct address } } +static struct folio *shmem_get_partial_folio(struct inode *inode, pgoff_t index) +{ + struct folio *folio; + struct page *page; + + /* + * At first avoid shmem_getpage(,,,SGP_READ): that fails + * beyond i_size, and reports fallocated pages as holes. + */ + folio = __filemap_get_folio(inode->i_mapping, index, + FGP_ENTRY | FGP_LOCK, 0); + if (!folio || !xa_is_value(folio)) + return folio; + /* + * But read a page back from swap if any of it is within i_size + * (although in some cases this is just a waste of time). + */ + page = NULL; + shmem_getpage(inode, index, &page, SGP_READ); + return page ? page_folio(page) : NULL; +} + /* * Remove range of pages and swap entries from page cache, and free them. * If !unfalloc, truncate or punch hole; if unfalloc, undo failed fallocate. @@ -948,7 +957,7 @@ static void shmem_undo_range(struct inod } same_folio = (lstart >> PAGE_SHIFT) == (lend >> PAGE_SHIFT); - shmem_get_folio(inode, lstart >> PAGE_SHIFT, &folio, SGP_READ); + folio = shmem_get_partial_folio(inode, lstart >> PAGE_SHIFT); if (folio) { same_folio = lend < folio_pos(folio) + folio_size(folio); folio_mark_dirty(folio); @@ -963,7 +972,7 @@ static void shmem_undo_range(struct inod } if (!same_folio) - shmem_get_folio(inode, lend >> PAGE_SHIFT, &folio, SGP_READ); + folio = shmem_get_partial_folio(inode, lend >> PAGE_SHIFT); if (folio) { folio_mark_dirty(folio); if (!truncate_inode_partial_folio(folio, lstart, lend)) From patchwork Mon Jan 3 01:35:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 12702407 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB04DC433FE for ; Mon, 3 Jan 2022 01:35:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231326AbiACBfy (ORCPT ); Sun, 2 Jan 2022 20:35:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230110AbiACBfx (ORCPT ); Sun, 2 Jan 2022 20:35:53 -0500 Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4C94C061761 for ; Sun, 2 Jan 2022 17:35:53 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id r139so29066756qke.9 for ; Sun, 02 Jan 2022 17:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version; bh=JaSZZ+/ZBLkNzEcEn9eD+IlDGjCZFtM4r21Mxyksolg=; b=hT+6aP4/NC3vMVqIhmCXqGkMBlMD5MdP9vNNwMtApmbOflavOSVhqzfKbVOsBAZBq7 9tTaDUAhg829po65kAvLTn9iMygiB2/kWOd1VwWe8ipImHI7uJEixSZM5Fr5/CrJoH0F bjUo7d8TaCIGijcO4F0SN7kj54IKT027e82lDAcjzwldGVVsaS14B3i5SpoDgq6gqFw+ 1xoCmt26e37Ywc9tWAMH46RJiqDda3iJE9tm3YBtr9/+WDO5Yy6DT1/wUZ7CIt93Q5ks 4HJHfNKAotvDbnIoP7CKCyjZ9KOn/XgvebnatVwfHtf7oXaOuAxBHweJCIZ10UOVpVg/ sIpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version; bh=JaSZZ+/ZBLkNzEcEn9eD+IlDGjCZFtM4r21Mxyksolg=; b=tyzvBrYpBXN44TAZ/ZiAtuL6aHNUHMpIVRhP/4amtV69d7anwI6qSQmTlcQjw44v0d k8xgdUFxX8sD0QfswNcUdabJMCyE39HkcdYfgz3NeWN2S4f2Sw5o1JTstq2Mcyia17Iw N5dr1iz0ugSctqhVbGdAGNLVTnYzdpABxGFQcvSgi4mJmCbguyl7LDkbKQbm+8Ry26+L dJQNGStH0II11krz6XCqFDjoxxhYGIjxKt9wieIxG5CfHN2p+7xEzKf35qa52Ccv9qab Tr+VI/PEyntsK99WugkviN8mYxPjMgffC5K06x6nhWN4OGmnBiuLIKSXV7GUBqtS4oqW WZpg== X-Gm-Message-State: AOAM53388h8cFzkNe1S3Es+Wo463hD67r65jiAVenNw4nly1TJDl2ONS +njd1a8ZRoV5762CroiiJ0qbYw== X-Google-Smtp-Source: ABdhPJzoXsD5f7PvFJQ6Mu9VEZlpODAEzB2rbY5NHjHbnv/vRbwrq0S3GSu4FEPFxBMNh3OBJOHiAQ== X-Received: by 2002:a05:620a:c4f:: with SMTP id u15mr31341532qki.565.1641173752550; Sun, 02 Jan 2022 17:35:52 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id r20sm27971780qkp.21.2022.01.02.17.35.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 17:35:52 -0800 (PST) Date: Sun, 2 Jan 2022 17:35:50 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Andrew Morton , Christoph Hellwig , Jan Kara , William Kucharski , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH next 3/3] shmem: Fix "Unused swap" messages Message-ID: <49ae72d6-f5f-5cd-e480-e2212cb7af97@google.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org shmem_swapin_page()'s swap_free() has occasionally been generating "_swap_info_get: Unused swap offset entry" messages. Usually that's no worse than noise; but perhaps it indicates a worse case, when we might there be freeing swap already reused by others. The multi-index xas_find_conflict() loop in shmem_add_to_page_cache() did not allow for entry found NULL when expected to be non-NULL, so did not catch that race when the swap has already been freed. The loop would not actually catch a realistic conflict which the single check does not catch, so revert it back to the single check. Fixes: 3103f9a51dd0 ("mm: Use multi-index entries in the page cache") Signed-off-by: Hugh Dickins --- mm/shmem.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- hughd2/mm/shmem.c +++ hughd3/mm/shmem.c @@ -727,9 +727,8 @@ static int shmem_add_to_page_cache(struc do { void *entry; xas_lock_irq(&xas); - while ((entry = xas_find_conflict(&xas)) != NULL) { - if (entry == expected) - continue; + entry = xas_find_conflict(&xas); + if (entry != expected) { xas_set_err(&xas, -EEXIST); goto unlock; }