rbd: access snapshot context and mapping size safely

These fields may both change while the image is mapped if a snapshot
is created or deleted or the image is resized.  They are guarded by
rbd_dev->header_rwsem, so hold that while reading them, and store a
local copy to refer to outside of the critical section. The local copy
will stay consistent since the snapshot context is reference counted,
and the mapping size is just a u64. This prevents torn loads from
giving us inconsistent values.

Move reading header.snapc into the caller of rbd_img_request_create()
so that we only need to take the semaphore once. The read-only caller,
rbd_parent_request_create() can just pass NULL for snapc, since the
snapshot context is only relevant for writes.

Signed-off-by: Josh Durgin <josh.durgin@inktank.com>

rbd: do not return -ERANGE on auth failures

Trying to map an image out of a pool for which we don't have an 'x'
permission bit fails with -ERANGE from ceph_extract_encoded_string()
due to an unsigned vs signed bug.  Fix it and get rid of the -EINVAL
sink, thus propagating rbd::get_id cls method errors.  (I've seen
a bunch of unexplained -ERANGE reports, I bet this is it).

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>

libceph: don't try checking queue_work() return value

queue_work() doesn't "fail to queue", it returns false if work was
already on a queue, which can't happen here since we allocate
event_work right before we queue it.  So don't bother at all.

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>

ceph: make sure request isn't in any waiting list when kicking request.

we may corrupt waiting list if a request in the waiting list is kicked.

Signed-off-by: Yan, Zheng <zyan@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>

ceph: protect kick_requests() with mdsc->mutex

Signed-off-by: Yan, Zheng <zyan@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>

libceph: Convert pr_warning to pr_warn

Use the more common pr_warn.

Other miscellanea:

o Coalesce formats
o Realign arguments

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>

ceph: trim unused inodes before reconnecting to recovering MDS

So the recovering MDS does not need to fetch these ununsed inodes during
cache rejoin. This may reduce MDS recovery time.

Signed-off-by: Yan, Zheng <zyan@redhat.com>

libceph: fix a use after free issue in osdmap_set_max_osd

If the state variable is krealloced successfully, map->osd_state will be
freed, once following two reallocation failed, and exit the function
without resetting map->osd_state, map->osd_state become a wild pointer.

fix it by resetting them after krealloc successfully.

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>

libceph: select CRYPTO_CBC in addition to CRYPTO_AES

We want "cbc(aes)" algorithm, so select CRYPTO_CBC too, not just
CRYPTO_AES.  Otherwise on !CRYPTO_CBC kernels we fail rbd map/mount
with

    libceph: error -2 building auth method x request

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>

libceph: resend lingering requests with a new tid

Both not yet registered (r_linger && list_empty(&r_linger_item)) and
registered linger requests should use the new tid on resend to avoid
the dup op detection logic on the OSDs, yet we were doing this only for
"registered" case.  Factor out and simplify the "registered" logic and
use the new helper for "not registered" case as well.

Fixes: http://tracker.ceph.com/issues/8806

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>

libceph: abstract out ceph_osd_request enqueue logic

Introduce __enqueue_request() and switch to it.

Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>

Linux 3.17

Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "This is a set of two small fixes, both to code which went in during
  the merge window: cxgb4i has a scheduling in atomic bug in its new
  ipv6 code and uas fails to work properly with the new scsi-mq code"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] uas: disable use of blk-mq I/O path
  [SCSI] cxgb4i: avoid holding mutex in interrupt context

Merge tag 'tiny/kconfig-for-3.17' of https://git./linux/kernel/git/josh/linux

Pull kconfig fixes for tiny setups from Josh Triplett:
 "Two Kconfig bugfixes for 3.17 related to tinification.  These fixes
  make the Kconfig "General Setup" menu much more usable"

* tag 'tiny/kconfig-for-3.17' of https://git.kernel.org/pub/scm/linux/kernel/git/josh/linux:
  init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu
  init/Kconfig: Hide printk log config if CONFIG_PRINTK=n

init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu

commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow
architectures to skip futex_atomic_cmpxchg_inatomic() test") added the
HAVE_FUTEX_CMPXCHG symbol right below FUTEX.  This placed it right in
the middle of the options for the EXPERT menu.  However,
HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops
placing items in the EXPERT menu, and displays the remaining several
EXPERT items (starting with EPOLL) directly in the General Setup menu.

Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make
HAVE_FUTEX_CMPXCHG itself depend on FUTEX.  With this change, the
subsequent items display as part of the EXPERT menu again; the EMBEDDED
menu now appears as the next top-level item in the General Setup menu,
which makes General Setup much shorter and more usable.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Cc: stable <stable@vger.kernel.org>

init/Kconfig: Hide printk log config if CONFIG_PRINTK=n

The buffers sized by CONFIG_LOG_BUF_SHIFT and
CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't
ask about their size at all.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Cc: stable <stable@vger.kernel.org>

Merge branch 'i2c/for-current' of git://git./linux/kernel/git/wsa/linux

Pull i2c fixes from Wolfram Sang:
 "Two i2c driver bugfixes"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: qup: Fix order of runtime pm initialization
  i2c: rk3x: fix 0 length write transfers

Merge tag 'trace-fixes-v3.17-rc7' of git://git./linux/kernel/git/rostedt/linux-trace

