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: Tue, 24 Nov 2015 13:41:39 +0900 From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> To: Minchan Kim <minchan@...nel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Kyeongdon Kim <kyeongdon.kim@....com>, Sergey Senozhatsky <sergey.senozhatsky@...il.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] zram/zcomp: use GFP_NOIO to allocate streams On (11/24/15 13:13), Minchan Kim wrote: > First of all, Thanks for the summary and proposal. sure :) > I think GFP_NOIO critical part(ie, your lockdep fix patch) should > go to -stable so it should stand alone. > > About vmalloc, I like that. Just problem was gfp and we can > pass it from upper layer so I believe it makes code looks clean > and solve differnt gfp problem. doing vmalloc() after kmalloc in general looks ok, but the thing is that kmalloc()->vmalloc() fallback does not mean that stream allocation will end up being successful, because right after ->private we need to allocate ->buffer via __get_free_pages() and that thing can fail. so trying harder in comp->backend->create() is just half of what we need. but the question is -- do we have a really big reason to fallback in ->private allocation? we are quite prepared to handle that allocation failure and I tend to think that in low memory condition it's probably better to avoid stealing pages for additional streams; one stream is just enough, if we are lucky to have more than one stream by that time -- then fine. > Please look at my patchset I just sent. I'll take a look once I receive them (not in my inbox yet). -ss -- 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