linux-kernel - Re: [PATCH] NOMMU: Pages allocated to a ramfs inode's pagecache may get wrongly discarded

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:	Fri, 13 Mar 2009 18:19:47 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	torvalds@...ux-foundation.org, Enrik.Berkhan@...com,
	uclinux-dev@...inux.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] NOMMU: Pages allocated to a ramfs inode's pagecache may 
	get wrongly discarded

On Fri, Mar 13, 2009 at 5:15 PM, KOSAKI Motohiro
<kosaki.motohiro@...fujitsu.com> wrote:
>> > > >         The ramfs stuff is rather icky in that it adds the pages to the aging
>> > > >         list, marks them dirty, but does not provide a writeout method.
>> > > >
>> > > >         This will make the paging code scan over them (continuously) trying to
>> > > >         clean them, failing that (lack of writeout method) and putting them back
>> > > >         on the list.
>> > > >
>> > > > Not requiring the pages to be added to the LRU would be a really good idea.
>> > > > They are not discardable, be it in MMU or NOMMU mode, except when the inode
>> > > > itself is discarded.
>> > >
>> > > Yep, these pages shouldn't be on the LRU at all.  I guess that will
>> > > require some tweaks to core filemap.c code.
>> >
>> > IMHO, UNEVICTABLE_LRU already does lru isolation.
>> > only rest prblem is, getting rid of "depends on MMU" line in mm/Kconfig.
>> >
>> > Am I missing anything?
>>
>> Yes, the need to take something off that shouldn't be there to begin
>> with.
>
> In past unevictable lru discussion, we discuss the same thing.
> at that time, we found two reason of unevictable lru is better than
> completely taking off.
>
> (1) page migration code depend on the page stay on lru.
> (2) "taking off at reclaim time" can avoid adding lock to fastpath.
>    anyway, complely removing from lru need something lock.
>    we disliked it at that time

Can you explain this issue more detail when you are in convenience, please ?

> So, I think it is still true.
> Of cource, better cool solution is always welcome :)
>
>
>
>
> --
> 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/
>



-- 
Kinds regards,
Minchan Kim
--
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/