From patchwork Wed Sep 5 05:30:20 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shmulik Ladkani X-Patchwork-Id: 181722 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id A1DBD2C007D for ; Wed, 5 Sep 2012 15:31:53 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1T98CF-0006LG-4U; Wed, 05 Sep 2012 05:30:39 +0000 Received: from mail-we0-f177.google.com ([74.125.82.177]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1T98CC-0006Kt-95 for linux-mtd@lists.infradead.org; Wed, 05 Sep 2012 05:30:36 +0000 Received: by weyr3 with SMTP id r3so96808wey.36 for ; Tue, 04 Sep 2012 22:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=ZzXQFbVsL4Ngqja/iGZzxeLPORvaJ6sQKLRMD7CG+lI=; b=sG/pSNmZgpeBQCnsSDu+sSlOHTy4U+k5bo0m87FG+fSJ05MC821YF7WZCZ6H98UPUn HeRJI8agNtoxUEOzQeFEirk2t/VkTtBHXQ0kgkK1QD0AKSqXWQTuL6kU6UeIw2LD3pwr KX85JlwCBH8HsnJTmFtHsV9sF2FMXMUtdHtZyDd3gvDL4RIoQRnveIGDa8Wa8J6vd2uH FoYcNbZ441CIEsltcx3cJJ5ffSpE+q6SLm7EeEgSxpBN6JpWVzEqU68wj3yoVlq/Y/kr XIUwFegkqM8Y555qf1lHuINIPaGibTm/bZVY1FVwkzQemb7OFmy4Si0cfy/b54QqfE67 PZSg== Received: by 10.180.24.4 with SMTP id q4mr35318775wif.19.1346823034686; Tue, 04 Sep 2012 22:30:34 -0700 (PDT) Received: from halley (93-172-133-35.bb.netvision.net.il. [93.172.133.35]) by mx.google.com with ESMTPS id fb20sm1522028wid.1.2012.09.04.22.30.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 22:30:34 -0700 (PDT) Date: Wed, 5 Sep 2012 08:30:20 +0300 From: Shmulik Ladkani To: Huang Shijie Subject: Re: [PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict Message-ID: <20120905083020.0bf6b0bd@halley> In-Reply-To: <5046B504.6000608@freescale.com> References: <1346001700-26895-1-git-send-email-shijie8@gmail.com> <1346656701.3061.8.camel@sauron.fi.intel.com> <1346686544.3061.75.camel@sauron.fi.intel.com> <20120904144826.7b9b7518@halley> <5046B504.6000608@freescale.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.177 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (shmulik.ladkani[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Huang Shijie , linux-mtd@lists.infradead.org, dedekind1@gmail.com X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Wed, 5 Sep 2012 10:12:20 +0800 Huang Shijie wrote: > yes, it's really simple and flexible. > But I think it's not wise to export the 0-size partition to user. > The user may confused at this. > > And the mtd-utils, such as mtd-info/mtd-debug, do they can work with a > 0-size partition? I think the 0 sized partition case is really seldom, don't worth the trouble, the user will probably observe something went wrong in his cmdline parts specification. But nevertheless, if we think it's a MUST to forbid the 0 sized partitions, then amend my patch as follows: (sorry, didn't even compile tested this, please review and test, if the approach is acceptible) Also, I'll send a short coding cleanup patch, this loop's indent level is horrible... Regards, Shmulik diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c index 17b0bd4..aed1b8a 100644 --- a/drivers/mtd/cmdlinepart.c +++ b/drivers/mtd/cmdlinepart.c @@ -319,12 +319,22 @@ static int parse_cmdline_partitions(struct mtd_info *master, if (part->parts[i].size == SIZE_REMAINING) part->parts[i].size = master->size - offset; + if (part->parts[i].size == 0) { + printk(KERN_WARNING ERRP + "%s: skipping zero sized partition\n", + part->mtd_id); + part->num_parts--; + memmove(&part->parts[i], + &part->parts[i + 1], + sizeof(*part->parts) * (part->num_parts - i)); + continue; + } + if (offset + part->parts[i].size > master->size) { printk(KERN_WARNING ERRP "%s: partitioning exceeds flash size, truncating\n", part->mtd_id); part->parts[i].size = master->size - offset; - part->num_parts = i; } offset += part->parts[i].size; }