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
| ||
|
Date: Sun, 03 Oct 2010 15:40:55 -0400 From: Nitin Gupta <ngupta@...are.org> To: Dave Hansen <dave@...ux.vnet.ibm.com> CC: Pekka Enberg <penberg@...helsinki.fi>, Minchan Kim <minchan.kim@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Greg KH <greg@...ah.com>, Linux Driver Project <devel@...uxdriverproject.org>, linux-mm <linux-mm@...ck.org>, linux-kernel <linux-kernel@...r.kernel.org>, Greg KH - Meetings <ghartman@...ibm.com> Subject: Re: OOM panics with zram On 10/3/2010 3:27 PM, Dave Hansen wrote: > On Sun, 2010-10-03 at 14:41 -0400, Nitin Gupta wrote: >> Ability to write out zram (compressed) memory to a backing disk seems >> really useful. However considering lkml reviews, I had to drop this >> feature. Anyways, I guess I will try to push this feature again. > > I'd argue that zram is pretty useless without some ability to write to a > backing store, unless you *really* know what is going to be stored in it > and you trust the user. Otherwise, it's just too easy to OOM the > system. > > I've been investigating backing the xvmalloc space with a tmpfs file. > Instead of keeping page/offset pairs, you just keep a linear address > inside the tmpfile file. There's an extra step needed to look up and > lock the page cache page into place each time you go into the xvmalloc > store, but it does seem to basically work. The patches are really rough > and not quite functional, but I'm happy to share if you want to see them > now. > Yes, I would be really interested to look at them. Thanks. >> Also, please do not use linux-next/mainline version of compcache. Instead >> just use version in the project repository here: >> hg clone https://compcache.googlecode.com/hg/ compcache >> >> This is updated much more frequently and has many more bug fixes over >> the mainline. It will also be easier to fix bugs/add features much more >> quickly in this repo rather than sending them to lkml which can take >> long time. > > That looks like just a clone of the code needed to build the module. > > Kernel developers are pretty used to _some_ kernel tree being the > authoritative source. Also, having it in a kernel tree makes it > possible to get testing in places like linux-next, and it makes it > easier for people to make patches or kernel trees on top of your work. > > There's not really a point to the code being in -staging if it isn't > somewhat up-to-date or people can't generate patches to it. It sounds > to me like we need to take it out of -staging. > I will try sending patches to sync mainline and hg code (along with some changes in pipeline), or maybe just take it out of -staging and send fresh patch series. Thanks, Nitin -- 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