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 B89EAECAAD5 for ; Tue, 6 Sep 2022 13:57:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 476C88028C; Tue, 6 Sep 2022 09:57:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FE4D80224; Tue, 6 Sep 2022 09:57:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 251508028C; Tue, 6 Sep 2022 09:57:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0EDDC80224 for ; Tue, 6 Sep 2022 09:57:41 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D3D14808EF for ; Tue, 6 Sep 2022 13:57:40 +0000 (UTC) X-FDA: 79881813480.12.62CD1EF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 4FE8C180095 for ; Tue, 6 Sep 2022 13:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662472659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GesI69YyBCVOELWdci2COwV5wfsC9CiwSBWxkans3kQ=; b=fvghjFivLVZLG2x4zc6a3jIdQcu100Qz4Gyo3QA1tuHoM5Nw1XY3Xn2l2NcXFaWLrBXbFr jL+z6pNnAYdpK46O/1PhNmpi+t9rBdYLu95BKlZrpO87gVMAhJx7YisVKngu6SLvHREVoW b663pLFOCrFJfjGn6wFlS2HWnZwPBZ0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-592-daB0zPHtPj-6mr6zHRwVlw-1; Tue, 06 Sep 2022 09:57:32 -0400 X-MC-Unique: daB0zPHtPj-6mr6zHRwVlw-1 Received: by mail-wm1-f72.google.com with SMTP id r10-20020a1c440a000000b003a538a648a9so6322776wma.5 for ; Tue, 06 Sep 2022 06:57:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=GesI69YyBCVOELWdci2COwV5wfsC9CiwSBWxkans3kQ=; b=S1AUx19wTW7pxZmqRovvqON/tVqMOOkhDqI+mrIGDOTUY5s0wjIAAqAUkENdCek/YY hRd2VL3Bb+szaHOKAGg2zlw2obfhsB1n9gq6njJI65GzMFY+03xCfBSoICLEQAA2b2+T nCKkEwG/5VgDrlRHX/mId8onGJyf6ODZsxHvb5c3pa6lE6UGwg14gCMIGZnEAN/w3lUb jfZ0PzbajBhLx0+D+c/WrlkELpf3oxceCOpWVvwsOt2C5Kgt2vhLtxBYPOT20NwKb1Bv TaynkFqD111F0k/Lw2g8Vc1sg+wFWFgqO1uamIeq3V0eSWdoDZr3oGVyojCSJGBQOG15 RMCA== X-Gm-Message-State: ACgBeo3Adfmtlhy69xyMdXKnu+lkE6ymHB4eu32n4MblfesdOX6aDnO1 fRynCFrxP073adMN3eTP1XSFQPKeWXkMMyIMJPr2MHQknhj7V721rWHncIbHsAe6qn5vg4x6EJd D37nh9BrexA4= X-Received: by 2002:a5d:620f:0:b0:225:32fc:cea3 with SMTP id y15-20020a5d620f000000b0022532fccea3mr28879745wru.270.1662472651754; Tue, 06 Sep 2022 06:57:31 -0700 (PDT) X-Google-Smtp-Source: AA6agR7eSynrXPsi+KuH/gzENB5rhLBgeEcaH1gNRTh72DAT2eCUNGmvUgoO7mPK83bTeUzoRBEKiQ== X-Received: by 2002:a5d:620f:0:b0:225:32fc:cea3 with SMTP id y15-20020a5d620f000000b0022532fccea3mr28879731wru.270.1662472651469; Tue, 06 Sep 2022 06:57:31 -0700 (PDT) Received: from ?IPV6:2003:d8:2f0d:ba00:c951:31d7:b2b0:8ba0? (p200300d82f0dba00c95131d7b2b08ba0.dip0.t-ipconnect.de. [2003:d8:2f0d:ba00:c951:31d7:b2b0:8ba0]) by smtp.gmail.com with ESMTPSA id t12-20020a05600c198c00b003a2e92edeccsm22530563wmq.46.2022.09.06.06.57.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Sep 2022 06:57:30 -0700 (PDT) Message-ID: <4516a349-49cb-fd7b-176a-f1a9479906d9@redhat.com> Date: Tue, 6 Sep 2022 15:57:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH] mm: gup: fix the fast GUP race against THP collapse To: Jason Gunthorpe Cc: John Hubbard , Yang Shi , peterx@redhat.com, kirill.shutemov@linux.intel.com, hughd@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220901222707.477402-1-shy828301@gmail.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fvghjFiv; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662472660; a=rsa-sha256; cv=none; b=dd+YalBtUeoYnESTSV5t9aZZDtBVRusuJwIY+CXRpOv6birvkxPb7SvKm3SPzsQAR54Qqi ZYDAKVnGaWSspkwSXwlWPQhxoSiDTSiF6ZWxts8ksEZbbDmPwnGc7huHKUQLXaS7uojGyd a4URoEokO2p9ZvSp6JqwaURUte+8q3k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662472660; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GesI69YyBCVOELWdci2COwV5wfsC9CiwSBWxkans3kQ=; b=MSi2xD9F+lumBKmWy37B08IzbUhdF327MKrT5O2XypDfaltSfdCBWr1OClSDLf+jLA+IuJ R8LC/whQhYbjSNTeIVYmUD61PBFfc+LwfQwVK6Vk8EEzjasY8wddsRwozKIwAW2lQj627I RDfL98MHLOnIbDPcR1h4Pl0IvAtuV1M= Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fvghjFiv; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: b59h5rffwb31zrfg39f941oq8dryea4j X-Rspamd-Queue-Id: 4FE8C180095 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1662472660-252122 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 06.09.22 15:47, Jason Gunthorpe wrote: > On Mon, Sep 05, 2022 at 09:59:47AM +0200, David Hildenbrand wrote: > >>> That should be READ_ONCE() for the *pmdp and *ptep reads. Because this >>> whole lockless house of cards may fall apart if we try reading the >>> page table values without READ_ONCE(). >> >> I came to the conclusion that the implicit memory barrier when grabbing a >> reference on the page is sufficient such that we don't need READ_ONCE here. > > READ_ONCE is not about barriers or ordering, you still need the > acquire inside the atomic to make the algorithm work. While I don't disagree with what say is, I'll refer to Documentation/memory-barriers.txt "COMPILER BARRIER". As discussed somewhere in this thread, if we already have an atomic RWM that implies a full ordering, it implies a compile barrier. > > READ_ONCE primarily is a marker that the data being read is unstable > and that the compiler must avoid all instability when reading it. eg > in this case the compiler could insanely double read the value, even > though the 'if' requires only a single read. This would result in > corrupt calculation. As we have a full memory barrier + compile barrier, the compiler might indeed do double reads and all that stuff. BUT, it has to re-read after we incremented the refcount, and IMHO that's the important part to detect the change. -- Thanks, David / dhildenb