http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
------- Additional Comments From dgc@xxxxxxx 2007-02-05 22:48 CST -------
I've just looked at the test program provided in comment #2 and I see
there are several bugs in it.
First of all, XFS_IOC_RESVSP64 does not change the file size. hence
doing:
fd = open(xxx, O_TRUNC|O_CREAT|O_RDWR);
ioctl(fs, XFS_IOC_RESVSP64, &space);
leaves you with a zero length file. If you then try to fault a page
from the file, then you _correctly_ get a sigbus because you tried to
read beyond EOF.
You _must_ ftruncate() the file to the correct size (the range you
preallocated) before you fault any pages. The test program provided
even this if you tell it to and it is commented that it works. It works
because the file size is set correctly!
Secondly, the XFS_IOC_ALLOCSP64 case in teh test program which uses:
space.l_whence = SEEK_SET;
space.l_start = 0;
space.l_len = o;
if you read the man page for XFS_IOC_ALLOCSP64 carefully:
.... l_whence is 0, 1, or 2 to indicate that the relative offset l_start
will be measured from the start of the file. .... l_len is the size
of the section. An l_len value of zero frees up to the end of the file;
..... The l_len field is currently ignored, and should be set to zero.
The key is that last sentence - l_len is ignored and should be set to zero.
And a zero value says "truncate file to l_start".
So the effect of the test code is the equivalent of ftruncate64(fd, 0);
i.e. set the file size to zero and hence page faults occur past EOF
and the process _correctly_ gets a sigbus.
IOWs, I don't see an XFS bug in the test case provided; just user error.
Comment #3 tends to imply a different problem - a test case for that
would be helpful....
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|