Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1356338ybn; Wed, 2 Oct 2019 14:59:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqwyy2LWk5VowY6fvEXpb4NsgPp5xzVW9Aime7NKbMtzbyzXXHwIkTzmb1W6854YQJPwmZRP X-Received: by 2002:a50:9f42:: with SMTP id b60mr6400728edf.192.1570053553835; Wed, 02 Oct 2019 14:59:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570053553; cv=none; d=google.com; s=arc-20160816; b=zp4uVT71OUw4VR0im+ekfq6ztwyHGcODxCgZmXZ7h+qlVtifW6uZjVmi9VEr19VaSb l0bBPdgR1m+jK5zzm7mLjvixn6B/OB6DxuP/sNUk85a6q8YxRCQ6ebe0EAxqUt+c9fKJ TBXQo1m/ggxot1VKarrBmY8oI0wjnj16MJewfC6Pny/xessxPRFEr8V50N/TA9Rlm//o mMKB0VC2Mfe+95lmV1EGOXDhTp8vDmcy+MqDnijfvr/MxZFgBbdWf4az8ZRbSbXeO0ao JkZJlJas2fzcnEzawU/2Jxhcv1DWAX4oesfPfkWBoi0VLhgD6CBFWuMQkC4RaSFdVvyt meaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=1a9klFlHHN1v64I4Gtmc6w36DakNfCzhE6y2phcBEL4=; b=SpUlLgssVCReHTPGTHgqZxkzWzwnYD2KieGgRUI6PZZ1n+iF/qNIHFiODjnb98q523 5VnvHNGXdcpBAkf2IwKSAR8zlcnc6AOoyEVZJF/s7PI3IJrzIq18P41YSeGfUQqEHXpa U0vErSoH1lWpXyxuS4Jmfi+P7vU8OQSvGWySBgjBu9McEkO9k7fwSpqjc35wqAJoqMnJ wIRkTPnzu5aFfppA3OcjvrRxjztxvMhGSO1ca3+/M4JGD0DV4Lzvr2EaGjb/qIOrZo+I CsEEPtpCoa+l4Hm/3+KWs2N5rolvAOOnVaRasLXa3n3MTVI2ngBAyJCuQ6WluuEvcmj1 1fbw== 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 64si271079eda.384.2019.10.02.14.58.48; Wed, 02 Oct 2019 14:59:13 -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; 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 S1729490AbfJBVWQ (ORCPT + 99 others); Wed, 2 Oct 2019 17:22:16 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:37100 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728713AbfJBVWQ (ORCPT ); Wed, 2 Oct 2019 17:22:16 -0400 Received: from localhost (unknown [IPv6:2601:601:9f00:1e2::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 7DF32154F41D6; Wed, 2 Oct 2019 14:22:15 -0700 (PDT) Date: Wed, 02 Oct 2019 14:22:14 -0700 (PDT) Message-Id: <20191002.142214.252882219207569928.davem@davemloft.net> To: yzhai003@ucr.edu Cc: csong@cs.ucr.edu, zhiyunq@cs.ucr.edu, yisen.zhuang@huawei.com, salil.mehta@huawei.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: hisilicon: Fix usage of uninitialized variable in function mdio_sc_cfg_reg_write() From: David Miller In-Reply-To: <20191001202439.15766-1-yzhai003@ucr.edu> References: <20191001202439.15766-1-yzhai003@ucr.edu> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 02 Oct 2019 14:22:15 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Yizhuo Date: Tue, 1 Oct 2019 13:24:39 -0700 > In function mdio_sc_cfg_reg_write(), variable "reg_value" could be > uninitialized if regmap_read() fails. However, "reg_value" is used > to decide the control flow later in the if statement, which is > potentially unsafe. > > Signed-off-by: Yizhuo Applied, but really this is such a pervasive problem. So much code doesn't check the return value from either regmap_read or regmap_write. _EVEN_ in the code you are editing, the patch context shows an unchecked regmap_write() call. > @@ -148,11 +148,15 @@ static int mdio_sc_cfg_reg_write(struct hns_mdio_device *mdio_dev, > { > u32 time_cnt; > u32 reg_value; > + int ret; > > regmap_write(mdio_dev->subctrl_vbase, cfg_reg, set_val); ^^^^^^^^^^^^ Grepping for regmap_{read,write}() shows how big an issue this is. I don't know what to do, maybe we can work over time to add checks to all calls and then force warnings on unchecked return values so that the problem is not introduced in the future.