[CRIU] [PATCH] dump: pre-load kernel modules

[Christopher Covington]

Hi Tycho,

On 12/12/2014 01:38 PM, Tycho Andersen wrote:
> On Thu, Dec 11, 2014 at 04:55:34PM -0500, Christopher Covington wrote:
>> On 10/14/2014 06:21 AM, Pavel Emelyanov wrote:
>>> On 10/14/2014 11:49 AM, Tycho Andersen wrote:
>>
>>>> diff --git a/sockets.c b/sockets.c
>>>> index 0268d35..6c71503 100644
>>>> --- a/sockets.c
>>>> +++ b/sockets.c
>>>> @@ -96,6 +96,41 @@ bool socket_test_collect_bit(unsigned int family, unsigned int proto)
>>>>  	return test_bit(nr, socket_cl_bits) != 0;
>>>>  }
>>>>  
>>>> +void preload_socket_modules()
>>>> +{
>>>> +	/*
>>>> +	 * If the task to dump (e.g. an LXC container) has any netlink
>>>> +	 * KOBJECT_UEVENT socket open and the _diag modules aren't
>>>> +	 * loaded is dumped, criu will freeze the task and then the
>>>> +	 * kernel will send it messages on the socket, and then we will
>>>> +	 * fail to dump because the socket has pending data. The Real
>>>> +	 * Solution is to dump this pending data, but we just modprobe
>>>> +	 * things beforehand for now so that the first dump doesn't
>>>> +	 * fail.
>>>> +	 *
>>>> +	 * We ignore failure since these could be compiled directly
>>>> +	 * in, instead of being kernel modules.
>>>> +	 */
>>>> +	char *modules[] = {
>>>> +		"netlink_diag",
>>>> +		"af_packet_diag",
>>>> +		"udp_diag",
>>>> +		"tcp_diag",
>>>> +		"unix_diag",
>>>> +		NULL,
>>>> +	};
>>>> +	int i;
>>>> +	char *args[2] = {
>>>> +		"modprobe",
>>>> +		NULL
>>>> +	};
>>>> +
>>>> +	for (i = 0; modules[i]; i++) {
>>>> +		args[1] = modules[i];
>>>> +		cr_system(-1, -1, -1, args[0], args);
>>
>> With this patch I get the following spurious prints. Is there some way they
>> could be avoided?
> 
> I suppose they could be avoided by checking if the modules are already
> loaded, but modprobe shouldn't exit 1 in that case. Do you know why it
> is failing?

I have this functionality built in (=y), not built as modules (=m). Perhaps if
/proc/config.gz exists (it does for my defconfigs) and is readable, and the
config options are =y, no attempt to load the modules should be made?

Thanks,
Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project