1. 10 4月, 2006 35 次提交
  2. 03 4月, 2006 5 次提交
    • L
      Linux v2.6.17-rc1 · 6246b612
      Linus Torvalds 提交于
      Close of the merge window..
      6246b612
    • L
      Update dummy snd_power_wait() function for new calling convention · 6fdb94bd
      Linus Torvalds 提交于
      Apparently nobody had tried to compile the ALSA CVS tree without power
      management enabled.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6fdb94bd
    • L
      Merge branch 'splice' of git://brick.kernel.dk/data/git/linux-2.6-block · d6963615
      Linus Torvalds 提交于
      * '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
    • J
      [PATCH] splice: fix page stealing LRU handling. · 3e7ee3e7
      Jens Axboe 提交于
      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: NNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: NJens Axboe <axboe@suse.de>
      3e7ee3e7
    • J
      [PATCH] splice: page stealing needs to wait_on_page_writeback() · ad8d6f0a
      Jens Axboe 提交于
      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: NJens Axboe <axboe@suse.de>
      ad8d6f0a