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: <77afb898-fe6e-480d-9b7a-05cc31d8545b@gmail.com>
Date: Wed, 14 May 2025 10:00:58 +0300
From: Abdiel Janulgue <abdiel.janulgue@...il.com>
To: 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>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 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 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?

Regards,
Abdiel