1. 29 6月, 2005 1 次提交
  2. 24 6月, 2005 2 次提交
    • A
      [PATCH] Bug in error recovery in fs/buffer.c::__block_prepare_write() · 152becd2
      Anton Altaparmakov 提交于
      fs/buffer.c::__block_prepare_write() has broken error recovery.  It calls
      the get_block() callback with "create = 1" and if that succeeds it
      immediately clears buffer_new on the just allocated buffer (which has
      buffer_new set).
      
      The bug is that if an error occurs and get_block() returns != 0, we break
      from this loop and go into recovery code.  This code has this comment:
      
      /* Error case: */
      /*
       * Zero out any newly allocated blocks to avoid exposing stale
       * data.  If BH_New is set, we know that the block was newly
       * allocated in the above loop.
       */
      
      So the intent is obviously good in that it wants to clear just allocated
      and hence not zeroed buffers.  However the code recognises allocated
      buffers by checking for buffer_new being set.
      
      Unfortunately __block_prepare_write() as discussed above already cleared
      buffer_new on all allocated buffers thus no buffers will be cleared during
      error recovery and old data will be leaked.
      
      The simplest way I can see to fix this is to make the current recovery code
      work by _not_ clearing buffer_new after calling get_block() in
      __block_prepare_write().
      
      We cannot safely allow buffer_new buffers to "leak out" of
      __block_prepare_write(), thus we simply do a quick loop over the buffers
      clearing buffer_new on each of them if it is set just before returning
      "success" from __block_prepare_write().
      Signed-off-by: NAnton Altaparmakov <aia21@cantab.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      152becd2
    • O
      [PATCH] factor out common code in sys_fsync/sys_fdatasync · dfb388bf
      Oleg Nesterov 提交于
      This patch consolidates sys_fsync and sys_fdatasync.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dfb388bf
  3. 22 6月, 2005 1 次提交
  4. 17 5月, 2005 1 次提交
    • A
      [PATCH] block_read_full_page() get_block() error handling fix · c64610ba
      Andrew Morton 提交于
      If block_read_full_page() detects an error when running get_block() it will
      run SetPageError(), then it will zero out the block in pagecache and will mark
      the buffer_head uptodate.
      
      So at the end of readahead we end up with a non-uptodate pagecache page which
      is marked PageError.  But it has uptodate buffers.
      
      The pagefault code will run ClearPageError, will launch readpage a second time
      and block_read_full_page() will notice the uptodate buffers and will mark the
      page uptodate as well.  We end up with an uptodate, !PageError page full of
      zeros and the error is lost.
      
      (It seems a little odd that filemap_nopage() runs ClearPageError().  I guess
      all of this adds up to meaning that for each attempted access to the page, the
      pagefault handler will retry the I/O.  Which is good and bad.  If the app is
      ignoring SIGBUS for some reason we could get a lot of back-to-back I/O
      errors.)
      
      Fix it by not marking the pagecache buffer_head as uptodate if the attempt to
      map that buffer to a disk block failed.
      
      Credit-to: Qu Fuping <fs@ercist.iscas.ac.cn>
      
        For reporting the bug and identifying its source.
      Signed-off-by: NQu Fuping <fs@ercist.iscas.ac.cn>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c64610ba
  5. 06 5月, 2005 6 次提交
  6. 01 5月, 2005 4 次提交
  7. 17 4月, 2005 2 次提交