1. 06 Nov, 2009 3 commits
  2. 05 Nov, 2009 1 commit
  3. 04 Nov, 2009 9 commits
  4. 03 Nov, 2009 1 commit
  5. 02 Nov, 2009 2 commits
  6. 30 Oct, 2009 19 commits
  7. 29 Oct, 2009 5 commits
    • Gabor Gombas's avatar
      net: Fix 'Re: PACKET_TX_RING: packet size is too long' · b5dd884e
      Gabor Gombas authored
      Currently PACKET_TX_RING forces certain amount of every frame to remain
      unused. This probably originates from an early version of the
      PACKET_TX_RING patch that in fact used the extra space when the (since
      removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
      code does not make any use of this extra space.
      
      This patch removes the extra space reservation and lets userspace make
      use of the full frame size.
      Signed-off-by: default avatarGabor Gombas <gombasg@sztaki.hu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5dd884e
    • Janusz Krzysztofik's avatar
      netdev: usb: dm9601.c can drive a device not supported yet, add support for it · 06b71b65
      Janusz Krzysztofik authored
      I found that the current version of drivers/net/usb/dm9601.c can be used to
      successfully drive a low-power, low-cost network adapter with USB ID
      0a46:9000, based on a DM9000E chipset. As no device with this ID is yet
      present in the kernel, I have created a patch that adds support for the device
      to the dm9601 driver.
      
      Created and tested against linux-2.6.32-rc5.
      Signed-off-by: default avatarJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Acked-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06b71b65
    • Ron Mercer's avatar
      qlge: Fix firmware mailbox command timeout. · da039451
      Ron Mercer authored
      The mailbox command process would only process a maximum of 5 unrelated
      firmware events while waiting for it's command completion status.
      It should process an unlimited number of events while waiting for a maximum of 5 seconds.
      Signed-off-by: default avatarRon Mercer <ron.mercer@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da039451
    • Ron Mercer's avatar
      qlge: Fix EEH handling. · 6d190c6e
      Ron Mercer authored
      Clean up driver resources without touch the hardware. Add pci
      save/restore state.
      Signed-off-by: default avatarRon Mercer <ron.mercer@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d190c6e
    • Neil Horman's avatar
      AF_RAW: Augment raw_send_hdrinc to expand skb to fit iphdr->ihl (v2) · 55888dfb
      Neil Horman authored
      Augment raw_send_hdrinc to correct for incorrect ip header length values
      
      A series of oopses was reported to me recently.  Apparently when using AF_RAW
      sockets to send data to peers that were reachable via ipsec encapsulation,
      people could panic or BUG halt their systems.
      
      I've tracked the problem down to user space sending an invalid ip header over an
      AF_RAW socket with IP_HDRINCL set to 1.
      
      Basically what happens is that userspace sends down an ip frame that includes
      only the header (no data), but sets the ip header ihl value to a large number,
      one that is larger than the total amount of data passed to the sendmsg call.  In
      raw_send_hdrincl, we allocate an skb based on the size of the data in the msghdr
      that was passed in, but assume the data is all valid.  Later during ipsec
      encapsulation, xfrm4_tranport_output moves the entire frame back in the skbuff
      to provide headroom for the ipsec headers.  During this operation, the
      skb->transport_header is repointed to a spot computed by
      skb->network_header + the ip header length (ihl).  Since so little data was
      passed in relative to the value of ihl provided by the raw socket, we point
      transport header to an unknown location, resulting in various crashes.
      
      This fix for this is pretty straightforward, simply validate the value of of
      iph->ihl when sending over a raw socket.  If (iph->ihl*4U) > user data buffer
      size, drop the frame and return -EINVAL.  I just confirmed this fixes the
      reported crashes.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55888dfb