1. 14 May, 2003 2 commits
    • Jens Axboe's avatar
      [PATCH] ide minimum 48-bit support · aa914d0d
      Jens Axboe authored
      This is the small patch that we all agreed on. With this patch, we do
      nice big writes/reads on ide disks that support 48-bit lba.
      aa914d0d
    • Jens Axboe's avatar
      [PATCH] bio walking code · 21eca852
      Jens Axboe authored
      Add bio traversal functionality. This is a prereq for doing ide
      multiwrites safely and sanely. Patch was originally done by Suparna,
      Bartlomiej picked it up and changed the design somewhat. From Bart:
      
      Main idea is now reversed - instead of introducing rq->hard_bio as
      pointer for bio to be completed and using rq->bio as pointer for bio
      to be submitted, rq->cbio is introduced for submissions and rq->bio
      is used for completions
      
      This minimizes changes to block layer and assures that all existing
      block users are not affected by this patch.
      21eca852
  2. 13 May, 2003 5 commits
  3. 14 May, 2003 1 commit
  4. 13 May, 2003 4 commits
  5. 14 May, 2003 1 commit
  6. 13 May, 2003 17 commits
  7. 12 May, 2003 10 commits
    • Dave Jones's avatar
      Merge tetrachloride.(none):/mnt/raid/src/kernel/2.5/bk-linus · 0b1640a1
      Dave Jones authored
      into tetrachloride.(none):/mnt/raid/src/kernel/2.5/agpgart
      0b1640a1
    • Dave Jones's avatar
      [DRM] Intel i8xx DRM modules are dependant on their AGP counterparts. · e972902d
      Dave Jones authored
      Closes bugzilla #646
      e972902d
    • Linus Torvalds's avatar
      Merge http://linux-scsi.bkbits.net/scsi-for-linus-2.5 · f4e0fb85
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      f4e0fb85
    • James Bottomley's avatar
      Merge raven.il.steeleye.com:/home/jejb/BK/scsi-misc-2.5 · b8beaba6
      James Bottomley authored
      into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5
      b8beaba6
    • Andrew Morton's avatar
      [PATCH] ext3: htree memory leak fix · 2d10c0bb
      Andrew Morton authored
      From Alex Tomas
      
      We started using ext3_dx_readdir() for all dir_index filesystems, because
      we want to return entries in hash order always, so that readdir with a
      partial read + new entry added before next readdir won't be crazy.
      
      So we now need to free the structure at filp->pricate_data even against
      non-indexed directories.
      2d10c0bb
    • Andrew Morton's avatar
      [PATCH] htree nfs fix · 699155e3
      Andrew Morton authored
      Patch from "Theodore Ts'o" <tytso@mit.edu>
      
      We now use 0x7ffffff as the EOF cookie, because Linux NFS stupidly interprets
      the cookie (which is supposed to be a bag of bits without necessarily any
      semantic value) as a signed 64 bit integer, and then converts it to a
      unsigned integer, and then blows up if it cannot be expressed be expressed as
      a 32-bit value!!
      
      In order to do this, we have to fold the hash value 0x7ffffff into the hash
      value 0x7ffffffe.  This is relatively safe; the only time we will lose if the
      directory contains filenames that hash to both 0x7ffffffe and 0x7fffffff
      (under the original hash), and the last directory entry which hashes to
      0x7ffffffe is at the end of a leaf block, and the first directory entry which
      hashes to 0x7fffffff is at the beginning of a leaf block.
      699155e3
    • Andrew Morton's avatar
      [PATCH] Fix ext3 htree / NFS compatibility problems · 7c6d1fb9
      Andrew Morton authored
      Patch from "Theodore Ts'o" <tytso@mit.edu>
      
      The following patch should (in theory) fix the htree/NFS readdir problems
      that people have reported.  Specifically, it should fix the NFS looping on
      EOF problem with readdir, as well as the problems caused by coverting a
      directory to HTREE while an NFS readdir is in progress problem.
      
      I'd appreciate it if people who can easily replicate these NFS/htree problems
      could give this patch (against BK-recent / 2.5.63) a whirl.  Thanks!!
      7c6d1fb9
    • Andrew Morton's avatar
      [PATCH] Fix arch/i386/oprofile/init.c build error · 96198d06
      Andrew Morton authored
      From: John M Flinchbaugh <glynis@butterfly.hjsoft.com>
      
      this patch makes arch/i386/oprofile/init.c build.
      96198d06
    • Andrew Morton's avatar
      [PATCH] Reserve the ext2/ext3 EAs for the Lustre filesystem · 2c227ffa
      Andrew Morton authored
      From: Andreas Dilger <adilger@clusterfs.com>
      
      Below are the patches which reserve the Lustre EA index.  The rest of the
      code is part of the Lustre tree, which isn't working with 2.5 yet.
      2c227ffa
    • Andrew Morton's avatar
      [PATCH] vmalloc race fix · 9bc3b5f1
      Andrew Morton authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The new vmalloc() semantics from 2.5.32 had a race window.  As things stand,
      the presence of a vm_area in the vmlist protects from allocators other than
      the owner examining the ptes in that area.  This puts an ordering constraint
      on unmapping, so that allocators are required to unmap areas before removing
      them from the list or otherwise dropping the lock.
      
      Currently, unmap_vm_area() is done outside the lock and after the area is
      removed, which as we've seen from Felix von Leitner's test is oopsable.
      
      The following patch folds calls to unmap_vm_area() into remove_vm_area() to
      reinstate what are essentially the 2.4.x semantics of vfree().  This renders
      a number of unmap_vm_area() calls unnecessary (and in fact oopsable since
      they wipe ptes from later allocations).  It's an open question as to whether
      this is sufficiently performant, but it is the minimally invasive approach.
      The more performant alternative is to provide the right API hooks to wipe the
      vmalloc() area clean before removing them from the list, using the ownership
      of the area to eliminate holding the vmlist_lock for the duration of the
      unmapping.  If it proves to be necessary wli is on standby to implement it.
      9bc3b5f1