netlink bug?
Hi guys,
I've got a piece of code that seems to reliably cause the kernel to panic, looks like a problem somewhere down the netlink core...
I've been trying to use NETLINK_FIB_LOOKUP but so far the closest I've come to success was a kernel crash, a slightly stripped down version of the code that first crashed it attached. If somebody else can confirm this it would be appreciated, also, any pointers on what I'm doing wrong that triggers the behaviour to begin with would be appreciated, thanks.
I'm currently on kernel version 2.6.19.2, so this may have been fixed in the meantime. Note that I don't need to run the code as root in order to trigger the crash.
Jaco
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <memory.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/netlink.h>
/* stolen from kernel source ... could be a problem here ... */
struct fib_result_nl {
uint32_t fl_addr; /* To be looked up*/
uint32_t fl_fwmark;
unsigned char fl_tos;
unsigned char fl_scope;
unsigned char tb_id_in;
unsigned char tb_id; /* Results */
unsigned char prefixlen;
unsigned char nh_sel;
unsigned char type;
unsigned char scope;
int err;
};struct msg {
struct nlmsghdr nh;
struct fib_result_nl frn;
};int main()
{
struct msg msg;
struct sockaddr_nl sa;
int fd;
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
sa.nl_pid = getpid();
assert((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_FIB_LOOKUP)) > 0);
assert(bind(fd, (struct sockaddr*)&sa, sizeof(sa)) == 0);
sa.nl_pid = 0;
memset(&msg, 0, sizeof(msg));
msg.nh.nlmsg_len = sizeof(msg);
msg.nh.nlmsg_flags = NLMSG_DONE;
assert(sendto(fd, &msg, sizeof(msg), 0, (void*)&sa, sizeof(sa)) > 0);
return 0;
}_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors
Quoted 11 lines · Jaco Kroon
Hi guys,
I've got a piece of code that seems to reliably cause the kernel to panic, looks like a problem somewhere down the netlink core...
I've been trying to use
NETLINK_FIB_LOOKUPbut so far the closest I've come to success was a kernel crash, a slightly stripped down version of the code that first crashed it attached. If somebody else can confirm this it would be appreciated, also, any pointers on what I'm doing wrong that triggers the behaviour to begin with would be appreciated, thanks.
Quoted 3 lines
I'm currently on kernel version 2.6.19.2, so this may have been fixed in the meantime. Note that I don't need to run the code as root in order to trigger the crash.
Next time, if you find a kernel issue like this, could you just forward this to the [email protected] mail alias? This turned out to be a real kernel issue, and now 2.6.20.8 is released with a fix for this problem.
I still think there's a bug in your userspace program, but the kernel shouldn't die anymore at least :)
thanks,
greg k-h
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors
Quoted 16 lines · Greg KH
Quoted 11 lines · Jaco Kroon
Hi guys,
I've got a piece of code that seems to reliably cause the kernel to panic, looks like a problem somewhere down the netlink core...
I've been trying to use
NETLINK_FIB_LOOKUPbut so far the closest I've come to success was a kernel crash, a slightly stripped down version of the code that first crashed it attached. If somebody else can confirm this it would be appreciated, also, any pointers on what I'm doing wrong that triggers the behaviour to begin with would be appreciated, thanks.Quoted 3 lines
I'm currently on kernel version 2.6.19.2, so this may have been fixed in the meantime. Note that I don't need to run the code as root in order to trigger the crash.
Quoted 7 lines
Next time, if you find a kernel issue like this, could you just forward this to the [email protected] mail alias? This turned out to be a real kernel issue, and now 2.6.20.8 is released with a fix for this problem.
I still think there's a bug in your userspace program, but the kernel shouldn't die anymore at least :)
Trust me, I know there is a bug in my userspace app, wasn't aware of the [email protected] mail alias (and didn't like the idea of pushing directly to lkml where it would be likely to be overlooked), will use that next time. I'd like to know _how_ the userspace app should actually work, but I'll leave that for another day ... (documentation is rather scarce).
Thanks for forwarding, and thanks for getting it resolved.
Jaco
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors