linux-kernel - Re: [PATCH] eeprom: at25: convert to spi-mem API

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: <ad87d404-3d93-4c7e-908a-d9f47daca4b0@csgroup.eu>
Date: Sat, 8 Nov 2025 17:24:06 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>,
 "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc: "hui.wang@...onical.com" <hui.wang@...onical.com>,
 "mwalle@...nel.org" <mwalle@...nel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "florent.trinh-thai@...soprasteria.com"
 <florent.trinh-thai@...soprasteria.com>, "arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] eeprom: at25: convert to spi-mem API



Le 08/11/2025 à 12:41, Sverdlin, Alexander a écrit :
> Hi Christophe,
> 
> On Sat, 2025-11-08 at 12:14 +0100, Christophe Leroy wrote:
>>> Now I'm trying to understand why the problem surfaced with commit
>>> 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API")
>>>
>>
>> The reason why it was not a problem before was that the transfer was
>> done into of->prealloc_buf (fs/kernfs/file.c) which is a kmalloc() with
>> size (PAGE_SIZE + 1).
>>
>> Following the rework of at25 it now goes into the bounce buffer which is
>> allocated with the exact size of the transfer.
>>
>> Why do we need an intermediate bounce buffer now, why can't
>> of->prealloc_buf be used directly as before ?
> 
> userspace access is only one part of the story, the other is NVMEM
> kernel-internal API, like nvmem_cell_read*() and I suppose there is
> no requirement for a destination buffer to be DMA-able.
> 

As far as I can see nvmem_cell_read*() allocates a kmalloc() bounce 
buffer already:

	buf = kzalloc(max_t(size_t, entry->raw_len, entry->bytes), GFP_KERNEL);
	if (!buf)
		return ERR_PTR(-ENOMEM);

	rc = __nvmem_cell_read(nvmem, cell->entry, buf, len, cell->id, 
cell->index);
	if (rc) {
		kfree(buf);
		return ERR_PTR(rc);
	}

	return buf;

Christophe