1. 23 8月, 2009 37 次提交
  2. 22 8月, 2009 3 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 · e3054ea7
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
        [SCSI] mpt2sas: fix config request and diag reset deadlock
        [SCSI] mpt2sas: Bump driver version 01.100.04.00
        [SCSI] mpt2sas: fix oops because drv data points to NULL on resume from hibernate
        [SCSI] mpt2sas: fix crash due to Watchdog is active while OS in standby mode
        [SCSI] mpt2sas: fix infinite loop inside config request
        [SCSI] mpt2sas: Excessive log info causes sas iounit page time out
        [SCSI] mpt2sas: Raid 10 Value is showing as Raid 1E in /va/log/messages
        [SCSI] mpt2sas: Expander fix oops saying "Already part of another port"
        [SCSI] mpt2sas: Introduced check for enclosure_handle to avoid crash
      e3054ea7
    • L
      Linux 2.6.31-rc7 · 422bef87
      Linus Torvalds 提交于
      422bef87
    • L
      Re-introduce page mapping check in mark_buffer_dirty() · 8e9d78ed
      Linus Torvalds 提交于
      In commit a8e7d49a ("Fix race in
      create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test
      for a NULL page mapping unintentionally when some of the code inside
      __set_page_dirty() was moved to the callers.
      
      That removal generally didn't matter, since a filesystem would serialize
      truncation (which clears the page mapping) against writing (which marks
      the buffer dirty), so locking at a higher level (either per-page or an
      inode at a time) should mean that the buffer page would be stable.  And
      indeed, nothing bad seemed to happen.
      
      Except it turns out that apparently reiserfs does something odd when
      under load and writing out the journal, and we have a number of bugzilla
      entries that look similar:
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13556
      	http://bugzilla.kernel.org/show_bug.cgi?id=13756
      	http://bugzilla.kernel.org/show_bug.cgi?id=13876
      
      and it looks like reiserfs depended on that check (the common theme
      seems to be "data=journal", and a journal writeback during a truncate).
      
      I suspect reiserfs should have some additional locking, but in the
      meantime this should get us back to the pre-2.6.29 behavior.
      Pattern-pointed-out-by: NRoland Kletzing <devzero@web.de>
      Cc: stable@kernel.org (2.6.29 and 2.6.30)
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8e9d78ed