mmap successed but SIGBUS generated on access

mmap successed but SIGBUS generated on access

[Andrew V. Samoilov]

Hi!

I have bad CD-R with a some number of unreadable files.

Then user-space program use mmap system it returns ok but any
attempt to access a memory pointed by this system call finishes 
with SIGBUS. So Midnight Commander internal file viewer faults.

This error is 100 % reproduceable at 2.2.19 and 2.4.2 kernels.

Is there any way to detect such problem in user-space without signal handlers ?

Lines from /var/log/messages:

Sep 19 12:20:05 sav kernel: attempt to access beyond end of device
Sep 19 12:20:05 sav kernel: 16:00: rw=0, want=657860, limit=386954
Sep 19 12:20:05 sav kernel: dev 16:00 blksize=2048 blocknr=328929 sector=1315716 size=2048 
count=1

Test program:

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <sys/mman.h>
#include <errno.h>

int main (int argc, char ** argv) {
    int fd;
    struct stat st;
    void * p;
    while (--argc) {
	argv++;
	if (stat (*argv, &st)) {
	    fprintf (stderr, "stat (%s) -- %s\n", *argv, strerror (errno));
	    continue;
	}
	if ((fd = open (*argv, O_RDONLY)) == -1) {
	    fprintf (stderr, "open (%s) -- %s\n", *argv, strerror (errno));
	    continue;
	}
	fprintf (stderr, "mmap (%d) called...\n", st.st_size);
	if ((p = mmap (0, st.st_size, PROT_READ, MAP_SHARED, fd, 0)) == (void*) -1) {
	    fprintf (stderr, "mmap (%s) -- %s\n", *argv, strerror (errno));
	    close (fd);
	    continue;
	}
	fputs ("mmap done...\n", stderr);
	write (2, p, st.st_size);
	fputs ("munmap called...\n", stderr);
	if (munmap (p, st.st_size) == -1) {
	    fprintf (stderr, "munmap (%s) -- %s\n", *argv, strerror (errno));
	}
	fputs ("munmap done...\n", stderr);
	close (fd);
    }
}

This program output:

mmap (8) called...
mmap done...
Bus error


--
Regards,
Andrew.

____________________________________________

Играй в шахматы в Интернет на InstantChess.com! 

Play chess on InstantChess.com !

www.instantchess.com

Re: mmap successed but SIGBUS generated on access

[Jamie Lokier]

Andrew V. Samoilov wrote:
> I have bad CD-R with a some number of unreadable files.
> 
> Then user-space program use mmap system it returns ok but any
> attempt to access a memory pointed by this system call finishes 
> with SIGBUS. So Midnight Commander internal file viewer faults.

You can get the same problem even without read errors with some
configurations of NFS.  (root mmaps a file owned by someone else, but
cannot read the file due to `root_squash' on server).

> This error is 100 % reproduceable at 2.2.19 and 2.4.2 kernels.

It's not an error, it's standard behaviour.

> Is there any way to detect such problem in user-space without signal
> handlers ?

I don't think there is any way without a signal handler.

It is possible to do something useful with a signal handler sometimes.
For example, you can mmap() a zero page into the offending page once
you've got the fault address, or read() a zero page if you did
MAP_PRIVATE (this produces fewer VMAs), set a flag, and let the program
continue until it checks the flag and aborts the parsing or whatever
operation it's doing.

Unfortunately I don't think the signal handler's si_errno is set
properly to indicate the error.  So another thing to try is read() of
the offending page, to get a useful error code.  (And if the read
succeeds, that's ok because you did it at the correct address so the
program can proceed anyway).

Fwiw, unfortunately not all versions of the kernel, or all
architectures, set si_addr properly for SIGBUS.

enjoy,
-- Jamie

Re: mmap successed but SIGBUS generated on access

[Jamie Lokier]

Andrew V. Samoilov wrote:
>> It is possible to do something useful with a signal handler sometimes.
>> For example, you can mmap() a zero page into the offending page once
>> you've got the fault address, or read() a zero page if you did
>> MAP_PRIVATE (this produces fewer VMAs), set a flag, and let the program
>> continue until it checks the flag and aborts the parsing or whatever
>> operation it's doing.
> 
> So, I must read all of the mapped area and even this
> does not saves me of faulting next time if somebody
> change file permission. Does I understand this situation
> right?

If you use MAP_PRIVATE, then after your process modifies the mapped
page, you have the data for sure.  This includes calling read() over a
page that raises a SIGBUS -- the page is "modified" by this operation,
although the contents should hopefully be the correct file contents if
read() succeeds.  Any subsequent change to the file, including
permission changes and data changes, won't affect the data you have in
memory.

If you do not modify the pages (and usually, for efficiency, you
wouldn't), then yes a change in file permissions can mean you can read
data one second and will get a SIGBUS later.  You're not guaranteed to
get a SIGBUS, but you might get one -- it depends on whether the OS
decides to reclaim the page's memory temporarily in between.

If you want to do something like an Editor's "Load File" operation, then
you need to read the whole file.  Either call read(), or call mmap() and
then modify every page by reading one byte from each page and writing
the same value back to the same place.  read() is probably quicker, but
I've never checked.

-- Jamie

Re: mmap successed but SIGBUS generated on access

[Andrew V. Samoilov]

Hi, Jamie!

Thanks for an answer!

>> I have bad CD-R with a some number of unreadable
files.
>> 
>> Then user-space program use mmap system it returns ok
but any
>> attempt to access a memory pointed by this system
call finishes 
>> with SIGBUS. So Midnight Commander internal file
viewer faults.
>
>You can get the same problem even without read errors
with some
>configurations of NFS.  (root mmaps a file owned by
someone else, but
>cannot read the file due to `root_squash' on server).
>
>It's not an error, it's standard behaviour.

Well.

>> Is there any way to detect such problem in user-space
without signal
>> handlers ?
>
>I don't think there is any way without a signal
handler.
>
>It is possible to do something useful with a signal
handler sometimes.
>For example, you can mmap() a zero page into the
offending page once
>you've got the fault address, or read() a zero page if
you did
>MAP_PRIVATE (this produces fewer VMAs), set a flag, and
let the program
>continue until it checks the flag and aborts the
parsing or whatever
>operation it's doing.

So, I must read all of the mapped area and even this
does not saves me of faulting next time if somebody
change file permission. Does I understand this situation
right?

>Unfortunately I don't think the signal handler's
si_errno is set
>properly to indicate the error.  So another thing to
try is read() of
>the offending page, to get a useful error code.  (And
if the read
>succeeds, that's ok because you did it at the correct
address so the
>program can proceed anyway).
>
>Fwiw, unfortunately not all versions of the kernel, or
all
>architectures, set si_addr properly for SIGBUS.

It's pity. But thanks again.

--
Regards,
Andrew.

____________________________________________

Играй в шахматы в Интернет на InstantChess.com! 

Play chess on InstantChess.com !

www.instantchess.com