Re: Possible Memory Leak in KCOV Linux 4.15-rc1
On Sun, Jan 21, 2018 at 6:54 PM, Shankara Pailoorwrote: > Below is a reproducer. > > #define _GNU_SOURCE > #include > #include > #include > #include > #include > > #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) > #define KCOV_ENABLE _IO('c', 100) > #define KCOV_DISABLE _IO('c', 101) > #define COVER_SIZE (16 << 20) > > > void kcov_setup() { > unsigned long *cover; > int fd; > > fd = open("/sys/kernel/debug/kcov", O_RDWR); > if (fd == -1) > perror("open"), exit(1); > if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) > perror("ioctl"), exit(1); > cover = (unsigned long*)mmap(NULL, > COVER_SIZE * sizeof(unsigned long), > PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > if ((void*)cover == MAP_FAILED) > perror("mmap"), exit(1); > if (ioctl(fd, KCOV_ENABLE, 0)) > perror("ioctl"), exit(1); > > } > > void main() { > int i; > for (i = 0; i < 4; i++) > kcov_setup(); > sleep(10); > } Thanks! I've just mailed a fix for this: https://groups.google.com/d/msg/syzkaller/Hclbq5Elfs8/J5V_FnC4DgAJ With that patch the second KCOV_ENABLE return EBUSY. To make it clear, it won't fix your code per se, because it's a misuse of the API. You need to either call KCOV_DISABLE first, or reuse the first kcov descriptor and mapping, you can just write 0 to the first work of the mapping to reset current coverage (which should be much faster).
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
On Sun, Jan 21, 2018 at 6:54 PM, Shankara Pailoor wrote: > Below is a reproducer. > > #define _GNU_SOURCE > #include > #include > #include > #include > #include > > #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) > #define KCOV_ENABLE _IO('c', 100) > #define KCOV_DISABLE _IO('c', 101) > #define COVER_SIZE (16 << 20) > > > void kcov_setup() { > unsigned long *cover; > int fd; > > fd = open("/sys/kernel/debug/kcov", O_RDWR); > if (fd == -1) > perror("open"), exit(1); > if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) > perror("ioctl"), exit(1); > cover = (unsigned long*)mmap(NULL, > COVER_SIZE * sizeof(unsigned long), > PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > if ((void*)cover == MAP_FAILED) > perror("mmap"), exit(1); > if (ioctl(fd, KCOV_ENABLE, 0)) > perror("ioctl"), exit(1); > > } > > void main() { > int i; > for (i = 0; i < 4; i++) > kcov_setup(); > sleep(10); > } Thanks! I've just mailed a fix for this: https://groups.google.com/d/msg/syzkaller/Hclbq5Elfs8/J5V_FnC4DgAJ With that patch the second KCOV_ENABLE return EBUSY. To make it clear, it won't fix your code per se, because it's a misuse of the API. You need to either call KCOV_DISABLE first, or reuse the first kcov descriptor and mapping, you can just write 0 to the first work of the mapping to reset current coverage (which should be much faster).
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Below is a reproducer. #define _GNU_SOURCE #include #include #include #include #include #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) #define KCOV_ENABLE _IO('c', 100) #define KCOV_DISABLE _IO('c', 101) #define COVER_SIZE (16 << 20) void kcov_setup() { unsigned long *cover; int fd; fd = open("/sys/kernel/debug/kcov", O_RDWR); if (fd == -1) perror("open"), exit(1); if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) perror("ioctl"), exit(1); cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if ((void*)cover == MAP_FAILED) perror("mmap"), exit(1); if (ioctl(fd, KCOV_ENABLE, 0)) perror("ioctl"), exit(1); } void main() { int i; for (i = 0; i < 4; i++) kcov_setup(); sleep(10); } On Sun, Jan 21, 2018 at 1:11 AM, Shankara Pailoorwrote: > Hi Dmitry, > > The leaks went away when I disabled and closed the old file > descriptors before opening new ones. > > The patch you sent wouldn't work because t is not initialized at the > line. This seems to work for me > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 7594c03..1397006 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, > unsigned int cmd, > else > return -EINVAL; > t = current; > + if (!t->kcov) > + return -EBUSY; > /* Cache in task struct for performance. */ > t->kcov_size = kcov->size; > t->kcov_area = kcov->area; > > On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov wrote: >> On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor >> wrote: >>> Hi Dmitry, >>> >>> I will try and get something to you tomorrow. Just wondering, but what >>> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov >>> twice? I am looking here >>> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 >>> and I don't see where the previous struct would get freed. >> >> Good question. Perhaps we need something like: >> >> diff --git a/kernel/kcov.c b/kernel/kcov.c >> index 7594c033d98a..c76498018500 100644 >> --- a/kernel/kcov.c >> +++ b/kernel/kcov.c >> @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, >> unsigned int cmd, >> */ >> if (kcov->mode != KCOV_MODE_INIT || !kcov->area) >> return -EINVAL; >> - if (kcov->t != NULL) >> + if (kcov->t != NULL || t->kcov != NULL) >> return -EBUSY; >> if (arg == KCOV_TRACE_PC) >> kcov->mode = KCOV_MODE_TRACE_PC; >> >> >> >>> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: > Hi Dmitry, > > I added support for kcov in strace and I have been tracing a fairly > large program but after a little while, I notice that when I mmap a > new cover buffer, the call fails with ENOMEM. After killing the > program, I try and rerun and I notice that there is nearly no memory > on the system. When I do a kmemleak scan I get the following reports: > > I believe the problem occurs when I try and setup the kcov buffer > again after an exec. Instead of reusing the old file descriptor I open > kcov again within that process. In that case, I don't know what > happens to the old kcov struct. > > I don't see a maintainers list for kcov so I decided to email you > directly. Let me know what more information I can provide. Hi Shankara, Looks bad. Can you provide a reproducer? We extensively use kcov with syzkaller, but have not observed such leaks. Also I don't see anything obvious in the code. Thanks >>>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Below is a reproducer. #define _GNU_SOURCE #include #include #include #include #include #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) #define KCOV_ENABLE _IO('c', 100) #define KCOV_DISABLE _IO('c', 101) #define COVER_SIZE (16 << 20) void kcov_setup() { unsigned long *cover; int fd; fd = open("/sys/kernel/debug/kcov", O_RDWR); if (fd == -1) perror("open"), exit(1); if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE)) perror("ioctl"), exit(1); cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if ((void*)cover == MAP_FAILED) perror("mmap"), exit(1); if (ioctl(fd, KCOV_ENABLE, 0)) perror("ioctl"), exit(1); } void main() { int i; for (i = 0; i < 4; i++) kcov_setup(); sleep(10); } On Sun, Jan 21, 2018 at 1:11 AM, Shankara Pailoor wrote: > Hi Dmitry, > > The leaks went away when I disabled and closed the old file > descriptors before opening new ones. > > The patch you sent wouldn't work because t is not initialized at the > line. This seems to work for me > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 7594c03..1397006 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, > unsigned int cmd, > else > return -EINVAL; > t = current; > + if (!t->kcov) > + return -EBUSY; > /* Cache in task struct for performance. */ > t->kcov_size = kcov->size; > t->kcov_area = kcov->area; > > On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov wrote: >> On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor >> wrote: >>> Hi Dmitry, >>> >>> I will try and get something to you tomorrow. Just wondering, but what >>> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov >>> twice? I am looking here >>> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 >>> and I don't see where the previous struct would get freed. >> >> Good question. Perhaps we need something like: >> >> diff --git a/kernel/kcov.c b/kernel/kcov.c >> index 7594c033d98a..c76498018500 100644 >> --- a/kernel/kcov.c >> +++ b/kernel/kcov.c >> @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, >> unsigned int cmd, >> */ >> if (kcov->mode != KCOV_MODE_INIT || !kcov->area) >> return -EINVAL; >> - if (kcov->t != NULL) >> + if (kcov->t != NULL || t->kcov != NULL) >> return -EBUSY; >> if (arg == KCOV_TRACE_PC) >> kcov->mode = KCOV_MODE_TRACE_PC; >> >> >> >>> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: > Hi Dmitry, > > I added support for kcov in strace and I have been tracing a fairly > large program but after a little while, I notice that when I mmap a > new cover buffer, the call fails with ENOMEM. After killing the > program, I try and rerun and I notice that there is nearly no memory > on the system. When I do a kmemleak scan I get the following reports: > > I believe the problem occurs when I try and setup the kcov buffer > again after an exec. Instead of reusing the old file descriptor I open > kcov again within that process. In that case, I don't know what > happens to the old kcov struct. > > I don't see a maintainers list for kcov so I decided to email you > directly. Let me know what more information I can provide. Hi Shankara, Looks bad. Can you provide a reproducer? We extensively use kcov with syzkaller, but have not observed such leaks. Also I don't see anything obvious in the code. Thanks >>>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, The leaks went away when I disabled and closed the old file descriptors before opening new ones. The patch you sent wouldn't work because t is not initialized at the line. This seems to work for me diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c03..1397006 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, else return -EINVAL; t = current; + if (!t->kcov) + return -EBUSY; /* Cache in task struct for performance. */ t->kcov_size = kcov->size; t->kcov_area = kcov->area; On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukovwrote: > On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor wrote: >> Hi Dmitry, >> >> I will try and get something to you tomorrow. Just wondering, but what >> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov >> twice? I am looking here >> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 >> and I don't see where the previous struct would get freed. > > Good question. Perhaps we need something like: > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 7594c033d98a..c76498018500 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, > unsigned int cmd, > */ > if (kcov->mode != KCOV_MODE_INIT || !kcov->area) > return -EINVAL; > - if (kcov->t != NULL) > + if (kcov->t != NULL || t->kcov != NULL) > return -EBUSY; > if (arg == KCOV_TRACE_PC) > kcov->mode = KCOV_MODE_TRACE_PC; > > > >> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: >>> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor >>> wrote: Hi Dmitry, I added support for kcov in strace and I have been tracing a fairly large program but after a little while, I notice that when I mmap a new cover buffer, the call fails with ENOMEM. After killing the program, I try and rerun and I notice that there is nearly no memory on the system. When I do a kmemleak scan I get the following reports: I believe the problem occurs when I try and setup the kcov buffer again after an exec. Instead of reusing the old file descriptor I open kcov again within that process. In that case, I don't know what happens to the old kcov struct. I don't see a maintainers list for kcov so I decided to email you directly. Let me know what more information I can provide. >>> >>> >>> Hi Shankara, >>> >>> Looks bad. Can you provide a reproducer? >>> We extensively use kcov with syzkaller, but have not observed such >>> leaks. Also I don't see anything obvious in the code. >>> >>> Thanks >>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, The leaks went away when I disabled and closed the old file descriptors before opening new ones. The patch you sent wouldn't work because t is not initialized at the line. This seems to work for me diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c03..1397006 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, else return -EINVAL; t = current; + if (!t->kcov) + return -EBUSY; /* Cache in task struct for performance. */ t->kcov_size = kcov->size; t->kcov_area = kcov->area; On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov wrote: > On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor wrote: >> Hi Dmitry, >> >> I will try and get something to you tomorrow. Just wondering, but what >> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov >> twice? I am looking here >> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 >> and I don't see where the previous struct would get freed. > > Good question. Perhaps we need something like: > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 7594c033d98a..c76498018500 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, > unsigned int cmd, > */ > if (kcov->mode != KCOV_MODE_INIT || !kcov->area) > return -EINVAL; > - if (kcov->t != NULL) > + if (kcov->t != NULL || t->kcov != NULL) > return -EBUSY; > if (arg == KCOV_TRACE_PC) > kcov->mode = KCOV_MODE_TRACE_PC; > > > >> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: >>> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor >>> wrote: Hi Dmitry, I added support for kcov in strace and I have been tracing a fairly large program but after a little while, I notice that when I mmap a new cover buffer, the call fails with ENOMEM. After killing the program, I try and rerun and I notice that there is nearly no memory on the system. When I do a kmemleak scan I get the following reports: I believe the problem occurs when I try and setup the kcov buffer again after an exec. Instead of reusing the old file descriptor I open kcov again within that process. In that case, I don't know what happens to the old kcov struct. I don't see a maintainers list for kcov so I decided to email you directly. Let me know what more information I can provide. >>> >>> >>> Hi Shankara, >>> >>> Looks bad. Can you provide a reproducer? >>> We extensively use kcov with syzkaller, but have not observed such >>> leaks. Also I don't see anything obvious in the code. >>> >>> Thanks >>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoorwrote: > Hi Dmitry, > > I will try and get something to you tomorrow. Just wondering, but what > happens to the old struct kcov if a task opens /sys/kernel/debug/kcov > twice? I am looking here > https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 > and I don't see where the previous struct would get freed. Good question. Perhaps we need something like: diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c033d98a..c76498018500 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, */ if (kcov->mode != KCOV_MODE_INIT || !kcov->area) return -EINVAL; - if (kcov->t != NULL) + if (kcov->t != NULL || t->kcov != NULL) return -EBUSY; if (arg == KCOV_TRACE_PC) kcov->mode = KCOV_MODE_TRACE_PC; > On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: >> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor >> wrote: >>> Hi Dmitry, >>> >>> I added support for kcov in strace and I have been tracing a fairly >>> large program but after a little while, I notice that when I mmap a >>> new cover buffer, the call fails with ENOMEM. After killing the >>> program, I try and rerun and I notice that there is nearly no memory >>> on the system. When I do a kmemleak scan I get the following reports: >>> >>> I believe the problem occurs when I try and setup the kcov buffer >>> again after an exec. Instead of reusing the old file descriptor I open >>> kcov again within that process. In that case, I don't know what >>> happens to the old kcov struct. >>> >>> I don't see a maintainers list for kcov so I decided to email you >>> directly. Let me know what more information I can provide. >> >> >> Hi Shankara, >> >> Looks bad. Can you provide a reproducer? >> We extensively use kcov with syzkaller, but have not observed such >> leaks. Also I don't see anything obvious in the code. >> >> Thanks >
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor wrote: > Hi Dmitry, > > I will try and get something to you tomorrow. Just wondering, but what > happens to the old struct kcov if a task opens /sys/kernel/debug/kcov > twice? I am looking here > https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 > and I don't see where the previous struct would get freed. Good question. Perhaps we need something like: diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c033d98a..c76498018500 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, */ if (kcov->mode != KCOV_MODE_INIT || !kcov->area) return -EINVAL; - if (kcov->t != NULL) + if (kcov->t != NULL || t->kcov != NULL) return -EBUSY; if (arg == KCOV_TRACE_PC) kcov->mode = KCOV_MODE_TRACE_PC; > On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: >> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor >> wrote: >>> Hi Dmitry, >>> >>> I added support for kcov in strace and I have been tracing a fairly >>> large program but after a little while, I notice that when I mmap a >>> new cover buffer, the call fails with ENOMEM. After killing the >>> program, I try and rerun and I notice that there is nearly no memory >>> on the system. When I do a kmemleak scan I get the following reports: >>> >>> I believe the problem occurs when I try and setup the kcov buffer >>> again after an exec. Instead of reusing the old file descriptor I open >>> kcov again within that process. In that case, I don't know what >>> happens to the old kcov struct. >>> >>> I don't see a maintainers list for kcov so I decided to email you >>> directly. Let me know what more information I can provide. >> >> >> Hi Shankara, >> >> Looks bad. Can you provide a reproducer? >> We extensively use kcov with syzkaller, but have not observed such >> leaks. Also I don't see anything obvious in the code. >> >> Thanks >
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, I will try and get something to you tomorrow. Just wondering, but what happens to the old struct kcov if a task opens /sys/kernel/debug/kcov twice? I am looking here https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 and I don't see where the previous struct would get freed. Regards, Shankara On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukovwrote: > On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: >> Hi Dmitry, >> >> I added support for kcov in strace and I have been tracing a fairly >> large program but after a little while, I notice that when I mmap a >> new cover buffer, the call fails with ENOMEM. After killing the >> program, I try and rerun and I notice that there is nearly no memory >> on the system. When I do a kmemleak scan I get the following reports: >> >> I believe the problem occurs when I try and setup the kcov buffer >> again after an exec. Instead of reusing the old file descriptor I open >> kcov again within that process. In that case, I don't know what >> happens to the old kcov struct. >> >> I don't see a maintainers list for kcov so I decided to email you >> directly. Let me know what more information I can provide. > > > Hi Shankara, > > Looks bad. Can you provide a reproducer? > We extensively use kcov with syzkaller, but have not observed such > leaks. Also I don't see anything obvious in the code. > > Thanks
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, I will try and get something to you tomorrow. Just wondering, but what happens to the old struct kcov if a task opens /sys/kernel/debug/kcov twice? I am looking here https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 and I don't see where the previous struct would get freed. Regards, Shankara On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: > On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: >> Hi Dmitry, >> >> I added support for kcov in strace and I have been tracing a fairly >> large program but after a little while, I notice that when I mmap a >> new cover buffer, the call fails with ENOMEM. After killing the >> program, I try and rerun and I notice that there is nearly no memory >> on the system. When I do a kmemleak scan I get the following reports: >> >> I believe the problem occurs when I try and setup the kcov buffer >> again after an exec. Instead of reusing the old file descriptor I open >> kcov again within that process. In that case, I don't know what >> happens to the old kcov struct. >> >> I don't see a maintainers list for kcov so I decided to email you >> directly. Let me know what more information I can provide. > > > Hi Shankara, > > Looks bad. Can you provide a reproducer? > We extensively use kcov with syzkaller, but have not observed such > leaks. Also I don't see anything obvious in the code. > > Thanks
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoorwrote: > Hi Dmitry, > > I added support for kcov in strace and I have been tracing a fairly > large program but after a little while, I notice that when I mmap a > new cover buffer, the call fails with ENOMEM. After killing the > program, I try and rerun and I notice that there is nearly no memory > on the system. When I do a kmemleak scan I get the following reports: > > I believe the problem occurs when I try and setup the kcov buffer > again after an exec. Instead of reusing the old file descriptor I open > kcov again within that process. In that case, I don't know what > happens to the old kcov struct. > > I don't see a maintainers list for kcov so I decided to email you > directly. Let me know what more information I can provide. Hi Shankara, Looks bad. Can you provide a reproducer? We extensively use kcov with syzkaller, but have not observed such leaks. Also I don't see anything obvious in the code. Thanks
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: > Hi Dmitry, > > I added support for kcov in strace and I have been tracing a fairly > large program but after a little while, I notice that when I mmap a > new cover buffer, the call fails with ENOMEM. After killing the > program, I try and rerun and I notice that there is nearly no memory > on the system. When I do a kmemleak scan I get the following reports: > > I believe the problem occurs when I try and setup the kcov buffer > again after an exec. Instead of reusing the old file descriptor I open > kcov again within that process. In that case, I don't know what > happens to the old kcov struct. > > I don't see a maintainers list for kcov so I decided to email you > directly. Let me know what more information I can provide. Hi Shankara, Looks bad. Can you provide a reproducer? We extensively use kcov with syzkaller, but have not observed such leaks. Also I don't see anything obvious in the code. Thanks