1. 24 3月, 2011 7 次提交
  2. 23 3月, 2011 1 次提交
  3. 22 3月, 2011 13 次提交
    • M
      NET: smsc95xx: don't use stack for async writes to the device · 3c0f3c60
      Marc Zyngier 提交于
      The set_multicast operation performs asynchronous writes to the
      device, with some addresses pointing to the stack. Bad things may
      happen, and this is trapped CONFIG_DMA_API_DEBUG:
      
      [    5.237762] WARNING: at /build/buildd/linux-linaro-omap-2.6.38/lib/dma-debug.c:867 check_for_stack+0xd4/0x100()
      [    5.237792] ehci-omap ehci-omap.0: DMA-API: device driver maps memory fromstack [addr=d9c77dec]
      [    5.237792] Modules linked in: smsc95xx(+) usbnet twl6030_usb twl4030_pwrbutton leds_gpio omap_wdt omap2_mcspi
      [    5.237854] [<c006d618>] (unwind_backtrace+0x0/0xf8) from [<c00a6a14>] (warn_slowpath_common+0x54/0x64)
      [    5.237884] [<c00a6a14>] (warn_slowpath_common+0x54/0x64) from [<c00a6ab8>] (warn_slowpath_fmt+0x30/0x40)
      [    5.237915] [<c00a6ab8>] (warn_slowpath_fmt+0x30/0x40) from [<c034e9d8>] (check_for_stack+0xd4/0x100)
      [    5.237915] [<c034e9d8>] (check_for_stack+0xd4/0x100) from [<c034fea8>] (debug_dma_map_page+0xb4/0xdc)
      [    5.237976] [<c034fea8>] (debug_dma_map_page+0xb4/0xdc) from [<c04242f0>] (map_urb_for_dma+0x26c/0x304)
      [    5.237976] [<c04242f0>] (map_urb_for_dma+0x26c/0x304) from [<c0424594>] (usb_hcd_submit_urb+0x78/0x19c)
      [    5.238037] [<c0424594>] (usb_hcd_submit_urb+0x78/0x19c) from [<bf049c5c>] (smsc95xx_write_reg_async+0xb4/0x130 [smsc95xx])
      [    5.238067] [<bf049c5c>] (smsc95xx_write_reg_async+0xb4/0x130 [smsc95xx]) from [<bf049dd4>] (smsc95xx_set_multicast+0xfc/0x148 [smsc95xx])
      [    5.238098] [<bf049dd4>] (smsc95xx_set_multicast+0xfc/0x148 [smsc95xx]) from [<bf04a118>] (smsc95xx_reset+0x2f8/0x68c [smsc95xx])
      [    5.238128] [<bf04a118>] (smsc95xx_reset+0x2f8/0x68c [smsc95xx]) from [<bf04a8cc>] (smsc95xx_bind+0xcc/0x188 [smsc95xx])
      [    5.238159] [<bf04a8cc>] (smsc95xx_bind+0xcc/0x188 [smsc95xx]) from [<bf03ef1c>] (usbnet_probe+0x204/0x4c4 [usbnet])
      [    5.238220] [<bf03ef1c>] (usbnet_probe+0x204/0x4c4 [usbnet]) from [<c0429078>] (usb_probe_interface+0xe4/0x1c4)
      [    5.238250] [<c0429078>] (usb_probe_interface+0xe4/0x1c4) from [<c03a8770>] (really_probe+0x64/0x160)
      [    5.238250] [<c03a8770>] (really_probe+0x64/0x160) from [<c03a8a30>] (driver_probe_device+0x48/0x60)
      [    5.238281] [<c03a8a30>] (driver_probe_device+0x48/0x60) from [<c03a8ad4>] (__driver_attach+0x8c/0x90)
      [    5.238311] [<c03a8ad4>] (__driver_attach+0x8c/0x90) from [<c03a7b24>] (bus_for_each_dev+0x50/0x7c)
      [    5.238311] [<c03a7b24>] (bus_for_each_dev+0x50/0x7c) from [<c03a82ec>] (bus_add_driver+0x190/0x250)
      [    5.238311] [<c03a82ec>] (bus_add_driver+0x190/0x250) from [<c03a8cf8>] (driver_register+0x78/0x13c)
      [    5.238433] [<c03a8cf8>] (driver_register+0x78/0x13c) from [<c0428040>] (usb_register_driver+0x78/0x13c)
      [    5.238464] [<c0428040>] (usb_register_driver+0x78/0x13c) from [<c005b680>] (do_one_initcall+0x34/0x188)
      [    5.238494] [<c005b680>] (do_one_initcall+0x34/0x188) from [<c00e11f0>] (sys_init_module+0xb0/0x1c0)
      [    5.238525] [<c00e11f0>] (sys_init_module+0xb0/0x1c0) from [<c0065c40>] (ret_fast_syscall+0x0/0x30)
      
      Move the two offenders to the private structure which is kmalloc-ed,
      and thus safe.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c0f3c60
    • E
      veth: Fix the byte counters · 675071a2
      Eric W. Biederman 提交于
      Commit 44540960 "veth: move loopback logic to common location" introduced
      a bug in the packet counters.  I don't understand why that happened as it
      is not explained in the comments and the mut check in dev_forward_skb
      retains the assumption that skb->len is the total length of the packet.
      
      I just measured this emperically by setting up a veth pair between two
      noop network namespaces setting and attempting a telnet connection between
      the two.  I saw three packets in each direction and the byte counters were
      exactly 14*3 = 42 bytes high in each direction.  I got the actual
      packet lengths with tcpdump.
      
      So remove the extra ETH_HLEN from the veth byte count totals.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      675071a2
    • E
      macvlan: Fix use after free of struct macvlan_port. · d5cd9244
      Eric W. Biederman 提交于
      When the macvlan driver was extended to call unregisgter_netdevice_queue
      in 23289a37, a use after free of struct
      macvlan_port was introduced.  The code in dellink relied on unregister_netdevice
      actually unregistering the net device so it would be safe to free macvlan_port.
      
      Since unregister_netdevice_queue can just queue up the unregister instead of
      performing the unregiser immediately we free the macvlan_port too soon and
      then the code in macvlan_stop removes the macaddress for the set of macaddress
      to listen for and uses memory that has already been freed.
      
      To fix this add a reference count to track when it is safe to free the macvlan_port
      and move the call of macvlan_port_destroy into macvlan_uninit which is guaranteed
      to be called after the final macvlan_port_close.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5cd9244
    • J
      can: c_can: Do basic c_can configuration _before_ enabling the interrupts · 4f2d56c4
      Jan Altenberg 提交于
      I ran into some trouble while testing the SocketCAN driver for the BOSCH
      C_CAN controller. The interface is not correctly initialized, if I put
      some CAN traffic on the line, _while_ the interface is being started
      (which means: the interface doesn't come up correcty, if there's some RX
      traffic while doing 'ifconfig can0 up').
      
      The current implementation enables the controller interrupts _before_
      doing the basic c_can configuration. I think, this should be done the
      other way round.
      
      The patch below fixes things for me.
      Signed-off-by: NJan Altenberg <jan@linutronix.de>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Acked-by: NWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f2d56c4
    • M
      ath9k: Fix kernel panic in AR2427 · 61e1b0b0
      Mohammed Shafi Shajakhan 提交于
      Kernel panic occurs just after AR2427 establishes connection with AP.
      Unless aggregation is enabled we don't initialize the TID structure.
      Thus accesing the elements of the TID structure when aggregation is
      disabled, leads to NULL pointer dereferencing.
      
      [  191.320358] Call Trace:
      [  191.320364]  [<fd250ea7>] ? ath9k_tx+0xa7/0x200 [ath9k]
      [  191.320376]  [<fd1ec7fc>] ? __ieee80211_tx+0x5c/0x1e0 [mac80211]
      [  191.320386]  [<fd1edd2b>] ? ieee80211_tx+0x7b/0x90 [mac80211]
      [  191.320395]  [<fd1edddd>] ? ieee80211_xmit+0x9d/0x1d0 [mac80211]
      [  191.320401]  [<c014218f>] ? wake_up_state+0xf/0x20
      [  191.320405]  [<c015dbc8>] ? signal_wake_up+0x28/0x40
      [  191.320410]  [<c012a578>] ? default_spin_lock_flags+0x8/0x10
      [  191.320420]  [<fd1ee308>] ? ieee80211_subif_start_xmit+0x2e8/0x7c0
      [mac80211]
      [  191.320425]  [<c058f905>] ? do_page_fault+0x295/0x3a0
      [  191.320431]  [<c04c4a3d>] ? dev_hard_start_xmit+0x1ad/0x210
      [  191.320436]  [<c04d96b5>] ? sch_direct_xmit+0x105/0x170
      [  191.320445]  [<fd1f161a>] ? get_sta_flags+0x2a/0x40 [mac80211]
      [  191.320449]  [<c04c780f>] ? dev_queue_xmit+0x37f/0x4b0
      [  191.320452]  [<c04d75b0>] ? eth_header+0x0/0xb0
      [  191.320456]  [<c04cc479>] ? neigh_resolve_output+0xe9/0x310
      [  191.320461]  [<c053d295>] ? ip6_output_finish+0xa5/0x110
      [  191.320464]  [<c053e354>] ? ip6_output2+0x134/0x250
      [  191.320468]  [<c053f7dd>] ? ip6_output+0x6d/0x100
      [  191.320471]  [<c0559665>] ? mld_sendpack+0x395/0x3e0
      [  191.320475]  [<c0557f81>] ? add_grhead+0x31/0xa0
      [  191.320478]  [<c055a83c>] ? mld_send_cr+0x1bc/0x2b0
      [  191.320482]  [<c01535d9>] ? irq_exit+0x39/0x70
      [  191.320485]  [<c055a940>] ? mld_ifc_timer_expire+0x10/0x40
      [  191.320489]  [<c015b92e>] ? run_timer_softirq+0x13e/0x2c0
      [  191.320493]  [<c0103a30>] ? common_interrupt+0x30/0x40
      [  191.320498]  [<c055a930>] ? mld_ifc_timer_expire+0x0/0x40
      [  191.320502]  [<c0153358>] ? __do_softirq+0x98/0x1b0
      [  191.320506]  [<c01534b5>] ? do_softirq+0x45/0x50
      [  191.320509]  [<c0153605>] ? irq_exit+0x65/0x70
      [  191.320513]  [<c05917dc>] ? smp_apic_timer_interrupt+0x5c/0x8b
      [  191.320516]  [<c0103df1>] ? apic_timer_interrupt+0x31/0x40
      [  191.320521]  [<c016007b>] ? k_getrusage+0x12b/0x2f0
      [  191.320525]  [<c039e384>] ? acpi_idle_enter_simple+0x117/0x148
      [  191.320529]  [<c04a20da>] ? cpuidle_idle_call+0x7a/0x100
      [  191.320532]  [<c01021d4>] ? cpu_idle+0x94/0xd0
      [  191.320536]  [<c057ab88>] ? rest_init+0x58/0x60
      [  191.320541]  [<c07a58ec>] ? start_kernel+0x351/0x357
      [  191.320544]  [<c07a53c7>] ? unknown_bootoption+0x0/0x19e
      [  191.320548]  [<c07a50aa>] ? i386_start_kernel+0xaa/0xb1
      [  191.320550] Code: 03 66 3d 00 03 0f 84 7c 02 00 00 83 c3 18 0f b6 03
      8b 4d e0 89 c3 83 e3 0f 6b c3 48 89 5d d8 8d 04 06 8d 50 0c 89 55 d0 8b
      40 20 <8b> 00 3b 01 0f 85 8e 02 00 00 f6 47 20 40 0f 84 29 ff ff ff 8b
      [  191.320634] EIP: [<fd2586d4>] ath_tx_start+0x474/0x770 [ath9k] SS:ESP
      0068:c0761a90
      [  191.320642] CR2: 0000000000000000
      [  191.320647] ---[ end trace 9296ef23b9076ece ]---
      [  191.320650] Kernel panic - not syncing: Fatal exception in interrupt
      
      Cc: stable@kernel.org
      Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      61e1b0b0
    • I
      rtlwifi: Fix memset argument order · 6e9d592f
      Ilia Mirkin 提交于
      These were found using the following semantic match:
      // <smpl>
      @@expression E1; type T;@@
      * memset(E1, ... * sizeof(T) * ..., ...);
      // </smpl>
      
      Also take this opportunity to remove the unnecessary void* casts.
      Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
      Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6e9d592f
    • P
      rt2x00: Add unknown Toshiba device · 5da201a4
      Peter Lemenkov 提交于
      Add unknown Toshiba device, mentioned in rt3572sta sources, under
      CONFIG_RT2800USB_UNKNOWN
      Signed-off-by: NPeter Lemenkov <lemenkov@gmail.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5da201a4
    • P
      rt2x00: Add 2L Central Europe BV 8070 · 9a745972
      Peter Lemenkov 提交于
      Add 2L Central Europe BV 8070 under CONFIG_RT2800USB_UNKNOWN
      Signed-off-by: NPeter Lemenkov <lemenkov@gmail.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9a745972
    • P
      rt2x00: Add Planex Communications, Inc. RT8070 · 7a2a75bc
      Peter Lemenkov 提交于
      Add Planex Communications, Inc. RT8070 under CONFIG_RT2800USB_UNKNOWN
      Signed-off-by: NPeter Lemenkov <lemenkov@gmail.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7a2a75bc
    • P
      rt2x00: Add rt2870 device id · 2cea5b3c
      Peter Lemenkov 提交于
      Add ID for Asus USB-N11 Wi-FI adapter. Tested by me.
      Signed-off-by: NPeter Lemenkov <lemenkov@gmail.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2cea5b3c
    • J
      orinoco: Maintain lock until entry removed from list · 3bf184a7
      Joe Gunn 提交于
      Removing an entry from the scan_list should be performed while holding
      the lock.
      Signed-off-by: NJoseph J. Gunn <armadefuego@yahoo.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3bf184a7
    • D
      iwlwifi: missing unlock on error path · f8a22a2b
      Dan Carpenter 提交于
      We should unlock here instead of returning -EINVAL directly.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f8a22a2b
    • T
      zd1211rw: TrendNet TEW-509UB id added · 9011cd25
      Tõnu Samuel 提交于
      Signed-off-by: NTõnu Samuel <tonu@jes.ee>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9011cd25
  4. 20 3月, 2011 3 次提交
    • D
      niu: Rename NIU parent platform device name to fix conflict. · a769f496
      David S. Miller 提交于
      When the OF device driver bits were converted over to the platform
      device infrastructure in commit 74888760
      ("dt/net: Eliminate users of of_platform_{,un}register_driver") we
      inadvertantly created probing problems in the OF case.
      
      The NIU driver creates a dummy platform device to represent the
      board that contains one or more child NIU devices.  Unfortunately
      we use the same name, "niu", as the OF device driver itself uses.
      
      The result is that we try to probe the dummy "niu" parent device we
      create, and since it has a NULL ofdevice pointer etc. everything
      explodes:
      
      [783019.128243] niu: niu.c:v1.1 (Apr 22, 2010)
      [783019.128810] Unable to handle kernel NULL pointer dereference
      [783019.128949] tsk->{mm,active_mm}->context = 000000000000039e
      [783019.129078] tsk->{mm,active_mm}->pgd = fffff803afc5a000
      [783019.129206]               \|/ ____ \|/
      [783019.129213]               "@'/ .. \`@"
      [783019.129220]               /_| \__/ |_\
      [783019.129226]                  \__U_/
      [783019.129378] modprobe(2004): Oops [#1]
      [783019.129423] TSTATE: 0000000011001602 TPC: 0000000010052ff8 TNPC: 000000000061bbb4 Y: 00000000    Not tainted
      [783019.129542] TPC: <niu_of_probe+0x3c/0x2dc [niu]>
      [783019.129624] g0: 8080000000000000 g1: 0000000000000000 g2: 0000000010056000 g3: 0000000000000002
      [783019.129733] g4: fffff803fc1da0c0 g5: fffff800441e2000 g6: fffff803fba84000 g7: 0000000000000000
      [783019.129842] o0: fffff803fe7df010 o1: 0000000010055700 o2: 0000000000000000 o3: fffff803fbacaca0
      [783019.129951] o4: 0000000000000080 o5: 0000000000777908 sp: fffff803fba866e1 ret_pc: 0000000010052ff4
      [783019.130083] RPC: <niu_of_probe+0x38/0x2dc [niu]>
      [783019.130165] l0: fffff803fe7df010 l1: fffff803fbacafc0 l2: fffff803fbacaca0 l3: ffffffffffffffed
      [783019.130273] l4: 0000000000000000 l5: 000000007fffffff l6: fffff803fba86f40 l7: 0000000000000001
      [783019.130382] i0: fffff803fe7df000 i1: fffff803fc20aba0 i2: 0000000000000000 i3: 0000000000000001
      [783019.130490] i4: 0000000000000000 i5: 0000000000000000 i6: fffff803fba867a1 i7: 000000000062038c
      [783019.130614] I7: <platform_drv_probe+0xc/0x20>
      
      Fix by simply renaming the parent device to "niu-board".
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a769f496
    • E
      r8169: fix a bug in rtl8169_init_phy() · b26fa4e0
      Eric Dumazet 提交于
      commit 54405cde (r8169: support control of advertising.)
      introduced a bug in rtl8169_init_phy()
      Reported-by: NPiotr Hosowicz <piotr@hosowicz.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: Francois Romieu <romieu@fr.zoreil.com>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Tested-by: NPiotr Hosowicz <piotr@hosowicz.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b26fa4e0
    • N
      dadaa10b
  5. 19 3月, 2011 2 次提交
  6. 17 3月, 2011 9 次提交
  7. 16 3月, 2011 5 次提交
    • I
      xen network backend driver · f942dc25
      Ian Campbell 提交于
      netback is the host side counterpart to the frontend driver in
      drivers/net/xen-netfront.c. The PV protocol is also implemented by
      frontend drivers in other OSes too, such as the BSDs and even Windows.
      
      The patch is based on the driver from the xen.git pvops kernel tree but
      has been put through the checkpatch.pl wringer plus several manual
      cleanup passes and review iterations. The driver has been moved from
      drivers/xen/netback to drivers/net/xen-netback.
      
      One major change from xen.git is that the guest transmit path (i.e. what
      looks like receive to netback) has been significantly reworked to remove
      the dependency on the out of tree PageForeign page flag (a core kernel
      patch which enables a per page destructor callback on the final
      put_page). This page flag was used in order to implement a grant map
      based transmit path (where guest pages are mapped directly into SKB
      frags). Instead this version of netback uses grant copy operations into
      regular memory belonging to the backend domain. Reinstating the grant
      map functionality is something which I would like to revisit in the
      future.
      
      Note that this driver depends on 2e820f58 "xen/irq: implement
      bind_interdomain_evtchn_to_irqhandler for backend drivers" which is in
      linux next via the "xen-two" tree and is intended for the 2.6.39 merge
      window:
              git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/backends
      this branch has only that single commit since 2.6.38-rc2 and is safe for
      cross merging into the net branch.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f942dc25
    • P
      bonding: Improve syslog message at device creation time · 5f86cad1
      Phil Oester 提交于
      When the bonding module is loaded, it creates bond0 by default.
      Then, when attempting to create bond0, the following messages
      are printed to syslog:
      
          kernel: bonding: bond0 is being created...
          kernel: bonding: Bond creation failed.
      
      Which seems to indicate a problem, when in reality there is no
      problem.  Since the actual error code is passed down from bond_create,
      make use of it to print a bit less ominous message:
      
          kernel: bonding: bond0 is being created...
          kernel: bond0 already exists.
      Signed-off-by: NPhil Oester <kernel@linuxace.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f86cad1
    • P
      bonding: Call netif_carrier_off after register_netdevice · e826eafa
      Phil Oester 提交于
      Bringing up a bond interface with all network cables disconnected
      does not properly set the interface as DOWN because the call to
      netif_carrier_off occurs too early in bond_init.  The call needs
      to occur after register_netdevice has set dev->reg_state to
      NETREG_REGISTERED, so that netif_carrier_off will trigger the
      call to linkwatch_fire_event.
      Signed-off-by: NPhil Oester <kernel@linuxace.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e826eafa
    • P
      bonding: Incorrect TX queue offset · fd0e435b
      Phil Oester 提交于
      When packets come in from a device with >= 16 receive queues
      headed out a bonding interface, syslog gets filled with this:
      
          kernel: bond0 selects TX queue 16, but real number of TX queues is 16
      
      because queue_mapping is offset by 1.  Adjust return value
      to account for the offset.
      
      This is a revision of my earlier patch (which did not use the
      skb_rx_queue_* helpers - thanks to Ben for the suggestion).
      Andy submitted a similar patch which emits a pr_warning on
      invalid queue selection, but I believe the log spew is
      not useful.  We can revisit that question in the future,
      but in the interim I believe fixing the core problem is
      worthwhile.
      Signed-off-by: NPhil Oester <kernel@linuxace.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd0e435b
    • P
      be2net: Fix UDP packet detected status in RX compl · 9ecb42fd
      Padmanabh Ratnakar 提交于
      Status of UDP packet detection not getting populated in RX completion
      structure. This is required in csum_passed() routine.
      Signed-off-by: NPadmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ecb42fd