Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp649998img; Mon, 18 Mar 2019 11:04:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqz82YSB48kbZaDVNYR/IbMaEkQrCXfhXLWV4zgUZs4cTnPF5Noo4Qp5Bz1mo98/DPo9CxpF X-Received: by 2002:a17:902:b402:: with SMTP id x2mr20940134plr.53.1552932275903; Mon, 18 Mar 2019 11:04:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552932275; cv=none; d=google.com; s=arc-20160816; b=V77r01xlOCmmVzMjSo+tm7XQtdn8hAFmvrc8mO0VSZ8icsJz5RrX61MsSP96wgN7pw qdIoxQveNnKZxj7r4EpXj26X1/XFOQuNJDIcsW0MxmF+kLx9GYFN1vCQcCm01G6ygAX6 W++4n3XqxptKaMvvCca3wZSF2D8Cg99lMFglKavwdBYO0zlLet0vc885khMY2IikBLg6 UbM8Me6/Pvd0DYWA4xE7FS5k9ZWdC9hz+Dxse8OtPfkDoj3PXqu9Rnm861d/OvlJkz+k eLcASEDveh+QIlAYe1GKMxhaqKCe09yWiZ8Zf1ezWAIrGKp9Xm4SVC6BnIEATHdGiUPI NyGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=YFAfFgC1pRARxeTN6i+N1vLcyB/pcw+KxHt21hWZ8xQ=; b=q1IVEqMX4Zx6D1eciZeBoKPqcwgGUjFqReVevqC3SVXZp8VGPEySMm9/lJdIF31D8c oTfBr7WwhHVxrw+lahgaMat5kdduPLe5kyqLhHHZ/pvsH0zlUbn+EvfvxKo8ujyiRNs5 UwfqrSKyckpSvhYJVZ7nFTeCHdcxV8xh+Z1E1YAhGGV/RlFdcGzKPUfjXH5F+ajCLSjH UlM9lG3Zx+r+6EWG2B2hg2ftEeBM6OdKBTEVzxnkMUr0xVES9oAQp1AXbWKmGgW2EgSj vNsLeYrQ0s6+Xarx80frepA+f5LgzqDO2w3ep5puzW4VZ1ra6kZdMJm0HZ8rEKXLu59v zMIA== 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 e65si10047430pfa.80.2019.03.18.11.04.19; Mon, 18 Mar 2019 11:04:35 -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 S1727268AbfCRSCn (ORCPT + 99 others); Mon, 18 Mar 2019 14:02:43 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:9362 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727113AbfCRSCk (ORCPT ); Mon, 18 Mar 2019 14:02:40 -0400 X-UUID: fb778ddcda1c47c6892f8acbfe23e1f8-20190319 X-UUID: fb778ddcda1c47c6892f8acbfe23e1f8-20190319 Received: from mtkmrs01.mediatek.inc [(172.21.131.159)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1653476042; Tue, 19 Mar 2019 02:02:33 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Mar 2019 02:02:31 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 19 Mar 2019 02:02:31 +0800 Message-ID: <1552932151.24944.12.camel@mtkswgap22> Subject: Re: [PATCH] Bluetooth: mediatek: fix uninitialized symbol errors in btmtksdio_rx_packet From: Sean Wang To: Marcel Holtmann CC: Johan Hedberg , , , Date: Tue, 19 Mar 2019 02:02:31 +0800 In-Reply-To: <93CB6259-6FB8-4D3D-9FF3-8EB59499A6A1@holtmann.org> References: <8fb8e6840a39127112597963d665fbe6c21d8b91.1552509647.git.sean.wang@mediatek.com> <93CB6259-6FB8-4D3D-9FF3-8EB59499A6A1@holtmann.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-TM-SNTS-SMTP: 4B749FC33B091D298E4652708FFE71F44A75E42ED23B674999364EEAF587ABDF2000:8 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2019-03-18 at 17:55 +0100, Marcel Holtmann wrote: > Hi Sean, > > > Fixed all the below warnings. They would probably cause the following > > error handling path would use the uninitialized value and then produce > > unexpected behavior. > > > > drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used > > uninitialized in this function [-Wmaybe-uninitialized] > > print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > old_data, old_len, true); > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here > > unsigned int old_len; > > ^~~~~~~ > > drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used > > uninitialized in this function [-Wmaybe-uninitialized] > > print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > old_data, old_len, true); > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here > > unsigned char *old_data; > > ^~~~~~~~ > > > > Fixes: d74eef2834b5 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") > > Reported-by: Dan Carpenter > > Reported-by: Marcel Holtmann > > Signed-off-by: Sean Wang > > --- > > drivers/bluetooth/btmtksdio.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c > > index b4b8320f279e..23cf63888bac 100644 > > --- a/drivers/bluetooth/btmtksdio.c > > +++ b/drivers/bluetooth/btmtksdio.c > > @@ -372,8 +372,8 @@ static int btmtksdio_rx_packet(struct btmtksdio_dev *bdev, u16 rx_size) > > const struct h4_recv_pkt *pkts = mtk_recv_pkts; > > int pkts_count = ARRAY_SIZE(mtk_recv_pkts); > > struct mtkbtsdio_hdr *sdio_hdr; > > - unsigned char *old_data; > > - unsigned int old_len; > > + unsigned char *old_data = NULL; > > + unsigned int old_len = 0; > > int err, i, pad_size; > > struct sk_buff *skb; > > u16 dlen; > > or instead just remove this whole old_len + old_data stuff anyway since it is rather pointless. Or at least introduce a proper error path for sdio_readsb since you know when it fails, there is no point in writing the SKB. > > Regards > I will remove the old_len and old_data in the next version for the issue because the error path for sdio_readsb seems wrong. My initial purpose is that I would like to add a error path for these packets which are successful at sdio_readsb but fail at packet format parsing. I will update the error path for packet format error in a separate patch. > Marcel >