| 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: <x49lilcm1tb.fsf@segfault.boston.devel.redhat.com> Date: Tue, 01 May 2012 10:08:16 -0400 From: Jeff Moyer <jmoyer@...hat.com> To: Nick Piggin <npiggin@...il.com> Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, jaxboe@...ionio.com, Kyle McMartin <kmcmarti@...hat.com> Subject: Re: [patch|rfc] block: don't mark buffers beyond end of disk as mapped Nick Piggin <npiggin@...il.com> writes: > Not a bad fix. But it's kind of sad to have i_size checking logic also in > block_read_full_page, that does not cope with this. > > I have found there are parts of the kernel (readahead) that try to read > beyond EOF and seem to get angry if we return an error (by not > marking uptodate in readpage) in that case though :( > > But, either way, I think it's very reasonable to not mark buffers beyond > end of device as mapped. So I think your patch is fine. > > I guess for ext[234], it does not read metadata close to the end of the > device or you were using 4K sized blocks? Well, the test case just reads directly from the loop device, bypassing the file system, and I did use 1KB blocks when making the file system, so it is quite puzzling. Thanks for taking a look, Nick. Cheers, Jeff -- 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