From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] check mapped ranges on sysfs resource files (for 2.6.27)
Date: Thu, 2 Oct 2008 16:51:28 -0700 [thread overview]
Message-ID: <200810021651.29081.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0810021630100.3341@nehalem.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
On Thursday, October 2, 2008 4:30 pm Linus Torvalds wrote:
> On Thu, 2 Oct 2008, Jesse Barnes wrote:
> > + unsigned long map_len = vma->vm_end - vma->vm_start;
> > + unsigned long map_offset = vma->vm_pgoff << PAGE_SHIFT;
>
> This seems broken for big vm_pgoff values, where that shift will
> potentially overflow, no?
Ah yes, exactly what we want to be checking for in fact.
> Also, it strikes me that we don't seem to check that the resource start is
> page-aligned. We just do
>
> vma->vm_pgoff += start >> PAGE_SHIFT;
>
> without checking if we just dropped low bits from 'start'.
Hm, yeah looks like that's a long standing issue...
> Of course, if the length of the resource is bigger than a page, I guess
> the resource is guaranteed to be at least page-aligned, so maybe the
> length check - if it was correct - would be sufficient.
>
> Anyway, it would be *much* better to do the length check in pages rather
> than in bytes, to avoid the overflow condition.
>
> Can somebody test if something like this works? It also prints the actual
> name of the device, not just a random BAR number (but it will print
> everyting in PFN's, I hate potentially losing information).
Yeah, looks much better. I was using this silly test program to see if the
earlier code worked. Just pass in both valid and invalid sizes.
Jesse
[-- Attachment #2: sysfs-mmap-test.c --]
[-- Type: text/x-csrc, Size: 825 bytes --]
#include <errno.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
int main(int argc, char *argv[])
{
size_t len;
int fd;
void *ptr;
if (argc != 3) {
fprintf(stderr, "usage: %s <file> <mapsize>\n",
argv[0]);
return -1;
}
len = atoi(argv[2]);
fd = open(argv[1], O_RDONLY);
if (fd == -1) {
fprintf(stderr, "open failed: %s\n", strerror(errno));
return errno;
}
ptr = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
if (ptr == MAP_FAILED) {
fprintf(stderr, "mmap failed: %s\n", strerror(errno));
return errno;
}
printf("mmap of %s with size %zd succeeded\n", argv[1], len);
munmap(ptr, len); /* ignore any errors, we don't care */
close(fd);
return 0;
}
next prev parent reply other threads:[~2008-10-02 23:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-02 22:34 Jesse Barnes
2008-10-02 23:30 ` Linus Torvalds
2008-10-02 23:51 ` Jesse Barnes [this message]
2008-10-03 1:58 ` Linus Torvalds
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=200810021651.29081.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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®