From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52A346AA2 for ; Mon, 19 Sep 2022 18:05:29 +0000 (UTC) Received: by mail-wr1-f42.google.com with SMTP id cc5so373634wrb.6 for ; Mon, 19 Sep 2022 11:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=vb/BXICUNW5+h3UQtwzUqhGAHWrBZN2A+UXNfCT8Pqc=; b=Ns9exaZ9YtultAtWZhCFpGg1KR2dHcqO6XVgDCwr+eBGnRvIT8NEw/A/jkKbMICRJN vyk9IGJ2CvNUhq1AooQQQabinD7v2+YVXYuUueA0LikjHOLgB0FCY/YztXTwzkwb6sio ddGcL7vDyMmCiRLvD+CX99sYNptj+i7rzzHoJS2gt+R3uMGbTs26GZNlSP95RJoH1l8B Ga4gG1adKUtjr8QwtnFsh1H8wC2KLkLD4xYZrIzizvvo0cILv6a3Gojc4WYS2ntF2p3t lqMIkKZ6g4mr1NDoZ+jTX0r/wt9v9WbnUYFSJyGR++cOu5S4otfkRSklsQv1oljWKyud OpLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=vb/BXICUNW5+h3UQtwzUqhGAHWrBZN2A+UXNfCT8Pqc=; b=IFW95HnLXsUbQ7LwBd1+qauHyLqD5juP0ZyDDFGfoXcE8iFtw103LQaBIm+tgC2And ZqkltvVRpfS4zg4gQW9Fe7ncQUy2MzDcxlbFcddDdN7A4CE3ddjiG+CtWpt8fNoU8Skh 6+euECOUFvYEhL5hgxJGr0yrvSTeXhPfvta6SY5cQCJDTnc5Aznpq8d/dtMdrp1fa2xb 4HueH34FhBUYd/SToMGZ1e/04pb0M3W0/+S+bRx5Fg2nOJwspFKieGbjg45iMFrmn7va GTfJ2LxN2daEnJBzyGqjuONSKKujDNrrhdmitICCqtOs3EGCgQIzqx6ibPbQ3Ovgqoov kkbw== X-Gm-Message-State: ACrzQf0BaYHGxMZbM7O3dzVP7gk9x6wSBdavWKh2oro1LabZiRnwE9rf oyVn45/6kUwmr7uQS9U94kE= X-Google-Smtp-Source: AMsMyM5H7HXR/4Iir7gke5r6YX2qJZWSIMlDJoDP74sxpyTqChBYtElhHroI7JGUDABxT9OErvuQow== X-Received: by 2002:a05:6000:14c:b0:22a:c14a:29f8 with SMTP id r12-20020a056000014c00b0022ac14a29f8mr11434021wrx.588.1663610727419; Mon, 19 Sep 2022 11:05:27 -0700 (PDT) Received: from wedsonaf-dev ([81.2.152.129]) by smtp.gmail.com with ESMTPSA id s10-20020a5d510a000000b002252884cc91sm14494873wrt.43.2022.09.19.11.05.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Sep 2022 11:05:26 -0700 (PDT) Date: Mon, 19 Sep 2022 19:05:23 +0100 From: Wedson Almeida Filho To: Linus Torvalds Cc: Matthew Wilcox , Kees Cook , Miguel Ojeda , Konstantin Shelekhin , ojeda@kernel.org, alex.gaynor@gmail.com, ark.email@gmail.com, bjorn3_gh@protonmail.com, bobo1239@web.de, bonifaido@gmail.com, boqun.feng@gmail.com, davidgow@google.com, dev@niklasmohrin.de, dsosnowski@dsosnowski.pl, foxhlchen@gmail.com, gary@garyguo.net, geofft@ldpreload.com, gregkh@linuxfoundation.org, jarkko@kernel.org, john.m.baublitz@gmail.com, leseulartichaut@gmail.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, m.falkowski@samsung.com, me@kloenk.de, milan@mdaverde.com, mjmouse9999@gmail.com, patches@lists.linux.dev, rust-for-linux@vger.kernel.org, thesven73@gmail.com, viktor@v-gar.de, Andreas Hindborg Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate Message-ID: References: <20220805154231.31257-13-ojeda@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Sep 19, 2022 at 10:20:52AM -0700, Linus Torvalds wrote: > On Mon, Sep 19, 2022 at 9:09 AM Linus Torvalds > wrote: > > > > The whole "really know what context this code is running within" is > > really important. You may want to write very explicit comments about > > it. > > Side note: a corollary of this is that people should avoid "dynamic > context" things like the plague, because it makes for such pain when > the context isn't statically obvious. As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that leaving it up to comments isn't enough. I don't care as much about allocation flags as I do about sleeping in an rcu read-side critical region. When CONFIG_PREEMPT=n, if some CPU makes the mistake of sleeping between rcu_read_lock()/rcu_read_unlock(), RCU will take that as a quiescent state, which may cause unsuspecting code waiting for a grace period to wake up too early and potentially free memory that is still in use, which is obviously undefined behaviour. We generally have two routes to avoid undefined behaviour: detect at compile time (and fail compilation) or at runtime (and stop things before they go too far). The former, while feasible, would require some static analysi or passing tokens as arguments to guarantee that we're in sleepable context when sleeping (all ellided at compile time, so zero-cost in terms of run-time performance), but likely painful to program use. Always having preempt_count would allow us to detect such issues in RCU at runtime (for both C and Rust) and prevent user-after-frees. Do you have an opinion on the above? Cheers, -Wedson