linux-kernel - Re: [PATCH] mm readahead: Fix sys_readahead breakage by reverting 2MB limit (bug 79111)

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:	Thu, 3 Jul 2014 11:22:44 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	David Cohen <david.a.cohen@...ux.intel.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Damien Ramonda <damien.ramonda@...el.com>,
	Jan Kara <jack@...e.cz>, David Rientjes <rientjes@...gle.com>,
	Nishanth Aravamudan <nacc@...ux.vnet.ibm.com>,
	linux-mm <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm readahead: Fix sys_readahead breakage by reverting 2MB
 limit (bug 79111)

On Thu, Jul 3, 2014 at 11:11 AM, Raghavendra K T
<raghavendra.kt@...ux.vnet.ibm.com> wrote:
>>
>> What? Where did you find that insane sentence? And where did you find
>> an application that depends on that totally insane semantics that sure
>> as hell was never intentional.
>>
>> If this comes from some man-page,
>
> Yes it is.

Ok, googling actually finds a fairly recent patch to fix it

   http://www.spinics.net/lists/linux-mm/msg70517.html

and several much older "that's not true" comments.

I wonder how it ever happened, because it has never actually been true
that readahead() has been synchronous. It *has* been true that large
read-aheads have started so much IO that just the act of starting more
would wait for request allocations etc to free up, so it's not like it
has ever been entirely asynchonous either, but it definitely has
*never* been synchronous afaik.

The new behavior just means that you can't trigger the "request queues
are all so full that we end up blocking waiting for new request
allocations" quite as easily.

That said, the bugzilla entry you mentioned does mention "can't boot
3.14 now". I'm not sure what the meaning of that sentence is, though.
Does it mean "can't boot 3.14 to test it because the machine is busy",
or is it a typo and really meant 3.15, and that some bootup script
*depended* on readahead()? I don't know. It seems strange. It also
seems like it would be very hard to even show this semantically (aside
from timing, and looking at how much of the cache is used like the
test-program does).

So the bugzilla entry worries me a bit - we definitely do not want to
regress in case somebody really relied on timing - but without more
specific information I still think the real bug is just in the
man-page.

                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/