1. 17 Feb, 2004 11 commits
    • David Mosberger's avatar
      [PATCH] Fix radeon warning on 64-bit platforms · 015510a7
      David Mosberger authored
      Disable the RADEON_PARAM_SAREA_HANDLE ioctl on 64-bit architectures,
      since it is only used on some embedded platforms, and it isn't 64-bit
      safe.
      015510a7
    • Linus Torvalds's avatar
      Fix the dependency chain for I2C_ALGOBIT from the FB · 607e971e
      Linus Torvalds authored
      drivers that need it. 
      
      This allows us to have I2C as a module iff the FB driver
      that needs it is a module.
      607e971e
    • Roman Zippel's avatar
      [PATCH] Avoid bogus warning about recursive dependencies · 1fd850c4
      Roman Zippel authored
      This allows us to do something like
      
      	config FB_RADEON
      		select I2C_ALGOBIT if FB_RADEON_I2C
      
      where FB_RADEON_I2C itself depends on FB_RADEON without getting a bogus
      warning about recursive dependencies.
      
      This matters because the select takes the default minimum dependancy
      from the parent menu, so we want to do this under FB_RADEON rather than
      under FB_RADEON_I2C (so that the I2C_ALGOBIT config depends properly
      on the state of FB_RADEON)
      1fd850c4
    • Alexander Viro's avatar
      [PATCH] blkdev_put() data corruption · 31fc3053
      Alexander Viro authored
      	We used to have sync_blockdev() on each normal (== non-raw)
      blkdev_put() + kill_bdev() on the final blkdev_put().  That worked
      fine until we'd moved sync_blockdev() to the final blkdev_put().
      
      	Now we have a nasty scenario:
      
      open block device
      open raw device
      write on block device	# data ends up in cache
      close block device	# no sync here, we still have the sucker opened
      close raw device	# no sync here either
      			# ... and cache is killed by kill_bdev()
      
      	IOW, if we postpone sync to final close, we must do it regardless of
      kind of close.  Otherwise we are in for data corruption and yes, it is easy
      to trigger.  Fix is obvious...
      31fc3053
    • Andrew Morton's avatar
      [PATCH] cifs: kunmap_atomic() takes a kernel address · d6c561ce
      Andrew Morton authored
      kunmap_atomic() takes a kernel-virtual address, not a pageframe address.
      
      (Very common problem.  We really should make the atomic kmap functions
      type-safe).
      d6c561ce
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/nf-2.6 · 4e742d9c
      Linus Torvalds authored
      into home.osdl.org:/home/torvalds/v2.5/linux
      4e742d9c
    • Jim Paradis's avatar
      [PATCH] Fix fencepost error in x86_64 IOMMU · f65196a4
      Jim Paradis authored
      There's a fencepost error in the GART IOMMU handling on x86_64
      in the unmap path.  When testing to see if the bus address is
      within the IOMMU window and needs to be unmapped, the start of
      the first page *beyond* the window also passes the test.  This
      can cause the first doubleword of the next page beyond the gatt
      table to be smashed to zero, with unpredictable results depending
      on what that page is used for.
      f65196a4
    • David S. Miller's avatar
      Merge nuts.davemloft.net:/disk1/BK/nfwork-2.6 · 427f850f
      David S. Miller authored
      into nuts.davemloft.net:/disk1/BK/nf-2.6
      427f850f
    • David Mosberger's avatar
      [PATCH] fix ia64 build failure · ab5f03ce
      David Mosberger authored
      The attached trivial patch should fix the "i1-dig" build failure reported
      on this page:
      
      	http://www.gelato.unsw.edu.au/kerncomp/
      
      and should make it easier to build a properly configured ia64 kernel.
      ab5f03ce
    • Andrew Morton's avatar
      [PATCH] mremap NULL pointer dereference fix · 584f5bcb
      Andrew Morton authored
      This is a cleaned-up version of a mremap() fix for "move_one_page()"
      by Rajesh Venkatasubramanian <vrajesh@umich.edu>. We could use a NULL
      "src" pointer.
      
      Because while we do hold the MM semaphore over the whole sequence, the
      destination page table allocation will possibly drop the page table
      spinlock.  That in turn can cause a clean source page to be stolen by
      page reclaim, causing the source-side "get_one_pte_map_nested()" to
      return NULL the second time around even if it didn't on the first case.
      
      So we just check "src" again, and get rid of the bogus TLB invalidate
      while we're at it.
      584f5bcb
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/sparc-2.6 · d90349aa
      Linus Torvalds authored
      into home.osdl.org:/home/torvalds/v2.5/linux
      d90349aa
  2. 16 Feb, 2004 29 commits