linux-kernel - Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1

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: <CAHk-=wjHZBziH+5tXcTJ1aGZN2tC5S5gKhkNjhiaFFO93vNqcA@mail.gmail.com>
Date: Wed, 27 Mar 2024 09:56:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Greg KH <gregkh@...uxfoundation.org>, Chris Leech <cleech@...hat.com>, 
	Nilesh Javali <njavali@...vell.com>, Christoph Hellwig <hch@....de>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1

On Thu, 21 Mar 2024 at 06:02, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> Char/Misc and other driver subsystem updates for 6.9-rc1
[...]
> Chris Leech (4):
>       uio: introduce UIO_MEM_DMA_COHERENT type
>       cnic,bnx2,bnx2x: use UIO_MEM_DMA_COHERENT
>       uio_pruss: UIO_MEM_DMA_COHERENT conversion
>       uio_dmem_genirq: UIO_MEM_DMA_COHERENT conversion

So this was all broken, and doesn't even build on 32-bit architectures
with 64-bit physical addresses as reported by at least Guenter.
Notably that includes i386 allmodconfig.

I fixed up the build, but I did it the mindless way. I noted in the
commit message that I think the correct fix is likely to make
'uio_mem.mem' be a union of 'physaddr_t' and 'void *' and just always
use the right member. UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL should
probably use the pointer thing too.

I also *suspect* that using 'physaddr_t' is in itself pointless,
because I *think* the physical addresses are always page-aligned
anyway, and it would be better if the uio_mem thing just contained the
pfn instead. Which could just be 'unsigned long pfn'.

So there are proper cleanups that could be done in that area.

That's not what I did, though. I just fixed up the bad casts.

There may be other fixes pending out there, but I didn't want to delay
the 32-bit build fixes any more.

It turns out that the cnic,bnx2,bnx2x conversion avoided the problems,
almost by accident. That driver had used UIO_MEM_LOGICAL before and
had existing casts. That doesn't make it good, but at least it made it
not fail to build.

See commit 498e47cd1d1f ("Fix build errors due to new
UIO_MEM_DMA_COHERENT mess")

                    Linus