Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp973116ybm; Wed, 22 May 2019 15:00:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqwcLfwOjC4ODEDZUqLai7eXN2Yoc3kaIX/PyukAGt1PukT/vG52jkgvvPhkg/XvZcQN6MmN X-Received: by 2002:a62:4859:: with SMTP id v86mr69535354pfa.237.1558562437525; Wed, 22 May 2019 15:00:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558562437; cv=none; d=google.com; s=arc-20160816; b=cO8pKyTj5b+LI5av/wA5IZ2SnKgidS4zSAdXxnDWPnAEx73U8FfInldtCE5rHmc60R 4G9luV3DnfKia3XZcxgUq3mcZSjaoKxqJYTRDhj+/jyulEdV/9WPyvVUc12f10Gwrlbm ZEqNYrz2/sbgVxmqmbWMz6Nv/dnPeEn1AA0SUo0lG2QD5ch4ASoZLwCN1X8RI0LmEhTf RNnh2S3/SZBd/cpG7OakETSxy+Fb5pQeks88TQ+c2RlZJIaeKmk1aPdaaNa+BSWk5hhb cRGxnaGGRcwi2jeXLYd3d76hcjhZJACw1nO9alCRJIuH/bl86pu/AgfLXzJkaQvdgw8b DABw== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=elRFYld9M+83Oaa+skOhyU1eTFkEtyZrCA0pWj3dr14=; b=X5Li7S0jhymbwk9No5nENjatP1XRVbsf4Oht/EvCwpjukdmjM95Afnmgv0XLr5rhcI Wp4kpcQGIIXFkICtYj/upAl6FFwMgWK33o/LiyHihQ/4Qz1uHYyL3P1eBXSFOIPptCmk w29qkDXx60QKpHoQfE+AsrMfgun53+0YmRKvzcO7AFyK9Gfm6KjssgcM/iB0HXxfjnF0 2xLCqFF6hhp2akHmt5GmvV5TecIFrXvQllYPKHnJe+23x0JYor6iHbJJRG00p4M3FgNL YAnQ28oZph/xbw2t1lwtWy6CQh0/6ZNbiOZvrVx99xIpVRHxnaJHQoopnGvX0kyTG3cT Z/2A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f34si1423999ple.322.2019.05.22.15.00.22; Wed, 22 May 2019 15:00:37 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730354AbfEVV5o (ORCPT + 99 others); Wed, 22 May 2019 17:57:44 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:58304 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729996AbfEVV5n (ORCPT ); Wed, 22 May 2019 17:57:43 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:b93f:9fae:b276:a89a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 611FD26397A; Wed, 22 May 2019 22:57:41 +0100 (BST) Date: Wed, 22 May 2019 23:57:38 +0200 From: Boris Brezillon To: Kees Cook Cc: "Gustavo A. R. Silva" , Vignesh Raghavendra , Richard Weinberger , linux-kernel@vger.kernel.org, Marek Vasut , Kyungmin Park , linux-mtd@lists.infradead.org, Miquel Raynal , Brian Norris , David Woodhouse Subject: Re: [PATCH] mtd: onenand_base: Avoid fall-through warnings Message-ID: <20190522235738.68059906@collabora.com> In-Reply-To: <201905221403.642AF6092@keescook> References: <20190522180446.GA30082@embeddedor> <201905221403.642AF6092@keescook> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 22 May 2019 14:30:11 -0700 Kees Cook wrote: > Sorry for being late to speaking up on this. I missed something in the > code the first time I read the thread, that now stood out to me. Notes > below... > > On Wed, May 22, 2019 at 01:04:46PM -0500, Gustavo A. R. Silva wrote: > > diff --git a/drivers/mtd/nand/onenand/onenand_base.c b/drivers/mtd/nand/onenand/onenand_base.c > > index f41d76248550..6cf4df9f8c01 100644 > > --- a/drivers/mtd/nand/onenand/onenand_base.c > > +++ b/drivers/mtd/nand/onenand/onenand_base.c > > @@ -3280,12 +3280,14 @@ static void onenand_check_features(struct mtd_info *mtd) > > Reverse-order review, second hunk first: > > > case ONENAND_DEVICE_DENSITY_2Gb: > > /* 2Gb DDP does not have 2 plane */ > > if (!ONENAND_IS_DDP(this)) > > this->options |= ONENAND_HAS_2PLANE; > > this->options |= ONENAND_HAS_UNLOCK_ALL; > > + /* Fall through - ? */ > > > > case ONENAND_DEVICE_DENSITY_1Gb: > > /* A-Die has all block unlock */ > > So, I think the ONENAND_DEVICE_DENSITY_2Gb should be a "break". Though, > actually, it doesn't matter: > > case ONENAND_DEVICE_DENSITY_2Gb: > /* 2Gb DDP does not have 2 plane */ > if (!ONENAND_IS_DDP(this)) > this->options |= ONENAND_HAS_2PLANE; > this->options |= ONENAND_HAS_UNLOCK_ALL; > > case ONENAND_DEVICE_DENSITY_1Gb: > /* A-Die has all block unlock */ > if (process) > this->options |= ONENAND_HAS_UNLOCK_ALL; > break; > > Falling through from ONENAND_DEVICE_DENSITY_2Gb to > ONENAND_DEVICE_DENSITY_1Gb will actually have no side-effects: > ONENAND_HAS_UNLOCK_ALL was unconditionally set in ..._2Gb, so there is > no reason to fall through to ..._1Gb. (But falling through is harmless.) > > Now the first hunk: > > > if ((this->version_id & 0xf) == 0xe) > > this->options |= ONENAND_HAS_NOP_1; > > } > > + /* Fall through - ? */ > > > > case ONENAND_DEVICE_DENSITY_4Gb: > if (ONENAND_IS_DDP(this)) > this->options |= ONENAND_HAS_2PLANE; > else if (numbufs == 1) { > this->options |= ONENAND_HAS_4KB_PAGE; > this->options |= ONENAND_HAS_CACHE_PROGRAM; > /* > * There are two different 4KiB pagesize chips > * and no way to detect it by H/W config values. > * > * To detect the correct NOP for each chips, > * It should check the version ID as workaround. > * > * Now it has as following > * KFM4G16Q4M has NOP 4 with version ID 0x0131 > * KFM4G16Q5M has NOP 1 with versoin ID 0x013e > */ > if ((this->version_id & 0xf) == 0xe) > this->options |= ONENAND_HAS_NOP_1; > } > > Falling through from ONENAND_DEVICE_DENSITY_4Gb to > ONENAND_DEVICE_DENSITY_2Gb looks like it would mean that > ONENAND_HAS_2PLANE would be unconditionally set for ...4Gb, which seems > very strange to expect: > > if (ONENAND_IS_DDP(this)) > this->options |= ONENAND_HAS_2PLANE; > ... > if (!ONENAND_IS_DDP(this)) > this->options |= ONENAND_HAS_2PLANE; Oops, didn't notice the ! on the second test. > > However! This happens later: > > if (ONENAND_IS_4KB_PAGE(this)) > this->options &= ~ONENAND_HAS_2PLANE; > > i.e. falling through to ...2Gb (which sets ONENAND_HAS_2PLANE) has no > effect because when ONENAND_HAS_2PLANE isn't set (numbufs == 1), it gets > _cleared_ by the above code due to ONENAND_HAS_4KB_PAGE getting set: Are you sure !DDP implies num_bufs == 1? > > #define ONENAND_IS_4KB_PAGE(this) \ > (this->options & ONENAND_HAS_4KB_PAGE) > > > Unfortunately, though, it's less clear about ONENAND_HAS_UNLOCK_ALL, > which is getting set unconditionally for ...4Gb currently (due to the > fallthrough to ...2Gb). However, this happens later: > > if (FLEXONENAND(this)) { > this->options &= ~ONENAND_HAS_CONT_LOCK; > this->options |= ONENAND_HAS_UNLOCK_ALL; > } > ... > #define FLEXONENAND(this) \ > (this->device_id & DEVICE_IS_FLEXONENAND) > > So it's possible this fall through has no effect (are all 4Gb density > devices also FLEXONENAND devices?) > All this look suspicious, and even if the fall through logic has no side effects in practice (which I'm still not sure is the case), I think it'd be better to explicitly set the flags that have to be set in each case statement and add breaks.