linux-kernel - Re: [RFC PATCH 0/2] scatterlist rust bindings

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: <8eedf638-9fa5-470e-976e-9b18971f7b46@samsung.com>
Date: Wed, 14 May 2025 14:12:19 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Abdiel Janulgue <abdiel.janulgue@...il.com>, Daniel Almeida
	<daniel.almeida@...labora.com>
Cc: dakr@...nel.org, lyude@...hat.com, Miguel Ojeda <ojeda@...nel.org>, Alex
	Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
	<gary@...yguo.net>, Björn Roy Baron
	<bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, Andreas
	Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Trevor
	Gross <tmgross@...ch.edu>, Valentin Obst <kernel@...entinobst.de>, open list
	<linux-kernel@...r.kernel.org>, Robin Murphy <robin.murphy@....com>,
	airlied@...hat.com, rust-for-linux@...r.kernel.org, "open list:DMA MAPPING
 HELPERS" <iommu@...ts.linux.dev>, Petr Tesarik <petr@...arici.cz>, Andrew
	Morton <akpm@...ux-foundation.org>, Herbert Xu
	<herbert@...dor.apana.org.au>, Sui Jingfeng <sui.jingfeng@...ux.dev>, Randy
	Dunlap <rdunlap@...radead.org>, Michael Kelley <mhklinux@...look.com>
Subject: Re: [RFC PATCH 0/2] scatterlist rust bindings

On 14.05.2025 09:00, Abdiel Janulgue wrote:
>
> On 12/05/2025 14:19, Daniel Almeida wrote:
>> Hi Abdiel,
>>
>>> On 12 May 2025, at 06:53, Abdiel Janulgue 
>>> <abdiel.janulgue@...il.com> wrote:
>>>
>>> Hi,
>>>
>>> Here are the scatterlist bindings that has been brewing for a while 
>>> in my
>>> local tree while working with Nova code. The bindings are used 
>>> mostly to
>>> build the radix3 table from the GSP firmware which is loaded via dma.
>>> This interface can be used on top of existing kernel scatterlist 
>>> objects
>>> or to allocate a new one from scratch.
>>>
>>> Some questions still need to be resolved, which mostly come from
>>> the DeviceSGTable::dma_map() function. Primarily, what if you call
>>> bindings::dma_map_sgtable() on an already mapped sg_table? From my
>>
>> Perhaps we should introduce a type for buffers which are known to be 
>> mapped. Then
>> we can simply not offer the option to map for that type.
>>
>>> experiments it doesn't seem to do anything and no indication is 
>>> returned if
>>> the call succeeded or not. Should we save the "mapping info" to a list
>>> everytime we call DeviceSGTable::dma_map more than once?
>>
>> What mapping info are you referring to?
>>
> Basically the dma_data_direction enum and possibly `Device`, if we 
> decouple SGTable from the device. So this approach would mean that 
> every-time SGTable::dma_map() is called, unique mapping object(s) 
> would be created, and which would get unmapped later on the destructor:
>
> struct SgtDmaMap {
>     dev: ARef<Device>,
>     dir: DmaDataDirection,
> }
>
> impl SgtDmaMap {
>     /// Creates a new mapping object
>     fn new(dev: &Device, dir: DmaDataDirection) -> Self {
>         Self { dev: dev.into(), dir, }
>     }
> }
> ...
> ...
>
> impl SGTable {
>     pub fn dma_map(dev: &Device, dir: DmaDataDirection) -> 
> Result<SgtDmaMap>
>
> But I'm not sure if there is any point to that as the C 
> `dma_map_sgtable()` doesn't seem to care anyway (I could be wrong with 
> this) if the sg_table gets mapped more than once?


Standard DMA-mapping C api doesn't have the notion of the object, 
although in case of sgtable structure, one might add some flags might 
there. Originally the sgtable based helpers were just trivial wrappers 
for dma_sync_sg_*() and dma_unmap_sg() ensuring proper parameters (and 
avoiding the confusion which nents to pass).

It is generally assumed that caller uses the DMA API properly and there 
are no checks for double dma_map calls. It is only correct to call 
dma_map_sgtable() for the same sgtable structure after earlier call to 
dma_unmap_sgtable().


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland