Received: by 10.213.65.68 with SMTP id h4csp2551378imn; Mon, 9 Apr 2018 05:29:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+LWLK0chIFRrMHAIs2Ur33HwuNJxhBH2BsxJf5KXtNDmFpZABugHOZ3YPmD1TQLrxunrLh X-Received: by 2002:a17:902:264:: with SMTP id 91-v6mr38647269plc.178.1523276958542; Mon, 09 Apr 2018 05:29:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523276958; cv=none; d=google.com; s=arc-20160816; b=Kgcf0TrA/iw+PN77L/FS2YKO+pJhWWQ2QI6zeM9TmxNuEvAvIOd+cNwbhWZrNgHQnW /ueX2TheiQeVOd5si8S257XltLxCP4iEiiHfG01j8w02LFv/1HEVLRjZTBKht17XxFMm lxC242ChNOGnFFPj3q0LdAOxL9ZfskYtHDF/V+QwwH6KaT0DNnEh6vhJ4T5FMrRVSbAa 2SC0D/ZFgQmEZ6F6rjJPkf4NEsVMQnaAgEXT29xRn2OmNlhTCTNbg8VWFhBP6vmFlKyk 6iWp9D+8asnyHf3AmOMiR6Ktt3lSE3N9UUN8He5aJc5Q4LIC9gLkgnWImJto0IIg7WHn Aokw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=OHoaLFSYPMbEc6hdvH7eudmjRUZMbktAl2NdAWGiXl0=; b=NbrYOQwv0/MeUVBc74VMZqNZGi/UDeK4QjImEEk2CXOvQt25VMvaoVVgAkOF9nOa2T B+deDizl0ALtIVuoCTL+7vukDCikr9mg/Ae+Uo7qyIt0B9B+XAp6hnUhfVQ+mVga3Wkd 33n5QLkt0Df/v4oeEWjsqJVVherOmHzWz94OxAGsAjP+048yuT8+d2vvIEWrVrcWQOL4 33/8GTe5vmV/7tPOMByhK0jyB9LJaTHKh2Cn2/+oAlitFIfQvkr4bFlvAPvoYE2pENgN VEGBIfX9dicxU9C7X/Op6uEPL5Y0oeWILpeOfwiC3X+9i6UFkYmRzo/52CALuotyUd+8 N9wg== 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 n22si160803pgc.121.2018.04.09.05.28.41; Mon, 09 Apr 2018 05:29:18 -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 S1752107AbeDIMZe (ORCPT + 99 others); Mon, 9 Apr 2018 08:25:34 -0400 Received: from baptiste.telenet-ops.be ([195.130.132.51]:34924 "EHLO baptiste.telenet-ops.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751919AbeDIMZ3 (ORCPT ); Mon, 9 Apr 2018 08:25:29 -0400 Received: from ayla.of.borg ([84.194.111.163]) by baptiste.telenet-ops.be with bizsmtp id YCRN1x00W3XaVaC01CRNp4; Mon, 09 Apr 2018 14:25:28 +0200 Received: from ramsan.of.borg ([192.168.97.29] helo=ramsan) by ayla.of.borg with esmtp (Exim 4.86_2) (envelope-from ) id 1f5VrO-0007eS-If; Mon, 09 Apr 2018 14:25:22 +0200 Received: from geert by ramsan with local (Exim 4.86_2) (envelope-from ) id 1f5VrO-0001J6-Gr; Mon, 09 Apr 2018 14:25:22 +0200 From: Geert Uytterhoeven To: David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger Cc: linux-mtd@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, Geert Uytterhoeven Subject: [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully Date: Mon, 9 Apr 2018 14:25:21 +0200 Message-Id: <1523276721-4982-1-git-send-email-geert+renesas@glider.be> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently add_mtd_device() failures are plainly ignored, which may lead to kernel crashes later. E.g. after flipping SW17 on r8a7791/koelsch, to switch from the large to the small QSPI FLASH, without updating the partition description in DT, the following happens: m25p80 spi0.0: found s25sl032p, expected s25fl512s 3 fixed-partitions partitions found on MTD device spi0.0 Creating 3 MTD partitions on "spi0.0": 0x000000000000-0x000000080000 : "loader" 0x000000080000-0x000000600000 : "user" mtd: partition "user" extends beyond the end of device "spi0.0" -- size truncated to 0x380000 The second partition is truncated correctly. 0x000000600000-0x000004000000 : "flash" mtd: partition "flash" is out of reach -- disabled The third partition is disabled by allocate_partition(), which means fields like erasesize are not filled in. Hence add_mtd_device() fails and screams, rightfully: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at drivers/mtd/mtdcore.c:508 add_mtd_device+0x2a0/0x2e0 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-koelsch-08649-g58e35e77b00c075d #4029 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x7c/0x9c) [] (dump_stack) from [] (__warn+0xd4/0x104) [] (__warn) from [] (warn_slowpath_null+0x38/0x44) [] (warn_slowpath_null) from [] (add_mtd_device+0x2a0/0x2e0) [] (add_mtd_device) from [] (add_mtd_partitions+0xd0/0x16c) [] (add_mtd_partitions) from [] (mtd_device_parse_register+0xc4/0x1b4) [] (mtd_device_parse_register) from [] (m25p_probe+0x148/0x188) [] (m25p_probe) from [] (spi_drv_probe+0x84/0xa0) [...] ---[ end trace d43ce221bca7ab5c ]--- However, that failure is ignored by add_mtd_partitions(), leading to a crash later: ------------[ cut here ]------------ kernel BUG at fs/sysfs/file.c:330! Internal error: Oops - BUG: 0 [#1] SMP ARM Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.16.0-koelsch-08649-g58e35e77b00c075d #4029 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) PC is at sysfs_create_file_ns+0x24/0x40 LR is at 0x1 pc : [] lr : [<00000001>] psr: 60000013 sp : eb447c00 ip : 00000000 fp : c0e20174 r10: 00000003 r9 : c0e20150 r8 : eb7e3818 r7 : ea8b20f8 r6 : c0e2017c r5 : 00000000 r4 : 00000000 r3 : 00000200 r2 : 00000000 r1 : c0e2019c r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5387d Table: 40003000 DAC: 55555555 Process swapper/0 (pid: 1, stack limit = 0x7eba272f) Stack: (0xeb447c00 to 0xeb448000) [...] [] (sysfs_create_file_ns) from [] (sysfs_create_files+0x34/0x70) [] (sysfs_create_files) from [] (mtd_add_partition_attrs+0x10/0x34) [] (mtd_add_partition_attrs) from [] (add_mtd_partitions+0xd8/0x16c) [] (add_mtd_partitions) from [] (mtd_device_parse_register+0xc4/0x1b4) [] (mtd_device_parse_register) from [] (m25p_probe+0x148/0x188) [] (m25p_probe) from [] (spi_drv_probe+0x84/0xa0) Fix this by ignoring and freeing partitions that failed to add in add_mtd_partitions(). The same issue is present in mtd_add_partition(), so fix that as well. Signed-off-by: Geert Uytterhoeven --- I don't know if it is worthwhile factoring out the common handling. Should allocate_partition() fail instead? There's a comment saying "let's register it anyway to preserve ordering". --- drivers/mtd/mtdpart.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c index 023516a632766c42..d41adc1397dcf95e 100644 --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -637,7 +637,14 @@ int mtd_add_partition(struct mtd_info *parent, const char *name, list_add(&new->list, &mtd_partitions); mutex_unlock(&mtd_partitions_mutex); - add_mtd_device(&new->mtd); + ret = add_mtd_device(&new->mtd); + if (ret) { + mutex_lock(&mtd_partitions_mutex); + list_del(&new->list); + mutex_unlock(&mtd_partitions_mutex); + free_partition(new); + return ret; + } mtd_add_partition_attrs(new); @@ -731,7 +738,7 @@ int add_mtd_partitions(struct mtd_info *master, { struct mtd_part *slave; uint64_t cur_offset = 0; - int i; + int i, ret; printk(KERN_NOTICE "Creating %d MTD partitions on \"%s\":\n", nbparts, master->name); @@ -746,7 +753,15 @@ int add_mtd_partitions(struct mtd_info *master, list_add(&slave->list, &mtd_partitions); mutex_unlock(&mtd_partitions_mutex); - add_mtd_device(&slave->mtd); + ret = add_mtd_device(&slave->mtd); + if (ret) { + mutex_lock(&mtd_partitions_mutex); + list_del(&slave->list); + mutex_unlock(&mtd_partitions_mutex); + free_partition(slave); + continue; + } + mtd_add_partition_attrs(slave); if (parts[i].types) mtd_parse_part(slave, parts[i].types); -- 2.7.4