From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEB80C77B73 for ; Sun, 23 Apr 2023 08:02:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230166AbjDWIC1 convert rfc822-to-8bit (ORCPT ); Sun, 23 Apr 2023 04:02:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230123AbjDWICZ (ORCPT ); Sun, 23 Apr 2023 04:02:25 -0400 Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 563E5CC for ; Sun, 23 Apr 2023 01:02:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id CEB0463CC166; Sun, 23 Apr 2023 10:02:20 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SGYmLo3VK3p2; Sun, 23 Apr 2023 10:02:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 5CBEA63CC174; Sun, 23 Apr 2023 10:02:20 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zUKjAkq3QXJ7; Sun, 23 Apr 2023 10:02:20 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 42A9563CC166; Sun, 23 Apr 2023 10:02:20 +0200 (CEST) Date: Sun, 23 Apr 2023 10:02:20 +0200 (CEST) From: Richard Weinberger To: chengzhihao1 Cc: Yu Hao , Miquel Raynal , Vignesh Raghavendra , linux-mtd , linux-kernel Message-ID: <1366603418.245114.1682236940160.JavaMail.zimbra@nod.at> In-Reply-To: References: <687864524.118195.1681799447034.JavaMail.zimbra@nod.at> <977347543.226888.1682011999468.JavaMail.zimbra@nod.at> <412779912.228444.1682023015809.JavaMail.zimbra@nod.at> Subject: Re: BUG: divide error in ubi_attach_mtd_dev MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF97 (Linux)/8.8.12_GA_3809) Thread-Topic: divide error in ubi_attach_mtd_dev Thread-Index: P5jqm95hRKoxVO9TZkSQrtm6hLkHZQ== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Ursprüngliche Mail ----- > Von: "chengzhihao1" >>> root@syzkaller:~# cat /proc/mtd >>> dev: size erasesize name >>> mtd0: 00020000 00001000 “mtdram test device” >> >> Hmm, mtdram should be fine, erasesize is not zero. >> > > I guess the zero-erasesize mtd device is dynamically generated in > runtime, after looking through the code, I find erasesize is > initiallized in specific flash driver and it won't be updated later(eg. > ioctl\sysctl). And some mtd devices may have zero erasesize, eg. > drivers/mtd/devices/mchp23k256.c[1]. Unfortunately, I don't know how to > load/simulate this mtd, maybe it requires a real device? If we load this > mtd device as ubi, it will trigger the problem? Indeed. I guess qemu can emulate such chips. So better fix UBI to reject attaching of mtd's with erasesize being 0. (Please note, we cannot test for MTD_NO_ERASE, this one means there is no erase method). Thanks, //richard