1. 14 Jan, 2003 9 commits
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/net-2.5 · b615f582
      Linus Torvalds authored
      into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
      b615f582
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/sparc-2.5 · 6f3d20c9
      Linus Torvalds authored
      into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
      6f3d20c9
    • Andrew Morton's avatar
      [PATCH] remove has_stopped_jobs() · 84e7eb7a
      Andrew Morton authored
      patch from Bill Irwin
      
      has_stopped_jobs() is completely unused. This patch removes
      has_stopped_jobs() and renames __has_stopped_jobs() to has_stopped_jobs().
      84e7eb7a
    • Andrew Morton's avatar
      [PATCH] Create a per-cpu proces counter for /proc reporting · e5b36baf
      Andrew Morton authored
      proc_fill_super() simply wants a count of processes, not threads.
      This creates a per-cpu counter for it to use to determine that.
      e5b36baf
    • Andrew Morton's avatar
      [PATCH] Use for_each_task_pid() in do_SAK() · 82184668
      Andrew Morton authored
      Patch from Bill Irwin.
      
      __do_SAK() simply wants to kill off processes using a given tty.  This
      converts it to use for_each_task_pid().
      82184668
    • Andrew Morton's avatar
      [PATCH] hugetlbfs: don't implement read/write file_ops · 1cf1d22a
      Andrew Morton authored
      From Rohit Seth.
      
      We're currently disabling read() and write() against hugetlbfs files via the
      address_space ops.  But that's a bit awkward, and results in reads and writes
      instantiating useless, non-uptodate 4k pagecache against the inodes.
      
      The patch removes the read, write and sendfile file_operations entries.  So
      the caller will get their -EINVAL without us ever having to go to the
      pagecache layer.
      1cf1d22a
    • Andrew Morton's avatar
      [PATCH] fix ext3 memory leak · 2a6cb303
      Andrew Morton authored
      This is the leak which Con found.  Long story...
      
      - If a dirty page is fed into ext3_writepage() during truncate,
        block_write_full_page() will reutrn -EIO (it's outside i_size) and will
        leave the buffers dirty.  In the expectation that discard_buffer() will
        clean them.
      
      - ext3_writepage() then adds the still-dirty buffers to the journal's
        "async data list".  These are buffers which are known to have had IO
        started.  All we need to do is to wait on them in commit.
      
      - meanwhile, truncate will chop the pages off the address_space.  But
        truncate cannot invalidate the buffers (in journal_unmap_buffer()) because
        the buffers are attached to the committing transaction.  (hm.  This
        behaviour in journal_unmap_buffer() is bogus.  We just never need to write
        these buffers.)
      
      - ext3 commit will "wait on writeout" of these writepage buffers (even
        though it was never started) and will then release them from the
        journalling system.
      
      So we end up with pages which are attached to no mapping, which are clean and
      which have dirty buffers.  These are unreclaimable.
      
      
      Aside:
      
        ext3-ordered has two buffer lists: the "sync data list" and the "async
        data list".
      
        The sync list consists of probably-dirty buffers which were dirtied in
        commit_write().  Transaction commit must write all thee out and wait on
        them.
      
        The async list supposedly consists of clean buffers which were attached
        to the journal in ->writepage.  These have had IO started (by writepage) so
        commit merely needs to wait on them.
      
        This is all designed for the 2.4 VM really.  In 2.5, tons of writeback
        goes via writepage (instead of the buffer lru) and these buffers end up
        madly hpooing between the async and sync lists.
      
        Plus it's arguably incorrect to just wait on the writes in commit - if
        the buffers were set dirty again (say, by zap_pte_range()) then perhaps we
        should write them again before committing.
      
      
      So what the patch does is to remove the async list.  All ordered-data buffers
      are now attached to the single "sync data list".  So when we come to commit,
      those buffers which are dirty will have IO started and all buffers are waited
      upon.
      
      This means that the dirty buffers against a clean page which came about from
      block_write_full_page()'s -EIO will be written to disk in commit - this
      cleans them, and the page is now reclaimable.  No leak.
      
      It seems bogus to write these buffers in commit, and indeed it is.  But ext3
      will not allow those blocks to be reused until the commit has ended so there
      is no corruption risk.  And the amount of data involved is low - it only
      comes about as a race between truncate and writepage().
      2a6cb303
    • Andrew Morton's avatar
      [PATCH] factor free memory into max_sane_readahead() · daebe5ee
      Andrew Morton authored
      max_sane_readahead() permits the user to readahead up to
      half-the-inactive-list's worth of pages.  Which is totally wrong if most of
      memory is free.
      
      So make the limit be
      
      	(nr_inactive + nr_free) / 2
      daebe5ee
    • Andrew Morton's avatar
      [PATCH] ext3 ino_t removal · 42f834c3
      Andrew Morton authored
      Patch from Andreas Dilger <adilger@clusterfs.com>
      
      This patch against 2.5.53 removes my erronous use of ino_t in a couple of
      places in the ext3 code.  This has been replaced with unsigned long (the same
      as is used for inode->i_ino).  This patch matches the fix submitted to 2.4
      for fixing 64-bit compiler warnings, and also replaces a couple of %ld with
      %lu to forestall output wierdness with filesystems with a few billion inodes.
      42f834c3
  2. 13 Jan, 2003 31 commits