linux-kernel - RE: [PATCH v6 01/11] mtd: core: always create master device

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CY5PR11MB6366A8123B5FDA2BA2A2849EED74A@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Thu, 12 Jun 2025 12:37:36 +0000
From: "Usyskin, Alexander" <alexander.usyskin@...el.com>
To: Richard Weinberger <richard@....at>
CC: Miquel Raynal <miquel.raynal@...tlin.com>, Guenter Roeck
	<linux@...ck-us.net>, Vignesh Raghavendra <vigneshr@...com>, "De Marchi,
 Lucas" <lucas.demarchi@...el.com>, Thomas Hellström
	<thomas.hellstrom@...ux.intel.com>, "Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
	<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
	<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Jani Nikula
	<jani.nikula@...ux.intel.com>, Joonas Lahtinen
	<joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin <tursulin@...ulin.net>,
	"Poosa, Karthik" <karthik.poosa@...el.com>, "Abliyev, Reuven"
	<reuven.abliyev@...el.com>, "Weil, Oren jer" <oren.jer.weil@...el.com>,
	linux-mtd <linux-mtd@...ts.infradead.org>, DRI mailing list
	<dri-devel@...ts.freedesktop.org>, intel-gfx
	<intel-gfx@...ts.freedesktop.org>, linux-kernel
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v6 01/11] mtd: core: always create master device

> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
> 
> ----- Ursprüngliche Mail -----
> > Von: "Alexander Usyskin" <alexander.usyskin@...el.com>
> > In general, it is fine for me - we have parent mtd initialized and participating
> > in power management.
> >
> > I can't see how to bend idr_alloc to allocate from the end and corner case
> > of full idr range is also will be problematic.
> 
> I expected it to work because we can track the highest mtd ID and pass limits
> to idr_alloc(), no?
> 
> Thanks,
> //richard

This will produce different ids if there are two mtd chips.
E.g.:
Before patches:
0 - first chip partition 1 - second chip partition
After patches:
0 - first chip partition 1 - first chip master
2 - second chip partition 3 - second chip master

Or we should manually give region for master's ids at the end
of idr range near UINT_MAX.
And that requires careful manual handling of overflows.

Personally, I think it is bad idea to rely on partition number,
but it is the status-quo now.

- - 
Thanks,
Sasha