x86, MCE: Retract most UAPI exports

Retract back most macro definitions which went into the
user-visible mce.h header. Even though those bits are mostly
hardware-defined/-architectural, their naming is not. If we export them
to userspace, any kernel unification/renaming/cleanup cannot be done
anymore since those are effectively cast in stone. Besides, if userspace
wants those definitions, they can write their own defines and go crazy.

Signed-off-by: Borislav Petkov <bp@suse.de>
openvswitch: Move LRO check from transmit to receive.

The check for LRO packets was incorrectly put in the transmit path
instead of on receive.  Since this check is supposed to protect OVS
(and other parts of the system) from packets that it cannot handle
it is obviously not useful on egress.  Therefore, this commit moves
it back to the receive side.

The primary problem that this caused is upcalls to userspace tried
to segment the packet even though no segmentation information is
available.  This would later cause NULL pointer dereferences when
skb_gso_segment() did nothing.

Signed-off-by: Jesse Gross <jesse@nicira.com>
regulator: tps65217: Fix using wrong dev argument for calling of_regulator_match

The dev parameter is the device requestiong the data.
In this case it should be &pdev->dev rather than pdev->dev.parent.

The dev parameter is used to call devm_kzalloc in of_get_regulator_init_data(),
which means this fixes a memory leak because the memory is allocated every time
probe() is called, thus it should be freed when this driver is unloaded.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator: tps65910: Fix using wrong dev argument for calling of_regulator_match

The dev parameter is the device requesting the data.
In this case it should be &pdev->dev rather than pdev->dev.parent.

The dev parameter is used to call devm_kzalloc in of_get_regulator_init_data(),
which means this fixes a memory leak because the memory is allocated every time
probe() is called, thus it should be freed when this driver is unloaded.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Laxman Dewangan<ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Revert "iwlwifi: fix the reclaimed packet tracking upon flush queue"

This reverts commit f590dcec944552f9a4a61155810f3abd17d6465d
which has been reported to cause issues.

See https://lkml.org/lkml/2013/1/20/4 for further details.

Cc: stable@vger.kernel.org [3.7]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: off by one in ieee80211_bss()

We do a:

	sprintf(buf, " Last beacon: %ums ago",
		elapsed_jiffies_msecs(bss->ts));

elapsed_jiffies_msecs() can return a 10 digit number so "buf" needs to
be 31 characters long.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
regulator: max8998: fix incorrect min_uV value for ldo10

Correct value for minimal voltage for ldo10 output is 950000 uV. This
patch fixes the typo introduced by patch adf6178ad5552a7f2f742a8c85343c50
("regulator: max8998: Use uV in voltage_map_desc"), what solves broken
probe of max8998 in v3.8-rc4.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator: max8907: Fix using wrong dev argument for calling of_regulator_match

The dev parameter is the device requesting the data.
In this case it should be &pdev->dev rather than pdev->dev.parent.

The dev parameter is used to call devm_kzalloc in of_get_regulator_init_data(),
which means this fixes a memory leak because the memory is allocated every time
probe() is called, thus it should be freed when this driver is unloaded.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator: max77686: Fix using wrong dev argument at various places

Use &pdev->dev rather than iodev->dev for dev_err().
Use &pdev->dev rather than iodev->dev for devm_kzalloc() and
of_regulator_match(), this fixes memory leak.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator: max8997: Fix using wrong dev argument at various places

Use &pdev->dev rather than iodev->dev for dev_err(), dev_warn() and dev_info().
Use &pdev->dev rather than iodev->dev for devm_kzalloc() and
of_get_regulator_init_data(), this fixes memory leak.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
ipvs: freeing uninitialized pointer on error

If state != IP_VS_STATE_BACKUP then tinfo->buf is uninitialized.  If
kthread_run() fails then it means we free random memory resulting in an
oops.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
brcmsmac: fix tx status processing

This issue was reported on the wireless list (see [1]) in which
brcmsmac ran into a fatal error:

[  588.284074] brcmsmac bcma0:0: frameid != txh->TxFrameID
[  588.284098] brcmsmac bcma0:0: MI_TFS: fatal
[  588.284103] brcmsmac bcma0:0: wl0: fatal error, reinitializing
[  588.286208] ieee80211 phy0: Hardware restart was requested

