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 B3B11C433F5 for ; Tue, 10 May 2022 01:22:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D70B6B0072; Mon, 9 May 2022 21:22:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 387886B0073; Mon, 9 May 2022 21:22:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2520F6B0074; Mon, 9 May 2022 21:22:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1732E6B0072 for ; Mon, 9 May 2022 21:22:06 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D7C8E31576 for ; Tue, 10 May 2022 01:22:05 +0000 (UTC) X-FDA: 79448082210.14.ED9F453 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf26.hostedemail.com (Postfix) with ESMTP id 7A94C140098 for ; Tue, 10 May 2022 01:22:02 +0000 (UTC) Received: by mail-pj1-f46.google.com with SMTP id n10so3510283pjh.5 for ; Mon, 09 May 2022 18:22:04 -0700 (PDT) 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:references :mime-version:content-disposition:in-reply-to; bh=UbbErnk4URiyhDcgHPYh2QePDGVMcd5mePLEmIA+Vog=; b=Z25sPR8JnXdcrcaGcU5Xef3XCl6M1OgQkPLt+IxOBnso2HXkbVnO4b+tRvK/UHHjTY 7QFWlJvOnBWunImXA803w7SfMggFCyrD808FVTo2X8lAZKcDOdTMbJTL7cHRUMZiqhZx QhLVlB9XtNcfXn/ouLQiQjB9bz7kHTFugXhyIZoyMlZ10q6LNwuvYDxNElJ5boEYBq0W iWn/eakFqfMCd1FN53do0pKdKMhiW0HqzcGxEOdNTTnYW3Hvsog2vL/clQgUy/ODa0Ly EMdjxkSr/i4tnHXF7zj/yB7m7PNOR1jmhbxQcO2VKFa17wU2oAgsN1+eBscKIW2psiRk sJAw== X-Gm-Message-State: AOAM532ki2pM3svn1cVfjOVMYdNy/6zEFmevA0ryaF4CDybupQKVg3e/ zWPltVR9EGIfGN30HZk/13c= X-Google-Smtp-Source: ABdhPJzcWbH06lL3gp2KEEweSQjSbSld50Abyzk7g2naibSYcflCmRKeuJA15E1QHkKb+DgHm2NXJA== X-Received: by 2002:a17:90b:3b81:b0:1dc:32ac:a66b with SMTP id pc1-20020a17090b3b8100b001dc32aca66bmr20577182pjb.49.1652145724182; Mon, 09 May 2022 18:22:04 -0700 (PDT) Received: from sultan-box.localdomain ([204.152.216.102]) by smtp.gmail.com with ESMTPSA id be12-20020a056a001f0c00b0050dc76281basm9376105pfb.148.2022.05.09.18.22.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 18:22:03 -0700 (PDT) Date: Mon, 9 May 2022 18:22:01 -0700 From: Sultan Alsawaf To: Andrew Morton Cc: stable@vger.kernel.org, Minchan Kim , Nitin Gupta , Sergey Senozhatsky , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] zsmalloc: Fix races between asynchronous zspage free and page migration Message-ID: References: <20220509024703.243847-1-sultan@kerneltoast.com> <20220509170632.fec2f56ad9f640329330b9de@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220509170632.fec2f56ad9f640329330b9de@linux-foundation.org> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7A94C140098 X-Stat-Signature: b7e7trxywyztaodb531ajagz5bobbotd X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of sultan.kerneltoast@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=sultan.kerneltoast@gmail.com; dmarc=none X-HE-Tag: 1652145722-540612 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, May 09, 2022 at 05:06:32PM -0700, Andrew Morton wrote: > Why not simply lock_page() here? The get_page() alone won't protect > from all the dire consequences which you have identified? Hi, My reasoning is that if the page migrated, then we've got the last reference to it anyway and there's no point in locking. But more importantly, we'd still need to take migrate_read_lock() again in order to verify whether or not the page migrated because of data races stemming from replace_sub_page(), so I don't think there's much to gain by using lock_page(). When any of the pages in the zspage migrates, the entire page list is reconstructed and every page's private storage is rewritten. I had drafted another change that fixes the data races by trimming out all of that redundant work done in replace_sub_page(), but I wanted to keep this patch small to make it easier to review and easier to backport. Sultan