1. 12 5月, 2010 1 次提交
    • M
      vhost: fix barrier pairing · 0d499356
      Michael S. Tsirkin 提交于
      According to memory-barriers.txt, an smp memory barrier in guest
      should always be paired with an smp memory barrier in host,
      and I quote "a lack of appropriate pairing is almost certainly an
      error". In case of vhost, failure to flush out used index
      update before looking at the interrupt disable flag
      could result in missed interrupts, resulting in
      networking hang under stress.
      
      This might happen when flags read bypasses used index write.
      So we see interrupts disabled and do not interrupt, at the
      same time guest writes flags value to enable interrupt,
      reads an old used index value, thinks that
      used ring is empty and waits for interrupt.
      
      Note: the barrier we pair with here is in
      drivers/virtio/virtio_ring.c, function
      vring_enable_cb.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJuan Quintela <quintela@redhat.com>
      0d499356
  2. 11 5月, 2010 1 次提交
  3. 10 5月, 2010 2 次提交
    • D
      net: Fix FDDI and TR config checks in ipv4 arp and LLC. · f0ecde14
      David S. Miller 提交于
      Need to check both CONFIG_FOO and CONFIG_FOO_MODULE
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0ecde14
    • A
      IPv4: unresolved multicast route cleanup · bbd72543
      Andreas Meissner 提交于
      Fixes the expiration timer for unresolved multicast route entries.
      In case new multicast routing requests come in faster than the 
      expiration timeout occurs (e.g. zap through multicast TV streams), the 
      timer is prevented from being called at time for already existing entries.
      
      As the single timer is resetted to default whenever a new entry is made, 
      the timeout for existing unresolved entires are missed and/or not 
      updated. As a consequence new requests are denied when the limit of 
      unresolved entries has been reached because old entries live longer than 
      they are supposed to.
      
      The solution is to reset the timer only for the first unresolved entry 
      in the multicast routing cache. All other timers are already set and 
      updated correctly within the timer function itself by now.
      
      Signed-off by: Andreas Meissner <andreas.meissner@sphairon.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbd72543
  4. 08 5月, 2010 2 次提交
    • R
      mac80211: remove association work when processing deauth request · 79733a86
      Reinette Chatre 提交于
      In https://bugzilla.kernel.org/show_bug.cgi?id=15794 a user encountered the
      following:
      
      [18967.469098] wlan0: authenticated
      [18967.472527] wlan0: associate with 00:1c:10:b8:e3:ea (try 1)
      [18967.472585] wlan0: deauthenticating from 00:1c:10:b8:e3:ea by local choice (reason=3)
      [18967.672057] wlan0: associate with 00:1c:10:b8:e3:ea (try 2)
      [18967.872357] wlan0: associate with 00:1c:10:b8:e3:ea (try 3)
      [18968.072960] wlan0: association with 00:1c:10:b8:e3:ea timed out
      [18968.076890] ------------[ cut here ]------------
      [18968.076898] WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0xa8/0x140()
      [18968.076900] Hardware name: GX628
      [18968.076924] Pid: 1408, comm: phy0 Not tainted 2.6.34-rc4-00082-g250541fc-dirty #3
      [18968.076926] Call Trace:
      [18968.076931]  [<ffffffff8103459e>] ?  warn_slowpath_common+0x6e/0xb0
      [18968.076934]  [<ffffffff8157c2d8>] ?  cfg80211_send_assoc_timeout+0xa8/0x140
      [18968.076937]  [<ffffffff8103ff8b>] ? mod_timer+0x10b/0x180
      [18968.076940]  [<ffffffff8158f0fc>] ?  ieee80211_assoc_done+0xbc/0xc0
      [18968.076943]  [<ffffffff81590d53>] ?  ieee80211_work_work+0x553/0x11c0
      [18968.076945]  [<ffffffff8102d931>] ? finish_task_switch+0x41/0xb0
      [18968.076948]  [<ffffffff81590800>] ?  ieee80211_work_work+0x0/0x11c0
      [18968.076951]  [<ffffffff810476fb>] ? worker_thread+0x13b/0x210
      [18968.076954]  [<ffffffff8104b6b0>] ?  autoremove_wake_function+0x0/0x30
      [18968.076956]  [<ffffffff810475c0>] ? worker_thread+0x0/0x210
      [18968.076959]  [<ffffffff8104b21e>] ? kthread+0x8e/0xa0
      [18968.076962]  [<ffffffff810031f4>] ?  kernel_thread_helper+0x4/0x10
      [18968.076964]  [<ffffffff8104b190>] ? kthread+0x0/0xa0
      [18968.076966]  [<ffffffff810031f0>] ?  kernel_thread_helper+0x0/0x10
      [18968.076968] ---[ end trace 8aa6265f4b1adfe0 ]---
      
      As explained by Johannes Berg <johannes@sipsolutions.net>:
      
      We authenticate successfully, and then userspace requests association.
      Then we start that process, but the AP doesn't respond. While we're
      still waiting for an AP response, userspace asks for a deauth. We do
      the deauth, but don't abort the association work. Then once the
      association work times out we tell cfg80211, but it no longer wants
      to know since for all it is concerned we accepted the deauth that
      also kills the association attempt.
      
      Fix this by, upon receipt of deauth request, removing the association work
      and continuing to send the deauth.
      
      Unfortunately the user reporting the issue is not able to reproduce this
      problem anymore and cannot verify this fix. This seems like a well understood
      issue though and I thus present the patch.
      Bug-identified-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      79733a86
    • C
      ar9170: wait for asynchronous firmware loading · 160b8242
      Christian Lamparter 提交于
      This patch fixes a regression introduced by the following patch:
      "ar9170: load firmware asynchronously"
      
      When we kick off a firmware loading request and then unbind,
      or disconnect the usb device right away, we get into trouble:
      
      > ------------[ cut here ]------------
      > WARNING: at lib/kref.c:44 kref_get+0x1c/0x20()
      > Hardware name: 18666GU
      > Modules linked in: ar9170usb [...]
      > Pid: 6588, comm: firmware/ar9170 Not tainted 2.6.34-rc5-wl #43
      > Call Trace:
      > [<c102b05e>] ? warn_slowpath_common+0x6e/0xb0
      > [<c117c93c>] ? kref_get+0x1c/0x20
      > [<c102b0b3>] ? warn_slowpath_null+0x13/0x20
      > [<c117c93c>] ? kref_get+0x1c/0x20
      > [<c117bb2f>] ? kobject_get+0xf/0x20
      > [<c124d630>] ? get_device+0x10/0x20
      > [<c124e5a0>] ? device_add+0x60/0x530
      > [<c117b8b5>] ? kobject_init+0x25/0xa0
      > [<c12569f9>] ? _request_firmware+0x139/0x3e0
      > [<c1256cc0>] ? request_firmware_work_func+0x20/0x70
      > [<c1256ca0>] ? request_firmware_work_func+0x0/0x70
      > [<c103ff24>] ? kthread+0x74/0x80
      > [<c103feb0>] ? kthread+0x0/0x80
      > [<c1003136>] ? kernel_thread_helper+0x6/0x10
      >---[ end trace 2d50bd818f64a1b7 ]---
      - followed by a random Oops -
      
      Avoid that by waiting for the firmware loading to finish
      (whether successfully or not) before the unbind in
      ar9170_usb_disconnect.
      Reported-by: NJohannes Berg <johannes@sipsolutions.net>
      Bug-fixed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      160b8242
  5. 07 5月, 2010 1 次提交
  6. 06 5月, 2010 5 次提交
    • D
      phy: Fix initialization in micrel driver. · 80ea76bb
      David S. Miller 提交于
      Missing name string in ks8001_driver, so we crash on register.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80ea76bb
    • V
      sctp: Fix a race between ICMP protocol unreachable and connect() · 50b5d6ad
      Vlad Yasevich 提交于
      ICMP protocol unreachable handling completely disregarded
      the fact that the user may have locked the socket.  It proceeded
      to destroy the association, even though the user may have
      held the lock and had a ref on the association.  This resulted
      in the following:
      
      Attempt to release alive inet socket f6afcc00
      
      =========================
      [ BUG: held lock freed! ]
      -------------------------
      somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
      there!
       (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
      1 lock held by somenu/2672:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
      
      stack backtrace:
      Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
      Call Trace:
       [<c1232266>] ? printk+0xf/0x11
       [<c1038553>] debug_check_no_locks_freed+0xce/0xff
       [<c10620b4>] kmem_cache_free+0x21/0x66
       [<c1185f25>] __sk_free+0x9d/0xab
       [<c1185f9c>] sk_free+0x1c/0x1e
       [<c1216e38>] sctp_association_put+0x32/0x89
       [<c1220865>] __sctp_connect+0x36d/0x3f4
       [<c122098a>] ? sctp_connect+0x13/0x4c
       [<c102d073>] ? autoremove_wake_function+0x0/0x33
       [<c12209a8>] sctp_connect+0x31/0x4c
       [<c11d1e80>] inet_dgram_connect+0x4b/0x55
       [<c11834fa>] sys_connect+0x54/0x71
       [<c103a3a2>] ? lock_release_non_nested+0x88/0x239
       [<c1054026>] ? might_fault+0x42/0x7c
       [<c1054026>] ? might_fault+0x42/0x7c
       [<c11847ab>] sys_socketcall+0x6d/0x178
       [<c10da994>] ? trace_hardirqs_on_thunk+0xc/0x10
       [<c1002959>] syscall_call+0x7/0xb
      
      This was because the sctp_wait_for_connect() would aqcure the socket
      lock and then proceed to release the last reference count on the
      association, thus cause the fully destruction path to finish freeing
      the socket.
      
      The simplest solution is to start a very short timer in case the socket
      is owned by user.  When the timer expires, we can do some verification
      and be able to do the release properly.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50b5d6ad
    • E
      veth: Dont kfree_skb() after dev_forward_skb() · 6ec82562
      Eric Dumazet 提交于
      In case of congestion, netif_rx() frees the skb, so we must assume
      dev_forward_skb() also consume skb.
      
      Bug introduced by commit 44540960
      (veth: move loopback logic to common location)
      
      We must change dev_forward_skb() to always consume skb, and veth to not
      double free it.
      
      Bug report : http://marc.info/?l=linux-netdev&m=127310770900442&w=3Reported-by: NMartín Ferrari <martin.ferrari@gmail.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ec82562
    • B
      IPv6: fix IPV6_RECVERR handling of locally-generated errors · d40a4de0
      Brian Haley 提交于
      I noticed when I added support for IPV6_DONTFRAG that if you set
      IPV6_RECVERR and tried to send a UDP packet larger than 64K to an
      IPv6 destination, you'd correctly get an EMSGSIZE, but reading from
      MSG_ERRQUEUE returned the incorrect address in the cmsg:
      
      struct msghdr:
      	 msg_name         0x7fff8f3c96d0
      	 msg_namelen      28
      struct sockaddr_in6:
      	 sin6_family      10
      	 sin6_port        7639
      	 sin6_flowinfo    0
      	 sin6_addr        ::ffff:38.32.0.0
      	 sin6_scope_id    0  ((null))
      
      It should have returned this in my case:
      
      struct msghdr:
      	 msg_name         0x7fffd866b510
      	 msg_namelen      28
      struct sockaddr_in6:
      	 sin6_family      10
      	 sin6_port        7639
      	 sin6_flowinfo    0
      	 sin6_addr        2620:0:a09:e000:21f:29ff:fe57:f88b
      	 sin6_scope_id    0  ((null))
      
      The problem is that ipv6_recv_error() assumes that if the error
      wasn't generated by ICMPv6, it's an IPv4 address sitting there,
      and proceeds to create a v4-mapped address from it.
      
      Change ipv6_icmp_error() and ipv6_local_error() to set skb->protocol
      to htons(ETH_P_IPV6) so that ipv6_recv_error() knows the address
      sitting right after the extended error is IPv6, else it will
      incorrectly map the first octet into an IPv4-mapped IPv6 address
      in the cmsg structure returned in a recvmsg() call to obtain
      the error.
      Signed-off-by: NBrian Haley <brian.haley@hp.com>
      
      --
      To unsubscribe from this list: send the line "unsubscribe netdev" in
      the body of a message to majordomo@vger.kernel.org
      More majordomo info at  http://vger.kernel.org/majordomo-info.htmlSigned-off-by: NDavid S. Miller <davem@davemloft.net>
      d40a4de0
    • S
      net/gianfar: drop recycled skbs on MTU change · 7df9c43f
      Sebastian Andrzej Siewior 提交于
      The size for skbs which is added to the recycled list is using the
      current descriptor size which is current MTU. gfar_new_skb() is also
      using this size. So after changing or alteast increasing the MTU all
      recycled skbs should be dropped.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NAndy Fleming <afleming@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7df9c43f
  7. 05 5月, 2010 1 次提交
  8. 04 5月, 2010 6 次提交
  9. 03 5月, 2010 1 次提交
  10. 02 5月, 2010 1 次提交
  11. 01 5月, 2010 5 次提交
  12. 29 4月, 2010 11 次提交
    • S
      net/sb1250: register mdio bus in probe · 03f80cc3
      Sebastian Siewior 提交于
      "ifconfig eth0 up && ifconfig eth0 down" triggers:
      | kobject (a8000000cfa5a480): tried to init an initialized object, something is seriously wrong.
      | Call Trace:
      | [<ffffffff8010aabc>] dump_stack+0x8/0x34
      | [<ffffffff80293128>] kobject_init+0xe8/0xf0
      | [<ffffffff802d922c>] device_initialize+0x2c/0x98
      | [<ffffffff802d9cfc>] device_register+0x14/0x28
      | [<ffffffff80312cd4>] mdiobus_register+0xdc/0x1e0
      | [<ffffffff80314cf0>] sbmac_open+0x58/0x220
      | [<ffffffff803519bc>] __dev_open+0x11c/0x180
      | [<ffffffff8034d578>] __dev_change_flags+0x120/0x180
      | [<ffffffff80351848>] dev_change_flags+0x20/0x78
      | [<ffffffff803a753c>] devinet_ioctl+0x7cc/0x820
      | [<ffffffff80339ac8>] sock_do_ioctl+0x38/0x90
      | [<ffffffff8033a258>] compat_sock_ioctl_trans+0x408/0x1030
      | [<ffffffff8033af30>] compat_sock_ioctl+0xb0/0xd0
      | [<ffffffff80208b08>] compat_sys_ioctl+0xa0/0x18b8
      | [<ffffffff80102f94>] handle_sys+0x114/0x130
      |
      | sb1250-mac-mdio: probed
      
      mdiobus_register() calls device_register() which initializes the kobj of
      the device. mdiobus_unregister() calls only device_del() so we have one
      reference left. That one is leaving with mdiobus_free() which is only
      called on remove.
      Since I don't see any reason why mdiobus_register()/mdiobus_unregister()
      should happen in ->open()/->close() I move them to probe & exit.
      Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03f80cc3
    • N
      sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4) · 5fa782c2
      Neil Horman 提交于
      Ok, version 4
      
      Change Notes:
      1) Minor cleanups, from Vlads notes
      
      Summary:
      
      Hey-
      	Recently, it was reported to me that the kernel could oops in the
      following way:
      
      <5> kernel BUG at net/core/skbuff.c:91!
      <5> invalid operand: 0000 [#1]
      <5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter
      ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U)
      vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5
      ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss
      snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore
      pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi
      mptbase sd_mod scsi_mod
      <5> CPU:    0
      <5> EIP:    0060:[<c02bff27>]    Not tainted VLI
      <5> EFLAGS: 00010216   (2.6.9-89.0.25.EL)
      <5> EIP is at skb_over_panic+0x1f/0x2d
      <5> eax: 0000002c   ebx: c033f461   ecx: c0357d96   edx: c040fd44
      <5> esi: c033f461   edi: df653280   ebp: 00000000   esp: c040fd40
      <5> ds: 007b   es: 007b   ss: 0068
      <5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0)
      <5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180
      e0c2947d
      <5>        00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004
      df653490
      <5>        00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
      00000004
      <5> Call Trace:
      <5>  [<e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp]
      <5>  [<e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp]
      <5>  [<e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp]
      <5>  [<e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp]
      <5>  [<e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp]
      <5>  [<e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp]
      <5>  [<e0c25333>] sctp_do_sm+0x41/0x77 [sctp]
      <5>  [<c01555a4>] cache_grow+0x140/0x233
      <5>  [<e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp]
      <5>  [<e0c2b863>] sctp_inq_push+0xe/0x10 [sctp]
      <5>  [<e0c34600>] sctp_rcv+0x454/0x509 [sctp]
      <5>  [<e084e017>] ipt_hook+0x17/0x1c [iptable_filter]
      <5>  [<c02d005e>] nf_iterate+0x40/0x81
      <5>  [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151
      <5>  [<c02e0c7f>] ip_local_deliver_finish+0xc6/0x151
      <5>  [<c02d0362>] nf_hook_slow+0x83/0xb5
      <5>  [<c02e0bb2>] ip_local_deliver+0x1a2/0x1a9
      <5>  [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151
      <5>  [<c02e103e>] ip_rcv+0x334/0x3b4
      <5>  [<c02c66fd>] netif_receive_skb+0x320/0x35b
      <5>  [<e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd]
      <5>  [<c02c67a4>] process_backlog+0x6c/0xd9
      <5>  [<c02c690f>] net_rx_action+0xfe/0x1f8
      <5>  [<c012a7b1>] __do_softirq+0x35/0x79
      <5>  [<c0107efb>] handle_IRQ_event+0x0/0x4f
      <5>  [<c01094de>] do_softirq+0x46/0x4d
      
      Its an skb_over_panic BUG halt that results from processing an init chunk in
      which too many of its variable length parameters are in some way malformed.
      
      The problem is in sctp_process_unk_param:
      if (NULL == *errp)
      	*errp = sctp_make_op_error_space(asoc, chunk,
      					 ntohs(chunk->chunk_hdr->length));
      
      	if (*errp) {
      		sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
      				 WORD_ROUND(ntohs(param.p->length)));
      		sctp_addto_chunk(*errp,
      			WORD_ROUND(ntohs(param.p->length)),
      				  param.v);
      
      When we allocate an error chunk, we assume that the worst case scenario requires
      that we have chunk_hdr->length data allocated, which would be correct nominally,
      given that we call sctp_addto_chunk for the violating parameter.  Unfortunately,
      we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error
      chunk, so the worst case situation in which all parameters are in violation
      requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.
      
      The result of this error is that a deliberately malformed packet sent to a
      listening host can cause a remote DOS, described in CVE-2010-1173:
      http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173
      
      I've tested the below fix and confirmed that it fixes the issue.  We move to a
      strategy whereby we allocate a fixed size error chunk and ignore errors we don't
      have space to report.  Tested by me successfully
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5fa782c2
    • B
      sfc: Change falcon_probe_board() to fail for unsupported boards · e41c11ee
      Ben Hutchings 提交于
      The driver needs specific PHY and board support code for each SFC4000
      board; there is no point trying to continue if it is missing.
      Currently unsupported boards can trigger an 'oops'.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e41c11ee
    • B
      sfc: Always close net device at the end of a disabling reset · f49a4589
      Ben Hutchings 提交于
      This fixes a regression introduced by commit
      eb9f6744 "sfc: Implement ethtool
      reset operation".
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f49a4589
    • B
      sfc: Wait at most 10ms for the MC to finish reading out MAC statistics · aabc5649
      Ben Hutchings 提交于
      The original code would wait indefinitely if MAC stats DMA failed.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aabc5649
    • V
      sctp: Fix oops when sending queued ASCONF chunks · c0786693
      Vlad Yasevich 提交于
      When we finish processing ASCONF_ACK chunk, we try to send
      the next queued ASCONF.  This action runs the sctp state
      machine recursively and it's not prepared to do so.
      
      kernel BUG at kernel/timer.c:790!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/module/ipv6/initstate
      Modules linked in: sha256_generic sctp libcrc32c ipv6 dm_multipath
      uinput 8139too i2c_piix4 8139cp mii i2c_core pcspkr virtio_net joydev
      floppy virtio_blk virtio_pci [last unloaded: scsi_wait_scan]
      
      Pid: 0, comm: swapper Not tainted 2.6.34-rc4 #15 /Bochs
      EIP: 0060:[<c044a2ef>] EFLAGS: 00010286 CPU: 0
      EIP is at add_timer+0xd/0x1b
      EAX: cecbab14 EBX: 000000f0 ECX: c0957b1c EDX: 03595cf4
      ESI: cecba800 EDI: cf276f00 EBP: c0957aa0 ESP: c0957aa0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=c0956000 task=c0988ba0 task.ti=c0956000)
      Stack:
       c0957ae0 d1851214 c0ab62e4 c0ab5f26 0500ffff 00000004 00000005 00000004
      <0> 00000000 d18694fd 00000004 1666b892 cecba800 cecba800 c0957b14
      00000004
      <0> c0957b94 d1851b11 ceda8b00 cecba800 cf276f00 00000001 c0957b14
      000000d0
      Call Trace:
       [<d1851214>] ? sctp_side_effects+0x607/0xdfc [sctp]
       [<d1851b11>] ? sctp_do_sm+0x108/0x159 [sctp]
       [<d1863386>] ? sctp_pname+0x0/0x1d [sctp]
       [<d1861a56>] ? sctp_primitive_ASCONF+0x36/0x3b [sctp]
       [<d185657c>] ? sctp_process_asconf_ack+0x2a4/0x2d3 [sctp]
       [<d184e35c>] ? sctp_sf_do_asconf_ack+0x1dd/0x2b4 [sctp]
       [<d1851ac1>] ? sctp_do_sm+0xb8/0x159 [sctp]
       [<d1863334>] ? sctp_cname+0x0/0x52 [sctp]
       [<d1854377>] ? sctp_assoc_bh_rcv+0xac/0xe1 [sctp]
       [<d1858f0f>] ? sctp_inq_push+0x2d/0x30 [sctp]
       [<d186329d>] ? sctp_rcv+0x797/0x82e [sctp]
      Tested-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NYuansong Qiao <ysqiao@research.ait.ie>
      Signed-off-by: NShuaijun Zhang <szhang@research.ait.ie>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0786693
    • W
      sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set · a8170c35
      Wei Yongjun 提交于
      When calculating the INIT/INIT-ACK chunk length, we should not
      only account the length of parameters, but also the parameters
      zero padding length, such as AUTH HMACS parameter and CHUNKS
      parameter. Without the parameters zero padding length we may get
      following oops.
      
      skb_over_panic: text:ce2068d2 len:130 put:6 head:cac3fe00 data:cac3fe00 tail:0xcac3fe82 end:0xcac3fe80 dev:<NULL>
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:127!
      invalid opcode: 0000 [#2] SMP
      last sysfs file: /sys/module/aes_generic/initstate
      Modules linked in: authenc ......
      
      Pid: 4102, comm: sctp_darn Tainted: G      D    2.6.34-rc2 #6
      EIP: 0060:[<c0607630>] EFLAGS: 00010282 CPU: 0
      EIP is at skb_over_panic+0x37/0x3e
      EAX: 00000078 EBX: c07c024b ECX: c07c02b9 EDX: cb607b78
      ESI: 00000000 EDI: cac3fe7a EBP: 00000002 ESP: cb607b74
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process sctp_darn (pid: 4102, ti=cb607000 task=cabdc990 task.ti=cb607000)
      Stack:
       c07c02b9 ce2068d2 00000082 00000006 cac3fe00 cac3fe00 cac3fe82 cac3fe80
      <0> c07c024b cac3fe7c cac3fe7a c0608dec ca986e80 ce2068d2 00000006 0000007a
      <0> cb8120ca ca986e80 cb812000 00000003 cb8120c4 ce208a25 cb8120ca cadd9400
      Call Trace:
       [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp]
       [<c0608dec>] ? skb_put+0x2e/0x32
       [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp]
       [<ce208a25>] ? sctp_make_init+0x279/0x28c [sctp]
       [<c0686a92>] ? apic_timer_interrupt+0x2a/0x30
       [<ce1fdc0b>] ? sctp_sf_do_prm_asoc+0x2b/0x7b [sctp]
       [<ce202823>] ? sctp_do_sm+0xa0/0x14a [sctp]
       [<ce2133b9>] ? sctp_pname+0x0/0x14 [sctp]
       [<ce211d72>] ? sctp_primitive_ASSOCIATE+0x2b/0x31 [sctp]
       [<ce20f3cf>] ? sctp_sendmsg+0x7a0/0x9eb [sctp]
       [<c064eb1e>] ? inet_sendmsg+0x3b/0x43
       [<c04244b7>] ? task_tick_fair+0x2d/0xd9
       [<c06031e1>] ? sock_sendmsg+0xa7/0xc1
       [<c0416afe>] ? smp_apic_timer_interrupt+0x6b/0x75
       [<c0425123>] ? dequeue_task_fair+0x34/0x19b
       [<c0446abb>] ? sched_clock_local+0x17/0x11e
       [<c052ea87>] ? _copy_from_user+0x2b/0x10c
       [<c060ab3a>] ? verify_iovec+0x3c/0x6a
       [<c06035ca>] ? sys_sendmsg+0x186/0x1e2
       [<c042176b>] ? __wake_up_common+0x34/0x5b
       [<c04240c2>] ? __wake_up+0x2c/0x3b
       [<c057e35c>] ? tty_wakeup+0x43/0x47
       [<c04430f2>] ? remove_wait_queue+0x16/0x24
       [<c0580c94>] ? n_tty_read+0x5b8/0x65e
       [<c042be02>] ? default_wake_function+0x0/0x8
       [<c0604e0e>] ? sys_socketcall+0x17f/0x1cd
       [<c040264c>] ? sysenter_do_call+0x12/0x22
      Code: 0f 45 de 53 ff b0 98 00 00 00 ff b0 94 ......
      EIP: [<c0607630>] skb_over_panic+0x37/0x3e SS:ESP 0068:cb607b74
      
      To reproduce:
      
      # modprobe sctp
      # echo 1 > /proc/sys/net/sctp/addip_enable
      # echo 1 > /proc/sys/net/sctp/auth_enable
      # sctp_test -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 800 -l
      # sctp_darn -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 900 -h 192.168.0.21 -p 800 -I -s -t
      sctp_darn ready to send...
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.0.21
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.1.21
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> snd=10
      
      ------------------------------------------------------------------
      eth0 has addresses: 3ffe:501:ffff:100:20c:29ff:fe4d:f37e and 192.168.0.21
      eth1 has addresses: 192.168.1.21
      ------------------------------------------------------------------
      Reported-by: NGeorge Cheimonidis <gchimon@gmail.com>
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8170c35
    • V
      sctp: per_cpu variables should be in bh_disabled section · 81419d86
      Vlad Yasevich 提交于
      Since the change of the atomics to percpu variables, we now
      have to disable BH in process context when touching percpu variables.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81419d86
    • V
      sctp: fix potential reference of a freed pointer · 0c42749c
      Vlad Yasevich 提交于
      When sctp attempts to update an assocition, it removes any
      addresses that were not in the updated INITs.  However, the loop
      may attempt to refrence a transport with address after removing it.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c42749c
    • W
      sctp: avoid irq lock inversion while call sk->sk_data_ready() · 561b1733
      Wei Yongjun 提交于
      sk->sk_data_ready() of sctp socket can be called from both BH and non-BH
      contexts, but the default sk->sk_data_ready(), sock_def_readable(), can
      not be used in this case. Therefore, we have to make a new function
      sctp_data_ready() to grab sk->sk_data_ready() with BH disabling.
      
      =========================================================
      [ INFO: possible irq lock inversion dependency detected ]
      2.6.33-rc6 #129
      ---------------------------------------------------------
      sctp_darn/1517 just changed the state of lock:
       (clock-AF_INET){++.?..}, at: [<c06aab60>] sock_def_readable+0x20/0x80
      but this lock took another, SOFTIRQ-unsafe lock in the past:
       (slock-AF_INET){+.-...}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
      1 lock held by sctp_darn/1517:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<cdfe363d>] sctp_sendmsg+0x23d/0xc00 [sctp]
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      561b1733
    • D
      Revert "tcp: bind() fix when many ports are bound" · 8d238b25
      David S. Miller 提交于
      This reverts two commits:
      
      fda48a0d
      tcp: bind() fix when many ports are bound
      
      and a follow-on fix for it:
      
      6443bb1f
      ipv6: Fix inet6_csk_bind_conflict()
      
      It causes problems with binding listening sockets when time-wait
      sockets from a previous instance still are alive.
      
      It's too late to keep fiddling with this so late in the -rc
      series, and we'll deal with it in net-next-2.6 instead.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d238b25
  13. 28 4月, 2010 3 次提交
    • E
      net/usb: add sierra_net.c driver · eb4fd8cd
      Elina Pasheva 提交于
      Re-submitted based on comments from netdev community.
      Summary of the changes:
      1. Improved error handling.
      2. Added the missing timeout arguments to usb_control_msg().
      
      The following is a new Linux driver which exposes certain models of Sierra
      Wireless modems to the operating system as Network Interface Cards (NICs).
      
      This driver requires a version of the sierra.c driver which supports
      blacklisting to work properly. The blacklist in sierra.c rejects the interfaces
      claimed by sierra_net.c. Likewise, the sierra_net.c driver only accepts
      (i.e. whitelists) the interface(s) used for USB-to-WWAN traffic.
      The version of sierra.c which supports blacklisting is
      available from the sierra wireless knowledge base page for older kernels. It is
      also available in Linux kernel starting from version 2.6.31.
      
      This driver works with all Sierra Wireless devices configured with PID=68A3
      like USB305, USB306 provided the corresponding firmware version is I2.0
      (for USB305) or M3.0 (for USB306) and later.
      This driver will not work with earlier firmware versions than the ones shown
      above. In this case the driver will issue an error message indicating
      incompatibility and will not serve the device's USB-to-WWAN interface.
      
      Sierra_net.c sits atop a pre-existing Linux driver called usbnet.c.
      A series of hook functions are provided in sierra_net.c which are called by
      usbnet.c in response to a particular condition such as receipt or transmission
      of a data packet. As such, usbnet.c does most of the work of making
      a modem appear to the system as a network device and for properly exchanging
      traffic between the USB subsystem and the Network card interface.
      Sierra_net.c is concerned with managing the data exchanged between the
      USB-to-WWAN interface and the upper layers of the operating system.
      Signed-off-by: NElina Pasheva <epasheva@sierrawireless.com>
      Signed-off-by: NRory Filer <rfiler@sierrawireless.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb4fd8cd
    • T
      cdc_ether: fix autosuspend for mbm devices · 55964d72
      Torgny Johansson 提交于
      Autosuspend works until you bring the wwan interface up, then the
      device does not enter autosuspend anymore.
      
      The following patch fixes the problem by setting the .manage_power
      field in the mbm_info struct to the same as in the cdc_info struct
      (cdc_manager_power).
      Signed-off-by: NTorgny Johansson <torgny.johansson@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55964d72
    • D
      bluetooth: handle l2cap_create_connless_pdu() errors · 477fffb0
      Dan Carpenter 提交于
      l2cap_create_connless_pdu() can sometimes return ERR_PTR(-ENOMEM) or
      ERR_PTR(-EFAULT).
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      477fffb0