Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753171AbdGJJex (ORCPT ); Mon, 10 Jul 2017 05:34:53 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:33197 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbdGJJev (ORCPT ); Mon, 10 Jul 2017 05:34:51 -0400 MIME-Version: 1.0 In-Reply-To: <87k23gsn4u.fsf@xmission.com> References: <1499417992-3238-1-git-send-email-elena.reshetova@intel.com> <1499417992-3238-2-git-send-email-elena.reshetova@intel.com> <87bmottgo4.fsf@xmission.com> <2236FBA76BA1254E88B949DDB74E612B6FF2269B@IRSMSX102.ger.corp.intel.com> <87k23gsn4u.fsf@xmission.com> From: Alexey Dobriyan Date: Mon, 10 Jul 2017 12:34:50 +0300 Message-ID: Subject: Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t To: "Eric W. Biederman" Cc: "Reshetova, Elena" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "gregkh@linuxfoundation.org" , "akpm@linux-foundation.org" , "mingo@redhat.com" , "serge@hallyn.com" , "arozansk@redhat.com" , "dave@stgolabs.net" , "keescook@chromium.org" , Hans Liljestrand , David Windsor Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1358 Lines: 34 On Mon, Jul 10, 2017 at 11:37 AM, Eric W. Biederman wrote: > "Reshetova, Elena" writes: > > 2>> Elena Reshetova writes: >>> >>> > refcount_t type and corresponding API should be >>> > used instead of atomic_t when the variable is used as >>> > a reference counter. This allows to avoid accidental >>> > refcounter overflows that might lead to use-after-free >>> > situations. >>> >>> In this patch you can see all of the uses of the count. >>> What accidental refcount overflows are possible? >> >> Even if one can guarantee and prove that in the current implementation >> there are no overflows possible, we can't say that for >> sure for any future implementation. Bugs might always happen >> unfortunately, but if we convert the refcounter to a safer >> type we can be sure that overflows are not possible. >> >> Does it make sense to you? > > Not for code that is likely to remain unchanged for a decade no. > > This looks like a large set of unautomated changes without any real > thought put into it. That almost always results in a typo somewhere > that breaks things. This is nonsense. The wrong code would simply emit a warning which are caught very quickly. > So there is no benefit to the code, and a non-zero chance that there > will be a typo breaking the code.