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: Thu, 25 Jun 2009 09:44:52 -0700 (PDT) From: Davide Libenzi <davidel@...ilserver.org> To: Gregory Haskins <ghaskins@...ell.com> cc: kvm@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, mst@...hat.com, avi@...hat.com, paulmck@...ux.vnet.ibm.com, Rusty Russell <rusty@...tcorp.com.au> Subject: Re: [KVM PATCH v5 0/4] irqfd fixes and enhancements On Thu, 25 Jun 2009, Gregory Haskins wrote: > So I know we talked yesterday in the review session about whether it was > actually worth all this complexity to deal with the POLLHUP or if we > should just revert to the prior "two syscall" model and be done with > it. Rusty reflected these same sentiments this morning in response to > Davide's patch in a different thread. > > I am a bit torn myself, tbh. I do feel as though I have a good handle > on the issue and that it is indeed now fixed (at least, if this series > is applied and the slow-work issue is fixed, still pending upstream > ACK). I have a lot invested in going the POLLHUP direction having spent > so much time thinking about the problem and working on the patches, so I > a bit of a biased opinion, I know. > > The reason why I am pushing this series out now is at least partly so we > can tie up these loose ends. We have both solutions in front of us and > can make a decision either way. At least the solution is formally > documented in the internet archives forever this way ;) > > I took the review comments to heart that the shutdown code was > substantially larger and more complex than the actual fast-path code. I > went though last night and simplified and clarified it. I think the > latest result is leaner and clearer, so please give it another review > (particularly for races) before dismissing it. > > Ultimately, I think the concept of a release notification for eventfd is > a good thing for all eventfd users, so I don't think this thing should > go away per se even if irqfd decides to not use it. Whatever you guys decide if fine for me. Next time though, I think I'll wait a month or so after taking any action :) - Davide -- 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