The changes introduced in commit 4b1a25f0 ("fix build when
CONFIG_UIDGID_STRICT_TYPE_CHECKS is on") got the UID check the wrong way
around, leading to "Permission denied" when a regular user attempts to
retrieve his quota (lfs quota -u ...) but allowing him to retrieve other
users quota.

Full details at: https://jira.hpdd.intel.com/browse/LU-4530

Cc: Peng Tao <tao.peng@emc.com>
Cc: <stable@vger.kernel.org> # 3.12.x
Cc: <stable@vger.kernel.org> # 3.13.x
Signed-off-by: Cédric Dufour <cedric.dufour@idiap.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a race condition

Assume we have *one* sync_fence object, with *one* sync_pt
which belongs to *one* sync_timeline, given this condition,
sync_timeline->kref will have two counts, one for sync_timeline
(implicit) and another for sync_pt.

Assume following is the situation on CPU

Theead-1 : (Thread which calls sync_timeline_destroy())
  -> (some function calls)
   -> sync_timeline_destory()
    -> sync_timeline_signal() (CPU is inside this
function after putting reference to sync_timeline)

At this time Thread-2 comes and does following

Thread-2 : (fclose on fence fd)
> sync_fence_release() -> because of fclose() on fence object
 -> sync_fence_free()
  -> sync_pt_free()
   -> kref_put(&pt->parent->kref, sync_timeline_free);
    -> sync_timeline_free() (CPU is inside this because
this time kref will be zero after _put)

Thread-2 will free sync_timeline object before Thread-1
has finished its work inside sync_timeline_signal.

With this change we signals all sync_pt before putting
reference to sync_timeline object.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
[jstultz: minor commit subject tweak]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The last value written to a analog output channel is cached in the
private data of this driver for readback.

Currently, the wrong value is cached in the (*insn_write) functions.
The current code stores the data[n] value for readback afer the loop
has written all the values. At this time 'n' points past the end of
the data array.

Fix the functions by using a local variable to hold the data being
written to the analog output channel. This variable is then used
after the loop is complete to store the readback value. The current
value is retrieved before the loop in case no values are actually
written..
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We should cap the SSID length at NDIS_802_11_LENGTH_SSID (32) characters
to avoid memory corruption.  If the SSID is too long then I have opted
to ignore it instead of truncating it.

We don't need to clear bssid->Ssid.Ssid[0] because this struct is
allocated with rtw_zmalloc()
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Error handling code in gdm_usb_probe() misses to deallocate
tx_ and rx_structs and to do usb_put_dev().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit b73db547.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: Rashika Kheria <rashika.kheria@gmail.com>
Cc: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If net_dev is NULL memcpy() will Oops.
Signed-off-by: Salym Senyonga <salymsash@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When attach fails due to unsupported and/or invalid bus speed, the message
vhci_hcd prints out doesn't include any useful information as to what caused
the failure. Change the message to be informative and use usb_speed_string()
to get the right speed string from usb common.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linus Torvalds writes:

It causes an interesting warning for me:

drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function
‘rtl8821ae_dm_clear_txpower_tracking_state’:
drivers/staging/rtl8821ae/rtl8821ae/dm.c:487:31: warning: iteration 2u
invokes undefined behavior [-Waggressive-loop-optimizations]
   rtldm->bb_swing_idx_ofdm[p] = rtldm->default_ofdm_index;
                               ^
drivers/staging/rtl8821ae/rtl8821ae/dm.c:485:2: note: containing loop
  for (p = RF90_PATH_A; p < MAX_RF_PATH; ++p) {
  ^

and gcc is entirely correct: that loop iterates from 0 to 3, and does this:

                rtldm->bb_swing_idx_ofdm[p] = rtldm->default_ofdm_index;

but the bb_swing_idx_ofdm[] array only has two members. So the last
two iterations will overwrite bb_swing_idx_ofdm_current and the first
entry in bb_swing_idx_ofdm_base[].

Now, the bug does seem to be benign: bb_swing_idx_ofdm_current isn't
actually ever *used* as far as I can tell, and the first entry of
bb_swing_idx_ofdm_base[] will have been written with that same
"rtldm->default_ofdm_index" value.

But gcc is absolutely correct, and that driver needs fixing.

I've pulled it and will let it be because it doesn't seem to be an
issue in practice, but please fix it. The obvious fix would seem to
change the size of "2" to be "MAX_RF_PATH", but I'll abstain from
doing those kinds of changes in the merge when it doesn't seem to
affect the build or functionality).
Reported-By: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Surendra Patil <surendra.tux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Extract clocking parameters from the device tree, and remove now dead
code and types.
Signed-off-by: David Daney <david.daney@cavium.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The kernel to userspace communication routines (KUC) allocate
and limit the maximum cs_buf size to CR_MAXSIZE.  However this
fails to account for the fact that the buffer is assumed to begin
with a struct kuc_hdr.  To allocate and account for that space,
we introduce a new define, KUC_CHANGELOG_MSG_MAXSIZE.
Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Reviewed-on: http://review.whamcloud.com/7406
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3587Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: jacques-Charles Lafoucriere <jacques-charles.lafoucriere@cea.fr>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

CR_MAXSIZE needs to account for an llog_changelog_rec that actually
contains a changelog_ext_rec structure rather than a changelog_rec.
With out doing so, a file size approaching the Linux kernel NAME_MAX
length that is renamed to a size also close to, or at, NAME_MAX will
exceed CR_MAXSIZE and trip an assertion.
Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Reviewed-on: http://review.whamcloud.com/6993
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3587Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Call to ksocknal_launch_packet might schedule a callback that
might free the just sent message, and so subsequent access to it
via lntmsg->msg_vmflush goes to freed memory.

Instead we'll just remember if we are in the vmflush thread and
only restore if we happened to set mempressure flag.
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Reviewed-on: http://review.whamcloud.com/8667
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4360Reviewed-by: Liang Zhen <liang.zhen@intel.com>
Reviewed-by: Amir Shehata <amir.shehata@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Recent commit 175f5475
introduced this compile warning (because vaddr is unsigned long),
so add a cast:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function ‘kiblnd_kvaddr_to_page’:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:532:2: warning: passing argument 1 of ‘is_vmalloc_addr’ makes pointer from integer without a cast [enabled by default]
  if (is_vmalloc_addr(vaddr)) {
  ^
In file included from drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h:43:0,
                 from drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:41:
include/linux/mm.h:336:59: note: expected ‘const void *’ but argument is of type ‘long unsigned int’
 static inline int is_vmalloc_addr(const void *x)
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
CC: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an
atomic allocation, the code must test __GFP_WAIT flag presence.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add #include <linux/device.h> to fix the following warning seen
with gcc 4.7.3:

In file included from drivers/staging/android/ion/ion_heap.c:26:0:
drivers/staging/android/ion/ion_priv.h:358:21: warning: ‘struct device’ declared inside parameter list [enabled by default]
drivers/staging/android/ion/ion_priv.h:358:21: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The compat ioctl for ION_IOC_FREE currently passes allocation data
instead of the free data. Correct this.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
[jstultz: Folded in a small build fix]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a few bugs in ion_system_heap:

Initialize the list node in the info block.

Don't store size_remaining in a signed long, allocating >2GB
could overflow, resulting in a call to sg_alloc_table with
nents=0 which panics.  alloc_largest_available will never
return a block larger than size_remanining, so it can never
go negative.

Limit a single allocation to half of all memory.  Prevents a
large allocation from taking down the whole system.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
[jstultz: Minor commit subject tweak]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Avoid holding ashmem_mutex across code that can page fault.  Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex.  The reversed
order of locking between the two can deadlock.

The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls.  Move the code that accesses userspace pages
outside the ashmem_mutex.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
[jstultz: minor commit message tweaks]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
[jstultz: minor commit subject tweak]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add stubs for kernels without CONFIG_SW_SYNC

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
[jstultz: resolved minor conflict, tweaked commit message]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The ION_DUMMY option is bool, and hence this code is either
present or absent.  It will never be modular, so using
module_init as an alias for __initcall is rather misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future.  If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.

Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups.  As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.

Cc: Colin Cross <ccross@android.com>
Cc: Jesse Barker <jesse.barker@arm.com>
Cc: Android Kernel Team <kernel-team@android.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

use ARRAY_SIZE to count number of heaps in static array
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Need add "linux/io.h" to pass compiling under metag architecture with
allmodconfig (which use the default 'virt_to_phys'), the related error:

    CC      drivers/staging/android/ion/ion_dummy_driver.o
  drivers/staging/android/ion/ion_dummy_driver.c: In function 'ion_dummy_init':
  drivers/staging/android/ion/ion_dummy_driver.c:81: error: implicit declaration of function 'virt_to_phys'
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'iio-fixes-for-3.14a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

Jonathan writes:

First set of IIO fixes for the 3.14 cycle.

Included is the patch previously set as the fourth round for 3.13 which was
to late to be appropriate.

* Another endian fix (ad799x adc) due to missuse of the IIO_ST macro (which
  is going away very shortly)
* A reversed error check in ad5933 which will make the probe fail.
* A buffer overflow in the example code in the documentation.
* ad799x was freeing an irq that might or might not have been requested.
* tsl2563 was checking the wrong element of chan_spec for modifiers. Thus some
  sysfs reads would give the wrong values.
* A missing dependency on HAS_IOMEM in spear_adc and lpc32xx was causing some
  test build failures (on s390 and perhaps elsewhere).

I also have a few fixes queued up for things that went in during the 3.14
merge window which will follow as a separate pull request (to avoid rebasing
my tree).

Instead of redefining the enums, use the standard ones already
available to avoid the following build errors:

drivers/staging/imx-drm/imx-hdmi.c:56:13: error: nested redefinition of ‘enum hdmi_colorimetry’
drivers/staging/imx-drm/imx-hdmi.c:56:13: error: redeclaration of ‘enum hdmi_colorimetry’
In file included from include/drm/drm_crtc.h:33:0,
                 from include/drm/drmP.h:710,
                 from drivers/staging/imx-drm/imx-hdmi.c:24:
include/linux/hdmi.h:48:6: note: originally defined here
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There's no reason for this to be a separate function; merge the
two together.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We have the drm_device available, so rather than storing it and then
using the stored version, us the one we already have available to us.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There are a couple of ways to get at the drm_device for the vblank
operations.  One of them is via the private imxdrm structure, the
other is via the DRM crtc structure, which also stores a pointer.
Use the DRM method instead of our own method.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull parisc updates from Helge Deller:
 "The three major changes in this patchset is a implementation for
  flexible userspace memory maps, cache-flushing fixes (again), and a
  long-discussed ABI change to make EWOULDBLOCK the same value as
  EAGAIN.

  parisc has been the only platform where we had EWOULDBLOCK != EAGAIN
  to keep HP-UX compatibility.  Since we will probably never implement
  full HP-UX support, we prefer to drop this compatibility to make it
  easier for us with Linux userspace programs which mostly never checked
  for both values.  We don't expect major fall-outs because of this
  change, and if we face some, we will simply rebuild the necessary
  applications in the debian archives"

* 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: add flexible mmap memory layout support
  parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
  parisc: convert uapi/asm/stat.h to use native types only
  parisc: wire up sched_setattr and sched_getattr
  parisc: fix cache-flushing
  parisc/sti_console: prefer Linux fonts over built-in ROM fonts

HPFS needs to load 4 consecutive 512-byte sectors when accessing the
directory nodes or bitmaps.  We can't switch to 2048-byte block size
because files are allocated in the units of 512-byte sectors.

Previously, the driver would allocate a 2048-byte area using kmalloc,
copy the data from four buffers to this area and eventually copy them
back if they were modified.

In the current implementation of the buffer cache, buffers are allocated
in the pagecache.  That means that 4 consecutive 512-byte buffers are
stored in consecutive areas in the kernel address space.  So, we don't
need to allocate extra memory and copy the content of the buffers there.

This patch optimizes the code to avoid copying the buffers.  It checks
if the four buffers are stored in contiguous memory - if they are not,
it falls back to allocating a 2048-byte area and copying data there.
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Previously, hpfs scanned all bitmaps each time the user asked for free
space using statfs.  This patch changes it so that hpfs scans the
bitmaps only once, remembes the free space and on next invocation of
statfs it returns the value instantly.

New versions of wine are hammering on the statfs syscall very heavily,
making some games unplayable when they're stored on hpfs, with load
times in minutes.

This should be backported to the stable kernels because it fixes
user-visible problem (excessive level load times in wine).
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Add support for the flexible mmap memory layout (as described in
http://lwn.net/Articles/91829). This is especially very interesting on
parisc since we currently only support 32bit userspace (even with a
64bit Linux kernel).
Signed-off-by: Helge Deller <deller@gmx.de>

On Linux, only parisc uses a different value for EWOULDBLOCK which
causes a lot of troubles for applications not checking for both values.
Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
all other architectures.
Signed-off-by: Guy Martin <gmsoft@tuxicoman.be>
Signed-off-by: Helge Deller <deller@gmx.de>

The stat.h header file is exported to userspace. Some userspace
applications failed to compile due to missing/unknown types, so we
better convert it to use native types only (like it's done on other
architectures too).
Signed-off-by: Helge Deller <deller@gmx.de>

Signed-off-by: Helge Deller <deller@gmx.de>

This commit:
f8dae006: parisc: Ensure full cache coherency for kmap/kunmap
caused negative caching side-effects, e.g. hanging processes with expect and
too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems.

This patch now partly reverts it and has been in production use on our debian buildd
makeservers since a week without any major problems.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # v3.9+
Signed-off-by: Helge Deller <deller@gmx.de>

The built-in ROM fonts lack many necessary ASCII characters, which is
why it makes sens to prefer the Linux fonts instead if they are
available.  This makes consoles on STI graphics cards which are not
supported by the stifb driver (e.g. Visualize FXe) looks much nicer.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # v3.13