Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp877668imj; Fri, 15 Feb 2019 08:15:43 -0800 (PST) X-Google-Smtp-Source: AHgI3IaKdd5AOK96BjkKdPuICFsvgT+FEVhflnyNwni9VivwbQSbpLIyINnzymDkcDXvmblRuQYo X-Received: by 2002:a17:902:8d89:: with SMTP id v9mr11048026plo.90.1550247343623; Fri, 15 Feb 2019 08:15:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550247343; cv=none; d=google.com; s=arc-20160816; b=cEyXM2jwKIlg93kTVnmibAQpujKBR0N1BUrJjOwS5Em2douatoIYQJi1Fn43DN2yLt y37P7EYCpjSq80KtiBk05vdcAGsm9ghZOstGaWF8CbjW3lc/L22BAB+3WwO5Q8oglMB+ 4fa/EwwWQwXpyNUnPhy1GWsQYibLO/vCoMfEIxBiacXnJgGa6mHvXTs9IvnpLdK/ERPu OWdJG1Afjuv8shXk9MjqrPF1JGn5jspqJGtyFcB+gbVbzG9OrPMXwXU6/+9+rVjpyA06 zY9pt1d7n7kG0k8A8yrPMu7HR3G9rSeC7wEPN6kXU1J7wUHnNQou/Uh50BCLW2vHG6Z8 pwhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=bt706bL+MGbmdNSXcl2or67NHVkpyzTquWFnOWOsdsg=; b=L0HuxQCtkTTGzYiKGsfd1nSwt7OsSb3sNTvXmio4vdFMIiieMQQn3QoZyZmdIwKkJS H7+GMFLxo0zVwxpzikZzFgxisrRY7XU6Wbgoe1e/8noXUDD/e5kwFT3Gmz8dI++I19yb lqQpgsuJczXv2KWZ8dnNHrohndz7K1dNC76tnJQJSmWQR5Ylx2+pVVNb/V2Gn0786SJ6 ihaf3yOCl25E+VdymujOKfx6nC1CFDPJhnR+H+pdYaGAXSBTLHFafeYgqPO1Ag6wCNg2 oNr2d5Exa+aJIs/tpBBXMEop1epJdET86ojG8ydGJsBHPbjv4Ch8/U/mtLSCOYpfot4S kZFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si5899657pgo.273.2019.02.15.08.15.28; Fri, 15 Feb 2019 08:15:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394804AbfBONCJ (ORCPT + 99 others); Fri, 15 Feb 2019 08:02:09 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:48022 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726864AbfBONCJ (ORCPT ); Fri, 15 Feb 2019 08:02:09 -0500 X-IronPort-AV: E=Sophos;i="5.58,372,1544482800"; d="scan'208";a="296307215" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2019 14:02:06 +0100 Date: Fri, 15 Feb 2019 14:02:05 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Markus Elfring cc: Wen Yang , Gilles Muller , Nicolas Palix , Michal Marek , Yi Wang , Masahiro Yamada , Wen Yang , Cheng Shengyu , cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH v5] Coccinelle: semantic code search for missing put_device() In-Reply-To: <94e4b3e6-87a4-aea2-dfef-44d308f0fb4f@web.de> Message-ID: References: <1550217319-40418-1-git-send-email-wen.yang99@zte.com.cn> <94e4b3e6-87a4-aea2-dfef-44d308f0fb4f@web.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-662799820-1550235726=:3617" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --8323329-662799820-1550235726=:3617 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Fri, 15 Feb 2019, Markus Elfring wrote: > > +@search exists@ > > +local idexpression id; > > +expression x,e,e1; > > +position p1,p2; > > +type T,T1,T2,T3; > > +@@ > > + > > +id = of_find_device_by_node@p1(x) > > +... when != e = id > > +if (id == NULL || ...) { ... return ...; } > > +... when != put_device(&id->dev) > … > > + when != if (id) { ... put_device(&id->dev) ... } > … > > I would interpret this SmPL code in the way that the if statement > for the pointer check is “optional” in this line. > Is it an extra and redundant SmPL specification when the reference > release function could eventually be found just anywhere within > an implementation? The proposed when code is correct. It is not redundant, because it checks for a particular control-flow pattern. julia > > > Will a need evolve to develop a similar source code search approach > for safer resource management with other function combinations? > > Regards, > Markus > --8323329-662799820-1550235726=:3617--