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
| ||
|
Date: Fri, 20 May 2022 10:41:12 -0600 From: Jens Axboe <axboe@...nel.dk> To: "Jason A. Donenfeld" <Jason@...c4.com> Cc: Al Viro <viro@...iv.linux.org.uk>, Theodore Ts'o <tytso@....edu>, Christoph Hellwig <hch@....de>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v4 0/3] random: convert to using iters, for Al Viro On 5/20/22 10:39 AM, Jason A. Donenfeld wrote: > Hi Jens, > > On Fri, May 20, 2022 at 10:24:36AM -0600, Jens Axboe wrote: >> On 5/20/22 10:15 AM, Al Viro wrote: >>> IIRC, Linus' position at the time had been along the lines of >>> "splice is not so good ABI anyway, so let's do it and fix up >>> the places that do get real-world complaints once such appear". >>> So /dev/urandom is one such place... >> >> That's what Christoph said too. Honestly that's a very odd way to >> attempt to justify breakage like this, even if it is tempting to >> facilitate the set_fs() removal. But then be honest about it and say >> it like it is, rather than some hand wavy explanation that frankly >> doesn't make any sense. >> >> The referenced change doesn't change the splice ABI at all, hence the >> justification seems very random to me. It kept what we already have, >> except we randomly break some use cases. > > It looks like Al is right in the sense that Linus must certainly be > aware of the breakage. He fixed tty in 9bb48c82aced ("tty: implement > write_iter"). I don't think anyone is disputing that, but I also know that Linus wants these fixed up as they are discovered. And I agree with him on that, even if I disagree on the process to get there as it introduced frivolous breakage... > Anyway, it seems like the iter functions are the way forward, so this v4 > is queued up now (with a few minor cosmetic changes) and pushed to: > https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/log/ > I'll send an early 5.19 pull for everything either tonight or Sunday. > And then next week I'll start on backports. (Though, 5.12 is a weird > kernel version; I assume this is some Meta kernel that has its own > backport team?) Thanks! > Meanwhile, hopefully Al can pick up the splice.c sendfile(2) chardev > patch for 5.19, so at least there'll be some silver lining to the > performance hit. Let's hope so. -- Jens Axboe
Powered by blists - more mailing lists