linux-kernel - Re: [PATCH v1] um: fix incompatible argument type in iounmap()

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: <20250410.215650.1951840861716787929.fujita.tomonori@gmail.com>
Date: Thu, 10 Apr 2025 21:56:50 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: dakr@...nel.org
Cc: geert@...ux-m68k.org, miguel.ojeda.sandonis@...il.com,
 fujita.tomonori@...il.com, richard@....at,
 anton.ivanov@...bridgegreys.com, johannes@...solutions.net,
 linux-um@...ts.infradead.org, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, logang@...tatee.com, sbates@...thlin.com,
 dinguyen@...nel.org, arnd@...db.de
Subject: Re: [PATCH v1] um: fix incompatible argument type in iounmap()

On Wed, 9 Apr 2025 19:30:19 +0200
Danilo Krummrich <dakr@...nel.org> wrote:

>> On Wed, 9 Apr 2025 at 16:48, Miguel Ojeda
>> <miguel.ojeda.sandonis@...il.com> wrote:
>> > On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
>> > <fujita.tomonori@...il.com> wrote:
>> > >
>> > > Align iounmap() signature with other architectures.
>> >
>> > Most indeed have `volatile`, but nios2 and m68k don't -- Cc'ing them
>> > just in case.
>> 
>> Indeed. Apparently the volatile keyword has not always been there...
>> Why does iounmap() need the volatile keyword?
>> Why does pci_iounmap() not have the volatile keyword?
> 
> I think none of the functions within rust/helpers/io.c need volatile, since they
> just defer to the corresponding C function / macro.

Yeah, all volatile in the file should be safe to remove. I'll go with
that approach for the next version.

I think it would be nice to have the same function signature across
all architectures, but that's a separate topic.

Thanks,