commit 404df65d0480f6da2b768f6c9b5259436b1de10f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Mar 6 22:07:02 2014 -0800
Linux 3.13.6
commit 87c3c227f580e2965feceae5f8973e9a38644963
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Feb 11 11:52:05 2014 +0200
drm/i915/dp: add native aux defer retry limit
commit f51a44b9a6c4982cc25bfb3727de9bb893621ebc upstream.
Retrying indefinitely places too much trust on the aux implementation of
the sink devices.
Reported-by: Daniel Martin <consume.noise@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Theodore Ts'o <tytso@mit.edu>
Tested-by: Sree Harsha Totakura <freedesktop@h.totakura.in>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af42ee9f6b2028c6d77c1173fcf24fe0c4480b1f
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Feb 11 11:52:04 2014 +0200
drm/i915/dp: increase native aux defer retry timeout
commit 04eada25d1f72efdecd32d702706594f81de65d5 upstream.
Give more slack to sink devices before retrying on native aux
defer. AFAICT the 100 us timeout was not based on the DP spec.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org (on Jani's request)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 75b27119f191cde96910c16f4b3e8006b46095d8
Author: Jerome Glisse <jglisse@redhat.com>
Date: Wed Feb 26 19:22:47 2014 -0500
drm/radeon: free uvd ring on unload
commit d965441342f3b7d63db784cad852328d17d47942 upstream.
Need to free the uvd ring. Also reshuffle gart tear down to
happen after uvd tear down.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 65236ea8da1a70ffe1aca668768303cc7fb65472
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 25 10:21:43 2014 -0500
drm/radeon: disable pll sharing for DP on DCE4.1
commit 9ef4e1d000a5b335fcebfcf8aef3405e59574c89 upstream.
Causes display problems. We had already disabled
sharing for non-DP displays.
Based on a patch from:
Niels Ole Salscheider <niels_ole@salscheider-online.de>
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=58121
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5cac678c10b9b0d94b3415dba2905523d5e7029e
Author: Christian König <christian.koenig@amd.com>
Date: Thu Feb 20 18:47:14 2014 +0100
drm/radeon: fix missing bo reservation
commit 5e386b574cf7e1593e1296e5b0feea4108ed6ad8 upstream.
Otherwise we might get a crash here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4e9d52047b40b57d9e4d57cc9f159690ce409c94
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Thu Feb 20 09:16:01 2014 -0500
drm/radeon: print the supported atpx function mask
commit 9f050c7f9738ffa746c63415136645ad231b1348 upstream.
Print the supported functions mask in addition to
the version. This is useful in debugging PX
problems since we can see what functions are available.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1e0a28f4a869d9b996e26ad385fd53ee89a8722f
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 18 10:25:39 2014 -0500
drm/radeon: fix audio disable on dce6+
commit d7eb0a0940618f36e5937d81c06ad7bf438a99e2 upstream.
Properly clear the enable bit when audio disable is requested.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da723a73aef66345a9c69253666d8c9b52deec9c
Author: Mike Snitzer <snitzer@redhat.com>
Date: Wed Feb 19 20:32:33 2014 -0500
dm thin: fix the error path for the thin device constructor
commit 1acacc0784aab45627b6009e0e9224886279ac0b upstream.
dm_pool_close_thin_device() must be called if dm_set_target_max_io_len()
fails in thin_ctr(). Otherwise __pool_destroy() will fail because the
pool will still have an open thin device:
device-mapper: thin metadata: attempt to close pmd when 1 device(s) are still open
device-mapper: thin: __pool_destroy: dm_pool_metadata_close() failed.
Also, must establish error code if failing thin_ctr() because the pool
is in fail_io mode.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a6ffcbbf827518ada88e9ac38ae88c6709a6c87
Author: Mike Snitzer <snitzer@redhat.com>
Date: Thu Feb 6 06:08:56 2014 -0500
dm thin: avoid metadata commit if a pool's thin devices haven't changed
commit 4d1662a30dde6e545086fe0e8fd7e474c4e0b639 upstream.
Commit 905e51b ("dm thin: commit outstanding data every second")
introduced a periodic commit. This commit occurs regardless of whether
any thin devices have made changes.
Fix the periodic commit to check if any of a pool's thin devices have
changed using dm_pool_changed_this_transaction().
Reported-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f755b3dbadd5a8d72a21cad3cdaf74d18737f0a6
Author: Mike Snitzer <snitzer@redhat.com>
Date: Fri Jan 31 14:11:54 2014 -0500
dm cache: move hook_info into common portion of per_bio_data structure
commit c6eda5e81c4fcc77185117255c7419eda771f67f upstream.
Commit c9d28d5d ("dm cache: promotion optimisation for writes")
incorrectly placed the 'hook_info' member in the writethrough-only
portion of the per_bio_data structure.
Given that the overwrite optimization may be used for writeback the
'hook_info' member must be placed above the 'cache' member of the
per_bio_data structure. Any members above 'cache' are available from
both writeback and writethrough modes' per_bio_data structure.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 40e93d9d4ca18dc53f2e67896535549fc9e55f74
Author: Hannes Reinecke <hare@suse.de>
Date: Wed Feb 26 10:07:04 2014 +0100
dm mpath: fix stalls when handling invalid ioctls
commit a1989b330093578ea5470bea0a00f940c444c466 upstream.
An invalid ioctl will never be valid, irrespective of whether multipath
has active paths or not. So for invalid ioctls we do not have to wait
for multipath to activate any paths, but can rather return an error
code immediately. This fix resolves numerous instances of:
udevd[]: worker [] unexpectedly returned with status 0x0100
that have been seen during testing.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa9d53380e63a462329b54bfb00c9f9d5288cf46
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Thu Feb 13 10:39:01 2014 +0100
dma: ste_dma40: don't dereference free:d descriptor
commit e9baa9d9d520fb0e24cca671e430689de2d4a4b2 upstream.
It appears that in the DMA40 driver the DMA tasklet will very
often dereference memory for a descriptor just free:d from the
DMA40 slab. Nothing happens because no other part of the driver
has yet had a chance to claim this memory, but it's really
nasty to dereference free:d memory, so let's check the flag
before the descriptor is free and store it in a bool variable.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5b0fd691249908917e96659c03f2bc5869ed249
Author: Sebastian Capella <sebastian.capella@linaro.org>
Date: Tue Feb 18 17:52:08 2014 -0800
PM / hibernate: Fix restore hang in freeze_processes()
commit f8d5b9e9e5372f0deb7bc1ab1088a9b60b0a793d upstream.
During restore, pm_notifier chain are called with
PM_RESTORE_PREPARE. The firmware_class driver handler
fw_pm_notify does not have a handler for this. As a result,
it keeps a reader on the kmod.c umhelper_sem. During
freeze_processes, the call to __usermodehelper_disable tries to
take a write lock on this semaphore and hangs waiting.
Signed-off-by: Sebastian Capella <sebastian.capella@linaro.org>
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d8c2a97e20d1c4e726c21b2eac32a0258ff9ede0
Author: Jean Delvare <jdelvare@suse.de>
Date: Tue Feb 25 09:43:13 2014 +0100
i7300_edac: Fix device reference count
commit 75135da0d68419ef8a925f4c1d5f63d8046e314d upstream.
pci_get_device() decrements the reference count of "from" (last
argument) so when we break off the loop successfully we have only one
device reference - and we don't know which device we have. If we want
a reference to each device, we must take them explicitly and let
the pci_get_device() walk complete to avoid duplicate references.
This is serious, as over-putting device references will cause
the device to eventually disappear. Without this fix, the kernel
crashes after a few insmod/rmmod cycles.
Tested on an Intel S7000FC4UR system with a 7300 chipset.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7dd2bb40cc2e8eb357d772a55c36b762794dfe2
Author: Dr. Greg Wettstein <greg@enjellic.com>
Date: Mon Feb 24 13:59:53 2014 -0600
qla2xxx: Fix kernel panic on selective retransmission request
commit 6f58c780e5a5b43a6d2121e0d43cdcba1d3cc5fc upstream.
A selective retransmission request (SRR) is a fibre-channel
protocol control request which provides support for requesting
retransmission of a data sequence in response to an issue such as
frame loss or corruption. These events are experienced
infrequently in fibre-channel based networks which makes
it difficult to test and assess codepaths which handle these
events.
We were fortunate enough, for some definition of fortunate, to
have a metro-area single-mode SAN link which, at 10 GBPS
sustained load levels, would consistently generate SRR's in
a SCST based target implementation using our SCST/in-kernel
Qlogic target interface driver. In response to an SRR the
in-kernel Qlogic target driver immediately panics resulting
in a catastrophic storage failure for serviced initiators.
The culprit was a debug statement in the qla_target.c file which
does not verify that a pointer to the SCSI CDB is not null.
The unchecked pointer dereference results in the kernel panic
and resultant system failure.
The other two references to the SCSI CDB by the SRR handling code
use a ternary operator to verify a non-null pointer is being
acted on. This patch simply adds a similar test to the implicated
debug statement.
This patch is a candidate for any stable kernel being maintained
since it addresses a potentially catastrophic event with
minimal downside.
Signed-off-by: Dr. Greg Wettstein <greg@enjellic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0648c3a217e182e95161c8ebb763b93a54e4a70f
Author: Olof Johansson <olof@lixom.net>
Date: Fri Feb 14 19:35:15 2014 +0000
ARM64: unwind: Fix PC calculation
commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63 upstream.
The frame PC value in the unwind code used to just take the saved LR
value and use that. That's incorrect as a stack trace, since it shows
the return path stack, not the call path stack.
In particular, it shows faulty information in case the bl is done as
the very last instruction of one label, since the return point will be
in the next label. That can easily be seen with tail calls to panic(),
which is marked __noreturn and thus doesn't have anything useful after it.
Easiest here is to just correct the unwind code and do a -4, to get the
actual call site for the backtrace instead of the return site.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4588b179d044e5f16ed886877d665377822b63ac
Author: James Hogan <james.hogan@imgtec.com>
Date: Tue Feb 25 22:05:35 2014 +0000
irq-metag*: stop set_affinity vectoring to offline cpus
commit f229006ec6beabf7b844653d92fa61f025fe3dcf upstream.
Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND
cpu_online_mask into the cpumask when picking a CPU to vector the
interrupt to.
As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't
filter out offline CPUs, so without this patch if you offline CPU0 and
set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even
though it is offline.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1cb0a781a2bbfd20fccd37250db49893aef61bb
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Tue Feb 25 15:01:42 2014 -0800
mm, thp: fix infinite loop on memcg OOM
commit 9845cbbd113fbb5b769a45d8e88dc47bc12df4e0 upstream.
Masayoshi Mizuma reported a bug with the hang of an application under
the memcg limit. It happens on write-protection fault to huge zero page
If we successfully allocate a huge page to replace zero page but hit the
memcg limit we need to split the zero page with split_huge_page_pmd()
and fallback to small pages.
The other part of the problem is that VM_FAULT_OOM has special meaning
in do_huge_pmd_wp_page() context. __handle_mm_fault() expects the page
to be split if it sees VM_FAULT_OOM and it will will retry page fault
handling. This causes an infinite loop if the page was not split.
do_huge_pmd_wp_zero_page_fallback() can return VM_FAULT_OOM if it failed
to allocate one small page, so fallback to small pages will not help.
The solution for this part is to replace VM_FAULT_OOM with
VM_FAULT_FALLBACK is fallback required.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Rientjes <rientjes@google.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>
commit e2fa98092c16e795aa7dd9124e5ce6dfb795d49f
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue Feb 18 15:22:12 2014 +0000
Input - arizona-haptics: Fix double lock of dapm_mutex
commit c4204960e9d0ba99459dbf1db918f99a45e7a62a upstream.
snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take
it externally as well. This patch fixes this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 10daa7c723b6ad1d26fb8f0323f19c5b7c37ae46
Author: Davidlohr Bueso <davidlohr@hp.com>
Date: Tue Feb 25 15:01:45 2014 -0800
ipc,mqueue: remove limits for the amount of system-wide queues
commit f3713fd9cff733d9df83116422d8e4af6e86b2bb upstream.
Commit 93e6f119c0ce ("ipc/mqueue: cleanup definition names and
locations") added global hardcoded limits to the amount of message
queues that can be created. While these limits are per-namespace,
reality is that it ends up breaking userspace applications.
Historically users have, at least in theory, been able to create up to
INT_MAX queues, and limiting it to just 1024 is way too low and dramatic
for some workloads and use cases. For instance, Madars reports:
"This update imposes bad limits on our multi-process application. As
our app uses approaches that each process opens its own set of queues
(usually something about 3-5 queues per process). In some scenarios
we might run up to 3000 processes or more (which of-course for linux
is not a problem). Thus we might need up to 9000 queues or more. All
processes run under one user."
Other affected users can be found in launchpad bug #1155695:
https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695
Instead of increasing this limit, revert it entirely and fallback to the
original way of dealing queue limits -- where once a user's resource
limit is reached, and all memory is used, new queues cannot be created.
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Reported-by: Madars Vitolins <m@silodev.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.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>
commit 3dda6e5eb11dd9c0e183988d3780db6edb86abc1
Author: Jan Kara <jack@suse.cz>
Date: Thu Feb 20 17:02:27 2014 +0100
quota: Fix race between dqput() and dquot_scan_active()
commit 1362f4ea20fa63688ba6026e586d9746ff13a846 upstream.
Currently last dqput() can race with dquot_scan_active() causing it to
call callback for an already deactivated dquot. The race is as follows:
CPU1 CPU2
dqput()
spin_lock(&dq_list_lock);
if (atomic_read(&dquot->dq_count) > 1) {
- not taken
if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {
spin_unlock(&dq_list_lock);
->release_dquot(dquot);
if (atomic_read(&dquot->dq_count) > 1)
- not taken
dquot_scan_active()
spin_lock(&dq_list_lock);
if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))
- not taken
atomic_inc(&dquot->dq_count);
spin_unlock(&dq_list_lock);
- proceeds to release dquot
ret = fn(dquot, priv);
- called for inactive dquot
Fix the problem by making sure possible ->release_dquot() is finished by
the time we call the callback and new calls to it will notice reference
dquot_scan_active() has taken and bail out.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 098ae37294accb8de665cc8085a6cd3fda2d1372
Author: Dan Williams <dan.j.williams@intel.com>
Date: Wed Feb 19 16:19:35 2014 -0800
ioat: fix tasklet tear down
commit da87ca4d4ca101f177fffd84f1f0a5e4c0343557 upstream.
Since commit 77873803363c "net_dma: mark broken" we no longer pin dma
engines active for the network-receive-offload use case. As a result
the ->free_chan_resources() that occurs after the driver self test no
longer has a NET_DMA induced ->alloc_chan_resources() to back it up. A
late firing irq can lead to ksoftirqd spinning indefinitely due to the
tasklet_disable() performed by ->free_chan_resources(). Only
->alloc_chan_resources() can clear this condition in affected kernels.
This problem has been present since commit 3e037454bcfa "I/OAT: Add
support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the
NET_DMA use case is deprecated we can revisit moving the driver to use
threaded irqs. For now, just tear down the irq and tasklet properly by:
1/ Disable the irq from triggering the tasklet
2/ Disable the irq from re-arming
3/ Flush inflight interrupts
4/ Flush the timer
5/ Flush inflight tasklets
References:
https://lkml.org/lkml/2014/1/27/282
https://lkml.org/lkml/2014/2/19/672
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>
Reported-by: Mike Galbraith <bitbucket@online.de>
Reported-by: Stanislav Fomichev <stfomichev@yandex-team.ru>
Tested-by: Mike Galbraith <bitbucket@online.de>
Tested-by: Stanislav Fomichev <stfomichev@yandex-team.ru>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 37ab756f809417512318b5fca35f27792ad8d375
Author: Eric Paris <eparis@redhat.com>
Date: Thu Feb 20 10:56:45 2014 -0500
SELinux: bigendian problems with filename trans rules
commit 9085a6422900092886da8c404e1c5340c4ff1cbf upstream.
When writing policy via /sys/fs/selinux/policy I wrote the type and class
of filename trans rules in CPU endian instead of little endian. On
x86_64 this works just fine, but it means that on big endian arch's like
ppc64 and s390 userspace reads the policy and converts it from
le32_to_cpu. So the values are all screwed up. Write the values in le
format like it should have been to start.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ee9d6de73c5478edda84b2e373b4d336afe01927
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Wed Jan 22 08:04:43 2014 +0400
xtensa: introduce spill_registers_kernel macro
commit e2fd1374c705abe4661df3fb6fadb3879c7c1846 upstream.
Most in-kernel users want registers spilled on the kernel stack and
don't require PS.EXCM to be set. That means that they don't need fixup
routine and could reuse regular window overflow mechanism for that,
which makes spill routine very simple.
Suggested-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b87babbd6839a0112ad99a7384edc7e306bfbbe6
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Wed Oct 30 16:18:25 2013 +0400
xtensa: save current register frame in fast_syscall_spill_registers_fixup
commit 3251f1e27a5a17f0efd436cfd1e7b9896cfab0a0 upstream.
We need it saved because it contains a3 where we track which register
windows we still need to spill, and fixup handler may call C exception
handlers. Also fix comments.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 777bf82cd9a130cb5c4d472c0532a383c99e2ac8
Author: Andrew Lunn <andrew@lunn.ch>
Date: Fri Feb 7 00:41:58 2014 +0100
irqchip: orion: Fix getting generic chip pointer.
commit d86e9af6336c0ad586a5dbd70064253d40bbb5ff upstream.
Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
handler. The bridge interrupt is implemented using a single generic
chip. Thus the parameter passed to irq_get_domain_generic_chip()
should always be zero.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Fixes: 9dbd90f17e4f ("irqchip: Add support for Marvell Orion SoCs")
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cfc9142a23dff5a785bc846a91644accd475500e
Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Fri Jan 24 00:10:32 2014 +0100
irqchip: orion: clear stale interrupts in irq_startup
commit e0318ec3bf3f1502cd11b21b1eb00aa355b40b67 upstream.
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_startup callback to ensure stale
irqs are cleared before initial unmask.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c703ce709e64e399ed2490e39f80ebc36d37a2af
Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Thu Jan 23 23:38:05 2014 +0100
irqchip: orion: use handle_edge_irq on bridge irqs
commit 5f40067fc86f0e49329ad4a852c278998ff4394e upstream.
Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high
transitions and not on the level of the downstream interrupt line.
This replaces handle_level_irq by the more appropriate handle_edge_irq.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 31b61124fcfbe3af0667ae4dd6f25508ab9829e9
Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Thu Jan 23 23:38:04 2014 +0100
irqchip: orion: clear bridge cause register on init
commit 7b119fd1bdc59a8060df5b659b9f7a70e0169fd6 upstream.
It is good practice to mask and clear pending irqs on init. We already
mask all irqs, so also clear the bridge irq cause register.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84d6269121d2b7036ff815869cd288fbe22a9082
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 24 15:23:10 2014 +0100
ALSA: hda - Add a fixup for HP Folio 13 mute LED
commit 37c367ecdb9a01c9acc980e6e17913570a1788a7 upstream.
HP Folio 13 may have a broken BIOS that doesn't set up the mute LED
GPIO properly, and the driver guesses it wrongly, too. Add a new
fixup entry for setting the GPIO pin statically for this laptop.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70991
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7cc910f328067711168da773a67ab2476d729a6a
Author: Peter Zijlstra <peterz@infradead.org>
Date: Mon Feb 24 12:06:12 2014 +0100
perf: Fix hotplug splat
commit e3703f8cdfcf39c25c4338c3ad8e68891cca3731 upstream.
Drew Richardson reported that he could make the kernel go *boom* when hotplugging
while having perf events active.
It turned out that when you have a group event, the code in
__perf_event_exit_context() fails to remove the group siblings from
the context.
We then proceed with destroying and freeing the event, and when you
re-plug the CPU and try and add another event to that CPU, things go
*boom* because you've still got dead entries there.
Reported-by: Drew Richardson <drew.richardson@arm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af20781fceacf729078619c99381e5fa4f98d2d1
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Feb 6 01:00:35 2014 +0000
perf trace: Add fallback definition of EFD_SEMAPHORE
commit 79d26a6a19ace19faabf8d8d27d3430be2e26d34 upstream.
glibc 2.17 is missing this on sparc, despite the fact that it's not
architecture-specific.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: 49af9e93adfa ('perf trace: Beautify eventfd2 'flags' arg')
Cc: <stable@vger.kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1391648435.3003.100.camel@deadeye.wl.decadent.org.uk
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af56f133b3f16ccf18c20a706f0e7bcdb5117b8e
Author: Will Deacon <will.deacon@arm.com>
Date: Thu Feb 6 14:59:05 2014 +0000
iommu/arm-smmu: set CBARn.BPSHCFG to NSH for s1-s2-bypass contexts
commit 57ca90f6800987ac274d7ba065ae6692cdf9bcd7 upstream.
Whilst trying to bring-up an SMMUv2 implementation with the table
walker plumbed into a coherent interconnect, I noticed that the memory
transactions targetting the CPU caches from the SMMU were marked as
outer-shareable instead of inner-shareable.
After a bunch of digging, it seems that we actually need to program
CBARn.BPSHCFG for s1-s2-bypass contexts to act as non-shareable in order
for the shareability configured in the corresponding TTBCR not to be
overridden with an outer-shareable attribute.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bf6d0428283db250d9dde3e7fb6ca51fc490d5d7
Author: Will Deacon <will.deacon@arm.com>
Date: Wed Feb 5 17:49:34 2014 +0000
iommu/arm-smmu: fix table flushing during initial allocations
commit 6dd35f45b8dac827b6f9dd86f5aca6436cdd2410 upstream.
Now that we populate page tables as we traverse them ("iommu/arm-smmu:
fix pud/pmd entry fill sequence"), we need to ensure that we flush out
our zeroed tables after initial allocation, to prevent speculative TLB
fills using bogus data.
This patch adds additional calls to arm_smmu_flush_pgtable during
initial table allocation, and moves the dsb required by coherent table
walkers into the helper.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d38c6fee4dcd002f9936f4936334d95632bab064
Author: Will Deacon <will.deacon@arm.com>
Date: Tue Feb 4 22:12:42 2014 +0000
iommu/arm-smmu: really fix page table locking
commit c9d09e2748eaa55cac2af274574baa6368189bc1 upstream.
Commit a44a9791e778 ("iommu/arm-smmu: use mutex instead of spinlock for
locking page tables") replaced the page table spinlock with a mutex, to
allow blocking allocations to satisfy lazy mapping requests.
Unfortunately, it turns out that IOMMU mappings are created from atomic
context (e.g. spinlock held during a dma_map), so this change doesn't
really help us in practice.
This patch is a partial revert of the offending commit, bringing back
the original spinlock but replacing our page table allocations for any
levels below the pgd (which is allocated during domain init) with
GFP_ATOMIC instead of GFP_KERNEL.
Reported-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c8c2d723c2a217aba0eb475cd4e8fd484fb308e
Author: Yifan Zhang <zhangyf@marvell.com>
Date: Fri Jan 3 12:01:26 2014 +0000
iommu/arm-smmu: fix pud/pmd entry fill sequence
commit 97a644208d1a08b7104d1fe2ace8cef011222711 upstream.
The ARM SMMU driver's population of puds and pmds is broken, since we
iterate over the next level of table repeatedly setting the current
level descriptor to point at the pmd being initialised. This is clearly
wrong when dealing with multiple pmds/puds.
This patch fixes the problem by moving the pud/pmd population out of the
loop and instead performing it when we allocate the next level (like we
correctly do for ptes already). The starting address for the next level
is then calculated prior to entering the loop.
Signed-off-by: Yifan Zhang <zhangyf@marvell.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5a5153767e6935de848f89de746627d6145c837
Author: Denis CIOCCA <denis.ciocca@st.com>
Date: Fri Feb 14 14:15:00 2014 +0000
iio:gyro: bug on L3GD20H gyroscope support
commit a0657716416f834ef7710a9044614d50a36c3bdc upstream.
The driver was not able to manage the sensor: during probe function
and wai check, the driver stops and writes: "device name and WhoAmI mismatch."
The correct value of L3GD20H wai is 0xd7 instead of 0xd4.
Dropped support for the sensor.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 721486fa5cc6d8cf92ea6ffb8d54d71f2d7b7d47
Author: Manu Gupta <manugupt1@gmail.com>
Date: Mon Feb 24 12:12:28 2014 -0600
staging: r8188eu: Add new device ID
commit 260ea9c2e2d330303163e286ab01b66dbcfe3a6f upstream.
The D-Link DWA-123 REV D1 with USB ID 2001:3310 uses this driver.
Signed-off-by: Manu Gupta <manugupt1@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea6de21a0b82a8db5adc19967bbb89cb7b3a2244
Author: Juergen Beisert <jbe@pengutronix.de>
Date: Mon Feb 24 14:39:00 2014 +0000
staging:iio:adc:MXS:LRADC: fix touchscreen statemachine
commit 760dbe1dcb6d3dd3ead73dc69b23f206b52273bb upstream.
Releasing the touchscreen lets the internal statemachine left in a wrong state.
Due to this the release coordinate will be reported again by accident when the next
touchscreen event happens. This change sets up the correct state when waiting
for the next touchscreen event.
This has led to reported issues with calibrating the touchscreen.
Bug was introduced somewhere in the series that began with
18da755de59b406ce2371a55fb15ed676eb08ed2
Staging/iio/adc/touchscreen/MXS: add proper clock handling
in which the way this driver worked was substantially changed
to be interrupt driven rather than relying on a busy loop.
This was a regression in the 3.13 kernel.
Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b6e55e9c2599ed049524ba60aeb3b4f8bf986009
Author: Arve Hjønnevåg <arve@android.com>
Date: Mon Feb 17 13:58:29 2014 -0800
staging: binder: Fix death notifications
commit e194fd8a5d8e0a7eeed239a8534460724b62fe2d upstream.
The change (008fa749e0fe5b2fffd20b7fe4891bb80d072c6a) that moved the
node release code to a separate function broke death notifications in
some cases. When it encountered a reference without a death
notification request, it would skip looking at the remaining
references, and therefore fail to send death notifications for them.
Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f648ea81458f23fc6a0d0ed2e9a85b976a76c32
Author: Pekon Gupta <pekon@ti.com>
Date: Mon Feb 17 13:11:25 2014 +0530
mtd: nand: omap: fix ecclayout->oobfree->length
commit bb38eefb6858ce16b34716145b9597a5680aa54c upstream.
This patch excludes reserved-marker byte-position from oobfree->length
calculation. Thus all bytes from oobfree->offset till end of OOB are free.
Signed-off-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d98b58586fe428e08c43fa33081974a5961ddbf1
Author: Pekon Gupta <pekon@ti.com>
Date: Mon Feb 17 13:11:24 2014 +0530
mtd: nand: omap: fix ecclayout->oobfree->offset
commit aa6092f9835893290e77c3e24649def49dac1583 upstream.
1) In current implementation, ecclayout->oobfree->offset is calculated with
respect to ecclayout->eccpos[0] which is incorrect because ECC bytes may not
be stored contiguously in OOB.
So, this patch calculates ecclayout->oobfree->offset with respect to last
ECC byte-position 'eccpos[ecclayout->eccbytes-1]'.
2) ECC layout of some ecc-schemes expects reserved-markers at specific eccpos[]
which should not be over-written by any file-system metadata.
So this patch aligns oobfree->offset taking into account of such markers.
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aae6284e65491176f0e3de397162b8167fa0b4b6
Author: Pekon Gupta <pekon@ti.com>
Date: Mon Feb 17 13:11:23 2014 +0530
mtd: nand: omap: fix ecclayout to be in sync with u-boot NAND driver
commit eae39cb4934d3daab3ec828c5201c955b2e56af9 upstream.
Fixes: commit a919e51161b58ed7e6e663daba99ab7d558808f3
mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
Fixes ecclayout mismatch introduced in above commit for following ecc-schemes:
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
However, this patch also touches other ecc-schemes as the fix required
refactoring common code, into ecc-scheme specific code.
This patch aligns ecc-layout for below ecc-schemes as per reference [1],[2],[3]
+---+------------+-------------++-------------+-------------+
|OOB|BCH8_CODE_HW|BCH8_CODE_HW_||HAM1_CODE_HW |HAM1_CODE_HW |
|pos| | DETECTION_SW||(x8 device) |(x16 device) |
+---+------------+-------------++-------------+-------------+
| 0 |BADBLK_MARK | BADBLK_MARK || BADBLK_MARK | BADBLK_MARK |
| 1 |BADBLK_MARK | BADBLK_MARK || eccpos[0] | BADBLK_MARK |
| 2 | eccpos[0] | eccpos[0] || eccpos[1] | eccpos[0] |
| 3 | eccpos[1] | eccpos[1] || eccpos[2] | eccpos[1] |
| 4 | eccpos[2] | eccpos[2] || eccpos[3] | eccpos[2] |
| 5 | eccpos[3] | eccpos[3] || eccpos[4] | eccpos[3] |
| 6 | eccpos[4] | eccpos[4] || eccpos[5] | eccpos[4] |
| 7 | eccpos[5] | eccpos[5] || eccpos[6] | eccpos[5] |
| 8 | eccpos[6] | eccpos[6] || eccpos[7] | eccpos[6] |
| 9 | eccpos[7] | eccpos[7] || eccpos[8] | eccpos[7] |
|10 | eccpos[8] | eccpos[8] || eccpos[9] | eccpos[8] |
|11 | eccpos[9] | eccpos[9] || eccpos[10] | eccpos[9] |
|12 | eccpos[10] | eccpos[10] || eccpos[11] | eccpos[10] |
|13 | eccpos[11] | eccpos[11] || oobfree[0] | eccpos[11] |
|14 | eccpos[12] | eccpos[12] || oobfree[1] | oobfree[0] |
|15 | eccpos[13] | <reserved> || oobfree[2] | oobfree[1] |
+---+------------+-------------++-------------+-------------+
|16 | eccpos[14] | eccpos[13] || oobfree[3] | oobfree[2] |
|...| [...] | [...] || [...] | [...] |
|56 | eccpos[54] | eccpos[51] || oobfree[43] | oobfree[42] |
|57 | eccpos[55] | <reserved> || oobfree[44] | oobfree[43] |
+===+============+=============+==============+=============+
|58 | oobfree[0] | oobfree[0] || oobfree[45] | oobfree[44] |
|59 | oobfree[1] | oobfree[1] || oobfree[46] | oobfree[45] |
|60 | oobfree[2] | oobfree[2] || oobfree[47] | oobfree[46] |
|61 | oobfree[3] | oobfree[3] || oobfree[48] | oobfree[47] |
|62 | oobfree[4] | oobfree[4] || oobfree[49] | oobfree[48] |
|63 | oobfree[5] | oobfree[5] || oobfree[50] | oobfree[49] |
+---+------------+-------------+--------------+-------------+
[1] ecc-layout expected by ROM code, as specified in SoC TRM under:
Chapter="Initialization"
Section="Device Initialization by ROM code"
Sub-Section="Memory Booting"
Heading="NAND"
Figure="ECC Locations in NAND Spare Areas"
[2] ecc-layout updates in u-boot
http://lists.denx.de/pipermail/u-boot/2013-November/167551.html
[3] u-boot configurations to match above ecc-layout are documented at
https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide
Reported-by: Enric Balletbo Serra <eballetbo@iseebcn.com>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a905f20d21f16c1e09e7054c6bb7a868fd7192c4
Author: Steve Twiss <stwiss.opensource@diasemi.com>
Date: Wed Feb 12 09:57:52 2014 +0000
regulator: da9063: Bug fix when setting max voltage on LDOs 5-11
commit ebf6dad0de89677aa58a4d8b009014ff88a23452 upstream.
Bug fix to allow the setting of maximum voltage for certain LDOs.
What the bug is:
There is a problem caused by an invalid calculation of n_voltages
in the driver. This n_voltages value has the potential to be
different for each regulator.
The value for linear_min_sel is set as DA9063_V##regl_name#
which can be different depending upon the regulator. This is
chosen according to the following definitions in the DA9063
registers.h file:
DA9063_VLDO1_BIAS 0
DA9063_VLDO2_BIAS 0
DA9063_VLDO3_BIAS 0
DA9063_VLDO4_BIAS 0
DA9063_VLDO5_BIAS 2
DA9063_VLDO6_BIAS 2
DA9063_VLDO7_BIAS 2
DA9063_VLDO8_BIAS 2
DA9063_VLDO9_BIAS 3
DA9063_VLDO10_BIAS 2
DA9063_VLDO11_BIAS 2
The calculation for n_voltages is valid for LDOs whose BIAS value
is zero but this is not correct for those LDOs which have a
non-zero value.
What the fix is:
In order to take into account the non-zero linear_min_sel value which
is set for the regulators LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 and
LDO11, the calculation for n_voltages should take into account the
missing term defined by DA9063_V##regl_name#.
This will in turn allow the core constraints calculation to set the
maximum voltage limits correctly and therefore allow users to apply
the maximum expected voltage to all of the LDOs.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 42e2d5f1a3dd5656a3e0236f2840015e2b09d4ff
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Sat Feb 15 22:02:28 2014 +0800
workqueue: ensure @task is valid across kthread_stop()
commit 5bdfff96c69a4d5ab9c49e60abf9e070ecd2acbb upstream.
When a kworker should die, the kworkre is notified through WORKER_DIE
flag instead of kthread_should_stop(). This, IIRC, is primarily to
keep the test synchronized inside worker_pool lock. WORKER_DIE is
first set while holding pool->lock, the lock is dropped and
kthread_stop() is called.
Unfortunately, this means that there's a slight chance that the target
kworker may see WORKER_DIE before kthread_stop() finishes and exits
and frees the target task before or during kthread_stop().
Fix it by pinning the target task before setting WORKER_DIE and
putting it after kthread_stop() is done.
tj: Improved patch description and comment. Moved pinning above
WORKER_DIE for better signify what it's protecting.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 00b29b3d146043f5e4dc9077fc58bbfbff4d9198
Author: Guenter Roeck <linux@roeck-us.net>
Date: Sat Feb 15 17:54:06 2014 -0800
hwmon: (max1668) Fix writing the minimum temperature
commit 500a91571f0a5d0d3242d83802ea2fd1faccc66e upstream.
When trying to set the minimum temperature, the driver was erroneously
writing the maximum temperature into the chip.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cda6b481a453976f489d7f33595fd16ee4e7db40
Author: Chao Bi <chao.bi@intel.com>
Date: Wed Feb 12 21:27:25 2014 +0200
mei: set client's read_cb to NULL when flow control fails
commit accb884b32e82f943340688c9cd30290531e73e0 upstream.
In mei_cl_read_start(), if it fails to send flow control request, it
will release "cl->read_cb" but forget to set pointer to NULL, leaving
"cl->read_cb" still pointing to random memory, next time this client is
operated like mei_release(), it has chance to refer to this wrong pointer.
Fixes: PANIC at kfree in mei_release()
[228781.826904] Call Trace:
[228781.829737] [<c16249b8>] ? mei_cl_unlink+0x48/0xa0
[228781.835283] [<c1624487>] mei_io_cb_free+0x17/0x30
[228781.840733] [<c16265d8>] mei_release+0xa8/0x180
[228781.845989] [<c135c610>] ? __fsnotify_parent+0xa0/0xf0
[228781.851925] [<c1325a69>] __fput+0xd9/0x200
[228781.856696] [<c1325b9d>] ____fput+0xd/0x10
[228781.861467] [<c125cae1>] task_work_run+0x81/0xb0
[228781.866821] [<c1242e53>] do_exit+0x283/0xa00
[228781.871786] [<c1a82b36>] ? kprobe_flush_task+0x66/0xc0
[228781.877722] [<c124eeb8>] ? __dequeue_signal+0x18/0x1a0
[228781.883657] [<c124f072>] ? dequeue_signal+0x32/0x190
[228781.889397] [<c1243744>] do_group_exit+0x34/0xa0
[228781.894750] [<c12517b6>] get_signal_to_deliver+0x206/0x610
[228781.901075] [<c12018d8>] do_signal+0x38/0x100
[228781.906136] [<c1626d1c>] ? mei_read+0x42c/0x4e0
[228781.911393] [<c12600a0>] ? wake_up_bit+0x30/0x30
[228781.916745] [<c16268f0>] ? mei_poll+0x120/0x120
[228781.922001] [<c1324be9>] ? vfs_read+0x89/0x160
[228781.927158] [<c16268f0>] ? mei_poll+0x120/0x120
[228781.932414] [<c133ca34>] ? fget_light+0x44/0xe0
[228781.937670] [<c1324e58>] ? SyS_read+0x68/0x80
[228781.942730] [<c12019f5>] do_notify_resume+0x55/0x70
[228781.948376] [<c1a7de5d>] work_notifysig+0x29/0x30
[228781.953827] [<c1a70000>] ? bad_area+0x5/0x3e
Signed-off-by: Chao Bi <chao.bi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d0fd713810c13d00688fa01c94ea59202020c0e8
Author: Joerg Dorchain <joerg@dorchain.net>
Date: Fri Feb 21 20:29:33 2014 +0100
USB: ftdi_sio: add Cressi Leonardo PID
commit 6dbd46c849e071e6afc1e0cad489b0175bca9318 upstream.
Hello,
the following patch adds an entry for the PID of a Cressi Leonardo
diving computer interface to kernel 3.13.0.
It is detected as FT232RL.
Works with subsurface.
Signed-off-by: Joerg Dorchain <joerg@dorchain.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9995c904987d740b0457317b1d8c08968af7263a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed Feb 19 10:29:01 2014 +0100
usb: ehci: fix deadlock when threadirqs option is used
commit a1227f3c1030e96ebc51d677d2f636268845c5fb upstream.
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().
This change can be reverted when hrtimer callbacks become threaded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa0346d71ecec4b91cd48d35fcaa992c986a38ed
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Thu Feb 13 15:49:17 2014 -0500
USB: EHCI: add delay during suspend to prevent erroneous wakeups
commit 3e8d6d85adedc59115a564c0a54b36e42087c4d9 upstream.
High-speed USB connections revert back to full-speed signalling when
the device goes into suspend. This takes several milliseconds, and
during that time it's not possible to tell reliably whether the device
has been disconnected.
On some platforms, the Wake-On-Disconnect circuitry gets confused
during this intermediate state. It generates a false wakeup signal,
which can prevent the controller from going to sleep.
To avoid this problem, this patch adds a 5-ms delay to the
ehci_bus_suspend() routine if any ports have to switch over to
full-speed signalling. (Actually, the delay was already present for
devices using a particular kind of PHY power management; the patch
merely causes the delay to be used more widely.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Peter Chen <Peter.Chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a9a7909523e7b2c138dcaaee9d95557bcfe80be6
Author: Aleksander Morgado <aleksander@aleksander.es>
Date: Wed Feb 12 16:04:45 2014 +0100
USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8
commit 12df84d4a80278a5b1abfec3206795291da52fc9 upstream.
This interface is to be handled by the qmi_wwan driver.
CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
CC: Christian Schmiedl <christian.schmiedl@gemalto.com>
CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com>
CC: David McCullough <david.mccullough@accelecon.com>
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67cf8993b9ad6dde39020a18c2602c763d9770db
Author: Florian Fainelli <florian@openwrt.org>
Date: Tue Jan 14 15:36:29 2014 -0800
usb: gadget: bcm63xx_udc: fix build failure on DMA channel code
commit 2d1f7af3d60dd09794e0738a915d272c6c27abc5 upstream.
Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
changed the ENETDMA[CS] macros such that they are no longer macros, but
actual register offset definitions. The bcm63xx_udc driver was not
updated, and as a result, causes the following build error to pop up:
CC drivers/usb/gadget/u_ether.o
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write':
drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel':
drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not
a function
Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to
take an extra channel argument, and use the channel width
(ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence
doing again what the macro implicitely did for us.
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 045554542df724f4fbd17c26bc847d5f403c3b57
Author: Matthieu CASTET <matthieu.castet@parrot.com>
Date: Wed Feb 19 13:46:31 2014 +0800
usb: chipidea: need to mask when writting endptflush and endptprime
commit 5bf5dbeda2454296f1984adfbfc8e6f5965ac389 upstream.
ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Tested-by: Michael Grzeschik <mgrzeschik@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a122e1f4c504578e1379d2808ce8a6f7e71a96db
Author: Olivier Sobrie <olivier@sobrie.be>
Date: Tue Feb 11 11:01:23 2014 +0100
can: kvaser_usb: check number of channels returned by HW
commit 862474f8b46f6c1e600d4934e40ba40646c696ec upstream.
It is needed to check the number of channels returned by the HW because it
cannot be greater than MAX_NET_DEVICES otherwise it will crash.
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 55e02d0a3383b15d1fcff130f83c0096e22a19b2
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Wed Feb 12 10:01:06 2014 -0800
intel_pstate: Use LFM bus ratio as min ratio/P state
commit 4042e7570cff740460b75c6fc604c629621d3dd2 upstream.
LFM (max efficiency ratio) is the max frequency at minimum voltage
supported by the processor. Using LFM as the minimum P state
increases performmance without affecting power. By not using P states
below LFM we avoid using P states that are less power efficient.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d1fe6dc50ee5443e3a529a9b60b5aa1f5e3cc1e
Author: Lan Tianyu <tianyu.lan@intel.com>
Date: Wed Feb 26 21:03:05 2014 +0800
ACPI / processor: Rework processor throttling with work_on_cpu()
commit f3ca4164529b875374c410193bbbac0ee960895f upstream.
acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
sure that the (struct acpi_processor)->acpi_processor_set_throttling()
callback will run on the right CPU. However, the function may be
called from a worker thread already bound to a different CPU in which
case that won't work.
Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
instead of abusing set_cpus_allowed_ptr().
Reported-and-tested-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 55cd2c655d5470a7caf1a7ac56371f44645ed70f
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Feb 13 16:32:51 2014 +0100
ACPI / video: Filter the _BCL table for duplicate brightness values
commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream.
Some devices have duplicate entries in there brightness levels table, ie
on my Dell Latitude E6430 the table looks like this:
[ 3.686060] acpi backlight index 0, val 80
[ 3.686095] acpi backlight index 1, val 50
[ 3.686122] acpi backlight index 2, val 5
[ 3.686147] acpi backlight index 3, val 5
[ 3.686172] acpi backlight index 4, val 5
[ 3.686197] acpi backlight index 5, val 5
[ 3.686223] acpi backlight index 6, val 5
[ 3.686248] acpi backlight index 7, val 5
[ 3.686273] acpi backlight index 8, val 6
[ 3.686332] acpi backlight index 9, val 7
[ 3.686356] acpi backlight index 10, val 8
[ 3.686380] acpi backlight index 11, val 9
etc.
Notice that brightness values 0-5 are all mapped to 5. This means that
if userspace writes any value between 0 and 5 to the brightness sysfs attribute
and then reads it, it will always return 0, which is somewhat unexpected.
This is a problem for ie gnome-settings-daemon, which uses read-modify-write
logic when the users presses the brightness up or down keys. This is done
this way to take brightness changes from other sources into account.
On this specific laptop what happens once the brightness has been set to 0,
is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
again reads 0, so things get stuck at the lowest brightness setting.
Filtering out the duplicate table entries, makes any write to brightness
read back as the written value as one would expect, fixing this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d370afc93ddeb83e909d7dedea8ee8ea82438592
Author: Jean Delvare <jdelvare@suse.de>
Date: Mon Feb 24 09:39:27 2014 +0100
i7core_edac: Fix PCI device reference count
commit c0f5eeed0f4cef4f05b74883a7160e7edde58b6a upstream.
The reference count changes done by pci_get_device can be a little
misleading when the usage diverges from the most common scheme. The
reference count of the device passed as the last parameter is always
decreased, even if the function returns no new device. So if we are
going to try alternative device IDs, we must manually increment the
device reference count before each retry. If we don't, we end up
decreasing the reference count, and after a few modprobe/rmmod cycles
the PCI devices will vanish.
In other words and as Alan put it: without this fix the EDAC code
corrupts the PCI device list.
This fixes kernel bug #50491:
https://bugzilla.kernel.org/show_bug.cgi?id=50491
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvare
Reviewed-by: Alan Cox <alan@linux.intel.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 276826bee69b62789824cf6ab73b49a25e683f61
Author: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Date: Mon Feb 10 14:00:11 2014 +0100
ACPI / PCI: Fix memory leak in acpi_pci_irq_enable()
commit b685f3b1744061aa9ad822548ba9c674de5be7c6 upstream.
acpi_pci_link_allocate_irq() can return negative gsi even if
entry != NULL. For that case we have a memory leak, so free
entry before returning from acpi_pci_irq_enable() for gsi < 0.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3404ec304327ac92e8da2fd250c5aa7a81229fde
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Fri Feb 14 13:48:16 2014 -0700
PCI: Enable INTx if BIOS left them disabled
commit 1f42db786b14a31bf807fc41ee5583a00c08fcb1 upstream.
Some firmware leaves the Interrupt Disable bit set even if the device uses
INTx interrupts. Clear Interrupt Disable so we get those interrupts.
Based on the report mentioned below, if the user selects the "EHCI only"
option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS
with the PCI_COMMAND_INTX_DISABLE bit set.
Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601
Reported-by: Chris Cheng <chris.cheng@atrustcorp.com>
Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9984691beb0578d1211bb9b22292ea00789f9f5c
Author: Andrew Lunn <andrew@lunn.ch>
Date: Wed Feb 5 11:55:49 2014 +0100
PCI: mvebu: Use Device ID and revision from underlying endpoint
commit 322a8e91844f4ae2093e0d3d8a318d0ef2596756 upstream.
Marvell SoCs place the SoC number into the PCIe endpoint device ID. The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.
The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.
When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality. Debian would
like to use this in order to aid installing the correct DTB file.
Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2d05bc28656677e3b58ae7556e16a0ad1291ce08
Author: Jan Kara <jack@suse.cz>
Date: Fri Feb 21 11:19:04 2014 +0100
Revert "writeback: do not sync data dirtied after sync start"
commit 0dc83bd30b0bf5410c0933cfbbf8853248eff0a9 upstream.
This reverts commit c4a391b53a72d2df4ee97f96f78c1d5971b47489. Dave
Chinner <david@fromorbit.com> has reported the commit may cause some
inodes to be left out from sync(2). This is because we can call
redirty_tail() for some inode (which sets i_dirtied_when to current time)
after sync(2) has started or similarly requeue_inode() can set
i_dirtied_when to current time if writeback had to skip some pages. The
real problem is in the functions clobbering i_dirtied_when but fixing
that isn't trivial so revert is a safer choice for now.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6c54cb0037e20c772ccc5c0e3b0506e402789f8
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date: Mon Feb 17 16:18:21 2014 +0530
cpufreq: powernow-k8: Initialize per-cpu data-structures properly
commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e upstream.
The powernow-k8 driver maintains a per-cpu data-structure called
powernow_data that is used to perform the frequency transitions.
It initializes this data structure only for the policy->cpu. So,
accesses to this data structure by other CPUs results in various
problems because they would have been uninitialized.
Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get()
function, it returns 0 as the KHz value, since its per-cpu memory
doesn't point to anything valid. This causes problems during
suspend/resume since cpufreq_update_policy() tries to enforce this
(0 KHz) as the current frequency of the CPU, and this madness gets
propagated to adjust_jiffies() as well. Eventually, lots of things
start breaking down, including the r8169 ethernet card, in one
particularly interesting case reported by Pierre Ossman.
Fix this by initializing the per-cpu data-structures of all the CPUs
in the policy appropriately.
References: https://bugzilla.kernel.org/show_bug.cgi?id=70311
Reported-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2263f03bcb38ae553fabf83150011643dad3359f
Author: Tejun Heo <tj@kernel.org>
Date: Mon Feb 3 10:42:07 2014 -0500
sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN
commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.
It's a bit odd to see a newer device showing mod15write; however, the
reported behavior is highly consistent and other factors which could
contribute seem to have been verified well enough. Also, both
sata_sil itself and the drive are fairly outdated at this point making
the risk of this change fairly low. It is possible, probably likely,
that other drive models in the same family have the same problem;
however, for now, let's just add the specific model which was tested.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: matson <lists-matsonpa@luxsci.me>
References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 352ab492b2d49e663c780a6fdf07e44feec07cc9
Author: Denis V. Lunev <den@openvz.org>
Date: Thu Jan 30 15:20:30 2014 +0400
ata: enable quirk from jmicron JMB350 for JMB394
commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.
Without the patch the kernel generates the following error.
ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
ata11.15: PMP revalidation failed (errno=-19)
ata11.15: failed to recover PMP after 5 tries, giving up
This patch helps to bypass this error and the device becomes
functional.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: <linux-ide@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ae614b0adc5b1fb773a8d33f155b9534c242ed7a
Author: Peter Zijlstra <peterz@infradead.org>
Date: Fri Feb 21 16:03:12 2014 +0100
perf/x86: Fix event scheduling
commit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream.
Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
with perf WARN_ON()s triggering. He also provided traces of the failures.
This is I think the relevant bit:
> pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_disable: x86_pmu_disable
> pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_state: Events: {
> pec_1076_warn-2804 [000] d... 147.926156: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null))
> pec_1076_warn-2804 [000] d... 147.926158: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926159: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1
> pec_1076_warn-2804 [000] d... 147.926161: x86_pmu_state: Assignment: {
> pec_1076_warn-2804 [000] d... 147.926162: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926163: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926166: collect_events: Adding event: 1 (ffff880119ec8800)
So we add the insn:p event (fd[23]).
At this point we should have:
n_events = 2, n_added = 1, n_txn = 1
> pec_1076_warn-2804 [000] d... 147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)
> pec_1076_warn-2804 [000] d... 147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)
We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
that's not visible.
group_sched_in()
pmu->start_txn() /* nop - BP pmu */
event_sched_in()
event->pmu->add()
So here we should end up with:
0: n_events = 3, n_added = 2, n_txn = 2
4: n_events = 4, n_added = 3, n_txn = 3
But seeing the below state on x86_pmu_enable(), the must have failed,
because the 0 and 4 events aren't there anymore.
Looking at group_sched_in(), since the BP is the leader, its
event_sched_in() must have succeeded, for otherwise we would not have
seen the sibling adds.
But since neither 0 or 4 are in the below state; their event_sched_in()
must have failed; but I don't see why, the complete state: 0,0,1:p,4
fits perfectly fine on a core2.
However, since we try and schedule 4 it means the 0 event must have
succeeded! Therefore the 4 event must have failed, its failure will
have put group_sched_in() into the fail path, which will call:
event_sched_out()
event->pmu->del()
on 0 and the BP event.
Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
giving what we see below:
n_event = 2, n_added = 2, n_txn = 2
> pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_enable: x86_pmu_enable
> pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_state: Events: {
> pec_1076_warn-2804 [000] d... 147.926179: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null))
> pec_1076_warn-2804 [000] d... 147.926181: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926182: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2
> pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: Assignment: {
> pec_1076_warn-2804 [000] d... 147.926186: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800)
> pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: 1->0 tag: 1 config: 1 (ffff880119ec8800)
> pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: }
> pec_1076_warn-2804 [000] d... 147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0
So the problem is that x86_pmu_del(), when called from a
group_sched_in() that fails (for whatever reason), and without x86_pmu
TXN support (because the leader is !x86_pmu), will corrupt the n_added
state.
Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Dave Jones <davej@redhat.com>
Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f584e7ec1931dad298df512ec6a61a948d2a5e9
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Mon Feb 10 14:09:48 2014 -0300
perf trace: Fix ioctl 'request' beautifier build problems on !(i386 || x86_64) arches
commit 844ae5b46c08dbc7ba695b543c023f9cf3bbf9ff upstream.
Supporting decoding the ioctl 'request' parameter needs more work to
properly support more architectures, the current approach doesn't work
on at least powerpc and sparc, as reported by Ben Hutchings in
http://lkml.kernel.org/r/1391593985.3003.48.camel@deadeye.wl.decadent.org.uk .
Work around that by making it to be ifdefed for the architectures known
to work with the current, limited approach, i386 and x86_64 till better
code is written.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-ss04k11insqlu329xh5g02q0@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8e7b7d390418575c4754383a3ef66bafe46bd5a5
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Fri Jan 24 14:49:58 2014 +0100
x86: dma-mapping: fix GFP_ATOMIC macro usage
commit c091c71ad2218fc50a07b3d1dab85783f3b77efd upstream.
GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
flags, where meaningful is the LACK of __GFP_WAIT flag. To check if caller
wants to perform an atomic allocation, the code must test for a lack of the
__GFP_WAIT flag. This patch fixes the issue introduced in v3.5-rc1.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e9952c7a1f7640ec71e423d5a374245b63fd6e91
Author: Levente Kurusa <levex@linux.com>
Date: Tue Feb 18 10:22:17 2014 -0500
ahci: disable NCQ on Samsung pci-e SSDs on macbooks
commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.
Samsung's pci-e SSDs with device ID 0x1600 which are found on some
macbooks time out on NCQ commands. Blacklist NCQ on the device so
that the affected machines can at least boot.
Original-patch-by: Levente Kurusa <levex@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a526d9e7e39bf6edd14cfcfa5ea7e863a94742c
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Feb 28 16:20:38 2014 +1100
powerpc/powernv: Fix indirect XSCOM unmangling
commit e0cf957614976896111e676e5134ac98ee227d3d upstream.
We need to unmangle the full address, not just the register
number, and we also need to support the real indirect bit
being set for in-kernel uses.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ccd6c7ee279b4b7dc092bb9a9eb2dff35c34e16
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Feb 28 16:20:29 2014 +1100
powerpc/powernv: Fix opal_xscom_{read,write} prototype
commit 2f3f38e4d3d03dd4125cc9a1f49ab3cc91d8d670 upstream.
The OPAL firmware functions opal_xscom_read and opal_xscom_write
take a 64-bit argument for the XSCOM (PCB) address in order to
support the indirect mode on P8.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 64200db15c9b9e85970891fcbebabe525f9faf7b
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date: Mon Feb 24 17:30:55 2014 +0100
powerpc/crashdump : Fix page frame number check in copy_oldmem_page
commit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream.
In copy_oldmem_page, the current check using max_pfn and min_low_pfn to
decide if the page is backed or not, is not valid when the memory layout is
not continuous.
This happens when running as a QEMU/KVM guest, where RTAS is mapped higher
in the memory. In that case max_pfn points to the end of RTAS, and a hole
between the end of the kdump kernel and RTAS is not backed by PTEs. As a
consequence, the kdump kernel is crashing in copy_oldmem_page when accessing
in a direct way the pages in that hole.
This fix relies on the memblock's service memblock_is_region_memory to
check if the read page is part or not of the directly accessible memory.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26e0d6e26f1b45d819e1d95133eb21147488d7f9
Author: Tony Breeds <tony@bakeyournoodle.com>
Date: Thu Feb 20 21:13:52 2014 +1100
powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly
commit 41dd03a94c7d408d2ef32530545097f7d1befe5c upstream.
Currently we're storing a host endian RTAS token in
rtas_stop_self_args.token. We then pass that directly to rtas. This is
fine on big endian however on little endian the token is not what we
expect.
This will typically result in hitting:
panic("Alas, I survived.\n");
To fix this we always use the stop-self token in host order and always
convert it to be32 before passing this to rtas.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a5a6c18386c6c56081e54ea0faf7a4cd6256cd4e
Author: Paul Mackerras <paulus@samba.org>
Date: Wed Feb 26 17:07:38 2014 +1100
powerpc: Increase stack redzone for 64-bit userspace to 512 bytes
commit 573ebfa6601fa58b439e7f15828762839ccd306a upstream.
The new ELFv2 little-endian ABI increases the stack redzone -- the
area below the stack pointer that can be used for storing data --
from 288 bytes to 512 bytes. This means that we need to allow more
space on the user stack when delivering a signal to a 64-bit process.
To make the code a bit clearer, we define new USER_REDZONE_SIZE and
KERNEL_REDZONE_SIZE symbols in ptrace.h. For now, we leave the
kernel redzone size at 288 bytes, since increasing it to 512 bytes
would increase the size of interrupt stack frames correspondingly.
Gcc currently only makes use of 288 bytes of redzone even when
compiling for the new little-endian ABI, and the kernel cannot
currently be compiled with the new ABI anyway.
In the future, hopefully gcc will provide an option to control the
amount of redzone used, and then we could reduce it even more.
This also changes the code in arch_compat_alloc_user_space() to
preserve the expanded redzone. It is not clear why this function would
ever be used on a 64-bit process, though.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 620ec68c41ae63b88b8671e2032c60bfc5f9f612
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Sun Feb 16 12:14:13 2014 -0500
SUNRPC: Ensure that gss_auth isn't freed before its upcall messages
commit 9eb2ddb48ce3a7bd745c14a933112994647fa3cd upstream.
Fix a race in which the RPC client is shutting down while the
gss daemon is processing a downcall. If the RPC client manages to
shut down before the gss daemon is done, then the struct gss_auth
used in gss_release_msg() may have already been freed.
Link: http://lkml.kernel.org/r/1392494917.71728.YahooMailNeo@web140002.mail.bf1.yahoo.com
Reported-by: John <da_audiophile@yahoo.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a57401ef4a206089f2e075be65ca55b21c3ae209
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Tue Feb 11 09:15:54 2014 -0500
SUNRPC: Fix races in xs_nospace()
commit 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 upstream.
When a send failure occurs due to the socket being out of buffer space,
we call xs_nospace() in order to have the RPC task wait until the
socket has drained enough to make it worth while trying again.
The current patch fixes a race in which the socket is drained before
we get round to setting up the machinery in xs_nospace(), and which
is reported to cause hangs.
Link: http://lkml.kernel.org/r/20140210170315.33dfc621@notabene.brown
Fixes: a9a6b52ee1ba (SUNRPC: Don't start the retransmission timer...)
Reported-by: Neil Brown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89fe406b29aeeb32f7ff2116f084879f48bf19ce
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Sat Feb 22 18:30:13 2014 +0100
ASoC: wm8958-dsp: Fix firmware block loading
commit 548da08fc1e245faf9b0d7c41ecd8e07984fc332 upstream.
The codec->control_data contains a pointer to the device's regmap struct. But
wm8994_bulk_write() expects a pointer to the parent wm8998 device.
The issue was introduced in commit d9a7666f ("ASoC: Remove ASoC-specific
WM8994 I/O code").
Fixes: d9a7666f ("ASoC: Remove ASoC-specific WM8994 I/O code")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 580a25104088f51b44ea7fcebc2384fec647418b
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Feb 18 09:24:12 2014 +0100
ASoC: sta32x: Fix array access overflow
commit 025c3fa9256d4c54506b7a29dc3befac54f5c68d upstream.
Preset EQ enum of sta32x codec driver declares too many number of
items and it may lead to the access over the actual array size.
Use SOC_ENUM_SINGLE_DECL() helper and it's automatically fixed.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6c7dcbc2e23718b8e7990b17dbde92e9cf3ae63
Author: Takashi Iwai <tiwai@suse.de>
Date: Thu Feb 27 07:41:32 2014 +0100
ASoC: sta32x: Fix wrong enum for limiter2 release rate
commit b3619b288b621e63f66908045f48495869a996a6 upstream.
There is a typo in the Limiter2 Release Rate control, a wrong enum for
Limiter1 is assigned. It must point to Limiter2.
Spotted by a compile warning:
In file included from sound/soc/codecs/sta32x.c:34:0:
sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]
static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
^
include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’
struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
^
sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’
static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
^
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a44aeef0eb33442f7908755a26df3ffca5cdf87b
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Sat Feb 22 18:27:17 2014 +0100
ASoC: sta32x: Fix cache sync
commit 70ff00f82a6af0ff68f8f7b411738634ce2f20d0 upstream.
codec->control_data contains a pointer to the regmap struct of the device, not
to the device private data. Use snd_soc_codec_get_drvdata() instead.
The issue was introduced in commit 29fdf4fbbe ("ASoC: sta32x: Convert to
regmap").
Fixes: 29fdf4fbbe (ASoC: sta32x: Convert to regmap)
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e884073b0cec6548af1ade10682fd896af783510
Author: Mark Brown <broonie@linaro.org>
Date: Mon Feb 24 11:59:14 2014 +0900
ASoC: da732x: Mark DC offset control registers volatile
commit 75306820248e26d15d84acf4e297b9fb27dd3bb2 upstream.
The driver reads from the DC offset control registers during callibration
but since the registers are marked as volatile and there is a register
cache the values will not be read from the hardware after the first reading
rendering the callibration ineffective.
It appears that the driver was originally written for the ASoC level
register I/O code but converted to regmap prior to merge and this issue
was missed during the conversion as the framework level volatile register
functionality was not being used.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 10918de3e12ffc283367d1474fe7c6ad707212d3
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Feb 18 09:37:30 2014 +0100
ASoC: wm8770: Fix wrong number of enum items
commit 7a6c0a58dc824523966f212c76322d47c5b0e6fe upstream.
wm8770 codec driver defines ain_enum with a wrong number of items.
Use SOC_ENUM_DOUBLE_DECL() macro and it's automatically fixed.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 315881c8c00b4beee81ba1ca838c45f561894ec0
Author: Dylan Reid <dgreid@chromium.org>
Date: Wed Feb 12 10:24:54 2014 -0800
ASoC: max98090: sync regcache on entering STANDBY
commit c42c8922c46d33ed769e99618bdfba06866a0c72 upstream.
Sync regcache when entering STANDBY from OFF. ON isn't entered with
OFF as the current state, so the registers were not being re-synced
after suspend/resume.
The 98088 and 98095 already call regcache_sync from STANDBY.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a3433570cb91d5e4d276f9f7e9820a77e4331a7
Author: Shawn Guo <shawn.guo@linaro.org>
Date: Sat Feb 8 13:20:35 2014 +0800
ASoC: fsl: fix pm support of machine drivers
commit 47cf84e17ebb79a20e6244b954c4ea4e18a82d43 upstream.
The commit 1abe729 (ASoC: fsl: Add missing pm to current machine
drivers) enables pm support for a few IMX machine drivers. But it does
not update dev drvdata to be the pointer to 'card'. This causes the
kernel dump below in system suspend, because snd_soc_suspend() expects
that the dev drvdata points to 'card', while it still points to the
private data of machine driver.
This patch fixes imx-sgtl5000 and imx-wm8962 by attaching 'card' to dev
drvdata and private data to card drvdata. For imx-mc13783, I simply
revert the pm change because it must be broken for the same reason and
I don't have hardware to test pm enabling code.
$ echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc1: card e624 removed
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
PM: Entering mem sleep
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1861 Comm: bash Not tainted 3.14.0-rc1+ #1648
Backtrace:
[<80012144>] (dump_backtrace) from [<800122e4>] (show_stack+0x18/0x1c)
r6:8079c77c r5:00000c5a r4:00000000 r3:00000000
[<800122cc>] (show_stack) from [<80637ac0>] (dump_stack+0x78/0x94)
[<80637a48>] (dump_stack) from [<80028918>] (warn_slowpath_common+0x6c/0x8c)
r4:bdb21c38 r3:be62df00
[<800288ac>] (warn_slowpath_common) from [<800289dc>] (warn_slowpath_fmt+0x38/0x40)
r8:be62e3a8 r7:bf122960 r6:00000005 r5:00000000 r4:00000000
[<800289a8>] (warn_slowpath_fmt) from [<8006518c>] (__lock_acquire+0x1ae0/0x1ce0)
r3:8079d598 r2:80799e70
[<800636ac>] (__lock_acquire) from [<80065894>] (lock_acquire+0x68/0x7c)
r10:bdb20000 r9:be62df00 r8:00000000 r7:00000000 r6:60000013 r5:bdb20000
r4:00000000
[<8006582c>] (lock_acquire) from [<8063c938>] (mutex_lock_nested+0x5c/0x3b8)
r7:00000000 r6:80dfc78c r5:804be444 r4:bf122928
[<8063c8dc>] (mutex_lock_nested) from [<804be444>] (snd_soc_suspend+0x34/0x42c)
r10:00000000 r9:00000000 r8:00000000 r7:bf1c4444 r6:bf1c4410 r5:be978150
r4:be978010
[<804be410>] (snd_soc_suspend) from [<8034392c>] (platform_pm_suspend+0x34/0x64)
r10:00000000 r8:00000000 r7:bf1c4444 r6:bf1c4410 r5:803438f8 r4:bf1c4410
[<803438f8>] (platform_pm_suspend) from [<80348e18>] (dpm_run_callback.isra.7+0x34/0x6c)
[<80348de4>] (dpm_run_callback.isra.7) from [<80349354>] (__device_suspend+0x10c/0x220)
r9:808dd974 r8:808c4a5c r6:00000002 r5:80e5001c r4:bf1c4410
[<80349248>] (__device_suspend) from [<8034a338>] (dpm_suspend+0x60/0x220)
r7:bf1c4410 r6:808dd90c r5:80e5001c r4:bf1c44c0
[<8034a2d8>] (dpm_suspend) from [<8034a790>] (dpm_suspend_start+0x60/0x68)
r10:8079a818 r9:00000000 r8:00000004 r7:80dfbe90 r6:80641eec r5:00000000
r4:00000002
[<8034a730>] (dpm_suspend_start) from [<8006a788>] (suspend_devices_and_enter+0x74/0x318)
r4:00000003 r3:80dfbe98
[<8006a714>] (suspend_devices_and_enter) from [<8006abd8>] (pm_suspend+0x1ac/0x244)
r10:8079a818 r8:00000004 r7:00000003 r6:80641eec r5:00000000 r4:00000003
[<8006aa2c>] (pm_suspend) from [<80069a4c>] (state_store+0x70/0xc0)
r5:00000003 r4:bd85ea40
[<800699dc>] (state_store) from [<80294034>] (kobj_attr_store+0x1c/0x28)
r10:beb9fe08 r8:00000000 r7:bdb21f78 r6:bd85ea40 r5:00000004 r4:beb9fe00
[<80294018>] (kobj_attr_store) from [<80140f90>] (sysfs_kf_write+0x54/0x58)
[<80140f3c>] (sysfs_kf_write) from [<8014474c>] (kernfs_fop_write+0xc4/0x160)
r6:bd85ea40 r5:beb9fe00 r4:00000004 r3:80140f3c
[<80144688>] (kernfs_fop_write) from [<800dfa14>] (vfs_write+0xbc/0x184)
r10:00000000 r9:00000000 r8:00000000 r7:bdb21f78 r6:00500c08 r5:00000004
r4:be782600
[<800df958>] (vfs_write) from [<800dfe00>] (SyS_write+0x48/0x70)
r10:00000000 r8:00000000 r7:00000004 r6:00500c08 r5:00000000 r4:be782600
[<800dfdb8>] (SyS_write) from [<8000e800>] (ret_fast_syscall+0x0/0x48)
r9:bdb20000 r8:8000e9c4 r7:00000004 r6:00500c08 r5:00000004 r4:76eb65e0
Fixes: 1abe729 (ASoC: fsl: Add missing pm to current machine drivers)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa4d50b2100cf719f4dddc6d59f86fcf841975b6
Author: Alexander Shiyan <shc_work@mail.ru>
Date: Sat Feb 15 23:28:29 2014 +0400
ASoC: txx9aclc_ac97: Fix kernel crash on probe
commit 9febd494d15c4a351e9c9cae7184643144eea892 upstream.
This patch fixes a crash caused by commit 3bed3344c826
(ASoC: txx9aclc_ac97: Convert to devm_ioremap_resource()).
This is an attempt to assign "drvdata->base" while memory
for "drvdata" is not already allocated.
Fixes: 3bed3344c826 (ASoC: txx9aclc_ac97: Convert to devm_ioremap_resource())
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6699503037312c454cceb1397f6357347d81fa56
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date: Fri Feb 7 09:35:16 2014 +0200
ASoC: rt5640: Add ACPI ID for Intel Baytrail
commit b31b2b6d5de71c569413d8dc4f7b050cbe25a09e upstream.
Realtek RT5640 uses ACPI ID "10EC5640" for Intel Baytrail platforms.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0d6c7a1291ec99db200f7c74b1d000f2f1b5198
Author: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Date: Thu Feb 6 18:03:07 2014 +0000
ASoC: da9055: Fix device registration of PMIC and CODEC devices
commit 07b0e5b10258b48e5edfb6c8ac156f05510eb775 upstream.
Currently the I2C device Ids conflict for the MFD and CODEC so
cannot be both instantiated on one platform. This patch updates
the Ids and names to make them unique from each other.
It should be noted that the I2C addresses for both PMIC and CODEC
are modifiable so instantiation of the two are kept as separate
devices, rather than instantiating the CODEC from the MFD code.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Acked-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92cb6f3c5533832aa70a7dc9326ef21270169583
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu Feb 27 22:54:11 2014 +0100
kvm, vmx: Really fix lazy FPU on nested guest
commit 1b385cbdd74aa803e966e01e5fe49490d6044e30 upstream.
Commit e504c9098ed6 (kvm, vmx: Fix lazy FPU on nested guest, 2013-11-13)
highlighted a real problem, but the fix was subtly wrong.
nested_read_cr0 is the CR0 as read by L2, but here we want to look at
the CR0 value reflecting L1's setup. In other words, L2 might think
that TS=0 (so nested_read_cr0 has the bit clear); but if L1 is actually
running it with TS=1, we should inject the fault into L1.
The effective value of CR0 in L2 is contained in vmcs12->guest_cr0, use
it.
Fixes: e504c9098ed6acd9e1079c5e10e4910724ad429f
Reported-by: Kashyap Chamarty <kchamart@redhat.com>
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Tested-by: Kashyap Chamarty <kchamart@redhat.com>
Tested-by: Anthoine Bourgeois <bourgeois@bertin.fr>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74e1995da649f4669741dbb19cf5cffa5690a241
Author: Andrew Honig <ahonig@google.com>
Date: Thu Feb 27 19:35:14 2014 +0100
kvm: x86: fix emulator buffer overflow (CVE-2014-0049)
commit a08d3b3b99efd509133946056531cdf8f3a0c09b upstream.
The problem occurs when the guest performs a pusha with the stack
address pointing to an mmio address (or an invalid guest physical
address) to start with, but then extending into an ordinary guest
physical address. When doing repeated emulated pushes
emulator_read_write sets mmio_needed to 1 on the first one. On a
later push when the stack points to regular memory,
mmio_nr_fragments is set to 0, but mmio_is_needed is not set to 0.
As a result, KVM exits to userspace, and then returns to
complete_emulated_mmio. In complete_emulated_mmio
vcpu->mmio_cur_fragment is incremented. The termination condition of
vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments is never achieved.
The code bounces back and fourth to userspace incrementing
mmio_cur_fragment past it's buffer. If the guest does nothing else it
eventually leads to a a crash on a memcpy from invalid memory address.
However if a guest code can cause the vm to be destroyed in another
vcpu with excellent timing, then kvm_clear_async_pf_completion_queue
can be used by the guest to control the data that's pointed to by the
call to cancel_work_item, which can be used to gain execution.
Fixes: f78146b0f9230765c6315b2e14f56112513389ad
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 19d23c2d3828f46adc452a241cafee5178108ff6
Author: Johannes Berg <johannes.berg@intel.com>
Date: Thu Jan 16 10:18:48 2014 +1030
export: declare ksymtab symbols
commit 7b4ec8dd7d4ac467e9eee4d49f2c9574d773efbb upstream.
sparse complains about any __ksymtab symbols with the following:
warning: symbol '__ksymtab_...' was not declared. Should it be static?
due to Andi's patch making it non-static.
Mollify sparse by declaring the symbol extern, otherwise we get
drowned in sparse warnings for anything that uses EXPORT_SYMBOL
in the sources, making it easy to miss real warnings.
Fixes: e0f244c63fc9 ("asmlinkage, module: Make ksymtab [...] __visible")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74cec318204436d76d9407c8b17792fdb33b4891
Author: Christoph Hellwig <hch@infradead.org>
Date: Tue Nov 19 07:17:07 2013 -0800
fs: fix iversion handling
commit dff6efc326a4d5f305797d4a6bba14f374fdd633 upstream.
Currently notify_change directly updates i_version for size updates,
which not only is counter to how all other fields are updated through
struct iattr, but also breaks XFS, which need inode updates to happen
under its own lock, and synchronized to the structure that gets written
to the log.
Remove the update in the common code, and it to btrfs and ext4,
XFS already does a proper updaste internally and currently gets a
double update with the existing code.
IMHO this is 3.13 and -stable material and should go in through the XFS
tree.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Acked-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 432564bca7e73404311b231c864f41c2f6921f9e
Author: Tejun Heo <tj@kernel.org>
Date: Thu Feb 13 13:29:31 2014 -0500
cgroup: update cgroup_enable_task_cg_lists() to grab siglock
commit 532de3fc72adc2a6525c4d53c07bf81e1732083d upstream.
Currently, there's nothing preventing cgroup_enable_task_cg_lists()
from missing set PF_EXITING and race against cgroup_exit(). Depending
on the timing, cgroup_exit() may finish with the task still linked on
css_set leading to list corruption. Fix it by grabbing siglock in
cgroup_enable_task_cg_lists() so that PF_EXITING is guaranteed to be
visible.
This whole on-demand cg_list optimization is extremely fragile and has
ample possibility to lead to bugs which can cause things like
once-a-year oops during boot. I'm wondering whether the better
approach would be just adding "cgroup_disable=all" handling which
disables the whole cgroup rather than tempting fate with this
on-demand craziness.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c9c65d3ea1f5e1b06d513b9acb7e3235aff4afe
Author: Tejun Heo <tj@kernel.org>
Date: Sat Feb 8 10:26:34 2014 -0500
cgroup: fix locking in cgroup_cfts_commit()
commit 48573a893303986e3b0b2974d6fb11f3d1bb7064 upstream.
cgroup_cfts_commit() walks the cgroup hierarchy that the target
subsystem is attached to and tries to apply the file changes. Due to
the convolution with inode locking, it can't keep cgroup_mutex locked
while iterating. It currently holds only RCU read lock around the
actual iteration and then pins the found cgroup using dget().
Unfortunately, this is incorrect. Although the iteration does check
cgroup_is_dead() before invoking dget(), there's nothing which
prevents the dentry from going away inbetween. Note that this is
different from the usual css iterations where css_tryget() is used to
pin the css - css_tryget() tests whether the css can be pinned and
fails if not.
The problem can be solved by simply holding cgroup_mutex instead of
RCU read lock around the iteration, which actually reduces LOC.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a68fc0c2390d7a9da761733976bef093e9ae7e11
Author: Tejun Heo <tj@kernel.org>
Date: Sat Feb 8 10:26:33 2014 -0500
cgroup: fix error return from cgroup_create()
commit b58c89986a77a23658682a100eb15d8edb571ebb upstream.
cgroup_create() was returning 0 after allocation failures. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 95efbc257ea4f14c5b034f95ca1b3e6f64d933fa
Author: Tejun Heo <tj@kernel.org>
Date: Sat Feb 8 10:26:33 2014 -0500
cgroup: fix error return value in cgroup_mount()
commit eb46bf89696972b856a9adb6aebd5c7b65c266e4 upstream.
When cgroup_mount() fails to allocate an id for the root, it didn't
set ret before jumping to unlock_drop ending up returning 0 after a
failure. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3a9c76c8381acf8a9e5a78c83a794a840bd99d2e
Author: Hui Wang <hui.wang@canonical.com>
Date: Thu Feb 20 11:47:21 2014 +0800
ALSA: hda - Enable front audio jacks on one HP desktop model
commit 1de7ca5e844866f56bebb2fc47fa18e090677e88 upstream.
The front headphone and mic jackes on a HP desktop model (Vendor Id:
0x111d76c7 Subsystem Id: 0x103c2b17) can not work, the codec on this
machine has 8 physical ports, 6 of them are routed to rear jackes
and all of them work very well, while the remaining 2 ports are
routed to front headphone and mic jackes, but the corresponding
pin complex node are not defined correctly.
After apply this fix, the front audio jackes can work very well.
[trivial fix of enum definition by tiwai]
BugLink: https://bugs.launchpad.net/bugs/1282369
Cc: David Henningsson <david.henningsson@canonical.com>
Tested-by: Gerald Yang <gerald.yang@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ac700916405596cba84a4dd4a54610113b44fd4
Author: Hsin-Yu Chao <hychao@chromium.org>
Date: Wed Feb 19 14:30:35 2014 +0800
ALSA: hda/ca0132 - Fix recording from mode id 0x8
commit 13c12dbe3a2ce17227f7ddef652b6a53c78fa51f upstream.
Incorrect ADC is picked in ca0132_capture_pcm_prepare(),
where it assumes multiple streams while there is one stream
per ADC. Note that ca0132_capture_pcm_cleanup() already does
the right thing.
The Chromebook Pixel has a microphone under the keyboard that
is attached to node id 0x8. Before this fix, recording would
always go to the main internal mic (node id 0x7).
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aadc0119249f49d07b8adc9df181ec0e2f495cd1
Author: Hsin-Yu Chao <hychao@chromium.org>
Date: Wed Feb 19 14:27:07 2014 +0800
ALSA: hda/ca0132 - setup/cleanup streams
commit 28fba95087a7f3d107a3a6728aef7dbfaf3fd782 upstream.
When a HDMI stream is opened with the same stream tag
as a following opened stream to ca0132, audio will be
heard from two ports simultaneously.
Fix this issue by change to use snd_hda_codec_setup_stream
and snd_hda_codec_cleanup_stream instead, so that an
inactive stream can be marked as 'dirty' when found
with a conflict stream tag, and then get purified.
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1862d8b913b4f7117e2896ff0c6ccba9481114f3
Author: Hui Wang <hui.wang@canonical.com>
Date: Tue Feb 18 10:56:46 2014 +0800
ALSA: hda - add headset mic detect quirks for two Dell laptops
commit 4913e0bf239dafee356bc7fab61806cc2518930c upstream.
When we plug a 3-ring headset on the Dell machines (Vendor ID:
0x10ec0255, Subsystem ID: 0x10280657; Vendor ID: 0x10ec0255,
Subsystem ID: 0x1028065f), the headset mic can't be
detected, after apply this patch, the headset mic can work well.
BugLink: https://bugs.launchpad.net/bugs/1260303
Cc: David Henningsson <david.henningsson@canonical.com>
Tested-by: Cyrus Lien <cyrus.lien@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 906e84cad1d9fe792ee9fd3a5b741b0a27441a7d
Author: Clemens Ladisch <clemens@ladisch.de>
Date: Sun Feb 16 17:11:10 2014 +0100
ALSA: usb-audio: work around KEF X300A firmware bug
commit 624aef494f86ed0c58056361c06347ad62b26806 upstream.
When the driver tries to access Function Unit 10, the KEF X300A
speakers' firmware apparently locks up, making even PCM streaming
impossible. Work around this by ignoring this FU.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 944734c3d3554e6776f7c5a570abb572492e3988
Author: Antonio Quartulli <antonio@meshcoding.com>
Date: Sat Feb 15 21:50:37 2014 +0100
batman-adv: fix potential kernel paging error for unicast transmissions
[ Upstream commit 70b271a78beba787155d6696aacd7c4d4a251c50 ]
batadv_send_skb_prepare_unicast(_4addr) might reallocate the
skb's data. If it does then our ethhdr pointer is not valid
anymore in batadv_send_skb_unicast(), resulting in a kernel
paging error.
Fixing this by refetching the ethhdr pointer after the
potential reallocation.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3bf167762750638933cfbca080e46fdc00374b11
Author: Antonio Quartulli <antonio@meshcoding.com>
Date: Sat Feb 15 02:17:20 2014 +0100
batman-adv: avoid double free when orig_node initialization fails
[ Upstream commit a5a5cb8cab526af2f6cbe9715f8ca843192f0d81 ]
In the failure path of the orig_node initialization routine
the orig_node->bat_iv.bcast_own field is free'd twice: first
in batadv_iv_ogm_orig_get() and then later in
batadv_orig_node_free_rcu().
Fix it by removing the kfree in batadv_iv_ogm_orig_get().
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d74be7ef96bd38e40a3b19f431fc0e696249bed8
Author: Antonio Quartulli <antonio@open-mesh.com>
Date: Tue Feb 11 17:05:07 2014 +0100
batman-adv: free skb on TVLV parsing success
[ Upstream commit 05c3c8a636aa9ee35ce13f65afc5b665615cc786 ]
When the TVLV parsing routine succeed the skb is left
untouched thus leading to a memory leak.
Fix this by consuming the skb in case of success.
Introduced by ef26157747d42254453f6b3ac2bd8bd3c53339c3
("batman-adv: tvlv - basic infrastructure")
Reported-by: Russel Senior <russell@personaltelco.net>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Tested-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 176890fa4f29c7dbbbe6a6d5eb761d8c064c1efa
Author: Antonio Quartulli <antonio@open-mesh.com>
Date: Tue Feb 11 17:05:06 2014 +0100
batman-adv: fix TT CRC computation by ensuring byte order
[ Upstream commit a30e22ca8464c2dc573e0144a972221c2f06c2cd ]
When computing the CRC on a 2byte variable the order of
the bytes obviously alters the final result. This means
that computing the CRC over the same value on two archs
having different endianess leads to different numbers.
The global and local translation table CRC computation
routine makes this mistake while processing the clients
VIDs. The result is a continuous CRC mismatching between
nodes having different endianess.
Fix this by converting the VID to Network Order before
processing it. This guarantees that every node uses the same
byte order.
Introduced by 7ea7b4a142758deaf46c1af0ca9ceca6dd55138b
("batman-adv: make the TT CRC logic VLAN specific")
Reported-by: Russel Senior <russell@personaltelco.net>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Tested-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 456252dff8921cbd59a6ccd88016d49130d974ba
Author: Simon Wunderlich <sw@simonwunderlich.de>
Date: Sat Feb 8 16:45:06 2014 +0100
batman-adv: fix potential orig_node reference leak
[ Upstream commit b2262df7fcf2c395eca564df83238e931d88d7bf ]
Since batadv_orig_node_new() sets the refcount to two, assuming that
the calling function will use a reference for putting the orig_node into
a hash or similar, both references must be freed if initialization of
the orig_node fails. Otherwise that object may be leaked in that error
case.
Reported-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 45756c3dfa56ecc4a1f813d1051d9944f538153d
Author: Antonio Quartulli <antonio@open-mesh.com>
Date: Wed Jan 29 11:25:12 2014 +0100
batman-adv: avoid potential race condition when adding a new neighbour
[ Upstream commit 08bf0ed29c7ded45c477d08618220dd200c3524a ]
When adding a new neighbour it is important to atomically
perform the following:
- check if the neighbour already exists
- append the neighbour to the proper list
If the two operations are not performed in an atomic context
it is possible that two concurrent insertions add the same
neighbour twice.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a2f20aab51e33ee083d5f285275dc8b54f74be4
Author: Antonio Quartulli <antonio@meshcoding.com>
Date: Thu Jan 30 00:12:24 2014 +0100
batman-adv: properly check pskb_may_pull return value
[ Upstream commit f1791425cf0bcda43ab9a9a37df1ad3ccb1f6654 ]
pskb_may_pull() returns 1 on success and 0 in case of failure,
therefore checking for the return value being negative does
not make sense at all.
This way if the function fails we will probably read beyond the current
skb data buffer. Fix this by doing the proper check.
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b6cd79c3db913215ab2f162e58155527895d7f68
Author: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue Jan 28 02:06:47 2014 +0100
batman-adv: release vlan object after checking the CRC
[ Upstream commit 91c2b1a9f680ff105369d49abc7e19ca7efb33e1 ]
There is a refcounter unbalance in the CRC checking routine
invoked on OGM reception. A vlan object is retrieved (thus
its refcounter is increased by one) but it is never properly
released. This leads to a memleak because the vlan object
will never be free'd.
Fix this by releasing the vlan object after having read the
CRC.
Reported-by: Russell Senior <russell@personaltelco.net>
Reported-by: Daniel <daniel@makrotopia.org>
Reported-by: cmsv <cmsv@wirelesspt.net>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 658720abdccb8768b0db2b944b61325a5c5da3b0
Author: Antonio Quartulli <antonio@meshcoding.com>
Date: Mon Jan 27 12:23:28 2014 +0100
batman-adv: fix TT-TVLV parsing on OGM reception
[ Upstream commit e889241f45f9cecbc84a6ffed577083ab52e62ee ]
When accessing a TT-TVLV container in the OGM RX path
the variable pointing to the list of changes to apply is
altered by mistake.
This makes the TT component read data at the wrong position
in the OGM packet buffer.
Fix it by removing the bogus pointer alteration.
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5eaeaa72113865661568002bb57d611492451d3e
Author: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue Jan 21 11:22:05 2014 +0100
batman-adv: fix soft-interface MTU computation
[ Upstream commit 930cd6e46eadce8b8ed2a232ee536e5fd286c152 ]
The current MTU computation always returns a value
smaller than 1500bytes even if the real interfaces
have an MTU large enough to compensate the batman-adv
overhead.
Fix the computation by properly returning the highest
admitted value.
Introduced by a19d3d85e1b854e4a483a55d740a42458085560d
("batman-adv: limit local translation table max size")
Reported-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7f35646d50ad3052697dd29e22ba5be74f4dbcd6
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Feb 6 10:42:42 2014 -0800
net: use __GFP_NORETRY for high order allocations
[ Upstream commit ed98df3361f059db42786c830ea96e2d18b8d4db ]
sock_alloc_send_pskb() & sk_page_frag_refill()
have a loop trying high order allocations to prepare
skb with low number of fragments as this increases performance.
Problem is that under memory pressure/fragmentation, this can
trigger OOM while the intent was only to try the high order
allocations, then fallback to order-0 allocations.
We had various reports from unexpected regressions.
According to David, setting __GFP_NORETRY should be fine,
as the asynchronous compaction is still enabled, and this
will prevent OOM from kicking as in :
CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0,
oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled
CFSClientEventm
Call Trace:
[<ffffffff8043766c>] dump_header+0xe1/0x23e
[<ffffffff80437a02>] oom_kill_process+0x6a/0x323
[<ffffffff80438443>] out_of_memory+0x4b3/0x50d
[<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
[<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
[<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
[<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
[<ffffffff80295fa0>] tcp_sendmsg+0x560/0xee0
[<ffffffff802a5037>] inet_sendmsg+0x67/0x100
[<ffffffff80283c9c>] __sock_sendmsg_nosec+0x6c/0x90
[<ffffffff80283e85>] sock_sendmsg+0xc5/0xf0
[<ffffffff802847b6>] __sys_sendmsg+0x136/0x430
[<ffffffff80284ec8>] sys_sendmsg+0x88/0x110
[<ffffffff80711472>] system_call_fastpath+0x16/0x1b
Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f3a4f701b59a3e4b5c8503ac3d905c0a326f922
Author: willy tarreau <w@1wt.eu>
Date: Thu Jan 16 08:20:11 2014 +0100
net: mvneta: replace Tx timer with a real interrupt
[ Upstream commit 71f6d1b31fb1f278a345a30a2180515adc7d80ae ]
Right now the mvneta driver doesn't handle Tx IRQ, and relies on two
mechanisms to flush Tx descriptors : a flush at the end of mvneta_tx()
and a timer. If a burst of packets is emitted faster than the device
can send them, then the queue is stopped until next wake-up of the
timer 10ms later. This causes jerky output traffic with bursts and
pauses, making it difficult to reach line rate with very few streams.
A test on UDP traffic shows that it's not possible to go beyond 134
Mbps / 12 kpps of outgoing traffic with 1500-bytes IP packets. Routed
traffic tends to observe pauses as well if the traffic is bursty,
making it even burstier after the wake-up.
It seems that this feature was inherited from the original driver but
nothing there mentions any reason for not using the interrupt instead,
which the chip supports.
Thus, this patch enables Tx interrupts and removes the timer. It does
the two at once because it's not really possible to make the two
mechanisms coexist, so a split patch doesn't make sense.
First tests performed on a Mirabox (Armada 370) show that less CPU
seems to be used when sending traffic. One reason might be that we now
call the mvneta_tx_done_gbe() with a mask indicating which queues have
been done instead of looping over all of them.
The same UDP test above now happily reaches 987 Mbps / 87.7 kpps.
Single-stream TCP traffic can now more easily reach line rate. HTTP
transfers of 1 MB objects over a single connection went from 730 to
840 Mbps. It is even possible to go significantly higher (>900 Mbps)
by tweaking tcp_tso_win_divisor.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Arnaud Ebalard <arno@natisbad.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0ce58acf529bacd25dbe01298ff51a5c4d59a4f4
Author: willy tarreau <w@1wt.eu>
Date: Thu Jan 16 08:20:10 2014 +0100
net: mvneta: add missing bit descriptions for interrupt masks and causes
[ Upstream commit 40ba35e74fa56866918d2f3bc0528b5b92725d5e ]
Marvell has not published the chip's datasheet yet, so it's very hard
to find the relevant bits to manipulate to change the IRQ behaviour.
Fortunately, these bits are described in the proprietary LSP patch set
which is publicly available here :
http://www.plugcomputer.org/downloads/mirabox/
So let's put them back in the driver in order to reduce the burden of
current and future maintenance.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c2c9b1efcc4b04b4625d0613b9e74ef17016dea
Author: willy tarreau <w@1wt.eu>
Date: Thu Jan 16 08:20:09 2014 +0100
net: mvneta: do not schedule in mvneta_tx_timeout
[ Upstream commit 290213667ab53a95456397763205e4b1e30f46b5 ]
If a queue timeout is reported, we can oops because of some
schedules while the caller is atomic, as shown below :
mvneta d0070000.ethernet eth0: tx timeout
BUG: scheduling while atomic: bash/1528/0x00000100
Modules linked in: slhttp_ethdiv(C) [last unloaded: slhttp_ethdiv]
CPU: 2 PID: 1528 Comm: bash Tainted: G WC 3.13.0-rc4-mvebu-nf #180
[<c0011bd9>] (unwind_backtrace+0x1/0x98) from [<c000f1ab>] (show_stack+0xb/0xc)
[<c000f1ab>] (show_stack+0xb/0xc) from [<c02ad323>] (dump_stack+0x4f/0x64)
[<c02ad323>] (dump_stack+0x4f/0x64) from [<c02abe67>] (__schedule_bug+0x37/0x4c)
[<c02abe67>] (__schedule_bug+0x37/0x4c) from [<c02ae261>] (__schedule+0x325/0x3ec)
[<c02ae261>] (__schedule+0x325/0x3ec) from [<c02adb97>] (schedule_timeout+0xb7/0x118)
[<c02adb97>] (schedule_timeout+0xb7/0x118) from [<c0020a67>] (msleep+0xf/0x14)
[<c0020a67>] (msleep+0xf/0x14) from [<c01dcbe5>] (mvneta_stop_dev+0x21/0x194)
[<c01dcbe5>] (mvneta_stop_dev+0x21/0x194) from [<c01dcfe9>] (mvneta_tx_timeout+0x19/0x24)
[<c01dcfe9>] (mvneta_tx_timeout+0x19/0x24) from [<c024afc7>] (dev_watchdog+0x18b/0x1c4)
[<c024afc7>] (dev_watchdog+0x18b/0x1c4) from [<c0020b53>] (call_timer_fn.isra.27+0x17/0x5c)
[<c0020b53>] (call_timer_fn.isra.27+0x17/0x5c) from [<c0020cad>] (run_timer_softirq+0x115/0x170)
[<c0020cad>] (run_timer_softirq+0x115/0x170) from [<c001ccb9>] (__do_softirq+0xbd/0x1a8)
[<c001ccb9>] (__do_softirq+0xbd/0x1a8) from [<c001cfad>] (irq_exit+0x61/0x98)
[<c001cfad>] (irq_exit+0x61/0x98) from [<c000d4bf>] (handle_IRQ+0x27/0x60)
[<c000d4bf>] (handle_IRQ+0x27/0x60) from [<c000843b>] (armada_370_xp_handle_irq+0x33/0xc8)
[<c000843b>] (armada_370_xp_handle_irq+0x33/0xc8) from [<c000fba9>] (__irq_usr+0x49/0x60)
Ben Hutchings attempted to propose a better fix consisting in using a
scheduled work for this, but while it fixed this panic, it caused other
random freezes and panics proving that the reset sequence in the driver
is unreliable and that additional fixes should be investigated.
When sending multiple streams over a link limited to 100 Mbps, Tx timeouts
happen from time to time, and the driver correctly recovers only when the
function is disabled.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92817335465090aecfde6caef9bab6923f209664
Author: willy tarreau <w@1wt.eu>
Date: Thu Jan 16 08:20:08 2014 +0100
net: mvneta: use per_cpu stats to fix an SMP lock up
[ Upstream commit 74c41b048db1073a04827d7f39e95ac1935524cc ]
Stats writers are mvneta_rx() and mvneta_tx(). They don't lock anything
when they update the stats, and as a result, it randomly happens that
the stats freeze on SMP if two updates happen during stats retrieval.
This is very easily reproducible by starting two HTTP servers and binding
each of them to a different CPU, then consulting /proc/net/dev in loops
during transfers, the interface should immediately lock up. This issue
also randomly happens upon link state changes during transfers, because
the stats are collected in this situation, but it takes more attempts to
reproduce it.
The comments in netdevice.h suggest using per_cpu stats instead to get
rid of this issue.
This patch implements this. It merges both rx_stats and tx_stats into
a single "stats" member with a single syncp. Both mvneta_rx() and
mvneta_rx() now only update the a single CPU's counters.
In turn, mvneta_get_stats64() does the summing by iterating over all CPUs
to get their respective stats.
With this change, stats are still correct and no more lockup is encountered.
Note that this bug was present since the first import of the mvneta
driver. It might make sense to backport it to some stable trees. If
so, it depends on "d33dc73 net: mvneta: increase the 64-bit rx/tx stats
out of the hot path".
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fbfbed33a5effba7dc6f33e3ed598f9bd31b0cdf
Author: willy tarreau <w@1wt.eu>
Date: Thu Jan 16 08:20:07 2014 +0100
net: mvneta: increase the 64-bit rx/tx stats out of the hot path
[ Upstream commit dc4277dd41a80fd5f29a90412ea04bc3ba54fbf1 ]
Better count packets and bytes in the stack and on 32 bit then
accumulate them at the end for once. This saves two memory writes
and two memory barriers per packet. The incoming packet rate was
increased by 4.7% on the Openblocks AX3 thanks to this.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f7152716d66f5c24327b6a664a4feb4fbd46fc6c
Author: Florian Westphal <fw@strlen.de>
Date: Fri Feb 21 20:46:40 2014 +0100
net: ip, ipv6: handle gso skbs in forwarding path
commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.
Marcelo Ricardo Leitner reported problems when the forwarding link path
has a lower mtu than the incoming one if the inbound interface supports GRO.
Given:
Host <mtu1500> R1 <mtu1200> R2
Host sends tcp stream which is routed via R1 and R2. R1 performs GRO.
In this case, the kernel will fail to send ICMP fragmentation needed
messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu
checks in forward path. Instead, Linux tries to send out packets exceeding
the mtu.
When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does
not fragment the packets when forwarding, and again tries to send out
packets exceeding R1-R2 link mtu.
This alters the forwarding dstmtu checks to take the individual gso
segment lengths into account.
For ipv6, we send out pkt too big error for gso if the individual
segments are too big.
For ipv4, we either send icmp fragmentation needed, or, if the DF bit
is not set, perform software segmentation and let the output path
create fragments when the packet is leaving the machine.
It is not 100% correct as the error message will contain the headers of
the GRO skb instead of the original/segmented one, but it seems to
work fine in my (limited) tests.
Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid
sofware segmentation.
However it turns out that skb_segment() assumes skb nr_frags is related
to mss size so we would BUG there. I don't want to mess with it considering
Herbert and Eric disagree on what the correct behavior should be.
Hannes Frederic Sowa notes that when we would shrink gso_size
skb_segment would then also need to deal with the case where
SKB_MAX_FRAGS would be exceeded.
This uses sofware segmentation in the forward path when we hit ipv4
non-DF packets and the outgoing link mtu is too small. Its not perfect,
but given the lack of bug reports wrt. GRO fwd being broken this is a
rare case anyway. Also its not like this could not be improved later
once the dust settles.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
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>
commit 5a7e57ce36c13e42c4ad2859d87bcb97254903a1
Author: Florian Westphal <fw@strlen.de>
Date: Fri Feb 21 20:46:39 2014 +0100
net: core: introduce netif_skb_dev_features
commit d206940319c41df4299db75ed56142177bb2e5f6 upstream.
Will be used by upcoming ipv4 forward path change that needs to
determine feature mask using skb->dst->dev instead of skb->dev.
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>
commit f92583bf36ab8334baef427cc04ec3dab76d2ec7
Author: Florian Westphal <fw@strlen.de>
Date: Fri Feb 21 20:46:38 2014 +0100
net: add and use skb_gso_transport_seglen()
commit de960aa9ab4decc3304959f69533eef64d05d8e8 upstream.
This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to
skbuff core so it may be reused by upcoming ip forwarding path patch.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 270204513fd9ada5a269e7403c9863591e4209ee
Author: Daniel Borkmann <dborkman@redhat.com>
Date: Mon Feb 17 12:11:11 2014 +0100
net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
[ Upstream commit ffd5939381c609056b33b7585fb05a77b4c695f3 ]
SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
sizeof(param) check will always fail in kernel as the structure in
64bit kernel space is 4bytes larger than for user binaries compiled
in 32bit mode. Thus, applications making use of sctp_connectx() won't
be able to run under such circumstances.
Introduce a compat interface in the kernel to deal with such
situations by using a 'struct compat_sctp_getaddrs_old' structure
where user data is copied into it, and then sucessively transformed
into a 'struct sctp_getaddrs_old' structure with the help of
compat_ptr(). That fixes sctp_connectx() abi without any changes
needed in user space, and lets the SCTP test suite pass when compiled
in 32bit and run on 64bit kernels.
Fixes: f9c67811ebc0 ("sctp: Fix regression introduced by new sctp_connectx api")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0ef00f395c930057eb711af73e39e80daa5d7e09
Author: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Mon Feb 17 15:23:43 2014 +0800
ipv4: fix counter in_slow_tot
[ Upstream commit a6254864c08109c66a194612585afc0439005286 ]
since commit 89aef8921bf("ipv4: Delete routing cache."), the counter
in_slow_tot can't work correctly.
The counter in_slow_tot increase by one when fib_lookup() return successfully
in ip_route_input_slow(), but actually the dst struct maybe not be created and
cached, so we can increase in_slow_tot after the dst struct is created.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bf3885d8a582ba88047f8c681708183185b4ea21
Author: Jiri Bohac <jiri@boha.cz>
Date: Fri Feb 14 18:13:50 2014 +0100
bonding: 802.3ad: make aggregator_identifier bond-private
[ Upstream commit 163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ]
aggregator_identifier is used to assign unique aggregator identifiers
to aggregators of a bond during device enslaving.
aggregator_identifier is currently a global variable that is zeroed in
bond_3ad_initialize().
This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
create bond0
change bond0 mode to 802.3ad
enslave eth0 to bond0 //eth0 gets agg id 1
enslave eth1 to bond0 //eth1 gets agg id 2
create bond1
change bond1 mode to 802.3ad
enslave eth2 to bond1 //aggregator_identifier is reset to 0
//eth2 gets agg id 1
enslave eth3 to bond0 //eth3 gets agg id 2
Fix this by making aggregator_identifier private to the bond.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Acked-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 34bf180bd51daf5ae1f163ffb3cd81872d93c981
Author: Emil Goode <emilgoode@gmail.com>
Date: Thu Feb 13 17:50:19 2014 +0100
usbnet: remove generic hard_header_len check
[ Upstream commit eb85569fe2d06c2fbf4de7b66c263ca095b397aa ]
This patch removes a generic hard_header_len check from the usbnet
module that is causing dropped packages under certain circumstances
for devices that send rx packets that cross urb boundaries.
One example is the AX88772B which occasionally send rx packets that
cross urb boundaries where the remaining partial packet is sent with
no hardware header. When the buffer with a partial packet is of less
number of octets than the value of hard_header_len the buffer is
discarded by the usbnet module.
With AX88772B this can be reproduced by using ping with a packet
size between 1965-1976.
The bug has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=29082
This patch introduces the following changes:
- Removes the generic hard_header_len check in the rx_complete
function in the usbnet module.
- Introduces a ETH_HLEN check for skbs that are not cloned from
within a rx_fixup callback.
- For safety a hard_header_len check is added to each rx_fixup
callback function that could be affected by this change.
These extra checks could possibly be removed by someone
who has the hardware to test.
- Removes a call to dev_kfree_skb_any() and instead utilizes the
dev->done list to queue skbs for cleanup.
The changes place full responsibility on the rx_fixup callback
functions that clone skbs to only pass valid skbs to the
usbnet_skb_return function.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Reported-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 07eb46bc2368898014e075a93a10eb5bff2f8a81
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon Feb 17 14:22:21 2014 +0100
gre: add link local route when local addr is any
[ Upstream commit 08b44656c08c8c2f73cdac2a058be2880e3361f2 ]
This bug was reported by Steinar H. Gunderson and was introduced by commit
f7cb8886335d ("sit/gre6: don't try to add the same route two times").
root@morgental:~# ip tunnel add foo mode gre remote 1.2.3.4 ttl 64
root@morgental:~# ip link set foo up mtu 1468
root@morgental:~# ip -6 route show dev foo
fe80::/64 proto kernel metric 256
but after the above commit, no such route shows up.
There is no link local route because dev->dev_addr is 0 (because local ipv4
address is 0), hence no link local address is configured.
In this scenario, the link local address is added manually: 'ip -6 addr add
fe80::1 dev foo' and because prefix is /128, no link local route is added by the
kernel.
Even if the right things to do is to add the link local address with a /64
prefix, we need to restore the previous behavior to avoid breaking userpace.
Reported-by: Steinar H. Gunderson <sesse@samfundet.no>
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>
commit 7c3b169fc4b4b13f31de8c3af75993ad9ab85deb
Author: Emil Goode <emilgoode@gmail.com>
Date: Thu Feb 13 19:30:39 2014 +0100
net: asix: add missing flag to struct driver_info
[ Upstream commit d43ff4cd798911736fb39025ec8004284b1b0bc2 ]
The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f7b42540d33872efc76660c15912ddfefa3fe10d
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date: Wed Feb 12 16:54:27 2014 -0800
hyperv: Fix the carrier status setting
[ Upstream commit 891de74d693bb4fefe2efcc6432a4a9a9bee561e ]
Without this patch, the "cat /sys/class/net/ethN/operstate" shows
"unknown", and "ethtool ethN" shows "Link detected: yes", when VM
boots up with or without vNIC connected.
This patch fixed the problem.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a946f4c4672a224d17ca4b6a005dc43cf4c2ec74
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Thu Feb 13 11:42:05 2014 +0200
vhost: fix ref cnt checking deadlock
[ Upstream commit 0ad8b480d6ee916aa84324f69acf690142aecd0e ]
vhost checked the counter within the refcnt before decrementing. It
really wanted to know that it is the one that has the last reference, as
a way to batch freeing resources a bit more efficiently.
Note: we only let refcount go to 0 on device release.
This works well but we now access the ref counter twice so there's a
race: all users might see a high count and decide to defer freeing
resources.
In the end no one initiates freeing resources until the last reference
is gone (which is on VM shotdown so might happen after a looooong time).
Let's do what we probably should have done straight away:
switch from kref to plain atomic, documenting the
semantics, return the refcount value atomically after decrement,
then use that to avoid the deadlock.
Reported-by: Qin Chuanyu <qinchuanyu@huawei.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a2e8bb58a0bba9ae82cc087c08dda23e458d7e81
Author: Nithin Sujir <nsujir@broadcom.com>
Date: Thu Feb 6 14:13:05 2014 -0800
tg3: Fix deadlock in tg3_change_mtu()
[ Upstream commit c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ]
Quoting David Vrabel -
"5780 cards cannot have jumbo frames and TSO enabled together. When
jumbo frames are enabled by setting the MTU, the TSO feature must be
cleared. This is done indirectly by calling netdev_update_features()
which will call tg3_fix_features() to actually clear the flags.
netdev_update_features() will also trigger a new netlink message for the
feature change event which will result in a call to tg3_get_stats64()
which deadlocks on the tg3 lock."
tg3_set_mtu() does not need to be under the tg3 lock since converting
the flags to use set_bit(). Move it out to after tg3_netif_stop().
Reported-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cc886b64ce3747858491275d74802f5ed1dc20e8
Author: John Ogness <john.ogness@linutronix.de>
Date: Sun Feb 9 18:40:11 2014 -0800
tcp: tsq: fix nonagle handling
[ Upstream commit bf06200e732de613a1277984bf34d1a21c2de03d ]
Commit 46d3ceabd8d9 ("tcp: TCP Small Queues") introduced a possible
regression for applications using TCP_NODELAY.
If TCP session is throttled because of tsq, we should consult
tp->nonagle when TX completion is done and allow us to send additional
segment, especially if this segment is not a full MSS.
Otherwise this segment is sent after an RTO.
[edumazet] : Cooked the changelog, added another fix about testing
sk_wmem_alloc twice because TX completion can happen right before
setting TSQ_THROTTLED bit.
This problem is particularly visible with recent auto corking,
but might also be triggered with low tcp_limit_output_bytes
values or NIC drivers delaying TX completion by hundred of usec,
and very low rtt.
Thomas Glanzmann for example reported an iscsi regression, caused
by tcp auto corking making this bug quite visible.
Fixes: 46d3ceabd8d9 ("tcp: TCP Small Queues")
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a64ca3bb512275b4db2c1815c1f0834b3625bfa7
Author: Bjørn Mork <bjorn@mork.no>
Date: Tue Feb 4 13:04:33 2014 +0100
net: qmi_wwan: add Netgear Aircard 340U
[ Upstream commit fbd3a77d813f211060f86cc7a2f8416caf0e03b1 ]
This device was mentioned in an OpenWRT forum. Seems to have a "standard"
Sierra Wireless ifnumber to function layout:
0: qcdm
2: nmea
3: modem
8: qmi
9: storage
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5346207333039c82f391f78f17b087762d85225
Author: Sabrina Dubroca <sd@queasysnail.net>
Date: Thu Feb 6 18:34:12 2014 +0100
netpoll: fix netconsole IPv6 setup
[ Upstream commit 00fe11b3c67dc670fe6391d22f1fe64e7c99a8ec ]
Currently, to make netconsole start over IPv6, the source address
needs to be specified. Without a source address, netpoll_parse_options
assumes we're setting up over IPv4 and the destination IPv6 address is
rejected.
Check if the IP version has been forced by a source address before
checking for a version mismatch when parsing the destination address.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
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>
commit 0ef4fe500c79e3741515cff5705761a23cb30998
Author: Maciej Żenczykowski <maze@google.com>
Date: Fri Feb 7 16:23:48 2014 -0800
net: fix 'ip rule' iif/oif device rename
[ Upstream commit 946c032e5a53992ea45e062ecb08670ba39b99e3 ]
ip rules with iif/oif references do not update:
(detach/attach) across interface renames.
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: Willem de Bruijn <willemb@google.com>
CC: Eric Dumazet <edumazet@google.com>
CC: Chris Davis <chrismd@google.com>
CC: Carlo Contavalli <ccontavalli@google.com>
Google-Bug-Id: 12936021
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4ca4b24db196ffa9789ec04cd47b65b567fa34eb
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed Feb 5 08:38:25 2014 +0100
ipv4: Fix runtime WARNING in rtmsg_ifa()
[ Upstream commit 63b5f152eb4a5bb79b9caf7ec37b4201d12f6e66 ]
On m68k/ARAnyM:
WARNING: CPU: 0 PID: 407 at net/ipv4/devinet.c:1599 0x316a99()
Modules linked in:
CPU: 0 PID: 407 Comm: ifconfig Not tainted
3.13.0-atari-09263-g0c71d68014d1 #1378
Stack from 10c4fdf0:
10c4fdf0 002ffabb 000243e8 00000000 008ced6c 00024416 00316a99 0000063f
00316a99 00000009 00000000 002501b4 00316a99 0000063f c0a86117 00000080
c0a86117 00ad0c90 00250a5a 00000014 00ad0c90 00000000 00000000 00000001
00b02dd0 00356594 00000000 00356594 c0a86117 eff6c9e4 008ced6c 00000002
008ced60 0024f9b4 00250b52 00ad0c90 00000000 00000000 00252390 00ad0c90
eff6c9e4 0000004f 00000000 00000000 eff6c9e4 8000e25c eff6c9e4 80001020
Call Trace: [<000243e8>] warn_slowpath_common+0x52/0x6c
[<00024416>] warn_slowpath_null+0x14/0x1a
[<002501b4>] rtmsg_ifa+0xdc/0xf0
[<00250a5a>] __inet_insert_ifa+0xd6/0x1c2
[<0024f9b4>] inet_abc_len+0x0/0x42
[<00250b52>] inet_insert_ifa+0xc/0x12
[<00252390>] devinet_ioctl+0x2ae/0x5d6
Adding some debugging code reveals that net_fill_ifaddr() fails in
put_cacheinfo(skb, ifa->ifa_cstamp, ifa->ifa_tstamp,
preferred, valid))
nla_put complains:
lib/nlattr.c:454: skb_tailroom(skb) = 12, nla_total_size(attrlen) = 20
Apparently commit 5c766d642bcaffd0c2a5b354db2068515b3846cf ("ipv4:
introduce address lifetime") forgot to take into account the addition of
struct ifa_cacheinfo in inet_nlmsg_size(). Hence add it, like is already
done for ipv6.
Suggested-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d708b9d5bdea1eb243b4039d4e6e24e8b2c9dc1
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu Jan 30 10:11:28 2014 +0100
can: add destructor for self generated skbs
[ Upstream commit 0ae89beb283a0db5980d1d4781c7d7be2f2810d6 ]
Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
no explicit destructor which is enforced since Linux 3.11 with commit
376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
This patch adds some helper functions to make sure that a destructor is
properly defined when a sock reference is assigned to a CAN related skb.
To create an unshared skb owned by the original sock a common helper function
has been introduced to replace open coded functions to create CAN echo skbs.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Andre Naujoks <nautsch2@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5b7f6193f5cdde2fbfb5618a051754a60ada7832
Author: Cong Wang <cwang@twopensource.com>
Date: Thu Feb 6 15:00:52 2014 -0800
bridge: fix netconsole setup over bridge
[ Upstream commit dbe173079ab58a444e12dbebe96f5aec1e0bed1a ]
Commit 93d8bf9fb8f3 ("bridge: cleanup netpoll code") introduced
a check in br_netpoll_enable(), but this check is incorrect for
br_netpoll_setup(). This patch moves the code after the check
into __br_netpoll_enable() and calls it in br_netpoll_setup().
For br_add_if(), the check is still needed.
Fixes: 93d8bf9fb8f3 ("bridge: cleanup netpoll code")
Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Tested-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6e03fb49cd231559b20a6ea37853137f592b2ed6
Author: Richard Yao <ryao@gentoo.org>
Date: Sat Feb 8 19:32:01 2014 -0500
9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
[ Upstream commit b6f52ae2f0d32387bde2b89883e3b64d88b9bfe8 ]
The 9p-virtio transport does zero copy on things larger than 1024 bytes
in size. It accomplishes this by returning the physical addresses of
pages to the virtio-pci device. At present, the translation is usually a
bit shift.
That approach produces an invalid page address when we read/write to
vmalloc buffers, such as those used for Linux kernel modules. Any
attempt to load a Linux kernel module from 9p-virtio produces the
following stack.
[<ffffffff814878ce>] p9_virtio_zc_request+0x45e/0x510
[<ffffffff814814ed>] p9_client_zc_rpc.constprop.16+0xfd/0x4f0
[<ffffffff814839dd>] p9_client_read+0x15d/0x240
[<ffffffff811c8440>] v9fs_fid_readn+0x50/0xa0
[<ffffffff811c84a0>] v9fs_file_readn+0x10/0x20
[<ffffffff811c84e7>] v9fs_file_read+0x37/0x70
[<ffffffff8114e3fb>] vfs_read+0x9b/0x160
[<ffffffff81153571>] kernel_read+0x41/0x60
[<ffffffff810c83ab>] copy_module_from_fd.isra.34+0xfb/0x180
Subsequently, QEMU will die printing:
qemu-system-x86_64: virtio: trying to map MMIO memory
This patch enables 9p-virtio to correctly handle this case. This not
only enables us to load Linux kernel modules off virtfs, but also
enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
Special thanks to both Avi Kivity and Alexander Graf for their
interpretation of QEMU backtraces. Without their guidence, tracking down
this bug would have taken much longer. Also, special thanks to Linus
Torvalds for his insightful explanation of why this should use
is_vmalloc_addr() instead of is_vmalloc_or_module_addr():
https://lkml.org/lkml/2014/2/8/272
Signed-off-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ece3c8a719c8cc90d14cb3f10ed0bf3f5ad66fce
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Feb 10 11:42:35 2014 -0800
6lowpan: fix lockdep splats
[ Upstream commit 20e7c4e80dcd01dad5e6c8b32455228b8fe9c619 ]
When a device ndo_start_xmit() calls again dev_queue_xmit(),
lockdep can complain because dev_queue_xmit() is re-entered and the
spinlocks protecting tx queues share a common lockdep class.
Same issue was fixed for bonding/l2tp/ppp in commits
0daa2303028a6 ("[PATCH] bonding: lockdep annotation")
49ee49202b4ac ("bonding: set qdisc_tx_busylock to avoid LOCKDEP splat")
23d3b8bfb8eb2 ("net: qdisc busylock needs lockdep annotations ")
303c07db487be ("ppp: set qdisc_tx_busylock to avoid LOCKDEP splat ")
Reported-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 17f44a7c1d650464cc4ee173a0df91c6681a91a7
Author: Andy Adamson <andros@netapp.com>
Date: Tue Feb 18 10:36:05 2014 -0500
NFS fix error return in nfs4_select_rw_stateid
commit 146d70caaa1b87f64597743429d7da4b8073d0c9 upstream.
Do not return an error when nfs4_copy_delegation_stateid succeeds.
Signed-off-by: Andy Adamson <andros@netapp.com>
Link: http://lkml.kernel.org/r/1392737765-41942-1-git-send-email-andros@netapp.com
Fixes: ef1820f9be27b (NFSv4: Don't try to recover NFSv4 locks when...)
Cc: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fde4f2d2e1c2b7c1d7c0a9359f884293f8ec5a64
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Thu Feb 6 14:38:53 2014 -0500
NFS: Do not set NFS_INO_INVALID_LABEL unless server supports labeled NFS
commit fd1defc257e2b12ab69bc0b379105c00eca4e112 upstream.
Commit aa9c2669626c (NFS: Client implementation of Labeled-NFS) introduces
a performance regression. When nfs_zap_caches_locked is called, it sets
the NFS_INO_INVALID_LABEL flag irrespectively of whether or not the
NFS server supports security labels. Since that flag is never cleared,
it means that all calls to nfs_revalidate_inode() will now trigger
an on-the-wire GETATTR call.
This patch ensures that we never set the NFS_INO_INVALID_LABEL unless the
server advertises support for labeled NFS.
It also causes nfs_setsecurity() to clear NFS_INO_INVALID_LABEL when it
has successfully set the security label for the inode.
Finally it gets rid of the NFS_INO_INVALID_LABEL cruft from nfs_update_inode,
which has nothing to do with labeled NFS.
Reported-by: Neil Brown <neilb@suse.de>
Tested-by: Neil Brown <neilb@suse.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26154ff956fc591f4960c8d82707660f47749929
Author: Olivier Langlois <olivier@trillion01.com>
Date: Sat Feb 1 01:11:09 2014 -0500
rtlwifi: rtl8192ce: Fix too long disable of IRQs
commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 upstream.
rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
The observable symptoms in dmesg can be:
- underruns from ALSA playback
- clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
[ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
[ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
[ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
[ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
[ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
[ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
[ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
The exact code flow that causes that is:
1. wpa_supplicant send a start_scan request to the nl80211 driver
2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
3. rtl_ips_nic_on is called which disable local irqs
4. rtl92c_phy_set_rf_power_state() is called
5. rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled
A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 71548208cbc0765496fc8aaf7af44413404974e4
Author: Olivier Langlois <olivier@trillion01.com>
Date: Sat Feb 1 01:11:10 2014 -0500
rtlwifi: Fix incorrect return from rtl_ps_enable_nic()
commit 2e8c5e56b307271c2dab6f8bfd1d8a3822ca2390 upstream.
rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6b60665b70426b2e7f3aca413df632226a0adc9
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date: Mon Feb 10 22:38:28 2014 +0100
rtl8187: fix regression on MIPS without coherent DMA
commit b6213e413a4e0c66548153516b074df14f9d08e0 upstream.
This patch fixes regression caused by commit a16dad77634 "MIPS: Fix
potencial corruption". That commit fixes one corruption scenario in
cost of adding another one, which actually start to cause crashes
on Yeeloong laptop when rtl8187 driver is used.
For correct DMA read operation on machines without DMA coherence, kernel
have to invalidate cache, such it will refill later with new data that
device wrote to memory, when that data is needed to process. We can only
invalidate full cache line. Hence when cache line includes both dma
buffer and some other data (written in cache, but not yet in main
memory), the other data can not hit memory due to invalidation. That
happen on rtl8187 where struct rtl8187_priv fields are located just
before and after small buffers that are passed to USB layer and DMA
is performed on them.
To fix the problem we align buffers and reserve space after them to make
them match cache line.
This patch does not resolve all possible MIPS problems entirely, for
that we have to assure that we always map cache aligned buffers for DMA,
what can be complex or even not possible. But patch fixes visible and
reproducible regression and seems other possible corruptions do not
happen in practice, since Yeeloong laptop works stable without rtl8187
driver.
Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=54391
Reported-by: Petr Pisar <petr.pisar@atlas.cz>
Bisected-by: Tom Li <biergaizi2009@gmail.com>
Reported-and-tested-by: Tom Li <biergaizi2009@gmail.com>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Acked-by: Larry Finger <Larry.Finger@lwfinger.next>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f7da6f7c847a4c338465ed732ebf876d27ddbc5
Author: Pavel Shilovsky <piastry@etersoft.ru>
Date: Fri Feb 14 13:31:02 2014 +0400
CIFS: Fix too big maxBuf size for SMB3 mounts
commit 2365c4eaf077c48574ab6f143960048fc0f31518 upstream.
SMB3 servers can respond with MaxTransactSize of more than 4M
that can cause a memory allocation error returned from kmalloc
in a lock codepath. Also the client doesn't support multicredit
requests now and allows buffer sizes of 65536 bytes only. Set
MaxTransactSize to this maximum supported value.
Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14afffbe08f732c0a13a192f1f2a425ca1e59bae
Author: Jeff Layton <jlayton@redhat.com>
Date: Fri Feb 14 07:20:35 2014 -0500
cifs: ensure that uncached writes handle unmapped areas correctly
commit 5d81de8e8667da7135d3a32a964087c0faf5483f upstream.
It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user. This is CVE-2014-0069
cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata->tailsz, which will confuse the sending routines and
cause an oops at the very least.
Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.
[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
v2.6.38 may have a similar problem and may need similar fix]
Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 40684d7823515609a5b38f130f25b48719dc8f02
Author: Chen Gang <gang.chen.5i5j@gmail.com>
Date: Sat Feb 1 20:35:54 2014 +0800
avr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use
commit 8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6 upstream.
For avr32 cross compiler, do not define '__linux__' internally, so it
will cause issue with allmodconfig.
The related error:
CC [M] fs/coda/psdev.o
In file included from include/linux/coda.h:64,
from fs/coda/psdev.c:45:
include/uapi/linux/coda.h:221: error: expected specifier-qualifier-list before 'u_quad_t'
The related toolchain version (which only download, not re-compile):
[root@gchen linux-next]# /upstream/toolchain/download/avr32-gnu-toolchain-linux_x86/bin/avr32-gcc -v
Using built-in specs.
Target: avr32
Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/src/gcc/configure --target=avr32 --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-languages=c,c++ --disable-nls --disable-libssp --disable-libstdcxx-pch --with-dwarf2 --enable-version-specific-runtime-libs --disable-shared --enable-doc --with-mpfr-lib=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/lib --with-mpfr-include=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/include --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-__cxa_atexit --disable-shared --with-newlib --with-pkgversion=AVR_32_bit_GNU_Toolchain_3.4.2_435 --with-bugurl=http://www
.atmel.com/avr
Thread model: single
gcc version 4.4.7 (AVR_32_bit_GNU_Toolchain_3.4.2_435)
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Acked-by: Hans-Christian Egtvedt <hegtvedt@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bfe9485080def3205a15d8581f156988cc0a0074
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri Jan 10 09:29:39 2014 -0500
avr32: fix missing module.h causing build failure in mimc200/fram.c
commit 5745d6a41a4f4aec29e2ccd591c6fb09ed73a955 upstream.
Causing this:
In file included from arch/avr32/boards/mimc200/fram.c:13:
include/linux/miscdevice.h:51: error: field 'list' has incomplete type
include/linux/miscdevice.h:55: error: expected specifier-qualifier-list before 'mode_t'
arch/avr32/boards/mimc200/fram.c:42: error: 'THIS_MODULE' undeclared here (not in a function)
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d3142a00e65cb3664db42d080ba1e5468fae21a8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Feb 17 20:33:01 2014 -0500
jbd2: fix use after free in jbd2_journal_start_reserved()
commit 92e3b40537707001d17bbad800d150ab04e53bf4 upstream.
If start_this_handle() fails then it leads to a use after free of
"handle".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e0164307b2c2f95d636ad82b157eb9c3371230a1
Author: Gavin Shan <shangw@linux.vnet.ibm.com>
Date: Wed Feb 12 15:24:54 2014 +0800
powerpc/powernv: Rework EEH reset
commit 5b2e198e50f6ba57081586b853163ea1bb95f1a8 upstream.
When doing reset in order to recover the affected PE, we issue
hot reset on PE primary bus if it's not root bus. Otherwise, we
issue hot or fundamental reset on root port or PHB accordingly.
For the later case, we didn't cover the situation where PE only
includes root port and it potentially causes kernel crash upon
EEH error to the PE.
The patch reworks the logic of EEH reset to improve the code
readability and also avoid the kernel crash.
Reported-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d2e419b0941069aeaea6d01168ae535c9356dc5
Author: Kevin Hao <haokexin@gmail.com>
Date: Fri Jan 17 12:25:28 2014 +0800
powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
commit 1a18a66446f3f289b05b634f18012424d82aa63a upstream.
Guenter Roeck has got the following call trace on a p2020 board:
Kernel stack overflow in process eb3e5a00, r1=eb79df90
CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
task: eb3e5a00 ti: c0616000 task.ti: ef440000
NIP: c003a420 LR: c003a410 CTR: c0017518
REGS: eb79dee0 TRAP: 0901 Not tainted (3.13.0-rc8-juniper-00146-g19eca00)
MSR: 00029000 <CE,EE,ME> CR: 24008444 XER: 00000000
GPR00: c003a410 eb79df90 eb3e5a00 00000000 eb05d900 00000001 65d87646 00000000
GPR08: 00000000 020b8000 00000000 00000000 44008442
NIP [c003a420] __do_softirq+0x94/0x1ec
LR [c003a410] __do_softirq+0x84/0x1ec
Call Trace:
[eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable)
[eb79dfe0] [c003a970] irq_exit+0xbc/0xc8
[eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c
[ef441f20] [c00046a8] do_IRQ+0x8c/0xf8
[ef441f40] [c000e7f4] ret_from_except+0x0/0x18
--- Exception: 501 at 0xfcda524
LR = 0x10024900
Instruction dump:
7c781b78 3b40000a 3a73b040 543c0024 3a800000 3b3913a0 7ef5bb78 48201bf9
5463103a 7d3b182e 7e89b92e 7c008146 <3ba00000> 7e7e9b78 48000014 57fff87f
Kernel panic - not syncing: kernel stack overflow
CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
Call Trace:
The reason is that we have used the wrong register to calculate the
ksp_limit in commit cbc9565ee826 (powerpc: Remove ksp_limit on ppc64).
Just fix it.
As suggested by Benjamin Herrenschmidt, also add the C prototype of the
function in the comment in order to avoid such kind of errors in the
future.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6a19e4c5295259631f21c063dd92d616a724a11
Author: Stephen Warren <swarren@nvidia.com>
Date: Tue Feb 18 16:51:58 2014 -0700
ARM: tegra: only run PL310 init on systems with one
commit 8859685785bfafadf9bc922dd3a2278e59886947 upstream.
Fix tegra_init_cache() to check whether the system has a PL310 cache
before touching the PL310 registers. This prevents access to non-existent
registers on Tegra114 and later.
Note for stable kernels:
In <= v3.12, the file to patch is arch/arm/mach-tegra/common.c.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d15c4c3c6ed195480bb8ae6b3e48b8eb596a65ac
Author: Shawn Guo <shawn.guo@linaro.org>
Date: Tue Feb 18 10:35:05 2014 +0800
ARM: imx6: build pm-imx6q.c independently of CONFIG_PM
commit 28a9f3b078c545064dcf4b46d2c6917554d1642e upstream.
When building a kernel image with only CONFIG_CPU_IDLE but no CONFIG_PM,
we will get the following link error.
LD init/built-in.o
arch/arm/mach-imx/built-in.o: In function `imx6q_enter_wait':
platform-spi_imx.c:(.text+0x25c0): undefined reference to `imx6q_set_lpm'
platform-spi_imx.c:(.text+0x25d4): undefined reference to `imx6q_set_lpm'
arch/arm/mach-imx/built-in.o: In function `imx6q_cpuidle_init':
platform-spi_imx.c:(.init.text+0x75d4): undefined reference to `imx6q_set_chicken_bit'
make[1]: *** [vmlinux] Error 1
Since pm-imx6q.c has been a collection of library functions that access
CCM low-power registers used by not only suspend but also cpuidle and
other drivers, let's build pm-imx6q.c independently of CONFIG_PM to fix
above error.
Reported-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e5b5c42692d5448be5c7dbb8701d75c0fcd7f3b
Author: Pekon Gupta <pekon@ti.com>
Date: Tue Jan 28 11:42:41 2014 +0530
ARM: OMAP2+: gpmc: fix: DT ONENAND child nodes not probed when MTD_ONENAND is built as module
commit 980386d2d6d49e0b42f48550853ef1ad6aa5d79a upstream.
Fixes: commit 75d3625e0e86b2d8d77b4e9c6f685fd7ea0d5a96
ARM: OMAP2+: gpmc: add DT bindings for OneNAND
OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and
register them platform_device for ONENAND driver to probe later. However this does
not happen if generic MTD_ONENAND framework is built as module (CONFIG_MTD_ONENAND=m).
Therefore, when MTD/ONENAND and MTD/ONENAND/OMAP2 modules are loaded, they are unable
to find any matching platform_device and remain un-binded. This causes on board
ONENAND flash to remain un-detected.
This patch causes GPMC controller to parse DT nodes when
CONFIG_MTD_ONENAND=y || CONFIG_MTD_ONENAND=m
Signed-off-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9990998222fecea3e0b7940d2df53a022d7b8df7
Author: Pekon Gupta <pekon@ti.com>
Date: Tue Jan 28 11:42:40 2014 +0530
ARM: OMAP2+: gpmc: fix: DT NAND child nodes not probed when MTD_NAND is built as module
commit 6b187b21c92b6e2c7e8ef0b450181c37a3f31681 upstream.
Fixes: commit bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0
ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and
register them platform_device for NAND driver to probe later. However this does
not happen if generic MTD_NAND framework is built as module (CONFIG_MTD_NAND=m).
Therefore, when MTD/NAND and MTD/NAND/OMAP2 modules are loaded, they are unable
to find any matching platform_device and remain un-binded. This causes on board
NAND flash to remain un-detected.
This patch causes GPMC controller to parse DT nodes when
CONFIG_MTD_NAND=y || CONFIG_MTD_NAND=m
Signed-off-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0d5d1bdaaf41a11bee6b4d5609177341334e430
Author: Vinayak Kale <vkale@apm.com>
Date: Wed Feb 12 07:30:01 2014 +0100
ARM: 7957/1: add DSB after icache flush in __flush_icache_all()
commit 39544ac9df20f73e49fc6b9ac19ff533388c82c0 upstream.
Add DSB after icache flush to complete the cache maintenance operation.
Signed-off-by: Vinayak Kale <vkale@apm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 12f9e108a514f3d4878e26c0bec74142efe718b5
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Feb 7 19:12:32 2014 +0100
ARM: 7955/1: spinlock: ensure we have a compiler barrier before sev
commit 7c8746a9eb287642deaad0e7c2cdf482dce5e4be upstream.
When unlocking a spinlock, we require the following, strictly ordered
sequence of events:
<barrier> /* dmb */
<unlock>
<barrier> /* dsb */
<sev>
Whilst the code does indeed reflect this in terms of the architecture,
the final <barrier> + <sev> have been contracted into a single inline
asm without a "memory" clobber, therefore the compiler is at liberty to
reorder the unlock to the end of the above sequence. In such a case,
a waiting CPU may be woken up before the lock has been unlocked, leading
to extremely poor performance.
This patch reworks the dsb_sev() function to make use of the dsb()
macro and ensure ordering against the unlock.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 670c8af93264647d5399a68951cb253e2dc67b19
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Feb 7 19:12:20 2014 +0100
ARM: 7953/1: mm: ensure TLB invalidation is complete before enabling MMU
commit bae0ca2bc550d1ec6a118fb8f2696f18c4da3d8e upstream.
During __v{6,7}_setup, we invalidate the TLBs since we are about to
enable the MMU on return to head.S. Unfortunately, without a subsequent
dsb instruction, the invalidation is not guaranteed to have completed by
the time we write to the sctlr, potentially exposing us to junk/stale
translations cached in the TLB.
This patch reworks the init functions so that the dsb used to ensure
completion of cache/predictor maintenance is also used to ensure
completion of the TLB invalidation.
Reported-by: Albin Tonnerre <Albin.Tonnerre@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 76d80002580c2b81f40d7e8be14125fdf1ab0b68
Author: Christoffer Dall <christoffer.dall@linaro.org>
Date: Sun Feb 2 22:21:31 2014 +0100
ARM: 7950/1: mm: Fix stage-2 device memory attributes
commit 4d9c5b89cf3605bbc39c6e274351ff25f0d83e6a upstream.
The stage-2 memory attributes are distinct from the Hyp memory
attributes and the Stage-1 memory attributes. We were using the stage-1
memory attributes for stage-2 mappings causing device mappings to be
mapped as normal memory. Add the S2 equivalent defines for memory
attributes and fix the comments explaining the defines while at it.
Add a prot_pte_s2 field to the mem_type struct and fill out the field
for device mappings accordingly.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a6c4cd9a085da3ff617b6cfde5c221bfb2c0f83
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Thu Jan 16 15:39:17 2014 +0100
ARM: dma-mapping: fix GFP_ATOMIC macro usage
commit 10c8562f932d89c030083e15f9279971ed637136 upstream.
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. This patch
fixes the issue introduced in v3.6-rc5
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1883d769bbf9701b7f93ac8d5e8a44612aa894f9
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sun Feb 16 19:29:32 2014 -0500
ext4: don't leave i_crtime.tv_sec uninitialized
commit 19ea80603715d473600cd993b9987bc97d042e02 upstream.
If the i_crtime field is not present in the inode, don't leave the
field uninitialized.
Fixes: ef7f38359 ("ext4: Add nanosecond timestamps")
Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Tested-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe01b1a2d49c4a43ab556a1f0f35b8582ca62ac5
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sat Feb 15 22:42:25 2014 -0500
ext4: fix online resize with a non-standard blocks per group setting
commit 3d2660d0c9c2f296837078c189b68a47f6b2e3b5 upstream.
The set_flexbg_block_bitmap() function assumed that the number of
blocks in a blockgroup was sb->blocksize * 8, which is normally true,
but not always! Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block
bitmap corruption after:
mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G
mount -t ext4 /dev/vdd /vdd
resize2fs /dev/vdd 8G
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Jon Bernard <jbernard@tuxion.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 385d7ce181827add6cf1a4b1944765f34e9125be
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sat Feb 15 21:33:13 2014 -0500
ext4: fix online resize with very large inode tables
commit b93c95353413041a8cebad915a8109619f66bcc6 upstream.
If a file system has a large number of inodes per block group, all of
the metadata blocks in a flex_bg may be larger than what can fit in a
single block group. Unfortunately, ext4_alloc_group_tables() in
resize.c was never tested to see if it would handle this case
correctly, and there were a large number of bugs which caused the
following sequence to result in a BUG_ON:
kernel bug at fs/ext4/resize.c:409!
...
call trace:
[<ffffffff81256768>] ext4_flex_group_add+0x1448/0x1830
[<ffffffff81257de2>] ext4_resize_fs+0x7b2/0xe80
[<ffffffff8123ac50>] ext4_ioctl+0xbf0/0xf00
[<ffffffff811c111d>] do_vfs_ioctl+0x2dd/0x4b0
[<ffffffff811b9df2>] ? final_putname+0x22/0x50
[<ffffffff811c1371>] sys_ioctl+0x81/0xa0
[<ffffffff81676aa9>] system_call_fastpath+0x16/0x1b
code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0
rip [<ffffffff81254fa1>] set_flexbg_block_bitmap+0x171/0x180
This can be reproduced with the following command sequence:
mke2fs -t ext4 -i 4096 /dev/vdd 1G
mount -t ext4 /dev/vdd /vdd
resize2fs /dev/vdd 8G
To fix this, we need to make sure the right thing happens when a block
group's inode table straddles two block groups, which means the
following bugs had to be fixed:
1) Not clearing the BLOCK_UNINIT flag in the second block group in
ext4_alloc_group_tables --- the was proximate cause of the BUG_ON.
2) Incorrectly determining how many block groups contained contiguous
free blocks in ext4_alloc_group_tables().
3) Incorrectly setting the start of the next block range to be marked
in use after a discontinuity in setup_new_flex_group_blocks().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1503cbd3713b5d130815be0069b93bf75bb28104
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Feb 12 12:16:04 2014 -0500
ext4: don't try to modify s_flags if the the file system is read-only
commit 23301410972330c0ae9a8afc379ba2005e249cc6 upstream.
If an ext4 file system is created by some tool other than mke2fs
(perhaps by someone who has a pathalogical fear of the GPL) that
doesn't set one or the other of the EXT2_FLAGS_{UN}SIGNED_HASH flags,
and that file system is then mounted read-only, don't try to modify
the s_flags field. Otherwise, if dm_verity is in use, the superblock
will change, causing an dm_verity failure.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 087cee5b7b02d6b5f42a014e02dde2557098cf9a
Author: Zheng Liu <wenqing.lz@taobao.com>
Date: Wed Feb 12 11:48:31 2014 -0500
ext4: fix error paths in swap_inode_boot_loader()
commit 30d29b119ef01776e0a301444ab24defe8d8bef3 upstream.
In swap_inode_boot_loader() we forgot to release ->i_mutex and resume
unlocked dio for inode and inode_bl if there is an error starting the
journal handle. This commit fixes this issue.
Reported-by: Ahmed Tamrawi <ahmedtamrawi@gmail.com>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Dr. Tilmann Bubeck <t.bubeck@reinform.de>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4c5e5c76a2fd168bff550b20b1746e3604c07fa3
Author: Eric Whitney <enwlinux@gmail.com>
Date: Wed Feb 12 10:42:45 2014 -0500
ext4: fix xfstest generic/299 block validity failures
commit 15cc17678547676c82a5da9ccf357447333fc342 upstream.
Commit a115f749c1 (ext4: remove wait for unwritten extent conversion from
ext4_truncate) exposed a bug in ext4_ext_handle_uninitialized_extents().
It can be triggered by xfstest generic/299 when run on a test file
system created without a journal. This test continuously fallocates and
truncates files to which random dio/aio writes are simultaneously
performed by a separate process. The test completes successfully, but
if the test filesystem is mounted with the block_validity option, a
warning message stating that a logical block has been mapped to an
illegal physical block is posted in the kernel log.
The bug occurs when an extent is being converted to the written state
by ext4_end_io_dio() and ext4_ext_handle_uninitialized_extents()
discovers a mapping for an existing uninitialized extent. Although it
sets EXT4_MAP_MAPPED in map->m_flags, it fails to set map->m_pblk to
the discovered physical block number. Because map->m_pblk is not
otherwise initialized or set by this function or its callers, its
uninitialized value is returned to ext4_map_blocks(), where it is
stored as a bogus mapping in the extent status tree.
Since map->m_pblk can accidentally contain illegal values that are
larger than the physical size of the file system, calls to
check_block_validity() in ext4_map_blocks() that are enabled if the
block_validity mount option is used can fail, resulting in the logged
warning message.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 05524f5b61c3c15859477a2165cff81e3d682743
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Feb 11 19:52:06 2014 +0200
drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB
commit f66fab8e1cd6b3127ba4c5c0d11539fbe1de1e36 upstream.
According to BSpec the entire MI_DISPLAY_FLIP packet must be contained
in a single cacheline. Make sure that happens.
v2: Use intel_ring_begin_cacheline_safe()
v3: Use intel_ring_cacheline_align() (Chris)
Cc: Bjoern C <lkml@call-home.ch>
Cc: Alexandru DAMIAN <alexandru.damian@intel.com>
Cc: Enrico Tagliavini <enrico.tagliavini@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 12b96a3843431abcb29fe8f2cd04f17e32366de0
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Feb 11 19:52:05 2014 +0200
drm/i915: Add intel_ring_cachline_align()
commit 753b1ad4a281b0663329409d410243e91825c323 upstream.
intel_ring_cachline_align() emits MI_NOOPs until the ring tail is
aligned to a cacheline boundary.
Cc: Bjoern C <lkml@call-home.ch>
Cc: Alexandru DAMIAN <alexandru.damian@intel.com>
Cc: Enrico Tagliavini <enrico.tagliavini@gmail.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d25c294176b7f15f99b5965de67ca5b31812463
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date: Thu Feb 13 21:57:15 2014 -0500
drm/nv50/disp: use correct register to determine DP display bpp
commit a7f1c1e65b68e1e1ab70898528d5977ed68a0a7d upstream.
Commit 0a0afd282f ("drm/nv50-/disp: move DP link training to core and
train from supervisor") added code that uses the wrong register for
computing the display bpp, used for bandwidth calculation. Adjust to use
the same register as used by exec_clkcmp and nv50_disp_intr_unk20_2_dp.
Reported-by: Torsten Wagner <torsten.wagner@gmail.com>
Reported-by: Michael Gulick <mgulick@mathworks.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67628
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 88fd02dbb48c0298f10e66f7f93616cb45b8fece
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Wed Feb 12 01:41:42 2014 +0000
drm/nouveau/fb: use correct ram oclass for nv1a hardware
commit 95ca5b550ac255bf3cee108c123407785c47e3cc upstream.
commit 8613e7314ac254fdd67ed46192f021d76141e4c9
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Oct 21 08:50:25 2013 +1000
drm/nouveau/fb: remove ram oclass argument from base fb constructor
Introduced a unfortunate regression by using nv10 ram oclass for nv1a
hardware, causing corruption and eventually system lockup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74866
Reported-by: John F. Godfrey <jfgodfrey@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6283dfe5a10a4eb8aca615ec55726be58cf54f1
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date: Wed Jan 29 19:53:00 2014 -0500
drm/nouveau: set irq_enabled manually
commit 7d3428cd4b2ad51af86fdbdf8284ca38fa95e601 upstream.
Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup
ourselves"), drm_device->irq_enabled remained unset. This is needed in
order to properly wait for a vblank event in the generic drm code.
See https://bugs.freedesktop.org/show_bug.cgi?id=74195
Reported-by: Jan Janecek <janjanjanx@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 035a110edb37bbc731c57f3dae1819e53268cd81
Author: Christian König <christian.koenig@amd.com>
Date: Tue Feb 18 11:37:20 2014 +0100
drm/radeon: fix CP semaphores on CIK
commit 8f53492f86f9ca66bc762be98f0a9fce9bcb319a upstream.
The CP semaphore queue on CIK has a bug that triggers if uncompleted
waits use the same address while a signal is still pending. Work around
this by using different addresses for each sync.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c06e42d67903a5394fceb07469977aade27c2cd
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Feb 17 14:16:31 2014 -0500
drm/radeon: fix display tiling setup on SI
commit 6d8ea7de3f5035610f3bfacbe35e7b71ad1e4663 upstream.
Apply the same logic as CI to SI for setting up the
display tiling parameters. The num banks may vary
per tiling index just like CI.
Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=71488
https://bugs.freedesktop.org/show_bug.cgi?id=73946
https://bugs.freedesktop.org/show_bug.cgi?id=74927
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 31db11710d17f077866e718f14fac44a219c0357
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 18 10:16:28 2014 -0500
drm/radeon/ni: fix typo in dpm sq ramping setup
commit 21ed4947fdfe19b60a27b84162622e56439c7937 upstream.
inverted logic.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>