From: "Duane Griffin" <duaneg@dghda.com>
To: "linux-kernel Mailing List" <linux-kernel@vger.kernel.org>
Cc: "Nick Piggin" <npiggin@suse.de>
Subject: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning
Date: Wed, 31 Oct 2007 00:45:35 +0000 [thread overview]
Message-ID: <e9e943910710301745u429b14fj6c5a66fcbf6b0efa@mail.gmail.com> (raw)
Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start consuming 100% CPU and become unkillable. Once in
that state, SysRq-T doesn't show a stack trace for gdb, although it is
shown as running and stack traces are dumped for other tasks.
2.6.22 does not have this bug (gdb just prints '\0' as the contents,
although arguably that is also a bug, and it should instead report the
SIGBUS).
Bisection indicates the problem was introduced by:
54cb8821de07f2ffcd28c380ce9b93d5784b40d7
"mm: merge populate and nopage into fault (fixes nonlinear)"
The following program demonstrates the issue:
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
int main(int argc, char *argv[])
{
int fd;
struct stat buf;
if (argc != 2) {
fprintf(stderr, "usage: %s <filename>\n", argv[0]);
exit(1);
}
fd = open(argv[1], O_RDONLY);
fstat(fd, &buf);
int count = buf.st_size + sysconf(_SC_PAGE_SIZE);
char *file = (char *) mmap(NULL, count, PROT_READ, MAP_PRIVATE, fd, 0);
if (file == MAP_FAILED) {
fprintf(stderr, "mmap failed: %s\n", strerror(errno));
} else {
char ch;
fprintf(stderr, "using offset %d\n", (count - 1));
ch = file[count - 1];
munmap(file, count);
}
close(fd);
return 0;
}
To reproduce the bug, run it under gdb, go up a couple of frames to
the main function, then access invalid memory, for e.g. with: "print
file[4095]", or whatever offset was reported.
Cheers,
Duane.
--
"I never could learn to drink that blood and call it wine" - Bob Dylan
next reply other threads:[~2007-10-31 0:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 0:45 Duane Griffin [this message]
2007-10-31 4:19 ` Nick Piggin
2007-10-31 10:27 ` Duane Griffin
2007-10-31 15:11 ` Linus Torvalds
2007-10-31 15:19 ` Nick Piggin
2007-10-31 15:59 ` Linus Torvalds
2007-10-31 17:19 ` Duane Griffin
2007-10-31 22:55 ` Nick Piggin
2007-10-31 23:08 ` Linus Torvalds
2007-11-01 2:37 ` Nick Piggin
2007-11-01 15:14 ` Linus Torvalds
2007-11-01 15:47 ` Nick Piggin
2007-11-01 16:08 ` Linus Torvalds
2007-11-01 23:56 ` Nick Piggin
2007-11-02 1:17 ` Linus Torvalds
2007-11-02 6:30 ` Nick Piggin
2007-10-31 6:42 ` Nick Piggin
2007-10-31 6:56 ` David Miller
2007-10-31 7:41 ` Nick Piggin
2007-10-31 7:44 ` David Miller
2007-11-02 5:02 ` David Miller
2007-11-02 10:45 ` Nick Piggin
2007-11-02 15:36 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e9e943910710301745u429b14fj6c5a66fcbf6b0efa@mail.gmail.com \
--to=duaneg@dghda.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®