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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 090E6C2D0A8 for ; Mon, 28 Sep 2020 23:19:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C426620774 for ; Mon, 28 Sep 2020 23:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601335158; bh=XQKyASpPIt40WNaNXBoU3KZo5t8ZAquVbgrnzpIDkQs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:List-ID:From; b=ZDgEuexhzB/1RJpizbKViWCu+tymylBdTb4n52Ts9VLRsgELhI6vp/89u46m1qZhI 1WvJA+/uxVkRoTpd55BgNvAW/PqlPbRmMFHbDiTYJ6fRkJruiyg/fBEPfMO1gt/GW3 O47Z81TNQIBOrXmmn8T/rrjQOdbLx2tTmAZ0mfRQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726969AbgI1XSm (ORCPT ); Mon, 28 Sep 2020 19:18:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726882AbgI1XSm (ORCPT ); Mon, 28 Sep 2020 19:18:42 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BD3AC0604C1 for ; Mon, 28 Sep 2020 16:01:58 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id a2so2633275otr.11 for ; Mon, 28 Sep 2020 16:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G0T+RHalnOsx2x8ckC0/qbcC+AW5CzDJJe/ApeOC0+k=; b=Bm4inKBH6owPhXAt+WYO1qUH2sD6gp/JHO/rGqnxUTTZurVuB2oOlCFyuxF6Mrm1Fb Jl3P3mG83W6n3SQ1lAam+xSpWMDhH6aKSofFE4lx90AFeuypIUoqFdZzThdjUvc+zhBH v12MOvqlrd7l6N2Dd1M3mkf+WXumL1sotF7rM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G0T+RHalnOsx2x8ckC0/qbcC+AW5CzDJJe/ApeOC0+k=; b=pMnV6DdUrQQEKtg0DWFS76Gxf6XgzJvzMkX8U5Sxt3I9rxw3BgPEAipJhlZOLpjdks N1ga+w2EfS0UWzTmqR5SKFYSMdCuBA5IV3Q3K8LbZU6wTc9tmMUWpViPFWFpFogJtbUo RWv4La2uUbSz6OuK2/q0BEEJQaHOwRMYYySnuS0uXhdQl+ASD0d5fkW5eP/vd9xQ5Gnz acpO7MtLztOoQTIbCHhdI4oYu2eJxYrEoXv7DSDWvPPd14uErdI73btpjINASeUEPRtw SGvBWi5xO1eE55f3WDrndfvJI6EAF2M7/G4rcktrHa1vdgIqIDG8C7mf4wSXpTtcUWCQ icEg== X-Gm-Message-State: AOAM530mKkl6Whk0A38WzD/t8sBh+Ew0jG20sr9ceRUN96GISVNgcm6M 0iES8KP9NFPWbuLlzsjgSyK55g== X-Google-Smtp-Source: ABdhPJwSkr7ZuRk8wTA1EBTCYkbbMO+PyhCPeIPgE2gfdGNAWiJW8KkTuzvV5dYyicY9sgk6dMhK3A== X-Received: by 2002:a05:6830:1616:: with SMTP id g22mr823663otr.289.1601334117878; Mon, 28 Sep 2020 16:01:57 -0700 (PDT) Received: from [192.168.1.112] (c-24-9-64-241.hsd1.co.comcast.net. [24.9.64.241]) by smtp.gmail.com with ESMTPSA id a22sm559885oie.13.2020.09.28.16.01.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 16:01:57 -0700 (PDT) Subject: Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters To: Joel Fernandes , Kees Cook Cc: corbet@lwn.net, gregkh@linuxfoundation.org, shuah@kernel.org, rafael@kernel.org, johannes@sipsolutions.net, lenb@kernel.org, james.morse@arm.com, tony.luck@intel.com, bp@alien8.de, arve@android.com, tkjos@android.com, maco@android.com, christian@brauner.io, hridya@google.com, surenb@google.com, minyard@acm.org, arnd@arndb.de, mchehab@kernel.org, rric@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-acpi@vger.kernel.org, devel@driverdev.osuosl.org, openipmi-developer@lists.sourceforge.net, linux-edac@vger.kernel.org, Shuah Khan References: <20200927233526.GA500818@google.com> <202009281331.444F36A7B@keescook> <20200928211709.GA2641213@google.com> From: Shuah Khan Message-ID: <9c237ead-5b68-2e3f-2af6-a08c03b24fde@linuxfoundation.org> Date: Mon, 28 Sep 2020 17:01:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200928211709.GA2641213@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 9/28/20 3:17 PM, Joel Fernandes wrote: > On Mon, Sep 28, 2020 at 01:34:31PM -0700, Kees Cook wrote: >> On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote: >>> On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: >>>> This patch series is a result of discussion at the refcount_t BOF >>>> the Linux Plumbers Conference. In this discussion, we identified >>>> a need for looking closely and investigating atomic_t usages in >>>> the kernel when it is used strictly as a counter without it >>>> controlling object lifetimes and state changes. >>>> >>>> There are a number of atomic_t usages in the kernel where atomic_t api >>>> is used strictly for counting and not for managing object lifetime. In >>>> some cases, atomic_t might not even be needed. >>>> >>>> The purpose of these counters is twofold: 1. clearly differentiate >>>> atomic_t counters from atomic_t usages that guard object lifetimes, >>>> hence prone to overflow and underflow errors. It allows tools that scan >>>> for underflow and overflow on atomic_t usages to detect overflow and >>>> underflows to scan just the cases that are prone to errors. 2. provides >>>> non-atomic counters for cases where atomic isn't necessary. >>> >>> Nice series :) >>> Thanks. >>> It appears there is no user of counter_simple in this series other than the >>> selftest. Would you be planning to add any conversions in the series itself, >>> for illustration of use? Sorry if I missed a usage. >>> >>> Also how do we guard against atomicity of counter_simple RMW operations? Is >>> the implication that it should be guarded using other synchronization to >>> prevent lost-update problem? >>> >>> Some more comments: >>> >>> 1. atomic RMW operations that have a return value are fully ordered. Would >>> you be adding support to counter_simple for such ordering as well, for >>> consistency? >> >> No -- there is no atomicity guarantee for counter_simple. I would prefer >> counter_simple not exist at all, specifically for this reason. > > Yeah I am ok with it not existing, especially also as there are no examples > of its conversion/usage in the series. > No. counter_simple is just for counting when there is no need for atomicity with the premise that there might be some use-cases. You are right that this patch series doesn't use these. My hunch is though that atomic_t is overused and it isn't needed in all cases. I will do some research to look for any places that can use counter_simple before I spin v2. If I don't find any, I can drop them. thanks, -- Shuah 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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 984B5C2D0A8 for ; Mon, 28 Sep 2020 23:02:01 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 24CFD23A54 for ; Mon, 28 Sep 2020 23:02:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Bm4inKBH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24CFD23A54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 884F984519; Mon, 28 Sep 2020 23:02:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDQA7CdpEx90; Mon, 28 Sep 2020 23:02:00 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by fraxinus.osuosl.org (Postfix) with ESMTP id F03A284542; Mon, 28 Sep 2020 23:01:59 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 636D51BF278 for ; Mon, 28 Sep 2020 23:01:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 5C1A484542 for ; Mon, 28 Sep 2020 23:01:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RP7YhOKMa85 for ; Mon, 28 Sep 2020 23:01:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by fraxinus.osuosl.org (Postfix) with ESMTPS id A908F84519 for ; Mon, 28 Sep 2020 23:01:58 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id m12so2695969otr.0 for ; Mon, 28 Sep 2020 16:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G0T+RHalnOsx2x8ckC0/qbcC+AW5CzDJJe/ApeOC0+k=; b=Bm4inKBH6owPhXAt+WYO1qUH2sD6gp/JHO/rGqnxUTTZurVuB2oOlCFyuxF6Mrm1Fb Jl3P3mG83W6n3SQ1lAam+xSpWMDhH6aKSofFE4lx90AFeuypIUoqFdZzThdjUvc+zhBH v12MOvqlrd7l6N2Dd1M3mkf+WXumL1sotF7rM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G0T+RHalnOsx2x8ckC0/qbcC+AW5CzDJJe/ApeOC0+k=; b=nHMYJzU6shrF6oVsRIpEaEZmSXuxDtiB+qZZl6raK0p3QHiEUnoyM9l0ynVxDXxtDb VvOpBXKo/H9PsMQSl61fUn/eqoS/Y6+EKnXrLfgVHFu/qsZ0YW93FJREvcs1k1ejyQ0L lYfB7BXQOQ6Ase3AFrH59MIAIz5IR4Pq6UXX8vqMTz0LYZW85F6A3oOvzylUhQriu1Ro QBYP6A1tyEbMYNuU+SuQNcaFtRilO40mVBgD/RXFimV8ZMV035pVxyUCeVPRItX8+1/6 aAO31oeOcsL3aPujKCo6aSEE7hwF0lcgQv3TRwIw6v3WfZ+Pgs9DY7poIM1gxNK3TVpH mw/A== X-Gm-Message-State: AOAM530RQZ7p333RglgzBdOd2lAy5HHG5b2iFxf0/KwK9h/iOgclLh6e ltSNqgnTustftmqhn+OrimEpFw== X-Google-Smtp-Source: ABdhPJwSkr7ZuRk8wTA1EBTCYkbbMO+PyhCPeIPgE2gfdGNAWiJW8KkTuzvV5dYyicY9sgk6dMhK3A== X-Received: by 2002:a05:6830:1616:: with SMTP id g22mr823663otr.289.1601334117878; Mon, 28 Sep 2020 16:01:57 -0700 (PDT) Received: from [192.168.1.112] (c-24-9-64-241.hsd1.co.comcast.net. [24.9.64.241]) by smtp.gmail.com with ESMTPSA id a22sm559885oie.13.2020.09.28.16.01.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 16:01:57 -0700 (PDT) Subject: Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters To: Joel Fernandes , Kees Cook References: <20200927233526.GA500818@google.com> <202009281331.444F36A7B@keescook> <20200928211709.GA2641213@google.com> From: Shuah Khan Message-ID: <9c237ead-5b68-2e3f-2af6-a08c03b24fde@linuxfoundation.org> Date: Mon, 28 Sep 2020 17:01:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200928211709.GA2641213@google.com> Content-Language: en-US X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rafael@kernel.org, linux-kselftest@vger.kernel.org, rric@kernel.org, shuah@kernel.org, devel@driverdev.osuosl.org, minyard@acm.org, corbet@lwn.net, surenb@google.com, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org, tkjos@android.com, arnd@arndb.de, bp@alien8.de, Shuah Khan , openipmi-developer@lists.sourceforge.net, mchehab@kernel.org, maco@android.com, christian@brauner.io, linux-edac@vger.kernel.org, tony.luck@intel.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, arve@android.com, james.morse@arm.com, hridya@google.com, johannes@sipsolutions.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On 9/28/20 3:17 PM, Joel Fernandes wrote: > On Mon, Sep 28, 2020 at 01:34:31PM -0700, Kees Cook wrote: >> On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote: >>> On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: >>>> This patch series is a result of discussion at the refcount_t BOF >>>> the Linux Plumbers Conference. In this discussion, we identified >>>> a need for looking closely and investigating atomic_t usages in >>>> the kernel when it is used strictly as a counter without it >>>> controlling object lifetimes and state changes. >>>> >>>> There are a number of atomic_t usages in the kernel where atomic_t api >>>> is used strictly for counting and not for managing object lifetime. In >>>> some cases, atomic_t might not even be needed. >>>> >>>> The purpose of these counters is twofold: 1. clearly differentiate >>>> atomic_t counters from atomic_t usages that guard object lifetimes, >>>> hence prone to overflow and underflow errors. It allows tools that scan >>>> for underflow and overflow on atomic_t usages to detect overflow and >>>> underflows to scan just the cases that are prone to errors. 2. provides >>>> non-atomic counters for cases where atomic isn't necessary. >>> >>> Nice series :) >>> Thanks. >>> It appears there is no user of counter_simple in this series other than the >>> selftest. Would you be planning to add any conversions in the series itself, >>> for illustration of use? Sorry if I missed a usage. >>> >>> Also how do we guard against atomicity of counter_simple RMW operations? Is >>> the implication that it should be guarded using other synchronization to >>> prevent lost-update problem? >>> >>> Some more comments: >>> >>> 1. atomic RMW operations that have a return value are fully ordered. Would >>> you be adding support to counter_simple for such ordering as well, for >>> consistency? >> >> No -- there is no atomicity guarantee for counter_simple. I would prefer >> counter_simple not exist at all, specifically for this reason. > > Yeah I am ok with it not existing, especially also as there are no examples > of its conversion/usage in the series. > No. counter_simple is just for counting when there is no need for atomicity with the premise that there might be some use-cases. You are right that this patch series doesn't use these. My hunch is though that atomic_t is overused and it isn't needed in all cases. I will do some research to look for any places that can use counter_simple before I spin v2. If I don't find any, I can drop them. thanks, -- Shuah _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel