ipv6: add link-local, sit and loopback address with INFINITY_LIFE_TIME

In the past the IFA_PERMANENT flag indicated, that the valid and preferred
lifetime where ignored. Since change fad8da3e085ddf ("ipv6 addrconf: fix
preferred lifetime state-changing behavior while valid_lft is infinity")
we honour at least the preferred lifetime on those addresses. As such
the valid lifetime gets recalculated and updated to 0.

If loopback address is added manually this problem does not occur.
Also if NetworkManager manages IPv6, those addresses will get added via
inet6_rtm_newaddr and thus will have a correct lifetime, too.

Reported-by: François-Xavier Le Bail <fx.lebail@yahoo.com>
Reported-by: Damien Wyart <damien.wyart@gmail.com>
Fixes: fad8da3e085ddf ("ipv6 addrconf: fix preferred lifetime state-changing behavior while valid_lft is infinity")
Cc: Yasushi Asano <yasushi.asano@jp.fujitsu.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: prevent WARN during driver unload

Starting with commit 80c33dd "net: add might_sleep() call to napi_disable"
bnx2x fails the might_sleep tests causing a stack trace to appear whenever
the driver is unloaded, as local_bh_disable() is being called before
napi_disable().

This changes the locking schematics related to CONFIG_NET_RX_BUSY_POLL,
preventing the need for calling local_bh_disable() and thus eliminating
the issue.

Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git./linux/kernel/git/pablo/nf

Pablo Neira Ayuso says:

====================
The following patchset contains two patches:

* fix the IRC NAT helper which was broken when adding (incomplete) IPv6
  support, from Daniel Borkmann.

* Refine the previous bugtrap that Jesper added to catch problems for the
  usage of the sequence adjustment extension in IPVs in Dec 16th, it may
  spam messages in case of finding a real bug.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

tipc: correctly unlink packets from deferred packet queue

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 40ba3cdf542a469aaa9083fa041656e59b109b90 ("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: 40ba3cdf542a4 ("tipc: message reassembly using fragment chain")
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reported-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: pcpu_tstats.syncp should be initialised in ip6_vti.c

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 469bdcefdc ("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: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'ext4_for_linus_stable' of git://git./linux/kernel/git/tytso/ext4

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

Merge git://git./linux/kernel/git/davem/net

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.
  ...

bridge: use spin_lock_bh() in br_multicast_set_hash_max

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: Curt Brune <curt@cumulusnetworks.com>
Signed-off-by: Scott Feldman <sfeldma@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: don't install anycast address for /128 addresses on routers

It does not make sense to create an anycast address for an /128-prefix.
Suppress it.

As 32019e651c6fce ("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: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

hso: fix handling of modem port SERIAL_STATE notifications

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: Dan Williams <dcbw@redhat.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: Drop big endian cpp checks from telespci and hfc_pci drivers

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: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

ext4: fix bigalloc regression

Commit f5a44db5d2 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: Eric Whitney <enwlinux@gmail.com>

Merge branch 'be2net'

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: David S. Miller <davem@davemloft.net>

be2net: fix max_evt_qs calculation for BE3 in SR-IOV config

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: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

be2net: increase the timeout value for loopback-test FW cmd

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: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

be2net: disable RSS when number of RXQs is reduced to 1 via set-channels

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: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netfilter: only warn once on wrong seqadj usage

Avoid potentially spamming the kernel log with WARN splash messages
when catching wrong usage of seqadj, by simply using WARN_ONCE.

This is a followup to commit db12cf274353 (netfilter: WARN about
wrong usage of sequence number adjustments)

Suggested-by: Flavio Leitner <fbl@redhat.com>
Suggested-by: Daniel Borkmann <dborkman@redhat.com>
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

netfilter: nf_nat: fix access to uninitialized buffer in IRC NAT helper

Commit 5901b6be885e attempted to introduce IPv6 support into
IRC NAT helper. By doing so, the following code seemed to be removed
by accident:

  ip = ntohl(exp->master->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip);
  sprintf(buffer, "%u %u", ip, port);
  pr_debug("nf_nat_irc: inserting '%s' == %pI4, port %u\n", buffer, &ip, port);

This leads to the fact that buffer[] was left uninitialized and
contained some stack value. When we call nf_nat_mangle_tcp_packet(),
we call strlen(buffer) on excatly this uninitialized buffer. If we
are unlucky and the skb has enough tailroom, we overwrite resp. leak
contents with values that sit on our stack into the packet and send
that out to the receiver.

Since the rather informal DCC spec [1] does not seem to specify
IPv6 support right now, we log such occurences so that admins can
act accordingly, and drop the packet. I've looked into XChat source,
and IPv6 is not supported there: addresses are in u32 and print
via %u format string.

Therefore, restore old behaviour as in IPv4, use snprintf(). The
IRC helper does not support IPv6 by now. By this, we can safely use
strlen(buffer) in nf_nat_mangle_tcp_packet() and prevent a buffer
overflow. Also simplify some code as we now have ct variable anyway.

  [1] http://www.irchelp.org/irchelp/rfc/ctcpspec.html

Fixes: 5901b6be885e ("netfilter: nf_nat: support IPv6 in IRC NAT helper")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Harald Welte <laforge@gnumonks.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

xen-netback: Include header for vmalloc

Commit ac3d5ac27735 ("xen-netback: fix guest-receive-side array sizes")
added calls to vmalloc and vfree in the interface.c file without including
<linux/vmalloc.h>.  This causes build failures if the
-Werror=implicit-function-declaration flag is passed.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: 6lowpan: fix lowpan_header_create non-compression memcpy call

In function lowpan_header_create(), we invoke the following code
construct:

  struct ipv6hdr *hdr;
  ...
  hdr = ipv6_hdr(skb);
  ...
  if (...)
    memcpy(hc06_ptr + 1, &hdr->flow_lbl[1], 2);
  else
    memcpy(hc06_ptr, &hdr, 4);

Where the else path of the condition, that is, non-compression
path, calls memcpy() with a pointer to struct ipv6hdr *hdr as
source, thus two levels of indirection. This cannot be correct,
and likely only one level of pointer was intended as source
buffer for memcpy() here.

Fixes: 44331fe2aa0d ("IEEE802.15.4: 6LoWPAN basic support")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Werner Almesberger <werner@almesberger.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

fec: Revert "fec: Do not assume that PHY reset is active low"

In order to keep DT compatibility we need to revert this, otherwise the original
dts files will no longer work with this driver change.

This reverts commit 7a399e3a2e05bc580a78ea72371b3896827f72e1.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'bnx2x'

Yuval Mintz says:

====================
bnx2x: Bug fixes patch series

Most of what this parch series contains is SR-IOV related bug fixes.
Additionally, it contains some small fixes for legacy devices/modes.

Please consider applying these patches to `net'.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: fix VLAN configuration for VFs.

If the hypervisor configures a vlan for the VF via the PF, the expected
result is that only packets tagged by said vlan will be received by the VF
(and that vlan will be silently removed).
Due to an incorrect manipulation of vlan filters in the driver, the
VF can receive untagged traffic even if the hypervisor configured
some vlan for it.

This patch corrects the behaviour.

Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: fix AFEX memory overflow

There are 2 different (related) flows in the slowpath configuration
that utilize the same pointer and cast it to different structs;
This is obviously incorrect as the intended allocated memory is that
of the smaller struct, possibly causing the flow utilizing the larger
struct to corrupt other slowpath configuration.

Since both flows are exclusive, set the allocated memory to be a union
of both structs.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Clean before update RSS arrives

When a PF receives a VF message indicating a change in RSS properties
it should clean the flags' bit-fields; Otherwise, it's possible that
some random values will be considered as flags by the lower layers configuring
the RSS in FW.

Signed-off-by: Michal Kalderon <michals@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Correct number of MSI-X vectors for VFs

Number of VFs in PCIe configuration space is zero-based. Driver incorrectly
sets the number of VFs to be larger by one than what actually is feasible by
HW, which might cause later VFs to fail to allocate their MSI-X interrupts.

Signed-off-by: Michal Kalderon <michals@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: limit number of interrupt vectors for 57711

Original straightforward division may lead to zeroing number of SB and
null-pointer dereference when device is short of MSIX vectors or lacks
MSIX capabilities.

Reported-by: Vladislav Zolotarov <vladz@cloudius-systems.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Another set of small fixes for ARM, covering various areas.

  Laura fixed a long standing issue with virt_addr_valid() failing to
  handle holes in memory.  Steve found a problem with dcache flushing
  for compound pages.  I fixed another bug in footbridge stuff causing
  time to tick slowly, and also a problem with the AES code which can
  cause linker errors.

  A patch from Rob which fixes Xen problems induced by a lack of
  consistency in our naming of ioremap_cache() - which thankfully has
  very few users"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 7933/1: rename ioremap_cached to ioremap_cache
  ARM: fix "bad mode in ... handler" message for undefined instructions
  CRYPTO: Fix more AES build errors
  ARM: 7931/1: Correct virt_addr_valid
  ARM: 7923/1: mm: fix dcache flush logic for compound high pages
  ARM: fix footbridge clockevent device

ARM: 7933/1: rename ioremap_cached to ioremap_cache

ioremap_cache is more aligned with other architectures.
There are only 2 users of this in the kernel: pxa2xx-flash and Xen.

This fixes Xen build failures on arm64:

drivers/tty/hvc/hvc_xen.c:233:2: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration]
drivers/xen/grant-table.c:1174:3: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration]
drivers/xen/xenbus/xenbus_probe.c:778:4: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration]

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: fix "bad mode in ... handler" message for undefined instructions

The array was missing the final entry for the undefined instruction
exception handler; this commit adds it.

Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

CRYPTO: Fix more AES build errors

Building a multi-arch kernel results in:

arch/arm/crypto/built-in.o: In function `aesbs_xts_decrypt':
sha1_glue.c:(.text+0x15c8): undefined reference to `bsaes_xts_decrypt'
arch/arm/crypto/built-in.o: In function `aesbs_xts_encrypt':
sha1_glue.c:(.text+0x1664): undefined reference to `bsaes_xts_encrypt'
arch/arm/crypto/built-in.o: In function `aesbs_ctr_encrypt':
sha1_glue.c:(.text+0x184c): undefined reference to `bsaes_ctr32_encrypt_blocks'
arch/arm/crypto/built-in.o: In function `aesbs_cbc_decrypt':
sha1_glue.c:(.text+0x19b4): undefined reference to `bsaes_cbc_encrypt'

This code is already runtime-conditional on NEON being supported, so
there's no point compiling it out depending on the minimum build
architecture.

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Merge git://git./linux/kernel/git/davem/sparc

Pull sparc bugfixes from David Miller:

 1) Missing include can lead to build failure, from Kirill Tkhai.

 2) Use dev_is_pci() where applicable, from Yijing Wang.

 3) Enable irqs after we enable preemption in cpu startup path, from
    Kirill Tkhai.

 4) Revert a __copy_{to,from}_user_inatomic change that broke
    iov_iter_copy_from_user_atomic() and thus several tests in xfstests
    and LTP.  From Dave Kleikamp.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."
  sparc64: smp_callin: Enable irqs after preemption is disabled
  sparc/PCI: Use dev_is_pci() to identify PCI devices
  sparc64: Fix build regression

Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."

This reverts commit 145e1c0023585e0e8f6df22316308ec61c5066b2.

This commit broke the behavior of __copy_from_user_inatomic when
it is only partially successful. Instead of returning the number
of bytes not copied, it now returns 1. This translates to the
wrong value being returned by iov_iter_copy_from_user_atomic.

xfstests generic/246 and LTP writev01 both fail on btrfs and nfs
because of this.

Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

sparc64: smp_callin: Enable irqs after preemption is disabled

Most of other architectures have below suggested order.
So lets do the same to fit generic idle loop scheme better.

Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>

sparc/PCI: Use dev_is_pci() to identify PCI devices

Use dev_is_pci() instead of checking bus type directly.

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 3.13-rc7

qlcnic: Fix bug in Tx completion path

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: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

infiniband: make sure the src net is infiniband when create new link

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: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

{vxlan, inet6} Mark vxlan_dev flags with VXLAN_F_IPV6 properly

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: Fan Du <fan.du@windriver.com>
Reported-by: Ryan Whelan <rcwhelan@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cxgb4: allow large buffer size to have page size

Since commit 52367a763d8046190754ab43743e42638564a2d1
("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: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'for-v3.13-fixes' of git://git.infradead.org/battery-2.6

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

Merge tag 'pm+acpi-3.13-rc7' of git://git./linux/kernel/git/rafael/linux-pm

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

netpoll: Fix missing TXQ unlock and and OOPS.

The VLAN tag handling code in netpoll_send_skb_on_dev() has two problems.

1) It exits without unlocking the TXQ.

2) It then tries to queue a NULL skb to npinfo->txq.

Reported-by: Ahmed Tamrawi <atamrawi@iastate.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: fix the use of pcpu_tstats in ip6_vti.c

when read/write the 64bit data, the correct lock should be hold.
and we can use the generic vti6_get_stats to return stats, and
not define a new one in ip6_vti.c

Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics")
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: fix the use of pcpu_tstats in ip6_tunnel

when read/write the 64bit data, the correct lock should be hold.

Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics")

Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6 addrconf: fix preferred lifetime state-changing behavior while valid_lft is infinity

Fixed a problem with setting the lifetime of an IPv6
address. When setting preferred_lft to a value not zero or
infinity, while valid_lft is infinity(0xffffffff) preferred
lifetime is set to forever and does not update. Therefore
preferred lifetime never becomes deprecated. valid lifetime
and preferred lifetime should be set independently, even if
valid lifetime is infinity, preferred lifetime must expire
correctly (meaning it must eventually become deprecated)

Signed-off-by: Yasushi Asano <yasushi.asano@jp.fujitsu.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: llc: fix use after free in llc_ui_recvmsg

While commit 30a584d944fb fixes datagram interface in LLC, a use
after free bug has been introduced for SOCK_STREAM sockets that do
not make use of MSG_PEEK.

The flow is as follow ...

  if (!(flags & MSG_PEEK)) {
    ...
    sk_eat_skb(sk, skb, false);
    ...
  }
  ...
  if (used + offset < skb->len)
    continue;

... where sk_eat_skb() calls __kfree_skb(). Therefore, cache
original length and work on skb_len to check partial reads.

Fixes: 30a584d944fb ("[LLX]: SOCK_DGRAM interface fixes")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio-net: fix refill races during restore

During restoring, try_fill_recv() was called with neither napi lock nor napi
disabled. This can lead two try_fill_recv() was called in the same time. Fix
this by refilling before trying to enable napi.

Fixes 0741bcb5584f9e2390ae6261573c4de8314999f2
(virtio: net: Add freeze, restore handlers to support S4).

Cc: Amit Shah <amit.shah@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv4: fix tunneled VM traffic over hw VXLAN/GRE GSO NIC

VM to VM GSO traffic is broken if it goes through VXLAN or GRE
tunnel and the physical NIC on the host supports hardware VXLAN/GRE
GSO offload (e.g. bnx2x and next-gen mlx4).

Two issues -
(VXLAN) VM traffic has SKB_GSO_DODGY and SKB_GSO_UDP_TUNNEL with
SKB_GSO_TCP/UDP set depending on the inner protocol. GSO header
integrity check fails in udp4_ufo_fragment if inner protocol is
TCP. Also gso_segs is calculated incorrectly using skb->len that
includes tunnel header. Fix: robust check should only be applied
to the inner packet.

(VXLAN & GRE) Once GSO header integrity check passes, NULL segs
is returned and the original skb is sent to hardware. However the
tunnel header is already pulled. Fix: tunnel header needs to be
restored so that hardware can perform GSO properly on the original
packet.

Signed-off-by: Wei-Chun Chao <weichunc@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm bugfixes from Marcelo Tosatti.

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: nVMX: Unconditionally uninit the MMU on nested vmexit
  KVM: x86: Fix APIC map calculation after re-enabling

Merge branch 'akpm' (incoming from Andrew)

Merge patches from Andrew Morton:
 "Ten fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  epoll: do not take the nested ep->mtx on EPOLL_CTL_DEL
  sh: add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
  drivers/dma/ioat/dma.c: check DMA mapping error in ioat_dma_self_test()
  mm/memory-failure.c: transfer page count from head page to tail page after split thp
  MAINTAINERS: set up proper record for Xilinx Zynq
  mm: remove bogus warning in copy_huge_pmd()
  memcg: fix memcg_size() calculation
  mm: fix use-after-free in sys_remap_file_pages
  mm: munlock: fix deadlock in __munlock_pagevec()
  mm: munlock: fix a bug where THP tail page is encountered

epoll: do not take the nested ep->mtx on EPOLL_CTL_DEL

The EPOLL_CTL_DEL path of epoll contains a classic, ab-ba deadlock.
That is, epoll_ctl(a, EPOLL_CTL_DEL, b, x), will deadlock with
epoll_ctl(b, EPOLL_CTL_DEL, a, x).  The deadlock was introduced with
commmit 67347fe4e632 ("epoll: do not take global 'epmutex' for simple
topologies").

The acquistion of the ep->mtx for the destination 'ep' was added such
that a concurrent EPOLL_CTL_ADD operation would see the correct state of
the ep (Specifically, the check for '!list_empty(&f.file->f_ep_links')

However, by simply not acquiring the lock, we do not serialize behind
the ep->mtx from the add path, and thus may perform a full path check
when if we had waited a little longer it may not have been necessary.
However, this is a transient state, and performing the full loop
checking in this case is not harmful.

The important point is that we wouldn't miss doing the full loop
checking when required, since EPOLL_CTL_ADD always locks any 'ep's that
its operating upon.  The reason we don't need to do lock ordering in the
add path, is that we are already are holding the global 'epmutex'
whenever we do the double lock.  Further, the original posting of this
patch, which was tested for the intended performance gains, did not
perform this additional locking.

Signed-off-by: Jason Baron <jbaron@akamai.com>
Cc: Nathan Zimmer <nzimmer@sgi.com>
Cc: Eric Wong <normalperson@yhbt.net>
Cc: Nelson Elhage <nelhage@nelhage.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

sh: add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c

Min_low_pfn and max_low_pfn were used in pfn_valid macro if defined
CONFIG_FLATMEM.  When the functions that use the pfn_valid is used in
driver module, max_low_pfn and min_low_pfn is to undefined, and fail to
build.

  ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
  ERROR: "max_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
  make[2]: *** [__modpost] Error 1
  make[1]: *** [modules] Error 2

This patch fix this problem.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/dma/ioat/dma.c: check DMA mapping error in ioat_dma_self_test()

Check DMA mapping return values in function ioat_dma_self_test() to get
rid of following warning message.

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1203 at lib/dma-debug.c:937 check_unmap+0x4c0/0x9a0()
  ioatdma 0000:00:04.0: DMA-API: device driver failed to check map error[device address=0x000000085191b000] [size=2000 bytes] [mapped as single]
  Modules linked in: ioatdma(+) mac_hid wmi acpi_pad lp parport hidd_generic usbhid hid ixgbe isci dca libsas ahci ptp libahci scsi_transport_sas meegaraid_sas pps_core mdio
  CPU: 0 PID: 1203 Comm: systemd-udevd Not tainted 3.13.0-rc4+ #8
  Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIIN1.86B.0044.L09.1311181644 11/18/2013
  Call Trace:
    dump_stack+0x4d/0x66
    warn_slowpath_common+0x7d/0xa0
    warn_slowpath_fmt+0x4c/0x50
    check_unmap+0x4c0/0x9a0
    debug_dma_unmap_page+0x81/0x90
    ioat_dma_self_test+0x3d2/0x680 [ioatdma]
    ioat3_dma_self_test+0x12/0x30 [ioatdma]
    ioat_probe+0xf4/0x110 [ioatdma]
    ioat3_dma_probe+0x268/0x410 [ioatdma]
    ioat_pci_probe+0x122/0x1b0 [ioatdma]
    local_pci_probe+0x45/0xa0
    pci_device_probe+0xd9/0x130
    driver_probe_device+0x171/0x490
    __driver_attach+0x93/0xa0
    bus_for_each_dev+0x6b/0xb0
    driver_attach+0x1e/0x20
    bus_add_driver+0x1f8/0x2b0
    driver_register+0x81/0x110
    __pci_register_driver+0x60/0x70
    ioat_init_module+0x89/0x1000 [ioatdma]
    do_one_initcall+0xe2/0x250
    load_module+0x2313/0x2a00
    SyS_init_module+0xd9/0x130
    system_call_fastpath+0x1a/0x1f
  ---[ end trace 990c591681d27c31 ]---
  Mapped at:
    debug_dma_map_page+0xbe/0x180
    ioat_dma_self_test+0x1ab/0x680 [ioatdma]
    ioat3_dma_self_test+0x12/0x30 [ioatdma]
    ioat_probe+0xf4/0x110 [ioatdma]
    ioat3_dma_probe+0x268/0x410 [ioatdma]

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/memory-failure.c: transfer page count from head page to tail page after split thp

Memory failures on thp tail pages cause kernel panic like below:

   mce: [Hardware Error]: Machine check events logged
   MCE exception done on CPU 7
   BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
   IP: [<ffffffff811b7cd1>] dequeue_hwpoisoned_huge_page+0x131/0x1e0
   PGD bae42067 PUD ba47d067 PMD 0
   Oops: 0000 [#1] SMP
  ...
   CPU: 7 PID: 128 Comm: kworker/7:2 Tainted: G   M       O 3.13.0-rc4-131217-1558-00003-g83b7df08e462 #25
  ...
   Call Trace:
     me_huge_page+0x3e/0x50
     memory_failure+0x4bb/0xc20
     mce_process_work+0x3e/0x70
     process_one_work+0x171/0x420
     worker_thread+0x11b/0x3a0
     ? manage_workers.isra.25+0x2b0/0x2b0
     kthread+0xe4/0x100
     ? kthread_create_on_node+0x190/0x190
     ret_from_fork+0x7c/0xb0
     ? kthread_create_on_node+0x190/0x190
  ...
   RIP   dequeue_hwpoisoned_huge_page+0x131/0x1e0
   CR2: 0000000000000058

The reasoning of this problem is shown below:
 - when we have a memory error on a thp tail page, the memory error
   handler grabs a refcount of the head page to keep the thp under us.
 - Before unmapping the error page from processes, we split the thp,
   where page refcounts of both of head/tail pages don't change.
 - Then we call try_to_unmap() over the error page (which was a tail
   page before). We didn't pin the error page to handle the memory error,
   this error page is freed and removed from LRU list.
 - We never have the error page on LRU list, so the first page state
   check returns "unknown page," then we move to the second check
   with the saved page flag.
 - The saved page flag have PG_tail set, so the second page state check
   returns "hugepage."
 - We call me_huge_page() for freed error page, then we hit the above panic.

The root cause is that we didn't move refcount from the head page to the
tail page after split thp.  So this patch suggests to do this.

This panic was introduced by commit 524fca1e73 ("HWPOISON: fix
misjudgement of page_action() for errors on mlocked pages").  Note that we
did have the same refcount problem before this commit, but it was just
ignored because we had only first page state check which returned "unknown
page." The commit changed the refcount problem from "doesn't work" to
"kernel panic."

Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: <stable@vger.kernel.org> [3.9+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

MAINTAINERS: set up proper record for Xilinx Zynq

Setup correct zynq entry.
 - Add missing cadence_ttc_timer maintainership
 - Add zynq wildcard
 - Add xilinx wildcard

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove bogus warning in copy_huge_pmd()

Sasha Levin reported the following warning being triggered

  WARNING: CPU: 28 PID: 35287 at mm/huge_memory.c:887 copy_huge_pmd+0x145/ 0x3a0()
  Call Trace:
    copy_huge_pmd+0x145/0x3a0
    copy_page_range+0x3f2/0x560
    dup_mmap+0x2c9/0x3d0
    dup_mm+0xad/0x150
    copy_process+0xa68/0x12e0
    do_fork+0x96/0x270
    SyS_clone+0x16/0x20
    stub_clone+0x69/0x90

This warning was introduced by "mm: numa: Avoid unnecessary disruption
of NUMA hinting during migration" for paranoia reasons but the warning
is bogus.  I was thinking of parallel races between NUMA hinting faults
and forks but this warning would also be triggered by a parallel reclaim
splitting a THP during a fork.  Remote the bogus warning.

Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

memcg: fix memcg_size() calculation

The mem_cgroup structure contains nr_node_ids pointers to
mem_cgroup_per_node objects, not the objects themselves.

Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Glauber Costa <glommer@openvz.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: fix use-after-free in sys_remap_file_pages

remap_file_pages calls mmap_region, which may merge the VMA with other
existing VMAs, and free "vma".  This can lead to a use-after-free bug.
Avoid the bug by remembering vm_flags before calling mmap_region, and
not trying to dereference vma later.

Signed-off-by: Rik van Riel <riel@redhat.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michel Lespinasse <walken@google.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: munlock: fix deadlock in __munlock_pagevec()

Commit 7225522bb429 ("mm: munlock: batch non-THP page isolation and
munlock+putback using pagevec" introduced __munlock_pagevec() to speed
up munlock by holding lru_lock over multiple isolated pages.  Pages that
fail to be isolated are put_page()d immediately, also within the lock.

This can lead to deadlock when __munlock_pagevec() becomes the holder of
the last page pin and put_page() leads to __page_cache_release() which
also locks lru_lock.  The deadlock has been observed by Sasha Levin
using trinity.

This patch avoids the deadlock by deferring put_page() operations until
lru_lock is released.  Another pagevec (which is also used by later
phases of the function is reused to gather the pages for put_page()
operation.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: munlock: fix a bug where THP tail page is encountered

Since commit ff6a6da60b89 ("mm: accelerate munlock() treatment of THP
pages") munlock skips tail pages of a munlocked THP page.  However, when
the head page already has PageMlocked unset, it will not skip the tail
pages.

Commit 7225522bb429 ("mm: munlock: batch non-THP page isolation and
munlock+putback using pagevec") has added a PageTransHuge() check which
contains VM_BUG_ON(PageTail(page)).  Sasha Levin found this triggered
using trinity, on the first tail page of a THP page without PageMlocked
flag.

This patch fixes the issue by skipping tail pages also in the case when
PageMlocked flag is unset.  There is still a possibility of race with
THP page split between clearing PageMlocked and determining how many
pages to skip.  The race might result in former tail pages not being
skipped, which is however no longer a bug, as during the skip the
PageTail flags are cleared.

However this race also affects correctness of NR_MLOCK accounting, which
is to be fixed in a separate patch.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Bob Liu <bob.liu@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

sctp: Remove outqueue empty state

The SCTP outqueue structure maintains a data chunks
that are pending transmission, the list of chunks that
are pending a retransmission and a length of data in
flight.  It also tries to keep the emtpy state so that
it can performe shutdown sequence or notify user.

The problem is that the empy state is inconsistently
tracked.  It is possible to completely drain the queue
without sending anything when using PR-SCTP.  In this
case, the empty state will not be correctly state as
report by Jamal Hadi Salim <jhs@mojatatu.com>.  This
can cause an association to be perminantly stuck in the
SHUTDOWN_PENDING state.

Additionally, SCTP is incredibly inefficient when setting
the empty state.  Even though all the data is availaible
in the outqueue structure, we ignore it and walk a list
of trasnports.

In the end, we can completely remove the extra empty
state and figure out if the queue is empty by looking
at 3 things:  length of pending data, length of in-flight
data, and exisiting of retransmit data.  All of these
are already in the strucutre.

Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix resource allocation for TX queues

o TX queues allocation was getting distributed equally among all the
  functions of the port including VFs and PF. Which was leading to failure
  in PF's multiple TX queues creation.

o Instead of dividing queues equally allocate one TX queue for each VF as VF
  doesn't support multiple TX queues.

Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic: Fix loopback diagnostic test

o Adapter requires that if the port is in loopback mode no traffic should
  be flowing through that port, so on arrival of Link up AEN, do not advertise
  Link up to the stack until port is out of loopback mode

Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'gfs2-fixes' of git://git./linux/kernel/git/steve/gfs2-3.0-fixes

Pull GFS2 fixes from Steven Whitehouse:
 "Here is a set of small fixes for GFS2.  There is a fix to drop
  s_umount which is copied in from the core vfs, two patches relate to a
  hard to hit "use after free" and memory leak.  Two patches related to
  using DIO and buffered I/O on the same file to ensure correct
  operation in relation to glock state changes.  The final patch adds an
  RCU read lock to ensure correct locking on an error path"

* tag 'gfs2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
  GFS2: Fix unsafe dereference in dump_holder()
  GFS2: Wait for async DIO in glock state changes
  GFS2: Fix incorrect invalidation for DIO/buffered I/O
  GFS2: Fix slab memory leak in gfs2_bufdata
  GFS2: Fix use-after-free race when calling gfs2_remove_from_ail
  GFS2: don't hold s_umount over blkdev_put

Merge branch 'for-linus' of git://git./linux/kernel/git/s390/linux

Pull s390 fixes from Martin Schwidefsky:
 "Two small bug fixes and a follow-up to the CONFIG_NR_CPUS change.

  A kernel compiled with CONFIG_NR_CPUS=256 will waste quite a bit of
  memory for the per-cpu arrays.  Under z/VM the maximum number of CPUs
  is 64, the code now limits the possible cpu mask to 64 if running
  under z/VM"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/pci: obtain function handle in hotplug notifier
  s390/3270: fix allocation of tty3270_screen structure
  s390/smp: improve setup of possible cpu mask

KVM: nVMX: Unconditionally uninit the MMU on nested vmexit

Three reasons for doing this: 1. arch.walk_mmu points to arch.mmu anyway
in case nested EPT wasn't in use. 2. this aligns VMX with SVM. But 3. is
most important: nested_cpu_has_ept(vmcs12) queries the VMCS page, and if
one guest VCPU manipulates the page of another VCPU in L2, we may be
fooled to skip over the nested_ept_uninit_mmu_context, leaving mmu in
nested state. That can crash the host later on if nested_ept_get_cr3 is
invoked while L1 already left vmxon and nested.current_vmcs12 became
NULL therefore.

Cc: stable@kernel.org
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

GFS2: Fix unsafe dereference in dump_holder()

GLOCK_BUG_ON() might call this function without RCU read lock. Make sure that
RCU read lock is held when using task_struct returned from pid_task().

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

ipv6: fix the use of pcpu_tstats in sit

when read/write the 64bit data, the correct lock should be hold.

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: llc: fix order of evaluation in llc_conn_ac_inc_vr_by_1

Function llc_conn_ac_inc_vr_by_1() evaluates via macro
PDU_GET_NEXT_Vr() into ...

  llc_sk(sk)->vR = ++llc_sk(sk)->vR & 0xffffffffffffff7f

... but the order in which the side effects take place is
undefined because there is no intervening sequence point.

As llc_sk(sk)->vR is written in llc_sk(sk)->vR (assignment
left-hand side) and written in ++llc_sk(sk)->vR & 0xffffffffffffff7f
this might possibly yield undefined behavior.

The final value of llc_sk(sk)->vR is ambiguous, because,
depending on the order of expression evaluation, the
increment may occur before, after, or interleaved with
the assignment. In C, evaluating such an expression yields
undefined behavior.

Since we're doing the increment via PDU_GET_NEXT_Vr() macro
and the only place it is being used is from
llc_conn_ac_inc_vr_by_1(), in order to increment vR by 1
with a follow-up optimized modulo, rewrite the expression
into ((vR + 1) & CONST) in order to fix this.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Fix KR2 work-around detection of BCM8073

KR2 work-around is based on detecting non-KR2 devices which may not link up
in this mode. One such link-partner is the BCM8073 which has specific
advertisement characteristics in specific mode, and this condition was not set
correctly.

Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Fix incorrect link-up report

Fix a problem where link is reported to be up when SFP+ module is plugged in
without cable. This occurs with specific module types which may generate
temporary TX_FAULT indication. Solution is to avoid changing any link parameters
when checking TX_FAULT indication while physical link is down.

Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Fix Duplex setting for 54618se

BCM54618SE is used to advertise half-duplex even if HD was not requested by the
user. This change makes the legacy speed/duplex advertisement for this PHY
exactly according to the requested speed and duplex.

Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Fix passive DAC cable detection

Fix Passive DAC detection for specific cables, such that even in case
SFP_CABLE_TECHNOLOGY option is not set in the EEPROM (offset 8), treat it as a
passive DAC cable, since some cables don't have this indication.

Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2x: Fix 578xx-KR 1G link

Fix a problem where 578xx-KR is unable to get link when connected to 1G link
partner. Two fixes were required:
One was to force CL37 sync_status low to prevent Warpcore from getting stuck in
CL73 parallel detect loop while link partner is sending.
Second fix was to enable auto-detect mode, thus allowing the Warpcore to select
the higher speed protocol between 10G-KR (over CL73), or go down to 1G over CL73
when there's indication for it.

Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull radeon drm fixes from Dave Airlie:
 "Just piping a bunch of fixes from pre-xmas from Alex for radeon, all
  either fix bad hw setup issues or regressions"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: Bump version for CIK DCE tiling fix
  drm/radeon: set correct number of banks for CIK chips in DCE
  drm/radeon: set correct pipe config for Hawaii in DCE
  drm/radeon: expose render backend mask to the userspace
  drm/radeon: fix render backend setup for SI and CIK
  drm/radeon: 0x9649 is SUMO2 not SUMO
  drm/radeon: fix UVD 256MB check

Merge git://git./linux/kernel/git/herbert/crypto-2.6

Pull crypto fix from Herbert Xu:
 "Fix a build error on ARM that was introduced in 3.13-rc1"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: ixp4xx - Fix kernel compile error

Merge branch 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

Radeon fixes, Christmas eve edition.  Fix incorrect family for 0x9649
which lead to bogus rendering, tiling and RB fixes for SI and CIK,
and a UVD fix.

* 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: Bump version for CIK DCE tiling fix
  drm/radeon: set correct number of banks for CIK chips in DCE
  drm/radeon: set correct pipe config for Hawaii in DCE
  drm/radeon: expose render backend mask to the userspace
  drm/radeon: fix render backend setup for SI and CIK
  drm/radeon: 0x9649 is SUMO2 not SUMO
  drm/radeon: fix UVD 256MB check

crypto: ixp4xx - Fix kernel compile error

drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function)

Now builds. Not tested on real hw.

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

usbnet: mcs7830: rework link state detection

Even with the quirks in commit dabdaf0c (mcs7830: Fix link state
detection) there are still spurious link-down events for some chips
where the false link-down events count go over a few hundreds.

This patch takes a more conservative approach and only looks at
link-down events where the link-down state is not combined with other
states (e.g. half/full speed, pending frames in SRAM or TX status
information valid). In all other cases we assume the link is up.

Tested on MCS7830CV-DA (USB ID 9710:7830).

Cc: Ondrej Zary <linux@rainbow-software.org>
Cc: Michael Leun <lkml20120218@newton.leun.net>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

vlan: Fix header ops passthru when doing TX VLAN offload.

When the vlan code detects that the real device can do TX VLAN offloads
in hardware, it tries to arrange for the real device's header_ops to
be invoked directly.

But it does so illegally, by simply hooking the real device's
header_ops up to the VLAN device.

This doesn't work because we will end up invoking a set of header_ops
routines which expect a device type which matches the real device, but
will see a VLAN device instead.

Fix this by providing a pass-thru set of header_ops which will arrange
to pass the proper real device instead.

To facilitate this add a dev_rebuild_header().  There are
implementations which provide a ->cache and ->create but not a
->rebuild (f.e. PLIP).  So we need a helper function just like
dev_hard_header() to avoid crashes.

Use this helper in the one existing place where the
header_ops->rebuild was being invoked, the neighbour code.

With lots of help from Florian Westphal.

Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branches 'pm-cpufreq' and 'pm-cpuidle'

* pm-cpufreq:
  intel_pstate: Fail initialization if P-state information is missing
  cpufreq: preserve user_policy across suspend/resume
  cpufreq: Clean up after a failing light-weight initialization

* pm-cpuidle:
  ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function

Merge branch 'cpuidle/3.13-fixes' of git://git.linaro.org/people/daniel.lezcano/linux into pm-cpuidle

Pull ARM cpuidle fixes for v3.13 from Daniel Lezcano.

* 'cpuidle/3.13-fixes' of git://git.linaro.org/people/daniel.lezcano/linux:
  ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function

Merge branches 'acpi-pci-pm' and 'acpi-pci-hotplug'

* acpi-pci-pm:
  PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI

* acpi-pci-hotplug:
  ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
  ACPI / PCI / hotplug: Avoid warning when _ADR not present

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input updates from Dmitry Torokhov:
 "A fix for a panic in gpio-keys driver when set up with absolute
  events, a fixup to the new zforce driver and a new keycode definition"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: allocate absinfo data when setting ABS capability
  Input: define KEY_WWAN for Wireless WAN
  Input: zforce - fix possible driver hang during suspend

Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6

Pull cifs fixes from Steve French:
 "A few small cifs fixes including two for stable, and fixing a
  regression introduced by the VFS change to file create"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: set FILE_CREATED
  cifs: We do not drop reference to tlink in CIFSCheckMFSymlink()
  Add missing end of line termination to some cifs messages

Input: allocate absinfo data when setting ABS capability

We need to make sure we allocate absinfo data when we are setting one of
EV_ABS/ABS_XXX capabilities, otherwise we may bomb when we try to emit this
event.

Rested-by: Paul Cercueil <pcercuei@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug

The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcdd1b2 (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891
Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk>
Reported-and-tested-by: <madcatx@atlas.cz>
Reported-and-tested-by: Joaquín Aramendía <samsagax@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+

intel_pstate: Fail initialization if P-state information is missing

If pstate.current_pstate is 0 after the initial
intel_pstate_get_cpu_pstates(), this means that we were unable to
obtain any useful P-state information and there is no reason to
continue, so free memory and return an error in that case.

This fixes the following divide error occuring in a nested KVM
guest:

Intel P-state driver initializing.
Intel pstate controlling: cpu 0
cpufreq: __cpufreq_add_dev: ->get() failed
divide error: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: ffff88001ea20000 ti: ffff88001e9bc000 task.ti: ffff88001e9bc000
RIP: 0010:[<ffffffff815c551d>]  [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
RSP: 0000:ffff88001ee03e18  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88001a454348 RCX: 0000000000006100
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88001ee03e38 R08: 0000000000000000 R09: 0000000000000000
R10: ffff88001ea20000 R11: 0000000000000000 R12: 00000c0a1ea20000
R13: 1ea200001ea20000 R14: ffffffff815c5400 R15: ffff88001a454348
FS:  0000000000000000(0000) GS:ffff88001ee00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006f0
Stack:
 fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100
 ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40
 ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000
Call Trace:
 <IRQ>
 [<ffffffff81083e9a>] call_timer_fn+0x8a/0x310
 [<ffffffff81083e15>] ? call_timer_fn+0x5/0x310
 [<ffffffff815c5400>] ? pid_param_set+0x130/0x130
 [<ffffffff81084354>] run_timer_softirq+0x234/0x380
 [<ffffffff8107aee4>] __do_softirq+0x104/0x430
 [<ffffffff8107b5fd>] irq_exit+0xcd/0xe0
 [<ffffffff81770645>] smp_apic_timer_interrupt+0x45/0x60
 [<ffffffff8176efb2>] apic_timer_interrupt+0x72/0x80
 <EOI>
 [<ffffffff810e15cd>] ? vprintk_emit+0x1dd/0x5e0
 [<ffffffff81757719>] printk+0x67/0x69
 [<ffffffff815c1493>] __cpufreq_add_dev.isra.13+0x883/0x8d0
 [<ffffffff815c14f0>] cpufreq_add_dev+0x10/0x20
 [<ffffffff814a14d1>] subsys_interface_register+0xb1/0xf0
 [<ffffffff815bf5cf>] cpufreq_register_driver+0x9f/0x210
 [<ffffffff81fb19af>] intel_pstate_init+0x27d/0x3be
 [<ffffffff81761e3e>] ? mutex_unlock+0xe/0x10
 [<ffffffff81fb1732>] ? cpufreq_gov_dbs_init+0x12/0x12
 [<ffffffff8100214a>] do_one_initcall+0xfa/0x1b0
 [<ffffffff8109dbf5>] ? parse_args+0x225/0x3f0
 [<ffffffff81f64193>] kernel_init_freeable+0x1fc/0x287
 [<ffffffff81f638d0>] ? do_early_param+0x88/0x88
 [<ffffffff8174b530>] ? rest_init+0x150/0x150
 [<ffffffff8174b53e>] kernel_init+0xe/0x130
 [<ffffffff8176e27c>] ret_from_fork+0x7c/0xb0
 [<ffffffff8174b530>] ? rest_init+0x150/0x150
Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89
RIP  [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
 RSP <ffff88001ee03e18>
---[ end trace f166110ed22cc37a ]---
Kernel panic - not syncing: Fatal exception in interrupt

Reported-and-tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>

Merge tag 'dt-fixes-for-3.13' of git://git./linux/kernel/git/robh/linux

Pull devicetree fixes from Rob Herring:
 - Fix 2 regressions found on PPC
 - Allow NULL ptr in unflatten_and_copy_device_tree
 - Update my email address

* tag 'dt-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  MAINTAINERS: Update Rob Herring's email address
  of/irq: Fix device_node refcount in of_irq_parse_raw()
  of/Kconfig: Spelling s/one/once/
  Revert "of/address: Handle #address-cells > 2 specially"
  of: Fix NULL dereference in unflatten_and_copy()

KVM: x86: Fix APIC map calculation after re-enabling

Update arch.apic_base before triggering recalculate_apic_map. Otherwise
the recalculation will work against the previous state of the APIC and
will fail to build the correct map when an APIC is hardware-enabled
again.

This fixes a regression of 1e08ec4a13.

Cc: stable@vger.kernel.org
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull powerpc fixes from Ben Herrenschmidt:
 "A bit more endian problems found during testing of 3.13 and a few
  other simple fixes and regressions fixes"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Fix alignment of secondary cpu spin vars
  powerpc: Align p_end
  powernv/eeh: Add buffer for P7IOC hub error data
  powernv/eeh: Fix possible buffer overrun in ioda_eeh_phb_diag()
  powerpc: Make 64-bit non-VMX __copy_tofrom_user bi-endian
  powerpc: Make unaligned accesses endian-safe for powerpc
  powerpc: Fix bad stack check in exception entry
  powerpc/512x: dts: disable MPC5125 usb module
  powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)

Merge remote-tracking branch 'grant/devicetree/merge' into dt-fixes

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:
 "Some holiday bug fixes for 3.13...  There is still one bug I'd like to
  get fixed before 3.13-final.

  The vlan code erroneously assignes the header ops of the underlying
  real device to the VLAN device above it when the real device can
  hardware offload VLAN handling.  That's completely bogus because
  header ops are tied to the device type, so they only expect to see a
  'dev' argument compatible with their ops.

  The fix is the have the VLAN code use a special set of header ops that
  does the pass-thru correctly, by calling the underlying real device's
  header ops but _also_ passing in the real device instead of the VLAN
  device.

  That fix is currently waiting some testing.

  Anyways, of note here:

   1) Fix bitmap edge case in radiotap, from Johannes Berg.

   2) Fix oops on driver unload in rtlwifi, from Larry Finger.

   3) Bonding doesn't do locking correctly during speed/duplex/link
      changes, from Ding Tianhong.

   4) Fix header parsing in GRE code, this bug has been around for a few
      releases.  From Timo Teräs.

   5) SIT tunnel driver MTU check needs to take GSO into account, from
      Eric Dumazet.

   6) Minor info leak in inet_diag, from Daniel Borkmann.

   7) Info leak in YAM hamradio driver, from Salva Peiró.

   8) Fix route expiration state handling in ipv6 routing code, from Li
      RongQing.

   9) DCCP probe module does not check request_module()'s return value,
      from Wang Weidong.

  10) cpsw driver passes NULL device names to request_irq(), from
      Mugunthan V N.

  11) Prevent a NULL splat in RDS binding code, from Sasha Levin.

  12) Fix 4G overflow test in tg3 driver, from Nithin Sujir.

  13) Cure use after free in arc_emac and fec driver's software
      timestamp handling, from Eric Dumazet.

  14) SIT driver can fail to release the route when
      iptunnel_handle_offloads() throws an error.  From Li RongQing.

  15) Several batman-adv fixes from Simon Wunderlich and Antonio
      Quartulli.

  16) Fix deadlock during TIPC socket release, from Ying Xue.

  17) Fix regression in ROSE protocol recvmsg() msg_name handling, from
      Florian Westphal.

  18) stmmac PTP support releases wrong spinlock, from Vince Bridgers"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (73 commits)
  stmmac: Fix incorrect spinlock release and PTP cap detection.
  phy: IRQ cannot be shared
  net: rose: restore old recvmsg behavior
  xen-netback: fix guest-receive-side array sizes
  fec: Do not assume that PHY reset is active low
  tipc: fix deadlock during socket release
  netfilter: nf_tables: fix wrong datatype in nft_validate_data_load()
  batman-adv: fix vlan header access
  batman-adv: clean nf state when removing protocol header
  batman-adv: fix alignment for batadv_tvlv_tt_change
  batman-adv: fix size of batadv_bla_claim_dst
  batman-adv: fix size of batadv_icmp_header
  batman-adv: fix header alignment by unrolling batadv_header
  batman-adv: fix alignment for batadv_coded_packet
  netfilter: nf_tables: fix oops when updating table with user chains
  netfilter: nf_tables: fix dumping with large number of sets
  ipv6: release dst properly in ipip6_tunnel_xmit
  netxen: Correct off-by-one errors in bounds checks
  net: Add some clarification to skb_tx_timestamp() comment.
  arc_emac: fix potential use after free
  ...

MAINTAINERS: Update Rob Herring's email address

My Calxeda email address is going away.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rob Herring <robh@kernel.org>

of/irq: Fix device_node refcount in of_irq_parse_raw()

Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" changed
the refcount on the device_node causing an error in of_node_put():

ERROR: Bad of_node_put() on /pci@800000020000000
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3-dirty #2
Call Trace:
[c00000003e403500] [c0000000000144fc] .show_stack+0x7c/0x1f0 (unreliable)
[c00000003e4035d0] [c00000000070f250] .dump_stack+0x88/0xb4
[c00000003e403650] [c0000000005e8768] .of_node_release+0xd8/0xf0
[c00000003e4036e0] [c0000000005eeafc] .of_irq_parse_one+0x10c/0x280
[c00000003e4037a0] [c0000000005efd4c] .of_irq_parse_pci+0x3c/0x1d0
[c00000003e403840] [c000000000038240] .pcibios_setup_device+0xa0/0x2e0
[c00000003e403910] [c0000000000398f0] .pcibios_setup_bus_devices+0x60/0xd0
[c00000003e403990] [c00000000003b3a4] .__of_scan_bus+0x1a4/0x2b0
[c00000003e403a80] [c00000000003a62c] .pcibios_scan_phb+0x30c/0x410
[c00000003e403b60] [c0000000009fe430] .pcibios_init+0x7c/0xd4

This patch adjusts the refcount in the walk of the interrupt tree.
When a match is found, there is no need to increase the refcount
on 'out_irq->np' as 'newpar' is already holding a ref. The refcount
balance between 'ipar' and 'newpar' is maintained in the skiplevel:
goto label.

This patch also removes the usage of the device_node variable 'old'
which seems useless after the latest changes.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Rob Herring <robh@kernel.org>

of/Kconfig: Spelling s/one/once/

Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Rob Herring <robh@kernel.org>

Revert "of/address: Handle #address-cells > 2 specially"

This reverts commit e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7.

Nikita Yushchenko reports:
While trying to make freescale p2020ds and  mpc8572ds boards working
with mainline kernel, I faced that commit e38c0a1f (Handle

Both these boards have uli1575 chip.
Corresponding part in device tree is something like

                uli1575@0 {
                        reg = <0x0 0x0 0x0 0x0 0x0>;
                        #size-cells = <2>;
                        #address-cells = <3>;
                        ranges = <0x2000000 0x0 0x80000000
                                  0x2000000 0x0 0x80000000
                                  0x0 0x20000000

                                  0x1000000 0x0 0x0
                                  0x1000000 0x0 0x0
                                  0x0 0x10000>;
                        isa@1e {
...

I.e. it has #address-cells = <3>

With commit e38c0a1f reverted, devices under uli1575 are registered
correctly, e.g. for rtc

OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address: 00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=a0000000, s=20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 01000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 01000000 00000000 00000070
OF: parent bus is default (na=2, ns=2) on /
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for: 00000000 ffc10000
OF: with offset: 70
OF: one level translation: 00000000 ffc10070
OF: reached root node

With commit e38c0a1f in place, address translation fails:

OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address: 00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=a0000000, s=20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: not found !

Thierry Reding confirmed this commit was not needed after all:
"We ended up merging a different address representation for Tegra PCIe
and I've confirmed that reverting this commit doesn't cause any obvious
regressions. I think all other drivers in drivers/pci/host ended up
copying what we did on Tegra, so I wouldn't expect any other breakage
either."

There doesn't appear to be a simple way to support both behaviours, so
reverting this as nothing should be depending on the new behaviour.

Cc: stable@vger.kernel.org # v3.7+
Signed-off-by: Rob Herring <robh@kernel.org>

ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function

Commit 60a66e370007e8535b7a561353b07b37deaf35ba changed the Calxeda
cpuidle driver to a platform driver, copying the __init tag from the
_init() to the newly used _probe() function. However, "probe should
not be __init." (Rob said ;-)
Remove the __init tag to fix a section mismatch in the Calxeda
cpuidle driver.

Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>

s390/pci: obtain function handle in hotplug notifier

When using the CLP interface to enable or disable a pci device a
valid function handle needs to be delivered. So far our assumption
was that we always have an up-to-date version of the function handle
(since it doesn't change when the device is in use). This assumption
is incorrect if the pci device is enabled or disabled outside of our
control. When we are notified about such a change we already receive
the new function handle. Just use it.

Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>