linux-kernel - Re: [PATCH v9 02/12] mtd: add driver for intel graphics non-volatile memory 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCXabQt_nhiTa1pF@black.fi.intel.com>
Date: Thu, 15 May 2025 15:13:33 +0300
From: Raag Jadav <raag.jadav@...el.com>
To: "Usyskin, Alexander" <alexander.usyskin@...el.com>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>,
	Richard Weinberger <richard@....at>,
	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@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"intel-xe@...ts.freedesktop.org" <intel-xe@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tomas Winkler <tomasw@...il.com>
Subject: Re: [PATCH v9 02/12] mtd: add driver for intel graphics non-volatile
 memory device

On Thu, May 15, 2025 at 03:41:08PM +0530, Usyskin, Alexander wrote:
> > On Thu, Apr 24, 2025 at 04:25:26PM +0300, Alexander Usyskin wrote:
> > > Add auxiliary driver for intel discrete graphics
> > > non-volatile memory device.

...

> > > +	for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> > > +		if (!invm->regions[i].name)
> > > +			continue;
> > > +
> > > +		name = kasprintf(GFP_KERNEL, "%s.%s",
> > > +				 dev_name(&aux_dev->dev), invm-
> > >regions[i].name);
> > > +		if (!name)
> > > +			continue;
> > > +		nvm->regions[n].name = name;
> > > +		nvm->regions[n].id = i;
> > > +		n++;
> > > +	}
> > > +	nvm->nregions = n; /* in case where kasprintf fail */
> > 
> > Considering kasprintf failure, should we move forward if n == 0?
> Not sure if adding exit path here adds something positive to driver
> other than complexity.

With an error path already in place it shouldn't be too complex, but upto you.

...

> > > +static void intel_dg_mtd_remove(struct auxiliary_device *aux_dev)
> > > +{
> > > +	struct intel_dg_nvm *nvm = dev_get_drvdata(&aux_dev->dev);
> > > +
> > > +	if (!nvm)
> > > +		return;
> > 
> > Are we expecting this?
> > 
> > > +	dev_set_drvdata(&aux_dev->dev, NULL);
> > 
> > Do we need this?
> Is there guaranty by auxiliary device that after release nothing is called?

Any reports/link to read about such issues? My understanding is that driver
->remove() callbacks are bus lock held and there won't be an active instance
to be called after unbind.

Raag