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: Wed, 21 Aug 2013 12:30:32 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Benjamin LaHaise <bcrl@...ck.org> Cc: Dave Kleikamp <dave.kleikamp@...cle.com>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, "Maxim V. Patlasov" <mpatlasov@...allels.com>, Zach Brown <zab@...bo.net>, linux-aio@...ck.org Subject: Re: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio_vec On Wed, 21 Aug 2013 09:02:31 -0400 Benjamin LaHaise <bcrl@...ck.org> wrote: > One of the major problems your changeset continues to carry is that your > new read_iter/write_iter operations permit blocking (implicitely), which > really isn't what we want for aio. If you're going to introduce a new api, > it should be made non-blocking, and enforce that non-blocking requirement It's been so incredibly long and I've forgotten everything AIO :( In this context, "non-blocking" means no synchronous IO, yes? Even for indirect blocks, etc. What about accidental D-state blockage in page reclaim, or against random sleeping locks? Also, why does this requirement exist? "99% async" is not good enough? How come? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists