home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8164 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.1 KB
  1. Path: sparky!uunet!gatech!darwin.sura.net!dtix!mimsy!ra!tantalus!eric
  2. From: eric@tantalus.dell.com (Eric Youngdale)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Buffer corruption problems.
  5. Message-ID: <3341@ra.nrl.navy.mil>
  6. Date: 13 Aug 92 22:43:20 GMT
  7. References: <16078@ucdavis.ucdavis.edu> <1992Aug13.163854.21617@midway.uchicago.edu> <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu>
  8. Sender: usenet@ra.nrl.navy.mil
  9. Organization: Naval Research Laboratory
  10. Lines: 46
  11.  
  12. In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
  13. >...I believe there is a bug in Linux that has the following behavior:
  14. >
  15. >-  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
  16. >   so that what your app ends up with is some _other_ 1024KB chunk
  17. >   (apparently from the same file)
  18. >
  19. >-  occurs only during very heavy disk access, such as megabytes accessed
  20. >   continually
  21.  
  22.     You did not specify how many processes were doing the heavy disk
  23. access.  If it is just one, then the problem could be localized to certain
  24. areas, if you need more than one, then the problem probably lies somewhere
  25. else. 
  26.  
  27.     That being said, this sounds like a race to me.  I started to browse
  28. the kernel sources, and I did spot one thing.  This is a bit of a stab in the
  29. dark, but it would appear as if this is a bug which *might* be responsible for
  30. the error you are seeing.  Try the following, and see what happens.  I make no
  31. warranty, and I have not tried this.  You might even want to wait for it to be
  32. blessed by Linus.
  33.  
  34.     It appears as if interrupts are re-enabled before we lock the
  35. request queue entry by setting the device id field.  My guess is that this bug
  36. will only raise it's ugly head if there is more than one process trying to read
  37. the disk.
  38.  
  39. -Eric
  40.  
  41. In linux/kernel/blk_drv/ll_rw_blk.c (make_request):
  42. Old:
  43.     found:    sti();
  44.     /* fill up the request-info, and add it to the queue */
  45.         req->dev = bh->b_dev;
  46.         req->cmd = rw;
  47.     
  48. New:
  49.  
  50.     found:
  51.     /* fill up the request-info, and add it to the queue */
  52.         req->dev = bh->b_dev;
  53.         sti();
  54.         req->cmd = rw;
  55. --
  56. Eric Youngdale
  57. eric@tantalus.nrl.navy.mil
  58.