1. 16 5月, 2006 32 次提交
  2. 13 5月, 2006 8 次提交
    • L
      Revert "[PATCH] i386: export: memory more than 4G through /proc/iomem" · 9be2f7c3
      Linus Torvalds 提交于
      This reverts commit 10dbe196.
      
      The resource struct is still 32-bit, so trying to save a 64-bit memory
      size there obviously won't work.
      
      When we merge the 64-bit resource series, we can re-enable this.
      
      Thanks to Sachin Sant and Maneesh Soni for debugging
      
      Cc: Maneesh Soni <maneesh@in.ibm.com>
      Cc: Sachin Sant <sachinp@in.ibm.com>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Cc: Sharyathi Nagesh <sharyath@in.ibm.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9be2f7c3
    • L
      Alternative fix for MMC oops on unmount after removal · 032ebf26
      Linus Torvalds 提交于
      Make sure to clear the driverfs_dev pointer when we do del_gendisk() (on
      disk removal), so that other users that may still have a ref to the disk
      won't try to use the stale pointer.
      
      Also move the KOBJ_REMOVE uevent handler up, so that the uevent still
      has access to the driverfs_dev data.
      
      This all should hopefully fix the problems with MMC umounts after device
      removals that caused commit 56cf6504 and
      its reversal (1a2acc9e).
      
      Original problem reported by Todd Blumer and others.
      Acked-by: NGreg KH <gregkh@suse.de>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Cc: James Bottomley <James.Bottomley@SteelEye.com>
      Cc: Erik Mouw <erik@harddisk-recovery.com>
      Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
      Cc: Todd Blumer <todd@sdgsystems.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      032ebf26
    • L
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · 18552b8f
      Linus Torvalds 提交于
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
        [NEIGH]: Fix IP-over-ATM and ARP interaction.
        [TG3]: ethtool always report port is TP.
      18552b8f
    • L
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 · faa88df8
      Linus Torvalds 提交于
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
        [SPARC]: Fix warning on prom_getproperty in openprom.c
        [SPARC]: Handle UNWIND_INFO properly.
        [SPARC64]: Update defconfig.
        [SPARC]: show device name in /proc/dvma_map
        [SPARC]: Remove duplicate symbol exports
      faa88df8
    • S
      IB: refcount race fixes · 1b52fa98
      Sean Hefty 提交于
      Fix race condition during destruction calls to avoid possibility of
      accessing object after it has been freed.  Instead of waking up a wait
      queue directly, which is susceptible to a race where the object is
      freed between the reference count going to 0 and the wake_up(), use a
      completion to wait in the function doing the freeing.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      1b52fa98
    • R
      IB/ipath: Properly terminate PCI ID table · 6f4bb3d8
      Roland Dreier 提交于
      The ipath driver's table of PCI IDs needs a { 0, } entry at the end.
      This makes all of the device aliases visible to userspace so hotplug
      loads the module for all supported devices.  Without the patch,
      modinfo ipath_core only shows:
      
          alias:          pci:v00001FC1d0000000Dsv*sd*bc*sc*i*
      
      instead of the correct:
      
          alias:          pci:v00001FC1d00000010sv*sd*bc*sc*i*
          alias:          pci:v00001FC1d0000000Dsv*sd*bc*sc*i*
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NBryan O'Sullivan <bos@pathscale.com>
      6f4bb3d8
    • S
      [NEIGH]: Fix IP-over-ATM and ARP interaction. · bd89efc5
      Simon Kelley 提交于
      The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
      ARP table, using the standard neighbour-table code. The
      neigh_table_init function adds this neighbour table to a linked list
      of all neighbor tables which is used by the functions neigh_delete()
      neigh_add() and neightbl_set(), all called by the netlink code.
      
      Once the ATM neighbour table is added to the list, there are two
      tables with family == AF_INET there, and ARP entries sent via netlink
      go into the first table with matching family. This is indeterminate
      and often wrong.
      
      To see the bug, on a kernel with CLIP enabled, create a standard IPv4
      ARP entry by pinging an unused address on a local subnet. Then attempt
      to complete that entry by doing
      
      ip neigh replace <ip address> lladdr <some mac address> nud reachable
      
      Looking at the ARP tables by using 
      
      ip neigh show
      
      will reveal two ARP entries for the same address. One of these can be
      found in /proc/net/arp, and the other in /proc/net/atm/arp.
      
      This patch adds a new function, neigh_table_init_no_netlink() which
      does everything the neigh_table_init() does, except add the table to
      the netlink all-arp-tables chain. In addition neigh_table_init() has a
      check that all tables on the chain have a distinct address family.
      The init call in clip.c is changed to call
      neigh_table_init_no_netlink().
      
      Since ATM ARP tables are rather more complicated than can currently be
      handled by the available rtattrs in the netlink protocol, no
      functionality is lost by this patch, and non-ATM ARP manipulation via
      netlink is rescued. A more complete solution would involve a rtattr
      for ATM ARP entries and some way for the netlink code to give
      neigh_add and friends more information than just address family with
      which to find the correct ARP table.
      
      [ I've changed the assertion checking in neigh_table_init() to not
        use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
        we found an existing tbl with the same family, and after dropping
        the lock we'll give a diagnostic kernel log message and a stack dump.
        -DaveM ]
      Signed-off-by: NSimon Kelley <simon@thekelleys.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd89efc5
    • M