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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 2 Feb 2010 10:40:41 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Olivier Galibert <galibert@...ox.com>
cc:	Wu Fengguang <fengguang.wu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Memory Management List <linux-mm@...ck.org>,
	linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 10/11] readahead: dont do start-of-file readahead after
 lseek()



On Tue, 2 Feb 2010, Olivier Galibert wrote:
> 
> Wouldn't that trigger on lseeks to end of file to get the size?

Well, you'd only ever do that with a raw block device, no (if even that: 
more "raw block device" tools just use the BLKSIZE64 ioctl etc)? Any sane 
regular file accessor will do 'fstat()' instead.

And do we care about startup speed of ramping up read-ahead from the 
beginning? In fact, the problem case that caused this was literally 
'blkid' on a block device - and the fact that the kernel tried to 
read-ahead TOO MUCh rather than too little.

If somebody is really doing lots of serial reading, the read-ahead code 
will figure it out very quickly. The case this worries about is just the 
_first_ read, where the question is one of "do we think it might be 
seeking around, or does it look like the user is going to just read the 
whole thing"?

IOW, if you start off with a SEEK_END, I think it's reasonable to expect 
it to _not_ read the whole thing.

			Linus
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