RT Scheduler and Network Namespaces - possible issue

Florin Medrea (Gmail) florinmedrea at gmail.com
Tue Oct 28 15:13:42 UTC 2014

Hello all,

I have a doubt about a certain issue I encounter on my embedded Linux

*Use case*: Use Network Namespaces on RT Processes
*Environment*: 2.6.35 Linux Kernel + some patches for netns (
*Configuration*: the *CONFIG_RT_GROUP_SCHED* option is activated

In my user space application (RT priority) I attemp to *unshare* to a new
Network Namespace. This fais with *EINVAL*. By debugging with printks in
the kernel scheduler, I found that the *unshare* request is refused at this
point: http://lxr.free-electrons.com/source/kernel/sched.c?v=2.6.35#L8392
(because *rt_bandwidth.rt_runtime* is 0).

Digging more in the trace calls, I see that the bandwidth is initialised
here: http://lxr.free-electrons.com/source/kernel/sched.c?v=2.6.35#L7932
and remains set to 0 during the *can_attach* check. Can someone explain why
the bandwidth is initialised to 0 runtime, whilst initialised to
*global_rt_runtime()* at other places in *sched.c* (
As a test, I have replaced the 0 value during this *init_rt_bandwidth* call
to *def_rt_bandwidth.rt_runtime* and my *unshare *system call succeeds.
Firsts tests of network namespaces with this workaround seem to work.

*To resume*, my question is related to this code line:

*Why initialise to 0 and not to the global/default value?*


Kind regards,
Florin Medrea

More information about the Containers mailing list