From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753851AbdGJIp6 (ORCPT ); Mon, 10 Jul 2017 04:45:58 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:40797 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753580AbdGJIp5 (ORCPT ); Mon, 10 Jul 2017 04:45:57 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Reshetova\, Elena" Cc: "linux-kernel\@vger.kernel.org" , "peterz\@infradead.org" , "gregkh\@linuxfoundation.org" , "akpm\@linux-foundation.org" , "mingo\@redhat.com" , "adobriyan\@gmail.com" , "serge\@hallyn.com" , "arozansk\@redhat.com" , "dave\@stgolabs.net" , "keescook\@chromium.org" , Hans Liljestrand , "David Windsor" 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> Date: Mon, 10 Jul 2017 03:37:53 -0500 In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B6FF2269B@IRSMSX102.ger.corp.intel.com> (Elena Reshetova's message of "Mon, 10 Jul 2017 06:48:22 +0000") Message-ID: <87k23gsn4u.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dUUK7-0005i3-KP;;;mid=<87k23gsn4u.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18GGYFhCsAucThfFWbb/NWuGD1GwHfxHt4= X-SA-Exim-Connect-IP: 67.3.213.87 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% * [score: 0.1529] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;"Reshetova\, Elena" X-Spam-Relay-Country: X-Spam-Timing: total 5319 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.1 (0.1%), b_tie_ro: 2.1 (0.0%), parse: 1.29 (0.0%), extract_message_metadata: 26 (0.5%), get_uri_detail_list: 2.1 (0.0%), tests_pri_-1000: 11 (0.2%), tests_pri_-950: 2.2 (0.0%), tests_pri_-900: 1.69 (0.0%), tests_pri_-400: 31 (0.6%), check_bayes: 29 (0.5%), b_tokenize: 12 (0.2%), b_tok_get_all: 7 (0.1%), b_comp_prob: 4.1 (0.1%), b_tok_touch_all: 2.2 (0.0%), b_finish: 0.75 (0.0%), tests_pri_0: 587 (11.0%), check_dkim_signature: 0.97 (0.0%), check_dkim_adsp: 4.4 (0.1%), tests_pri_500: 4651 (87.4%), poll_dns_idle: 4643 (87.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "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. So there is no benefit to the code, and a non-zero chance that there will be a typo breaking the code. All to harden the code for an unlikely future when the code is updated with a full test cycle and people paying attention. Introduce a bug now to avoid a bug in the future. That seems like a very poor engineering trade off. Eric