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 53408C433F5 for ; Wed, 16 Mar 2022 18:26:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A59D6B0071; Wed, 16 Mar 2022 14:26:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 861726B0072; Wed, 16 Mar 2022 14:26:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71D148D0001; Wed, 16 Mar 2022 14:26:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 625DF6B0071 for ; Wed, 16 Mar 2022 14:26:33 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E1E6718215FB3 for ; Wed, 16 Mar 2022 18:26:32 +0000 (UTC) X-FDA: 79251079824.31.6A9BCCF Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 3237A100021 for ; Wed, 16 Mar 2022 18:26:32 +0000 (UTC) Received: by mail-yb1-f174.google.com with SMTP id o5so6022176ybe.2 for ; Wed, 16 Mar 2022 11:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+VVGHpNw2aToH4nlv/qP4fsUY4xFNKKSta7CoxCOLqU=; b=Im3UELGk/iBvvXDdwloE1LayQw78/8xAF5xIkzHUcYNoTmJQWTbW5FnZyqyYEgkf/2 u6yjX7f4cTiiB6Xl/VU6E5cj6YVeOpmIafJOgwchCrZVrCmBGaGiUTzK8ypCnXwxX13n /DVouNRz5uqNvN42UYjat3gLTPyDsihe7EGdA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+VVGHpNw2aToH4nlv/qP4fsUY4xFNKKSta7CoxCOLqU=; b=JphB3Sp1aIf17vgxjLG4AYrQw4AN/v0+T0C/61/WTBPGGT0zsz/lAnoPs/bBOBdfTw dGvf/ERgcIYjEQuPbpjnR7fmH/fbyPmVLzI7P53ZsmESF/BhCMtWLDQ1uNjkMxFcw/hc 9LOJnjrocA5JYya5DIaWGfM+0WGeGhPPLLI84+qFrd32ibEx3Vxk5oz+kvd4/3xk+NiE HYtL1uHOg0GxteHT4+OvEGL8+1eqO61Munq8AQAFs4fgNhacyoWxB94hI3hKAjiBHEvc 5UdjrGAxKHXAHTG9RkMhwTvoaJm+IXJL2UZlZZcR7+DHvkgyu1mGw7AIEkFScLaFoMqC y3Vw== X-Gm-Message-State: AOAM533ffyam1HfvgiNWO5xhT3BuAjlq71uTRcWPHG7gZqnF4p1lPUwz w1x/PdQ+ncA+Wu37t4frO59T/t3D1NPXzpiaofHoKw== X-Google-Smtp-Source: ABdhPJxgt41Y/UgMqCYCVzLLEzyZ00uN4v/bBuIogqY9sdSDfrECHl2+T+gNWPVLRmPOUuKWlmIHWV6lhzeCmDlncpY= X-Received: by 2002:a25:918f:0:b0:633:6f7d:6d78 with SMTP id w15-20020a25918f000000b006336f7d6d78mr1343447ybl.134.1647455191504; Wed, 16 Mar 2022 11:26:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivan Babrou Date: Wed, 16 Mar 2022 11:26:20 -0700 Message-ID: Subject: Re: zram corruption due to uninitialized do_swap_page fault To: Minchan Kim Cc: Linux MM , linux-kernel , Andrew Morton , Nitin Gupta , Sergey Senozhatsky , Jens Axboe , linux-block@vger.kernel.org, kernel-team Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 3237A100021 X-Stat-Signature: fy55hrm6j7q64edcq8fjpbze5kig3hjx Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=cloudflare.com header.s=google header.b=Im3UELGk; dmarc=pass (policy=reject) header.from=cloudflare.com; spf=none (imf05.hostedemail.com: domain of ivan@cloudflare.com has no SPF policy when checking 209.85.219.174) smtp.mailfrom=ivan@cloudflare.com X-Rspamd-Server: rspam03 X-HE-Tag: 1647455192-278904 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 Tue, Mar 15, 2022 at 3:09 PM Minchan Kim wrote: > I think the problem with CLONE_VM is following race > > CPU A CPU B > > do_swap_page do_swap_page > SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path > swap_readpage original data > swap_slot_free_notify > delete zram entry > swap_readpage zero data > pte_lock > map the *zero data* to userspace > pte_unlock > pte_lock > if (!pte_same) > goto out_nomap; > pte_unlock > return and next refault will > read zero data > > So, CPU A and B see zero data. With patchset below, it changes > > > CPU A CPU B > > do_swap_page do_swap_page > SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path > swap_readpage original data > pte_lock > map the original data > swap_free > swap_range_free > bd_disk->fops->swap_slot_free_notify > swap_readpage read zero data > pte_unlock > pte_lock > if (!pte_same) > goto out_nomap; > pte_unlock > return and next refault will > read correct data again > > Here, CPU A could read zero data from zram but that's not a bug > (IOW, warning injected doesn't mean bug). > > The concern of the patch would increase memory size since it could > increase wasted memory with compressed form in zram and uncompressed > form in address space. However, most of cases of zram uses no > readahead and then, do_swap_page is followed by swap_free so it will > free the compressed from in zram quickly. > > Ivan, with this patch, you can see the warning you added in the zram > but it shouldn't trigger the userspace corruption as mentioned above > if I understand correctly. > > Could you test whether the patch prevent userspace broken? I'm making an internal build and will push it to some location to see how it behaves, but it might take a few days to get any sort of confidence in the results (unless it breaks immediately). I've also pushed my patch that disables SWP_SYNCHRONOUS_IO to a few locations yesterday to see how it fares.