From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE2051369A8 for ; Mon, 17 Jun 2024 16:52:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.201.40.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718643166; cv=none; b=mXxSKTpHUwyrWaXQuIdlLbs0Yasu32F32IKicezy2B9YgnOpOneBJ5MppOeZji4yda9TgeVy5V++56OeGvY13rJdUaPehbJ6S3jiJoG0fMc8FBm0XKKgGie9i0qIJyliPhG1/IZWJy/XDZgNn2cOisFrlDnXseGH/ZTipNIvQ0s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718643166; c=relaxed/simple; bh=CcAJqzNSlaf+l+Rz+hZwCU+gUQtZqN2sKhsZylP4k2c=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=WiBXhiE54jO65OtUUHPtojU5X0yp+jCjHohqAURBdfTpmlrUkTbOzVdp1e/17MeHYS5/Ucjplj9JXw2UCfRnamh/a2aTtuNM0e/DAYR/uTedIGF9Ehez+JTgANijg9Elpc4Xbrav5wpo/7mr1BXTT1aVL61tJP2tm7EyolslzI8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=195.201.40.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 619E26195FC1; Mon, 17 Jun 2024 18:52:41 +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 rVZusyb9lOqr; Mon, 17 Jun 2024 18:52:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 0EE376195FC6; Mon, 17 Jun 2024 18:52:41 +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 Srg5VmlXEUGF; Mon, 17 Jun 2024 18:52:40 +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 DF1846195FC1; Mon, 17 Jun 2024 18:52:40 +0200 (CEST) Date: Mon, 17 Jun 2024 18:52:40 +0200 (CEST) From: Richard Weinberger To: Gagan Sidhu Cc: ZhaoLong Wang , chengzhihao1 , dpervushin , linux-kernel , linux-mtd , Miquel Raynal , Vignesh Raghavendra , yangerkun , yi zhang Message-ID: <1802911356.251780.1718643160760.JavaMail.zimbra@nod.at> In-Reply-To: <65E62DA3-EF16-44BD-8E51-E751BD2C496F@mac.com> References: <561660214.251562.1718638970757.JavaMail.zimbra@nod.at> <14779870-BA54-4ABF-8ABF-FF1D23D172A7@mac.com> <1641029267.251608.1718640023954.JavaMail.zimbra@nod.at> <65E62DA3-EF16-44BD-8E51-E751BD2C496F@mac.com> Subject: Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by ftl notifier Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF97 (Linux)/8.8.12_GA_3809) Thread-Topic: gluebi: Fix NULL pointer dereference caused by ftl notifier Thread-Index: CeaQ9NY8GO3IkkuxNvz0If8vASUkgg== ----- Urspr=C3=BCngliche Mail ----- > Von: "Gagan Sidhu" > i don=E2=80=99t think my articulation is correct if you interpreted it as= that. >=20 > as i understand it, gluebi simply makes it handy when you have a filesyst= em > packed within a ubi file, and it will take that file and mount itas a blo= ck > device. There is no such thing as an UBI file. UBI hosts volumes. You can install into these volumes whatever you want. Also a file system such as UBIFS, but this seems not to be the case here. > so i would say it=E2=80=99s not MTD->UBI->GLUEBI->MTD->MTDBLOCK >=20 > it=E2=80=99d say it=E2=80=99s more MTD->GLUEBI->MTDBLOCK No. GLUBI emulates a MTD on top of an UBI volume. So every read/write operation of the filesystem will first to through: 1. block layer 2. MTDBLOCK (and mtd) 3. GLUBI 4. UBI 5. MTD (this time the real one) Is this really a setup OpenWRT is using? I'm not saying it's impossible, but far from ideal. We have UBIBlock for reasons. Anyway, since the kernel has to be user space friendly and users seems to use such "odd" stackings I consider reverting this patch. ZhaoLong Wang, what do you think? Thanks, //richard