Pull trace ring buffer iterator fix from Steven Rostedt:
 "While testing some new changes for 3.18, I kept hitting a bug every so
  often in the ring buffer.  At first I thought it had to do with some
  of the changes I was working on, but then testing something else I
  realized that the bug was in 3.17 itself.  I ran several bisects as
  the bug was not very reproducible, and finally came up with the commit
  that I could reproduce easily within a few minutes, and without the
  change I could run the tests over an hour without issue.  The change
  fit the bug and I figured out a fix.  That bad commit was:

    Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page"

  This commit fixed a bug, but in the process created another one.  It
  used the wrong value as the cached value that is used to see if things
  changed while an iterator was in use.  This made it look like a change
  always happened, and could cause the iterator to go into an infinite
  loop"

* tag 'trace-fixes-v3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ring-buffer: Fix infinite spin in reading buffer

Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6

Pull cifs/smb3 fixes from Steve French:
 "Fix for CIFS/SMB3 oops on reconnect during readpages (3.17 regression)
  and for incorrectly closing file handle in symlink error cases"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  CIFS: Fix readpages retrying on reconnects
  Fix problem recognizing symlinks

Merge tag 'md/3.17-final-fix' of git://neil.brown.name/md

Pull raid5 discard fix from Neil Brown:
 "One fix for raid5 discard issue"

* tag 'md/3.17-final-fix' of git://neil.brown.name/md:
  md/raid5: disable 'DISCARD' by default due to safety concerns.

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "Nothing too major or scary.

  One i915 regression fix, nouveau has a tmds regression fix, along with
  a regression fix for the runtime pm code for optimus laptops not
  restoring the display hw correctly"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/nouveau: make sure display hardware is reinitialised on runtime resume
  drm/nouveau: punt fbcon resume out to a workqueue
  drm/nouveau: fix regression on original nv50 board
  drm/nv50/disp: fix dpms regression on certain boards
  drm/i915: Flush the PTEs after updating them before suspend

[SCSI] uas: disable use of blk-mq I/O path

The uas driver uses the block layer tag for USB3 stream IDs.  With
blk-mq we can get larger tag numbers that the queue depth, which breaks
this assumption.  A fix is under way for 3.18, but sits on top of
large changes so can't easily be backported.   Set the disable_blk_mq
path so that a uas device can't easily crash the system when using
blk-mq for SCSI.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Merge tag 'pm+acpi-3.17-final' of git://git./linux/kernel/git/rafael/linux-pm

Pull ACPI and power management fixes from Rafael Wysocki:
 "These are three regression fixes (cpufreq core, pcc-cpufreq, i915 /
  ACPI) and one trivial fix for a callback return value mismatch in the
  cpufreq integrator driver.

  Specifics:

   - A recent cpufreq core fix went too far and introduced a regression
     in the system suspend code path.  Fix from Viresh Kumar.

   - An ACPI-related commit in the i915 driver that fixed backlight
     problems for some Thinkpads inadvertently broke a Dell machine (in
     3.16).  Fix from Aaron Lu.

   - The pcc-cpufreq driver was broken during the 3.15 cycle by a commit
     that put wait_event() under a spinlock by mistake.  Fix that
     (Rafael J Wysocki).

   - The return value type of integrator_cpufreq_remove() is void, but
     should be int.  Fix from Arnd Bergmann"

* tag 'pm+acpi-3.17-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpufreq: update 'cpufreq_suspended' after stopping governors
  ACPI / i915: Update the condition to ignore firmware backlight change request
  cpufreq: integrator: fix integrator_cpufreq_remove return type
  cpufreq: pcc-cpufreq: Fix wait_event() under spinlock

Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes

final regression fix for 3.17.

* tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Flush the PTEs after updating them before suspend

i2c: qup: Fix order of runtime pm initialization

The runtime pm calls need to be done before populating the children via the
i2c_add_adapter call.  If this is not done, a child can run into issues trying
to do i2c read/writes due to the pm_runtime_sync failing.

Signed-off-by: Andy Gross <agross@codeaurora.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2c: rk3x: fix 0 length write transfers

i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.

Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Tested-by: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

Merge branches 'pm-cpufreq' and 'acpi-video'

* pm-cpufreq:
  cpufreq: update 'cpufreq_suspended' after stopping governors
  cpufreq: integrator: fix integrator_cpufreq_remove return type
  cpufreq: pcc-cpufreq: Fix wait_event() under spinlock

* acpi-video:
  ACPI / i915: Update the condition to ignore firmware backlight change request

Merge branch 'akpm' (fixes from Andrew Morton)

Merge fixes from Andrew Morton:
 "5 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm: page_alloc: fix zone allocation fairness on UP
  perf: fix perf bug in fork()
  MAINTAINERS: change git URL for mpc5xxx tree
  mm: memcontrol: do not iterate uninitialized memcgs
  ocfs2/dlm: should put mle when goto kill in dlm_assert_master_handler

mm: page_alloc: fix zone allocation fairness on UP

The zone allocation batches can easily underflow due to higher-order
allocations or spills to remote nodes.  On SMP that's fine, because
underflows are expected from concurrency and dealt with by returning 0.
But on UP, zone_page_state will just return a wrapped unsigned long,
which will get past the <= 0 check and then consider the zone eligible
until its watermarks are hit.

