1. 10 Apr, 2006 4 commits
  2. 09 Apr, 2006 31 commits
  3. 03 Apr, 2006 1 commit
  4. 02 Apr, 2006 4 commits
    • Linus Torvalds's avatar
      Update dummy snd_power_wait() function for new calling convention · 6fdb94bd
      Linus Torvalds authored
      Apparently nobody had tried to compile the ALSA CVS tree without power
      management enabled.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6fdb94bd
    • Linus Torvalds's avatar
      Merge branch 'splice' of git://brick.kernel.dk/data/git/linux-2.6-block · d6963615
      Linus Torvalds authored
      * 'splice' of git://brick.kernel.dk/data/git/linux-2.6-block:
        [PATCH] splice: fix page stealing LRU handling.
        [PATCH] splice: page stealing needs to wait_on_page_writeback()
        [PATCH] splice: export generic_splice_sendpage
        [PATCH] splice: add a SPLICE_F_MORE flag
        [PATCH] splice: add comments documenting more of the code
        [PATCH] splice: improve writeback and clean up page stealing
        [PATCH] splice: fix shadow[] filling logic
      d6963615
    • Jens Axboe's avatar
      [PATCH] splice: fix page stealing LRU handling. · 3e7ee3e7
      Jens Axboe authored
      Originally from Nick Piggin, just adapted to the newer branch.
      
      You can't check PageLRU without holding zone->lru_lock.  The page
      release code can get away with it only because the page refcount is 0 at
      that point. Also, you can't reliably remove pages from the LRU unless
      the refcount is 0. Ever.
      Signed-off-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      3e7ee3e7
    • Jens Axboe's avatar
      [PATCH] splice: page stealing needs to wait_on_page_writeback() · ad8d6f0a
      Jens Axboe authored
      Thanks to Andrew for the good explanation of why this is so. akpm writes:
      
      If a page is under writeback and we remove it from pagecache, it's still
      going to get written to disk.  But the VFS no longer knows about that page,
      nor that this page is about to modify disk blocks.
      
      So there might be scenarios in which those
      blocks-which-are-about-to-be-written-to get reused for something else.
      When writeback completes, it'll scribble on those blocks.
      
      This won't happen in ext2/ext3-style filesystems in normal mode because the
      page has buffers and try_to_release_page() will fail.
      
      But ext2 in nobh mode doesn't attach buffers at all - it just sticks the
      page in a BIO, finds some new blocks, points the BIO at those blocks and
      lets it rip.
      
      While that write IO's in flight, someone could truncate the file.  Truncate
      won't block on the writeout because the page isn't in pagecache any more.
      So truncate will the free the blocks from the file under the page's feet.
      Then something else can reallocate those blocks.  Then write data to them.
      
      Now, the original write completes, corrupting the filesystem.
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      ad8d6f0a