Hi
Thanks good comment!
How many times do we have to make this mistake :(Yeah, but making the caller need to know about the internal implementation details of the callee (ie, whether it needs to allocate memory or not) leads to pretty warty interfaces. In this case, you could push the gfp_t up to the call_usermodehelper_setup() level, but pushing it any higher wouldn't make much sense.
Only the caller knows what allocation mode the callee can use. call_usermodehelper_setup() should be extended to take a gfp_t argument.
No problem :)
almost caller doesn't call call_usermodehelper_setup() directly.
thus, call_usermodehelper_setup() chage is hided in call_usermodehelper().
----------------chunk of my current testing patch-----------------------------
@@ -68,8 +69,9 @@ static inline int
call_usermodehelper(char *path, char **argv, char **envp, enum umh_wait wait)
{
struct subprocess_info *info;
+ gfp_t gfp_mask = (wait == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
- info = call_usermodehelper_setup(path, argv, envp);
+ info = call_usermodehelper_setup(path, argv, envp, gfp_mask);
if (info == NULL)
return -ENOMEM;
return call_usermodehelper_exec(info, wait);