Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2438833pxa; Mon, 24 Aug 2020 14:21:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4nBwOpjG7jEGVkyzHV71Zh4rhLXnRPlYZ6XXGASEU0ajiqn6sUByeObfWhg4pYIK/A4mo X-Received: by 2002:a17:906:5902:: with SMTP id h2mr7779046ejq.423.1598304115551; Mon, 24 Aug 2020 14:21:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598304115; cv=none; d=google.com; s=arc-20160816; b=px145Y3K691RRg4TlPyDC3jBzrkmADS7q+ZV8o8jlH6sAqsM7PcadtknnBWgTfo0Uy AzPnQ4avaEaO+c0m9q0rkVWMioFycbwT5inxullNbFCQjVhpm52cSOWAOw7uitZnqJGr JZTTAJ+dCdvgCZMgnMajV/YlKk0w8yRw41E+usf96AOdLdAj0rI+9QNoXXDyfpIdNJaM tpOuSFVsl7ganKYm1aF3s5tbmpY/Wahn/qfstoxBUHAIS6+nQpfmIaQ5yY77q/5QbpW2 94hzTC7DYXajB0bBnNUl2isAzJURwdKMed+mtO+C8P63wcknYdUm9pMPc3NCTqn7hu3W WLvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=38Y2Inb/IbZnfvYrhBDhlLyAHS2+wjW04o1UW2EqWrI=; b=WQpaAj0XUzLdvsWzrDk5mKuaMw3Hjj1YHYOPPvf10CySP2SXq7ZXjBPgZOsO80BVl1 yOFlxfNSerWX/c5ZpDQPUiNgPkpXyr9W3gYMzd/WAOgkD6ZRidTz0LU8dNzUtqALXuaw ZoGux4vXGMWGF14yOHuy3Xbq0NpVfN6yBoWnQIlbxWI7icMjleIV9vZkOf7BondyuTny DuAI5G88b3xmwsAR6JZbx61Bgc3+1kUas9pdV0ArouyavjVUitS+CeNyu8vOrkjNgFZj T0H2/+/D9DusfahINcXb/fOJJ6a3MS9s677+I0pdtu/6iXhfOCyNhxBq/BS9AL1qRlps PEGw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bh4si8059133ejb.193.2020.08.24.14.21.32; Mon, 24 Aug 2020 14:21:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727981AbgHXVSl (ORCPT + 99 others); Mon, 24 Aug 2020 17:18:41 -0400 Received: from shells.gnugeneration.com ([66.240.222.126]:46752 "EHLO shells.gnugeneration.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726090AbgHXVSk (ORCPT ); Mon, 24 Aug 2020 17:18:40 -0400 Received: by shells.gnugeneration.com (Postfix, from userid 1000) id D265F1A4018B; Mon, 24 Aug 2020 14:18:39 -0700 (PDT) Date: Mon, 24 Aug 2020 14:18:39 -0700 From: Vito Caputo To: trix@redhat.com Cc: stern@rowland.harvard.edu, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] usb: storage: initialize variable Message-ID: <20200824211839.6c7m7yhgd7ffq3g3@shells.gnugeneration.com> References: <20200824211027.11543-1-trix@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200824211027.11543-1-trix@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 24, 2020 at 02:10:27PM -0700, trix@redhat.com wrote: > From: Tom Rix > > clang static analysis reports this representative problem > > transport.c:495:15: warning: Assigned value is garbage or > undefined > length_left -= partial; > ^ ~~~~~~~ > partial is set only when usb_stor_bulk_transfer_sglist() > is successful. > > So set partial on entry to 0. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Signed-off-by: Tom Rix > --- > drivers/usb/storage/transport.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c > index 238a8088e17f..044429717dcc 100644 > --- a/drivers/usb/storage/transport.c > +++ b/drivers/usb/storage/transport.c > @@ -414,6 +414,9 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe, > { > int result; > > + if (act_len) > + *act_len = 0; > + > /* don't submit s-g requests during abort processing */ > if (test_bit(US_FLIDX_ABORTING, &us->dflags)) > return USB_STOR_XFER_ERROR; At a glance this seems odd to me. If the caller insists on ignoring the return value, shouldn't it just initialize partial to zero? In my experience it's generally frowned upon for functions to store results in error paths. Regards, Vito Caputo