Commit 3a025760fc15 ("mm: page_alloc: spill to remote nodes before
waking kswapd") already made the counter-resetting use
atomic_long_read() to accomodate underflows from remote spills, but it
didn't go all the way with it.

Make it clear that these batches are expected to go negative regardless
of concurrency, and use atomic_long_read() everywhere.

Fixes: 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

perf: fix perf bug in fork()

Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by
calling perf_event_free_task() when failing sched_fork() we will not yet
have done the memset() on ->perf_event_ctxp[] and will therefore try and
'free' the inherited contexts, which are still in use by the parent
process.  This is bad..

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

MAINTAINERS: change git URL for mpc5xxx tree

The repository for mpc5xxx has been moved, update git URL to new
location.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: memcontrol: do not iterate uninitialized memcgs

The cgroup iterators yield css objects that have not yet gone through
css_online(), but they are not complete memcgs at this point and so the
memcg iterators should not return them.  Commit d8ad30559715 ("mm/memcg:
iteration skip memcgs not yet fully initialized") set out to implement
exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does
not meet the ordering requirements for memcg, and so the iterator may
skip over initialized groups, or return partially initialized memcgs.

The cgroup core can not reasonably provide a clear answer on whether the
object around the css has been fully initialized, as that depends on
controller-specific locking and lifetime rules.  Thus, introduce a
memcg-specific flag that is set after the memcg has been initialized in
css_online(), and read before mem_cgroup_iter() callers access the memcg
members.

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ocfs2/dlm: should put mle when goto kill in dlm_assert_master_handler

In dlm_assert_master_handler, the mle is get in dlm_find_mle, should be
put when goto kill, otherwise, this mle will never be released.

Signed-off-by: Alex Chen <alex.chen@huawei.com>
Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
Reviewed-by: joyce.xue <xuejiufei@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'media/v3.17-rc8' of git://git./linux/kernel/git/mchehab/linux-media

Pull media fix from Mauro Carvalho Chehab:
 "One last time regression fix at em28xx.  The removal of .reset_resume
  broke suspend/resume on this driver for some devices.

  There are more fixes to be done for em28xx suspend/resume to be better
  handled, but I'm opting to let them to stay for a while at the media
  devel tree, in order to get more tests.  So, for now, let's just
  revert this patch"

* tag 'media/v3.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  Revert "[media] media: em28xx - remove reset_resume interface"

ring-buffer: Fix infinite spin in reading buffer

Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page"
fixed one bug but in the process caused another one. The reset is to
update the header page, but that fix also changed the way the cached
reads were updated. The cache reads are used to test if an iterator
needs to be updated or not.

A ring buffer iterator, when created, disables writes to the ring buffer
but does not stop other readers or consuming reads from happening.
Although all readers are synchronized via a lock, they are only
synchronized when in the ring buffer functions. Those functions may
be called by any number of readers. The iterator continues down when
its not interrupted by a consuming reader. If a consuming read
occurs, the iterator starts from the beginning of the buffer.

The way the iterator sees that a consuming read has happened since
its last read is by checking the reader "cache". The cache holds the
last counts of the read and the reader page itself.

Commit 651e22f2701b changed what was saved by the cache_read when
the rb_iter_reset() occurred, making the iterator never match the cache.
Then if the iterator calls rb_iter_reset(), it will go into an
infinite loop by checking if the cache doesn't match, doing the reset
and retrying, just to see that the cache still doesn't match! Which
should never happen as the reset is suppose to set the cache to the
current value and there's locks that keep a consuming reader from
having access to the data.

Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page"
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Merge branch 'parisc-3.17-8' of git://git./linux/kernel/git/deller/parisc-linux

Pull parisc fix from Helge Deller:
 "One late but trivial patch to fix the serial console on parisc
  machines which got broken during the 3.17 release cycle"

* 'parisc-3.17-8' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Fix serial console for machines with serial port on superio chip

CIFS: Fix readpages retrying on reconnects

If we got a reconnect error from async readv we re-add pages back
to page_list and continue loop. That is wrong because these pages
have been already added to the pagecache but page_list has pages that
have not been added to the pagecache yet. This ends up with a general
protection fault in put_pages after readpages. Fix it by not retrying
the read of these pages and falling back to readpage instead.

Fixes debian bug 762306

Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Tested-by: Arthur Marsh <arthur.marsh@internode.on.net>

Fix problem recognizing symlinks

Changeset eb85d94bd introduced a problem where if a cifs open
fails during query info of a file we
will still try to close the file (happens with certain types
of reparse points) even though the file handle is not valid.

In addition for SMB2/SMB3 we were not mapping the return code returned
by Windows when trying to open a file (like a Windows NFS symlink)
which is a reparse point.

Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Pavel Shilovsky <pshilovsky@samba.org>
CC: stable <stable@vger.kernel.org> #v3.13+

Merge branch 'numa-migration-fixes' (fixes from Mel Gorman)

Merge NUMA balancing related fixlets from Mel Gorman:
 "There were a few minor changes so am resending just the two patches
  that are mostly likely to affect the bug Dave and Sasha saw and marked
  them for stable.

  I'm less confident it will address Sasha's problem because while I
  have not kept up to date, I believe he's also seeing memory corruption
  issues in next from an unknown source.  Still, it would be nice to see
  how they affect trinity testing.

  I'll send the MPOL_MF_LAZY patch separately because it's not urgent"

* emailed patches from Mel Gorman <mgorman@suse.de>:
  mm: numa: Do not mark PTEs pte_numa when splitting huge pages
  mm: migrate: Close race between migration completion and mprotect

mm: numa: Do not mark PTEs pte_numa when splitting huge pages

This patch reverts 1ba6e0b50b ("mm: numa: split_huge_page: transfer the
NUMA type from the pmd to the pte"). If a huge page is being split due
a protection change and the tail will be in a PROT_NONE vma then NUMA
hinting PTEs are temporarily created in the protected VMA.

 VM_RW|VM_PROTNONE
|-----------------|
      ^
      split here

In the specific case above, it should get fixed up by change_pte_range()
but there is a window of opportunity for weirdness to happen. Similarly,
if a huge page is shrunk and split during a protection update but before
pmd_numa is cleared then a pte_numa can be left behind.

Instead of adding complexity trying to deal with the case, this patch
will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults
will not be triggered which is marginal in comparison to the complexity
in dealing with the corner cases during THP split.

Cc: stable@vger.kernel.org
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: migrate: Close race between migration completion and mprotect

A migration entry is marked as write if pte_write was true at the time the
entry was created. The VMA protections are not double checked when migration
entries are being removed as mprotect marks write-migration-entries as
read. It means that potentially we take a spurious fault to mark PTEs write
again but it's straight-forward. However, there is a race between write
migrations being marked read and migrations finishing. This potentially
allows a PTE to be write that should have been read. Close this race by
double checking the VMA permissions using maybe_mkwrite when migration
completes.

[torvalds@linux-foundation.org: use maybe_mkwrite]
Cc: stable@vger.kernel.org
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'sound-3.17' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Just a few pending bits of random fixes in ASoC.  Nothing exciting,
  but would be nice to be merged in 3.17, as most of them are also for
  stable kernels"

* tag 'sound-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: ssm2602: do not hardcode type to SSM2602
  ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error.
  MAINTAINERS: add atmel audio alsa driver maintainer entry
  ASoC: rt286: Fix sync function
  ASoC: rt286: Correct default value
  ASoC: soc-compress: fix double unlock of fe card mutex
  ASoC: fsl_ssi: fix kernel panic in probe function

Merge branch 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

A few regression fixes, the runpm ones dating back to 3.15.  Also a fairly severe TMDS regression that effected a lot of GF8/9/GT2xx users.

* 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau: make sure display hardware is reinitialised on runtime resume
  drm/nouveau: punt fbcon resume out to a workqueue
  drm/nouveau: fix regression on original nv50 board
  drm/nv50/disp: fix dpms regression on certain boards

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:

 1) Don't halt the firmware in r8152 driver, from Hayes Wang.

 2) Handle full sized 802.1ad frames in bnx2 and tg3 drivers properly,
    from Vlad Yasevich.

 3) Don't sleep while holding tx_clean_lock in netxen driver, fix from
    Manish Chopra.

 4) Certain kinds of ipv6 routes can end up endlessly failing the route
    validation test, causing it to be re-looked up over and over again.
    This particularly kills input route caching in TCP sockets.  Fix
    from Hannes Frederic Sowa.

 5) netvsc_start_xmit() has a use-after-free access to skb->len, fix
    from K Y Srinivasan.

 6) Fix matching of inverted containers in ematch module, from Ignacy
    Gawędzki.

 7) Aggregation of GRO frames via SKB ->frag_list for linear skbs isn't
    handled properly, regression fix from Eric Dumazet.

 8) Don't test return value of ipv4_neigh_lookup(), which returns an
    error pointer, against NULL.  From WANG Cong.

 9) Fix an old regression where we mistakenly allow a double add of the
    same tunnel.  Fixes from Steffen Klassert.

