tipc: pskb_copy() buffers when sending on more than one bearer

When sending packets, TIPC bearers use skb_clone() before writing their
hardware header. This will however NOT copy the data buffer.
So when the same packet is sent over multiple bearers (to reach multiple
nodes), the same socket buffer data will be treated by multiple
tipc_media drivers which will write their own hardware header through
dev_hard_header().
Most of the time this is not a problem, because by the time the
packet is processed by the second media, it has already been sent over
the first one. However, when the first transmission is delayed (e.g.
because of insufficient bandwidth or through a shaper), the next bearer
will overwrite the hardware header, resulting in the packet being sent:
a) with the wrong source address, when bearers of the same type,
e.g. ethernet, are involved
b) with a completely corrupt header, or even dropped, when bearers of
different types are involved.

So when the same socket buffer is to be sent multiple times, send a
pskb_copy() instead (from the second instance on), and release it
afterwards (the bearer will skb_clone() it anyway).

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bridge: fix race with topology change timer

A bridge should only send topology change notice if it is not
the root bridge. It is possible for message age timer to elect itself
as a new root bridge, and still have a topology change timer running
but waiting for bridge lock on other CPU.

Solve the race by checking if we are root bridge before continuing.
This was the root cause of the cases where br_send_tcn_bpdu would OOPS.

Reported-by: JerryKang <jerry.kang@samsung.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
gre: Fix GREv4 TCPv6 segmentation.

For ipv6 traffic, GRE can generate packet with strange GSO
bits, e.g. ipv4 packet with SKB_GSO_TCPV6 flag set.  Therefore
following patch relaxes check in inet gso handler to allow
such packet for segmentation.
This patch also fixes wrong skb->protocol set that was done in
gre_gso_segment() handler.

Reported-by: Steinar H. Gunderson <sesse@google.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
vxlan: Fix TCPv6 segmentation.

This patch set correct skb->protocol so that inner packet can
lookup correct gso handler.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
usbnet: pegasus: endian bug in write_mii_word()

We're only passing the two high bytes of an integer.  It works for
little endian but not for big endian.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: qmi_wwan: Add Telewell TW-LTE 4G

Information from driver description files:

  diag:  VID_19D2&PID_0412&MI_00
  nmea:  VID_19D2&PID_0412&MI_01
  at:    VID_19D2&PID_0412&MI_02
  modem: VID_19D2&PID_0412&MI_03
  net:   VID_19D2&PID_0412&MI_04

Signed-off-by: Teppo Kotilainen <qubit303@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
asix: fix BUG in receive path when lowering MTU

There is bug in the receive path of the asix driver at the time a
packet is received larger than MTU size and DF bit set:

 BUG: unable to handle kernel paging request at 0000004000000001
 IP: [<ffffffff8126f65b>] skb_release_head_state+0x2d/0xd2
 ...
 Call Trace:
  <IRQ>
  [<ffffffff8126f86d>] ? skb_release_all+0x9/0x1e
  [<ffffffff8126f8ad>] ? __kfree_skb+0x9/0x6f
  [<ffffffffa00b4200>] ? asix_rx_fixup_internal+0xff/0x1ae [asix]
  [<ffffffffa00fb3dc>] ? usbnet_bh+0x4f/0x226 [usbnet]
  ...

It is easily reproducable by setting an MTU of 512 e. g. and sending
something like

  ping -s 1472 -c 1 -M do $SELF

from another box.

And this is because the rx->ax_skb is freed on error, but rx->ax_skb
is not reset, and the size is not reset to zero in this case.

And since the skb is added again to the usbnet->done skb queue it is
accessing already freed memory, resulting in the BUG when freeing a
2nd time.  I therefore think the value 0x0000004000000001 show in the
trace is more or less random data.

Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
packet: tpacket_v3: do not trigger bug() on wrong header status

Jakub reported that it is fairly easy to trigger the BUG() macro
from user space with TPACKET_V3's RX_RING by just giving a wrong
header status flag. We already had a similar situation in commit
7f5c3e3a80e6654 (``af_packet: remove BUG statement in
tpacket_destruct_skb'') where this was the case in the TX_RING
side that could be triggered from user space. So really, don't use
BUG() or BUG_ON() unless there's really no way out, and i.e.
don't use it for consistency checking when there's user space
involved, no excuses, especially not if you're slapping the user
with WARN + dump_stack + BUG all at once. The two functions are
of concern:

  prb_retire_current_block() [when block status != TP_STATUS_KERNEL]
  prb_open_block() [when block_status != TP_STATUS_KERNEL]

Calls to prb_open_block() are guarded by ealier checks if block_status
is really TP_STATUS_KERNEL (racy!), but the first one BUG() is easily
triggable from user space. System behaves still stable after they are
removed. Also remove that yoda condition entirely, since it's already
guarded.

Reported-by: Jakub Zawadzki <darkjames-ws@darkjames.pl>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
sky2: Fix crash on receiving VLAN frames

After recent 86a9bad3 (net: vlan: add protocol argument to packet
tagging functions) my sky2 started to crash on receive of tagged
frames, with backtrace similar to

    #CRASH!!!
    vlan_do_receive
    __netif_receive_skb_core
    __netif_receive_skb
    netif_receive_skb
    sky2_poll
    ...
    __net_rx_action
    __do_softirq

The problem turned out to be:

    1) sky2 copies small packets from ring on RX, and in its
       receive_copy() skb header is copied manually field, by field, and
       only for some fields;

    2) 86a9bad3  added skb->vlan_proto, which vlan_untag() or
       __vlan_hwaccel_put_tag() set, and which is later used in
       vlan_do_receive().

       That patch updated copy_skb_header() for newly introduced
       skb->vlan_proto, but overlooked the need to also copy it in sky2's
       receive_copy().

