commit 39386d75ac70cdf91b9bb9763f01156e440bb2bb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Feb 6 11:22:39 2014 -0800
Linux 3.12.10
commit c5e16510e3454393fa8e40591bff28c190be2faa
Author: Borislav Petkov <bp@suse.de>
Date: Wed Jan 15 00:07:11 2014 +0100
x86, cpu, amd: Add workaround for family 16h, erratum 793
commit 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 upstream.
This adds the workaround for erratum 793 as a precaution in case not
every BIOS implements it. This addresses CVE-2013-6885.
Erratum text:
[Revision Guide for AMD Family 16h Models 00h-0Fh Processors,
document 51810 Rev. 3.04 November 2013]
793 Specific Combination of Writes to Write Combined Memory Types and
Locked Instructions May Cause Core Hang
Description
Under a highly specific and detailed set of internal timing
conditions, a locked instruction may trigger a timing sequence whereby
the write to a write combined memory type is not flushed, causing the
locked instruction to stall indefinitely.
Potential Effect on System
Processor core hang.
Suggested Workaround
BIOS should set MSR
C001_1020[15] = 1b.
Fix Planned
No fix planned
[ hpa: updated description, fixed typo in MSR name ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/20140114230711.GS29865@pd.tnic
Tested-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50692bdd5cde9f86d1f96f50627d2fbf266ee783
Author: Paul Mackerras <paulus@samba.org>
Date: Sat Jan 18 21:14:47 2014 +1100
powerpc: Make sure "cache" directory is removed when offlining cpu
commit 91b973f90c1220d71923e7efe1e61f5329806380 upstream.
The code in remove_cache_dir() is supposed to remove the "cache"
subdirectory from the sysfs directory for a CPU when that CPU is
being offlined. It tries to do this by calling kobject_put() on
the kobject for the subdirectory. However, the subdirectory only
gets removed once the last reference goes away, and the reference
being put here may well not be the last reference. That means
that the "cache" subdirectory may still exist when the offlining
operation has finished. If the same CPU subsequently gets onlined,
the code tries to add a new "cache" subdirectory. If the old
subdirectory has not yet been removed, we get a WARN_ON in the
sysfs code, with stack trace, and an error message printed on the
console. Further, we ultimately end up with an online cpu with no
"cache" subdirectory.
This fixes it by doing an explicit kobject_del() at the point where
we want the subdirectory to go away. kobject_del() removes the sysfs
directory even though the object still exists in memory. The object
will get freed at some point in the future. A subsequent onlining
operation can create a new sysfs directory, even if the old object
still exists in memory, without causing any problems.
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 634bcdd9a104b791eec3f808d6ee4f1e565303e2
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date: Mon Dec 30 17:05:34 2013 +0530
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
commit d4edc5b6c480a0917e61d93d55531d7efa6230be upstream.
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b572f9aaacdcb9b22ee6483fecaaa7a38c757896
Author: David Sterba <dsterba@suse.cz>
Date: Wed Jan 15 18:15:52 2014 +0100
btrfs: restrict snapshotting to own subvolumes
commit d024206133ce21936b3d5780359afc00247655b7 upstream.
Currently, any user can snapshot any subvolume if the path is accessible and
thus indirectly create and keep files he does not own under his direcotries.
This is not possible with traditional directories.
In security context, a user can snapshot root filesystem and pin any
potentially buggy binaries, even if the updates are applied.
All the snapshots are visible to the administrator, so it's possible to
verify if there are suspicious snapshots.
Another more practical problem is that any user can pin the space used
by eg. root and cause ENOSPC.
Original report:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/484786
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0f602ae0ea2f3e6f519f8927cd9feb3bbaf4843
Author: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Date: Tue Jan 7 17:26:58 2014 +0800
Btrfs: handle EAGAIN case properly in btrfs_drop_snapshot()
commit 90515e7f5d7d24cbb2a4038a3f1b5cfa2921aa17 upstream.
We may return early in btrfs_drop_snapshot(), we shouldn't
call btrfs_std_err() for this case, fix it.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 268938938ee6e9be5697932dfc92c9de703216af
Author: Andy Grover <agrover@redhat.com>
Date: Fri Jan 24 16:18:54 2014 -0800
target/iscsi: Fix network portal creation race
commit ee291e63293146db64668e8d65eb35c97e8324f4 upstream.
When creating network portals rapidly, such as when restoring a
configuration, LIO's code to reuse existing portals can return a false
negative if the thread hasn't run yet and set np_thread_state to
ISCSI_NP_THREAD_ACTIVE. This causes an error in the network stack
when attempting to bind to the same address/port.
This patch sets NP_THREAD_ACTIVE before the np is placed on g_np_list,
so even if the thread hasn't run yet, iscsit_get_np will return the
existing np.
Also, convert np_lock -> np_mutex + hold across adding new net portal
to g_np_list to prevent a race where two threads may attempt to create
the same network portal, resulting in one of them failing.
(nab: Add missing mutex_unlocks in iscsit_add_np failure paths)
(DanC: Fix incorrect spin_unlock -> spin_unlock_bh)
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0663ebb3d524621d0baf59cf70bc4d9f4b05560e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Fri Jan 10 02:06:59 2014 +0000
iscsi-target: Pre-allocate more tags to avoid ack starvation
commit 4a4caa29f1abcb14377e05d57c0793d338fb945d upstream.
This patch addresses an traditional iscsi-target fabric ack starvation
issue where iscsit_allocate_cmd() -> percpu_ida_alloc_state() ends up
hitting slow path percpu-ida code, because iscsit_ack_from_expstatsn()
is expected to free ack'ed tags after tag allocation.
This is done to take into account the tags waiting to be acknowledged
and released in iscsit_ack_from_expstatsn(), but who's number are not
directly limited by the CmdSN Window queue_depth being enforced by
the target.
So that said, this patch bumps up the pre-allocated number of
per session tags to:
(max(queue_depth, ISCSIT_MIN_TAGS) * 2) + ISCSIT_EXTRA_TAGS
for good measure to avoid the percpu_ida_alloc_state() slow path.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f2d6b1bada7ce0e72258302dbd365e89b4578986
Author: Asias He <asias.hejun@gmail.com>
Date: Thu Jan 16 10:18:48 2014 +1030
virtio-scsi: Fix hotcpu_notifier use-after-free with virtscsi_freeze
commit f466f75385369a181409e46da272db3de6f5c5cb upstream.
vqs are freed in virtscsi_freeze but the hotcpu_notifier is not
unregistered. We will have a use-after-free usage when the notifier
callback is called after virtscsi_freeze.
Fixes: 285e71ea6f3583a85e27cb2b9a7d8c35d4c0d558
("virtio-scsi: reset virtqueue affinity when doing cpu hotplug")
Signed-off-by: Asias He <asias.hejun@gmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e88fcbf2e77942ae29ec1fb2c387363b5ac5ef31
Author: Vijaya Mohan Guvva <vmohan@brocade.com>
Date: Wed Dec 4 05:43:58 2013 -0800
SCSI: bfa: Chinook quad port 16G FC HBA claim issue
commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream.
Bfa driver crash is observed while pushing the firmware on to chinook
quad port card due to uninitialized bfi_image_ct2 access which gets
initialized only for CT2 ASIC based cards after request_firmware().
For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting
initialized as there is no check for chinook PCI device ID before
request_firmware and instead bfi_image_cb is initialized as it is the
default case for card type check.
This patch includes changes to read the right firmware for quad port chinook.
Signed-off-by: Vijaya Mohan Guvva <vmohan@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8e3197c35eba06b8c65f80bfede432119e26ccc0
Author: Thomas Pugliese <thomas.pugliese@gmail.com>
Date: Mon Dec 9 13:40:29 2013 -0600
usb: core: get config and string descriptors for unauthorized devices
commit 83e83ecb79a8225e79bc8e54e9aff3e0e27658a2 upstream.
There is no need to skip querying the config and string descriptors for
unauthorized WUSB devices when usb_new_device is called. It is allowed
by WUSB spec. The only action that needs to be delayed until
authorization time is the set config. This change allows user mode
tools to see the config and string descriptors earlier in enumeration
which is needed for some WUSB devices to function properly on Android
systems. It also reduces the amount of divergent code paths needed
for WUSB devices.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 29b49c82199f85661963e52c8dea0e8563bc09e8
Author: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Date: Wed Jan 29 00:10:44 2014 +0100
hpfs: remember free space
commit 2cbe5c76fc5e38e9af4b709593146e4b8272b69e upstream.
Previously, hpfs scanned all bitmaps each time the user asked for free
space using statfs. This patch changes it so that hpfs scans the
bitmaps only once, remembes the free space and on next invocation of
statfs it returns the value instantly.
New versions of wine are hammering on the statfs syscall very heavily,
making some games unplayable when they're stored on hpfs, with load
times in minutes.
This should be backported to the stable kernels because it fixes
user-visible problem (excessive level load times in wine).
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 940a96a5511e1b0a330e5b9b73956e3280f519de
Author: Stephen Warren <swarren@nvidia.com>
Date: Mon Feb 3 16:54:04 2014 -0700
ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled
(This is upstream 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be
dynamically enabled", backported to stable 3.10 through 3.12. 3.13 and
later can take the original patch.)
Commit 384a48d71520 "ALSA: hda: HDMI: Support codecs with fewer cvts
than pins" dynamically enabled each pin widget's PIN_OUT only when the
pin was actively in use. This was required on certain NVIDIA CODECs for
correct operation. Specifically, if multiple pin widgets each had their
mux input select the same audio converter widget and each pin widget had
PIN_OUT enabled, then only one of the pin widgets would actually receive
the audio, and often not the one the user wanted!
However, this apparently broke some Intel systems, and commit
6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP" reverted the
dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA
CODECs.
This change supports either dynamic or static handling of PIN_OUT,
selected by a flag set up during CODEC initialization. This flag is
enabled for all recent NVIDIA GPUs.
Reported-by: Uosis <uosisl@gmail.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3573ce4b5611ded185a7e211bdbc1b65b5cf5df9
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date: Mon Feb 3 16:54:03 2014 -0700
ALSA: hda - hdmi: introduce patch_nvhdmi()
(This is a backport of *part* of upstream 611885bc963a "ALSA: hda -
hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" to stable
3.10 through 3.12. Later stable already contain all of the original
patch.)
Mainline commit 611885bc963a "ALSA: hda - hdmi: Disallow unsupported 2ch
remapping on NVIDIA codecs" introduces function patch_nvhdmi(). That
function is edited by 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be
dynamically enabled". In order to backport the PIN_OUT patch, I am first
back-porting just the addition of function patch_nvhdmi(), so that the
conflicts applying the PIN_OUT patch are simplified.
Ideally, one might backport all of 611885bc963a. However, that commit
doesn't apply to stable kernels, since it relies on a chain of other
patches which implement new features.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[swarren, extracted just a small part of the original patch]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fdc514317fc03a570dd3667ce5820ce3cfb5cea
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Jan 13 12:40:07 2014 +0100
ALSA: hda - Don't set indep_hp flag for old AD codecs
commit cbd209f41ea5f39394de5c1fe2dd9aa54a9c5744 upstream.
Some old AD codecs don't like the independent HP handling, either it
contains a single DAC (AD1981) or it mandates the mixer routing
(AD1986A). This patch removes the indep_hp flag for such codecs.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68081
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ee1c2e62dc47f69e5b4b18b1af33851c9491e0c7
Author: Mihai Caraman <mihai.caraman@freescale.com>
Date: Thu Jan 9 17:01:05 2014 +0200
KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()
commit 70713fe315ed14cd1bb07d1a7f33e973d136ae3d upstream.
Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss().
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de0bb60dd19845d14f7d63f640c4b77c2d079c58
Author: Andreas Schwab <schwab@linux-m68k.org>
Date: Mon Dec 30 15:36:56 2013 +0100
KVM: PPC: Book3S HV: use xics_wake_cpu only when defined
commit 48eaef0518a565d3852e301c860e1af6a6db5a84 upstream.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 62137ca3bf39188bf19a7ceade570ba4bec6761c
Author: Helge Deller <deller@gmx.de>
Date: Fri Jan 31 21:33:17 2014 +0100
parisc: fix cache-flushing
commit 57737c49dd72c96cfbcd4f66559f3ffc399aeb4f upstream.
This commit:
f8dae00684d678afa13041ef170cecfd1297ed40: parisc: Ensure full cache coherency for kmap/kunmap
caused negative caching side-effects, e.g. hanging processes with expect and
too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems.
This patch now partly reverts it and has been in production use on our debian buildd
makeservers since a week without any major problems.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit afb6162fa801161e5842a700aa1432e5921f6794
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Wed Jan 22 23:04:33 2014 -0500
alpha: fix broken network checksum
commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream.
The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 breaks networking on
alpha (there is a follow-up fix 5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6,
but networking is still broken even with the second patch).
The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 makes
csum_partial_copy_from_user check the pointer with access_ok. However,
csum_partial_copy_from_user is called also from csum_partial_copy_nocheck
and csum_partial_copy_nocheck is called on kernel pointers and it is
supposed not to check pointer validity.
This bug results in ssh session hangs if the system is loaded and bulk
data are printed to ssh terminal.
This patch fixes csum_partial_copy_nocheck to call set_fs(KERNEL_DS), so
that access_ok in csum_partial_copy_from_user accepts kernel-space
addresses.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18fe5f72e8cd2f549002ada925c1a43daafbf4c1
Author: Neal Cardwell <ncardwell@google.com>
Date: Sun Feb 2 20:40:13 2014 -0500
inet_diag: fix inet_diag_dump_icsk() timewait socket state logic
[ Based upon upstream commit 70315d22d3c7383f9a508d0aab21e2eb35b2303a ]
Fix inet_diag_dump_icsk() to reflect the fact that both TIME_WAIT and
FIN_WAIT2 connections are represented by inet_timewait_sock (not just
TIME_WAIT). Thus:
(a) We need to iterate through the time_wait buckets if the user wants
either TIME_WAIT or FIN_WAIT2. (Before fixing this, "ss -nemoi state
fin-wait-2" would not return any sockets, even if there were some in
FIN_WAIT2.)
(b) We need to check tw_substate to see if the user wants to dump
sockets in the particular substate (TIME_WAIT or FIN_WAIT2) that a
given connection is in. (Before fixing this, "ss -nemoi state
time-wait" would actually return sockets in state FIN_WAIT2.)
An analogous fix is in v3.13: 70315d22d3c7383f9a508d0aab21e2eb35b2303a
("inet_diag: fix inet_diag_dump_icsk() to use correct state for
timewait sockets") but that patch is quite different because 3.13 code
is very different in this area due to the unification of TCP hash
tables in 05dbc7b ("tcp/dccp: remove twchain") in v3.13-rc1.
I tested that this applies cleanly between v3.3 and v3.12, and tested
that it works in both 3.3 and 3.12. It does not apply cleanly to 3.2
and earlier (though it makes semantic sense), and semantically is not
the right fix for 3.13 and beyond (as mentioned above).
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
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 3760d6b277229dbfbbacbab08dbebc71c0a94145
Author: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Tue Jan 28 11:49:43 2014 +0800
net: gre: use icmp_hdr() to get inner ip header
[ Upstream commit c0c0c50ff7c3e331c90bab316d21f724fb9e1994 ]
When dealing with icmp messages, the skb->data points the
ip header that triggered the sending of the icmp message.
In gre_cisco_err(), the parse_gre_header() is called, and the
iptunnel_pull_header() is called to pull the skb at the end of
the parse_gre_header(), so the skb->data doesn't point the
inner ip header.
Unfortunately, the ipgre_err still needs those ip addresses in
inner ip header to look up tunnel by ip_tunnel_lookup().
So just use icmp_hdr() to get inner ip header instead of skb->data.
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 295e71589bc8e417c6d563864ed783e9b98bb405
Author: Annie Li <annie.li@oracle.com>
Date: Tue Jan 28 11:35:42 2014 +0800
xen-netfront: fix resource leak in netfront
[ Upstream commit cefe0078eea52af17411eb1248946a94afb84ca5 ]
This patch removes grant transfer releasing code from netfront, and uses
gnttab_end_foreign_access to end grant access since
gnttab_end_foreign_access_ref may fail when the grant entry is
currently used for reading or writing.
* clean up grant transfer code kept from old netfront(2.6.18) which grants
pages for access/map and transfer. But grant transfer is deprecated in current
netfront, so remove corresponding release code for transfer.
* fix resource leak, release grant access (through gnttab_end_foreign_access)
and skb for tx/rx path, use get_page to ensure page is released when grant
access is completed successfully.
Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches
for them will be created separately.
V6: Correct subject line and commit message.
V5: Remove unecessary change in xennet_end_access.
V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in
single patch.
V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill
grant acess is ended.
V2: Improve patch comments.
Signed-off-by: Annie Li <annie.li@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b90dd2223bdc2a60e3bb7ed468158b2f867c3aa
Author: Holger Eitzenberger <holger@eitzenberger.org>
Date: Mon Jan 27 10:33:18 2014 +0100
net: Fix memory leak if TPROXY used with TCP early demux
[ Upstream commit a452ce345d63ddf92cd101e4196569f8718ad319 ]
I see a memory leak when using a transparent HTTP proxy using TPROXY
together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable):
unreferenced object 0xffff88008cba4a40 (size 1696):
comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s)
hex dump (first 32 bytes):
0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2.....
02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9
[<ffffffff81270185>] sk_prot_alloc+0x29/0xc5
[<ffffffff812702cf>] sk_clone_lock+0x14/0x283
[<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b
[<ffffffff8129a893>] netlink_broadcast+0x14/0x16
[<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3
[<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d
[<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0
[<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e
[<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55
[<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725
[<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154
[<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514
[<ffffffff8127aa77>] process_backlog+0xee/0x1c5
[<ffffffff8127c949>] net_rx_action+0xa7/0x200
[<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157
But there are many more, resulting in the machine going OOM after some
days.
From looking at the TPROXY code, and with help from Florian, I see
that the memory leak is introduced in tcp_v4_early_demux():
void tcp_v4_early_demux(struct sk_buff *skb)
{
/* ... */
iph = ip_hdr(skb);
th = tcp_hdr(skb);
if (th->doff < sizeof(struct tcphdr) / 4)
return;
sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
iph->saddr, th->source,
iph->daddr, ntohs(th->dest),
skb->skb_iif);
if (sk) {
skb->sk = sk;
where the socket is assigned unconditionally to skb->sk, also bumping
the refcnt on it. This is problematic, because in our case the skb
has already a socket assigned in the TPROXY target. This then results
in the leak I see.
The very same issue seems to be with IPv6, but haven't tested.
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b29a742344c0837b1a548ebcd9eccb19aed83f7
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu Jan 23 10:19:34 2014 +0100
fib_frontend: fix possible NULL pointer dereference
[ Upstream commit a0065f266a9b5d51575535a25c15ccbeed9a9966 ]
The two commits 0115e8e30d (net: remove delay at device dismantle) and
748e2d9396a (net: reinstate rtnl in call_netdevice_notifiers()) silently
removed a NULL pointer check for in_dev since Linux 3.7.
This patch re-introduces this check as it causes crashing the kernel when
setting small mtu values on non-ip capable netdevices.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
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 7da69d2cbd4bcf50d3ea2b930829a2e4b7001c03
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu Jan 23 11:28:13 2014 +0200
net/vxlan: Share RX skb de-marking and checksum checks with ovs
[ Upstream commit d0bc65557ad09a57b4db176e9e3ccddb26971453 ]
Make sure the practice set by commit 0afb166 "vxlan: Add capability
of Rx checksum offload for inner packet" is applied when the skb
goes through the portion of the RX code which is shared between
vxlan netdevices and ovs vxlan port instances.
Cc: Joseph Gasparakis <joseph.gasparakis@intel.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9cafae949e2126d396b745bf06626a08e803b282
Author: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Thu Jan 23 14:00:25 2014 +0800
ip_tunnel: clear IPCB in ip_tunnel_xmit() in case dst_link_failure() is called
[ Upstream commit 11c21a307d79ea5f6b6fc0d3dfdeda271e5e65f6 ]
commit a622260254ee48("ip_tunnel: fix kernel panic with icmp_dest_unreach")
clear IPCB in ip_tunnel_xmit() , or else skb->cb[] may contain garbage from
GSO segmentation layer.
But commit 0e6fbc5b6c621("ip_tunnels: extend iptunnel_xmit()") refactor codes,
and it clear IPCB behind the dst_link_failure().
So clear IPCB in ip_tunnel_xmit() just like commti a622260254ee48("ip_tunnel:
fix kernel panic with icmp_dest_unreach").
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 121aef658bcfb1e8b273cabc8b55b274a1ac7a9c
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Fri Jan 17 09:37:15 2014 +0100
s390/bpf,jit: fix 32 bit divisions, use unsigned divide instructions
[ Upstream commit 3af57f78c38131b7a66e2b01e06fdacae01992a3 ]
The s390 bpf jit compiler emits the signed divide instructions "dr" and "d"
for unsigned divisions.
This can cause problems: the dividend will be zero extended to a 64 bit value
and the divisor is the 32 bit signed value as specified A or X accumulator,
even though A and X are supposed to be treated as unsigned values.
The divide instrunctions will generate an exception if the result cannot be
expressed with a 32 bit signed value.
This is the case if e.g. the dividend is 0xffffffff and the divisor either 1
or also 0xffffffff (signed: -1).
To avoid all these issues simply use unsigned divide instructions.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a25dda5b26eed2d9246f9dfb9e7459c935a28557
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Jan 15 06:50:07 2014 -0800
bpf: do not use reciprocal divide
[ Upstream commit aee636c4809fa54848ff07a899b326eb1f9987a2 ]
At first Jakub Zawadzki noticed that some divisions by reciprocal_divide
were not correct. (off by one in some cases)
http://www.wireshark.org/~darkjames/reciprocal-buggy.c
He could also show this with BPF:
http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c
The reciprocal divide in linux kernel is not generic enough,
lets remove its use in BPF, as it is not worth the pain with
current cpus.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jakub Zawadzki <darkjames-ws@darkjames.pl>
Cc: Mircea Gherzan <mgherzan@gmail.com>
Cc: Daniel Borkmann <dxchgb@gmail.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Matt Evans <matt@ozlabs.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e3b0f65e71dfa5c1a2e276f1a0df01a79aa07e3
Author: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Thu Jan 16 20:01:21 2014 +0100
tcp: metrics: Avoid duplicate entries with the same destination-IP
[ Upstream commit 77f99ad16a07aa062c2d30fae57b1fee456f6ef6 ]
Because the tcp-metrics is an RCU-list, it may be that two
soft-interrupts are inside __tcp_get_metrics() for the same
destination-IP at the same time. If this destination-IP is not yet part of
the tcp-metrics, both soft-interrupts will end up in tcpm_new and create
a new entry for this IP.
So, we will have two tcp-metrics with the same destination-IP in the list.
This patch checks twice __tcp_get_metrics(). First without holding the
lock, then while holding the lock. The second one is there to confirm
that the entry has not been added by another soft-irq while waiting for
the spin-lock.
Fixes: 51c5d0c4b169b (tcp: Maintain dynamic metrics in local cache.)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
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 c2d828a8e5dcea50926bde6277741aafb4ca4927
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date: Thu Jan 16 16:54:48 2014 +0100
net: rds: fix per-cpu helper usage
[ Upstream commit c196403b79aa241c3fefb3ee5bb328aa7c5cc860 ]
commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu
handling for rds. chpfirst is the result of __this_cpu_read(), so it is
an absolute pointer and not __percpu. Therefore, __this_cpu_write()
should not operate on chpfirst, but rather on cache->percpu->first, just
like __this_cpu_read() did before.
Signed-off-byd Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e9f138ed4e403136240d0ea3dce7167f14adcdba
Author: Richard Weinberger <richard@nod.at>
Date: Tue Jan 14 22:46:36 2014 +0100
net,via-rhine: Fix tx_timeout handling
[ Upstream commit a926592f5e4e900f3fa903298c4619a131e60963 ]
rhine_reset_task() misses to disable the tx scheduler upon reset,
this can lead to a crash if work is still scheduled while we're resetting
the tx queue.
Fixes:
[ 93.591707] BUG: unable to handle kernel NULL pointer dereference at 0000004c
[ 93.595514] IP: [<c119d10d>] rhine_napipoll+0x491/0x6
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d09a96563bed3178012014275aa3ff912a0b38ce
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon Jan 13 02:45:22 2014 +0100
net: avoid reference counter overflows on fib_rules in multicast forwarding
[ Upstream commit 95f4a45de1a0f172b35451fc52283290adb21f6e ]
Bob Falken reported that after 4G packets, multicast forwarding stopped
working. This was because of a rule reference counter overflow which
freed the rule as soon as the overflow happend.
This patch solves this by adding the FIB_LOOKUP_NOREF flag to
fib_rules_lookup calls. This is safe even from non-rcu locked sections
as in this case the flag only implies not taking a reference to the rule,
which we don't need at all.
Rules only hold references to the namespace, which are guaranteed to be
available during the call of the non-rcu protected function reg_vif_xmit
because of the interface reference which itself holds a reference to
the net namespace.
Fixes: f0ad0860d01e47 ("ipv4: ipmr: support multiple tables")
Fixes: d1db275dd3f6e4 ("ipv6: ip6mr: support multiple tables")
Reported-by: Bob Falken <NetFestivalHaveFun@gmx.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
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 e41b2fe81655f70c20b964d7b184be1469391320
Author: Christian Engelmayer <cengelma@gmx.at>
Date: Sat Jan 11 22:19:30 2014 +0100
ieee802154: Fix memory leak in ieee802154_add_iface()
[ Upstream commit 267d29a69c6af39445f36102a832b25ed483f299 ]
Fix a memory leak in the ieee802154_add_iface() error handling path.
Detected by Coverity: CID 710490.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dafceed284787a69622553eb2316c60500d5efb3
Author: Bjørn Mork <bjorn@mork.no>
Date: Fri Jan 10 23:10:17 2014 +0100
net: usbnet: fix SG initialisation
[ Upstream commit fdc3452cd2c7b2bfe0f378f92123f4f9a98fa2bd ]
Commit 60e453a940ac ("USBNET: fix handling padding packet")
added an extra SG entry in case padding is necessary, but
failed to update the initialisation of the list. This can
cause list traversal to fall off the end of the list,
resulting in an oops.
Fixes: 60e453a940ac ("USBNET: fix handling padding packet")
Reported-by: Thomas Kear <thomas@kear.co.nz>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f9e04ca1afe0b6faaef14ee6c65f2d9a8a6c5b7
Author: Michal Schmidt <mschmidt@redhat.com>
Date: Thu Jan 9 14:36:27 2014 +0100
bnx2x: fix DMA unmapping of TSO split BDs
[ Upstream commit 95e92fd40c967c363ad66b2fd1ce4dcd68132e54 ]
bnx2x triggers warnings with CONFIG_DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 2253 at lib/dma-debug.c:887 check_unmap+0xf8/0x920()
bnx2x 0000:28:00.0: DMA-API: device driver frees DMA memory with
different size [device address=0x00000000da2b389e] [map size=1490 bytes]
[unmap size=66 bytes]
The reason is that bnx2x splits a TSO BD into two BDs (headers + data)
using one DMA mapping for both, but it uses only the length of the first
BD when unmapping.
This patch fixes the bug by unmapping the whole length of the two BDs.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a81a0ae34d50bf9c15d9f4b233f81888a000650
Author: Shane Huang <shane.huang@amd.com>
Date: Wed Jan 22 14:05:46 2014 -0800
i2c: piix4: Add support for AMD ML and CZ SMBus changes
commit 032f708bc4f6da868ec49dac48ddf3670d8035d3 upstream.
The locations of SMBus register base address and enablement bit are changed
from AMD ML, which need this patch to be supported.
Signed-off-by: Shane Huang <shane.huang@amd.com>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 983565dcd368782495f3988e78888289e32f46b3
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Tue Dec 31 17:07:35 2013 +0100
i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
commit f8b94beb7e6a374cb0de531b72377c49857b35ca upstream.
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The commit introduces a new the compatible string
marvell,mv78230-a0-i2c for the i2c controller.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
cc: devicetree@vger.kernel.org
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6ab649440058e703f5d479cb390050937c3b1702
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Tue Dec 31 16:59:33 2013 +0100
i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
commit 6cf70ae928bae17077efc0d528dec49bc380438b upstream.
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The commit introduces a new the compatible string
marvell,mv78230-a0-i2c for the i2c controller. When this compatible
string is used the driver disables the offload mechanism and the
kernel no more hangs on these SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reported-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4496ba6f8961044812d6362426774c231bbe6df
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Tue Jan 7 16:26:01 2014 +0100
ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
commit 85e618a1be2b2092318178d1d66bdad49cbbeeeb upstream.
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
This commit add quirk in the mvebu platform code to check the SoC
version and then update the compatible string for the i2c controller
according to the revision of the SoC. Currently only some OpenBlocks
AX3-4 boards are known to use an A0 revision so the check is done only
for these boards.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 710398e3b203763d847a6310a65006bba7205d27
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Thu Jan 2 15:08:59 2014 +0100
ARM: mvebu: Add support to get the ID and the revision of a SoC
commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream.
All the mvebu SoCs have information related to their variant and
revision that can be read from the PCI control register.
This patch adds support for Armada XP and Armada 370. This reading of
the revision and the ID are done before the PCI initialization to
avoid any conflicts. Once these data are retrieved, the resources are
freed to let the PCI subsystem use it.
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 603d05037dc89f1a827c7c5c0e4427bacf077b36
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Jan 13 12:32:44 2014 +0100
hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
commit b0ad4ff35d479a46a3b995a299db9aeb097acfce upstream.
The DriveGuard chips on the new HP laptops are with a new PnP ID
"HPQ6007". It should be compatible with older chips.
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 34976229092cd9a28afdbffbf79b8dfc823c6cf0
Author: Minchan Kim <minchan@kernel.org>
Date: Thu Jan 30 15:45:58 2014 -0800
zram: fix race between reset and flushing pending work
commit da4a04126baa3be03bc566d4a2ee0944c5e783d0 upstream.
Dan and Sergey reported that there is a racy between reset and flushing
of pending work so that it could make oops by freeing zram->meta in
reset while zram_slot_free can access zram->meta if new request is
adding during the race window.
This patch moves flush after taking init_lock so it prevents new request
so that it closes the race.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.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 6273bd307165a7f773c3ba5f0278e9ec51a5b2b8
Author: Kent Overstreet <kmo@daterainc.com>
Date: Tue Dec 17 17:51:02 2013 -0800
bcache: Data corruption fix
commit ef71ec00002d92a08eb27e9d036e3d48835b6597 upstream.
The code that handles overlapping extents that we've just read back in from disk
was depending on the behaviour of the code that handles overlapping extents as
we're inserting into a btree node in the case of an insert that forced an
existing extent to be split: on insert, if we had to split we'd also insert a
new extent to represent the top part of the old extent - and then that new
extent would get written out.
The code that read the extents back in thus not bother with splitting extents -
if it saw an extent that ovelapped in the middle of an older extent, it would
trim the old extent to only represent the bottom part, assuming that the
original insert would've inserted a new extent to represent the top part.
I still haven't figured out _how_ it can happen, but I'm now pretty convinced
(and testing has confirmed) that there's some kind of an obscure corner case
(probably involving extent merging, and multiple overwrites in different sets)
that breaks this. The fix is to change the mergesort fixup code to split extents
itself when required.
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 441d2e3031a3d6c3dc18ebc4f79d09ccb9b208ed
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Mon Jan 20 15:26:15 2014 -0800
vfs: Is mounted should be testing mnt_ns for NULL or error.
commit 260a459d2e39761fbd39803497205ce1690bc7b1 upstream.
A bug was introduced with the is_mounted helper function in
commit f7a99c5b7c8bd3d3f533c8b38274e33f3da9096e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Jun 9 00:59:08 2012 -0400
get rid of ->mnt_longterm
it's enough to set ->mnt_ns of internal vfsmounts to something
distinct from all struct mnt_namespace out there; then we can
just use the check for ->mnt_ns != NULL in the fast path of
mntput_no_expire()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The intent was to test if the real_mount(vfsmount)->mnt_ns was
NULL_OR_ERR but the code is actually testing real_mount(vfsmount)
and always returning true.
The result is d_absolute_path returning paths it should be hiding.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 87df85def4003d893fe099c4011ecf1ee5c2582f
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Mon Jan 20 15:43:25 2014 -0800
vfs: Remove second variable named error in __dentry_path
commit a8323da0366d3398eda62741d2ac1130c8a172ed upstream.
In commit 232d2d60aa5469bb097f55728f65146bd49c1d25
Author: Waiman Long <Waiman.Long@hp.com>
Date: Mon Sep 9 12:18:13 2013 -0400
dcache: Translating dentry into pathname without taking rename_lock
The __dentry_path locking was changed and the variable error was
intended to be moved outside of the loop. Unfortunately the inner
declaration of error was not removed. Resulting in a version of
__dentry_path that will never return an error.
Remove the problematic inner declaration of error and allow
__dentry_path to return errors once again.
Cc: Waiman Long <Waiman.Long@hp.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 842408e7c7835d67c5eab0867fdd6b4676dc11bd
Author: Theodore Ts'o <tytso@mit.edu>
Date: Tue Jan 7 12:58:19 2014 -0500
ext4: avoid clearing beyond i_blocks when truncating an inline data file
commit 09c455aaa8f47a94d5bafaa23d58365768210507 upstream.
A missing cast means that when we are truncating a file which is less
than 60 bytes, we don't clear the correct area of memory, and in fact
we can end up truncating the next inode in the inode table, or worse
yet, some other kernel data structure.
Addresses-Coverity-Id: #751987
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ac25d5623b1ead9d3cd0981c668e97d26b2bef2
Author: Tejun Heo <tj@kernel.org>
Date: Thu Jan 16 09:47:17 2014 -0500
libata: disable LPM for some WD SATA-I devices
commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.
For some reason, some early WD drives spin up and down drives
erratically when the link is put into slumber mode which can reduce
the life expectancy of the device significantly. Unfortunately, we
don't have full list of devices and given the nature of the issue it'd
be better to err on the side of false positives than the other way
around. Let's disable LPM on all WD devices which match one of the
known problematic model prefixes and are SATA-I.
As horkage list doesn't support matching SATA capabilities, this is
implemented as two horkages - WD_BROKEN_LPM and NOLPM. The former is
set for the known prefixes and sets the latter if the matched device
is SATA-I.
Note that this isn't optimal as this disables all LPM operations and
partial link power state reportedly works fine on these; however, the
way LPM is implemented in libata makes it difficult to precisely map
libata LPM setting to specific link power state. Well, these devices
are already fairly outdated. Let's just disable whole LPM for now.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Nikos Barkas <levelwol@gmail.com>
Reported-and-tested-by: Ioannis Barkas <risc4all@yahoo.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 72caa216dc85afa30a26ae0d48a3b30b21e9b506
Author: Simon Guinot <simon.guinot@sequanux.org>
Date: Tue Jan 14 20:10:27 2014 +0100
ARM: mvebu: update the SATA compatible string for Armada 370/XP
commit a96cc303e42ad7830dde929aad0046e448a05505 upstream.
This patch updates the Armada 370/XP SATA node with the new compatible
string "marvell,armada-370-sata".
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Lior Amsalem <alior@marvell.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f26e0352f4b04edefd9cb7c40e0782f9faa3698
Author: Lior Amsalem <alior@marvell.com>
Date: Tue Jan 14 20:09:57 2014 +0100
ata: sata_mv: fix disk hotplug for Armada 370/XP SoCs
commit 9013d64e661fc2a37a1742670202171c27fef4b5 upstream.
On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the
re-plug events are not detected by the sata_mv driver. This patch fixes
the issue by updating the PHY speed in the LP_PHY_CTL register (0x58)
according to the SControl speed.
Note that this fix is only applied if the compatible string
"marvell,armada-370-sata" is found in the SATA DT node.
Fixes: 9ae6f740b49f ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT")
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4eb601c2edae46928fed973aec7cd257d74b56f9
Author: Simon Guinot <simon.guinot@sequanux.org>
Date: Tue Jan 14 20:04:39 2014 +0100
ata: sata_mv: introduce compatible string "marvell, armada-370-sata"
commit b1f5c73bd5a4752efb7d7af019034044b08aafe9 upstream.
The sata_mv driver supports the SATA IP found in several Marvell SoCs.
As some new SATA registers have been introduced with the Armada 370/XP
SoCs, a way to identify them is needed.
This patch introduces a new compatible string for the SATA IP found in
Armada 370/XP SoCs.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Lior Amsalem <alior@marvell.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 008ec9d9293b6738e90444aa21993d5def8f2d85
Author: Peter Huewe <PeterHuewe@gmx.de>
Date: Wed Oct 30 20:46:55 2013 +0100
tpm/tpm_ppi: Do not compare strcmp(a,b) == -1
commit 747d35bd9bb4ae6bd74b19baa5bbe32f3e0cee11 upstream.
Depending on the implementation strcmp might return the difference between
two strings not only -1,0,1 consequently
if (strcmp (a,b) == -1)
might lead to taking the wrong branch
-> compare with < 0 instead,
which in any case is more canonical.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e0383660eb2692180b23a8b833fd8b13c602de28
Author: Peter Huewe <PeterHuewe@gmx.de>
Date: Wed Oct 30 00:54:20 2013 +0100
tpm/tpm_i2c_stm_st33: Check return code of get_burstcount
commit 85c5e0d451125c6ddb78663972e40af810b83644 upstream.
The 'get_burstcount' function can in some circumstances 'return -EBUSY' which
in tpm_stm_i2c_send is stored in an 'u32 burstcnt'
thus converting the signed value into an unsigned value, resulting
in 'burstcnt' being huge.
Changing the type to u32 only does not solve the problem as the signed
value is converted to an unsigned in I2C_WRITE_DATA, resulting in the
same effect.
Thus
-> Change type of burstcnt to u32 (the return type of get_burstcount)
-> Add a check for the return value of 'get_burstcount' and propagate a
potential error.
This makes also sense in the 'I2C_READ_DATA' case, where the there is no
signed/unsigned conversion.
found by coverity
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 898e49a224c935709db86fada5dce191b5777a1d
Author: Adrien Vergé <adrienverge@gmail.com>
Date: Fri Jan 24 14:56:14 2014 -0500
ALSA: hda - Fix silent output on MacBook Air 1,1
commit e7729a415315fcd9516912050d85d5aaebcededc upstream.
Similarly to other Apple products, MBA 1,1 needs a specific quirk.
Pin 0x18 must be set to VREF_50 to have sound output. This was no
longer done since commit 1a97b7f, resulting in a mute built-in speaker.
This patch corrects the regression by creating a fixup for the MBA 1,1.
Fixes: 1a97b7f22774 ("ALSA: hda/realtek - Remove the last static quirks for ALC882")
Tested-by: Adrien Vergé <adrienverge@gmail.com>
Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dfcede768466b6a0c39128a25541f2f0db6f42bd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu Jan 23 11:21:28 2014 +0300
ALSA: bits vs bytes bug in snd_card_create()
commit 4c3773eda49c872a3034382f8ec3080002e715bf upstream.
The test here is intended intended to prevent shift wrapping bugs when
we do "1U << idx2". We should consider the number of bits in a u32
instead of the number of bytes.
[fix another chunk similarly by tiwai]
Fixes: 7bb2491b35a2 ('ALSA: Add kconfig to specify the max card numbers')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a3e79cff3880637211431a0858c796070f3bc1c7
Author: Takashi Iwai <tiwai@suse.de>
Date: Fri Jan 10 14:20:42 2014 +0100
ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks
commit 80ab8eae70e51d578ebbeb228e0f7a562471b8b7 upstream.
The PCI devices with DMA masks smaller than 32bit should enable
CONFIG_ZONE_DMA. Since the recent change of page allocator, page
allocations via dma_alloc_coherent() with the limited DMA mask bits
may fail more frequently, ended up with no available buffers, when
CONFIG_ZONE_DMA isn't enabled. With CONFIG_ZONE_DMA, the system has
much more chance to obtain such pages.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e15339e11c028e87d22cf1f50d3ef21964938179
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Jan 7 18:11:44 2014 +0100
ALSA: hda - Don't create duplicated ctls for loopback paths
commit 43a8e50a46a4e1dd1451e4a4ffa1f7695fb7d287 upstream.
AD1986A mic pins (0x1d and 0x1f) share the same widget for controlling
the loopback volume/mute, but the generic parser didn't check it.
This ended up with the duplicated controls for the same effect.
This patch adds the check of the duplication for avoiding it.
After this fix, there will be only one control although it affects
both paths; this remaining issue should be fixed later in a different
patch.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a8015c470e1119a47d55bab83a9c01480714609e
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Jan 7 17:48:11 2014 +0100
ALSA: hda - Correct AD1986A 3stack pin configs
commit ed0e0d0617a8dc3d8b82c6e54827f269f2247b07 upstream.
The 3stack pin configs for AD1986A codec had incorrect values that
resulted in broken mic and line-in.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9719e743d1464b778c5faaf22218ebbe7e9b6a53
Author: Takashi Iwai <tiwai@suse.de>
Date: Fri Dec 27 00:13:08 2013 +0200
ALSA: rme9652: fix a missing comma in channel_map_9636_ds[]
commit 770bd4bf2e664939a9dacd3d26ec9ff7a3933210 upstream.
The lack of comma leads to the wrong channel for an SPDIF channel.
Unfortunately this wasn't caught by compiler because it's still a
valid expression.
Reported-by: Alexander Aristov <aristov.alexander@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f5cf0a30b78fd89d789760f6be10fd38224452fb
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue Jan 21 16:27:51 2014 +0000
ASoC: wm5110: Extend SYSCLK patch file for rev D
commit 34354792432b6e0a3b156819a1a19716c50d3473 upstream.
Latest evaluation of the the device has given some patch file additions
for improved performance.
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 dcee3420048bc06242d6229b392ed517b2836aa6
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Wed Jan 8 11:22:25 2014 +0100
ASoC: adau1701: Fix ADAU1701_SEROCTL_WORD_LEN_16 constant
commit e20970ada3f699c113fe64b04492af083d11a7d8 upstream.
The driver defines ADAU1701_SEROCTL_WORD_LEN_16 as 0x10 while it should be b10,
so 0x2. This patch fixes it.
Reported-by: Magnus Reftel <magnus.reftel@lockless.no>
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 62350c32e91d3b074a515b3b90b0fe6e09c20384
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Dec 20 10:35:07 2013 +0100
mfd: max77686: Fix regmap resource leak on driver remove
commit 74142ffc0b52cfe6f9d2f6f34a5f3eedbfe3ce51 upstream.
The regmap used by max77686 MFD driver was not freed with regmap_exit()
on driver exit. This lead to leak of resources.
Replace regmap_init_i2c() call in driver probe with initialization of
managed register map so the regmap will be properly freed by the device
management code.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26991248a1e553068c935036947ae2d66d452fb5
Author: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Date: Fri Dec 20 13:41:47 2013 -0500
perf kvm: Fix kvm report without guestmount.
commit ad85ace07a05062ef6b59c35a5e80b6eaee1eee6 upstream.
Currently, if we use perf kvm --guestkallsyms --guestmodules report, we
can not get the perf information from perf data file. All sample are
shown as unknown.
Reproducing steps:
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 samples) ]
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules report |grep %
100.00% [guest/6471] [unknown] [g] 0xffffffff8164f330
This bug was introduced by 207b57926 (perf kvm: Fix regression with guest machine creation).
In original code, it uses perf_session__find_machine(), it means we deliver symbol to machine
which has the same pid, if no machine found, deliver it to *default* guest. But if we use
perf_session__findnew_machine() here, if no machine was found, new machine with pid will be built
and added. Then the default guest which with pid == 0 will never get a symbol.
And because the new machine initialized here has no kernel map created, the symbol delivered to
it will be marked as "unknown".
This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in another way.
Verification steps:
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 samples) ]
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules report |grep %
22.64% :6471 [guest.kernel.kallsyms] [g] update_rq_clock.part.70
19.99% :6471 [guest.kernel.kallsyms] [g] d_free
18.46% :6471 [guest.kernel.kallsyms] [g] bio_phys_segments
16.25% :6471 [guest.kernel.kallsyms] [g] dequeue_task
12.78% :6471 [guest.kernel.kallsyms] [g] __switch_to
7.91% :6471 [guest.kernel.kallsyms] [g] scheduler_tick
1.75% :6471 [guest.kernel.kallsyms] [g] native_apic_mem_write
0.21% :6471 [guest.kernel.kallsyms] [g] apic_timer_interrupt
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Link: http://lkml.kernel.org/r/1387564907-3045-1-git-send-email-yangds.fnst@cn.fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89de7377112f8e062924d190362b8820fd90903d
Author: Chen-Yu Tsai <wens@csie.org>
Date: Thu Jan 16 14:34:23 2014 +0800
pinctrl: sunxi: Honor GPIO output initial vaules
commit fa8cf57c923e86a693a85aff1df579245a27cbb3 upstream.
Some GPIO users, such as fixed-regulator, request GPIO output with
initial value of 1. This was ignored by sunxi driver.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 94a99ec83ac3cfb36c33d3583d7f14cbc7c612f4
Author: Stephen Warren <swarren@nvidia.com>
Date: Thu Jan 23 15:55:19 2014 -0800
rtc: max8907: weekday encoding fixes
commit 75ea799df4cb07e505c91b4abaa87bc28aad3e66 upstream.
The current MAX8907 driver has two issues related to weekday value
handling:
1)
The HW WEEKDAY register has range 0..6 rather than 1..7 as documented.
Note that I validated the actual HW range by observing the HW register
roll from 6->0 rather than 6->7->1 as would otherwise be expected.
This matches Linux's tm_wday range of 0..6.
When the CMOS RAM content is lost, the date returned from the device is
2007-01-01 00:00:00, which is a Monday. The WEEKDAY register reads 1 in
this case. This matches the numbering in Linux's tm_wday field.
Hence we should write Linux's tm_wday value to the register without
modifying it. Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday.
2)
There's no need to make alarms match on the WEEKDAY register, since the
other fields together uniquely define the alarm date/time. Ignoring the
WEEKDAY value in the match isolates the driver from any incorrect value in
the current time copy of the WEEKDAY register.
Each change individually, or both together, solves an issue that I
observed; "hwclock -r" would time out waiting for its alarm to fire if the
CMOS RAM content had been lost, and hence the WEEKDAY register value
mismatched what the driver expected it to be. "hwclock -w" would solve
this by over-writing the HW default WEEKDAY register value with what the
driver expected.
Signed-off-by: Stephen Warren <swarren@nvidia.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 205744c9418264b706f6e753b5cc62ecb38a6804
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed Nov 27 17:43:43 2013 +0100
parport: parport_pc: remove double PCI ID for NetMos
commit d6a484520c5572a4170fa915109ccfc0c38f5008 upstream.
In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added
the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which
was at the v2.4.26 time frame. The patch made into 2.6.14.
Shortly before that patch akpm merged commit 296d3c783b ("[PATCH] Support
NetMOS based PCI cards providing serial and parallel ports") which made
into v2.6.9-rc1.
Now we have two different entries for the same PCI id.
I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode.
This patch takes Max's entry for titan_1284p1 (base != -1 specifies the
ioport for ECP mode) and replaces akpm's entry for netmos_9805 which
specified -1 (=none). Both share the same PCI-ID (my card has subsystem
0x1000 / 0x0020 so it should match PCI_ANY).
While here I also drop the entry for titan_1284p2 which is the same as
netmos_9815.
Cc: Maximilian Attems <maks@stro.at>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f7faf39df54a38b542659b3504ee3ab8003324d8
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Tue Jan 21 17:31:10 2014 +0100
s390/uapi: fix struct statfs64 definition
commit 4e078146dff728f4865270a47710d57797e81eb6 upstream.
With b8668fd0a7e1b59f "s390/uapi: change struct statfs[64] member types
to unsigned values" the size of a couple of struct statfs64 member got
incorrectly changed from 64 to 32 bit for 32 bit builds.
Fix this by changing the type of couple of struct statfs64 members from
unsigned long to unsigned long long.
The definition of struct compat_statfs64 was correct however.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bd6307cab16209fabb96feb236b808c46e2d22d
Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
Date: Mon Dec 9 18:30:01 2013 +0100
KVM: s390: ioeventfd: ignore leftmost bits
commit ff1f3cb4b3ac5d039f02679f34cb1498d110d241 upstream.
The diagnose 500 subcode 3 contains the 32 bit subchannel id in bits 32-63
(counting from the left). As for other I/O instructions, bits 0-31 should be
ignored and thus not be passed to kvm_io_bus_write_cookie().
This fixes a bug where the guest passed non-zero bits 0-31 which the
host tried to interpret, leading to ioeventfd notification failures.
Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0cadc7231408c3edbe17f0fbfa6d3d721f06f07
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Mon Nov 11 13:56:47 2013 +0100
KVM: s390: fix diagnose code extraction
commit 743db27c526e0f31cc507959d662e97e2048a86f upstream.
The diagnose code to be used is the contents of the base register (if not
zero), plus the displacement. The current code ignores the base register
contents. So let's fix that...
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7a11402ab28c099eccfa2d34c0653f89a99b272
Author: Stephen Warren <swarren@nvidia.com>
Date: Tue Jan 7 15:00:12 2014 -0700
serial: 8250: enable UART_BUG_NOMSR for Tegra
commit 3685f19e07802ec4207b52465c408f185b66490e upstream.
Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
their MODEM-control signals tied off to a static state. However UARTs A
and B can optionally route those signals to/from package pins, depending
on the exact pinmux configuration.
When these signals are not routed to package pins, false interrupts may
trigger either temporarily, or permanently, all while not showing up in
the IIR; it will read as NO_INT. This will eventually lead to the UART
IRQ being disabled due to unhandled interrupts. When this happens, the
kernel may print e.g.:
irq 68: nobody cared (try booting with the "irqpoll" option)
In order to prevent this, enable UART_BUG_NOMSR. This prevents
UART_IER_MSI from being enabled, which prevents the false interrupts
from triggering.
In practice, this is not needed under any of the following conditions:
* On Tegra chips after Tegra30, since the HW bug has apparently been
fixed.
* On UARTs C..E since their MODEM control signals are tied to the correct
static state which doesn't trigger the issue.
* On UARTs A..B if the MODEM control signals are routed out to package
pins, since they will then carry valid signals.
However, we ignore these exceptions for now, since they are only relevant
if a board actually hooks up more than a 4-wire UART, and no currently
supported board does this. If we ever support a board that does, we can
refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
into account, and/or read a flag from DT/... that indicates that the
board has hooked up and pinmux'd more than a 4-wire UART.
Reported-by: Olof Johansson <olof@lixom.net> # autotester
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aee1455b10f1e744389e9d2a3b7aaec190599bf6
Author: Jonathan Woithe <jwoithe@just42.net>
Date: Mon Dec 9 16:33:08 2013 +1030
serial: 8250: Fix initialisation of Quatech cards with the AMCC PCI chip
commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream.
Fix the initialisation of older Quatech serial cards which are fitted with
the AMCC PCI Matchmaker interface chip.
Signed-off-by: Jonathan Woithe (jwoithe@just42.net)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d6289a3303010809ac152e19fd93160d1591a54
Author: Yegor Yefremov <yegorslists@googlemail.com>
Date: Mon Dec 9 12:11:15 2013 +0100
serial: add support for 200 v3 series Titan card
commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 201a3fa8b289b490886aa3f5cf508af165152a42
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Mon Jan 6 13:07:03 2014 -0800
xhci: Set scatter-gather limit to avoid failed block writes.
commit f2d9b991c549f159dc9ae81f77d8206c790cbfee upstream.
Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB
must not occur within a USB payload burst" attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices. The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).
usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:
http://marc.info/?l=linux-usb&m=138498190419312&w=2
That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63
...
Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00
Limit the number of scatter-gather entries to half a ring segment. That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst')
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7104ed26ac349d1ed2e7d9b8716100823477ab4
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Mon Jan 6 03:16:32 2014 +0000
xhci: Avoid infinite loop when sg urb requires too many trbs
commit d6c9ea9069af684358efedcaf2f2f687f51c58ee upstream.
Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment. usb_sg_wait() treats this error as a temporary
condition and will keep retrying until something else goes wrong.
The number of retries should be limited in usb_sg_wait(), but also
prepare_ring() should not return an error code that suggests it might
be worth retrying. Change it to -EINVAL.
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c7d51ca3d6acdcd3fa0aff2e6f6a7bdfb8e2d85
Author: Phil Pokorny <ppokorny@penguincomputing.com>
Date: Tue Jan 14 10:46:46 2014 -0800
hwmon: (k10temp) Add support for Kaveri CPUs
commit d303b1b5fbb688282bbf72a534b9dfed7af9fe4f upstream.
Add new PCI ID to support new model "Kaveri" family.
Signed-off-by: Philip Pokorny <ppokorny@penguincomputing.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1206f81de978fed1ce9f3e401e8965e0eeb93b5c
Author: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Date: Thu Jan 9 16:01:54 2014 +0100
ARM: at91: smc: bug fix in sam9_smc_cs_read()
commit 1588c51cf6d782e63a8719681d905ef0ac22ee62 upstream.
There was a copy/paste error when reading the nwe_pulse value.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 63e03c0954658a46d17fe8a895cace1410542e76
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date: Fri Nov 22 14:49:52 2013 +0100
ARM: at91: at91sam9g45: set default mmc pinctrl-names
commit 0645b93f6c223b594c0dca348e2ae0a23bccf6e3 upstream.
pinctrl-names property was missing from mmc nodes.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2d328c95bef7063598b5663f2024d3e245d19ffb
Author: Marek Roszko <mark.roszko@gmail.com>
Date: Fri Jan 10 10:33:11 2014 +0100
tty/serial: at91: disable uart timer at start of shutdown
commit 8bc661bfc0c2d221e209f4205bdaaf574d50100c upstream.
The uart timer will schedule a tasklet when it fires. It is possible that it
can fire inside _shutdown before it is killed in the dma and pdc cleanup
routines. This causes a tasklet that exists after the port is shutdown, so when
the kernel finally executes it, it panics as the tty port is NULL.
This is a somewhat rare condition but its possible if a program keeps on
opening/closing the port. It has been observed in particular with systemd
boot messages that were causing a kernel panic because of this behavior.
Moving the timer deletion to the beginning of the function stops a tasklet from
being scheduled unexpectedly.
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
[nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6bdf61a056192cf6bb4cf13a1bae5e9b7bc9c4e2
Author: Mark Deneen <mdeneen@gmail.com>
Date: Tue Jan 7 11:45:09 2014 +0100
tty/serial: at91: reset rx_ring when port is shutdown
commit bb7e73c598fb226c75f7625088a8f6a45a0fc892 upstream.
When using RX DMA, the driver won't pass any data to the uart layer
until the buffer is flipped. When the port is shutdown, the dma buffers
are unmapped, but the head and tail of the ring buffer are not reseted.
Since the serial console will keep the port open, this will only
present itself when the uart is not shared.
To reproduce the issue, with an unpatched driver, run a getty on /dev/ttyS0
with no serial console and exit. Getty will exit, and when the new one returns
you will be unable to log in. If you hold down a key long enough to fill the
DMA buffer and flip it, you can then log in.
Signed-off-by: Mark Deneen <mdeneen@gmail.com>
Acked-by: Leilei Zhao <leilei.zhao@atmel.com>
[nicolas.ferre@atmel.com: adapt to mainline kernel, handle !DMA case]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aef9c8df1165ac2b19079c109361b2db8434571b
Author: Marek Roszko <mark.roszko@gmail.com>
Date: Tue Jan 7 11:45:07 2014 +0100
tty/serial: at91: fix race condition in atmel_serial_remove
commit f50c995f9ebf064cea1368bf361c4e29679415b4 upstream.
The _remove callback could be called when a tasklet is scheduled. tasklet_kill
was called inside the function in order to free up any scheduled tasklets.
However it was called after uart_remove_one_port which destroys tty references
needed in the port for atmel_tasklet_func.
Simply putting the tasklet_kill at the start of the function will prevent this
conflict.
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
Acked-by: Leilei Zhao <leilei.zhao@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c543d348038c69312d6e9589146922e690e7a725
Author: Marek Roszko <mark.roszko@gmail.com>
Date: Tue Jan 7 11:45:06 2014 +0100
tty/serial: at91: Handle shutdown more safely
commit 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream.
Interrupts were being cleaned up late in the shutdown handler, it is possible
that an interrupt can occur and schedule a tasklet that runs after the port is
cleaned up. There is a null dereference due to this race condition with the
following stacktrace:
[<c02092b0>] (atmel_tasklet_func+0x514/0x814) from [<c001fd34>] (tasklet_action+0x70/0xa8)
[<c001fd34>] (tasklet_action+0x70/0xa8) from [<c001f60c>] (__do_softirq+0x90/0x144)
[<c001f60c>] (__do_softirq+0x90/0x144) from [<c001fa18>] (irq_exit+0x40/0x4c)
[<c001fa18>] (irq_exit+0x40/0x4c) from [<c000e298>] (handle_IRQ+0x64/0x84)
[<c000e298>] (handle_IRQ+0x64/0x84) from [<c000d6c0>] (__irq_svc+0x40/0x50)
[<c000d6c0>] (__irq_svc+0x40/0x50) from [<c0208060>] (atmel_rx_dma_release+0x88/0xb8)
[<c0208060>] (atmel_rx_dma_release+0x88/0xb8) from [<c0209740>] (atmel_shutdown+0x104/0x160)
[<c0209740>] (atmel_shutdown+0x104/0x160) from [<c0205e8c>] (uart_port_shutdown+0x2c/0x38)
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
Acked-by: Leilei Zhao <leilei.zhao@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0121cc1144c36a651d1528b4579413f078934cf
Author: Tomas Winkler <tomas.winkler@intel.com>
Date: Wed Jan 8 20:19:22 2014 +0200
mei: use hbm idle state to prevent spurious resets
commit 66ae460b13c31a176b41550259683c841a62af3e upstream.
When reset is caused by hbm protocol mismatch or timeout
we might end up in an endless reset loop and hbm protocol
will never sync
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b72ac0b363f9039e4f03fce4a8dcb47bb8ccef5d
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date: Wed Jan 1 19:19:28 2014 +0000
staging: vt6656: CARDqGetNextTBTT correct uLowNextTBTT
commit 9acec059c0cef0bf086c738f4c0b1f4447782a48 upstream.
value uLowNextTBTT yields wrong value.
ULL is needed with qwTSF
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 95034a45badff94f237a20d74aef1211f436c586
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date: Sun Dec 8 09:11:30 2013 +0000
staging: vt6656: [BUG] BBvUpdatePreEDThreshold Always set sensitivity on bScanning
commit 8f248dae133668bfb8e9379b4b3f0571c858b24a upstream.
byBBPreEDIndex value is initially 0, this means that from
cold BBvUpdatePreEDThreshold is never set.
This means that sensitivity may be in an ambiguous state,
failing to scan any wireless points or at least distant ones.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01e084b82fab8ec22ea03f32bbf3c4d97d1edea3
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Tue Dec 24 11:22:54 2013 -0600
staging: r8712u: Set device type to wlan
commit 3a21f00a5002b14e4aab52aef59d33ed28468a13 upstream.
The latest version of NetworkManager does not recognize the device as wireless
without this change.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 226c54c6f7acb651d1d77635ffce0e9e6fccf7cb
Author: Amir Shehata <amir.shehata@intel.com>
Date: Tue Dec 3 21:58:47 2013 +0800
staging/lustre/ptlrpc: Fix a crash when dereferencing NULL pointer
commit 3c92a0bf4d72737035a16c4fe357ccd439c9b7d2 upstream.
When a system runs out of memory and the function
ptlrpc_register_bulk() is called from ptl_send_rpc() the call to
LNetMEAttach() fails due to failure to allocate memory. This forces
the code into an error path, which most probably previously went
untested. The error path:
if (rc != 0) {
CERROR("%s: LNetMEAttach failed x"LPU64"/%d: rc = %dn",
desc->bd_export->exp_obd->obd_name, xid,
posted_md, rc);
break;
}
This print assumes that desc->bd_export is not NULL. However, it is.
In fact it is expected to be NULL. desc->bd_import is the correct
structure to access in this case.
Lustre-change: http://review.whamcloud.com/7121
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3585
Signed-off-by: Amir Shehata <amir.shehata@intel.com>
Reviewed-by: Liang Zhen <liang.zhen@intel.com>
Reviewed-by: Doug Oucharek <doug.s.oucharek@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9afc8978c96a9c8b21858e8b950efd492c1011ce
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date: Thu Jan 9 08:51:15 2014 +0530
ath9k: Disable cross-band FCC
commit 1e2f9295f4c657500111514f92a3d3894d0e05b4 upstream.
Fast Channel Change across bands was enabled for
AR9462 recently, but this is causing baseband issues.
Disable it until this feature is tested well. Also,
remove the feature bit for AR9565 since it is
a single-band card and doesn't support this feature.
Reported-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit df590d884ef9a0d85c1fd53a97cc54bb0f5341a7
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date: Thu Jan 9 08:51:14 2014 +0530
ath9k: Use correct channel for RX packets
commit ff9a93f2ebb88ac7aab9568de80b64b92078e96d upstream.
Accessing the current channel definition in mac80211
when processing RX packets is problematic because it
could have been updated when a scan is issued. Since a
channel change involves flushing the existing packets
in the RX queue before a chip-reset is done, they would
be processed using the wrong band/channel information.
To avoid this, use the current channel information
maintained in the driver.
Reported-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5425534d6b0e9036ee5a6954b1fb53cac371b16b
Author: ZHAO Gang <gamerh2o@gmail.com>
Date: Sat Jan 18 00:17:38 2014 +0800
b43: fix the wrong assignment of status.freq in b43_rx()
commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream.
Use the right function to update frequency value.
If rx skb is probe response or beacon, the wrong frequency value can
cause problem that bss info can't be updated when it should be.
Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211 and driver conversion")
Signed-off-by: ZHAO Gang <gamerh2o@gmail.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 070b6fdbde673f5995997d7cf94786bb9ed435ef
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Sun Jan 12 15:11:39 2014 -0600
b43legacy: Fix unload oops if firmware is not available
commit 452028665312672c6ba9e16a19248ee00ead9400 upstream.
The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.
Signed-off-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 ac44c9e127d1c1452441af52eed1a55515bf10bd
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Sun Jan 12 15:11:38 2014 -0600
b43: Fix unload oops if firmware is not available
commit 0673effd41dba323d6a280ef37b5ef29f3f5a653 upstream.
The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.
To be able to access the completion structure at teardown, it had to be moved
into the b43_wldev structure.
This patch also fixes a typo in a comment.
Signed-off-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 166da381bb32cdb0873c81f9fc918ec41bcde63c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Sun Jan 12 15:11:37 2014 -0600
b43: Fix lockdep splat
commit 09164043f63c947a49797750a09ca1cd7c31108e upstream.
In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported
when b43 is used with hostapd, and rfkill is used to kill the radio output.
The lockdep splat (in part) is as follows:
======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0 #1 Not tainted
-------------------------------------------------------
rfkill/10040 is trying to acquire lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff8146f282>] rtnl_lock+0x12/0x20
but task is already holding lock:
(rfkill_global_mutex){+.+.+.}, at: [<ffffffffa04832ca>] rfkill_fop_write+0x6a/0x170 [rfkill]
--snip--
Chain exists of:
rtnl_mutex --> misc_mtx --> rfkill_global_mutex
The fix is to move the initialization of the hardware random number generator
outside the code range covered by the rtnl_mutex.
Reported-by: yury <urykhy@gmail.com>
Tested-by: yury <urykhy@gmail.com>
Signed-off-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 e573278e05b773fc66c78f6c7aa4a377379010e7
Author: Eliad Peller <eliadx.peller@intel.com>
Date: Sun Jan 5 12:41:12 2014 +0200
iwlwifi: mvm: fix missing cleanup in .start() error path
commit 91b0d1198417cf4fd9a7bd4138b6909f0b359099 upstream.
Cleanup of iwl_mvm_leds was missing in case of error,
resulting in the following warning:
WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x210()
kobject_add_internal failed for phy0-led with -EEXIST, don't try to register things with the same name in the same directory.
which prevents further reloads of the driver.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0880e59a45b2ac82dbaaf0cbed9075ae5ce134bf
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Tue Dec 24 14:15:41 2013 +0200
iwlwifi: pcie: enable oscillator for L1 exit
commit 2d93aee152b1758a94a18fe15d72153ba73b5679 upstream.
Enabling the oscillator consumes slightly more power (100uA)
but allows to make sure that we exit from L1 on time.
Not doing so might lead to a PCIe specification violation
since we might wake up from L1 at the wrong time.
This issue has been identified on 3160 and 7260 only.
On older NICs L1 off is not enabled, on newer NICs (7265),
the issue is fixed.
When the bug occurs the user sees that the NIC has
disappeared from the PCI bridge, any access to the device
returns 0xff.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=64541
and has been extensively discussed here:
http://markmail.org/thread/mfmpzqt3r333n4bo
Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration")
Reported-and-tested-by: wzyboy <wzyboy@wzyboy.org>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67d98b4f53e5509e912be53046088f332d6734e1
Author: Bing Zhao <bzhao@marvell.com>
Date: Tue Jan 14 19:16:34 2014 -0800
mwifiex: fix wrong 11ac bits setting in fw_cap_info
commit 1e202242ee1432d68a8bea4919b2ae0ef19d9e06 upstream.
bit 14 is actually reserved and bit 12 & 13 should be used for
11ac capability in fw_cap_info.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d5964fe3b7e85509e5d4dde619c2997ea21431d
Author: Amitkumar Karwar <akarwar@marvell.com>
Date: Fri Jan 10 14:30:41 2014 -0800
mwifiex: add missing endian conversion for fw_tsf
commit 9795229752c31da0c5f8a7dc4c827665327b52f9 upstream.
It is u64 data received from firmware. Little endian to cpu
conversion is required here.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d7f7f299d8ab8c3636f96b9cf945bdec3f02283e
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 25 10:45:28 2013 -0600
rtlwifi: rtl8188ee: Fix typo in code
commit f699273d6a624266ebc9198774f06ee64a3847a1 upstream.
The static analyser "cppcheck" shows the following typo:
drivers/net/wireless/rtlwifi/rtl8188ee/dm.c:1081]: (style) Same expression on both sides of '!='.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: David Binderman <dcb314@hotmail.com>
Cc: David Binderman <dcb314@hotmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 589e4795d83e17bdf85353117488e5c6238a0241
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:35 2013 -0600
rtlwifi: Add missing code to PWDB statics routine
commit d82403a9f407217b6aed5260aa92a120e8e98310 upstream.
Signed-off-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 cc05514f367be842adfb465ffe09c23a86c388e1
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:34 2013 -0600
rtlwifi: rtl8192cu: Fix some code in RF handling
commit e9b0784bb9de3152e787ee779868c626b137fb3b upstream.
Signed-off-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 3b4c79cf27bf597f899bff490e8e944581c0ea95
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:33 2013 -0600
rtlwifi: rtl8192cu: Update the power index registers
commit 9806eacf5de27ab01d680c5d75c92a3a89734e4f upstream.
This patch uses the newly introduced power index register routines.
Signed-off-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 301a10fe85598fa739fccc13d5d538de4e5a8ea0
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:32 2013 -0600
rtlwifi: rtl8192c: Add routines to save/restore power index registers
commit 97204e93f01868eeba6ae5c4f3270f32905bb418 upstream.
Signed-off-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 eb80a892ee5fbb9ff7637467347124f9d3194e55
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:30 2013 -0600
rtlwifi: Increase the RX queue length for USB drivers
commit dc6405712268fe514d3dd89aa936c4397b0871b9 upstream.
The current number of RX buffers queued is 32, which is too small under
heavy load. That number is doubled.
Signed-off-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 420304624575aec6221caeee8f1d32404226092a
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:29 2013 -0600
rtlwifi: rtl8192c: Add new definitions in the dm_common header
commit c908c74e005de780fddbe8cb6fcd44803f5d4b74 upstream.
Changes in the gain-control mechanism will require some changes in the header.
Signed-off-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 a7d9733c557dcab00ebfdffba6e05d56346aeb02
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:28 2013 -0600
rtlwifi: Set the link state
commit 619ce76f8bb850b57032501a39f26aa6c6731c70 upstream.
The present code fails to set the linked state when an interface is
added.
Signed-off-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 319ae9421e9272b967831f84f4f38d7d0c605496
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:27 2013 -0600
rtlwifi: Redo register save locations
commit b9a758a8c905fc59e783ae91ad645452d877ea88 upstream.
The initial USB driver did not use some register save locations in the
private data storage. To save some memory, a union was used to overlay these
variables with USB I/O components. In an update of the gain-control code,
these register save locations are now needed for USB drivers.
Signed-off-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 1f314ecffde9ddbe2fa874abd4010020cdc00eab
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:26 2013 -0600
rtlwifi: rtl8192cu: Add new firmware
commit 62009b7f12793c932aaba0df946b04cb4a77d022 upstream.
Vendor driver rtl8188C_8192C_8192D_usb_linux_v3.4.2_3727.20120404 introduced
new firmware for these chips. The code try for the new file, and fall back to
the original firmware if the new file is not available.
Signed-off-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 00dff61e1a6348dec19a3e5f14258d8ebc19ce80
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:25 2013 -0600
rtlwifi: rtl8192c: Prevent reconnect attempts if not connected
commit 8fd77aec1a9d6f4328fc0244f21932114e066df3 upstream.
This driver has a watchdog timer that attempts to reconnect when beacon frames
are not seen for 6 seconds. This patch disables that reconnect whenever the
device has never been connected.
Signed-off-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 2a056704386ebc3f58e37f5f467c6c61487d8d33
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Nov 18 11:11:31 2013 -0600
rtlwifi: Update beacon statistics for USB driver
commit 65b9cc97c6852fae19dc5c7745e9abc8dd380aad upstream.
The USB drivers were not updating the beacon statistics, which led to
false beacon loss indications.
Signed-off-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 0f77beebb5671da7ab357a39eab5fe19429a5ef3
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Thu Jan 9 10:27:27 2014 -0600
rtlwifi: rtl8192cu: Add new device ID
commit f87f960b2fb802f26ee3b00c19320e57a9c583ff upstream.
Reported-by: Jan Prinsloo <janroot@gmail.com>
Tested-by: Jan Prinsloo <janroot@gmail.com>
Signed-off-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 f5a67eedd6c513de2cd707ab2015e1154119d74b
Author: Peter Chen <peter.chen@freescale.com>
Date: Fri Jan 10 13:51:26 2014 +0800
usb: ehci: add freescale imx28 special write register method
commit feffe09f510c475df082546815f9e4a573f6a233 upstream.
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2
Without this patcheset, imx28 works unstable at high AHB bus loading.
If the bus loading is not high, the imx28 usb can work well at the most
of time. There is a IC errata for this problem, usually, we consider
IC errata is a problem not a new feature, and this workaround is needed
for that, so we need to add them to stable tree 3.11+.
Cc: robert.hodaszi@digi.com
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 292d6ae243442b4c2fbf855bc4f22d3eca37e4f5
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Tue Jan 7 10:43:02 2014 -0500
USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED
commit 543d7784b07ffd16cc82a9cb4e1e0323fd0040f1 upstream.
There is a race in the hub driver between hub_disconnect() and
recursively_mark_NOTATTACHED(). This race can be triggered if the
driver is unbound from a device at the same time as the bus's root hub
is removed. When the race occurs, it can cause an oops:
BUG: unable to handle kernel NULL pointer dereference at 0000015c
IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60
Call Trace:
[<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
[<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
[<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
[<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
[<c16d6082>] usb_set_device_state+0x92/0x120
[<c16d862b>] usb_disconnect+0x2b/0x1a0
[<c16dd4c0>] usb_remove_hcd+0xb0/0x160
[<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50
[<c1704efc>] ehci_mid_remove+0x1c/0x30
[<c1704f26>] ehci_mid_stop_host+0x16/0x30
[<c16f7698>] penwell_otg_work+0xd28/0x3520
[<c19c945b>] ? __schedule+0x39b/0x7f0
[<c19cdb9d>] ? sub_preempt_count+0x3d/0x50
[<c125e97d>] process_one_work+0x11d/0x3d0
[<c19c7f4d>] ? mutex_unlock+0xd/0x10
[<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270
[<c125f009>] worker_thread+0xf9/0x320
[<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50
[<c125ef10>] ? rescuer_thread+0x2b0/0x2b0
[<c1264ac4>] kthread+0x94/0xa0
[<c19d0f77>] ret_from_kernel_thread+0x1b/0x28
[<c1264a30>] ? kthread_create_on_node+0xc0/0xc0
One problem is that recursively_mark_NOTATTACHED() uses the intfdata
value and hub->hdev->maxchild while hub_disconnect() is clearing them.
Another problem is that it uses hub->ports[i] while the port device is
being released.
To fix this race, we need to hold the device_state_lock while
hub_disconnect() changes the values. (Note that usb_disconnect()
and hub_port_connect_change() already acquire this lock at similar
critical times during a USB device's life cycle.) We also need to
remove the port devices after maxchild has been set to 0, instead of
before.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: "Du, Changbin" <changbinx.du@intel.com>
Tested-by: "Du, Changbin" <changbinx.du@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 494a99a553c3362e18fc9d0687dbd495f7942f83
Author: Jack Pham <jackp@codeaurora.org>
Date: Fri Nov 15 14:53:14 2013 -0800
usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix()
commit 9005355af23856c55a5538c9024355785424821b upstream.
If CONFIG_PCI is enabled, make sure xhci_cleanup_msix()
doesn't try to free a bogus PCI IRQ or dereference an invalid
pci_dev when the xHCI device is actually a platform_device.
This patch should be backported to kernels as old as 3.9, that
contain the commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25
"xhci-plat: Don't enable legacy PCI interrupts."
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9746f01fc21e4dee9f39bb3d1cde46ecf6c995e
Author: Mikhail Zolotaryov <lebon@lebon.org.ua>
Date: Sat Dec 28 01:56:35 2013 +0200
USB: Nokia 502 is an unusual device
commit 0e16114f2db4838251fb64f3b550996ad3585890 upstream.
The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha
Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered
files are corrupted). A similar issue is described here:
http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170
The workaround is (MAX_SECTORS_64):
rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m
The patch adds the tested device to the unusual list permanently.
Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5b79d530f14e04b0b9c4cc8be031239a6b546e4
Author: Colin Leitner <colin.leitner@googlemail.com>
Date: Mon Jan 6 21:33:54 2014 +0100
USB: ftdi_sio: added CS5 quirk for broken smartcard readers
commit c1f15196ac3b541d084dc80a8fbd8a74c6a0bd44 upstream.
Genuine FTDI chips support only CS7/8. A previous fix in commit
8704211f65a2 ("USB: ftdi_sio: fixed handling of unsupported CSIZE
setting") enforced this limitation and reported it back to userspace.
However, certain types of smartcard readers depend on specific
driver behaviour that requests 0 data bits (not 5) to change into a
different operating mode if CS5 has been set.
This patch reenables this behaviour for all FTDI devices.
Tagged to be added to stable, because it affects a lot of users of
embedded systems which rely on these readers to work properly.
Reported-by: Heinrich Siebmanns <H.Siebmanns@t-online.de>
Tested-by: Heinrich Siebmanns <H.Siebmanns@t-online.de>
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d9a6eb5924e310bb3738f53a6aeb49a4e8a4002e
Author: Johan Hovold <jhovold@gmail.com>
Date: Thu Jan 2 22:49:24 2014 +0100
USB: cypress_m8: fix ring-indicator detection and reporting
commit 440ebadeae9298d7de3d4d105342691841ec88d0 upstream.
Fix ring-indicator (RI) status-bit definition, which was defined as CTS,
effectively preventing RI-changes from being detected while reporting
false RI status.
This bug predates git.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de3ee0d0d41c5796a780a4dd9dfa0483ba9fc975
Author: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Date: Thu Jan 2 20:57:56 2014 +0530
USB: serial: add support for iBall 3.5G connect usb modem
commit 7d5c1b9c7cb5ec8e52b1adc65c484a923a8ea6c3 upstream.
Add support for iBall 3.5G connect usb modem.
$lsusb
Bus 002 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY
$usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1c9e ProdID=9605 Rev=00.00
S: Manufacturer=USB Modem
S: Product=USB Modem
S: SerialNumber=1234567890ABCDEF
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 021055e411bf4687d6435d3d5eb805f8ae040bbd
Author: 张君 <zjn77777@163.com>
Date: Wed Dec 18 15:37:17 2013 +0800
usb: option: add new zte 3g modem pids to option driver
commit 4d90b819ae4c7ea8fd5e2bb7edc68c0f334be2e4 upstream.
Signed-off-by: Jun zhang <zhang.jun92@zte.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b3d3b553055966bda60679945d17a74a15f82432
Author: Johan Hovold <jhovold@gmail.com>
Date: Sun Dec 29 19:22:53 2013 +0100
USB: pl2303: fix data corruption on termios updates
commit 623c8263376c0b8a4b0c220232e7313d762cd0cc upstream.
Some PL2303 devices are known to lose bytes if you change serial
settings even to the same values as before. Avoid this by comparing the
encoded settings with the previsouly used ones before configuring the
device.
The common case was fixed by commit bf5e5834bffc6 ("pl2303: Fix mode
switching regression"), but this problem was still possible to trigger,
for instance, by using the TCSETS2-interface to repeatedly request
115201 baud, which gets mapped to 115200 and thus always triggers a
settings update.
Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c3d0a890ee3d67198fce4510e073f087c8f3b42f
Author: Peter Chen <peter.chen@freescale.com>
Date: Fri Jan 10 13:51:32 2014 +0800
usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX
commit 2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a upstream.
We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is "Transaction Error".
The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.
We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).
Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.
For stable tree: 3.11+.
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Reported-by: Matthieu Vanin <b47495@freescale.com>
Tested-by: Matthieu Vanin <b47495@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92083ad956978ee6a79e8a14b38dce6f3e278db2
Author: Peter Chen <peter.chen@freescale.com>
Date: Fri Jan 10 13:51:31 2014 +0800
usb: chipidea: need to mask INT_STATUS when write otgsc
commit 5332ff1fb63c46588656e4208201bc131627c878 upstream.
For otgsc, both enable bits and status bits are in it. So we need
to make sure the status bits are not be cleared when write enable
bits. It can fix one bug that we plug in/out Micro AB cable fast,
and sometimes, the IDIS will be cleared wrongly when handle last
ID interrupt (ID 0->1), so the current interrupt will not occur.
For stable tree: 3.12+
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cdde9f60ed6516f020926863a765a3cb624b1854
Author: Peter Chen <peter.chen@freescale.com>
Date: Fri Jan 10 13:51:28 2014 +0800
usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
commit 1071055e2a118a81c0b300d7f4af7eba3f7a7c82 upstream.
Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.
This patch is needed for stable tree 3.11+
Cc: robert.hodaszi@digi.com
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 03df63f78245cd9db67a2b4f049348783f31ed6e
Author: Peter Chen <peter.chen@freescale.com>
Date: Fri Jan 10 13:51:27 2014 +0800
usb: chipidea: add freescale imx28 special write register method
commit ed8f8318d2ef3e5f9e4ddf79349508c116b68d7f upstream.
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2
This patch is needed for stable tree 3.11+.
Cc: robert.hodaszi@digi.com
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a650dc266e2d2eddbfb8c2b75c69374e7f58630
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon Jan 27 14:51:44 2014 +0100
x86, kvm: correctly access the KVM_CPUID_FEATURES leaf at 0x40000101
commit 77f01bdfa5e55dc19d3eb747181d2730a9bb3ca8 upstream.
When Hyper-V hypervisor leaves are present, KVM must relocate
its own leaves at 0x40000100, because Windows does not look for
Hyper-V leaves at indices other than 0x40000000. In this case,
the KVM features are at 0x40000101, but the old code would always
look at 0x40000001.
Fix by using kvm_cpuid_base(). This also requires making the
function non-inline, since kvm_cpuid_base() is static.
Fixes: 1085ba7f552d84aa8ac0ae903fa8d0cc2ff9f79d
Cc: mtosatti@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f39cea7488daa2f2d77269337597529f047d168
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon Jan 27 14:49:40 2014 +0100
x86, kvm: cache the base of the KVM cpuid leaves
commit 1c300a40772dae829b91dad634999a6a522c0829 upstream.
It is unnecessary to go through hypervisor_cpuid_base every time
a leaf is found (which will be every time a feature is requested
after the next patch).
Fixes: 1085ba7f552d84aa8ac0ae903fa8d0cc2ff9f79d
Cc: mtosatti@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67454c317bc75219d41516419ffe516a6c3e962e
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon Jan 6 12:00:02 2014 -0200
KVM: x86: limit PIT timer frequency
commit 9ed96e87c5748de4c2807ef17e81287c7304186c upstream.
Limit PIT timer frequency similarly to the limit applied by
LAPIC timer.
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 408860f39b5924308f30f5d5d0a6472756e73922
Author: Dave Young <dyoung@redhat.com>
Date: Fri Dec 20 18:02:15 2013 +0800
x86/efi: Fix off-by-one bug in EFI Boot Services reservation
commit a7f84f03f660d93574ac88835d056c0d6468aebe upstream.
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 1000000 md start: 800000 md size: 800000
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1769bfb6aa93250f83d6d9d3ac85d15f990849f
Author: PaX Team <pageexec@freemail.hu>
Date: Thu Jan 30 16:59:25 2014 -0800
x86, x32: Correct invalid use of user timespec in the kernel
commit 2def2ef2ae5f3990aabdbe8a755911902707d268 upstream.
The x32 case for the recvmsg() timout handling is broken:
asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
unsigned int vlen, unsigned int flags,
struct compat_timespec __user *timeout)
{
int datagrams;
struct timespec ktspec;
if (flags & MSG_CMSG_COMPAT)
return -EINVAL;
if (COMPAT_USE_64BIT_TIME)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT,
(struct timespec *) timeout);
...
The timeout pointer parameter is provided by userland (hence the __user
annotation) but for x32 syscalls it's simply cast to a kernel pointer
and is passed to __sys_recvmmsg which will eventually directly
dereference it for both reading and writing. Other callers to
__sys_recvmmsg properly copy from userland to the kernel first.
The bug was introduced by commit ee4fa23c4bfc ("compat: Use
COMPAT_USE_64BIT_TIME in net/compat.c") and should affect all kernels
since 3.4 (and perhaps vendor kernels if they backported x32 support
along with this code).
Note that CONFIG_X86_X32_ABI gets enabled at build time and only if
CONFIG_X86_X32 is enabled and ld can build x32 executables.
Other uses of COMPAT_USE_64BIT_TIME seem fine.
This addresses CVE-2014-0038.
Signed-off-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3ea3b3c4646582daf3dc656de0c34ae949c3b027
Author: David Rientjes <rientjes@google.com>
Date: Thu Jan 30 15:46:08 2014 -0800
mm/mempolicy.c: fix mempolicy printing in numa_maps
commit 8790c71a18e5d2d93532ae250bcf5eddbba729cd upstream.
As a result of commit 5606e3877ad8 ("mm: numa: Migrate on reference
policy"), /proc/<pid>/numa_maps prints the mempolicy for any <pid> as
"prefer:N" for the local node, N, of the process reading the file.
This should only be printed when the mempolicy of <pid> is
MPOL_PREFERRED for node N.
If the process is actually only using the default mempolicy for local
node allocation, make sure "default" is printed as expected.
Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Robert Lippert <rlippert@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: <stable@vger.kernel.org> [3.7+]
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 a5ebe38400dcc9ada1452090d317beef9ecc7099
Author: David Ertman <davidx.m.ertman@intel.com>
Date: Sat Dec 14 07:18:18 2013 +0000
e1000e: fix compiler warnings
commit 9e6c3b63399dd424d33a34e08b77f2cab0b84cdc upstream.
This patch is to fix a compiler warning of __bad_udelay due to a value
of >999 being passed as a parameter to udelay() in the function
e1000e_phy_has_link_generic(). This affects the gcc compiler when
it is given a flag of -O3 and the icc compiler.
This patch is also making the change from mdelay() to msleep() in the
same function, since it was determined though code inspection that this
function is never called in atomic context.
Signed-off-by: David Ertman <davidx.m.ertman@intel.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7abfe210e2e74224400b95be11f96728b1347ed9
Author: Aristeu Rozanski <aris@redhat.com>
Date: Thu Dec 5 10:37:56 2013 -0500
e752x_edac: Fix pci_dev usage count
commit 90ed4988b8c030d65b41b7d13140e9376dc6ec5a upstream.
In case the device 0, function 1 is not found using pci_get_device(),
pci_scan_single_device() will be used but, differently than
pci_get_device(), it allocates a pci_dev but doesn't does bump the usage
count on the pci_dev and after few module removals and loads the pci_dev
will be freed.
Signed-off-by: Aristeu Rozanski <aris@redhat.com>
Reviewed-by: mark gross <mark.gross@intel.com>
Link: http://lkml.kernel.org/r/20131205153755.GL4545@redhat.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0e2e423fef687985cbc0ecf9a9de684fa2d2f61e
Author: Andrea Arcangeli <aarcange@redhat.com>
Date: Thu Nov 21 14:32:02 2013 -0800
mm: hugetlbfs: fix hugetlbfs optimization
commit 27c73ae759774e63313c1fbfeb17ba076cea64c5 upstream.
Commit 7cb2ef56e6a8 ("mm: fix aio performance regression for database
caused by THP") can cause dereference of a dangling pointer if
split_huge_page runs during PageHuge() if there are updates to the
tail_page->private field.
Also it is repeating compound_head twice for hugetlbfs and it is running
compound_head+compound_trans_head for THP when a single one is needed in
both cases.
The new code within the PageSlab() check doesn't need to verify that the
THP page size is never bigger than the smallest hugetlbfs page size, to
avoid memory corruption.
A longstanding theoretical race condition was found while fixing the
above (see the change right after the skip_unlock label, that is
relevant for the compound_lock path too).
By re-establishing the _mapcount tail refcounting for all compound
pages, this also fixes the below problem:
echo 0 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
BUG: Bad page state in process bash pfn:59a01
page:ffffea000139b038 count:0 mapcount:10 mapping: (null) index:0x0
page flags: 0x1c00000000008000(tail)
Modules linked in:
CPU: 6 PID: 2018 Comm: bash Not tainted 3.12.0+ #25
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
dump_stack+0x55/0x76
bad_page+0xd5/0x130
free_pages_prepare+0x213/0x280
__free_pages+0x36/0x80
update_and_free_page+0xc1/0xd0
free_pool_huge_page+0xc2/0xe0
set_max_huge_pages.part.58+0x14c/0x220
nr_hugepages_store_common.isra.60+0xd0/0xf0
nr_hugepages_store+0x13/0x20
kobj_attr_store+0xf/0x20
sysfs_write_file+0x189/0x1e0
vfs_write+0xc5/0x1f0
SyS_write+0x55/0xb0
system_call_fastpath+0x16/0x1b
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Pravin Shelar <pshelar@nicira.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guillaume Morin <guillaume@morinfr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d004cdc6054bf21a9eb2fc1b83b5628f2a4d644
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date: Tue Jan 7 12:33:59 2014 -0500
drm/nouveau/bios: fix offset calculation for BMPv1 bioses
commit 5d2f4767c4eacab351b8450b0de4d3261fe1a957 upstream.
The only BIOS on record that needs the 14 offset has a bios major
version 2 but BMP version 1.01. Another bunch of BIOSes that need the 18
offset have BMP version 2.01 or 5.01 or higher. So instead of looking at the
bios major version, look at the BMP version. BIOSes with BMP version 0
do not contain a detectable script, so always return 0 for them.
See https://bugs.freedesktop.org/show_bug.cgi?id=68835
Reported-by: Mauro Molinari <mauromol@tiscali.it>
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 709f3756e9c1bc0ba0dff0edb0bff2b4149dd2fe
Author: NeilBrown <neilb@suse.de>
Date: Thu Jan 16 09:35:38 2014 +1100
md/raid5: fix long-standing problem with bitmap handling on write failure.
commit 9f97e4b128d2ea90a5f5063ea0ee3b0911f4c669 upstream.
Before a write starts we set a bit in the write-intent bitmap.
When the write completes we clear that bit if the write was successful
to all devices. However if the write wasn't fully successful we
should not clear the bit. If the faulty drive is subsequently
re-added, the fact that the bit is still set ensure that we will
re-write the data that is missing.
This logic is mediated by the STRIPE_DEGRADED flag - we only clear the
bitmap bit when this flag is not set.
Currently we correctly set the flag if a write starts when some
devices are failed or missing. But we do *not* set the flag if some
device failed during the write attempt.
This is wrong and can result in clearing the bit inappropriately.
So: set the flag when a write fails.
This bug has been present since bitmaps were introduces, so the fix is
suitable for any -stable kernel.
Reported-by: Ethan Wilson <ethan.wilson@shiftmail.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b755e49c15fb7475ce772f506d0288f182f6ba8
Author: Andrew Jones <drjones@redhat.com>
Date: Wed Jan 15 13:39:59 2014 +0100
kvm: x86: fix apic_base enable check
commit 0dce7cd67fd9055c4a2ff278f8af1431e646d346 upstream.
Commit e66d2ae7c67bd moved the assignment
vcpu->arch.apic_base = value above a condition with
(vcpu->arch.apic_base ^ value), causing that check
to always fail. Use old_value, vcpu->arch.apic_base's
old value, in the condition instead.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>