The tx status feedback is processed in a loop limiting the number of
frames processed in one run. The code terminate processing when the
limit is reached regardless the txstatus value read from the device
register. When that status is is flagged as being valid it must be
processed as the hardware will clear it after is has been read.

Bisecting was done by Seth Forshee and showed following commit as the
culprit:

commit 57fe504817ccec9b6ac23e973d2925343bf1e3b6
Author: Piotr Haber <phaber@broadcom.com>
Date:   Wed Nov 28 21:44:07 2012 +0100

    brcmsmac: fix bounds checking in tx/rx

[1] http://www.spinics.net/lists/linux-wireless/msg101293.html

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
bcma: fix NAND flash validation

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Fix the usage of the wrong variable in usb.c

In routine _rtl_rx_pre_process(), skb_dequeue() is called to get an skb;
however, the wrong variable name is used in subsequent calls.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
l2tp: prevent l2tp_tunnel_delete racing with userspace close

If a tunnel socket is created by userspace, l2tp hooks the socket destructor
in order to clean up resources if userspace closes the socket or crashes.  It
also caches a pointer to the struct sock for use in the data path and in the
netlink interface.

While it is safe to use the cached sock pointer in the data path, where the
skb references keep the socket alive, it is not safe to use it elsewhere as
such access introduces a race with userspace closing the socket.  In
particular, l2tp_tunnel_delete is prone to oopsing if a multithreaded
userspace application closes a socket at the same time as sending a netlink
delete command for the tunnel.

This patch fixes this oops by forcing l2tp_tunnel_delete to explicitly look up
a tunnel socket held by userspace using sockfd_lookup().

Signed-off-by: Tom Parkin <tparkin@katalix.com>
Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
netem: fix delay calculation in rate extension

The delay calculation with the rate extension introduces in v3.3 does
not properly work, if other packets are still queued for transmission.
For the delay calculation to work, both delay types (latency and delay
introduces by rate limitation) have to be handled differently. The
latency delay for a packet can overlap with the delay of other packets.
The delay introduced by the rate however is separate, and can only
start, once all other rate-introduced delays finished.

Latency delay is from same distribution for each packet, rate delay
depends on the packet size.

.: latency delay
-: rate delay
x: additional delay we have to wait since another packet is currently
   transmitted

  .....----                    Packet 1
    .....xx------              Packet 2
               .....------     Packet 3
    ^^^^^
    latency stacks
         ^^
         rate delay doesn't stack
               ^^
               latency stacks

  -----> time

When a packet is enqueued, we first consider the latency delay. If other
packets are already queued, we can reduce the latency delay until the
last packet in the queue is send, however the latency delay cannot be
<0, since this would mean that the rate is overcommitted.  The new
reference point is the time at which the last packet will be send. To
find the time, when the packet should be send, the rate introduces delay
has to be added on top of that.

Signed-off-by: Johannes Naab <jn@stusta.de>
Acked-by: Hagen Paul Pfeifer <hagen@jauu.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
pktgen: correctly handle failures when adding a device

The return value of pktgen_add_device() is not checked, so
even if we fail to add some device, for example, non-exist one,
we still see "OK:...". This patch fixes it.

After this patch, I got:

	# echo "add_device non-exist" > /proc/net/pktgen/kpktgend_0
	-bash: echo: write error: No such device
	# cat /proc/net/pktgen/kpktgend_0
	Running:
	Stopped:
	Result: ERROR: can not add device non-exist
	# echo "add_device eth0" > /proc/net/pktgen/kpktgend_0
	# cat /proc/net/pktgen/kpktgend_0
	Running:
	Stopped: eth0
	Result: OK: add_device=eth0

(Candidate for -stable)

Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
tun: fix carrier on/off status

Commit c8d68e6be1c3b242f1c598595830890b65cea64a removed carrier off call
from tun_detach since it's now called on queue disable and not only on
tun close.  This confuses userspace which used this flag to detect a
free tun. To fix, put this back but under if (clean).

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Jason Wang <jasowang@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>