10) macvtap device delete and open can run in parallel and corrupt lists
    etc., fix from Vlad Yasevich.

11) Fix build error with IPV6=m NETFILTER_XT_TARGET_TPROXY=y, from Pablo
    Neira Ayuso.

12) rhashtable_destroy() triggers lockdep splats, fix also from Pablo.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (32 commits)
  bna: Update Maintainer Email
  r8152: disable power cut for RTL8153
  r8152: remove clearing bp
  bnx2: Correctly receive full sized 802.1ad fragmes
  tg3: Allow for recieve of full-size 8021AD frames
  r8152: fix setting RTL8152_UNPLUG
  netxen: Fix bug in Tx completion path.
  netxen: Fix BUG "sleeping function called from invalid context"
  ipv6: remove rt6i_genid
  hyperv: Fix a bug in netvsc_start_xmit()
  net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected
  ematch: Fix matching of inverted containers.
  gro: fix aggregation for skb using frag_list
  neigh: check error pointer instead of NULL for ipv4_neigh_lookup()
  ip6_gre: Return an error when adding an existing tunnel.
  ip6_vti: Return an error when adding an existing tunnel.
  ip6_tunnel: Return an error when adding an existing tunnel.
  ip6gre: add a rtnl link alias for ip6gretap
  net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode
  r8152: fix the carrier off when autoresuming
  ...

md/raid5: disable 'DISCARD' by default due to safety concerns.

It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint.  Some devices in some cases don't do what it
says on the label.

The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero.  If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks.  If all were zero, this would
be the case.  If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.

As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.

As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.

If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
    raid456.devices_handle_discard_safely=Y

As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7

Cc: Shaohua Li <shli@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Heinz Mauelshagen <heinzm@redhat.com>
Cc: stable@vger.kernel.org (3.7+)
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
Signed-off-by: NeilBrown <neilb@suse.de>

drm/nouveau: make sure display hardware is reinitialised on runtime resume

Linus commit 05c63c2ff23a80b654d6c088ac3ba21628db0173 modified the
runtime suspend/resume paths to skip over display-related tasks to
avoid locking issues on resume.

Unfortunately, this resulted in the display hardware being left in
a partially initialised state, preventing subsequent modesets from
completing.

This commit unifies the (many) suspend/resume paths, bringing back
display (and fbcon) handling in the runtime paths.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: punt fbcon resume out to a workqueue

Preparation for some runtime pm fixes.  Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.

As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.

To solve this, we'll just delay the fbcon resume to a workqueue.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: fix regression on original nv50 board

Xorg (and any non-DRM client really) doesn't have permission to directly
touch VRAM on nv50 and up, which the fence code prior to g84 depends on.

