netdev - Re: [PATCH 02/31] swap over network documentation

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] [day] [month] [year] [list]

Message-ID: <20091025063040.GB1480@ucw.cz>
Date:	Sun, 25 Oct 2009 07:30:40 +0100
From:	Pavel Machek <pavel@....cz>
To:	Suresh Jayaraman <sjayaraman@...e.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	netdev@...r.kernel.org, Neil Brown <neilb@...e.de>,
	Miklos Szeredi <mszeredi@...e.cz>, Wouter Verhelst <w@...r.be>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	trond.myklebust@....uio.no
Subject: Re: [PATCH 02/31] swap over network documentation

Hi!

> From: Neil Brown <neilb@...e.de>
> 
> Document describing the problem and proposed solution

> +Problem:
> +   When Linux needs to allocate memory it may find that there is
> +   insufficient free memory so it needs to reclaim space that is in
> +   use but not needed at the moment.  There are several options:
...
> +   3/ Write out some dirty page-cache pages so that they become clean.
> +      The VM limits the number of dirty page-cache pages to e.g. 40%
> +      of available memory so that (among other reasons) a "sync" will
> +      not take excessively long.  So there should never be excessive
> +      amounts of dirty pagecache.

I'd say "So it is not common to have excessive...". Yes, we try to
limit it, but IIRC malicious users would still be able to dirty
arbitrary ammounts...

....
> +      So anon pages tend to be left until last to be cleaned, and may
> +      be the only cleanable pages while there are still some dirty
> +      page-cache pages (which are waiting on a GFP_NOFS allocation).

Are you sure? Because this is saying 'Linux is broken without swap'
(and swap-less configs are more and more common). 

> +  For memory allocated using slab/slub: If a page that is added to a
> +  kmem_cache is found to have page->reserve set, then a  s->reserve
> +  flag is set for the whole kmem_cache.  Further allocations will only
> +  be returned from that page (or any other page in the cache) if they
> +  are emergency allocation (i.e. PF_MEMALLOC or GFP_MEMALLOC is set).
> +  Non-emergency allocations will block in alloc_page until a
> +  non-reserve page is available.  Once a non-reserve page has been
> +  added to the cache, the s->reserve flag on the cache is removed.

Does this greatly increase probability of GFP_ATOMIC allocations
failing?

> +  Similarly, if an skb is ever queued for delivery to user-space for
> +  example by netfilter, the ->emergency flag is tested and the skb is
> +  released if ->emergency is set. (so obviously the storage route may
> +  not pass through a userspace helper, otherwise the packets will never
> +  arrive and we'll deadlock)

(So -- .)

> +  pages_emergency can be changed dynamically based on need.  When
> +  swapout over the network is required, pages_emergency is increased
> +  to cover the maximum expected load.  When network swapout is
> +  disabled, pages_emergency is decreased.

Hmm, increasing pages_emergency is pretty interesting
operation.... right?

> +Thanks for reading this far.  I hope it made sense :-)
> +
> +Neil Brown (with updates from Peter Zijlstra)

Well, some warnings are misssing.

For example... swap over nfs over openvpn will do bad bad things,
right? ... and I guess that should be documented.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html