From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44ED0C433DF for ; Wed, 24 Jun 2020 11:30:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 25F1D20724 for ; Wed, 24 Jun 2020 11:30:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388972AbgFXLaT (ORCPT ); Wed, 24 Jun 2020 07:30:19 -0400 Received: from mail.loongson.cn ([114.242.206.163]:56230 "EHLO loongson.cn" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388470AbgFXLaT (ORCPT ); Wed, 24 Jun 2020 07:30:19 -0400 Received: from [10.130.0.52] (unknown [113.200.148.30]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9DxL986OfNeWT5JAA--.789S3; Wed, 24 Jun 2020 19:30:03 +0800 (CST) Subject: Re: [1/7] irqchip: Fix potential resource leaks To: Markus Elfring , devicetree@vger.kernel.org, linux-mips@vger.kernel.org References: <65e734f7-c43c-f96b-3650-980e15edba60@web.de> <9ca22645-8bf3-008f-fe55-d432f962cac3@web.de> <423f83e0-c533-c346-ab8b-f2c6ccc828a2@loongson.cn> <37ff7ca4-dc7c-6a43-94a3-9628efe69b25@web.de> Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Huacai Chen , Jason Cooper , Jiaxun Yang , Marc Zyngier , Rob Herring , Thomas Gleixner , Xuefeng Li From: Tiezhu Yang Message-ID: <8556e402-52ae-849f-2f6e-e56406057dce@loongson.cn> Date: Wed, 24 Jun 2020 19:30:02 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <37ff7ca4-dc7c-6a43-94a3-9628efe69b25@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf9DxL986OfNeWT5JAA--.789S3 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYy7AC8VAFwI0_Gr0_Xr1l1xkIjI8I6I8E 6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28Cjx kF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8I cVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aV CY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAq x4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Cr0_Gr1UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxG xcIEc7CjxVA2Y2ka0xkIwI1lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrw CFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE 14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2 IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxK x2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Gr1j6F4UJwCI42IY6I8E87Iv6xkF7I 0E14v26rxl6s0DYxBIdaVFxhVjvjDU0xZFpf9x0JUu5l8UUUUU= X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On 06/24/2020 06:06 PM, Markus Elfring wrote: >>> Were any known software analysis tools involved for the detection of >>> questionable source code places? >> kmemleak can detect memory leak, >> but I do not know how to detect other kind of leaks. > How do you think about to extend source code analysis tools accordingly? I have no good idea, maybe some simple match check tools can do this. > > >> I think consciously release resource in the error path can avoid leaks. > Is it often too easy to overlook relevant function calls? Yes, I think code review can avoid this issue in some certain degree. > > Regards, > Markus