Great question! Let’s break this down clearly—covering what’s technically possible, why it’s not a great idea, and the better approach.

Technical Possibility: Yes, But... #

Technically speaking, you can use one Netlink socket for both types of communication. Here’s how:

• Netlink uses pid (process ID) to route messages. The kernel is addressed with pid 0, while user-space processes use their own actual PIDs.
• When you create a Netlink socket in user space, you can bind it to your process’s PID and even join multicast groups. You’re free to send messages to both pid 0 (kernel) and other user-space PIDs, and receive responses from either.

Why You Should Avoid This #

While it works in theory, mixing these two communication paths in a single socket creates unnecessary headaches:

• Messy Message Handling: You’ll need extra logic to differentiate between messages coming from the kernel vs. other user processes. It’s easy to mix up responses, leading to bugs that are hard to trace.
• Security Risks: A malicious user-space process could craft messages that look like kernel responses, tricking your app into executing unintended actions. Separating sockets limits this exposure.
• Poor Maintainability: Other developers (or future you) will struggle to parse which traffic is which. Clean, separated sockets make your code self-documenting and easier to debug.

The Recommended Approach #

The standard best practice is to use two distinct Netlink sockets:

• One socket dedicated exclusively to user-kernel communication (send to pid 0, handle kernel responses).
• Another socket for user-user communication—either targeting specific PIDs directly or using a dedicated multicast group for broader user-space messaging.

内容的提问来源于stack exchange，提问作者Karthick