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 Oct 2006 11:55:22 -0700 From: Mark Fasheh <mark.fasheh@...cle.com> To: Nick Piggin <nickpiggin@...oo.com.au> Cc: Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org, akpm@...l.org, linux-fsdevel@...r.kernel.org Subject: Re: + fs-prepare_write-fixes.patch added to -mm tree On Fri, Oct 20, 2006 at 09:27:02AM +1000, Nick Piggin wrote: > >Cool, I appreciate that. > > OK, I will be posting that mail tomorrow or next day... I'll summarise > your concerns you've posted in this thread too. Thanks. > zeroing out the hole and marking it uptodate in case of a 0 length > ->commit_write does sound like the right way to go. I probably haven't > handled that correctly if it needs to be done in ext? or generic fs/ > routines... I *think* we want to handle this in generic_file_buffered_write(). Between ->prepare_write() and ->commit_write(). Here's what I'm thinking: generic_file_buffered_write() notices that it got a short copy from copy_from_user_inatomic(). It can then call a helper which walks the buffer heads attached to the page looking for BH_New regions which haven't been written to yet. It can then zero those out. We pass the normal from/to arguments over to ->commit_write() and those callbacks don't have to change - they just continue as usual. The newly allocated regions get written out, filling the holes with valid data and we avoid returning garbage from disk on subsequent reads. Ideas? "Holes" in the design? :) --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@...cle.com - 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