It's less invasive to temporarily grant it premission to do so, as it
previously did, than it is to rework fencenv50 to use the VM.  That
will come later on.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv50/disp: fix dpms regression on certain boards

Reported in fdo#82527 comment #2.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

bna: Update Maintainer Email

Update the maintainer email for BNA driver.

Signed-off-by: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'r8152'

Hayes Wang says:

====================
r8152: patches about firmware

The patches fix the issues when the firmware exists.

For the multiple OS, the firmware may be loaded by the
driver of the other OS. And the Linux driver has influences
on it.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

r8152: disable power cut for RTL8153

The firmware would be clear when the power cut is enabled for
RTL8153.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

r8152: remove clearing bp

The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bnx2: Correctly receive full sized 802.1ad fragmes

This driver, similar to tg3, has a check that will
cause full sized 802.1ad frames to be dropped.  The
frame will be larger then the standard mtu due to the
presense of vlan header that has not been stripped.
The driver should not drop this frame and should process
it just like it does for 802.1q.

CC: Sony Chacko <sony.chacko@qlogic.com>
CC: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tg3: Allow for recieve of full-size 8021AD frames

When receiving a vlan-tagged frame that still contains
a vlan header, the length of the packet will be greater
then MTU+ETH_HLEN since it will account of the extra
vlan header.  TG3 checks this for the case for 802.1Q,
but not for 802.1ad.  As a result, full sized 802.1ad
frames get dropped by the card.

Add a check for 802.1ad protocol when receving full
sized frames.

Suggested-by: Prashant Sreedharan <prashant@broadcom.com>
CC: Prashant Sreedharan <prashant@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'for-3.17' of git://linux-nfs.org/~bfields/linux

Pull nfsd bugfix from Bruce Fields:
 "This fixes a data corruption bug introduced by the v3.16 xdr encoding
  rewrite.  I haven't managed to reproduce it myself yet, but it's
  apparently not hard to hit given the right workload"

* 'for-3.17' of git://linux-nfs.org/~bfields/linux:
  nfsd4: fix corruption of NFSv4 read data

parisc: Fix serial console for machines with serial port on superio chip

Fix the serial console on machines where the serial port is located on
the SuperIO chip.

Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Peter Hurley <peter@hurleysoftware.com>

[SCSI] cxgb4i: avoid holding mutex in interrupt context

cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu
protected list while finding netdev.  This is observed as a scheduling in
atomic oops when running over ipv6.

Fixes: fc8d0590d914 ("libcxgbi: Add ipv6 api to driver")
Fixes: 759a0cc5a3e1 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api")

Signed-off-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: Karen Xie <kxie@chelsio.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Merge tag 'asoc-v3.17-rc7' of git://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fix SSM2602 device identification

Another fix for v3.17, fixing device identification after the split out
of the I2C and SPI code.

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Some further ARM fixes:
   - another build fix for the kprobes test code
   - a fix for no kuser helpers for the set_tls code, which oopsed on
     noMMU hardware
   - a fix for alignment handler with neon opcodes being misinterpreted
   - turning off the hardware access support, which is not implemented
   - a build fix for the v7 coherency exiting code, which can be built
     in non-v7 environments (but still only executed on v7 CPUs)"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset"
  ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS
  ARM: 8177/1: cacheflush: Fix v7_exit_coherency_flush exynos build breakage on ARMv6
  ARM: 8165/1: alignment: don't break misaligned NEON load/store
  ARM: 8164/1: mm: clear SCTLR.HA instead of setting it for LPAE

r8152: fix setting RTL8152_UNPLUG

The flag of RTL8152_UNPLUG should only be set when the device is
unplugged, not each time the rtl8152_disconnect() is called.
Otherwise, the device wouldn't be stopped normally.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'netxen'

Manish Chopra says:

====================
netxen: Bug fixes.

This series fixes some TX specific issues.
* Move spin_lock(tx_clean_lock) in down path to fix
  atomic sleep bug (Reported by Mike Galbraith).
* Fix hang in interface down while running traffic.

Please consider applying this to 'net'.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: Fix bug in Tx completion path.

o Driver is not updating sw_consumer while processing Tx completion
  when interface is going down. Due to this interface down path gets
  stuck forever waiting for NAPI to complete.

Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: Fix BUG "sleeping function called from invalid context"

o __netxen_nic_down() function might sleep while holding spinlock_t(tx_clean_lock).
  Acquire this lock for only releasing TX buffers instead of taking it
  for whole down path.

Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

nfsd4: fix corruption of NFSv4 read data

The calculation of page_ptr here is wrong in the case the read doesn't
start at an offset that is a multiple of a page.

The result is that nfs4svc_encode_compoundres sets rq_next_page to a
value one too small, and then the loop in svc_free_res_pages may
incorrectly fail to clear a page pointer in rq_respages[].

Pages left in rq_respages[] are available for the next rpc request to
use, so xdr data may be written to that page, which may hold data still
waiting to be transmitted to the client or data in the page cache.

The observed result was silent data corruption seen on an NFSv4 client.

We tag this as "fixing" 05638dc73af2 because that commit exposed this
bug, though the incorrect calculation predates it.

Particular thanks to Andrea Arcangeli and David Gilbert for analysis and
testing.

Fixes: 05638dc73af2 "nfsd4: simplify server xdr->next_page use"
Cc: stable@vger.kernel.org
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Tested-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

cpufreq: update 'cpufreq_suspended' after stopping governors

Commit 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
introduced a bug where the governors wouldn't be stopped anymore for
->target{_index}() drivers during suspend. This happens because
'cpufreq_suspended' is updated before stopping the governors during suspend
and due to this __cpufreq_governor() would return early due to this check:

