mac80211: fix scan_sdata assignment

We need to use RCU to assign scan_sdata.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wireless: reg: restore previous behaviour of chan->max_power calculations

commit eccc068e8e84c8fe997115629925e0422a98e4de
Author: Hong Wu <Hong.Wu@dspg.com>
Date:   Wed Jan 11 20:33:39 2012 +0200

    wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit pow

changed the way we calculate chan->max_power as min(chan->max_power,
chan->max_reg_power). That broke rt2x00 (and perhaps some other
drivers) that do not set chan->max_power. It is not so easy to fix this
problem correctly in rt2x00.

According to commit eccc068e8 changelog, change claim only to save
maximum regulatory power - changing setting of chan->max_power was side
effect. This patch restore previous calculations of chan->max_power and
do not touch chan->max_reg_power.

Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
vlv: it might be wise if we initialised the flag value...

Otherwise our initial behaviour is "randomly save a bogus PLL
choice" as far as I can see.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915: fix error path leak in intel_sdvo_write_cmd

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915: Remove silly test

drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful
than a chocolate teapot.

Possibly we should be testing bus != NULL each iteration of the loop
instead ?

gcc could help by warning too!

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fix forcewake related hangs on snb

... by adding seemingly redudant posting reads.

This little dragon lair exploded the first time around when we've
refactored the code a bit to use the common wait_for_atomic_us in
"drm/i915: Group the GT routines together in both code and vtable",
which caused QA to file fdo bug #51738.

Chris Wilson entertained a few approaches to fixing #51738: Replacing
the udelay(1) with the previously-used udelay(10) (or any other
"sufficiently larger" delay), adding a posting read, or ditching the
delay completely and using cpu_relax. We went with the cpu_relax and
"915: Workaround hang with BSD and forcewake on SandyBridge". Which
blew up in fdo bug #52424, but adding the posting read while still
using cpu_relax seems to also fix that, it looks like the
posting read is the important ingriedient to fix these rc6 related
hangs on snb.

Popular theories as to why this is like it is include:
- A herd of pink elephants got royally angered somehow.

