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=-5.8 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 D84E1C4338F for ; Thu, 19 Aug 2021 19:09:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 71FC26108B for ; Thu, 19 Aug 2021 19:09:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 71FC26108B 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=kvack.org Received: by kanga.kvack.org (Postfix) id 94E986B006C; Thu, 19 Aug 2021 15:09:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FED36B0071; Thu, 19 Aug 2021 15:09:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C7686B0072; Thu, 19 Aug 2021 15:09:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id 609F36B006C for ; Thu, 19 Aug 2021 15:09:57 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F1AE11F349 for ; Thu, 19 Aug 2021 19:09:56 +0000 (UTC) X-FDA: 78492769992.20.770C060 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf01.hostedemail.com (Postfix) with ESMTP id 9ECC15024D56 for ; Thu, 19 Aug 2021 19:09:56 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id o10so15087508lfr.11 for ; Thu, 19 Aug 2021 12:09:56 -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=47eBvc3morcta5Nynwcfir11Tm/8Tdt9QjDTf46bd28=; b=CvQP0aLgX9ae5Hc/8Bcp+kZ0Gxk9PyruGSgedrMRoG9uh8NRj8Xb7JRC3jT7s4a8qZ NMLDEKuam1GC97jSirK6f4V6WFZpxp15taQzaltBOnh5Fiy2Vt18/59rapCHUcVNOt7w QfXaUM3dini5pJyTDHtMVatSFEe3fxEPGFUIU= 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=47eBvc3morcta5Nynwcfir11Tm/8Tdt9QjDTf46bd28=; b=Ck011mTZ7w4Qo2kwNfklsZPeXnIg3hDYAimpY79PVnX2mh1KaDQkTg+OWxp93A+faS loiUUlNtmfjfJtraOXFhH0CZDpMEcqkM/vBqriAWSgN+zg7+bOrfhA6lavu4gHzjuHIU uHqZ0FRVUtA3KzXFZRYpmXcBqUg5FdgcK+29fWFwgnalWjoP1fzUtfpQfcQk3VMnMnzz vPLiQdGcFgc2UV9eSoqrQjtoxGJVIM/8D9BoGh8CzRpqQU16pmeG9Uk8jAuWOrGxrtmp n8odq3Ku+j+rFSDRamwbbUM8HA2qBfBbqlar5ei3rkPgcgaBRfgRxYni3jY/tsxV5Vjp fSLA== X-Gm-Message-State: AOAM531PHYjBNlk0b/pA5s+6VTHBn1+Q0FzQdBJEp/1Rivm7urV6tEiU 0JRkol2xjRvhvaG/pGv0jzT8D+BQ1FFyWpoz X-Google-Smtp-Source: ABdhPJyxOmdb9ktxacoKlbfUF0AWrBB9/BnYGQMIff6gi0vqXEifwme4SxQZTKmHuITNlBWVRQkh/Q== X-Received: by 2002:a05:6512:3494:: with SMTP id v20mr5528472lfr.637.1629400194589; Thu, 19 Aug 2021 12:09:54 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id b19sm391108lff.121.2021.08.19.12.09.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 12:09:53 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id c12so13215472ljr.5 for ; Thu, 19 Aug 2021 12:09:53 -0700 (PDT) X-Received: by 2002:a2e:557:: with SMTP id 84mr13169568ljf.507.1629400193248; Thu, 19 Aug 2021 12:09:53 -0700 (PDT) MIME-Version: 1.0 References: <1626665029-49104-1-git-send-email-xiyuyang19@fudan.edu.cn> <20210720160127.ac5e76d1e03a374b46f25077@linux-foundation.org> <20210819132131.GA15779@willie-the-truck> In-Reply-To: From: Linus Torvalds Date: Thu, 19 Aug 2021 12:09:37 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/rmap: Convert from atomic_t to refcount_t on anon_vma->refcount To: Peter Zijlstra Cc: Will Deacon , Andrew Morton , Borislav Petkov , Xiyu Yang , Alistair Popple , Yang Shi , Shakeel Butt , Hugh Dickins , Miaohe Lin , Linux Kernel Mailing List , Linux-MM , yuanxzhang@fudan.edu.cn, Xin Tan , Will Deacon , David Howells Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9ECC15024D56 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CvQP0aLg; dmarc=none; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam04 X-Stat-Signature: j8aj4e4wz85m9so7nz38sxwskd9q7367 X-HE-Tag: 1629400196-175858 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 Thu, Aug 19, 2021 at 8:21 AM Peter Zijlstra wrote: > > If we can skip the OF... we can do something like this: Honestly, I think a lot of the refcount code is questionable. It was absolutely written with no care for performance AT ALL. I'm not sure it helps to then add arch-specific code for it without thinking it through a _lot_ first. It might be better to just have a "atomic_t with overflow handling" in general, exactly because the refcount_t was designed and written without any regard for code that cares about performance. > static inline bool refcount_dec_and_test(refcount_t *r) > { > asm_volatile_goto (LOCK_PREFIX "decl %[var]\n\t" > "jz %l[cc_zero]\n\t" > "jns 1f\n\t" I think you can use "jl" for the bad case. You want to fail if the old value was negative, or if the old value was less than what you subtracted. That's literally the "less than" operator. I think it's better to handle that case out-of-line than play games with UD, though - this is going to be the rare case, the likelihood that we get the fixup wrong is just too big. Once it's out-of-line it's not as critical any more, even if it does add to the size of the code. So if we do this, I think it should be something like static inline __must_check bool refcount_dec_and_test(refcount_t *r) { asm_volatile_goto (LOCK_PREFIX "decl %[var]\n\t" "jz %l[cc_zero]\n\t" "jl %l[cc_error]" : : [var] "m" (r->refs.counter) : "memory" : cc_zero, cc_error); return false; cc_zero: return true; cc_error: refcount_warn_saturate(r, REFCOUNT_SUB_UAF); return false; } and we can discuss whether we could improve on the refcount_warn_saturate() separately. But see above: maybe just make this a separate "careful atomic_t", with the option to panic-on-overflow. So then we could get rid of refcount_warn_saturate() enmtirely above, and instead just have a (compile-time option) BUG() case, with the non-careful version just being our existing atomic_dec_and_test. Giving people who want a smaller kernel the option to do so, while giving people who want checking the option too. Linus