/* Don't start any governor operations if we are entering suspend */
if (cpufreq_suspended)
return 0;

Fixes: 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 8e30444e1530 "cpufreq: fix cpufreq suspend/resume for intel_pstate"
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ipv6: remove rt6i_genid

Eric Dumazet noticed that all no-nonexthop or no-gateway routes which
are already marked DST_HOST (e.g. input routes routes) will always be
invalidated during sk_dst_check. Thus per-socket dst caching absolutely
had no effect and early demuxing had no effect.

Thus this patch removes rt6i_genid: fn_sernum already gets modified during
add operations, so we only must ensure we mutate fn_sernum during ipv6
address remove operations. This is a fairly cost extensive operations,
but address removal should not happen that often. Also our mtu update
functions do the same and we heard no complains so far. xfrm policy
changes also cause a call into fib6_flush_trees. Also plug a hole in
rt6_info (no cacheline changes).

I verified via tracing that this change has effect.

Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: YOSHIFUJI Hideaki <hideaki@yoshifuji.org>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Martin Lau <kafai@fb.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset"

When compiling kprobes-test-arm.c the following error has been observed

/tmp/ccoT403o.s:21439: Error: bad immediate value for offset (4168)

This is caused by the compiler spilling it's literal pool too far away
from the site which is trying to reference it with a PC relative load.
This arises because the compiler is underestimating the size of the
inline assembler code present, which apparently it approximates as 4
bytes per line or instruction.

We fix this problem by moving the operations which generate more than
4 bytes out of the text section. Specifically, moving the .ascii
directives to the .rodata section.

Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS

Joachim Eastwood reports that commit fbfb872f5f41 "ARM: 8148/1: flush
TLS and thumbee register state during exec" causes a boot-time crash
on a Cortex-M4 nommu system:

Freeing unused kernel memory: 68K (281e5000 - 281f6000)
Unhandled exception: IPSR = 00000005 LR = fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
task: 29834000 ti: 29832000 task.ti: 29832000
PC is at flush_thread+0x2e/0x40
LR is at flush_thread+0x21/0x40
pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b
sp : 29833d60 ip : 00000000 fp : 00000001
r10: 00003cf8 r9 : 29b1f000 r8 : 00000000
r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000
r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0
xPSR: 4100000b
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
[<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc)
[<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c)

The problem is that set_tls is attempting to clear the TLS location in
the kernel-user helper page, which isn't set up on V7M.

Fix this by guarding the write to the kuser helper page with
a CONFIG_KUSER_HELPERS ifdef.

Fixes: fbfb872f5f41 ARM: 8148/1: flush TLS and thumbee register state during exec

Reported-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Joachim Eastwood <manabian@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 8177/1: cacheflush: Fix v7_exit_coherency_flush exynos build breakage on ARMv6

This fixes build breakage of platsmp.c if ARMv6 was chosen for compile
time options (e.g. by building allmodconfig):

$ make allmodconfig
$ make
  CC      arch/arm/mach-exynos/platsmp.o
