1. 26 Nov, 2008 6 commits
  2. 25 Nov, 2008 12 commits
  3. 24 Nov, 2008 1 commit
  4. 23 Nov, 2008 2 commits
  5. 22 Nov, 2008 4 commits
    • Catalin Marinas's avatar
      net: Fix memory leak in the proto_register function · 7e56b5d6
      Catalin Marinas authored
      If the slub allocator is used, kmem_cache_create() may merge two or more
      kmem_cache's into one but the cache name pointer is not updated and
      kmem_cache_name() is no longer guaranteed to return the pointer passed
      to the former function. This patch stores the kmalloc'ed pointers in the
      corresponding request_sock_ops and timewait_sock_ops structures.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e56b5d6
    • Petr Tesarik's avatar
      tcp: Do not use TSO/GSO when there is urgent data · 33cf71ce
      Petr Tesarik authored
      This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=12014
      
      Since most (if not all) implementations of TSO and even the in-kernel
      software GSO do not update the urgent pointer when splitting a large
      segment, it is necessary to turn off TSO/GSO for all outgoing traffic
      with the URG pointer set.
      
      Looking at tcp_current_mss (and the preceding comment) I even think
      this was the original intention. However, this approach is insufficient,
      because TSO/GSO is turned off only for newly created frames, not for
      frames which were already pending at the arrival of a message with
      MSG_OOB set. These frames were created when TSO/GSO was enabled,
      so they may be large, and they will have the urgent pointer set
      in tcp_transmit_skb().
      
      With this patch, such large packets will be fragmented again before
      going to the transmit routine.
      
      As a side note, at least the following NICs are known to screw up
      the urgent pointer in the TCP header when doing TSO:
      
      	Intel 82566MM (PCI ID 8086:1049)
      	Intel 82566DC (PCI ID 8086:104b)
      	Intel 82541GI (PCI ID 8086:1076)
      	Broadcom NetXtreme II BCM5708 (PCI ID 14e4:164c)
      Signed-off-by: default avatarPetr Tesarik <ptesarik@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33cf71ce
    • Randy Dunlap's avatar
      net/hp-plus: fix link errors · 38ae07e4
      Randy Dunlap authored
      Fix hp-plus driver link errors.
      Builds as loadable module and kernel image driver.
      All drivers that use 8390.o or 8390p.o that will build on
      i386 with MCA/PCI/EISA/ISA were built successfully both
      =m and =y.
      
      drivers/built-in.o: In function `hpp_open':
      hp-plus.c:(.text+0xac06c): undefined reference to `eip_interrupt'
      hp-plus.c:(.text+0xac0d7): undefined reference to `eip_open'
      drivers/built-in.o: In function `hpp_close':
      hp-plus.c:(.text+0xac1bb): undefined reference to `eip_close'
      drivers/built-in.o: In function `hpp_probe1':
      hp-plus.c:(.init.text+0xa98a): undefined reference to `NS8390p_init'
      drivers/built-in.o: In function `hp_plus_probe':
      (.init.text+0xa9fe): undefined reference to `__alloc_eip_netdev'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38ae07e4
    • Cord Walter's avatar
      axnet_cs / pcnet_cs: moving PCMCIA_DEVICE_PROD_ID for Netgear FA411 · 208fbec5
      Cord Walter authored
      Hi,
      
      after noticing that my Netgear FA411 (PCMCIA-NIC) [1] stopped working with
      the release of the 2.6.25 kernel (sidux-version), I checked the
      respective driver sources and noticed that the pcnet_cs driver bailed
      out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs
      doesn't claim this ID.
      
      I compiled a kernel with the PCMCIA-ID for the netgear card moved to
      axnet_cs from pcnet_cs which worked. I then contacted sidux-kernel
      maintainer Stefan Lippers-Hollmann who turned the info into this patch
      and integrated it into the kernel:
      
      <http://svn.berlios.de/svnroot/repos/fullstory/linux-sidux-2.6/trunk/debian/patches/features/2.6.27.4_PCMCIA_move-PCMCIA-ID-for-Netgear-FA411-from-pcnet_cs-to-axnet_cs.patch>
      
      This works for me and AFAIK there were no reports of any breakage for
      other devices on sidux-support.
      
      This looks like a trivial patch, but since I have very limited
      experience with kernel modifications  I might be woefully wrong there.
      But if there are no side effects of this patch, is it possible to get it
      into the official kernel?
      
      I can provide more detailed information on the affected hardware if
      necessary.
      
      -cord
      
      [1]
      Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
              Configuration:  state: on
              Product Name:   NETGEAR FA411 Fast Ethernet
              Identification: manf_id: 0x0149 card_id: 0x0411
                              function: 6 (network)
                              prod_id(1): "NETGEAR" (0x9aa79dc3)
                              prod_id(2): "FA411" (0x40fad875)
                              prod_id(3): "Fast Ethernet" (0xb4be14e3)
                              prod_id(4): --- (---)
      
      From: Stefan Lippers-Hollmann <s.l-h@gmx.de>
      Date: Sat, 1 Nov 2008 23:53:04 +0000
      Subject: PCMCIA: move PCMCIA ID for Netgear FA411 from pcnet_cs to axnet_cs:
      
      Since kernel 2.6.25, commit 61da96be
      (pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.),
      pcnet_cs bails out with "use axnet_cs instead" for the Netgear FA411, but
      axnet_cs doesn't claim this ID.
      
      Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
              Configuration:  state: on
              Product Name:   NETGEAR FA411 Fast Ethernet
              Identification: manf_id: 0x0149 card_id: 0x0411
                              function: 6 (network)
                              prod_id(1): "NETGEAR" (0x9aa79dc3)
                              prod_id(2): "FA411" (0x40fad875)
                              prod_id(3): "Fast Ethernet" (0xb4be14e3)
                              prod_id(4): --- (---)
      
      Cc: stable <stable@kernel.org> [2.6.25, 2.6.26, 2.6.27]
      Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Signed-off-by: default avatarCord Walter <qord@cwalter.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      208fbec5
  6. 21 Nov, 2008 2 commits
  7. 20 Nov, 2008 13 commits