1. 12 12月, 2008 1 次提交
  2. 11 12月, 2008 1 次提交
  3. 10 12月, 2008 3 次提交
    • N
      netpoll: fix race on poll_list resulting in garbage entry · 7b363e44
      Neil Horman 提交于
      	A few months back a race was discused between the netpoll napi service
      path, and the fast path through net_rx_action:
      http://kerneltrap.org/mailarchive/linux-netdev/2007/10/16/345470
      
      A patch was submitted for that bug, but I think we missed a case.
      
      Consider the following scenario:
      
      INITIAL STATE
      CPU0 has one napi_struct A on its poll_list
      CPU1 is calling netpoll_send_skb and needs to call poll_napi on the same
      napi_struct A that CPU0 has on its list
      
      
      
      CPU0						CPU1
      net_rx_action					poll_napi
      !list_empty (returns true)			locks poll_lock for A
      						 poll_one_napi
      						  napi->poll
      						   netif_rx_complete
      						    __napi_complete
      						    (removes A from poll_list)
      list_entry(list->next)
      
      
      In the above scenario, net_rx_action assumes that the per-cpu poll_list is
      exclusive to that cpu.  netpoll of course violates that, and because the netpoll
      path can dequeue from the poll list, its possible for CPU0 to detect a non-empty
      list at the top of the while loop in net_rx_action, but have it become empty by
      the time it calls list_entry.  Since the poll_list isn't surrounded by any other
      structure, the returned data from that list_entry call in this situation is
      garbage, and any number of crashes can result based on what exactly that garbage
      is.
      
      Given that its not fasible for performance reasons to place exclusive locks
      arround each cpus poll list to provide that mutal exclusion, I think the best
      solution is modify the netpoll path in such a way that we continue to guarantee
      that the poll_list for a cpu is in fact exclusive to that cpu.  To do this I've
      implemented the patch below.  It adds an additional bit to the state field in
      the napi_struct.  When executing napi->poll from the netpoll_path, this bit will
      be set. When a driver calls netif_rx_complete, if that bit is set, it will not
      remove the napi_struct from the poll_list.  That work will be saved for the next
      iteration of net_rx_action.
      
      I've tested this and it seems to work well.  About the biggest drawback I can
      see to it is the fact that it might result in an extra loop through
      net_rx_action in the event that the device is actually contended for (i.e. the
      netpoll path actually preforms all the needed work no the device, and the call
      to net_rx_action winds up doing nothing, except removing the napi_struct from
      the poll_list.  However I think this is probably a small price to pay, given
      that the alternative is a crash.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b363e44
    • J
      ipv6: silence log messages for locally generated multicast · 24fc7b86
      Jan Sembera 提交于
      This patch fixes minor annoyance during transmission of unsolicited
      neighbor advertisements from userspace to multicast addresses (as
      far as I can see in RFC, this is allowed and the similar functionality
      for IPv4 has been in arping for a long time).
      
      Outgoing multicast packets get reinserted into local processing as if they
      are received from the network. The machine thus sees its own NA and fills
      the logs with error messages. This patch removes the message if NA has been
      generated locally.
      Signed-off-by: NJan Sembera <jsembera@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24fc7b86
    • H
      sungem: improve ethtool output with internal pcs and serdes · fbf0229e
      Hermann Lauer 提交于
      From: Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de>
      
      Attached is a patch which improves the output of ethtool (see below)
      to some sensefull values with a sungem fibre card which uses the
      sungem interal pcs connected to a serdes chip. The seriallink case in
      the driver is untouched.
      
      Most values are hardcoded, because gigabit fibre autoneg is anyways
      limited and the driver don't really support much at the moment with
      that hardware.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbf0229e
  4. 09 12月, 2008 2 次提交
    • D
      tcp: tcp_vegas cong avoid fix · 8d3a564d
      Doug Leith 提交于
      This patch addresses a book-keeping issue in tcp_vegas.c.  At present
      tcp_vegas does separate book-keeping of cwnd based on packet sequence
      numbers.  A mismatch can develop between this book-keeping and
      tp->snd_cwnd due, for example, to delayed acks acking multiple
      packets.  When vegas transitions to reno operation (e.g. following
      loss), then this mismatch leads to incorrect behaviour (akin to a cwnd
      backoff).  This seems mostly to affect operation at low cwnds where
      delayed acking can lead to a significant fraction of cwnd being
      covered by a single ack, leading to the book-keeping mismatch.  This
      patch modifies the congestion avoidance update to avoid the need for
      separate book-keeping while leaving vegas congestion avoidance
      functionally unchanged.  A secondary advantage of this modification is
      that the use of fixed-point (via V_PARAM_SHIFT) and 64 bit arithmetic
      is no longer necessary, simplifying the code.
      
      Some example test measurements with the patched code (confirming no functional
      change in the congestion avoidance algorithm) can be seen at:
      
      http://www.hamilton.ie/doug/vegaspatch/Signed-off-by: NDoug Leith <doug.leith@nuim.ie>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d3a564d
    • D
      sungem: Make PCS PHY support partially work again. · 8c83f80b
      David S. Miller 提交于
      As reported by Hermann Lauer, PCS PHY support in the sungem
      driver simply doesn't work.
      
      When the chip is reset due to open, or some other similar operation,
      the PCS is reset too but we don't program it back into a running
      state.  The result is no link when the device is brought up.
      
      This partially rectifies the situation for the moment, by kicking
      the PCS after a sungem chip reset so that it will renegotiate and
      be re-enabled again.
      
      The behavior is still a little bit dodgy as the added renegotiate
      make the link take some time after bringing the interface up,
      but this is a significant improvement in that things actually work
      now :-)
      
      Based almost entirely upon an initial patch by Hermann.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c83f80b
  5. 08 12月, 2008 1 次提交
  6. 06 12月, 2008 1 次提交
  7. 05 12月, 2008 7 次提交
  8. 04 12月, 2008 7 次提交
    • U
      netx-eth: initialize per device spinlock · 2cc002c4
      Uwe Kleine-König 提交于
      The spinlock used in the netx-eth driver was never properly initialized.
      This was noticed using CONFIG_DEBUG_SPINLOCK=y
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cc002c4
    • I
      tcp: make urg+gso work for real this time · f8269a49
      Ilpo Järvinen 提交于
      I should have noticed this earlier... :-) The previous solution
      to URG+GSO/TSO will cause SACK block tcp_fragment to do zig-zig
      patterns, or even worse, a steep downward slope into packet
      counting because each skb pcount would be truncated to pcount
      of 2 and then the following fragments of the later portion would
      restore the window again.
      
      Basically this reverts "tcp: Do not use TSO/GSO when there is
      urgent data" (33cf71ce). It also removes some unnecessary code
      from tcp_current_mss that didn't work as intented either (could
      be that something was changed down the road, or it might have
      been broken since the dawn of time) because it only works once
      urg is already written while this bug shows up starting from
      ~64k before the urg point.
      
      The retransmissions already are split to mss sized chunks, so
      only new data sending paths need splitting in case they have
      a segment otherwise suitable for gso/tso. The actually check
      can be improved to be more narrow but since this is late -rc
      already, I'll postpone thinking the more fine-grained things.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8269a49
    • B
      enc28j60: Fix sporadic packet loss (corrected again) · 5176da7e
      Baruch Siach 提交于
      Packet data read from the RX buffer the when the RSV is at the end of the RX
      buffer does not warp around. This causes packet loss, as the actual data is
      never read. Fix this by calculating the right packet data location.
      
      Thanks to Shachar Shemesh for suggesting the fix.
      Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
      Acked-by: NClaudio Lanconelli <lanconelli.claudio@eptar.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5176da7e
    • P
      hysdn: fix writing outside the field on 64 bits · bd091410
      Pascal Terjan 提交于
      ifa_local is assumed to be unsigned long which lead to writing the address
      at dev->dev_addr-2 instead of +2
      
      noticed thanks to gcc:
      
      drivers/isdn/hysdn/hysdn_net.c: In function `net_open':
      drivers/isdn/hysdn/hysdn_net.c:91: warning: array subscript is below array bounds
      Signed-off-by: NPascal Terjan <pterjan@mandriva.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd091410
    • W
      b1isa: fix b1isa_exit() to really remove registered capi controllers · 1c594c05
      Wilfried Klaebe 提交于
      On "/etc/init.d/capiutils stop", this oops happened.
      
      The oops happens on reading /proc/capi/controllers because
      capi_ctrl->procinfo is called for the wrongly not unregistered
      controller, which points to b1isa_procinfo(), which was removed on
      module unload.
      
      b1isa_exit() did not call b1isa_remove() for its controllers because
      io[0] == 0 on module unload despite having been 0x340 on module load.
      
      Besides, just removing the controllers that where added on module
      load time and not those that were added later via b1isa_add_card() is
      wrong too - the place where all added cards are found is isa_dev[].
      
      relevant dmesg lines:
      
      [    0.000000] Linux version 2.6.27.4 (w@shubashi) (gcc version 4.3.2 (Debian 4.3.2-1) ) #3 Thu Oct 30 16:49:03 CET 2008
      
      [   67.403555] CAPI Subsystem Rev 1.1.2.8
      [   68.529154] capifs: Rev 1.1.2.3
      [   68.563292] capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
      [   77.026936] b1: revision 1.1.2.2
      [   77.049992] b1isa: revision 1.1.2.3
      [   77.722655] kcapi: Controller [001]: b1isa-340 attached
      [   77.722671] b1isa: AVM B1 ISA at i/o 0x340, irq 5, revision 255
      [   81.272669] b1isa-340: card 1 "B1" ready.
      [   81.272683] b1isa-340: card 1 Protocol: DSS1
      [   81.272689] b1isa-340: card 1 Linetype: point to multipoint
      [   81.272695] b1isa-340: B1-card (3.11-03) now active
      [   81.272702] kcapi: card [001] "b1isa-340" ready.
      
      [  153.721281] kcapi: card [001] down.
      [  154.151889] BUG: unable to handle kernel paging request at e87af000
      [  154.152081] IP: [<e87af000>]
      [  154.153292] *pde = 2655b067 *pte = 00000000
      [  154.153307] Oops: 0000 [#1]
      [  154.153360] Modules linked in: rfcomm l2cap ppdev lp ipt_MASQUERADE tun capi capifs kernelcapi ac battery nfsd exportfs nfs lockd nfs_acl sunrpc sit tunnel4 bridge stp llc ipt_REJECT ipt_LOG xt_tcpudp xt_state iptable_filter iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables nls_utf8 isofs nls_base zlib_inflate loop ipv6 netconsole snd_via82xx dvb_usb_dib0700 gameport dib7000p dib7000m dvb_usb snd_ac97_codec ac97_bus dvb_core mt2266 snd_pcm tuner_xc2028 dib3000mc dibx000_common mt2060 dib0070 snd_page_alloc snd_mpu401_uart snd_seq_midi snd_seq_midi_event btusb snd_rawmidi bluetooth snd_seq snd_timer snd_seq_device snd via686a i2c_viapro soundcore i2c_core parport_pc parport button dm_mirror dm_log dm_snapshot floppy sg ohci1394 uhci_hcd ehci_hcd 8139too mii ieee1394 usbcore sr_mod cdrom sd_mod thermal processor fan [last unloaded: b1]
      [  154.153360]
      [  154.153360] Pid: 4132, comm: capiinit Not tainted (2.6.27.4 #3)
      [  154.153360] EIP: 0060:[<e87af000>] EFLAGS: 00010286 CPU: 0
      [  154.153360] EIP is at 0xe87af000
      [  154.153360] EAX: e6b9ccc8 EBX: e6b9ccc8 ECX: e87a0c67 EDX: e87af000
      [  154.153360] ESI: e142bbc0 EDI: e87a56e0 EBP: e0505f0c ESP: e0505ee4
      [  154.153360]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [  154.153360] Process capiinit (pid: 4132, ti=e0504000 task=d1196cf0 task.ti=e0504000)
      [  154.153360] Stack: e879f650 00000246 e0505ef4 c01472eb e0505f0c 00000246 e7001780 fffffff4
      [  154.153360]        fffffff4 e142bbc0 e0505f48 c01a56c6 00000400 b805e000 d102dc80 e142bbe0
      [  154.153360]        00000000 e87a56e0 00000246 e12617ac 00000000 00000000 e1261760 fffffffb
      [  154.153360] Call Trace:
      [  154.153360]  [<e879f650>] ? controller_show+0x20/0x90 [kernelcapi]
      [  154.153360]  [<c01472eb>] ? trace_hardirqs_on+0xb/0x10
      [  154.153360]  [<c01a56c6>] ? seq_read+0x126/0x2f0
      [  154.153360]  [<c01a55a0>] ? seq_read+0x0/0x2f0
      [  154.153360]  [<c01c033c>] ? proc_reg_read+0x5c/0x90
      [  154.153360]  [<c0189919>] ? vfs_read+0x99/0x140
      [  154.153360]  [<c01c02e0>] ? proc_reg_read+0x0/0x90
      [  154.153360]  [<c0189a7d>] ? sys_read+0x3d/0x70
      [  154.153360]  [<c0103c3d>] ? sysenter_do_call+0x12/0x35
      [  154.153360]  =======================
      [  154.153360] Code:  Bad EIP value.
      [  154.153360] EIP: [<e87af000>] 0xe87af000 SS:ESP 0068:e0505ee4
      [  154.153360] ---[ end trace 23750b6c2862de94 ]---
      Signed-off-by: NWilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NKarsten Keil <kkeil@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c594c05
    • O
      can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter · d253eee2
      Oliver Hartkopp 提交于
      Due to a wrong safety check in af_can.c it was not possible to filter
      for SFF frames with a specific CAN identifier without getting the
      same selected CAN identifier from a received EFF frame also.
      
      This fix has a minimum (but user visible) impact on the CAN filter
      API and therefore the CAN version is set to a new date.
      
      Indeed the 'old' API is still working as-is. But when now setting
      CAN_(EFF|RTR)_FLAG in can_filter.can_mask you might get less traffic
      than before - but still the stuff that you expected to get for your
      defined filter ...
      
      Thanks to Kurt Van Dijck for pointing at this issue and for the review.
      Signed-off-by: NOliver Hartkopp <oliver@hartkopp.net>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d253eee2
    • R
  9. 03 12月, 2008 17 次提交