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: 12702405 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EC10C433F5 for ; Mon, 3 Jan 2022 01:32:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF6356B0071; Sun, 2 Jan 2022 20:32:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA6016B0073; Sun, 2 Jan 2022 20:32:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96CB16B0074; Sun, 2 Jan 2022 20:32:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 8841D6B0071 for ; Sun, 2 Jan 2022 20:32:32 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2DBAA8249980 for ; Mon, 3 Jan 2022 01:32:32 +0000 (UTC) X-FDA: 78987250944.27.39FDC42 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf07.hostedemail.com (Postfix) with ESMTP id D15AB4000A for ; Mon, 3 Jan 2022 01:32:31 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id l17so29047901qtk.7 for ; Sun, 02 Jan 2022 17:32:31 -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=zcrnc8xNDY8bEw56+RSWAqlRja2kZF2gq5TbsG94EyV4iLmHnIZlcGbtJxea8aixFW XIGxXGYe4Ai/610sOQfR1uyI4eaPOdFiWG01mDVwxohHurKrmfGCPq0vEqGQa0rD3Y3o BdW83eXUvGjZCm2k9XC+/YL7GSUP9JwvhfcLSPTj2UMObMYC/hAGgJr0SKfKni+UMyRn 1YxPrWJBmi8TVm8inKQMK4uXgxhlxbT+iiQa+9EBhKDVtLitcyj7LAB3iXE/bkF37Bnw sL1bAUYcjQb9nhgLykqRg8gSRefFKc75QMBWEB2vzCN+t0yfJf4dQuz+XVUSmDW26zp1 FM4g== X-Gm-Message-State: AOAM532favCQ3gPlSNcbOqWy6ZIDtZafJGsN3SO/FbB75jwtU8AGmmEl RPbFPBDQn2gB6CIVKUre6BSy/Q== 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 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BjrOMM6C; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of hughd@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D15AB4000A X-Stat-Signature: jasy1rgykgtnkb4qn8wrjpsbtadfwsuu X-HE-Tag: 1641173551-798790 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: 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: 12702408 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98C2BC433F5 for ; Mon, 3 Jan 2022 01:34:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DEF96B0071; Sun, 2 Jan 2022 20:34:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2670C6B0073; Sun, 2 Jan 2022 20:34:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E0526B0074; Sun, 2 Jan 2022 20:34:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id ECE696B0071 for ; Sun, 2 Jan 2022 20:34:08 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AA469181AC9C6 for ; Mon, 3 Jan 2022 01:34:08 +0000 (UTC) X-FDA: 78987254976.18.B6A1A79 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf30.hostedemail.com (Postfix) with ESMTP id 4999B80005 for ; Mon, 3 Jan 2022 01:34:08 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id f138so29939920qke.10 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=rIO+3kbHbFK76lNStQGjV8QVI6eEzjabebwGtM9Kx771qyQ7afweovVnkfWefpd6ab DBqhEhqkRhjAaelsnxSJrzgMCNIsbGhT9bUeAcug668S42ey40GnBvUEVgBVhybHv4bQ RgZv3u/4qesxr6C+VoyqBhwo9ppAsRMgcAlN3jci0AVEOoxpK0cgHoZVZYcwVXgw5MmO rzbfYA+P+yGxhRdd3J9blMNmUEtn1FtkDywT0elHYfpz8qmW3HCFmnHkjW6FC45gL/Dp M/A+sI81/NJ3Nm4JzvZwqDBvCO6humJ15Sk/wn30HYv1RgYXpYcjrWPCN/dkIw7n9ULS dKrw== X-Gm-Message-State: AOAM530arLq3Nzu7oi8J2s4NgQc3z3InottSV14Au+etj37i2+jtPEMb dt+TgBfMAJE7nJNcdXLVveiWKg== 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 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4999B80005 X-Stat-Signature: qjtis36pt5oekjnaiite7n97g9s3inr7 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZZg5oPjU; spf=pass (imf30.hostedemail.com: domain of hughd@google.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1641173648-340447 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: 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: 12702409 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96B9CC433F5 for ; Mon, 3 Jan 2022 01:35:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28E0A6B0071; Sun, 2 Jan 2022 20:35:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 23D5B6B0073; Sun, 2 Jan 2022 20:35:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 105FE6B0074; Sun, 2 Jan 2022 20:35:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 016756B0071 for ; Sun, 2 Jan 2022 20:35:53 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BBAE58F6D3 for ; Mon, 3 Jan 2022 01:35:53 +0000 (UTC) X-FDA: 78987259386.10.7CF2AB0 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf24.hostedemail.com (Postfix) with ESMTP id BE458180003 for ; Mon, 3 Jan 2022 01:35:45 +0000 (UTC) Received: by mail-qk1-f172.google.com with SMTP id m2so28348085qkd.8 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=pemzlNx/OFcr3YRyofTPM7yUGRoCOkAbv9BytXxwieMs2UBVuz3DYHeGj959YBQ3RX jH2BXvzxM9e+wiNHV/qfqUlWy8efk6otOwK8RpVo4VLfa8blNP6XT4QVtHkxWYc26BTE IzmVmUyAOUFYD+nLe0Hv68hUw+GZ9DzJWSKKkKti9kw3sG++aDYHgAbX78Ah3nxODGYh JcRXdppTHdobgan2bc7nMnMvxjYk32+xSbSd8a678W+Nfo1PFppSKuMoP/L9nSseg2da CeA7TXisXlTI+4Bwqe7j/76nP3L48mvZCYGfDq3G0MsWdbhRsPljUMcaht1PQd8B3blK 7fGg== X-Gm-Message-State: AOAM5310YjT0SY8y8n6EuNAB3qiJxfsS4sXjF7qWcAbvp9yHTchdugbZ fm82XkZq8/jgBdF5NSFGl2gLfw== 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 X-Rspamd-Queue-Id: BE458180003 X-Stat-Signature: om5ikqr7bwrkor1d8ob35t8sz7yysxuy Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="hT+6aP4/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspamd-Server: rspam02 X-HE-Tag: 1641173745-437393 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: 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; }