Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Mon, 14 Feb 2022 12:18:12 +0100
From:   =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= <kernel@kempniu.pl>
To:     Richard Weinberger <richard@nod.at>
Cc:     Miquel Raynal <miquel.raynal@bootlin.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Boris Brezillon <boris.brezillon@collabora.com>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 4/4] mtdchar: add MEMREAD ioctl
Message-ID: <Ygo6dNsVn1Y6c3PJ@larwa.hq.kempniu.pl>
References: <20220125104822.8420-1-kernel@kempniu.pl>
 <20220125104822.8420-5-kernel@kempniu.pl>
 <1173246756.12597.1643879936765.JavaMail.zimbra@nod.at>
 <20220203104654.6cb43ea3@xps13>
 <340602071.12640.1643883222200.JavaMail.zimbra@nod.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <340602071.12640.1643883222200.JavaMail.zimbra@nod.at>
Precedence: bulk

> >> If mtd->erasesize is large (which is not uncommon these days) you might
> >> request more from kmalloc() than it can serve.
> >> Maybe kvmalloc() makes more sense?
> > 
> > Mmmh, I would really like these buffers dma-able.
> > 
> > I just discovered mtd_kmalloc_up_to(). Would this work?
> 
> mtd_kmalloc_up_to() makes sense to be more friendly to the system.
> It tries to get memory without forcing write-back and such.
> But if we're out of continuous memory it won't help much. 
> 
> Regarding dma-able, as soon you use something like UBI/UBIFS ontop of it
> the mtd driver has to be able to deal in any way with vmalloc()'ed memory.

Note that the MEMWRITE ioctl is affected by the same issue.  Judging
from the discussion above, I assume a separate patch is in order to turn
kmalloc() calls in mtdchar_write_ioctl() into kvmalloc() calls?

> Another option would be not working on full erase blocks.

Right, the approach proposed in this patch series and also previously in
commit f6562bca84d22525f792305e3106571f8714d057 ("mtdchar: prevent
unbounded allocation in MEMWRITE ioctl") is a trade-off.  I followed a
suggestion I heard earlier:

https://lists.infradead.org/pipermail/linux-mtd/2021-September/088485.html

-- 
Best regards,
Michał Kępień