[LU-12236] Support more than the default root network namespace

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.13.0, Lustre 2.12.5
• Labels: patch
• Assignee: Aurelien Degremont (Inactive)
• Reporter: Aurelien Degremont (Inactive)

Description

Linux supports network namespaces. These namespaces creates different network views for different process groups. Each network namespace has its own set of network devices, IP addresses, routing table and TCP stack, including firewalling rules.

Network devices and TCP sockets are attached to a specific network namespace and are visible and usable only through it. Since network namespace feature was added to Linux, LNET has been using the default root namespace every time it needs a network namespace reference.

Container is a technical solution relying on cgroups and namespaces, including network namespaces. Trying to use Lustre in a container means trying to use Lustre in a specific network namespace. If this network namespace does have a dedicated network card to access the Lustre filesystem, it will not be possible for LNET to use and mount the Lustre filesystem. This feature intends to enable using more than the root namespace for Lustre communication.

Proposal:

Based on code audit, LNET uses this hardcoded root network namespace in 3 use cases. When:

• Enumerating all network devices, when configuring the LNET layer
• Listening to the LNET default socket for connection (by default: 0.0.0.0:988), in acceptor thread
• Creating a socket to connect to other LNET peers

As of Lustre 2.10, LNET records the current process network namespace when it setups a network interface definition internally.
The main idea to implement this feature is to rely on the current process network namespace instead of using the root namespace. This namespace is easily accessible in current->nsproxy->net_ns. Every time the current process could be easily accessed, this namespace will be used. The call chain is updated to pass this value down to the call that needs this value. This covers LNET setup, usually done using lnetctl, lctl or automatically when loading module with insmod or modprobe.
There are 2 cases where network accesses are made by Lustre service kernel threads. Service threads are always started in the default root namespace. We cannot rely on the current thread namespace for them:

• When a connection is received, this connection is received on a specific network interface usage. We know which network namespace is associated to it.
• When opening a socket to listen for incoming connections, Lustre does not enforce any specific network interface. Ideally we would like to accept connection from all LNET configured interfaces. However this requires more code changes. Instead of creating the socket into the root namespace, we will use the current process namespace that created the network listening thread. This keeps the code change limited and still able to use any network namespace on the system instead of the root one.

 

This is a initial design proposal.

Issue Links

• is related to: LU-11385 client hit BUG: unable to handle kernel NULL pointer dereference at 0000000000000028