ipvs: fix crash with sync protocol v0 and FTP

commit 56184858d1fc95c46723436b455cb7261cd8be6f upstream.

Fix crash in 3.5+ if FTP is used after switching
sync_version to 0.

Fixes: 749c42b620a9 ("ipvs: reduce sync rate with time thresholds")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipvs: do not use random local source address for tunnels

commit 4754957f04f5f368792a0eb7dab0ae89fb93dcfd upstream.

Michael Vallaly reports about wrong source address used
in rare cases for tunneled traffic. Looks like
__ip_vs_get_out_rt in 3.10+ is providing uninitialized
dest_dst->dst_saddr.ip because ip_vs_dest_dst_alloc uses
kmalloc. While we retry after seeing EINVAL from routing
for data that does not look like valid local address, it
still succeeded when this memory was previously used from
other dests and with different local addresses. As result,
we can use valid local address that is not suitable for
our real server.

Fix it by providing 0.0.0.0 every time our cache is refreshed.
By this way we will get preferred source address from routing.

Reported-by: Michael Vallaly <lvs@nolatency.com>
Fixes: 026ace060dfe ("ipvs: optimize dst usage for real server")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Initialize msg/shm IPC objects before doing ipc_addid()

commit b9a532277938798b53178d5a66af6e2915cb27cf upstream.

As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before
having initialized the IPC object state.  Yes, we initialize the IPC
object in a locked state, but with all the lockless RCU lookup work,
that IPC object lock no longer means that the state cannot be seen.

We already did this for the IPC semaphore code (see commit e8577d1f0329:
"ipc/sem.c: fully initialize sem_array before making it visible") but we
clearly forgot about msg and shm.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers

commit 4758dcd19a7d9ba9610b38fecb93f65f56f86346 upstream.

This commit checks for the URB_ZERO_PACKET flag and creates an extra
zero-length td if the urb transfer length is a multiple of the endpoint's
max packet length.

Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: change xhci 1.0 only restrictions to support xhci 1.1

commit dca7794539eff04b786fb6907186989e5eaaa9c2 upstream.

Some changes between xhci 0.96 and xhci 1.0 specifications forced us to
check the hci version in code, some of these checks were implemented as
hci_version == 1.0, which will not work with new xhci 1.1 controllers.

xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these
checks to hci_version >= 1.0

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci: Clear XHCI_STATE_DYING on start

commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 upstream.

For whatever reason if XHCI died in the previous instant
then it will never recover on the next xhci_start unless we
clear the DYING flag.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: whiteheat: fix potential null-deref at probe

commit cbb4be652d374f64661137756b8f357a1827d6a4 upstream.

Fix potential null-pointer dereference at probe by making sure that the
required endpoints are present.

The whiteheat driver assumes there are at least five pairs of bulk
endpoints, of which the final pair is used for the "command port". An
attempt to bind to an interface with fewer bulk endpoints would
currently lead to an oops.

Fixes CVE-2015-5257.

Reported-by: Moein Ghasemzadeh <moein@istuary.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm: Reject DRI1 hw lock ioctl functions for kms drivers

commit da168d81b44898404d281d5dbe70154ab5f117c1 upstream.

I've done some extensive history digging across libdrm, mesa and
xf86-video-{intel,nouveau,ati}. The only potential user of this with
kms drivers I could find was ttmtest, which once used drmGetLock
still. But that mistake was quickly fixed up. Even the intel xvmc
library (which otherwise was really good with using dri1 stuff in kms
mode) managed to never take the hw lock for dri2 (and hence kms).

Hence it should be save to unconditionally disallow this.

Cc: Peter Antoine <peter.antoine@intel.com>
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

disabling oplocks/leases via module parm enable_oplocks broken for SMB3

commit e0ddde9d44e37fbc21ce893553094ecf1a633ab5 upstream.

leases (oplocks) were always requested for SMB2/SMB3 even when oplocks
disabled in the cifs.ko module.

Signed-off-by: Steve French <steve.french@primarydata.com>
Reviewed-by: Chandrika Srinivasan <chandrika.srinivasan@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_conntrack: Support expectations in different zones

commit 4b31814d20cbe5cd4ccf18089751e77a04afe4f2 upstream.

When zones were originally introduced, the expectation functions were
all extended to perform lookup using the zone. However, insertion was
not modified to check the zone. This means that two expectations which
are intended to apply for different connections that have the same tuple
but exist in different zones cannot both be tracked.

Fixes: 5d0aa2ccd4 (netfilter: nf_conntrack: add support for "conntrack zones")
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm raid: fix round up of default region size

commit 042745ee53a0a7c1f5aff191a4a24213c6dcfb52 upstream.

Commit 3a0f9aaee028 ("dm raid: round region_size to power of two")
intended to make sure that the default region size is a power of two.
However, the logic in that commit is incorrect and sets the variable
region_size to 0 or 1, depending on whether min_region_size is a power
of two.

Fix this logic, using roundup_pow_of_two(), so that region_size is
properly rounded up to the next power of two.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fixes: 3a0f9aaee028 ("dm raid: round region_size to power of two")
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: option: add ZTE PIDs

commit 19ab6bc5674a30fdb6a2436b068d19a3c17dc73e upstream.

This is intended to add ZTE device PIDs on kernel.

Signed-off-by: Liu.Zhao <lzsos369@163.com>
[johan: sort the new entries ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm btree: add ref counting ops for the leaves of top level btrees

commit b0dc3c8bc157c60b1d470163882be8c13e1950af upstream.

When using nested btrees, the top leaves of the top levels contain
block addresses for the root of the next tree down.  If we shadow a
shared leaf node the leaf values (sub tree roots) should be incremented
accordingly.

This is only an issue if there is metadata sharing in the top levels.
Which only occurs if metadata snapshots are being used (as is possible
with dm-thinp).  And could result in a block from the thinp metadata
snap being reused early, thus corrupting the thinp metadata snap.

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: comedi: adl_pci7x3x: fix digital output on PCI-7230

commit ad83dbd974feb2e2a8cc071a1d28782bd4d2c70e upstream.

The "adl_pci7x3x" driver replaced the "adl_pci7230" and "adl_pci7432"
drivers in commits 8f567c373c4b ("staging: comedi: new adl_pci7x3x
driver") and 657f77d173d3 ("staging: comedi: remove adl_pci7230 and
adl_pci7432 drivers").  Although the new driver code agrees with the
user manuals for the respective boards, digital outputs stopped working
on the PCI-7230.  This has 16 digital output channels and the previous
adl_pci7230 driver shifted the 16 bit output state left by 16 bits
before writing to the hardware register.  The new adl_pci7x3x driver
doesn't do that.  Fix it in `adl_pci7x3x_do_insn_bits()` by checking
for the special case of the subdevice having only 16 channels and
duplicating the 16 bit output state into both halves of the 32-bit
register.  That should work both for what the board actually does and
for what the user manual says it should do.

Fixes: 8f567c373c4b ("staging: comedi: new adl_pci7x3x driver")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: skip waiting on ordered range for special files

commit a30e577c96f59b1e1678ea5462432b09bf7d5cbc upstream.

In btrfs_evict_inode, we properly truncate the page cache for evicted
inodes but then we call btrfs_wait_ordered_range for every inode as well.
It's the right thing to do for regular files but results in incorrect
behavior for device inodes for block devices.

filemap_fdatawrite_range gets called with inode->i_mapping which gets
resolved to the block device inode before getting passed to
wbc_attach_fdatawrite_inode and ultimately to inode_to_bdi.  What happens
next depends on whether there's an open file handle associated with the
inode.  If there is, we write to the block device, which is unexpected
behavior.  If there isn't, we through normally and inode->i_data is used.
We can also end up racing against open/close which can result in crashes
when i_mapping points to a block device inode that has been closed.

Since there can't be any page cache associated with special file inodes,
it's safe to skip the btrfs_wait_ordered_range call entirely and avoid
the problem.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100911
Tested-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: dwc: correct irq clear method

commit 4873867e5f2bd90faad861dd94865099fc3140f3 upstream.

from Designware I2S datasheet, tx/rx XRUN irq is cleared by
reading register TOR/ROR, rather than by writing into them.

Signed-off-by: Yitian Bu <yitian.bu@tangramtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: fix broken pxa SoC support

commit 3c8f7710c1c44fb650bc29b6ef78ed8b60cfaa28 upstream.

The previous fix of pxa library support, which was introduced to fix the
library dependency, broke the previous SoC behavior, where a machine
code binding pxa2xx-ac97 with a coded relied on :
 - sound/soc/pxa/pxa2xx-ac97.c
 - sound/soc/codecs/XXX.c

For example, the mioa701_wm9713.c machine code is currently broken. The
"select ARM" statement wrongly selects the soc/arm/pxa2xx-ac97 for
compilation, as per an unfortunate fate SND_PXA2XX_AC97 is both declared
in sound/arm/Kconfig and sound/soc/pxa/Kconfig.

Fix this by ensuring that SND_PXA2XX_SOC correctly triggers the correct
pxa2xx-ac97 compilation.

Fixes: 846172dfe33c ("ASoC: fix SND_PXA2XX_LIB Kconfig warning")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: synth: Fix conflicting OSS device registration on AWE32

commit 225db5762dc1a35b26850477ffa06e5cd0097243 upstream.

When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel
warnings like:
  WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80()
  sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0'

It's because both emux synth and opl3 drivers try to register their
OSS device object with the same static index number 0.  This hasn't
been a big problem until the recent rewrite of device management code
(that exposes sysfs at the same time), but it's been an obvious bug.

This patch works around it just by using a different index number of
emux synth object.  There can be a more elegant way to fix, but it's
enough for now, as this code won't be touched so often, in anyway.

Reported-and-tested-by: Michael Shell <list1@michaelshell.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault

commit 2f84a8990ebbe235c59716896e017c6b2ca1200f upstream.

SunDong reported the following on

  https://bugzilla.kernel.org/show_bug.cgi?id=103841

I think I find a linux bug, I have the test cases is constructed. I
can stable recurring problems in fedora22(4.0.4) kernel version,
arch for x86_64.  I construct transparent huge page, when the parent
and child process with MAP_SHARE, MAP_PRIVATE way to access the same
huge page area, it has the opportunity to lead to huge page copy on
write failure, and then it will munmap the child corresponding mmap
area, but then the child mmap area with VM_MAYSHARE attributes, child
process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
functions (vma - > vm_flags & VM_MAYSHARE).

There were a number of problems with the report (e.g.  it's hugetlbfs that
triggers this, not transparent huge pages) but it was fundamentally
correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
looks like this

 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
 pgoff 0 file ffff88106bdb9800 private_data           (null)
 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
 ------------
 kernel BUG at mm/hugetlb.c:462!
 SMP
 Modules linked in: xt_pkttype xt_LOG xt_limit [..]
 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
 set_vma_resv_flags+0x2d/0x30

The VM_BUG_ON is correct because private and shared mappings have
different reservation accounting but the warning clearly shows that the
VMA is shared.

When a private COW fails to allocate a new page then only the process
that created the VMA gets the page -- all the children unmap the page.
If the children access that data in the future then they get killed.

The problem is that the same file is mapped shared and private.  During
the COW, the allocation fails, the VMAs are traversed to unmap the other
private pages but a shared VMA is found and the bug is triggered.  This
patch identifies such VMAs and skips them.

Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reported-by: SunDong <sund_sky@126.com>
Reviewed-by: Michal Hocko <mhocko@suse.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled

commit 02bc933ebb59208f42c2e6305b2c17fd306f695d upstream.

On Intel Baytrail, there is case when interrupt handler get called, no SPI
message is captured. The RX FIFO is indeed empty when RX timeout pending
interrupt (SSSR_TINT) happens.

Use the BIOS version where both HSUART and SPI are on the same IRQ. Both
drivers are using IRQF_SHARED when calling the request_irq function. When
running two separate and independent SPI and HSUART application that
generate data traffic on both components, user will see messages like
below on the console:

  pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler

This commit will fix this by first checking Receiver Time-out Interrupt,
if it is disabled, ignore the request and return without servicing.

Signed-off-by: Tan, Jui Nee <jui.nee.tan@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: Fix documentation of spi_alloc_master()

commit a394d635193b641f2c86ead5ada5b115d57c51f8 upstream.

Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
by kfree(). The memory is already freed with the call to spi_master_put()
through spi_master_class, which registers a release function. Calling both
spi_master_put() and kfree() results in often nasty (and delayed) crashes
elsewhere in the kernel, often in the networking stack.

This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.

Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269
or
http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html

Alexey Klimov: This revert becomes valid after
94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c
has been fixed and there is no need to call kfree() so comment
for spi_alloc_master() should be fixed.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

commit 0b34a166f291d255755be46e43ed5497cdd194f2 upstream.

Currently there is a number of issues preventing PVHVM Xen guests from
doing successful kexec/kdump:

  - Bound event channels.
  - Registered vcpu_info.
  - PIRQ/emuirq mappings.
  - shared_info frame after XENMAPSPACE_shared_info operation.
  - Active grant mappings.

Basically, newly booted kernel stumbles upon already set up Xen
interfaces and there is no way to reestablish them. In Xen-4.7 a new
feature called 'soft reset' is coming. A guest performing kexec/kdump
operation is supposed to call SCHEDOP_shutdown hypercall with
SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
(with some help from toolstack) will do full domain cleanup (but
keeping its memory and vCPU contexts intact) returning the guest to
the state it had when it was first booted and thus allowing it to
start over.

Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
probably OK as by default all unknown shutdown reasons cause domain
destroy with a message in toolstack log: 'Unknown shutdown reason code
5. Destroying domain.'  which gives a clue to what the problem is and
eliminates false expectations.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/mm: Set NX on gap between __ex_table and rodata

commit ab76f7b4ab2397ffdd2f1eb07c55697d19991d10 upstream.

Unused space between the end of __ex_table and the start of
rodata can be left W+x in the kernel page tables.  Extend the
setting of the NX bit to cover this gap by starting from
text_end rather than rodata_start.

  Before:
  ---[ High Kernel Mapping ]---
  0xffffffff80000000-0xffffffff81000000          16M                               pmd
  0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
  0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
  0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB x  pte
  0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
  0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
  0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
  0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
  0xffffffff82200000-0xffffffffa0000000         478M                               pmd

  After:
  ---[ High Kernel Mapping ]---
  0xffffffff80000000-0xffffffff81000000          16M                               pmd
  0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
  0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
  0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB NX pte
  0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
  0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
  0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
  0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
  0xffffffff82200000-0xffffffffa0000000         478M                               pmd

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.gov
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

commit d2922422c48df93f3edff7d872ee4f3191fefb08 upstream.

The cpu feature flags are not ever going to change, so warning
everytime can cause a lot of kernel log spam
(in our case more than 10GB/hour).

The warning seems to only occur when nested virtualization is
enabled, so it's probably triggered by a KVM bug.  This is a
sensible and safe change anyway, and the KVM bug fix might not
be suitable for stable releases anyway.

Signed-off-by: Dirk Mueller <dmueller@suse.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/platform: Fix Geode LX timekeeping in the generic x86 build

commit 03da3ff1cfcd7774c8780d2547ba0d995f7dc03d upstream.

In 2007, commit 07190a08eef36 ("Mark TSC on GeodeLX reliable")
bypassed verification of the TSC on Geode LX. However, this code
(now in the check_system_tsc_reliable() function in
arch/x86/kernel/tsc.c) was only present if CONFIG_MGEODE_LX was
set.

OpenWRT has recently started building its generic Geode target
for Geode GX, not LX, to include support for additional
platforms. This broke the timekeeping on LX-based devices,
because the TSC wasn't marked as reliable:
https://dev.openwrt.org/ticket/20531

By adding a runtime check on is_geode_lx(), we can also include
the fix if CONFIG_MGEODEGX1 or CONFIG_X86_GENERIC are set, thus
fixing the problem.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: Andres Salomon <dilinger@queued.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <marcelo@kvack.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1442409003.131189.87.camel@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/apic: Serialize LVTT and TSC_DEADLINE writes

commit 5d7c631d926b59aa16f3c56eaeb83f1036c81dc7 upstream.

The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an
MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not
guaranteed that the write to LVTT has reached the APIC before the
TSC_DEADLINE MSR is written. In such a case the write to the MSR is
ignored and as a consequence the local timer interrupt never fires.

The SDM decribes this issue for xAPIC and x2APIC modes. The
serialization methods recommended by the SDM differ.

xAPIC:
 "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
  2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current time-stamp counter.
  3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2.
  4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline."

x2APIC:
 "To allow for efficient access to the APIC registers in x2APIC mode,
  the serializing semantics of WRMSR are relaxed when writing to the
  APIC registers. Thus, system software should not use 'WRMSR to APIC
  registers in x2APIC mode' as a serializing instruction. Read and write
  accesses to the APIC registers will occur in program order. A WRMSR to
  an APIC register may complete before all preceding stores are globally
  visible; software can prevent this by inserting a serializing
  instruction, an SFENCE, or an MFENCE before the WRMSR."

The xAPIC method is to just wait for the memory mapped write to hit
the LVTT by checking whether the MSR write has reached the hardware.
There is no reason why a proper MFENCE after the memory mapped write would
not do the same. Andi Kleen confirmed that MFENCE is sufficient for the
xAPIC case as well.

Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done
unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE
support.

[ tglx: Massaged the changelog ]

Signed-off-by: Shaohua Li <shli@fb.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: <Kernel-team@fb.com>
Cc: <lenb@kernel.org>
Cc: <fenghua.yu@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: http://lkml.kernel.org/r/20150909041352.GA2059853@devbig257.prn2.facebook.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

windfarm: decrement client count when unregistering

commit fe2b592173ff0274e70dc44d1d28c19bb995aa7c upstream.

wf_unregister_client() increments the client count when a client
unregisters. That is obviously incorrect. Decrement that client count
instead.

Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines")
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: 8429/1: disable GCC SRA optimization

commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 upstream.

While working on the 32-bit ARM port of UEFI, I noticed a strange
corruption in the kernel log. The following snprintf() statement
(in drivers/firmware/efi/efi.c:efi_md_typeattr_format())

snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",

was producing the following output in the log:

|    |   |   |   |    |WB|WT|WC|UC]
|    |   |   |   |    |WB|WT|WC|UC]
|    |   |   |   |    |WB|WT|WC|UC]
|RUN|   |   |   |    |WB|WT|WC|UC]*
|RUN|   |   |   |    |WB|WT|WC|UC]*
|    |   |   |   |    |WB|WT|WC|UC]
|RUN|   |   |   |    |WB|WT|WC|UC]*
|    |   |   |   |    |WB|WT|WC|UC]
|RUN|   |   |   |    |   |   |   |UC]
|RUN|   |   |   |    |   |   |   |UC]

As it turns out, this is caused by incorrect code being emitted for
the string() function in lib/vsprintf.c. The following code

if (!(spec.flags & LEFT)) {
while (len < spec.field_width--) {
if (buf < end)
*buf = ' ';
++buf;
}
}
for (i = 0; i < len; ++i) {
if (buf < end)
*buf = *s;
++buf; ++s;
}
while (len < spec.field_width--) {
if (buf < end)
*buf = ' ';
++buf;
}

when called with len == 0, triggers an issue in the GCC SRA optimization
pass (Scalar Replacement of Aggregates), which handles promotion of signed
struct members incorrectly. This is a known but as yet unresolved issue.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
case, it is causing the second while loop to be executed erroneously a
single time, causing the additional space characters to be printed.

So disable the optimization by passing -fno-ipa-sra.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf header: Fixup reading of HEADER_NRCPUS feature

commit caa470475d9b59eeff093ae650800d34612c4379 upstream.

The original patch introducing this header wrote the number of CPUs available
and online in one order and then swapped those values when reading, fix it.

Before:

  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 4
  # echo 0 > /sys/devices/system/cpu/cpu2/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 3
  # echo 0 > /sys/devices/system/cpu/cpu1/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 2

After the fix, bringing back the CPUs online:

  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 2
  # nrcpus avail : 4
  # echo 1 > /sys/devices/system/cpu/cpu2/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 3
  # nrcpus avail : 4
  # echo 1 > /sys/devices/system/cpu/cpu1/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 4

Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: fbe96f29ce4b ("perf tools: Make perf.data more self-descriptive (v8)")
Link: http://lkml.kernel.org/r/20150911153323.GP23511@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: fix scsi_error_handler vs. scsi_host_dev_release race

commit 537b604c8b3aa8b96fe35f87dd085816552e294c upstream.

b9d5c6b7ef57 ("[SCSI] cleanup setting task state in
scsi_error_handler()") has introduced a race between scsi_error_handler
and scsi_host_dev_release resulting in the hang when the device goes
away because scsi_error_handler might miss a wake up:

CPU0 CPU1
scsi_error_handler scsi_host_dev_release
     kthread_stop()
  kthread_should_stop()
    test_bit(KTHREAD_SHOULD_STOP)
    set_bit(KTHREAD_SHOULD_STOP)
    wake_up_process()
    wait_for_completion()

  set_current_state(TASK_INTERRUPTIBLE)
  schedule()

The most straightforward solution seems to be to invert the ordering of
the set_current_state and kthread_should_stop.

The issue has been noticed during reboot test on a 3.0 based kernel but
the current code seems to be affected in the same way.

[jejb: additional comment added]
Reported-and-debugged-by: Mike Mayer <Mike.Meyer@teradata.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: rockchip: rockchip_defconfig: enable DEBUG_INFO

Better support for DS-5

Change-Id: If54a51c32c0ece2df08f3a6d79da1bff8a51eda6
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

OP-TEE: build optee_linuxdriver into kernel

Change-Id: I4cacc3b0670643ab02af592549de988f11c378df
Signed-off-by: Zhang Zhijie <zhangzj@rock-chips.com>

ARM: dts: rk3228: add syscon node for sgrf\grf\cru\ddrpctl\msch

Change-Id: I00bdb4b64a4e5e0a7f5fcd9dd29ec76fd4aba218
Signed-off-by: Chen Liang <cl@rock-chips.com>

ARM: dts: rk3228: support cru soft reset

support cru soft reset for rk3228.

Change-Id: I7bd1a58d55bdd2b2f1eb3ae9fc80705ffb74c1be
Signed-off-by: zhangqing <zhangqing@rock-chips.com>

thermal: rockchip: fix an error code

3.19.8-ckt2 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <dan.carpenter@oracle.com>

commit 0d0a2bf6ed4b489eef9a84450b3d90e6e001ce63 upstream.

There is a copy and paste bug, "->clk" vs "->pclk", so we return the
wrong error code here.

Change-Id: I3ef649ce940016fd9214ea924b243a07bdc58248
Fixes: cbac8f639437 ('thermal: rockchip: add driver for thermal')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

rk312x, mali_400: make it more 'difficult' to disable one core in low load.

Change-Id: I8f9aaa5d442a1d0f7a7685ba1885ad39b89ee097
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

rk3368: thermal: remove unused code and fix style

Change-Id: Ie9e370082e422f528b4156a56b4ebc881686b12a
Signed-off-by: David Wu <wdc@rock-chips.com>

cpufreq: rockchip: fix scale rate error when resume

If the return value is 0, it will change voltage in DVFS and lead to
error when resume. Here it change frequency unsuccessfully in fact, so
it need return -EINVAL.

Change-Id: Ia9eff9f75060fcc79c1b275c19de8740754617de
Signed-off-by: Xiao Feng <xf@rock-chips.com>

ARM: rk3228: dts: add SDCard/SDIO/eMMC DTS node for RK3228 SDK board

Change-Id: I32b778c73a7aeb9461c462b0328f98eca0a06fdc
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>

ARM: rk3228: dtsi: add SDCard/SDIO/eMMC DTS node for RK3228 Chip

Change-Id: I172bceadc7bb4a09394837fd6bb81bbbedd7ddae
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>

rk312x, mali_400: add comments and reform some detail codes in PDP.

PDP: platform_dependent_part

Change-Id: I82fa8be69966ee6dddac48d899df5254ab38c87f
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

8723BU: Update 8723BU wifi driver to version v4.3.16_14189.20150519_BTCOEX2015119-5844

This driver is released by RealTek, main update as shown below:

1.  Support Android 5.0,5.1 and older
2.  Support Linux kernel 3.19.3 and older
3.  Improve Wi-Fi/BT Coexistence stability and performance
4.  Fix the problem of unexpected scan timeout
5.  Add TDLS function
6.  Fix STA mode disconnect problem caused by not checking TA of DEAUTH and DISASSOC frame
7.  Fix the failed association issue with specific AP which supports only 11n MCS data rate

Change-Id: I103d22a06eecc456c9777f17afdd1049efe9ff6a
Signed-off-by: Xu Xuehui <xxh@rock-chips.com>

video: rockchip: tve: support rk3228

Change-Id: I7046f5b42de442c8bf7946a537d3e26922882d1d
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>

ARM: dts: rk3228: add tve config

Change-Id: I455e94459078632d42e9653b926d3fc4d06bddb4
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>

OP-TEE: add optee driver from GitHub: optee_linuxdriver

Commit 4136b9d5a139(Fix TEESMC{32,64}_FASTCALL_RETURN_FROM_RPC)

Change-Id: I389e4f79270e3bc6e8844ec81758f8b5546192a1
Signed-off-by: Zhang Zhijie <zhangzj@rock-chips.com>

ARM: rockchip_defconfig: add config for mali_400_ko.

Change-Id: I6f28c56fd5a9f9fb77980e09ed2f15c6f997337c
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

video: lcdc: 3228: update colorspace config

Add windows bt601 and bt709 convert

Change-Id: I0a24227e91c5bf7643f72ef79acaadde1a37be25
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

rk3228: dts: add series nodes for display

Change-Id: I488ac645ceb7ccd7ecd7512f711ce5418553e431
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

video: lcdc: 3228: fix alpha when only one layer enable

rk3228 not support ppixel_alpha mode when only one layer enable.

Change-Id: I4de3a46f2f876230932a09fd202f318b130a5709
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

video: lcdc: 3228: fix post colorspace display

fix table offset, config and overlay mode.

Change-Id: I1e0af6c2b56db9a509495c17b53835c1722b68ba
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

rk3228: gpu: fix rk3228 gpu pd issue

1. For compatible with other SOC,more dig into gpu pd when init gpu pd
2. Add cpu_is_rk3228 macro for gpu

Change-Id: I3adf4ab32d98c0cfebb0f0e769fac1b84f525c6f
Signed-off-by: Simon Xue <xxm@rock-chips.com>

usb: rk3368: set disconnect threshold to 625 mV

The disconnect threshold of 28nm usb phy from innosilicon is
imprecise, if the value set to 575 mV will trigger unnecessary
disconnect interrupt.

Change-Id: I63985fb9257a1142bdad476583c0c141de70618d
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

rk312x, mali_400: modify period_of_notifying_mali_utilization to 20 ms.

This is a rk_custom_in_common_part.

Change-Id: I3d691c01ed199a17980dadf03e6d3c1b711f9159
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

ARM: dts: rk3228: add hdmi and hdcp22

Change-Id: I4c2081ce5bbede0880361b54aa38478c79e529fa
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

video: rockchip: hdmi: support rk3228

Change-Id: I3b1e3d4042c5b14e0759418c29e112dfae7d50b1
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

Merge branch 'linux-linaro-lsk-v3.10' into linux-linaro-lsk-v3.10-android

rk312x, mali_400: correct coding style in platform_dependent_part.

Change-Id: I312b59f8875fd5d115a3a1c1e925a38afe8e7fa6
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

ARM: dts: rk3228: add vop/vpu/hevc/iep iommu config

Change-Id: Id784598ad7af4ddb5569423a4f77e035b4a7c9d0
Signed-off-by: Simon Xue <xxm@rock-chips.com>

ARM: dts: rk3228: clk: rename gpu clk name

change gpu clk name aclk_gpu to clk_gpu.

Change-Id: I0ee1fc47b94d7459914c6040aa3bcfc616626a83
Signed-off-by: zhangqing <zhangqing@rock-chips.com>

video: rockchip: hdmiv1: fix no sound/noise problem

when hdmi mute audio, need to reset the audio logic and fifo.
otherwise, this may lead no sound/noise sometimes.

this patch add power down hdmi audio logic when mute audio,
and then power up hdmi audio logic when unmute audio.

Change-Id: Ifb8beac9690764b4ec1c6d3e1dfdb4253a05df51
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

video: rockchip: fb: distinguish between RGB YUV and FBDC data format

Change-Id: Ia351340cf05e5264d798348178b488917ada4482
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

video: rockchip: lcdc: 3288: fix iommu pagefault when user set win3 dsp size bigger than act size

Change-Id: Icf474cf35c9bbf37deccd415e810f7d0a0c2142d
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

video: rockchip: hdmi: v2: phy support clk 59.4MHz

Change-Id: Ibce9bcd09fa8011642c7a9e8de9f4b3471c23e8b
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

ARM: dts: rk3228: add gpu config

Change-Id: Ib8dbc4ede8abd4816e501454fe4a1f21fe3f54ad
Signed-off-by: Simon Xue <xxm@rock-chips.com>

video: rockchip: hdmi: 3288w: support HDCP2.2

Change-Id: Ie20cba47fa925b5a3cce49ec2557e47ce737459e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit db93f1aadfa06f47a0b9041b172cfcc4028e4928)

Merge branch 'linux-3.10.y' of git://git./linux/kernel/git/stable/linux-stable into linux-linaro-lsk-v3.10

* 'linux-3.10.y' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (77 commits)
  Linux 3.10.90
  Revert "iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required"
  vfs: Remove incorrect debugging WARN in prepend_path
  fib_rules: fix fib rule dumps across multiple skbs
  sctp: fix race on protocol/netns initialization
  net/ipv6: Correct PIM6 mrt_lock handling
  ipv6: fix exthdrs offload registration in out_rt path
  usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared
  ip6_gre: release cached dst on tunnel removal
  rds: fix an integer overflow test in rds_info_getsockopt()
  netlink: don't hold mutex in rcu callback when releasing mmapd ring
  inet: frags: fix defragmented packet's IP header for af_packet
  bonding: fix destruction of bond with devices different from arphrd_ether
  ipv6: lock socket in ip6_datagram_connect()
  isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
  bridge: mdb: fix double add notification
  net: Fix skb_set_peeked use-after-free bug
  net: Fix skb csum races when peeking
  net: Clone skb before setting peeked flag
  net: call rcu_read_lock early in process_backlog
  ...

video: rockchip: display-sys: Add the same display interface device naming convention

When multiple same type display interface is registered, such as TV, named TV, TV1, TV2.

Change-Id: I33f7e12c4942c3bf7eb29cca8ef6037f9e78d1af
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>

rk3128-box: add dts file for NS kernel

Change-Id: I987886db8624e09deacc1fb6f19b4e5bf90cf6d8
Signed-off-by: Chen Liang <cl@rock-chips.com>

rk312x: add psci support

This is just add psci code into kernel, if you want to enable psci, you must
add psci=enable in the Command Line.

Change-Id: I3a6a24e455a4f684d543938257dc2771c5c267e2
Signed-off-by: Chen Liang <cl@rock-chips.com>

dts: rk3228: add i2s, spdif dts node

Change-Id: Icbec983c72b81cc584bf552522e02e9fcbc0c29c
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

rk_fb: add extern screen open iommu, when dual screen display using iommu

Change-Id: Ia216d102df6841d4497144fe3c53aaeea9860178
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>

video: rockchip: hdmi: fix parsing 1st block edid

If parsing 1st block edid failed, we think it is good
only when there is more than one external block.

Change-Id: I1eb11405dade41ebb2ad041ba909de0c7ea120f8
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

video: rockchip: fb: delele obsolete code for box

There is no difference between mid and box on setting
RK_FBIOSET_CONFIG_DONE.

Change-Id: I8a454a318ad8663b5e0f94ac05c067c6b386801a
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

arm64: dts: Makefile: Add more rockchip target in dtbs list

Change-Id: I85902304639d6c938df2ff3f1702d5a2531b26d1
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

ARM: dts: Makefile: Add more rockchip target in dtbs list

Change-Id: Ieaa459bed8b3a6f6b67b52c78d4a37d9e50836d3
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

rk3228: clk: enable aclk_dmac_bus when clk init

modify enable aclk_dmac_bus control bits.
make aclk_dmac_bus enabled when clk init.

Change-Id: I670dbaabcf9ba6cf9ce683090b49c72e4cbd0410
Signed-off-by: zhangqing <zhangqing@rock-chips.com>

arm: rockchip: rk3228: dts: add DMAC support

Change-Id: Ic6f8a106e8ecdcdf153873a65b90567b3edb48ad
Signed-off-by: Xiao Feng <xf@rock-chips.com>

video: rockchip: lcdc: 3288: set iommu_status to 0, when all layer closed

Change-Id: I494c54017be89e48836870f015f420a0c148c980
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>

esp8089: fix ESP8089 wifi can not work when use CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOT

Change-Id: Ib08bcc45f3c11e2de0f29c9739772d56071d467f
Signed-off-by: Xu Xuehui <xxh@rock-chips.com>

video: rockchip: hdmi: v2: get phy register setting from dts

We can configurate phy setting in dts node "rockchip,phy_table"
with following format:

<maxfreq pre-emphasis slopeboost clklevel data0level data1level data2level>

Phy setting table must list from low freq to high freq and cover
all supported frequency, for example:

&hdmi {
status = "okay";
rockchip,phy_table =
<165000000 0 0 17 17 17 17>,
<340000000 0 0 14 17 17 17>,
<594000000 0 0 9 17 17 17>;
};

If dts node is not exist, we use default setting defined in code.

Change-Id: I06731419057a2a8cf4d210bf566b1206edc39ea1
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

video: rockchip: hdmi: fix error of 8/10 bit color depth selection

Change-Id: I3c9c35dced4db9b5f103d0d3de482f33d7257ae0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

video: rockchip: hdmi: redefine input/output color relationship

For YCbCr420 mode, input color and output color must be same as
HDMI_COLOR_YCBCR420.

Change-Id: I302c1a0572d706abdebf5d2d35bd100e0242edf9
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit c3ed688f02f76dfc5533124c41bbb8c016e3cc97)

rk3288: dts: support popmetal opensource board

Change-Id: I42fd55bfa73d25643a9e0435af93e311d3ed3206
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

lcd: vga: add some vga timing

Change-Id: I6e54d0025b4622cdfcc3a4ceac443e441c7e1742
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

Linux 3.10.90

Revert "iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required"

This reverts commit 35c45e8bce3c92fb1ff94d376f1d4bfaae079d66 which was
commit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 upstream as it should
not have been applied.

Reported-by: Luis Henriques <luis.henriques@canonical.com>
Cc: Markus Pargmann <mpa@pengutronix.de>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfs: Remove incorrect debugging WARN in prepend_path

commit 93e3bce6287e1fb3e60d3324ed08555b5bbafa89 upstream.

The warning message in prepend_path is unclear and outdated.  It was
added as a warning that the mechanism for generating names of pseudo
files had been removed from prepend_path and d_dname should be used
instead.  Unfortunately the warning reads like a general warning,
making it unclear what to do with it.

Remove the warning.  The transition it was added to warn about is long
over, and I added code several years ago which in rare cases causes
the warning to fire on legitimate code, and the warning is now firing
and scaring people for no good reason.

Reported-by: Ivan Delalande <colona@arista.com>
Reported-by: Omar Sandoval <osandov@osandov.com>
Fixes: f48cfddc6729e ("vfs: In d_path don't call d_dname on a mount point")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[ vlee: Backported to 3.10. Adjusted context. ]
Signed-off-by: Vinson Lee <vlee@twitter.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fib_rules: fix fib rule dumps across multiple skbs

[ Upstream commit 41fc014332d91ee90c32840bf161f9685b7fbf2b ]

dump_rules returns skb length and not error.
But when family == AF_UNSPEC, the caller of dump_rules
assumes that it returns an error. Hence, when family == AF_UNSPEC,
we continue trying to dump on -EMSGSIZE errors resulting in
incorrect dump idx carried between skbs belonging to the same dump.
This results in fib rule dump always only dumping rules that fit
into the first skb.

This patch fixes dump_rules to return error so that we exit correctly
and idx is correctly maintained between skbs that are part of the
same dump.

Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sctp: fix race on protocol/netns initialization

[ Upstream commit 8e2d61e0aed2b7c4ecb35844fe07e0b2b762dee4 ]

Consider sctp module is unloaded and is being requested because an user
is creating a sctp socket.

During initialization, sctp will add the new protocol type and then
initialize pernet subsys:

        status = sctp_v4_protosw_init();
        if (status)
                goto err_protosw_init;

        status = sctp_v6_protosw_init();
        if (status)
                goto err_v6_protosw_init;

        status = register_pernet_subsys(&sctp_net_ops);

The problem is that after those calls to sctp_v{4,6}_protosw_init(), it
is possible for userspace to create SCTP sockets like if the module is
already fully loaded. If that happens, one of the possible effects is
that we will have readers for net->sctp.local_addr_list list earlier
than expected and sctp_net_init() does not take precautions while
dealing with that list, leading to a potential panic but not limited to
that, as sctp_sock_init() will copy a bunch of blank/partially
initialized values from net->sctp.

The race happens like this:

     CPU 0                           |  CPU 1
  socket()                           |
   __sock_create                     | socket()
    inet_create                      |  __sock_create
     list_for_each_entry_rcu(        |
        answer, &inetsw[sock->type], |
        list) {                      |   inet_create
      /* no hits */                  |
     if (unlikely(err)) {            |
      ...                            |
      request_module()               |
      /* socket creation is blocked  |
       * the module is fully loaded  |
       */                            |
       sctp_init                     |
        sctp_v4_protosw_init         |
         inet_register_protosw       |
          list_add_rcu(&p->list,     |
                       last_perm);   |
                                     |  list_for_each_entry_rcu(
                                     |     answer, &inetsw[sock->type],
        sctp_v6_protosw_init         |     list) {
                                     |     /* hit, so assumes protocol
                                     |      * is already loaded
                                     |      */
                                     |  /* socket creation continues
                                     |   * before netns is initialized
                                     |   */
        register_pernet_subsys       |

Simply inverting the initialization order between
register_pernet_subsys() and sctp_v4_protosw_init() is not possible
because register_pernet_subsys() will create a control sctp socket, so
the protocol must be already visible by then. Deferring the socket
creation to a work-queue is not good specially because we loose the
ability to handle its errors.

So, as suggested by Vlad, the fix is to split netns initialization in
two moments: defaults and control socket, so that the defaults are
already loaded by when we register the protocol, while control socket
initialization is kept at the same moment it is today.

Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace")
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/ipv6: Correct PIM6 mrt_lock handling

[ Upstream commit 25b4a44c19c83d98e8c0807a7ede07c1f28eab8b ]

In the IPv6 multicast routing code the mrt_lock was not being released
correctly in the MFC iterator, as a result adding or deleting a MIF would
cause a hang because the mrt_lock could not be acquired.

This fix is a copy of the code for the IPv4 case and ensures that the lock
is released correctly.

Signed-off-by: Richard Laing <richard.laing@alliedtelesis.co.nz>
Acked-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: fix exthdrs offload registration in out_rt path

[ Upstream commit e41b0bedba0293b9e1e8d1e8ed553104b9693656 ]

We previously register IPPROTO_ROUTING offload under inet6_add_offload(),
but in error path, we try to unregister it with inet_del_offload(). This
doesn't seem correct, it should actually be inet6_del_offload(), also
ipv6_exthdrs_offload_exit() from that commit seems rather incorrect (it
also uses rthdr_offload twice), but it got removed entirely later on.

Fixes: 3336288a9fea ("ipv6: Switch to using new offload infrastructure.")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared

[ Upstream commit f50791ac1aca1ac1b0370d62397b43e9f831421a ]

It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
usbnet_stop(), but its value should be read before it is cleared
when dev->flags is set to 0.

The problem was spotted and the fix was provided by
Oliver Neukum <oneukum@suse.de>.

Signed-off-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ip6_gre: release cached dst on tunnel removal

[ Upstream commit d4257295ba1b389c693b79de857a96e4b7cd8ac0 ]

When a tunnel is deleted, the cached dst entry should be released.

This problem may prevent the removal of a netns (seen with a x-netns IPv6
gre tunnel):
  unregister_netdevice: waiting for lo to become free. Usage count = 3

CC: Dmitry Kozlov <xeb@mail.ru>
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: huaibin Wang <huaibin.wang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rds: fix an integer overflow test in rds_info_getsockopt()

[ Upstream commit 468b732b6f76b138c0926eadf38ac88467dcd271 ]

"len" is a signed integer.  We check that len is not negative, so it
goes from zero to INT_MAX.  PAGE_SIZE is unsigned long so the comparison
is type promoted to unsigned long.  ULONG_MAX - 4095 is a higher than
INT_MAX so the condition can never be true.

I don't know if this is harmful but it seems safe to limit "len" to
INT_MAX - 4095.

Fixes: a8c879a7ee98 ('RDS: Info and stats')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netlink: don't hold mutex in rcu callback when releasing mmapd ring

[ Upstream commit 0470eb99b4721586ccac954faac3fa4472da0845 ]

Kirill A. Shutemov says:

This simple test-case trigers few locking asserts in kernel:

int main(int argc, char **argv)
{
        unsigned int block_size = 16 * 4096;
        struct nl_mmap_req req = {
                .nm_block_size          = block_size,
                .nm_block_nr            = 64,
                .nm_frame_size          = 16384,
                .nm_frame_nr            = 64 * block_size / 16384,
        };
        unsigned int ring_size;
int fd;

fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
        if (setsockopt(fd, SOL_NETLINK, NETLINK_RX_RING, &req, sizeof(req)) < 0)
                exit(1);
        if (setsockopt(fd, SOL_NETLINK, NETLINK_TX_RING, &req, sizeof(req)) < 0)
                exit(1);

ring_size = req.nm_block_nr * req.nm_block_size;
mmap(NULL, 2 * ring_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
return 0;
}

+++ exited with 0 +++
BUG: sleeping function called from invalid context at /home/kas/git/public/linux-mm/kernel/locking/mutex.c:616
in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
3 locks held by init/1:
 #0:  (reboot_mutex){+.+...}, at: [<ffffffff81080959>] SyS_reboot+0xa9/0x220
 #1:  ((reboot_notifier_list).rwsem){.+.+..}, at: [<ffffffff8107f379>] __blocking_notifier_call_chain+0x39/0x70
 #2:  (rcu_callback){......}, at: [<ffffffff810d32e0>] rcu_do_batch.isra.49+0x160/0x10c0
Preemption disabled at:[<ffffffff8145365f>] __delay+0xf/0x20

CPU: 1 PID: 1 Comm: init Not tainted 4.1.0-00009-gbddf4c4818e0 #253
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Debian-1.8.2-1 04/01/2014
 ffff88017b3d8000 ffff88027bc03c38 ffffffff81929ceb 0000000000000102
 0000000000000000 ffff88027bc03c68 ffffffff81085a9d 0000000000000002
 ffffffff81ca2a20 0000000000000268 0000000000000000 ffff88027bc03c98
Call Trace:
 <IRQ>  [<ffffffff81929ceb>] dump_stack+0x4f/0x7b
 [<ffffffff81085a9d>] ___might_sleep+0x16d/0x270
 [<ffffffff81085bed>] __might_sleep+0x4d/0x90
 [<ffffffff8192e96f>] mutex_lock_nested+0x2f/0x430
 [<ffffffff81932fed>] ? _raw_spin_unlock_irqrestore+0x5d/0x80
 [<ffffffff81464143>] ? __this_cpu_preempt_check+0x13/0x20
 [<ffffffff8182fc3d>] netlink_set_ring+0x1ed/0x350
 [<ffffffff8182e000>] ? netlink_undo_bind+0x70/0x70
 [<ffffffff8182fe20>] netlink_sock_destruct+0x80/0x150
 [<ffffffff817e484d>] __sk_free+0x1d/0x160
 [<ffffffff817e49a9>] sk_free+0x19/0x20
[..]

Cong Wang says:

We can't hold mutex lock in a rcu callback, [..]

Thomas Graf says:

The socket should be dead at this point. It might be simpler to
add a netlink_release_ring() function which doesn't require
locking at all.

Reported-by: "Kirill A. Shutemov" <kirill@shutemov.name>
Diagnosed-by: Cong Wang <cwang@twopensource.com>
Suggested-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

inet: frags: fix defragmented packet's IP header for af_packet

[ Upstream commit 0848f6428ba3a2e42db124d41ac6f548655735bf ]

When ip_frag_queue() computes positions, it assumes that the passed
sk_buff does not contain L2 headers.

However, when PACKET_FANOUT_FLAG_DEFRAG is used, IP reassembly
functions can be called on outgoing packets that contain L2 headers.

Also, IPv4 checksum is not corrected after reassembly.

Fixes: 7736d33f4262 ("packet: Add pre-defragmentation support for ipv4 fanouts.")
Signed-off-by: Edward Hyunkoo Jee <edjee@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Jerry Chu <hkchu@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bonding: fix destruction of bond with devices different from arphrd_ether

[ Upstream commit 06f6d1094aa0992432b1e2a0920b0ee86ccd83bf ]

When the bonding is being unloaded and the netdevice notifier is
unregistered it executes NETDEV_UNREGISTER for each device which should
remove the bond's proc entry but if the device enslaved is not of
ARPHRD_ETHER type and is in front of the bonding, it may execute
bond_release_and_destroy() first which would release the last slave and
destroy the bond device leaving the proc entry and thus we will get the
following error (with dynamic debug on for bond_netdev_event to see the
events order):
[  908.963051] eql: event: 9
[  908.963052] eql: IFF_SLAVE
[  908.963054] eql: event: 2
[  908.963056] eql: IFF_SLAVE
[  908.963058] eql: event: 6
[  908.963059] eql: IFF_SLAVE
[  908.963110] bond0: Releasing active interface eql
[  908.976168] bond0: Destroying bond bond0
[  908.976266] bond0 (unregistering): Released all slaves
[  908.984097] ------------[ cut here ]------------
[  908.984107] WARNING: CPU: 0 PID: 1787 at fs/proc/generic.c:575
remove_proc_entry+0x112/0x160()
[  908.984110] remove_proc_entry: removing non-empty directory
'net/bonding', leaking at least 'bond0'
[  908.984111] Modules linked in: bonding(-) eql(O) 9p nfsd auth_rpcgss
oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul
crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev qxl drm_kms_helper
snd_hda_codec_generic aesni_intel ttm aes_x86_64 glue_helper pcspkr lrw
gf128mul ablk_helper cryptd snd_hda_intel virtio_console snd_hda_codec
psmouse serio_raw snd_hwdep snd_hda_core 9pnet_virtio 9pnet evdev joydev
drm virtio_balloon snd_pcm snd_timer snd soundcore i2c_piix4 i2c_core
pvpanic acpi_cpufreq parport_pc parport processor thermal_sys button
autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sr_mod cdrom
ata_generic virtio_blk virtio_net floppy ata_piix e1000 libata ehci_pci
virtio_pci scsi_mod uhci_hcd ehci_hcd virtio_ring virtio usbcore
usb_common [last unloaded: bonding]

[  908.984168] CPU: 0 PID: 1787 Comm: rmmod Tainted: G        W  O
4.2.0-rc2+ #8
[  908.984170] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  908.984172]  0000000000000000 ffffffff81732d41 ffffffff81525b34
ffff8800358dfda8
[  908.984175]  ffffffff8106c521 ffff88003595af78 ffff88003595af40
ffff88003e3a4280
[  908.984178]  ffffffffa058d040 0000000000000000 ffffffff8106c59a
ffffffff8172ebd0
[  908.984181] Call Trace:
[  908.984188]  [<ffffffff81525b34>] ? dump_stack+0x40/0x50
[  908.984193]  [<ffffffff8106c521>] ? warn_slowpath_common+0x81/0xb0
[  908.984196]  [<ffffffff8106c59a>] ? warn_slowpath_fmt+0x4a/0x50
[  908.984199]  [<ffffffff81218352>] ? remove_proc_entry+0x112/0x160
[  908.984205]  [<ffffffffa05850e6>] ? bond_destroy_proc_dir+0x26/0x30
[bonding]
[  908.984208]  [<ffffffffa057540e>] ? bond_net_exit+0x8e/0xa0 [bonding]
[  908.984217]  [<ffffffff8142f407>] ? ops_exit_list.isra.4+0x37/0x70
[  908.984225]  [<ffffffff8142f52d>] ?
unregister_pernet_operations+0x8d/0xd0
[  908.984228]  [<ffffffff8142f58d>] ?
unregister_pernet_subsys+0x1d/0x30
[  908.984232]  [<ffffffffa0585269>] ? bonding_exit+0x23/0xdba [bonding]
[  908.984236]  [<ffffffff810e28ba>] ? SyS_delete_module+0x18a/0x250
[  908.984241]  [<ffffffff81086f99>] ? task_work_run+0x89/0xc0
[  908.984244]  [<ffffffff8152b732>] ?
entry_SYSCALL_64_fastpath+0x16/0x75
[  908.984247] ---[ end trace 7c006ed4abbef24b ]---

Thus remove the proc entry manually if bond_release_and_destroy() is
used. Because of the checks in bond_remove_proc_entry() it's not a
problem for a bond device to change namespaces (the bug fixed by the
Fixes commit) but since commit
f9399814927ad ("bonding: Don't allow bond devices to change network
namespaces.") that can't happen anyway.

Reported-by: Carol Soto <clsoto@linux.vnet.ibm.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Fixes: a64d49c3dd50 ("bonding: Manage /proc/net/bonding/ entries from
                      the netdev events")
Tested-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: lock socket in ip6_datagram_connect()

[ Upstream commit 03645a11a570d52e70631838cb786eb4253eb463 ]

ip6_datagram_connect() is doing a lot of socket changes without
socket being locked.

This looks wrong, at least for udp_lib_rehash() which could corrupt
lists because of concurrent udp_sk(sk)->udp_portaddr_hash accesses.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]

Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
first merged in kernel release 3.10, caused the following regression
in the Gigaset M101 driver:

Before that commit, when closing the N_TTY line discipline in
preparation to switching to N_GIGASET_M101, receive_room would be
reset to a non-zero value by the call to n_tty_flush_buffer() in
n_tty's close method. With the removal of that call, receive_room
might be left at zero, blocking data reception on the serial line.

The present patch fixes that regression by setting receive_room
to an appropriate value in the ldisc open method.

Fixes: 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc")
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bridge: mdb: fix double add notification

[ Upstream commit 5ebc784625ea68a9570d1f70557e7932988cd1b4 ]

Since the mdb add/del code was introduced there have been 2 br_mdb_notify
calls when doing br_mdb_add() resulting in 2 notifications on each add.

Example:
 Command: bridge mdb add dev br0 port eth1 grp 239.0.0.1 permanent
 Before patch:
 root@debian:~# bridge monitor all
 [MDB]dev br0 port eth1 grp 239.0.0.1 permanent
 [MDB]dev br0 port eth1 grp 239.0.0.1 permanent

 After patch:
 root@debian:~# bridge monitor all
 [MDB]dev br0 port eth1 grp 239.0.0.1 permanent

Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Fixes: cfd567543590 ("bridge: add support of adding and deleting mdb entries")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>