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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16C0BC433DF for ; Fri, 21 Aug 2020 19:05:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2D142075E for ; Fri, 21 Aug 2020 19:05:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="govgPlM5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2D142075E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3596B8D0074; Fri, 21 Aug 2020 15:05:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3082D8D0002; Fri, 21 Aug 2020 15:05:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D1708D0074; Fri, 21 Aug 2020 15:05:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 070E18D0002 for ; Fri, 21 Aug 2020 15:05:44 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BB47E181AC9CB for ; Fri, 21 Aug 2020 19:05:43 +0000 (UTC) X-FDA: 77175504966.16.swing08_3306f852703b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 2CBB2100E4AFB for ; Fri, 21 Aug 2020 19:05:42 +0000 (UTC) X-HE-Tag: swing08_3306f852703b X-Filterd-Recvd-Size: 5769 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 19:05:41 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id f26so2981668ljc.8 for ; Fri, 21 Aug 2020 12:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nYAilJKJE/Ww6fPETY0UsPcqYTSdX+KcqzOQ2SZHjHk=; b=govgPlM5hnPkSEwfWGUIYxRmIaYCCF2bJTE78xBfzEYFWIPnokbR5UlRZzXwtuMDBP 3GiSRxTe+MNLCrhfBipl0worTfXzuhdTvTP6Gg+IWnDBkSdWt5veGPtmhC5r57CVxwrS LCil9FpOzP42GhiX+Lc1tk9QZDcIjKIcMjeTQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nYAilJKJE/Ww6fPETY0UsPcqYTSdX+KcqzOQ2SZHjHk=; b=Ir2OpPLkx7htH1PwwOY+QniQLtCvehBk/aQv01d0YYzfLmz+SYj7lplvTUgXbRY+nU 9X7Dzipflb6hZgVaJ079Xv/ol+wC9naSMHN+ujaiZ6SDXLDEOQN6LXiRA55ckA/uFxjZ 4MBbpfC1OudLqozQmt1pokXH5gvOEsruhh4AWJ31S3UBE55jSZzQnfbflmiOpljyMynH VQsTX62OXnQE7jBUsXYq4vPKNFwsSx5SB2jiUcw0lYk3ZmbzB46xd8VUNsQTU0auRu49 or499BD94caZ04kWp5OH6Vly6ZXx1vRMAXE5ymt7bPqhbGgRQ0zktIqyMDqsD9YF48yW yJqA== X-Gm-Message-State: AOAM5301aUhE85kKq7lv9ypkxcVBPZHU3YkbgijyX435ZW8Agd5DBItd e16fcCl724Ajp9DsHYFOvMHlSxvEHBfiFg== X-Google-Smtp-Source: ABdhPJwNWGSBhV67cjUPkTEG78Jyr9HJA/T6mMVWYgek2MdwZ++1zFJG6n+AASNsel9Hk6skgsb+iw== X-Received: by 2002:a2e:b174:: with SMTP id a20mr2376893ljm.200.1598036739231; Fri, 21 Aug 2020 12:05:39 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id m142sm548560lfa.47.2020.08.21.12.05.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2020 12:05:36 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id m22so3000310ljj.5 for ; Fri, 21 Aug 2020 12:05:36 -0700 (PDT) X-Received: by 2002:a2e:545:: with SMTP id 66mr2338287ljf.285.1598036735955; Fri, 21 Aug 2020 12:05:35 -0700 (PDT) MIME-Version: 1.0 References: <20200811214255.GE6353@xz-x1> <20200820215449.GB358043@xz-x1> <20200821101333.GA3432@quack2.suse.cz> <20200821154756.GC3432@quack2.suse.cz> <20200821180848.GA11376@xz-x1> In-Reply-To: From: Linus Torvalds Date: Fri, 21 Aug 2020 12:05:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] mm/gup: Allow real explicit breaking of COW To: Peter Xu Cc: Jan Kara , Andrea Arcangeli , Linux-MM , Linux Kernel Mailing List , Andrew Morton , Marty Mcfadden , "Maya B . Gokhale" , Jann Horn , Christoph Hellwig , Oleg Nesterov , Kirill Shutemov Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2CBB2100E4AFB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Fri, Aug 21, 2020 at 11:23 AM Linus Torvalds wrote: > > But the PageKsm() page_count() issue I didn't even realize. That worries me. Well, the fix is simple, although I don't love the magic PageKsm semantics that hide it from the page count. But since (a) a Ksm page is presumably normally shared (ie things like all zeroes) and (b) copying should always be safe, just do that. The case we *used* to have with trying to reuse the KSM page seems like it's not just adding complexity, it's optimizing for entirely the wrong case. Check both before and after getting the page lock, for the same reason we do it for the page count. The logic there matches the "reuse swap page", but while that old logic may have made sense 20 years ago, the swap cache case should be *so* rare these days that it feels completely pointless to try to reuse it. Aggressively doing a new allocation, copy, and freeing the old swap cache page is quite possibly cheaper than taking the page lock anyway, but more importantly, it's not a case that should normally trigger in the first place. That said, looking at this code again, I get the feeling that the mapcount check is pointless. Afaik, page_count() should always be larger than page_mapcount(), so if mapcount is > 1, then we'd have caught it with the page_count() check. Hmm? Am I popssibly missing some other subtle special case? Are there any THP issues? Again, doing the copy should always be the safe thing to do, and since we get the page lock for the reuse case I think we're ok on that front. What else possible special cases could we hit? Linus