1. 08 1月, 2014 2 次提交
    • E
      tipc: correctly unlink packets from deferred packet queue · 732256b9
      Erik Hugne 提交于
      When we pull a received packet from a link's 'deferred packets' queue
      for processing, its 'next' pointer is not cleared, and still refers to
      the next packet in that queue, if any. This is incorrect, but caused
      no harm before commit 40ba3cdf ("tipc:
      message reassembly using fragment chain") was introduced. After that
      commit, it may sometimes lead to the following oops:
      
      general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      Modules linked in: tipc
      CPU: 4 PID: 0 Comm: swapper/4 Tainted: G        W 3.13.0-rc2+ #6
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      task: ffff880017af4880 ti: ffff880017aee000 task.ti: ffff880017aee000
      RIP: 0010:[<ffffffff81710694>]  [<ffffffff81710694>] skb_try_coalesce+0x44/0x3d0
      RSP: 0018:ffff880016603a78  EFLAGS: 00010212
      RAX: 6b6b6b6bd6d6d6d6 RBX: ffff880013106ac0 RCX: ffff880016603ad0
      RDX: ffff880016603ad7 RSI: ffff88001223ed00 RDI: ffff880013106ac0
      RBP: ffff880016603ab8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000000 R12: ffff88001223ed00
      R13: ffff880016603ad0 R14: 000000000000058c R15: ffff880012297650
      FS:  0000000000000000(0000) GS:ffff880016600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000805b000 CR3: 0000000011f5d000 CR4: 00000000000006e0
      Stack:
       ffff880016603a88 ffffffff810a38ed ffff880016603aa8 ffff88001223ed00
       0000000000000001 ffff880012297648 ffff880016603b68 ffff880012297650
       ffff880016603b08 ffffffffa0006c51 ffff880016603b08 00ffffffa00005fc
      Call Trace:
       <IRQ>
       [<ffffffff810a38ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffffa0006c51>] tipc_link_recv_fragment+0xd1/0x1b0 [tipc]
       [<ffffffffa0007214>] tipc_recv_msg+0x4e4/0x920 [tipc]
       [<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
       [<ffffffffa000177c>] tipc_l2_rcv_msg+0xcc/0x250 [tipc]
       [<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
       [<ffffffff8171e65b>] __netif_receive_skb_core+0x80b/0xd00
       [<ffffffff8171df94>] ? __netif_receive_skb_core+0x144/0xd00
       [<ffffffff8171eb76>] __netif_receive_skb+0x26/0x70
       [<ffffffff8171ed6d>] netif_receive_skb+0x2d/0x200
       [<ffffffff8171fe70>] napi_gro_receive+0xb0/0x130
       [<ffffffff815647c2>] e1000_clean_rx_irq+0x2c2/0x530
       [<ffffffff81565986>] e1000_clean+0x266/0x9c0
       [<ffffffff81985f7b>] ? notifier_call_chain+0x2b/0x160
       [<ffffffff8171f971>] net_rx_action+0x141/0x310
       [<ffffffff81051c1b>] __do_softirq+0xeb/0x480
       [<ffffffff819817bb>] ? _raw_spin_unlock+0x2b/0x40
       [<ffffffff810b8c42>] ? handle_fasteoi_irq+0x72/0x100
       [<ffffffff81052346>] irq_exit+0x96/0xc0
       [<ffffffff8198cbc3>] do_IRQ+0x63/0xe0
       [<ffffffff81981def>] common_interrupt+0x6f/0x6f
       <EOI>
      
      This happens when the last fragment of a message has passed through the
      the receiving link's 'deferred packets' queue, and at least one other
      packet was added to that queue while it was there. After the fragment
      chain with the complete message has been successfully delivered to the
      receiving socket, it is released. Since 'next' pointer of the last
      fragment in the released chain now is non-NULL, we get the crash shown
      above.
      
      We fix this by clearing the 'next' pointer of all received packets,
      including those being pulled from the 'deferred' queue, before they
      undergo any further processing.
      
      Fixes: 40ba3cdf ("tipc: message reassembly using fragment chain")
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reported-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      732256b9
    • L
      ipv6: pcpu_tstats.syncp should be initialised in ip6_vti.c · 657e5d19
      Li RongQing 提交于
      initialise pcpu_tstats.syncp to kill the calltrace
      [   11.973950] Call Trace:
      [   11.973950]  [<819bbaff>] dump_stack+0x48/0x60
      [   11.973950]  [<819bbaff>] dump_stack+0x48/0x60
      [   11.973950]  [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
      [   11.973950]  [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
      [   11.973950]  [<81079fa7>] lock_acquire+0x77/0xa0
      [   11.973950]  [<81079fa7>] lock_acquire+0x77/0xa0
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
      [   11.973950]  [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<811cf8c1>] ? __nla_reserve+0x21/0xd0
      [   11.973950]  [<811cf8c1>] ? __nla_reserve+0x21/0xd0
      [   11.973950]  [<817ca7ab>] dev_get_stats+0xcb/0x130
      [   11.973950]  [<817ca7ab>] dev_get_stats+0xcb/0x130
      [   11.973950]  [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
      [   11.973950]  [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
      [   11.973950]  [<810352e0>] ? kvm_clock_read+0x20/0x30
      [   11.973950]  [<810352e0>] ? kvm_clock_read+0x20/0x30
      [   11.973950]  [<81008e38>] ? sched_clock+0x8/0x10
      [   11.973950]  [<81008e38>] ? sched_clock+0x8/0x10
      [   11.973950]  [<8106ba45>] ? sched_clock_local+0x25/0x170
      [   11.973950]  [<8106ba45>] ? sched_clock_local+0x25/0x170
      [   11.973950]  [<810da6bd>] ? __kmalloc+0x3d/0x90
      [   11.973950]  [<810da6bd>] ? __kmalloc+0x3d/0x90
      [   11.973950]  [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
      [   11.973950]  [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
      [   11.973950]  [<810da81a>] ? slob_alloc_node+0x2a/0x60
      [   11.973950]  [<810da81a>] ? slob_alloc_node+0x2a/0x60
      [   11.973950]  [<817b919a>] ? __alloc_skb+0x6a/0x2b0
      [   11.973950]  [<817b919a>] ? __alloc_skb+0x6a/0x2b0
      [   11.973950]  [<817d8795>] rtmsg_ifinfo+0x65/0xe0
      [   11.973950]  [<817d8795>] rtmsg_ifinfo+0x65/0xe0
      [   11.973950]  [<817cbd31>] register_netdevice+0x531/0x5a0
      [   11.973950]  [<817cbd31>] register_netdevice+0x531/0x5a0
      [   11.973950]  [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
      [   11.973950]  [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
      [   11.973950]  [<817cbdb6>] register_netdev+0x16/0x30
      [   11.973950]  [<817cbdb6>] register_netdev+0x16/0x30
      [   11.973950]  [<81f574a6>] vti6_init_net+0x1c4/0x1d4
      [   11.973950]  [<81f574a6>] vti6_init_net+0x1c4/0x1d4
      [   11.973950]  [<81f573af>] ? vti6_init_net+0xcd/0x1d4
      [   11.973950]  [<81f573af>] ? vti6_init_net+0xcd/0x1d4
      [   11.973950]  [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
      [   11.973950]  [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
      [   11.973950]  [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
      [   11.973950]  [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
      [   11.973950]  [<817c18d1>] register_pernet_device+0x21/0x60
      [   11.973950]  [<817c18d1>] register_pernet_device+0x21/0x60
      [   11.973950]  [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
      [   11.973950]  [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
      [   11.973950]  [<81f574c7>] vti6_tunnel_init+0x11/0x68
      [   11.973950]  [<81f574c7>] vti6_tunnel_init+0x11/0x68
      [   11.973950]  [<81f572a1>] ? mip6_init+0x73/0xb4
      [   11.973950]  [<81f572a1>] ? mip6_init+0x73/0xb4
      [   11.973950]  [<81f0cba4>] do_one_initcall+0xbb/0x15b
      [   11.973950]  [<81f0cba4>] do_one_initcall+0xbb/0x15b
      [   11.973950]  [<811a00d8>] ? sha_transform+0x528/0x1150
      [   11.973950]  [<811a00d8>] ? sha_transform+0x528/0x1150
      [   11.973950]  [<81f0c544>] ? repair_env_string+0x12/0x51
      [   11.973950]  [<81f0c544>] ? repair_env_string+0x12/0x51
      [   11.973950]  [<8105c30d>] ? parse_args+0x2ad/0x440
      [   11.973950]  [<8105c30d>] ? parse_args+0x2ad/0x440
      [   11.973950]  [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
      [   11.973950]  [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
      [   11.973950]  [<81f0cd27>] kernel_init_freeable+0xe3/0x182
      [   11.973950]  [<81f0cd27>] kernel_init_freeable+0xe3/0x182
      [   11.973950]  [<81f0c532>] ? do_early_param+0x7a/0x7a
      [   11.973950]  [<81f0c532>] ? do_early_param+0x7a/0x7a
      [   11.973950]  [<819b5b1b>] kernel_init+0xb/0x100
      [   11.973950]  [<819b5b1b>] kernel_init+0xb/0x100
      [   11.973950]  [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
      [   11.973950]  [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
      [   11.973950]  [<819b5b10>] ? rest_init+0xc0/0xc0
      [   11.973950]  [<819b5b10>] ? rest_init+0xc0/0xc0
      
      Before 469bdcef ("ipv6: fix the use of pcpu_tstats in ip6_vti.c"),
      the pcpu_tstats.syncp is not used to pretect the 64bit elements of
      pcpu_tstats, so not appear this calltrace.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      657e5d19
  2. 07 1月, 2014 11 次提交
    • L
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · ef350bb7
      Linus Torvalds 提交于
      Pull ext4 bugfix from Ted Ts'o:
       "Fix a regression introduced in v3.13-rc6"
      
      * tag 'ext4_for_linus_stable' of http://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: fix bigalloc regression
      ef350bb7
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · a707271a
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
       "I'm hoping this is the very last batch of networking fixes for 3.13,
        here goes nothing:
      
         1) Fix crashes in VLAN's header_ops passthru.
      
         2) Bridge multicast code needs to use BH spinlocks to prevent
            deadlocks with timers.  From Curt Brune.
      
         3) ipv6 tunnels lack proper synchornization when updating percpu
            statistics.  From Li RongQing.
      
         4) Fixes to bnx2x driver from Yaniv Rosner, Dmitry Kravkov and Michal
            Kalderon.
      
         5) Avoid undefined operator evaluation order in llc code, from Daniel
            Borkmann.
      
         6) Error paths in various GSO offload paths do not unwind properly,
            in particular they must undo any modifications they have made to
            the SKB.  From Wei-Chun Chao.
      
         7) Fix RX refill races during restore in virtio-net, from Jason Wang.
      
         8) Fix SKB use after free in LLC code, from Daniel Borkmann.
      
         9) Missing unlock and OOPS in netpoll code when VLAN tag handling
            fails.
      
        10) Fix vxlan device attachment wrt ipv6, from Fan Du.
      
        11) Don't allow creating infiniband links to non-infiniband devices,
            from Hangbin Liu.
      
        12) Revert FEC phy reset active low change, it breaks things.  From
            Fabio Estevam.
      
        13) Fix header pointer handling in 6lowpan header building code, from
            Daniel Borkmann.
      
        14) Fix RSS handling in be2net driver, from Vasundhara Volam.
      
        15) Fix modem port indexing in HSO driver, from Dan Williams"
      
      * http://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (38 commits)
        bridge: use spin_lock_bh() in br_multicast_set_hash_max
        ipv6: don't install anycast address for /128 addresses on routers
        hso: fix handling of modem port SERIAL_STATE notifications
        isdn: Drop big endian cpp checks from telespci and hfc_pci drivers
        be2net: fix max_evt_qs calculation for BE3 in SR-IOV config
        be2net: increase the timeout value for loopback-test FW cmd
        be2net: disable RSS when number of RXQs is reduced to 1 via set-channels
        xen-netback: Include header for vmalloc
        net: 6lowpan: fix lowpan_header_create non-compression memcpy call
        fec: Revert "fec: Do not assume that PHY reset is active low"
        bnx2x: fix VLAN configuration for VFs.
        bnx2x: fix AFEX memory overflow
        bnx2x: Clean before update RSS arrives
        bnx2x: Correct number of MSI-X vectors for VFs
        bnx2x: limit number of interrupt vectors for 57711
        qlcnic: Fix bug in Tx completion path
        infiniband: make sure the src net is infiniband when create new link
        {vxlan, inet6} Mark vxlan_dev flags with VXLAN_F_IPV6 properly
        cxgb4: allow large buffer size to have page size
        netpoll: Fix missing TXQ unlock and and OOPS.
        ...
      a707271a
    • C
      bridge: use spin_lock_bh() in br_multicast_set_hash_max · fe0d692b
      Curt Brune 提交于
      br_multicast_set_hash_max() is called from process context in
      net/bridge/br_sysfs_br.c by the sysfs store_hash_max() function.
      
      br_multicast_set_hash_max() calls spin_lock(&br->multicast_lock),
      which can deadlock the CPU if a softirq that also tries to take the
      same lock interrupts br_multicast_set_hash_max() while the lock is
      held .  This can happen quite easily when any of the bridge multicast
      timers expire, which try to take the same lock.
      
      The fix here is to use spin_lock_bh(), preventing other softirqs from
      executing on this CPU.
      
      Steps to reproduce:
      
      1. Create a bridge with several interfaces (I used 4).
      2. Set the "multicast query interval" to a low number, like 2.
      3. Enable the bridge as a multicast querier.
      4. Repeatedly set the bridge hash_max parameter via sysfs.
      
        # brctl addbr br0
        # brctl addif br0 eth1 eth2 eth3 eth4
        # brctl setmcqi br0 2
        # brctl setmcquerier br0 1
      
        # while true ; do echo 4096 > /sys/class/net/br0/bridge/hash_max; done
      Signed-off-by: NCurt Brune <curt@cumulusnetworks.com>
      Signed-off-by: NScott Feldman <sfeldma@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe0d692b
    • H
      ipv6: don't install anycast address for /128 addresses on routers · 88ad3149
      Hannes Frederic Sowa 提交于
      It does not make sense to create an anycast address for an /128-prefix.
      Suppress it.
      
      As 32019e65 ("ipv6: Do not leave router anycast address for /127
      prefixes.") shows we also may not leave them, because we could accidentally
      remove an anycast address the user has allocated or got added via another
      prefix.
      
      Cc: François-Xavier Le Bail <fx.lebail@yahoo.com>
      Cc: Thomas Haller <thaller@redhat.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88ad3149
    • D
      hso: fix handling of modem port SERIAL_STATE notifications · e5e97ee9
      Dan Williams 提交于
      The existing serial state notification handling expected older Option
      devices, having a hardcoded assumption that the Modem port was always
      USB interface #2.  That isn't true for devices from the past few years.
      
      hso_serial_state_notification is a local cache of a USB Communications
      Interface Class SERIAL_STATE notification from the device, and the
      USB CDC specification (section 6.3, table 67 "Class-Specific Notifications")
      defines wIndex as the USB interface the event applies to.  For hso
      devices this will always be the Modem port, as the Modem port is the
      only port which is set up to receive them by the driver.
      
      So instead of always expecting USB interface #2, instead validate the
      notification with the actual USB interface number of the Modem port.
      Signed-off-by: NDan Williams <dcbw@redhat.com>
      Tested-by: NH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5e97ee9
    • G
      isdn: Drop big endian cpp checks from telespci and hfc_pci drivers · 22d3b76e
      Guenter Roeck 提交于
      With arm:allmodconfig, building the Teles PCI driver fails with
      
      telespci.c:294:2: error: #error "not running on big endian machines now"
      
      Similar, building the driver for HFC PCI-Bus cards fails with
      
      hfc_pci.c:1647:2: error: #error "not running on big endian machines now"
      
      Remove the big endian cpp check from both drivers to fix the build errors.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22d3b76e
    • E
      ext4: fix bigalloc regression · d0abafac
      Eric Whitney 提交于
      Commit f5a44db5 introduced a regression on filesystems created with
      the bigalloc feature (cluster size > blocksize).  It causes xfstests
      generic/006 and /013 to fail with an unexpected JBD2 failure and
      transaction abort that leaves the test file system in a read only state.
      Other xfstests run on bigalloc file systems are likely to fail as well.
      
      The cause is the accidental use of a cluster mask where a cluster
      offset was needed in ext4_ext_map_blocks().
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      d0abafac
    • D
      Merge branch 'be2net' · ce088848
      David S. Miller 提交于
      Sathya Perla says:
      
      ====================
      be2net: patch set
      
      Pls apply the following bug fixes to the 'net' tree. Thanks.
      
      Suresh Reddy (2):
        be2net: increase the timeout value for loopback-test FW cmd
        be2net: fix max_evt_qs calculation for BE3 in SR-IOV config
      
      Vasundhara Volam (1):
        be2net: disable RSS when number of RXQs is reduced to 1 via
          set-channels
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce088848
    • S
      be2net: fix max_evt_qs calculation for BE3 in SR-IOV config · e3dc867c
      Suresh Reddy 提交于
      The driver wrongly assumes 16 EQs/vectors are available for each BE3 PF.
      When SR-IOV is enabled, a BE3 PF can support only a max of 8 EQs.
      Signed-off-by: NSuresh Reddy <suresh.reddy@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3dc867c
    • S
      be2net: increase the timeout value for loopback-test FW cmd · 5eeff635
      Suresh Reddy 提交于
      The loopback test FW cmd may need upto 15 seconds to complete on
      certain PHYs. This patch also fixes the name of the completion variable
      used to synchronize FW cmd completions as it not used by the flashing
      cmd alone anymore.
      Signed-off-by: NSuresh Reddy <suresh.reddy@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5eeff635
    • V
      be2net: disable RSS when number of RXQs is reduced to 1 via set-channels · da1388d6
      Vasundhara Volam 提交于
      When *only* the default RXQ is used, the RSS policy must be disabled so
      that all IP and no-IP traffic is placed into the default RXQ. If not,
      IP traffic is dropped.
      
      Also, issue the RSS_CONFIG cmd only if FW advertises RSS capability for
      the interface.
      Signed-off-by: NVasundhara Volam <vasundhara.volam@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da1388d6
  3. 06 1月, 2014 10 次提交
  4. 05 1月, 2014 8 次提交
  5. 04 1月, 2014 6 次提交
    • S
      qlcnic: Fix bug in Tx completion path · a02bdd42
      Shahed Shaikh 提交于
      o Driver is using common tx_clean_lock for all Tx queues. This patch
        adds per queue tx_clean_lock.
      o Driver is not updating sw_consumer while processing Tx completion
        when interface is going down. Fixed in this patch.
      Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
      Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a02bdd42
    • H
      infiniband: make sure the src net is infiniband when create new link · 0d68fc4f
      Hangbin Liu 提交于
      When we create a new infiniband link with uninfiniband device, e.g. `ip link
      add link em1 type ipoib pkey 0x8001`. We will get a NULL pointer dereference
      cause other dev like Ethernet don't have struct ib_device.
      
      The code path is:
      rtnl_newlink
        |-- ipoib_new_child_link
              |-- __ipoib_vlan_add
                    |-- ipoib_set_dev_features
                          |-- ib_query_device
      
      Fix this bug by make sure the src net is infiniband when create new link.
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d68fc4f
    • F
      {vxlan, inet6} Mark vxlan_dev flags with VXLAN_F_IPV6 properly · 7bda701e
      fan.du 提交于
      Even if user doesn't supply the physical netdev to attach vxlan dev
      to, and at the same time user want to vxlan sit top of IPv6, mark
      vxlan_dev flags with VXLAN_F_IPV6 to create IPv6 based socket.
      Otherwise kernel crashes safely every time spitting below messages,
      
      Steps to reproduce:
      ip link add vxlan0 type vxlan id 42 group ff0e::110
      ip link set vxlan0 up
      
      [   62.656266] BUG: unable to handle kernel NULL pointer dereference[   62.656320] ip (3008) used greatest stack depth: 3912 bytes left
       at 0000000000000046
      [   62.656423] IP: [<ffffffff816d822d>] ip6_route_output+0xbd/0xe0
      [   62.656525] PGD 2c966067 PUD 2c9a2067 PMD 0
      [   62.656674] Oops: 0000 [#1] SMP
      [   62.656781] Modules linked in: vxlan netconsole deflate zlib_deflate af_key
      [   62.657083] CPU: 1 PID: 2128 Comm: whoopsie Not tainted 3.12.0+ #182
      [   62.657083] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
      [   62.657083] task: ffff88002e2335d0 ti: ffff88002c94c000 task.ti: ffff88002c94c000
      [   62.657083] RIP: 0010:[<ffffffff816d822d>]  [<ffffffff816d822d>] ip6_route_output+0xbd/0xe0
      [   62.657083] RSP: 0000:ffff88002fd038f8  EFLAGS: 00210296
      [   62.657083] RAX: 0000000000000000 RBX: ffff88002fd039e0 RCX: 0000000000000000
      [   62.657083] RDX: ffff88002fd0eb68 RSI: ffff88002fd0d278 RDI: ffff88002fd0d278
      [   62.657083] RBP: ffff88002fd03918 R08: 0000000002000000 R09: 0000000000000000
      [   62.657083] R10: 00000000000001ff R11: 0000000000000000 R12: 0000000000000001
      [   62.657083] R13: ffff88002d96b480 R14: ffffffff81c8e2c0 R15: 0000000000000001
      [   62.657083] FS:  0000000000000000(0000) GS:ffff88002fd00000(0063) knlGS:00000000f693b740
      [   62.657083] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      [   62.657083] CR2: 0000000000000046 CR3: 000000002c9d2000 CR4: 00000000000006e0
      [   62.657083] Stack:
      [   62.657083]  ffff88002fd03a40 ffffffff81c8e2c0 ffff88002fd039e0 ffff88002d96b480
      [   62.657083]  ffff88002fd03958 ffffffff816cac8b ffff880019277cc0 ffff8800192b5d00
      [   62.657083]  ffff88002d5bc000 ffff880019277cc0 0000000000001821 0000000000000001
      [   62.657083] Call Trace:
      [   62.657083]  <IRQ>
      [   62.657083]  [<ffffffff816cac8b>] ip6_dst_lookup_tail+0xdb/0xf0
      [   62.657083]  [<ffffffff816caea0>] ip6_dst_lookup+0x10/0x20
      [   62.657083]  [<ffffffffa0020c13>] vxlan_xmit_one+0x193/0x9c0 [vxlan]
      [   62.657083]  [<ffffffff8137b3b7>] ? account+0xc7/0x1f0
      [   62.657083]  [<ffffffffa0021513>] vxlan_xmit+0xd3/0x400 [vxlan]
      [   62.657083]  [<ffffffff8161390d>] dev_hard_start_xmit+0x49d/0x5e0
      [   62.657083]  [<ffffffff81613d29>] dev_queue_xmit+0x2d9/0x480
      [   62.657083]  [<ffffffff817cb854>] ? _raw_write_unlock_bh+0x14/0x20
      [   62.657083]  [<ffffffff81630565>] ? eth_header+0x35/0xe0
      [   62.657083]  [<ffffffff8161bc5e>] neigh_resolve_output+0x11e/0x1e0
      [   62.657083]  [<ffffffff816ce0e0>] ? ip6_fragment+0xad0/0xad0
      [   62.657083]  [<ffffffff816cb465>] ip6_finish_output2+0x2f5/0x470
      [   62.657083]  [<ffffffff816ce166>] ip6_finish_output+0x86/0xc0
      [   62.657083]  [<ffffffff816ce218>] ip6_output+0x78/0xb0
      [   62.657083]  [<ffffffff816eadd6>] mld_sendpack+0x256/0x2a0
      [   62.657083]  [<ffffffff816ebd8c>] mld_ifc_timer_expire+0x17c/0x290
      [   62.657083]  [<ffffffff816ebc10>] ? igmp6_timer_handler+0x80/0x80
      [   62.657083]  [<ffffffff816ebc10>] ? igmp6_timer_handler+0x80/0x80
      [   62.657083]  [<ffffffff81051065>] call_timer_fn+0x45/0x150
      [   62.657083]  [<ffffffff816ebc10>] ? igmp6_timer_handler+0x80/0x80
      [   62.657083]  [<ffffffff81052353>] run_timer_softirq+0x1f3/0x2a0
      [   62.657083]  [<ffffffff8102dfd8>] ? lapic_next_event+0x18/0x20
      [   62.657083]  [<ffffffff8109e36f>] ? clockevents_program_event+0x6f/0x110
      [   62.657083]  [<ffffffff8104a2f6>] __do_softirq+0xd6/0x2b0
      [   62.657083]  [<ffffffff8104a75e>] irq_exit+0x7e/0xa0
      [   62.657083]  [<ffffffff8102ea15>] smp_apic_timer_interrupt+0x45/0x60
      [   62.657083]  [<ffffffff817d3eca>] apic_timer_interrupt+0x6a/0x70
      [   62.657083]  <EOI>
      [   62.657083]  [<ffffffff817d4a35>] ? sysenter_dispatch+0x7/0x1a
      [   62.657083] Code: 4d 8b 85 a8 02 00 00 4c 89 e9 ba 03 04 00 00 48 c7 c6 c0 be 8d 81 48 c7 c7 48 35 a3 81 31 c0 e8 db 68 0e 00 49 8b 85 a8 02 00 00 <0f> b6 40 46 c0 e8 05 0f b6 c0 c1 e0 03 41 09 c4 e9 77 ff ff ff
      [   62.657083] RIP  [<ffffffff816d822d>] ip6_route_output+0xbd/0xe0
      [   62.657083]  RSP <ffff88002fd038f8>
      [   62.657083] CR2: 0000000000000046
      [   62.657083] ---[ end trace ba8a9583d7cd1934 ]---
      [   62.657083] Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Reported-by: NRyan Whelan <rcwhelan@gmail.com>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7bda701e
    • T
      cxgb4: allow large buffer size to have page size · 940d9d34
      Thadeu Lima de Souza Cascardo 提交于
      Since commit 52367a76
      ("cxgb4/cxgb4vf: Code cleanup to enable T4 Configuration File support"),
      we have failures like this during cxgb4 probe:
      
      cxgb4 0000:01:00.4: bad SGE FL page buffer sizes [65536, 65536]
      cxgb4: probe of 0000:01:00.4 failed with error -22
      
      This happens whenever software parameters are used, without a
      configuration file. That happens when the hardware was already
      initialized (after kexec, or after csiostor is loaded).
      
      It happens that these values are acceptable, rendering fl_pg_order equal
      to 0, which is the case of a hard init when the page size is equal or
      larger than 65536.
      
      Accepting fl_large_pg equal to fl_small_pg solves the issue, and
      shouldn't cause any trouble besides a possible performance reduction
      when smaller pages are used. And that can be fixed by a configuration
      file.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      940d9d34
    • L
      Merge tag 'for-v3.13-fixes' of git://git.infradead.org/battery-2.6 · 9a2f1aad
      Linus Torvalds 提交于
      Pull battery fixes from Anton Vorontsov:
       "Two fixes:
      
         - fix build error caused by max17042_battery conversion to the regmap
           API.
      
         - fix kernel oops when booting with wakeup_source_activate enabled"
      
      * tag 'for-v3.13-fixes' of git://git.infradead.org/battery-2.6:
        max17042_battery: Fix build errors caused by missing REGMAP_I2C config
        power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate
      9a2f1aad
    • L
      Merge tag 'pm+acpi-3.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 23e8e590
      Linus Torvalds 提交于
      Pull ACPI and PM fixes and new device IDs from Rafael Wysocki:
       "These commits, except for one, are regression fixes and the remaining
        one fixes a divide error leading to a kernel panic.  The majority of
        the regressions fixed here were introduced during the 3.12 cycle, one
        of them is from this cycle and one is older.
      
        Specifics:
      
         - VGA switcheroo was broken for some users as a result of the
           ACPI-based PCI hotplug (ACPIPHP) changes in 3.12, because some
           previously ignored hotplug events started to be handled.  The fix
           causes them to be ignored again.
      
         - There are two more issues related to cpufreq's suspend/resume
           handling changes from the 3.12 cycle addressed by Viresh Kumar's
           fixes.
      
         - intel_pstate triggers a divide error in a timer function if the
           P-state information it needs is missing during initialization.
           This leads to kernel panics on nested KVM clients and is fixed by
           failing the initialization cleanly in those cases.
      
         - PCI initalization code changes during the 3.9 cycle uncovered BIOS
           issues related to ACPI wakeup notifications (some BIOSes send them
           for devices that aren't supposed to support ACPI wakeup).  Work
           around them by installing an ACPI wakeup notify handler for all PCI
           devices with ACPI support.
      
         - The Calxeda cpuilde driver's probe function is tagged as __init,
           which is incorrect and causes a section mismatch to occur during
           build.  Fix from Andre Przywara removes the __init tag from there.
      
         - During the 3.12 cycle ACPIPHP started to print warnings about
           missing _ADR for devices that legitimately don't have it.  Fix from
           Toshi Kani makes it only print the warnings where they make sense"
      
      * tag 'pm+acpi-3.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
        intel_pstate: Fail initialization if P-state information is missing
        ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function
        PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI
        cpufreq: preserve user_policy across suspend/resume
        cpufreq: Clean up after a failing light-weight initialization
        ACPI / PCI / hotplug: Avoid warning when _ADR not present
      23e8e590
  6. 03 1月, 2014 3 次提交