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, 16 Mar 2007 00:28:37 +0100 From: Andrea Arcangeli <andrea@...e.de> To: Dave Kleikamp <shaggy@...ux.vnet.ibm.com> Cc: Hugh Dickins <hugh@...itas.com>, Nick Piggin <npiggin@...e.de>, Chuck Ebbert <cebbert@...hat.com>, Ashif Harji <asharji@...uwaterloo.ca>, Miquel van Smoorenburg <miquels@...tron.nl>, linux-mm@...ck.org, Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org Subject: Re: [PATCH] mm/filemap.c: unconditionally call mark_page_accessed On Thu, Mar 15, 2007 at 06:15:45PM -0500, Dave Kleikamp wrote: > On Thu, 2007-03-15 at 23:59 +0100, Andrea Arcangeli wrote: > > On Thu, Mar 15, 2007 at 05:44:01PM +0000, Hugh Dickins wrote: > > > who removed the !offset condition, he should be consulted on its > > > reintroduction. > > > > the !offset check looks a pretty broken heuristic indeed, it would > > break random I/O. > > I wouldn't call it broken. At worst, I'd say it's imperfect. But > that's the nature of a heuristic. It most likely works in a huge > majority of cases. well, IMHO in the huge majority of cases the prev_page check isn't necessary in the first place (and IMHO it hurts a lot more than it can help, as demonstrated by specweb, since we'll bite on the good guys to help the bad guys). The only case where I can imagine the prev_page to make sense is to handle contiguous I/O made with a small buffer, so clearly an inefficient code in the first place. But if this guy is reading with <PAGE_SIZE buffer there's no guarantee that he's reading f_pos aligned either, hence the need of taking last_offset into account too so at least it's a "perfect" heuristic that will reliably detect contiguous I/O no matter in what shape or form you execute it, as long as it is contiguous I/O. Any other variation of behavior besides the autodetection of contiguous I/O run in whatever buffer/aligned form, should be mandated by userland through fadvise/madvise IMHO or we run into the toes of the good guys. - 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