linux/drivers/connector/cn_proc.c

483 lines
13 KiB

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix unsafe usage of ->real_parent proc_exit_connector() uses ->real_parent lockless. This is not safe that its parent can go away at any moment, so use RCU to protect it, and ensure that this task is not released. [ 747.624551] ================================================================== [ 747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310 [ 747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882 [ 747.648032] [ 747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G E 4.19.26-rc2 #11 [ 747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014 [ 747.668419] Call Trace: [ 747.671269] dump_stack+0xf0/0x19b [ 747.675186] ? show_regs_print_info+0x5/0x5 [ 747.679988] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 747.685302] print_address_description+0x6a/0x270 [ 747.691162] kasan_report+0x258/0x380 [ 747.695835] ? proc_exit_connector+0x1f7/0x310 [ 747.701402] proc_exit_connector+0x1f7/0x310 [ 747.706767] ? proc_coredump_connector+0x2d0/0x2d0 [ 747.712715] ? _raw_write_unlock_irq+0x29/0x50 [ 747.718270] ? _raw_write_unlock_irq+0x29/0x50 [ 747.723820] ? ___preempt_schedule+0x16/0x18 [ 747.729193] ? ___preempt_schedule+0x16/0x18 [ 747.734574] do_exit+0xa11/0x14f0 [ 747.738880] ? mm_update_next_owner+0x590/0x590 [ 747.744525] ? debug_show_all_locks+0x3c0/0x3c0 [ 747.761448] ? ktime_get_coarse_real_ts64+0xeb/0x1c0 [ 747.767589] ? lockdep_hardirqs_on+0x1a6/0x290 [ 747.773154] ? check_chain_key+0x139/0x1f0 [ 747.778345] ? check_flags.part.35+0x240/0x240 [ 747.783908] ? __lock_acquire+0x2300/0x2300 [ 747.789171] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.795316] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.801457] ? do_raw_spin_unlock+0x10f/0x1e0 [ 747.806914] ? do_raw_spin_trylock+0x120/0x120 [ 747.812481] ? preempt_count_sub+0x14/0xc0 [ 747.817645] ? _raw_spin_unlock+0x2e/0x50 [ 747.822708] ? __handle_mm_fault+0x12db/0x1fa0 [ 747.828367] ? __pmd_alloc+0x2d0/0x2d0 [ 747.833143] ? check_noncircular+0x50/0x50 [ 747.838309] ? match_held_lock+0x7f/0x340 [ 747.843380] ? check_noncircular+0x50/0x50 [ 747.848561] ? handle_mm_fault+0x21a/0x5f0 [ 747.853730] ? check_flags.part.35+0x240/0x240 [ 747.859290] ? check_chain_key+0x139/0x1f0 [ 747.864474] ? __do_page_fault+0x40f/0x760 [ 747.869655] ? __audit_syscall_entry+0x4b/0x1f0 [ 747.875319] ? syscall_trace_enter+0x1d5/0x7b0 [ 747.880877] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.887895] ? trace_raw_output_sys_exit+0x80/0x80 [ 747.893860] ? up_read+0x3b/0x90 [ 747.898142] ? stop_critical_timings+0x260/0x260 [ 747.903909] do_group_exit+0xe0/0x1c0 [ 747.908591] ? __x64_sys_exit+0x30/0x30 [ 747.913460] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.920485] ? tracer_hardirqs_on+0x270/0x270 [ 747.925956] __x64_sys_exit_group+0x28/0x30 [ 747.931214] do_syscall_64+0x117/0x400 [ 747.935988] ? syscall_return_slowpath+0x2f0/0x2f0 [ 747.941931] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.947788] ? trace_hardirqs_on_caller+0x1d0/0x1d0 [ 747.953838] ? lockdep_sys_exit+0x16/0x8e [ 747.958915] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.964784] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 747.971021] RIP: 0033:0x7f572f154c68 [ 747.975606] Code: Bad RIP value. [ 747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68 [ 747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 [ 748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0 [ 748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840 [ 748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310 [ 748.032287] [ 748.034509] Allocated by task 2300: [ 748.038982] kasan_kmalloc+0xa0/0xd0 [ 748.043562] kmem_cache_alloc_node+0xf5/0x2e0 [ 748.049018] copy_process+0x1781/0x4790 [ 748.053884] _do_fork+0x166/0x9a0 [ 748.058163] do_syscall_64+0x117/0x400 [ 748.062943] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.069180] [ 748.071405] Freed by task 15395: [ 748.075591] __kasan_slab_free+0x130/0x180 [ 748.080752] kmem_cache_free+0xc2/0x310 [ 748.085619] free_task+0xea/0x130 [ 748.089901] __put_task_struct+0x177/0x230 [ 748.095063] finish_task_switch+0x51b/0x5d0 [ 748.100315] __schedule+0x506/0xfa0 [ 748.104791] schedule+0xca/0x260 [ 748.108978] futex_wait_queue_me+0x27e/0x420 [ 748.114333] futex_wait+0x251/0x550 [ 748.118814] do_futex+0x75b/0xf80 [ 748.123097] __x64_sys_futex+0x231/0x2a0 [ 748.128065] do_syscall_64+0x117/0x400 [ 748.132835] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.139066] [ 748.141289] The buggy address belongs to the object at ffff88a027698000 [ 748.141289] which belongs to the cache task_struct of size 12160 [ 748.156589] The buggy address is located 2272 bytes inside of [ 748.156589] 12160-byte region [ffff88a027698000, ffff88a02769af80) [ 748.171114] The buggy address belongs to the page: [ 748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0 [ 748.189136] flags: 0x57ffffc0008100(slab|head) [ 748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00 [ 748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ 748.214146] page dumped because: kasan: bad access detected [ 748.220976] [ 748.223197] Memory state around the buggy address: [ 748.229128] ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.238271] ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.256564] ^ [ 748.264267] ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.273493] ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.282630] ================================================================== Fixes: b086ff87251b4a4 ("connector: add parent pid and tgid to coredump and exit events") Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-06 14:46:27 +08:00
connector: fix unsafe usage of ->real_parent proc_exit_connector() uses ->real_parent lockless. This is not safe that its parent can go away at any moment, so use RCU to protect it, and ensure that this task is not released. [ 747.624551] ================================================================== [ 747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310 [ 747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882 [ 747.648032] [ 747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G E 4.19.26-rc2 #11 [ 747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014 [ 747.668419] Call Trace: [ 747.671269] dump_stack+0xf0/0x19b [ 747.675186] ? show_regs_print_info+0x5/0x5 [ 747.679988] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 747.685302] print_address_description+0x6a/0x270 [ 747.691162] kasan_report+0x258/0x380 [ 747.695835] ? proc_exit_connector+0x1f7/0x310 [ 747.701402] proc_exit_connector+0x1f7/0x310 [ 747.706767] ? proc_coredump_connector+0x2d0/0x2d0 [ 747.712715] ? _raw_write_unlock_irq+0x29/0x50 [ 747.718270] ? _raw_write_unlock_irq+0x29/0x50 [ 747.723820] ? ___preempt_schedule+0x16/0x18 [ 747.729193] ? ___preempt_schedule+0x16/0x18 [ 747.734574] do_exit+0xa11/0x14f0 [ 747.738880] ? mm_update_next_owner+0x590/0x590 [ 747.744525] ? debug_show_all_locks+0x3c0/0x3c0 [ 747.761448] ? ktime_get_coarse_real_ts64+0xeb/0x1c0 [ 747.767589] ? lockdep_hardirqs_on+0x1a6/0x290 [ 747.773154] ? check_chain_key+0x139/0x1f0 [ 747.778345] ? check_flags.part.35+0x240/0x240 [ 747.783908] ? __lock_acquire+0x2300/0x2300 [ 747.789171] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.795316] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.801457] ? do_raw_spin_unlock+0x10f/0x1e0 [ 747.806914] ? do_raw_spin_trylock+0x120/0x120 [ 747.812481] ? preempt_count_sub+0x14/0xc0 [ 747.817645] ? _raw_spin_unlock+0x2e/0x50 [ 747.822708] ? __handle_mm_fault+0x12db/0x1fa0 [ 747.828367] ? __pmd_alloc+0x2d0/0x2d0 [ 747.833143] ? check_noncircular+0x50/0x50 [ 747.838309] ? match_held_lock+0x7f/0x340 [ 747.843380] ? check_noncircular+0x50/0x50 [ 747.848561] ? handle_mm_fault+0x21a/0x5f0 [ 747.853730] ? check_flags.part.35+0x240/0x240 [ 747.859290] ? check_chain_key+0x139/0x1f0 [ 747.864474] ? __do_page_fault+0x40f/0x760 [ 747.869655] ? __audit_syscall_entry+0x4b/0x1f0 [ 747.875319] ? syscall_trace_enter+0x1d5/0x7b0 [ 747.880877] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.887895] ? trace_raw_output_sys_exit+0x80/0x80 [ 747.893860] ? up_read+0x3b/0x90 [ 747.898142] ? stop_critical_timings+0x260/0x260 [ 747.903909] do_group_exit+0xe0/0x1c0 [ 747.908591] ? __x64_sys_exit+0x30/0x30 [ 747.913460] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.920485] ? tracer_hardirqs_on+0x270/0x270 [ 747.925956] __x64_sys_exit_group+0x28/0x30 [ 747.931214] do_syscall_64+0x117/0x400 [ 747.935988] ? syscall_return_slowpath+0x2f0/0x2f0 [ 747.941931] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.947788] ? trace_hardirqs_on_caller+0x1d0/0x1d0 [ 747.953838] ? lockdep_sys_exit+0x16/0x8e [ 747.958915] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.964784] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 747.971021] RIP: 0033:0x7f572f154c68 [ 747.975606] Code: Bad RIP value. [ 747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68 [ 747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 [ 748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0 [ 748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840 [ 748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310 [ 748.032287] [ 748.034509] Allocated by task 2300: [ 748.038982] kasan_kmalloc+0xa0/0xd0 [ 748.043562] kmem_cache_alloc_node+0xf5/0x2e0 [ 748.049018] copy_process+0x1781/0x4790 [ 748.053884] _do_fork+0x166/0x9a0 [ 748.058163] do_syscall_64+0x117/0x400 [ 748.062943] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.069180] [ 748.071405] Freed by task 15395: [ 748.075591] __kasan_slab_free+0x130/0x180 [ 748.080752] kmem_cache_free+0xc2/0x310 [ 748.085619] free_task+0xea/0x130 [ 748.089901] __put_task_struct+0x177/0x230 [ 748.095063] finish_task_switch+0x51b/0x5d0 [ 748.100315] __schedule+0x506/0xfa0 [ 748.104791] schedule+0xca/0x260 [ 748.108978] futex_wait_queue_me+0x27e/0x420 [ 748.114333] futex_wait+0x251/0x550 [ 748.118814] do_futex+0x75b/0xf80 [ 748.123097] __x64_sys_futex+0x231/0x2a0 [ 748.128065] do_syscall_64+0x117/0x400 [ 748.132835] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.139066] [ 748.141289] The buggy address belongs to the object at ffff88a027698000 [ 748.141289] which belongs to the cache task_struct of size 12160 [ 748.156589] The buggy address is located 2272 bytes inside of [ 748.156589] 12160-byte region [ffff88a027698000, ffff88a02769af80) [ 748.171114] The buggy address belongs to the page: [ 748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0 [ 748.189136] flags: 0x57ffffc0008100(slab|head) [ 748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00 [ 748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ 748.214146] page dumped because: kasan: bad access detected [ 748.220976] [ 748.223197] Memory state around the buggy address: [ 748.229128] ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.238271] ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.256564] ^ [ 748.264267] ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.273493] ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.282630] ================================================================== Fixes: b086ff87251b4a4 ("connector: add parent pid and tgid to coredump and exit events") Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-06 14:46:27 +08:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix unsafe usage of ->real_parent proc_exit_connector() uses ->real_parent lockless. This is not safe that its parent can go away at any moment, so use RCU to protect it, and ensure that this task is not released. [ 747.624551] ================================================================== [ 747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310 [ 747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882 [ 747.648032] [ 747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G E 4.19.26-rc2 #11 [ 747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014 [ 747.668419] Call Trace: [ 747.671269] dump_stack+0xf0/0x19b [ 747.675186] ? show_regs_print_info+0x5/0x5 [ 747.679988] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 747.685302] print_address_description+0x6a/0x270 [ 747.691162] kasan_report+0x258/0x380 [ 747.695835] ? proc_exit_connector+0x1f7/0x310 [ 747.701402] proc_exit_connector+0x1f7/0x310 [ 747.706767] ? proc_coredump_connector+0x2d0/0x2d0 [ 747.712715] ? _raw_write_unlock_irq+0x29/0x50 [ 747.718270] ? _raw_write_unlock_irq+0x29/0x50 [ 747.723820] ? ___preempt_schedule+0x16/0x18 [ 747.729193] ? ___preempt_schedule+0x16/0x18 [ 747.734574] do_exit+0xa11/0x14f0 [ 747.738880] ? mm_update_next_owner+0x590/0x590 [ 747.744525] ? debug_show_all_locks+0x3c0/0x3c0 [ 747.761448] ? ktime_get_coarse_real_ts64+0xeb/0x1c0 [ 747.767589] ? lockdep_hardirqs_on+0x1a6/0x290 [ 747.773154] ? check_chain_key+0x139/0x1f0 [ 747.778345] ? check_flags.part.35+0x240/0x240 [ 747.783908] ? __lock_acquire+0x2300/0x2300 [ 747.789171] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.795316] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.801457] ? do_raw_spin_unlock+0x10f/0x1e0 [ 747.806914] ? do_raw_spin_trylock+0x120/0x120 [ 747.812481] ? preempt_count_sub+0x14/0xc0 [ 747.817645] ? _raw_spin_unlock+0x2e/0x50 [ 747.822708] ? __handle_mm_fault+0x12db/0x1fa0 [ 747.828367] ? __pmd_alloc+0x2d0/0x2d0 [ 747.833143] ? check_noncircular+0x50/0x50 [ 747.838309] ? match_held_lock+0x7f/0x340 [ 747.843380] ? check_noncircular+0x50/0x50 [ 747.848561] ? handle_mm_fault+0x21a/0x5f0 [ 747.853730] ? check_flags.part.35+0x240/0x240 [ 747.859290] ? check_chain_key+0x139/0x1f0 [ 747.864474] ? __do_page_fault+0x40f/0x760 [ 747.869655] ? __audit_syscall_entry+0x4b/0x1f0 [ 747.875319] ? syscall_trace_enter+0x1d5/0x7b0 [ 747.880877] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.887895] ? trace_raw_output_sys_exit+0x80/0x80 [ 747.893860] ? up_read+0x3b/0x90 [ 747.898142] ? stop_critical_timings+0x260/0x260 [ 747.903909] do_group_exit+0xe0/0x1c0 [ 747.908591] ? __x64_sys_exit+0x30/0x30 [ 747.913460] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.920485] ? tracer_hardirqs_on+0x270/0x270 [ 747.925956] __x64_sys_exit_group+0x28/0x30 [ 747.931214] do_syscall_64+0x117/0x400 [ 747.935988] ? syscall_return_slowpath+0x2f0/0x2f0 [ 747.941931] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.947788] ? trace_hardirqs_on_caller+0x1d0/0x1d0 [ 747.953838] ? lockdep_sys_exit+0x16/0x8e [ 747.958915] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.964784] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 747.971021] RIP: 0033:0x7f572f154c68 [ 747.975606] Code: Bad RIP value. [ 747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68 [ 747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 [ 748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0 [ 748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840 [ 748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310 [ 748.032287] [ 748.034509] Allocated by task 2300: [ 748.038982] kasan_kmalloc+0xa0/0xd0 [ 748.043562] kmem_cache_alloc_node+0xf5/0x2e0 [ 748.049018] copy_process+0x1781/0x4790 [ 748.053884] _do_fork+0x166/0x9a0 [ 748.058163] do_syscall_64+0x117/0x400 [ 748.062943] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.069180] [ 748.071405] Freed by task 15395: [ 748.075591] __kasan_slab_free+0x130/0x180 [ 748.080752] kmem_cache_free+0xc2/0x310 [ 748.085619] free_task+0xea/0x130 [ 748.089901] __put_task_struct+0x177/0x230 [ 748.095063] finish_task_switch+0x51b/0x5d0 [ 748.100315] __schedule+0x506/0xfa0 [ 748.104791] schedule+0xca/0x260 [ 748.108978] futex_wait_queue_me+0x27e/0x420 [ 748.114333] futex_wait+0x251/0x550 [ 748.118814] do_futex+0x75b/0xf80 [ 748.123097] __x64_sys_futex+0x231/0x2a0 [ 748.128065] do_syscall_64+0x117/0x400 [ 748.132835] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.139066] [ 748.141289] The buggy address belongs to the object at ffff88a027698000 [ 748.141289] which belongs to the cache task_struct of size 12160 [ 748.156589] The buggy address is located 2272 bytes inside of [ 748.156589] 12160-byte region [ffff88a027698000, ffff88a02769af80) [ 748.171114] The buggy address belongs to the page: [ 748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0 [ 748.189136] flags: 0x57ffffc0008100(slab|head) [ 748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00 [ 748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ 748.214146] page dumped because: kasan: bad access detected [ 748.220976] [ 748.223197] Memory state around the buggy address: [ 748.229128] ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.238271] ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.256564] ^ [ 748.264267] ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.273493] ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.282630] ================================================================== Fixes: b086ff87251b4a4 ("connector: add parent pid and tgid to coredump and exit events") Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-06 14:46:27 +08:00
connector: fix unsafe usage of ->real_parent proc_exit_connector() uses ->real_parent lockless. This is not safe that its parent can go away at any moment, so use RCU to protect it, and ensure that this task is not released. [ 747.624551] ================================================================== [ 747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310 [ 747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882 [ 747.648032] [ 747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G E 4.19.26-rc2 #11 [ 747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014 [ 747.668419] Call Trace: [ 747.671269] dump_stack+0xf0/0x19b [ 747.675186] ? show_regs_print_info+0x5/0x5 [ 747.679988] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 747.685302] print_address_description+0x6a/0x270 [ 747.691162] kasan_report+0x258/0x380 [ 747.695835] ? proc_exit_connector+0x1f7/0x310 [ 747.701402] proc_exit_connector+0x1f7/0x310 [ 747.706767] ? proc_coredump_connector+0x2d0/0x2d0 [ 747.712715] ? _raw_write_unlock_irq+0x29/0x50 [ 747.718270] ? _raw_write_unlock_irq+0x29/0x50 [ 747.723820] ? ___preempt_schedule+0x16/0x18 [ 747.729193] ? ___preempt_schedule+0x16/0x18 [ 747.734574] do_exit+0xa11/0x14f0 [ 747.738880] ? mm_update_next_owner+0x590/0x590 [ 747.744525] ? debug_show_all_locks+0x3c0/0x3c0 [ 747.761448] ? ktime_get_coarse_real_ts64+0xeb/0x1c0 [ 747.767589] ? lockdep_hardirqs_on+0x1a6/0x290 [ 747.773154] ? check_chain_key+0x139/0x1f0 [ 747.778345] ? check_flags.part.35+0x240/0x240 [ 747.783908] ? __lock_acquire+0x2300/0x2300 [ 747.789171] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.795316] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.801457] ? do_raw_spin_unlock+0x10f/0x1e0 [ 747.806914] ? do_raw_spin_trylock+0x120/0x120 [ 747.812481] ? preempt_count_sub+0x14/0xc0 [ 747.817645] ? _raw_spin_unlock+0x2e/0x50 [ 747.822708] ? __handle_mm_fault+0x12db/0x1fa0 [ 747.828367] ? __pmd_alloc+0x2d0/0x2d0 [ 747.833143] ? check_noncircular+0x50/0x50 [ 747.838309] ? match_held_lock+0x7f/0x340 [ 747.843380] ? check_noncircular+0x50/0x50 [ 747.848561] ? handle_mm_fault+0x21a/0x5f0 [ 747.853730] ? check_flags.part.35+0x240/0x240 [ 747.859290] ? check_chain_key+0x139/0x1f0 [ 747.864474] ? __do_page_fault+0x40f/0x760 [ 747.869655] ? __audit_syscall_entry+0x4b/0x1f0 [ 747.875319] ? syscall_trace_enter+0x1d5/0x7b0 [ 747.880877] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.887895] ? trace_raw_output_sys_exit+0x80/0x80 [ 747.893860] ? up_read+0x3b/0x90 [ 747.898142] ? stop_critical_timings+0x260/0x260 [ 747.903909] do_group_exit+0xe0/0x1c0 [ 747.908591] ? __x64_sys_exit+0x30/0x30 [ 747.913460] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.920485] ? tracer_hardirqs_on+0x270/0x270 [ 747.925956] __x64_sys_exit_group+0x28/0x30 [ 747.931214] do_syscall_64+0x117/0x400 [ 747.935988] ? syscall_return_slowpath+0x2f0/0x2f0 [ 747.941931] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.947788] ? trace_hardirqs_on_caller+0x1d0/0x1d0 [ 747.953838] ? lockdep_sys_exit+0x16/0x8e [ 747.958915] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.964784] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 747.971021] RIP: 0033:0x7f572f154c68 [ 747.975606] Code: Bad RIP value. [ 747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68 [ 747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 [ 748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0 [ 748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840 [ 748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310 [ 748.032287] [ 748.034509] Allocated by task 2300: [ 748.038982] kasan_kmalloc+0xa0/0xd0 [ 748.043562] kmem_cache_alloc_node+0xf5/0x2e0 [ 748.049018] copy_process+0x1781/0x4790 [ 748.053884] _do_fork+0x166/0x9a0 [ 748.058163] do_syscall_64+0x117/0x400 [ 748.062943] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.069180] [ 748.071405] Freed by task 15395: [ 748.075591] __kasan_slab_free+0x130/0x180 [ 748.080752] kmem_cache_free+0xc2/0x310 [ 748.085619] free_task+0xea/0x130 [ 748.089901] __put_task_struct+0x177/0x230 [ 748.095063] finish_task_switch+0x51b/0x5d0 [ 748.100315] __schedule+0x506/0xfa0 [ 748.104791] schedule+0xca/0x260 [ 748.108978] futex_wait_queue_me+0x27e/0x420 [ 748.114333] futex_wait+0x251/0x550 [ 748.118814] do_futex+0x75b/0xf80 [ 748.123097] __x64_sys_futex+0x231/0x2a0 [ 748.128065] do_syscall_64+0x117/0x400 [ 748.132835] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.139066] [ 748.141289] The buggy address belongs to the object at ffff88a027698000 [ 748.141289] which belongs to the cache task_struct of size 12160 [ 748.156589] The buggy address is located 2272 bytes inside of [ 748.156589] 12160-byte region [ffff88a027698000, ffff88a02769af80) [ 748.171114] The buggy address belongs to the page: [ 748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0 [ 748.189136] flags: 0x57ffffc0008100(slab|head) [ 748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00 [ 748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ 748.214146] page dumped because: kasan: bad access detected [ 748.220976] [ 748.223197] Memory state around the buggy address: [ 748.229128] ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.238271] ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.256564] ^ [ 748.264267] ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.273493] ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.282630] ================================================================== Fixes: b086ff87251b4a4 ("connector: add parent pid and tgid to coredump and exit events") Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-06 14:46:27 +08:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector: fix out-of-order cn_proc netlink message delivery The proc connector messages include a sequence number, allowing userspace programs to detect lost messages. However, performing this detection is currently more difficult than necessary, since netlink messages can be delivered to the application out-of-order. To fix this, leave pre-emption disabled during cn_netlink_send(), and use GFP_NOWAIT. The following was written as a test case. Building the kernel w/ make -j32 proved a reliable way to generate out-of-order cn_proc messages. int main(int argc, char *argv[]) { static uint32_t last_seq[CPU_SETSIZE], seq; int cpu, fd; struct sockaddr_nl sa; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; struct proc_event cn_proc; }; } rmsg; struct __attribute__((aligned(NLMSG_ALIGNTO))) { struct nlmsghdr nl_hdr; struct __attribute__((__packed__)) { struct cn_msg cn_msg; enum proc_cn_mcast_op cn_mcast; }; } smsg; fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); if (fd < 0) { perror("socket"); } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_PROC; sa.nl_pid = getpid(); if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror("bind"); } memset(&smsg, 0, sizeof(smsg)); smsg.nl_hdr.nlmsg_len = sizeof(smsg); smsg.nl_hdr.nlmsg_pid = getpid(); smsg.nl_hdr.nlmsg_type = NLMSG_DONE; smsg.cn_msg.id.idx = CN_IDX_PROC; smsg.cn_msg.id.val = CN_VAL_PROC; smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op); smsg.cn_mcast = PROC_CN_MCAST_LISTEN; if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) { perror("send"); } while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) { cpu = rmsg.cn_proc.cpu; if (cpu < 0) { continue; } seq = rmsg.cn_msg.seq; if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) { printf("out-of-order seq=%d on cpu=%d\n", seq, cpu); } last_seq[cpu] = seq; } /* NOTREACHED */ perror("recv"); return -1; } Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-24 10:05:32 -03:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00
connector/cn_proc: Performance improvements This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-19 13:18:19 -07:00