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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 224D8C433EF for ; Mon, 3 Jan 2022 20:10:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A1396B0071; Mon, 3 Jan 2022 15:10:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 650766B0073; Mon, 3 Jan 2022 15:10:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F1D46B0074; Mon, 3 Jan 2022 15:10:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 3F3B86B0071 for ; Mon, 3 Jan 2022 15:10:38 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E27E08249980 for ; Mon, 3 Jan 2022 20:10:37 +0000 (UTC) X-FDA: 78990068514.17.092D234 Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by imf10.hostedemail.com (Postfix) with ESMTP id 77F0AC0006 for ; Mon, 3 Jan 2022 20:10:25 +0000 (UTC) Received: by mail-qv1-f45.google.com with SMTP id kc16so32151611qvb.3 for ; Mon, 03 Jan 2022 12:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=B6cJU8nUUHYKdvDmldo02pUWTeqS+YG5TTvHjwEsWPU=; b=lVvKTKyvI3NLQtkFTAhATKtPuyBuuPR4NWtBrpBm7gxtLNm1yIYrxvFMQSXZFa/I90 MGMYHPYSROO2Hh2246WjncaSVMdPxxxYJNIoVohoe67x/uA+RPtxoeXCp6gX2+seizsc 4PJUWD4M1n7i5y22BmhN7Rm4NqLuktyQWG5UIZLp2gdKoznRn7i1uzyyzBQPMND/Ri3S X2oEy/jmx4O3MzBPgB7TWX1tFVTz4Rne3vQRMJbuql8UdJg94nOh4tacduLI+5sZSXh1 iRHjc/4033hTpD3x/iLxzyC/UWs4aOr+9oFPwoD6VcdJpKehPWOuII/4VejFzlAVMLoC 5vtw== 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:in-reply-to:message-id :references:mime-version; bh=B6cJU8nUUHYKdvDmldo02pUWTeqS+YG5TTvHjwEsWPU=; b=IfsZL9sHT/HHQ8jD6lcBZ8Jz5I7Fnf2YcozFy2pzPdg25sB/cXdlAPb+iNerQD+6Dc 08GwjSfWt9mbvdXIa51mrslRD9HBfqk3yFYxjNUYrp48RIosoY8gCcz6TFg0YL8NJ/B3 usQr75+rTKKICNwSARPrZvuYD61XrJHcjJgr9ZDkYRMLSXqn5pxOF7KdNvdm1rY22K3K F6niW8hmmdgvrETp9sbPpf9WmdwDmotuTi59zRTzR83PSISpn/ctXA5xdTNPpnSUivON 4BbTZzg9kxKE+IRZjtr2MRUAoJdLvkeQQ1niqDmbRoCHHwK+hc0inrASxVSOyiOjnmT5 47Qg== X-Gm-Message-State: AOAM530asbKH7Fsb568yNfRhL7BFF2M+rXamAZcjDzdqVrsfkoRKJfW2 7G/madwkyJlY1AJYC9tjud0KbQ== X-Google-Smtp-Source: ABdhPJy6M0drJX0wQ6xu4CXGfaUHQKjFKlsG9NcckbXNpYiM8S9gl9icl65iX/SDx6NqPlYG+x4VkQ== X-Received: by 2002:ad4:5bc1:: with SMTP id t1mr43989461qvt.72.1641240636522; Mon, 03 Jan 2022 12:10:36 -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 u9sm30948968qta.17.2022.01.03.12.10.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jan 2022 12:10:35 -0800 (PST) Date: Mon, 3 Jan 2022 12:10:21 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Hugh Dickins , Andrew Morton , Christoph Hellwig , Jan Kara , William Kucharski , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH next 3/3] shmem: Fix "Unused swap" messages In-Reply-To: Message-ID: <2da9d057-8111-5759-a0dc-d9dca9fb8c9f@google.com> References: <49ae72d6-f5f-5cd-e480-e2212cb7af97@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 77F0AC0006 X-Stat-Signature: 4867fdbx5kntrq1ym5un3n8wjgnx4zc7 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lVvKTKyv; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.219.45 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspamd-Server: rspam11 X-HE-Tag: 1641240625-531195 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 Mon, 3 Jan 2022, Matthew Wilcox wrote: > On Sun, Jan 02, 2022 at 05:35:50PM -0800, Hugh Dickins wrote: > > 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. > > I think what led to the loop was concern for the xa_state if trying > to find a swap entry that's smaller than the size of the folio. > So yes, the loop was expected to execute twice, but I didn't consider > the case where we were looking for something non-NULL and actually found > NULL. > > So should we actually call xas_find_conflict() twice (if we're looking > for something non-NULL), and check that we get @expected, followed by > NULL? Sorry, I've no idea. You say "twice", and that does not fit the imaginary model I had when I said "The loop would not actually catch a realistic conflict which the single check does not catch". I was imagining it either looking at a single entry, or looking at an array of (perhaps sometimes in shmem's case 512) entries, looking for conflict with the supplied pointer/value expected there. The loop technique was already unable to report on unexpected NULLs, and the single test would catch a non-NULL entry different from an expected non-NULL entry. Its only relative weakness appeared to be if that array contained (perhaps some NULLs then) a "narrow" instance of the same pointer/value that was expected to fill the array; and I didn't see any possibility for shmem to be inserting small and large folios sharing the same address at the same time. That "explanation" may make no sense to you, don't worry about it; just as "twice" makes no immediate sense to me - I'd have to go off and study multi-index XArray to make sense of it, which I'm not about to do. I've seen no problems with the proposed patch, but if you see a real case that it's failing to cover, yes, please do improve it of course. Though now I'm wondering if the "loop" totally misled me; and your "twice" just means that we need to test first this and then that and we're done - yeah, maybe. Hugh