- The gpu has internally different functional units and judging by the
  register offsets, the forcewake request register and the forcewake
  ack registers are _not_ in the same functional unit (or at least
  aren't reached through the same routes). Hence the posting read
  syncs up with the wrong block and gets the entire gpu confused.

- ...

As a minimal ducttape fix for 3.6, let's just put these posting reads
into place again. We can try fancier approaches (like adding back the
cpu_relax instead of the udelay) in -next.

This (re-)fixes a regression introduced in

commit 990bbdadabaa51828e475eda86ee5720a4910cc3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 2 11:51:02 2012 -0300

    drm/i915: Group the GT routines together in both code and vtable

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Du Yan <yanx.du@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52424
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738u
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
tcm_vhost: Initial merge for vhost level target fabric driver

This patch adds the initial code for tcm_vhost, a Vhost level TCM
fabric driver for virtio SCSI initiators into KVM guest.

This code is currently up and running on v3.5-rc2 host+guest
from target-pending/for-next-merge.

Using tcm_vhost requires Zhi's -> Stefan -> nab's qemu vhost-scsi tree here:

  http://git.kernel.org/?p=virt/kvm/nab/qemu-kvm.git;a=shortlog;h=refs/heads/vhost-scsi

--

Changelog v4 -> v5:

  Expose ABI version via VHOST_SCSI_GET_ABI_VERSION + use Rev 0 as
  starting point for v3.6-rc code (Stefan + ALiguori + nab)
  Convert vhost_scsi_handle_vq() to vq_err() (nab + MST)
  Minor style fixes from checkpatch (nab)

Changelog v3 -> v4:

  Rename vhost_vring_target -> vhost_scsi_target (mst + nab)
  Use TRANSPORT_IQN_LEN in vhost_scsi_target->vhost_wwpn[] def (nab)
  Move back to drivers/vhost/, and just use drivers/vhost/Kconfig.tcm (mst)
  Move TCM_VHOST related ioctl defines from include/linux/vhost.h ->
  drivers/vhost/tcm_vhost.h as requested by MST (nab)
  Move Kbuild.tcm include from drivers/staging -> drivers/vhost/, and
  just use 'if STAGING' around 'source drivers/vhost/Kbuild.tcm'

Changelog v2 -> v3:

  Unlock on error in tcm_vhost_drop_nexus() (DanC)
  Fix strlen() doesn't count the terminator (DanC)
  Call kfree() on an error path (DanC)
  Convert tcm_vhost_write_pending to use target_execute_cmd (hch + nab)
  Fix another strlen() off by one in tcm_vhost_make_tport (DanC)
  Add option under drivers/staging/Kconfig, and move to drivers/vhost/tcm/
  as requested by MST (nab)

Changelog v1 -> v2:

  Fix tv_cmd completion -> release SGL memory leak (nab)
  Fix sparse warnings for static variable usage ((Fengguang Wu)
  Fix sparse warnings for min() typing + printk format specs (Fengguang Wu)
  Convert to cmwq submission for I/O dispatch (nab + hch)

Changelog v0 -> v1:

  Merge into single source + header file, and move to drivers/vhost/

Acked-by: Michael S. Tsirkin <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Cc: Zhi Yong Wu <wuzhy@cn.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Merge remote-tracking branch 'wireless/master' into mac80211
mac80211: don't clear sched_scan_sdata on sched scan stop request

ieee80211_request_sched_scan_stop() cleared
local->sched_scan_sdata. However, sched_scan_sdata
should be cleared only after the driver calls
ieee80211_sched_scan_stopped() (like with normal hw scan).

Clearing sched_scan_sdata too early caused
ieee80211_sched_scan_stopped_work to exit prematurely
without properly cleaning all the sched scan resources
and without calling cfg80211_sched_scan_stopped (so
userspace wasn't notified about sched scan completion).

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: clear timer bits when disconnecting

There's a corner case that can happen when we
suspend with a timer running, then resume and
disconnect. If we connect again, suspend and
resume we might start timers that shouldn't be
running. Reset the timer flags to avoid this.

This affects both mesh and managed modes.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: cancel mesh path timer

The mesh path timer needs to be canceled when
leaving the mesh as otherwise it could fire
after the interface has been removed already.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
net: Allow driver to limit number of GSO segments per skb

A peer (or local user) may cause TCP to use a nominal MSS of as little
as 88 (actual MSS of 76 with timestamps).  Given that we have a
sufficiently prodigious local sender and the peer ACKs quickly enough,
it is nevertheless possible to grow the window for such a connection
to the point that we will try to send just under 64K at once.  This
results in a single skb that expands to 861 segments.

In some drivers with TSO support, such an skb will require hundreds of
DMA descriptors; a substantial fraction of a TX ring or even more than
a full ring.  The TX queue selected for the skb may stall and trigger
the TX watchdog repeatedly (since the problem skb will be retried
after the TX reset).  This particularly affects sfc, for which the
issue is designated as CVE-2012-3412.

Therefore:
1. Add the field net_device::gso_max_segs holding the device-specific
   limit.
2. In netif_skb_features(), if the number of segments is too high then
   mask out GSO features to force fall back to software GSO.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
sfc: Fix maximum number of TSO segments and minimum TX queue size

Currently an skb requiring TSO may not fit within a minimum-size TX
queue.  The TX queue selected for the skb may stall and trigger the TX
watchdog repeatedly (since the problem skb will be retried after the
TX reset).  This issue is designated as CVE-2012-3412.

Set the maximum number of TSO segments for our devices to 100.  This
should make no difference to behaviour unless the actual MSS is less
than about 700.  Increase the minimum TX queue size accordingly to
allow for 2 worst-case skbs, so that there will definitely be space
to add an skb after we wake a queue.

To avoid invalidating existing configurations, change
efx_ethtool_set_ringparam() to fix up values that are too small rather
than returning -EINVAL.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
tcp: Apply device TSO segment limit earlier

Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
limit the size of TSO skbs.  This avoids the need to fall back to
software GSO for local TCP senders.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix unexpected SA hard expiration after changing date

After SA is setup, one timer is armed to detect soft/hard expiration,
however the timer handler uses xtime to do the math. This makes hard
expiration occurs first before soft expiration after setting new date
with big interval. As a result new child SA is deleted before rekeying
the new one.

Signed-off-by: Fan Du <fdu@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bnx2x: fix mem leak when command is unknown

In bnx2x_mcast_enqueue_cmd() we'll leak the memory allocated to
'new_cmd' if we hit the deafault case of the 'switch (cmd)'.
Add a 'kfree(new_cmd)' to that case to avoid the leak.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ARM: dts: imx27-3ds.dts: Fix serial console node

Fix serial console node and allow the board to boot again.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
ipv4: route.c cleanup

Remove unused includes after IP cache removal

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
cfg80211: add channel flag to prohibit OFDM operation

Currently the only way for wireless drivers to tell whether or not OFDM
is allowed on the current channel is to check the regulatory
information. However, this requires hodling cfg80211_mutex, which is not
visible to the drivers.

Other regulatory restrictions are provided as flags in the channel
definition, so let's do similarly with OFDM. This patch adds a new flag,
IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
allowed. This flag is set on any channels for which regulatory indicates
that OFDM is prohibited.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tested-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: Clear "beacon_found" on regulatory restore

Restore the default state to the "beacon_found" flag when
the channel flags are restored.  Otherwise, we can end up
with a channel that we can no longer transmit on even when
we can see beacons on that channel.

Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>