Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp543739imm; Wed, 18 Jul 2018 06:42:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc8HwhaChlKlyVe91VB0hMjEO+qsO/6l4tnx1Cqtq/x0qhBPbxhk1n/atGTDWoN8O0SrmT2 X-Received: by 2002:a63:2a0b:: with SMTP id q11-v6mr5862961pgq.36.1531921365405; Wed, 18 Jul 2018 06:42:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531921365; cv=none; d=google.com; s=arc-20160816; b=JnqVvCCymlGRcO6O7k62zD9/iEJlcLEMNAkbyIQkNO4hZiSddHRwDIqOUvPJ9uH/zc ddbLDoB+EGUZ9rA7Gum8ybHTg4os06caM9uujN0WpBT4oUg1k0oXNuZTHr5VG53funhT GRDJbw6h3IfIiFI+ZCpes9srFfAs/hOgcEZb76Yz6dOFcjsgxbpJLx0NJ1MBat/8d1Sv HAGJJMJ5G8uMwzs6A9f/dwcET7QUhA4P2+Yq5yf6C9RtkrdMGIt3asIuGh6IL6WXgPvX vFHC+2N3OPxy4FeH+B1hZR+kK9bYzxPcKH+/wOxdZ/I2Hpw8sLRuFLUsucN+/9uunh8E TqSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=Gb+pLow3sAMG/+PfNYvDstkm1RNF523qewEMo+QvMyI=; b=mGyRwdGuBHGHM7i3P5MaY9zwPtTIeKm305JU6ESd6EwYISIX8livcaq8cu9E8+XY3n BI8JPAuUEwBxgTGbcUf+x/Ou2B9N8BTa4r13OvO57aznqbS3GuBZHjeFIUsPohkz1AU2 jr1O7BwE/SthpwAMB4cFiWsb1Vd7EzsANbBlqkyl00PyWxGrj/Gxz2Vq8FdooFmymyCE Sa7GObixknXAi4ZbfMXfUglcop0pGtn/Q+AgvatLl4qlMBDv5I/uwNE3qYb6aT271cYH opnV7QJr/51F899rHecJR3tR9erKZ52Ikp3fq2X2QeILtH/IaoEdp7Rql6+yW8V25glw LRiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=OAA4qLua; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s14-v6si3222266pga.21.2018.07.18.06.42.30; Wed, 18 Jul 2018 06:42:45 -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=@linaro.org header.s=google header.b=OAA4qLua; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731758AbeGROTI (ORCPT + 99 others); Wed, 18 Jul 2018 10:19:08 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:42971 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731143AbeGROTI (ORCPT ); Wed, 18 Jul 2018 10:19:08 -0400 Received: by mail-wr1-f67.google.com with SMTP id e7-v6so4736349wrs.9 for ; Wed, 18 Jul 2018 06:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Gb+pLow3sAMG/+PfNYvDstkm1RNF523qewEMo+QvMyI=; b=OAA4qLuauuwzXyT3HuVnACeznC/iKPoCMLBIOlyqxamZEni5eFecUykkXuG7qguR93 bY2hbTq2/veCD1YdIoB4aiSymjlktyDwDHsdff3bvpjpehbGPNKe9+x3ppR7rz7beWsz yWIbEVlv6q84MP7MQBF2CGHufojNhNAuSLzdI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Gb+pLow3sAMG/+PfNYvDstkm1RNF523qewEMo+QvMyI=; b=djY9WGNVSHfeCG5WDm9MNBwekmpYc2yAyXzeTogLGKvzqr0bqV09q7pGpTyaKZ8iiy CYpc+i6bwabCznZTSoEJ40fMGT9DiLO06vUgcIFHDaond1ju3HiwbRrqLdYlb9McCj2D X/LWxFX/jcAIF1IA/+FDv21nL/3jSKQ+FpizZuwf/FMFdSC2q4jRlzMe7tnK8WQWnYLM 7jWsFAxh77OW/Guop9DdlxnZb8Q1BA4thtxxVtgluJQHi/dGfIi+MR1fWF2HKWxCA8ZG AiREMyz9RoocyETPHQNRi98iQXmxiUFqP+O8ADN2cdYmRKruAedFnzqj5cYpwOZ2JGV/ IaPQ== X-Gm-Message-State: AOUpUlES4/FCpiP8Hygof8xh9/KaJz0LobsbBgfNTtmbUtfkw1C4+IT5 deRLT3mMxANGGi5sA/yHKuDCaQ== X-Received: by 2002:adf:afd3:: with SMTP id y19-v6mr4907002wrd.176.1531921267146; Wed, 18 Jul 2018 06:41:07 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id b123-v6sm4482197wma.24.2018.07.18.06.41.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Jul 2018 06:41:06 -0700 (PDT) Date: Wed, 18 Jul 2018 14:41:03 +0100 From: Daniel Thompson To: Lee Jones Cc: Marcel Ziswiler , "linux-kernel@vger.kernel.org" , "jingoohan1@gmail.com" , "linux-pwm@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "b.zolnierkie@samsung.com" , "thierry.reding@gmail.com" , "dri-devel@lists.freedesktop.org" , "patches@linaro.org" Subject: Re: [PATCH] backlight: pwm_bl: Fix uninitialized variable Message-ID: <20180718134103.bgwpgk7l6joxtjoa@holly.lan> References: <20180716210241.9457-1-daniel.thompson@linaro.org> <20180718080913.GB4641@dell> <1531902119.16896.13.camel@toradex.com> <20180718095335.GD4641@dell> <20180718101227.shqf54wpt4kdrsj2@holly.lan> <1531918626.16896.22.camel@toradex.com> <20180718130853.GE4641@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180718130853.GE4641@dell> User-Agent: NeoMutt/20180622 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 18, 2018 at 02:08:53PM +0100, Lee Jones wrote: > > > > > No, then we are back to the initial issue of num_steps > > > > > potentially not > > > > > being initialised. We really want both of_property_read_u32() to > > > > > succeed AND num_steps to actually be set. > > > > > > > > I also think num_steps should be pre-initialised. > > > > Yes, I guess it definitely does not hurt. > > > > > > Then it will only be set if of_property_read_u32() succeeds. > > > > Yes, but we still need to check for both, the function not failing and > > num_steps to actually be non zero. > > Why? You don't do anything differently if it fails. Only if you initialize num_steps... We should either initialize to zero and not worry about the return code[1] or we check the return code and not worry about initialization[2]. I don't think both are worthwhile. Whilst initialization can fix this specific instance we generally avoid overusing it since it messes up static analysis and, in this instance, distance from declaration to use is >25 lines, hence current patchset. Daniel. [1] https://lkml.org/lkml/2018/7/16/399 [2] https://lkml.org/lkml/2018/7/16/1042 Or... We check the return code and leave number num_steps is uninitialized and stack allocated so it only has a valid value if of_property_read_u32() succeeds. We can (and I originally did) fix the bug by initializing num_steps to 0 but its quite some distance between declaration and use so I accepted Marcel's counter proposal to check the return code instead. Daniel.