All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sébastien Paumier" <sebastien.paumier@univ-mlv.fr>
To: linux-kernel@vger.kernel.org
Subject: mmap
Date: Fri, 02 Dec 2011 13:20:05 +0100	[thread overview]
Message-ID: <4ED8C275.7020907@univ-mlv.fr> (raw)

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

Hi,
I have a question about mmap's behavior when one tries to map a file asking for 
a length greater than the actual file size. When I run the attached code on a 
100 bytes file, I have the following output:

(... file content followed by zeros...)
n=4096
write: Bad address

So, it seems that the actual memory area provided by mmap is one page large and 
not the requested length of filesize+10000. I guess that 'write' writes less 
than requested because it was interrupted by the SIGBUS signal. And my question is:

shouldn't mmap either complain about the requested length or provide an 
accessible area of the requested length, instead of silently failing ?

Best regards,
Sébastien Paumier

[-- Attachment #2: mmap.c --]
[-- Type: text/x-csrc, Size: 884 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <signal.h>
#include <time.h>
#include <errno.h>

int main(int argc, char* argv[]){
if(argc != 2) {
	fprintf(stderr,"Usage: %s <file>\n",argv[0]);
	exit(1);
}
int fd = open(argv[argc-1],O_RDONLY);
if (fd==-1) {
	perror("open");
	return 1;
}
struct stat status;
if(-1 == fstat(fd,&status)){
	perror("fstat");
	return 1;
}
char* mem=(char*) mmap(NULL, status.st_size+10000, PROT_READ, MAP_PRIVATE,fd,0);
if(mem == MAP_FAILED){
	perror("mmap");
	return 1;
}
int n;
if ( -1 == (n=write(1,mem, status.st_size+10000))) {
	perror("write");
	return 1;
}
printf("\nn=%d\n",n);
if( -1 == (n=write(1,mem+n, status.st_size+10000-n))) {
	perror("write");
	return 1;
}
printf("\nn=%d\n",n);
return 0;
}

             reply	other threads:[~2011-12-02 12:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-02 12:20 Sébastien Paumier [this message]
2011-12-02 14:45 ` mmap Eric Dumazet
  -- strict thread matches above, loose matches on Subject: below --
2012-08-23 13:06 mmap Christophe Hauser
2012-08-23 14:18 ` mmap Mulyadi Santosa
2006-10-26  0:48 mmap Sudharsan Rangarajan
2006-10-26  1:02 ` mmap Ian McDonald
2006-10-26  1:02 ` mmap Hagen Paul Pfeifer
2006-01-05 10:03 mmap Fillod Stephane
2006-01-05  6:16 mmap Brett McNerney
2001-07-02 14:00 mmap mdaljeet
2001-07-03 17:47 ` mmap Jens Axboe
2001-05-15 10:08 mmap mdaljeet
2001-05-15  6:47 mmap mdaljeet
2001-05-15  7:33 ` mmap Gerd Knorr
2001-05-15  9:42 ` mmap Alan Cox

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=4ED8C275.7020907@univ-mlv.fr \
    --to=sebastien.paumier@univ-mlv.fr \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.