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
| ||
|
Message-ID: <87350psmzo.wl-tiwai@suse.de> Date: Fri, 11 Aug 2023 15:54:35 +0200 From: Takashi Iwai <tiwai@...e.de> To: Linus Torvalds <torvalds@...ux-foundation.org> 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, 09 Aug 2023 20:08:30 +0200, Takashi Iwai wrote: > > On Wed, 09 Aug 2023 19:01:50 +0200, > Linus Torvalds wrote: > > > > On Wed, 9 Aug 2023 at 09:05, Takashi Iwai <tiwai@...e.de> wrote: > > > > > > OTOH, it simplifies the code well for us; as of now, we have two > > > callbacks for copying PCM memory from/to the device, distinct for > > > kernel and user pointers. It's basically either copy_from_user() or > > > memcpy() of the given size depending on the caller. The sockptr_t or > > > its variant would allow us to unify those to a single callback. > > > > I didn't see the follow-up patches that use this, but... > > > > > (And yeah, iov_iter is there, but it's definitely overkill for the > > > purpose.) > > > > You can actually use a "simplified form" of iov_iter, and it's not all that bad. > > > > If the actual copying operation is just a memcpy, you're all set: just > > do copy_to/from_iter(), and it's a really nice interface, and you > > don't have to carry "ptr+size" things around. > > > > And we now have a simple way to generate simple iov_iter's, so > > *creating* the iter is trivial too: > > > > struct iov_iter iter; > > int ret = import_ubuf(ITER_SRC/DEST, uptr, len, &iter); > > > > if (unlikely(ret < 0)) > > return ret; > > > > and you're all done. You can now pass '&iter' around, and it has a > > nice user pointer and a range in it, and copying that thing is easy. > > > > Perhaps somewhat strangely (*) we don't have the same for a simple > > kernel buffer, but adding that wouldn't be hard. You either end up > > using a 'kvec', or we could even add something like ITER_KBUF if it > > really matters. > > > > 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. > > > > So yes, iov_iter does have some abstraction overhead, but it really > > isn't that bad. And it *does* allow you to do a lot of things, and can > > actually simplify the users quite a bit, exactly because it allows you > > to just pass that single iter pointer around, and you automatically > > have not just the user/kernel distinction, you have the buffer size, > > and you have a lot of helper functions to use it. > > > > I really think that if you want a user-or-kernel buffer interface, you > > should use these things. > > > > Please? At least look into it. > > All sounds convincing, I'll take a look tomorrow. Thanks! FYI, I rewrote and tested patches, and it looks promising. The only missing piece in the upstream side was the export of import_ubuf(). Takashi
Powered by blists - more mailing lists