1. 06 Feb, 2004 10 commits
    • Andrew Morton's avatar
      [PATCH] janitor: video/fbcmap: kmalloc() audit · 7a3e7a62
      Andrew Morton authored
      From: "Randy.Dunlap" <rddunlap@osdl.org>
      
      From: Leann Ogasawara <ogasawara@osdl.org>
      
      Handle kmalloc() failures
      7a3e7a62
    • Andrew Morton's avatar
      [PATCH] Set CCISS driver VM read-ahead to 1024K · d53303ed
      Andrew Morton authored
      From: Torben Mathiasen <torben.mathiasen@hp.com>
      
      After a lot of testing and measuring we decided to increase the read-ahead
      for the CISS driver in 2.6 to 1MB.
      d53303ed
    • Andrew Morton's avatar
      [PATCH] ext2/3: incorrect increment of i_blocks when keeping the same xattr block · 14484915
      Andrew Morton authored
      From: Andreas Gruenbacher <agruen@suse.de>
      
      Here is a fix for extended attributes on ext2 and ext3, reported by
      Stephen Tweedie <sct@redhat.com>.
      
      From: Stephen Tweedie <sct@redhat.com>:
      
      When you have an EA block that is shared between multiple inodes; AND you
      then change an attribute in that on one inode, AND the new attribute value
      is the same as the old, then xattr computes the new EA block, finds it
      still in the cache, bumps the reference count on it (and the i_blocks field
      on the inode, incidentally), and leaves it incremented because we haven't
      changed EA block so there's no need to drop the refcount on the old block.
      
      So *every* time you have more than one inode sharing an EA block and you
      perform an identical write to an EA, you get a leak on both i_blocks and
      the EA refcount.
      
      This is a big problem for symlinks, which rely on correct i_blocks
      accounting to determine the difference between fast and slow symlinks.
      With the leak, you end up thinking that a fast symlink (ie.  one small
      enough to be stored in the inode direct blocks) is slow, so you dereference
      the ascii contents of the symlink as if they were a disk block address.
      That typically results in EIO all over the place.
      14484915
    • Andrew Morton's avatar
      [PATCH] oss/ad1889: correct printk of dma_addr_t · 389f24aa
      Andrew Morton authored
      From: "Randy.Dunlap" <rddunlap@osdl.org>
      
      fix dma_addr_t type error with CONFIG_HIGHMEM64G=y
      389f24aa
    • Andrew Morton's avatar
      [PATCH] With size > XATTR_SIZE_MAX, getxattr(2) always returns E2BIG · 82243d15
      Andrew Morton authored
      From: Andreas Gruenbacher <agruen@suse.de>
      
      The getxattr (listxattr) syscall returns E2BIG if the buffer passed to them
      is bigger than XATTR_SIZE_MAX (XATTR_LIST_MAX), no matter what buffer size is
      actually required.  Here is a fix.  It also removes the xattr_alloc and
      xattr_free functions which are not of much use anymore.
      82243d15
    • Andrew Morton's avatar
      [PATCH] snprintf() commentary · dd382b3c
      Andrew Morton authored
      From: Paul Jackson <pj@sgi.com>
      
      Explain the snprintf() return value.
      dd382b3c
    • Andrew Morton's avatar
      [PATCH] gcc-3.5: drivers/atm/atmtcp.c · fd555edb
      Andrew Morton authored
      drivers/atm/atmtcp.c: In function `atmtcp_c_close':
      drivers/atm/atmtcp.c:258: error: invalid lvalue in assignment
      drivers/atm/atmtcp.c: In function `atmtcp_create':
      drivers/atm/atmtcp.c:383: error: invalid lvalue in assignment
      fd555edb
    • Andrew Morton's avatar
      [PATCH] ppc64: Add readq/writeq and __raw* IO functions · 6bf2c4c0
      Andrew Morton authored
      From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      
      This patch adds those for ppc64, except for iSeries which cannot do
      readq/writeq easily, at least not as far as I know but I need to ask the
      iSeries specialists in Rochester to be sure.  But anyway, iSeries shouldn't
      use anything in fb.h anyway ...
      
      It also add the proper tweaks & barriers to make sure reads are actually
      done right away and not delayed indefinitely (making the CPU think the read
      data is actually used) and add necessary write barriers on IO writes.  For
      some reasons, ppc64 in 2.6 lacked some of these, opening potential races
      within some drivers.
      6bf2c4c0
    • Andrew Morton's avatar
      [PATCH] ppc64: vio fix · 039c5e57
      Andrew Morton authored
      From: Anton Blanchard <anton@samba.org>
      
      It doesn't link.  Add a chunk which got lost.
      039c5e57
    • Andrew Morton's avatar
      [PATCH] ppc32: Update PowerMac dmasound driver · 89728e0e
      Andrew Morton authored
      From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      
      This patch was missing from my big merge.  It updates the PowerMac
      "dmasound" driver.  Adds input support for some recent machines using the
      tas3004 coded/mixer chip.  Code mostly written by Renzo Davoli.
      
      This driver isn't (unfortunately) fully obsoleted by the Alsa one.  There
      are lots of reports of the Alsa one not working properly on various
      PowerMac machines, and some people are unhappy with Alsa in general, enough
      to have ported the messy PowerMac dmasound to 2.6 :)
      89728e0e
  2. 05 Feb, 2004 1 commit
  3. 06 Feb, 2004 29 commits