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 9D2BAC433DB for ; Mon, 18 Jan 2021 20:58:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F9CD207C4 for ; Mon, 18 Jan 2021 20:58:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389515AbhARU5o (ORCPT ); Mon, 18 Jan 2021 15:57:44 -0500 Received: from raptor.unsafe.ru ([5.9.43.93]:40720 "EHLO raptor.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388520AbhARU5k (ORCPT ); Mon, 18 Jan 2021 15:57:40 -0500 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) Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org 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