From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751440AbdGRM1S convert rfc822-to-8bit (ORCPT ); Tue, 18 Jul 2017 08:27:18 -0400 Received: from mga06.intel.com ([134.134.136.31]:26736 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751415AbdGRM1R (ORCPT ); Tue, 18 Jul 2017 08:27:17 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,377,1496127600"; d="scan'208";a="112619339" From: "Reshetova, Elena" To: Julia Lawall CC: "linux-kernel@vger.kernel.org" , "cocci@systeme.lip6.fr" , Gilles Muller , "nicolas.palix@imag.fr" , "mmarek@suse.com" , "keescook@chromium.org" , "ishkamiel@gmail.com" Subject: RE: [PATCH] Coccinelle report script for refcounters Thread-Topic: [PATCH] Coccinelle report script for refcounters Thread-Index: AQHS/5pWDXpdGpwpG0un9f/SB9ncgaJZNSWAgAAbEfCAABisAIAAGORw Date: Tue, 18 Jul 2017 12:27:13 +0000 Message-ID: <2236FBA76BA1254E88B949DDB74E612B6FF26BE0@IRSMSX102.ger.corp.intel.com> References: <1500364111-2192-1-git-send-email-elena.reshetova@intel.com> <2236FBA76BA1254E88B949DDB74E612B6FF26A28@IRSMSX102.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Tue, 18 Jul 2017, Reshetova, Elena wrote: > > > > On Tue, 18 Jul 2017, Elena Reshetova wrote: > > > > > > > The below script can be used to detect potential misusage > > > > of atomic_t type and API for reference counting purposes. > > > > Now when we have a dedicated refcount_t type and API with > > > > security protection implemented, people should be using it > > > > instead. > > > > > > > > Currently it still reports many occurences since we are > > > > nowhere near the end of our kernel-wide conversion execrise, > > > > but hopefully after couple of cycles more, the amount of > > > > output would be much more limited. > > > > > > > > Each script result must be analysed manually before any > > > > conversion, since refcount_t might not suit for certain > > > > purposes (for example if an object is not always destroyed > > > > upon refcounter reaching zero, if increments from zero are > > > > allowed in the code etc.) > > > > > > > > As we go further and get less results in output, we will > > > > improve the pattern to detect conversion cases more precisely. > > > > > > The regexps are the best you can do? > > > > They are simple and so far they were sufficient for the purpose since > > they found pretty much all the cases we are aware about. I was thinking > > on working to improve the pattern later on after we merge the bulk of > > conversions and I have some cycles free on that front. > > > > What would you suggest to do instead of regexps? > > Is there anything about the definitions of these functions that indicates > why they are important? I am not sure I understand the question fully. Do you mean the functions used in the rules, such as atomic_dec_and_test() etc.? If yes, then for example the combination of atomic_dec_and_test(&(a)->x) on a pointer, then followed later by some kind of *free*(a) function (kfree, kmem_cache_free() etc.) on that pointer is a quite common indicator that we are dealing with a reference counter since they would normally free resources when counter reaches zero. Again, it is not a 100% indicator since I have seen weird schemes that for example free a resource upon reaching -1, or free it in one case and don't free on another, but such cases are more rare. Does this answer your questions? Best Regards, Elena. > > julia > > > > > Best Regards, > > Elena. > > > > > > > > julia > > > > > > > > > > > Elena Reshetova (1): > > > > Coccinelle: add atomic_as_refcounter script > > > > > > > > scripts/coccinelle/api/atomic_as_refcounter.cocci | 102 > > > ++++++++++++++++++++++ > > > > 1 file changed, 102 insertions(+) > > > > create mode 100644 scripts/coccinelle/api/atomic_as_refcounter.cocci > > > > > > > > -- > > > > 2.7.4 > > > > > > > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: elena.reshetova@intel.com (Reshetova, Elena) Date: Tue, 18 Jul 2017 12:27:13 +0000 Subject: [Cocci] [PATCH] Coccinelle report script for refcounters In-Reply-To: References: <1500364111-2192-1-git-send-email-elena.reshetova@intel.com> <2236FBA76BA1254E88B949DDB74E612B6FF26A28@IRSMSX102.ger.corp.intel.com> Message-ID: <2236FBA76BA1254E88B949DDB74E612B6FF26BE0@IRSMSX102.ger.corp.intel.com> To: cocci@systeme.lip6.fr List-Id: cocci@systeme.lip6.fr > On Tue, 18 Jul 2017, Reshetova, Elena wrote: > > > > On Tue, 18 Jul 2017, Elena Reshetova wrote: > > > > > > > The below script can be used to detect potential misusage > > > > of atomic_t type and API for reference counting purposes. > > > > Now when we have a dedicated refcount_t type and API with > > > > security protection implemented, people should be using it > > > > instead. > > > > > > > > Currently it still reports many occurences since we are > > > > nowhere near the end of our kernel-wide conversion execrise, > > > > but hopefully after couple of cycles more, the amount of > > > > output would be much more limited. > > > > > > > > Each script result must be analysed manually before any > > > > conversion, since refcount_t might not suit for certain > > > > purposes (for example if an object is not always destroyed > > > > upon refcounter reaching zero, if increments from zero are > > > > allowed in the code etc.) > > > > > > > > As we go further and get less results in output, we will > > > > improve the pattern to detect conversion cases more precisely. > > > > > > The regexps are the best you can do? > > > > They are simple and so far they were sufficient for the purpose since > > they found pretty much all the cases we are aware about. I was thinking > > on working to improve the pattern later on after we merge the bulk of > > conversions and I have some cycles free on that front. > > > > What would you suggest to do instead of regexps? > > Is there anything about the definitions of these functions that indicates > why they are important? I am not sure I understand the question fully. Do you mean the functions used in the rules, such as atomic_dec_and_test() etc.? If yes, then for example the combination of atomic_dec_and_test(&(a)->x) on a pointer, then followed later by some kind of *free*(a) function (kfree, kmem_cache_free() etc.) on that pointer is a quite common indicator that we are dealing with a reference counter since they would normally free resources when counter reaches zero. Again, it is not a 100% indicator since I have seen weird schemes that for example free a resource upon reaching -1, or free it in one case and don't free on another, but such cases are more rare. Does this answer your questions? Best Regards, Elena. > > julia > > > > > Best Regards, > > Elena. > > > > > > > > julia > > > > > > > > > > > Elena Reshetova (1): > > > > Coccinelle: add atomic_as_refcounter script > > > > > > > > scripts/coccinelle/api/atomic_as_refcounter.cocci | 102 > > > ++++++++++++++++++++++ > > > > 1 file changed, 102 insertions(+) > > > > create mode 100644 scripts/coccinelle/api/atomic_as_refcounter.cocci > > > > > > > > -- > > > > 2.7.4 > > > > > > > > > >