Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2234009pxb; Mon, 18 Jan 2021 11:50:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxe3LtRI1SsYAf5IgDUqiyXu/ORvCCIRaoQBDFxelxKf2YvEBhQ3Rzq9zvjNHYpZgbG/gZz X-Received: by 2002:a17:906:d209:: with SMTP id w9mr784440ejz.211.1610999457260; Mon, 18 Jan 2021 11:50:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610999457; cv=none; d=google.com; s=arc-20160816; b=Ip8CMxjL0pSVBa4rn0gPcnI+sfgKRJ0gNO+TmrpZ693VMNEIERqFsllTDFK4bx71BI 9iKEhALaabY9Gtz1pmRyEH2+zpWlNbDWatx4nG28UizbazqBPVLrDmL3vnthT428th3q oIxm/w1EPkoR3bBz6iI6ZyM9g67grpJJXMnTmXCSxjMdDH/adpbe9rtzPT+lpBcgIV7D NADjPU5k0l9G77EH2dB4yRMLOkKYpZoaCbN0pCQjmdRo/wFw4fnI/jGN7uPqFx94d3vp aVdvvLPuewnDS32wHwVB6MiRrgxf9PZlw1T1C6dQ87REN88NJNhm2yfwgCWcCQnhzUks LLgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=zGLv7xl7MvMS5uMzKGZJhH+lOLyxoM+cYRuMkiU+SP8=; b=o34oLswtf7a4QLVJEVVgqTDp1bH9jsUGU3AngZJC55UPGyFwpvZzPSLv3BLn2lpWJG 9bIv9z4bt+MhGQO4VhzkDl4HayO/l2um/DIjYWmsB4GyfwR5oavUIJvpkEEwT4TfWOyn W78fN3v8WeoD1Bx8fZHEc2fLphleykWOz7sXAvt+c/0IDtC9uO3UkCt6XOzhT2rltnu4 MNbTafCxWoTZvBItriLEsio+XB6VH0lsFo17fLh18VdjqNUDLu0gb51I8gY86BfkYUXa zgVJzxRTyhb2S8VSw1HsNJLQn5lUhw6ymIh+QZEby6tvN1PhtUNB9djNH+e63k0X+Y7U u9Bw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f14si1506863ejc.535.2021.01.18.11.50.33; Mon, 18 Jan 2021 11:50:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437606AbhARTse (ORCPT + 99 others); Mon, 18 Jan 2021 14:48:34 -0500 Received: from raptor.unsafe.ru ([5.9.43.93]:56470 "EHLO raptor.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394024AbhARTrD (ORCPT ); Mon, 18 Jan 2021 14:47:03 -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 3C0D820479; Mon, 18 Jan 2021 19:45:56 +0000 (UTC) Date: Mon, 18 Jan 2021 20:45:51 +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: <20210118194551.h2hrwof7b3q5vgoi@example.org> References: <116c7669744404364651e3b380db2d82bb23f983.1610722473.git.gladkov.alexey@gmail.com> 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 19:46:07 +0000 (UTC) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 18, 2021 at 11:14:48AM -0800, Linus Torvalds wrote: > On Fri, Jan 15, 2021 at 6:59 AM Alexey Gladkov wrote: > > > > @@ -152,10 +153,7 @@ static struct ucounts *get_ucounts(struct user_namespace *ns, kuid_t uid) > > ucounts = new; > > } > > } > > - if (ucounts->count == INT_MAX) > > - ucounts = NULL; > > - else > > - ucounts->count += 1; > > + refcount_inc(&ucounts->count); > > spin_unlock_irq(&ucounts_lock); > > return ucounts; > > } > > This is wrong. > > It used to return NULL when the count saturated. > > Now it just silently saturates. > > I'm not sure how many people care, but that NULL return ends up being > returned quite widely (through "inc_uncount()" and friends). > > The fact that this has no commit message at all to explain what it is > doing and why is also a grounds for just NAK. Sorry about that. I thought that this code is not needed when switching from int to refcount_t. I was wrong. I'll think about how best to check it. -- Rgrds, legion