Re: [Pvfs2-developers] read buffer bug

2006-12-01 Thread Sam Lang


Its in CVS now.  Thanks Murali for the fix, and Phil for the report.

-sam

On Nov 30, 2006, at 10:15 AM, Phil Carns wrote:


Thanks for the quick fix!

Murali Vilayannur wrote:

Hi guys,
I am really sorry about this. I am surprised we did not catch this
earlier. This was basically introduced by the file.c/bufmap.c  
cleanups

that I had done a while back.
Attached patch should fix this error.
thanks for the testcase, Phil!
Murali
On 11/29/06, Phil Carns [EMAIL PROTECTED] wrote:

I ran into a problem today with the 2.6.0 release.  This happened to
show up in the read04 LTP test, but not reliably.  I have attached a
test program that I think does trigger it reliably, though.

When run on ext3:

/home/pcarns ./testme /tmp/foo.txt
read returned: 7, test_buf: hello   world

When run on pvfs2:

/home/pcarns ./testme /mnt/pvfs2/foo.txt
read returned: 7, test_buf: hello

(or sometimes you might get garbage after the hello)

The test program creates a string buffer with goodbye world  
stored in
it.  It then reads the string hello   out of a file into the  
beginning
of that buffer.   The result should be that the final resulting  
string

is hello  world.

The trick that makes this fail is asking to read more than 7  
bytes from

the file.

In this particular test program, we attempt to do a read of 255  
bytes.
There are only 7 bytes in the file, though.  The return code from  
read
accurately reflects this.  However, rather than just fill in the  
first 7

bytes of the buffer, it looks like PVFS2 is overwriting the full 255
bytes.  What ends up in those trailing 248 bytes is somewhat random.

I suspect that somewhere in the kernel module there is a  
copy_to_user()
call that is copying the number of bytes requested by the read  
rather

than the number of bytes returned by the servers.

-Phil


___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers






___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers



___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers


[Pvfs2-developers] read buffer bug

2006-11-29 Thread Phil Carns
I ran into a problem today with the 2.6.0 release.  This happened to 
show up in the read04 LTP test, but not reliably.  I have attached a 
test program that I think does trigger it reliably, though.


When run on ext3:

/home/pcarns ./testme /tmp/foo.txt
read returned: 7, test_buf: hello   world

When run on pvfs2:

/home/pcarns ./testme /mnt/pvfs2/foo.txt
read returned: 7, test_buf: hello

(or sometimes you might get garbage after the hello)

The test program creates a string buffer with goodbye world stored in 
it.  It then reads the string hello   out of a file into the beginning 
of that buffer.   The result should be that the final resulting string 
is hello  world.


The trick that makes this fail is asking to read more than 7 bytes from 
the file.


In this particular test program, we attempt to do a read of 255 bytes. 
There are only 7 bytes in the file, though.  The return code from read 
accurately reflects this.  However, rather than just fill in the first 7 
bytes of the buffer, it looks like PVFS2 is overwriting the full 255 
bytes.  What ends up in those trailing 248 bytes is somewhat random.


I suspect that somewhere in the kernel module there is a copy_to_user() 
call that is copying the number of bytes requested by the read rather 
than the number of bytes returned by the servers.


-Phil
#include stdio.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include string.h

int main(int argc, char **argv)	 
{
   int fd = 0;
   int ret = 0;
   char test_string[] = hello  ;
   char test_buf[256];

   if(argc != 2)
   {
  fprintf(stderr, Usage: %s filename\n, argv[0]);
  return(-1);
   }

   fd = open(argv[1], O_RDWR|O_CREAT|O_TRUNC, (S_IRUSR | S_IWUSR));
   if(fd  0)
   {
  perror(open);
  return(-1);
   }

   ret = write(fd, test_string, strlen(test_string));
   if(ret != strlen(test_string))
   {
  fprintf(stderr, Error: write failed.\n);
  return(-1);
   }

   /* put some garbage in the buffer so we can detect if something goes wrong */
   strcpy(test_buf, goodbye world);
   
   lseek(fd, 0, SEEK_SET);
   ret = read(fd, test_buf, 255);
   
   printf(read returned: %d, test_buf: %s\n, ret, test_buf);

   close(fd);

   return(0);
}
___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers


Re: [Pvfs2-developers] read buffer bug

2006-11-29 Thread Murali Vilayannur

Hi guys,
I am really sorry about this. I am surprised we did not catch this
earlier. This was basically introduced by the file.c/bufmap.c cleanups
that I had done a while back.
Attached patch should fix this error.
thanks for the testcase, Phil!
Murali

On 11/29/06, Phil Carns [EMAIL PROTECTED] wrote:

I ran into a problem today with the 2.6.0 release.  This happened to
show up in the read04 LTP test, but not reliably.  I have attached a
test program that I think does trigger it reliably, though.

When run on ext3:

/home/pcarns ./testme /tmp/foo.txt
read returned: 7, test_buf: hello   world

When run on pvfs2:

/home/pcarns ./testme /mnt/pvfs2/foo.txt
read returned: 7, test_buf: hello

(or sometimes you might get garbage after the hello)

The test program creates a string buffer with goodbye world stored in
it.  It then reads the string hello   out of a file into the beginning
of that buffer.   The result should be that the final resulting string
is hello  world.

The trick that makes this fail is asking to read more than 7 bytes from
the file.

In this particular test program, we attempt to do a read of 255 bytes.
There are only 7 bytes in the file, though.  The return code from read
accurately reflects this.  However, rather than just fill in the first 7
bytes of the buffer, it looks like PVFS2 is overwriting the full 255
bytes.  What ends up in those trailing 248 bytes is somewhat random.

I suspect that somewhere in the kernel module there is a copy_to_user()
call that is copying the number of bytes requested by the read rather
than the number of bytes returned by the servers.

-Phil


___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers






err
Description: Binary data
___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers