lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 28 Jan 2021 06:33:47 +0000 From: "Winkler, Tomas" <tomas.winkler@...el.com> To: Richard Weinberger <richard@....at> CC: Miquel Raynal <miquel.raynal@...tlin.com>, Vignesh Raghavendra <vigneshr@...com>, linux-mtd <linux-mtd@...ts.infradead.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: RE: [PATCH] mtd: use refcount to prevent corruption > > ----- Ursprüngliche Mail ----- > >> > When underlying device is removed mtd core will crash in case user > >> > space is still holding an open handle to a mtd device node. > >> > A proper refcounting is needed so device is release only when a > >> > partition has no active users. The current simple counter is not > >> > sufficient. > >> > >> Can you please explain a little more what devices are involved? > >> Does it implement _get_device() and _put_device()? > > No this is not connected to those handlers of the underlying device > > and those won't help. > > I have a spi device provided by MFD framework so it can go away anytime. > > Can it go away physically or just in software? Software, but since this is mfd it's basically hotplug. The kernel is crashing when I simulate hardware failure. > > Usually the pattern is that you make sure in the device driver that nobody can > orphan the MTD while it is in use. > e.g. drivers/mtd/ubi/gluebi.c does so. In _get_device() it grabs a reference on > the underlying UBI volume to make sure it cannot go away while the MTD (on > top of UBI) is in use. I can try that if it helps, because we are simulating possible lower level crash. In an case I believe that the proper refcouting is much more robust solution, than the current one. I'd appreciate if someone can review the actual implementation. Thanks Tomas
Powered by blists - more mailing lists