On Tue, Jan 24, 2017 at 7:24 PM, Sergey Senozhatsky <[email protected]> wrote: > > just a note, > > On (01/24/17 15:02), Dan Streetman wrote: > [..] >> @@ -692,6 +702,15 @@ static int __zswap_param_set(const char *val, const >> struct kernel_param *kp, >> */ >> list_add_tail_rcu(&pool->list, &zswap_pools); >> put_pool = pool; >> + } else if (!zswap_has_pool) { >> + /* if initial pool creation failed, and this pool creation also >> + * failed, maybe both compressor and zpool params were bad. >> + * Allow changing this param, so pool creation will succeed >> + * when the other param is changed. We already verified this >> + * param is ok in the zpool_has_pool() or crypto_has_comp() >> + * checks above. >> + */ >> + ret = param_set_charp(s, kp); >> } >> >> spin_unlock(&zswap_pools_lock); > > looks like there still GFP_KERNEL allocation from atomic section: > param_set_charp()->kmalloc_parameter()->kmalloc(GFP_KERNEL), under > `zswap_pools_lock'.
thanks, it looks like the other param_set_charp above this new one has been in the spinlock ever since i added the param callback. I'll send a patch. > > -ss >
