Received: by 10.192.165.148 with SMTP id m20csp4281435imm; Tue, 8 May 2018 06:07:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZovuVRtwtJLZFZ/fE9rLaFqEMjdPhkD7RL+pmOy3axsPjoMBKOdo1v8oLNwRkuw8VoGHMei X-Received: by 2002:a17:902:9886:: with SMTP id s6-v6mr41038114plp.380.1525784831469; Tue, 08 May 2018 06:07:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525784831; cv=none; d=google.com; s=arc-20160816; b=s8JxTAne+AhPHTc+9v+cAq7h/LsLluOGoY76c0eF1cg2YybFBxKiC3Ig4T9cRYyMqX bJgTjfrSoDsKshH4KpVsZDegc4PobCdURfbFDmIWqFt+zW99eUwOsAAz+wyCN/Rz4fct 4L+ikvynCSnxYCac9vMvKQ+GzpDun1qWlVmj1ztcfeU/lPVBgdhsbJRry3/joBk/yj9B r92OMhu1Gn7yYJPiRljhwOIczenoeCtU2XvkbsIswjG3IjU4Eu5tYRd9huN12qXB8b2S 6YNs1j2SSro+t9p+fn2PiAUzCs/dLkFCrmkmGBKa2gMKpxR8j8MGfY/Ig1PrWS3WBNJI myaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=yf5akQKoUYDr6vK2T+Oo2kKTkEY4tHSFuXj/QmNbM4M=; b=PuV+83leJRhop974ABhqzvqaaWl1XejUTiPcl9mtU3TGK0fxL5RYzjCoFKN72k14WZ GqiwVX4kU+QTHiXhm/ZhBJeGnKIkf6/c4tB6j/nbZOEZYj1mjDFQqcV2n4gbcz26ni3I nw1yqemchJ3DXavqRSDrzsmr4ACf1msit9JeVnbLezgTangddcbXj9GAtsZFiji446+z mszpEpzlwC1G3sIKNdOt6XQmeBW+tMwm9D2U43I/K0Xjtm/hMtK9t6dy8JsXAxyHHmTl vyC8b7MlWT8iW/LVa8T6M2xtHHEYB5DMpHXnK7esyLXhIJ9oL6Y56AH3yp8LVK52Wa7O Nglg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@umn.edu header.s=20160920 header.b=GQ2Qf7yA; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umn.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b10-v6si24573083pla.260.2018.05.08.06.06.57; Tue, 08 May 2018 06:07:11 -0700 (PDT) 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; dkim=pass header.i=@umn.edu header.s=20160920 header.b=GQ2Qf7yA; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umn.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754504AbeEHNFi (ORCPT + 99 others); Tue, 8 May 2018 09:05:38 -0400 Received: from mta-p2.oit.umn.edu ([134.84.196.202]:45262 "EHLO mta-p2.oit.umn.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751723AbeEHNFg (ORCPT ); Tue, 8 May 2018 09:05:36 -0400 Received: from localhost (localhost [127.0.0.1]) by mta-p2.oit.umn.edu (Postfix) with ESMTP id D8E4E17D; Tue, 8 May 2018 13:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=umn.edu; h= content-type:content-type:subject:subject:message-id:date:date :from:from:references:in-reply-to:received:mime-version:received :received:received; s=20160920; t=1525784735; x=1527599136; bh=2 8P+1jaDSO0y5P3EbyEFYr1+mVANA2hJeYc4lvRWzU8=; b=GQ2Qf7yA+lw9iCgXV co7b6ZnxO030bIABDQruiHmJzu55kt4ioaMJ0hKayiR1YW5GuD4fnJW2nZyskggd ecOA32pcbcbfJrL+DdBri6J++UciXU7pnzkCHTnIjQaCfV/udpeBQVaxQkU5cj8p oo9IeqNZ+gUSKe6zJ8P+La9ONj5GPn0txRm9w4Q1JNMQqVz8X2LzGFvbugJVvCpt tSgrRUqiswzvlLhsO80+Ead4C3tHy8nJCJViko+PoL0a+xN3FurDwujsaZDcmBrx xGO9yqh001reADyrBZyLix5CqPsSPW9oKp69a+wlIoMugydBHpz1FVWyq4FRlwQy S2YJg== X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p2.oit.umn.edu ([127.0.0.1]) by localhost (mta-p2.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLxFhWTEH24i; Tue, 8 May 2018 08:05:35 -0500 (CDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: wang6495) by mta-p2.oit.umn.edu (Postfix) with ESMTPSA id 9BA7915F; Tue, 8 May 2018 08:05:35 -0500 (CDT) Received: by mail-io0-f176.google.com with SMTP id c9-v6so31894972iob.12; Tue, 08 May 2018 06:05:35 -0700 (PDT) X-Gm-Message-State: ALQs6tBskJ6V/UMcmGfFU1MyPQTWGwDv64LKsKOyExKYMbobdEn6OMPk NsQYhli+c661JD+82myTH5VwiEcB+rw6FPtMzv8= X-Received: by 2002:a6b:200e:: with SMTP id g14-v6mr47699091iog.161.1525784735372; Tue, 08 May 2018 06:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:44c:0:0:0:0:0 with HTTP; Tue, 8 May 2018 06:04:54 -0700 (PDT) In-Reply-To: <20180508121635.mdw4jikv66iyprie@mwanda> References: <1525300731-27324-1-git-send-email-wang6495@umn.edu> <20180508121635.mdw4jikv66iyprie@mwanda> From: Wenwen Wang Date: Tue, 8 May 2018 08:04:54 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] media: staging: atomisp: fix a potential missing-check bug To: Dan Carpenter Cc: "open list:STAGING SUBSYSTEM" , Andy Shevchenko , Greg Kroah-Hartman , Kangjie Lu , "open list:STAGING - ATOMISP DRIVER" , open list , Hans Verkuil , Sakari Ailus , Mauro Carvalho Chehab , Alan Cox , Wenwen Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 8, 2018 at 7:16 AM, Dan Carpenter wrote: > On Wed, May 02, 2018 at 05:38:49PM -0500, Wenwen Wang wrote: >> At the end of atomisp_subdev_set_selection(), the function >> atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect. Since >> this function may return a NULL pointer, it is firstly invoked to check >> the returned pointer. If the returned pointer is not NULL, then the >> function is invoked again to obtain the pointer and the memory content >> at the location of the returned pointer is copied to the memory location of >> r. In most cases, the pointers returned by the two invocations are same. >> However, given that the pointer returned by the function >> atomisp_subdev_get_rect() is not a constant, it is possible that the two >> invocations return two different pointers. For example, another thread may >> race to modify the related pointers during the two invocations. > > You're assuming a very serious race condition exists. > > >> In that >> case, even if the first returned pointer is not null, the second returned >> pointer might be null, which will cause issues such as null pointer >> dereference. > > And then complaining that if a really serious bug exists then this very > minor bug would exist too... If there were really a race condition like > that then we'd want to fix it instead. In other words, this is not a > real life bug fix. > > But it would be fine as a readability or static checker fix so that's > fine. Thanks for your response. From the performance perspective, this bug should also be fixed, as the second invocation is redundant if it is expected to return a same pointer as the first one. Wenwen