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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 13 Mar 2009 17:15:44 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	kosaki.motohiro@...fujitsu.com,
	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

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

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