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=-0.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 8CDC6C433E0 for ; Mon, 18 Jan 2021 20:57:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 239DE207C4 for ; Mon, 18 Jan 2021 20:57:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 239DE207C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 60C178D0029; Mon, 18 Jan 2021 15:57:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5942C8D0017; Mon, 18 Jan 2021 15:57:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 410158D0029; Mon, 18 Jan 2021 15:57:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id 2470B8D0017 for ; Mon, 18 Jan 2021 15:57:04 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A73CB180AD806 for ; Mon, 18 Jan 2021 20:57:03 +0000 (UTC) X-FDA: 77720105526.08.pail09_1909cd62754c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 8A6991819E785 for ; Mon, 18 Jan 2021 20:57:03 +0000 (UTC) X-HE-Tag: pail09_1909cd62754c X-Filterd-Recvd-Size: 3337 Received: from raptor.unsafe.ru (raptor.unsafe.ru [5.9.43.93]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Mon, 18 Jan 2021 20:57:02 +0000 (UTC) Received: from example.org (ip-89-103-122-167.net.upcbroadband.cz [89.103.122.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by raptor.unsafe.ru (Postfix) with ESMTPSA id AA00720479; Mon, 18 Jan 2021 20:56:34 +0000 (UTC) Date: Mon, 18 Jan 2021 21:56:29 +0100 From: Alexey Gladkov To: Linus Torvalds Cc: LKML , io-uring , Kernel Hardening , Linux Containers , Linux-MM , Andrew Morton , Christian Brauner , "Eric W . Biederman" , Jann Horn , Jens Axboe , Kees Cook , Oleg Nesterov Subject: Re: [RFC PATCH v3 1/8] Use refcount_t for ucounts reference counting Message-ID: <20210118205629.zro2qkd3ut42bpyq@example.org> References: <116c7669744404364651e3b380db2d82bb23f983.1610722473.git.gladkov.alexey@gmail.com> <20210118194551.h2hrwof7b3q5vgoi@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (raptor.unsafe.ru [5.9.43.93]); Mon, 18 Jan 2021 20:56:57 +0000 (UTC) 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 Mon, Jan 18, 2021 at 12:34:29PM -0800, Linus Torvalds wrote: > On Mon, Jan 18, 2021 at 11:46 AM Alexey Gladkov > wrote: > > > > Sorry about that. I thought that this code is not needed when switching > > from int to refcount_t. I was wrong. > > Well, you _may_ be right. I personally didn't check how the return > value is used. > > I only reacted to "it certainly _may_ be used, and there is absolutely > no comment anywhere about why it wouldn't matter". I have not found examples where checked the overflow after calling refcount_inc/refcount_add. For example in kernel/fork.c:2298 : current->signal->nr_threads++; atomic_inc(¤t->signal->live); refcount_inc(¤t->signal->sigcnt); $ semind search signal_struct.sigcnt def include/linux/sched/signal.h:83 refcount_t sigcnt; m-- kernel/fork.c:723 put_signal_struct if (refcount_dec_and_test(&sig->sigcnt)) m-- kernel/fork.c:1571 copy_signal refcount_set(&sig->sigcnt, 1); m-- kernel/fork.c:2298 copy_process refcount_inc(¤t->signal->sigcnt); It seems to me that the only way is to use __refcount_inc and then compare the old value with REFCOUNT_MAX Since I have not seen examples of such checks, I thought that this is acceptable. Sorry once again. I have not tried to hide these changes. -- Rgrds, legion