netdev - Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer

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]

Date: Wed, 9 Aug 2023 10:21:26 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Mark Brown <broonie@...nel.org>, 
	netdev@...r.kernel.org
Subject: Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer

On Wed, 9 Aug 2023 at 10:01, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Right now the kernel buffer init is a *bit* more involved than the
> above ubuf case:
>
>         struct iov_iter iter;
>         struct kvec kvec = { kptr, len};
>
>         iov_iter_kvec(&iter, ITER_SRC/DEST, &kvec, 1, len);
>
> and that's maybe a *bit* annoying, but we could maybe simplify this
> with some helper macros even without ITER_KBUF.

Looking at the diff that Christoph quoted, you possibly also want

        strncpy_from_iov()

and honestly, that's a bit of an odd operation for the traditional
iov_iter use, but it certainly shouldn't be _hard_ to implement.

I'd probably initially implement it as a special case that only deals
with the "one single buffer" case (whether user space or kernel
space), since that would presumably be what you'd ever have, but
extending it to the generic case later if people actually need it
would not be problematic - those "iterate_and_advance()" macros in
lib/iovec.c are all about that horror.

               Linus