/tmp/ccdQM0Eg.s: Assembler messages:
/tmp/ccdQM0Eg.s:432: Error: selected processor does not support ARM mode `isb '
/tmp/ccdQM0Eg.s:437: Error: selected processor does not support ARM mode `isb '
/tmp/ccdQM0Eg.s:438: Error: selected processor does not support ARM mode `dsb '
make[1]: *** [arch/arm/mach-exynos/platsmp.o] Error 1

The error was introduced in commit "ARM: EXYNOS: Move code from
hotplug.c to platsmp.c".  Previously code using
v7_exit_coherency_flush() macro was built with '-march=armv7-a' flag but
this flag dissapeared during the movement.

Fix this by annotating the v7_exit_coherency_flush() asm code with
armv7-a architecture.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: Mark Brown <broonie@kernel.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ASoC: ssm2602: do not hardcode type to SSM2602

The correct type (SSM2602/SSM2603/SSM2604) is passed down
from the ssm2602_spi_probe()/ssm2602_spi_probe() functions,
so use that instead of hardcoding it to SSM2602 in
ssm2602_probe().

Fixes: c924dc68f737 ("ASoC: ssm2602: Split SPI and I2C code into different modules")
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: stable@vger.kernel.org

Merge tag 'asoc-v3.17-rc6' of git://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v3.17

A few small driver specific fixes and a couple of error handling fixes
in the core.

hyperv: Fix a bug in netvsc_start_xmit()

After the packet is successfully sent, we should not touch the skb
as it may have been freed. This patch is based on the work done by
Long Li <longli@microsoft.com>.

In this version of the patch I have fixed issues pointed out by David.
David, please queue this up for stable.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Tested-by: Long Li <longli@microsoft.com>
Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ACPI / i915: Update the condition to ignore firmware backlight change request

Some of the Thinkpads' firmware will issue a backlight change request
through i915 operation region unconditionally on AC plug/unplug, the
backlight level used is arbitrary and thus should be ignored. This is
handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests
for backlight change). Then there is a Dell laptop whose vendor backlight
interface also makes use of operation region to change backlight level
and with the above commit, that interface no long works. The condition
used to ignore the backlight change request from firmware is thus
changed to: if the vendor backlight interface is not in use and the ACPI
backlight interface is broken, we ignore the requests; oterwise, we keep
processing them.

Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change)
Link: https://lkml.org/lkml/2014/9/23/854
Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected

When the CONFIG_HAVE_CLK is selected for the system, the stmmac_pci_probe
will fail with dmesg:
[    2.167225] stmmaceth 0000:00:14.6: enabling device (0000 -> 0002)
[    2.178267] stmmaceth 0000:00:14.6: enabling bus mastering
[    2.178436] stmmaceth 0000:00:14.6: irq 24 for MSI/MSI-X
[    2.178703] stmmaceth 0000:00:14.6: stmmac_dvr_probe: warning: cannot
get CSR clock
[    2.186503] stmmac_pci_probe: main driver probe failed
[    2.194003] stmmaceth 0000:00:14.6: disabling bus mastering
[    2.196473] stmmaceth: probe of 0000:00:14.6 failed with error -2

This patch fix the issue by breaking the dependency to devm_clk_get()
as the CSR clock can be obtained at priv->plat->clk_csr from pci driver.

Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ematch: Fix matching of inverted containers.

Negated expressions and sub-expressions need to have their flags checked for
TCF_EM_INVERT and their result negated accordingly.

Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>

gro: fix aggregation for skb using frag_list

In commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
I added a regression for linear skb that traditionally force GRO
to use the frag_list fallback.

Erez Shitrit found that at most two segments were aggregated and
the "if (skb_gro_len(p) != pinfo->gso_size)" test was failing.

This is because pinfo at this spot still points to the last skb in the
chain, instead of the first one, where we find the correct gso_size
information.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb")
Reported-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

drm/i915: Flush the PTEs after updating them before suspend

As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).

Fixes a regression from

commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Wed Oct 16 09:21:30 2013 -0700

    drm/i915: Disable GGTT PTEs on GEN6+ suspend

that survived and continue to cause harm even after

commit e568af1c626031925465a5caaab7cca1303d55c7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 26 20:08:20 2014 +0100

    drm/i915: Undo gtt scratch pte unmapping again

v2: Trivial rebase.
v3: Fixes requires pointer dances.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
Tested-by: ming.yao@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Todd Previte <tprevite@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

cpufreq: integrator: fix integrator_cpufreq_remove return type

When building this driver as a module, we get a helpful warning
about the return type:

drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type
  .remove = __exit_p(integrator_cpufreq_remove),

If the remove callback returns void, the caller gets an undefined
value as it expects an integer to be returned. This fixes the
problem by passing down the value from cpufreq_unregister_driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: pcc-cpufreq: Fix wait_event() under spinlock

Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():

BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[<ffffffffa04d74d7>] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
[   51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: G            E  3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
Call Trace:
 [<ffffffff81589dbd>] dump_stack+0x4d/0x90
 [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180
 [<ffffffff8108e298>] __might_sleep+0x48/0xd0
 [<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing);
 [<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0
 [<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock);
 [<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0
 [<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170
 [<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0
 [<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0
 [<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720
 [<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0
 [<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210
 [<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0
 [<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110
 [<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0
 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
 [<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0
 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10
 [<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0
 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
 [<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0
 [<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [<ffffffff81000298>] do_one_initcall+0xc8/0x1f0
 [<ffffffff811a731d>] ? __vunmap+0x9d/0x100
 [<ffffffff810eb9a0>] do_init_module+0x30/0x1b0
 [<ffffffff810edfa6>] load_module+0x686/0x710
 [<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0
 [<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0
 [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b

Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Revert "[media] media: em28xx - remove reset_resume interface"

The reset_resume call is needed, otherwise it will break resume
on some conditions, depending on the usb ehci/xhci controller.

This reverts commit b89193e0b06f44f48e3bf897a5b5cb4a7aff3359.

Reported-by: Johannes Stezenbach <js@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

Linux 3.17-rc7

neigh: check error pointer instead of NULL for ipv4_neigh_lookup()

Fixes: commit f187bc6efb7250afee0e2009b6106 ("ipv4: No need to set generic neighbour pointer")
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

Pull slave-dmaengine fixes from Vinod Koul:
 "Two small fixes for omap dmaengine driver which fixes cyclic suspend
  and resume"

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
  dmaengine: omap-dma: Add memory barrier to dma_resume path

Merge branch 'ipv6_tunnel'

Steffen Klassert says:

====================
ipv6: Return an error when adding an already existing tunnel

The ipv6 tunnel locate functions should not return an existing
tunnel if create is true. Otherwise it is possible to add the
same tunnel multiple times without getting an error.

All our ipv6 tunnels have this bug from the very beginning.
Only the sit tunnel was fixed some years ago with:

commit 8db99e57175 ("sit: Fail to create tunnel, if it already exists").

This patchset fixes the remaining ipv6 tunnels.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

ip6_gre: Return an error when adding an existing tunnel.

ip6gre_tunnel_locate() should not return an existing tunnel if
create is true. Otherwise it is possible to add the same
tunnel multiple times without getting an error.

So return NULL if the tunnel that should be created already
exists.

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ip6_vti: Return an error when adding an existing tunnel.

vti6_locate() should not return an existing tunnel if
create is true. Otherwise it is possible to add the same
tunnel multiple times without getting an error.

So return NULL if the tunnel that should be created already
exists.

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ip6_tunnel: Return an error when adding an existing tunnel.

ip6_tnl_locate() should not return an existing tunnel if
create is true. Otherwise it is possible to add the same
tunnel multiple times without getting an error.

So return NULL if the tunnel that should be created already
exists.

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge remote-tracking branches 'asoc/fix/atmel', 'asoc/fix/compress', 'asoc/fix/core', 'asoc/fix/fsl-ssi' and 'asoc/fix/rt286' into asoc-linus

ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error.

Since we cannot make sure the 'params->num_regs' will always be none
zero here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling
kmemdup().

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

MAINTAINERS: add atmel audio alsa driver maintainer entry

Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs

Pull vfs fixes from Al Viro:
 "Assorted fixes + unifying __d_move() and __d_materialise_dentry() +
  minimal regression fix for d_path() of victims of overwriting rename()
  ported on top of that"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  vfs: Don't exchange "short" filenames unconditionally.
  fold swapping ->d_name.hash into switch_names()
  fold unlocking the children into dentry_unlock_parents_for_move()
  kill __d_materialise_dentry()
  __d_materialise_dentry(): flip the order of arguments
  __d_move(): fold manipulations with ->d_child/->d_subdirs
  don't open-code d_rehash() in d_materialise_unique()
  pull rehashing and unlocking the target dentry into __d_materialise_dentry()
  ufs: deal with nfsd/iget races
  fuse: honour max_read and max_write in direct_io mode
  shmem: fix nlink for rename overwrite directory

Merge branch 'for-3.17-fixes' of git://git./linux/kernel/git/tj/cgroup

Pull cgroup fixes from Tejun Heo:
 "This is quite late but these need to be backported anyway.

  This is the fix for a long-standing cpuset bug which existed from
  2009.  cpuset makes use of PF_SPREAD_{PAGE|SLAB} flags to modify the
  task's memory allocation behavior according to the settings of the
  cpuset it belongs to; unfortunately, when those flags have to be
  changed, cpuset did so directly even whlie the target task is running,
  which is obviously racy as task->flags may be modified by the task
  itself at any time.  This obscure bug manifested as corrupt
  PF_USED_MATH flag leading to a weird crash.

  The bug is fixed by moving the flag to task->atomic_flags.  The first
  two are prepatory ones to help defining atomic_flags accessors and the
  third one is the actual fix"

* 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags
  sched: add macros to define bitops for task atomic flags
  sched: fix confusing PFA_NO_NEW_PRIVS constant

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "Here's our last set of fixes for 3.17.  Most of these are for TI
  platforms, fixing some noisy Kconfig issues, runtime clock and power
  issues on several platforms and NAND timings on DRA7.

  There are also a couple of bug fixes for i.MX, one for QCOM and a
 small fix to avoid section mismatch noise on PXA.

  Diffstat looks large, partially due to some tables being updated and
  thus touching many lines.  The qcom gsbi change also restructures
  clock management a bit and thus touches a bunch of lines.

  All in all, a bit more changes than we'd like at this point, but
  nothing stands out as risky either so it seems like the right thing to
  send it up now instead of holding it to the merge window"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  drivers/soc: qcom: do not disable the iface clock in probe
  ARM: imx: fix .is_enabled() of shared gate clock
  ARM: OMAP3: Fix I/O chain clock line assertion timed out error
  ARM: keystone: dts: fix bindings for pcie and usb clock nodes
  bus: omap_l3_noc: Fix connID for OMAP4
  ARM: DT: imx53: fix lvds channel 1 port
  ARM: dts: cm-t54: fix serial console power supply.
  ARM: dts: dra7-evm: Fix NAND GPMC timings
  ARM: pxa: fix section mismatch warning for pxa_timer_nodt_init
  ARM: OMAP: Fix Kconfig warning for omap1

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS fixes from Ralf Baechle:
 "The final round of fixes.  One corner case in the math emulator and
  another one in the mcount function for ftrace"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: mcount: Adjust stack pointer for static trace in MIPS32
  MIPS: Fix MFC1 & MFHC1 emulation for 64-bit MIPS systems

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "This has:

   - EFI revert to fix a boot regression
   - early_ioremap() fix for boot failure
   - KASLR fix for possible boot failures
   - EFI fix for corrupted string printing
   - remove a misleading EFI bootup 'failed!' error message

  Unfortunately it's all rather close to the merge window"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/efi: Truncate 64-bit values when calling 32-bit OutputString()
  x86/efi: Delete misleading efi_printk() error message
  Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>"
  x86/kaslr: Avoid the setup_data area when picking location
  x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8

vfs: Don't exchange "short" filenames unconditionally.

Only exchange source and destination filenames
if flags contain RENAME_EXCHANGE.
In case if executable file was running and replaced by
other file /proc/PID/exe should still show correct file name,
not the old name of the file by which it was replaced.

The scenario when this bug manifests itself was like this:
* ALT Linux uses rpm and start-stop-daemon;
* during a package upgrade rpm creates a temporary file
  for an executable to rename it upon successful unpacking;
* start-stop-daemon is run subsequently and it obtains
  the (nonexistant) temporary filename via /proc/PID/exe
  thus failing to identify the running process.

Note that "long" filenames (> DNAiME_INLINE_LEN) are still
exchanged without RENAME_EXCHANGE and this behaviour exists
long enough (should be fixed too apparently).
So this patch is just an interim workaround that restores
behavior for "short" names as it was before changes
introduced by commit da1ce0670c14 ("vfs: add cross-rename").

See https://lkml.org/lkml/2014/9/7/6 for details.

AV: the comments about being more careful with ->d_name.hash
than with ->d_name.name are from back in 2.3.40s; they
became obsolete by 2.3.60s, when we started to unhash the
target instead of swapping hash chain positions followed
by d_delete() as we used to do when dcache was first
introduced.

Acked-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: da1ce0670c14 "vfs: add cross-rename"
Signed-off-by: Mikhail Efremov <sem@altlinux.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fold swapping ->d_name.hash into switch_names()

and do it along with ->d_name.len there

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fold unlocking the children into dentry_unlock_parents_for_move()

... renaming it into dentry_unlock_for_move() and making it more
symmetric with dentry_lock_for_move().

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

kill __d_materialise_dentry()

it folds into __d_move() now

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>