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
Kernel.

*Use case*: Use Network Namespaces on RT Processes
*Environment*: 2.6.35 Linux Kernel + some patches for netns (
https://github.com/unicell/redpatch/commits/rhel-2.6.32-358.6.2.ns.el6)
*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* (
http://lxr.free-electrons.com/source/kernel/sched.c?v=2.6.35#L7533)?
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:
http://lxr.free-electrons.com/source/kernel/sched.c?v=2.6.35#L7932

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

    init_rt_bandwidth(&tg->rt_bandwidth,
            ktime_to_ns(def_rt_bandwidth.rt_period),
def_rt_bandwidth.rt_runtime);

Kind regards,
Florin Medrea


More information about the Containers mailing list