Because of 2, we have the following scenario:

    - frame is received and tagged in a ring, by sky2_rx_tag(). Both
      skb->vlan_proto and skb->vlan_tci are set;

    - later skb is decided to be copied, but skb->vlan_proto is
      forgotten and becomes 0.

    - in the beginning of vlan_do_receive() we call

        __be16 vlan_proto = skb->vlan_proto;
        vlan_dev = vlan_find_dev(skb->dev, vlan_proto, vlan_id);

      which eventually invokes

        vlan_proto_idx(vlan_proto)

      and that routine BUGs for everything except ETH_P_8021Q and
      ETH_P_8021AD.

      Oops.

Fix it.

P.S.

Stephen, I wonder, why copy_skb_header() is not used in
sky2.c::receive_copy() ? Problems, where receive_copy was updated field
by field showed several times already, e.g.

    3f42941b    (sky2: propogate rx hash when packet is copied)
    e072b3fa    (sky2: fix receive length error in mixed non-VLAN/VLAN traffic)

Cc: Patrick McHardy <kaber@trash.net>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Mirko Lindner <mlindner@marvell.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
cxgb4: fix error recovery when t4_fw_hello returns a positive value

Since commit 636f9d371f70f22961fd598fe18380057518ca31 ("cxgb4: Add
support for T4 configuration file"), t4_fw_hello may return a positive
value instead of 0 for success. The recovery code tests only for zero
and fails recovery for any other value.

This fix tests for negative error values and fails only on those cases.
Error recovery after an error injection works after this change.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ARM: tegra: Tegra114 needs CPU_FREQ_TABLE

Like the other Tegra SoCs using the same cpufreq driver, we
have to enable CPU_FREQ_TABLE for this one.

drivers/built-in.o: In function `tegra_cpu_exit':
 drivers/cpufreq/tegra-cpufreq.c:237: undefined reference to
 `cpufreq_frequency_table_cpuinfo'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
nfsd4: don't allow owner override on 4.1 CLAIM_FH opens

The Linux client is using CLAIM_FH to implement regular opens, not just
recovery cases, so it depends on the server to check permissions
correctly.

Therefore the owner override, which may make sense in the delegation
recovery case, isn't right in the CLAIM_FH case.

Symptoms: on a client with 49f9a0fafd844c32f2abada047c0b9a5ba0d6255
"NFSv4.1: Enable open-by-filehandle", Bryan noticed this:

	touch test.txt
	chmod 000 test.txt
	echo test > test.txt

succeeding.

Cc: stable@kernel.org
Reported-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
ARM: OMAP: build SMP code only for OMAP4/5

The OMAP platform code assumes that SMP is only ever enabled when
CONFIG_ARCH_OMAP4 or CONFIG_SOC_OMAP5 is enabled, which is not
necessarirly true in a multiplatform configuration.

arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
 :(.init.text+0x413c): undefined reference to `omap_get_wakeupgen_base'
 :(.init.text+0x415c): undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
 :(.cpuinit.text+0x28): undefined reference to `omap_get_wakeupgen_base'
 :(.cpuinit.text+0x3c): undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
 :(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
 :(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
 :(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
 :(.ref.text+0x50): undefined reference to `omap_secure_apis_support'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
ARM: imx: build CPU suspend code only when needed

The ARM CPU suspend function has its own configuration symbol,
which we need to use for conditionalizing any code calling into
it as well.

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
/git/arm-soc/arch/arm/mach-imx/headsmp.S:57: undefined
 reference to `cpu_resume'

Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM: SPEAr: conditionalize l2x0 support

If the cache controller implementation is disabled at build time,
we must not call any functions related to it.

arch/arm/mach-spear/built-in.o: In function `spear13xx_l2x0_init':
arch/arm/mach-spear/spear13xx.c:47: undefined reference to `l2x0_init'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.linux@gmail.com>
ARM: SIRF: select SMP_ON_UP only on SMP builds

Like all other platforms, we can only select SMP_ON_UP if SMP
is also enabled.

warning: (SOC_IMX31 && SOC_IMX35 && ARCH_MARCO) selects
 SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL)

Cc: Barry Song <baohua.song@csr.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM: ux500: always select ABX500_CORE

We are probably selecting more drivers than we should in ux500,
but cleaning up that logic for good can be left for another
time. Most of these could be converted into silent options in
the future, since they are always enabled on ux500 and never
needed elsewhere.

As a fixup for 3.10, let's at least select the dependencies for
the other drivers we already select, to make it consistent.

warning: (UX500_SOC_COMMON) selects AB8500_CORE which has unmet direct dependencies (HAS_IOMEM && GENERIC_HARDIRQS && ABX500_CORE && MFD_DB8500_PRCMU)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP

Commit 8a6201b9 (ARM: OMAP2+: Fix unmet direct dependencies for zoom
for 8250 serial) fixed unmet direct dependencies for 8250, but failed
to do the same for omap serial. This can cause the following warning:

warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has
unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS &&
ARCH_OMAP2PLUS).

We should not select drivers, they should be selected by the
user. Fix the issue by removing the select and adding them to
omap2plus_defconfig instead.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ring-buffer: Select IRQ_WORK

As the wake up logic for waiters on the buffer has been moved
from the tracing code to the ring buffer, it requires also adding
IRQ_WORK as the wake up code is performed via irq_work.

This fixes compile breakage when a user of the ring buffer is selected
but tracing and irq_work are not.

Link http://lkml.kernel.org/r/20130503115332.GT8356@rric.localhost

Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Robert Richter <rric@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
target: Remove unused struct members in se_dev_entry

Some were incremented, but never used anywhere from what I could tell.

Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>