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: <e9ce5d1e-1465-4a0d-97f4-0495e02c8189@gmail.com>
Date: Fri, 16 May 2025 10:47:50 +0300
From: Abdiel Janulgue <abdiel.janulgue@...il.com>
To: Marek Szyprowski <m.szyprowski@...sung.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 15:12, Marek Szyprowski wrote:
> 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().

Thanks for the clarification! I think this double mapping issue can be 
solved by the suggestion presented by Alexander Courbot.

/Abdiel
> 
> 
> Best regards