Re: [uml-devel] Re: bug in COW? - Re: [uml-user] uml 2.6.0-test9 crash

[Lynn Kerby <lfk@kerbit.net>]

On 2003.11.29 18:29 roland wrote:
>hi,
>i have 2.6.0-test11-um running - as expected the error is still there.
>i compiled a debug version and attached a debugger to the "hanging" uml-process:
>
>linux:/uml/suse9 # gdb linux-2.6.0-test11-um-debug 2234
>GNU gdb 5.3.92
>Copyright 2003 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you are
>welcome to change it and/or distribute copies of it under certain conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB.  Type "show warranty" for details.
>This GDB was configured as "i586-suse-linux"...
>Attaching to program: /uml/suse9/linux-2.6.0-test11-um-debug, process 2234
>0xa0002091 in munmap ()
>(gdb) cont
>Continuing.
>
>Program received signal SIGSEGV, Segmentation fault.
>0xa002a80b in cowify_req (req=0xa02236e4, dev=0xa022ab40)
>    at arch/um/drivers/ubd_kern.c:820
>820     arch/um/drivers/ubd_kern.c: No such file or directory.  <- ???
>        in arch/um/drivers/ubd_kern.c
>(gdb) cont
>Continuing.
>
>Program received signal SIGSEGV, Segmentation fault.
>0xa002a80b in cowify_req (req=0xa02236e4, dev=0xa022ab40)
>    at arch/um/drivers/ubd_kern.c:820
>820     in arch/um/drivers/ubd_kern.c
>(gdb) cont
>Continuing.
>
>Program received signal SIGSEGV, Segmentation fault.
>0xa002a80b in cowify_req (req=0xa02236e4, dev=0xa022ab40)
>    at arch/um/drivers/ubd_kern.c:820
>820     in arch/um/drivers/ubd_kern.c
>(gdb) 
>
>
>so my speculation seems affirmed, that the bug is "somewhere inside COW".
>
>here is the appropriate code snippet from ubd_kern.c :
>
>
>    790 void cowify_req(struct io_thread_req *req, struct ubd *dev)
>    791 {
>    792         int i, update_bitmap, sector = req->offset >> 9;
>    793
>    794         if(req->length > (sizeof(req->sector_mask) * 8) << 9)
>    795                 panic("Operation too long");
>    796         if(req->op == UBD_READ) {
>    797                 for(i = 0; i < req->length >> 9; i++){
>    798                         if(ubd_test_bit(sector + i, (unsigned char *)
>    799                                         dev->cow.bitmap)){
>    800                                 ubd_set_bit(i, (unsigned char *)
>    801                                             &req->sector_mask);
>    802                         }
>    803                 }
>    804         }
>    805         else {
>    806                 update_bitmap = 0;
>    807                 for(i = 0; i < req->length >> 9; i++){
>    808                         ubd_set_bit(i, (unsigned char *)
>    809                                     &req->sector_mask);
>    810                         if(!ubd_test_bit(sector + i, (unsigned char *)
>    811                                          dev->cow.bitmap))
>    812                                 update_bitmap = 1;
>    813                         ubd_set_bit(sector + i, (unsigned char *)
>    814                                     dev->cow.bitmap);
>    815                 }
>    816                 if(update_bitmap){
>    817                         req->cow_offset = sector / (sizeof(unsigned long) * 8);
>    818                         req->bitmap_words[0] =
>    819                                 dev->cow.bitmap[req->cow_offset];
>    820                         req->bitmap_words[1] =
>    821                                 dev->cow.bitmap[req->cow_offset + 1];
>    822                         req->cow_offset *= sizeof(unsigned long);
>    823                         req->cow_offset += dev->cow.bitmap_offset;
>    824                 }
>    825         }
>    826 }
>
>
>sorry, i have no real experience in debugging with gdb, nor am i a good c programmer.
>does anybody have a clue whats going wrong here ?
>
>regards
>roland

Yes, this is a long standing bug in COW.  A crash occurs when attempting to update
the bitmap for writes out near the end of certain sized disk images.  The attempt
 to change the bitmap at req->cow_offset+1 can be out of bounds.

I'm running a RH kernel that is incompatible with any available skas patch so I'm not
actively using UML at the moment and have no idea what the status of this bug is.  I
submitted a patch many months ago that I believe fixes the problem with no significant
side effects.  I thought it - or something close - was integrated into the base long ago.
A little searching through the list archives from early March or a search through the
bug lists should get you a little history on the problem and some suggested solutions.
-- 
Lynn Kerby <mailto:lfk@kerbit.net>


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel