Petr Kubánek [Fri, 1 Feb 2013 16:24:04 +0000 (17:24 +0100)]
USB: ftdi_sio: add Zolix FTDI PID
commit
0ba3b2ccc72b3df5c305d61f59d93ab0f0e87991 upstream.
Add support for Zolix Omni 1509 monochromator custom USB-RS232 converter.
Signed-off-by: Petr Kubánek <petr@kubanek.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Luebbe [Mon, 4 Feb 2013 22:28:53 +0000 (14:28 -0800)]
drivers/rtc/rtc-isl1208.c: call rtc_update_irq() from the alarm irq handler
commit
72fca4a4b32dc778b5b885c3498700e42b610d49 upstream.
Previously the alarm event was not propagated into the RTC subsystem.
By adding a call to rtc_update_irq, this fixes a timeout problem with
the hwclock utility.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
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>
Vyacheslav Dubeyko [Mon, 4 Feb 2013 22:28:41 +0000 (14:28 -0800)]
nilfs2: fix fix very long mount time issue
commit
a9bae189542e71f91e61a4428adf6e5a7dfe8063 upstream.
There exists a situation when GC can work in background alone without
any other filesystem activity during significant time.
The nilfs_clean_segments() method calls nilfs_segctor_construct() that
updates superblocks in the case of NILFS_SC_SUPER_ROOT and
THE_NILFS_DISCONTINUED flags are set. But when GC is working alone the
nilfs_clean_segments() is called with unset THE_NILFS_DISCONTINUED flag.
As a result, the update of superblocks doesn't occurred all this time
and in the case of SPOR superblocks keep very old values of last super
root placement.
SYMPTOMS:
Trying to mount a NILFS2 volume after SPOR in such environment ends with
very long mounting time (it can achieve about several hours in some
cases).
REPRODUCING PATH:
1. It needs to use external USB HDD, disable automount and doesn't
make any additional filesystem activity on the NILFS2 volume.
2. Generate temporary file with size about 100 - 500 GB (for example,
dd if=/dev/zero of=<file_name> bs=
1073741824 count=200). The size of
file defines duration of GC working.
3. Then it needs to delete file.
4. Start GC manually by means of command "nilfs-clean -p 0". When you
start GC by means of such way then, at the end, superblocks is updated
by once. So, for simulation of SPOR, it needs to wait sometime (15 -
40 minutes) and simply switch off USB HDD manually.
5. Switch on USB HDD again and try to mount NILFS2 volume. As a
result, NILFS2 volume will mount during very long time.
REPRODUCIBILITY: 100%
FIX:
This patch adds checking that superblocks need to update and set
THE_NILFS_DISCONTINUED flag before nilfs_clean_segments() call.
Reported-by: Sergey Alexandrov <splavgm@gmail.com>
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Tested-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
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>
Shawn Bohrer [Mon, 14 Jan 2013 17:55:31 +0000 (11:55 -0600)]
sched/rt: Use root_domain of rt_rq not current processor
commit
aa7f67304d1a03180f463258aa6f15a8b434e77d upstream.
When the system has multiple domains do_sched_rt_period_timer()
can run on any CPU and may iterate over all rt_rq in
cpu_online_mask. This means when balance_runtime() is run for a
given rt_rq that rt_rq may be in a different rd than the current
processor. Thus if we use smp_processor_id() to get rd in
do_balance_runtime() we may borrow runtime from a rt_rq that is
not part of our rd.
This changes do_balance_runtime to get the rd from the passed in
rt_rq ensuring that we borrow runtime only from the correct rd
for the given rt_rq.
This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime
when we try reclaim runtime lent to other rt_rq but runtime has
been lent to a rt_rq in another rd.
Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Mike Galbraith <bitbucket@online.de>
Cc: peterz@infradead.org
Link: http://lkml.kernel.org/r/1358186131-29494-1-git-send-email-sbohrer@rgmadvisors.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Beulich [Wed, 30 Jan 2013 07:55:53 +0000 (07:55 +0000)]
x86-64: Replace left over sti/cli in ia32 audit exit code
commit
40a1ef95da85843696fc3ebe5fce39b0db32669f upstream.
For some reason they didn't get replaced so far by their
paravirt equivalents, resulting in code to be run with
interrupts disabled that doesn't expect so (causing, in the
observed case, a BUG_ON() to trigger) when syscall auditing is
enabled.
David (Cc-ed) came up with an identical fix, so likely this can
be taken to count as an ack from him.
Reported-by: Peter Moody <pmoody@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/5108E01902000078000BA9C5@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Tested-by: Peter Moody <pmoody@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
liu chuansheng [Thu, 31 Jan 2013 14:13:00 +0000 (22:13 +0800)]
drm/radeon: Calling object_unrefer() when creating fb failure
commit
f2d68cf4daa4de97d400d94836b907e35228e54f upstream.
When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: xueminsu <xuemin.su@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 30 Jan 2013 19:24:09 +0000 (14:24 -0500)]
drm/radeon: prevent crash in the ring space allocation
commit
fd5d93a0015ce1a7db881382022b2fcdfdc61760 upstream.
If the requested number of DWs on the ring is larger than
the size of the ring itself, return an error.
In testing with large VM updates, we've seen crashes when we
try and allocate more space on the ring than the total size
of the ring without checking.
This prevents the crash but for large VM updates or bo moves
of very large buffers, we will need to break the transaction
down into multiple batches. I have patches to use IBs for
the next kernel.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christopher Staite [Sat, 26 Jan 2013 16:10:58 +0000 (11:10 -0500)]
drm/radeon: fix MC blackout on evergreen+
commit
bb588820ef421c6098dca1fec29c3b347f1c8c19 upstream.
Force the crtc mem requests on/off immediately rather
than waiting for the double buffered updates to kick in.
Seems we miss the update in certain conditions. Also
handle the DCE6 case.
Signed-off-by: Christopher Staite <chris@yourdreamnet.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 29 Jan 2013 21:36:47 +0000 (16:36 -0500)]
drm/radeon: add quirk for RV100 board
commit
9200ee4941a6e5d1ec5df88982243686882dff3f upstream.
vbios says external TMDS while the board is actually
internal TMDS.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60037
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 28 Jan 2013 02:57:51 +0000 (21:57 -0500)]
drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
commit
674a16f2b4724880d07389abbb95abf320b924aa upstream.
Newer versions of mesa emit this.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 31 Jan 2013 14:00:52 +0000 (09:00 -0500)]
drm/radeon/evergreen+: wait for the MC to settle after MC blackout
commit
ed39fadd6df01095378e499fac3674883f16b853 upstream.
Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
YOSHIFUJI Hideaki [Fri, 25 Jan 2013 14:54:20 +0000 (16:54 +0200)]
digsig: Fix memory leakage in digsig_verify_rsa()
commit
7810cc1e7721220f1ed2a23ca95113d6434f6dcd upstream.
digsig_verify_rsa() does not free kmalloc'ed buffer returned by
mpi_get_buffer().
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 4 Feb 2013 00:24:52 +0000 (18:24 -0600)]
Linux 3.4.29
Nicholas Bellinger [Fri, 25 Jan 2013 02:57:14 +0000 (21:57 -0500)]
target: fix regression with dev_link_magic in target_fabric_port_link
This is to fix a regression that only affect the stable (not for the mainline)
that the stable commit fdf9d86 was incorrectly placed dev->dev_link_magic check
before the *dev assignment in target_fabric_port_link() due to fuzzy automatically
context adjustment during the back-porting.
Reported-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H. Peter Anvin [Mon, 14 Jan 2013 04:56:41 +0000 (20:56 -0800)]
x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI
commit
e43b3cec711a61edf047adf6204d542f3a659ef8 upstream.
early_pci_allowed() and read_pci_config_16() are only available if
CONFIG_PCI is defined.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Matt Fleming [Fri, 25 Jan 2013 10:07:25 +0000 (10:07 +0000)]
x86, efi: Set runtime_version to the EFI spec revision
commit
712ba9e9afc4b3d3d6fa81565ca36fe518915c01 upstream.
efi.runtime_version is erroneously being set to the value of the
vendor's firmware revision instead of that of the implemented EFI
specification. We can't deduce which EFI functions are available based
on the revision of the vendor's firmware since the version scheme is
likely to be unique to each vendor.
What we really need to know is the revision of the implemented EFI
specification, which is available in the EFI System Table header.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nathan Zimmer [Tue, 8 Jan 2013 15:02:43 +0000 (09:02 -0600)]
efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
commit
b8f2c21db390273c3eaf0e5308faeaeb1e233840 upstream.
Update efi_call_phys_prelog to install an identity mapping of all available
memory. This corrects a bug on very large systems with more then 512 GB in
which bios would not be able to access addresses above not in the mapping.
The result is a crash that looks much like this.
BUG: unable to handle kernel paging request at
000000effd870020
IP: [<
0000000078bce331>] 0x78bce330
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU 0
Pid: 0, comm: swapper/0 Tainted: G W 3.8.0-rc1-next-
20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
RIP: 0010:[<
0000000078bce331>] [<
0000000078bce331>] 0x78bce330
RSP: 0000:
ffffffff81601d28 EFLAGS:
00010006
RAX:
0000000078b80e18 RBX:
0000000000000004 RCX:
0000000000000004
RDX:
0000000078bcf958 RSI:
0000000000002400 RDI:
8000000000000000
RBP:
0000000078bcf760 R08:
000000effd870000 R09:
0000000000000000
R10:
0000000000000000 R11:
00000000000000c3 R12:
0000000000000030
R13:
000000effd870000 R14:
0000000000000000 R15:
ffff88effd870000
FS:
0000000000000000(0000) GS:
ffff88effe400000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
000000effd870020 CR3:
000000000160c000 CR4:
00000000000006b0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process swapper/0 (pid: 0, threadinfo
ffffffff81600000, task
ffffffff81614400)
Stack:
0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
Call Trace:
[<
ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83
[<
ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed
[<
ffffffff81035946>] ? efi_call4+0x46/0x80
[<
ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305
[<
ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2
[<
ffffffff816ae5ed>] ? repair_env_string+0x60/0x60
[<
ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1
[<
ffffffff816ae120>] ? early_idt_handlers+0x120/0x120
[<
ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163
Code: Bad RIP value.
RIP [<
0000000078bce331>] 0x78bce330
RSP <
ffffffff81601d28>
CR2:
000000effd870020
---[ end trace
ead828934fef5eab ]---
Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Cox [Thu, 15 Nov 2012 13:06:22 +0000 (13:06 +0000)]
x86/msr: Add capabilities check
commit
c903f0456bc69176912dee6dd25c6a66ee1aed00 upstream.
At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.
In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.
Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang YanQing [Sat, 26 Jan 2013 07:53:57 +0000 (15:53 +0800)]
smp: Fix SMP function call empty cpu mask race
commit
f44310b98ddb7f0d06550d73ed67df5865e3eda5 upstream.
I get the following warning every day with v3.7, once or
twice a day:
[ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()
As explained by Linus as well:
|
| Once we've done the "list_add_rcu()" to add it to the
| queue, we can have (another) IPI to the target CPU that can
| now see it and clear the mask.
|
| So by the time we get to actually send the IPI, the mask might
| have been cleared by another IPI.
|
This patch also fixes a system hang problem, if the data->cpumask
gets cleared after passing this point:
if (WARN_ONCE(!mask, "empty IPI mask"))
return;
then the problem in commit
83d349f35e1a ("x86: don't send an IPI to
the empty set of CPU's") will happen again.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: peterz@infradead.org
Cc: mina86@mina86.org
Cc: srivatsa.bhat@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/20130126075357.GA3205@udknight
[ Tidied up the changelog and the comment in the code. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 22 Jan 2013 05:17:06 +0000 (00:17 -0500)]
NFS: Don't silently fail setattr() requests on mountpoints
commit
ab225417825963b6dc66be7ea80f94ac1378dfdf upstream.
Ensure that any setattr and getattr requests for junctions and/or
mountpoints are sent to the server. Ever since commit
0ec26fd0698 (vfs: automount should ignore LOOKUP_FOLLOW), we have
silently dropped any setattr requests to a server-side mountpoint.
For referrals, we have silently dropped both getattr and setattr
requests.
This patch restores the original behaviour for setattr on mountpoints,
and tries to do the same for referrals, provided that we have a
filehandle...
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Thu, 20 Dec 2012 13:41:18 +0000 (14:41 +0100)]
mac80211: synchronize scan off/on-channel and PS states
commit
aacde9ee45225f7e0b90960f479aef83c66bfdc0 upstream.
Since:
commit
b23b025fe246f3acc2988eb6d400df34c27cb8ae
Author: Ben Greear <greearb@candelatech.com>
Date: Fri Feb 4 11:54:17 2011 -0800
mac80211: Optimize scans on current operating channel.
we do not disable PS while going back to operational channel (on
ieee80211_scan_state_suspend) and deffer that until scan finish.
But since we are allowed to send frames, we can send a frame to AP
without PM bit set, so disable PS on AP side. Then when we switch
to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
Hence we are off-channel with PS disabled, frames are not buffered
by AP.
To fix remove offchannel_ps_disable argument and always enable PS when
going off-channel and disable it when going on-channel, like it was
before.
Cc: stable@vger.kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Sun, 20 Jan 2013 22:50:13 +0000 (23:50 +0100)]
iommu/intel: disable DMAR for g4x integrated gfx
commit
9452618e7462181ed9755236803b6719298a13ce upstream.
DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
So don't bother, but instead disable it by default to allow distros to
unconditionally enable DMAR support.
v2: Actually wire up the right quirk entry, spotted by Adam Jackson.
Note that according to intel marketing materials only g45 and gm45
support DMAR/VT-d. So we have reports for all relevant gen4 pci ids by
now. Still, keep all the other gen4 ids in the quirk table in case the
marketing stuff confused me again, which would not be the first time.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51921
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Cc: Adam Jackson <ajax@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: stable@vger.kernel.org
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: stathis <stathis@npcglib.org>
Tested-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anderson Lizardo [Sun, 6 Jan 2013 22:28:53 +0000 (18:28 -0400)]
Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()
commit
0a9ab9bdb3e891762553f667066190c1d22ad62b upstream.
The length parameter should be sizeof(req->name) - 1 because there is no
guarantee that string provided by userspace will contain the trailing
'\0'.
Can be easily reproduced by manually setting req->name to 128 non-zero
bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
input subsystem:
$ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
AAAAAA[...]
AAAAAAAAf0:af:f0:af:f0:af
("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
field in struct hid_device due to overflow.)
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Rattray [Tue, 15 Jan 2013 13:22:36 +0000 (13:22 +0000)]
ASoC: wm2200: correct mixer values and text
commit
a80cc734282805e15b5e023751a4d02f7ffbcc91 upstream.
Signed-off-by: Chris Rattray <crattray@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 26 Jan 2013 07:49:24 +0000 (10:49 +0300)]
EDAC: Test correct variable in ->store function
commit
8024c4c0b1057d1cd811fc9c3f88f81de9729fcd upstream.
We're testing for ->show but calling ->store().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 23 Jan 2013 17:16:24 +0000 (18:16 +0100)]
ALSA: hda - Add a fixup for Packard-Bell desktop with ALC880
commit
0712eea349d8e2b6d0e44b94a752d999319027fb upstream.
A Packard-Bell desktop machine gives no proper pin configuration from
BIOS. It's almost equivalent with the 6stack+fp standard config, just
take the existing fixup.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=901846
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clemens Ladisch [Thu, 29 Nov 2012 16:04:23 +0000 (17:04 +0100)]
ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices
commit
d56268fb108c7c21e19933588ca4d94652585183 upstream.
Commit
23caaf19b11e (ALSA: usb-mixer: Add support for Audio Class v2.0)
forgot to adjust the length check for UAC 2.0 feature unit descriptors.
This would make the code abort on encountering a feature unit without
per-channel controls, and thus prevented the driver to work with any
device having such a unit, such as the RME Babyface or Fireface UCX.
Reported-by: Florian Hanisch <fhanisch@uni-potsdam.de>
Tested-by: Matthew Robbetts <wingfeathera@gmail.com>
Tested-by: Michael Beer <beerml@sigma6audio.de>
Cc: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Wed, 9 Jan 2013 15:16:53 +0000 (16:16 +0100)]
ath9k: fix double-free bug on beacon generate failure
commit
1adb2e2b5f85023d17eb4f95386a57029df27c88 upstream.
When the next beacon is sent, the ath_buf from the previous run is reused.
If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
the skb is freed, leading to a double-free on the next beacon tx attempt,
resulting in a system crash.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Wed, 9 Jan 2013 15:16:52 +0000 (16:16 +0100)]
ath9k: do not link receive buffers during flush
commit
a3dc48e82bb146ef11cf75676c8410c1df29b0c4 upstream.
On AR9300 the rx FIFO needs to be empty during reset to ensure that no
further DMA activity is generated, otherwise it might lead to memory
corruption issues.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sujith Manoharan [Wed, 9 Jan 2013 10:37:48 +0000 (16:07 +0530)]
ath9k_htc: Fix memory leak
commit
0981c3b24ef664f5611008a6e6d0622fac6d892b upstream.
SKBs that are allocated in the HTC layer do not have callbacks
registered and hence ended up not being freed, Fix this by freeing
them properly in the TX completion routine.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Tested-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>
Johannes Berg [Fri, 11 Jan 2013 13:34:25 +0000 (14:34 +0100)]
mac80211: fix FT roaming
commit
1626e0fa740dec8665a973cf2349405cdfeb46dc upstream.
During FT roaming, wpa_supplicant attempts to set the
key before association. This used to be rejected, but
as a side effect of my commit
66e67e418908442389d3a9e
("mac80211: redesign auth/assoc") the key was accepted
causing hardware crypto to not be used for it as the
station isn't added to the driver yet.
It would be possible to accept the key and then add it
to the driver when the station has been added. However,
this may run into issues with drivers using the state-
based station adding if they accept the key only after
association like it used to be.
For now, revert to the behaviour from before the auth
and assoc change.
Reported-by: Cédric Debarge <cedric.debarge@acksys.fr>
Tested-by: Cédric Debarge <cedric.debarge@acksys.fr>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Piotr Haber [Thu, 10 Jan 2013 10:20:48 +0000 (11:20 +0100)]
brcmsmac: increase timer reference count for new timers only
commit
a1fe52801a992e590cdaee2fb47a94bac9b5da90 upstream.
On hardware reintialization reference count of
already existing timers would be increased again.
This leads to problems on module unloading.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Wed, 16 Jan 2013 10:45:15 +0000 (11:45 +0100)]
iwlegacy: fix IBSS cleanup
commit
fa4cffcba9e13798ed7c6b8526b91b1631ecb53e upstream.
We do not correctly change interface type when switching from
IBSS mode to STA mode, that results in microcode errors.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=886946
Reported-by: Jaroslav Skarvada <jskarvad@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Avinash Patil [Tue, 22 Jan 2013 05:04:10 +0000 (21:04 -0800)]
mwifiex: fix typo in PCIe adapter NULL check
commit
83f0c6d1f502bd75bb4a9e31e8d64e59c6894ad1 upstream.
Add missing "!" as we are supposed to check "!card->adapter"
in PCIe suspend handler.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Sergey V. <sftp.mtuci@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 23 Jan 2013 12:56:18 +0000 (13:56 +0100)]
xfs: Fix possible use-after-free with AIO
commit
4b05d09c18d9aa62d2e7fb4b057f54e5a38963f5 upstream.
Running AIO is pinning inode in memory using file reference. Once AIO
is completed using aio_complete(), file reference is put and inode can
be freed from memory. So we have to be sure that calling aio_complete()
is the last thing we do with the inode.
Signed-off-by: Jan Kara <jack@suse.cz>
CC: xfs@oss.sgi.com
CC: Ben Myers <bpm@sgi.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suravee Suthikulpanit [Thu, 24 Jan 2013 19:17:53 +0000 (13:17 -0600)]
IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround
commit
318fe782539c4150d1b8e4e6c9dc3a896512cb8a upstream.
The IOMMU may stop processing page translations due to a perceived lack
of credits for writing upstream peripheral page service request (PPR)
or event logs. If the L2B miscellaneous clock gating feature is enabled
the IOMMU does not properly register credits after the log request has
completed, leading to a potential system hang.
BIOSes are supposed to disable L2B micellaneous clock gating by setting
L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
patch corrects that for those which do not enable this workaround.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xueminsu [Tue, 22 Jan 2013 14:16:53 +0000 (22:16 +0800)]
radeon_display: Use pointer return error codes
commit
b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream.
drm_mode_addfb() expects fb_create return error code
instead of NULL.
Signed-off-by: xueminsu <xuemin.su@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Glisse [Mon, 21 Jan 2013 20:50:03 +0000 (15:50 -0500)]
drm/radeon: fix cursor corruption on DCE6 and newer
commit
e521a29014794d139cca46396d1af8faf1295a26 upstream.
Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.
agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Szymon Janc [Tue, 11 Dec 2012 07:51:19 +0000 (08:51 +0100)]
Bluetooth: Fix sending HCI commands after reset
commit
dbccd791a3fbbdac12c33834b73beff3984988e9 upstream.
After sending reset command wait for its command complete event before
sending next command. Some chips sends CC event for command received
before reset if reset was send before chip replied with CC.
This is also required by specification that host shall not send
additional HCI commands before receiving CC for reset.
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Mon, 14 Jan 2013 18:50:42 +0000 (19:50 +0100)]
ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone
commit
568dca15aa2a0f4ddee255894ec393a159f13147 upstream.
Patrik Kluba reports that the preempt count becomes invalid due
to the preempt_enable() call being unbalanced with a
preempt_disable() call in the vfp assembly routines. This happens
because preempt_enable() and preempt_disable() update preempt
counts under PREEMPT_COUNT=y but the vfp assembly routines do so
under PREEMPT=y. In a configuration where PREEMPT=n and
DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable()
call in VFP_bounce() keeps subtracting from the preempt count
until it goes negative.
Fix this by always using PREEMPT_COUNT to decided when to update
preempt counts in the ARM assembly code.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reported-by: Patrik Kluba <pkluba@dension.com>
Tested-by: Patrik Kluba <pkluba@dension.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jean-Christophe PLAGNIOL-VILLARD [Sun, 23 Dec 2012 18:07:49 +0000 (18:07 +0000)]
ARM: at91: rm9200: remake the BGA as default version
commit
36224d0fe0f34cdde66a381708853ebadeac799c upstream.
Make BGA as the default version as we are supposed to just have
to specify when we use the PQFP version.
Issue was existing since commit:
3e90772 (ARM: at91: fix at91rm9200 soc subtype handling).
Signed-off-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>
Russell King [Sat, 19 Jan 2013 11:05:57 +0000 (11:05 +0000)]
ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem
commit
15653371c67c3fbe359ae37b720639dd4c7b42c5 upstream.
Subhash Jadavani reported this partial backtrace:
Now consider this call stack from MMC block driver (this is on the ARMv7
based board):
[<
c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<
c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
[<
c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<
c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
[<
c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<
c0017ff8>] (dma_map_sg+0x3c/0x114)
This is caused by incrementing the struct page pointer, and running off
the end of the sparsemem page array. Fix this by incrementing by pfn
instead, and convert the pfn to a struct page.
Suggested-by: James Bottomley <JBottomley@Parallels.com>
Tested-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cong Ding [Wed, 23 Jan 2013 00:20:58 +0000 (19:20 -0500)]
fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
commit
10b8c7dff5d3633b69e77f57d404dab54ead3787 upstream.
When it goes to error through line 144, the memory allocated to *devname is
not freed, and the caller doesn't free it either in line 250. So we free the
memroy of *devname in function cifs_compose_mount_options() when it goes to
error.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Olivier Sobrie [Fri, 18 Jan 2013 08:32:41 +0000 (09:32 +0100)]
can: pch_can: fix invalid error codes
commit
ee50e135aeb048b90fab662e661c58b67341830b upstream.
Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Olivier Sobrie [Fri, 18 Jan 2013 08:32:40 +0000 (09:32 +0100)]
can: ti_hecc: fix invalid error codes
commit
71088c4bd9b8f8cbffb0e66f2abc14297e4b2ca8 upstream.
Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Cc: Anant Gole <anantgole@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Olivier Sobrie [Fri, 18 Jan 2013 08:32:39 +0000 (09:32 +0100)]
can: c_can: fix invalid error codes
commit
6ea45886865c1abb01bb861f7f6bdd5d0f398cb3 upstream.
Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 28 Jan 2013 04:51:45 +0000 (20:51 -0800)]
Linux 3.4.28
Shuah Khan [Thu, 25 Oct 2012 16:22:32 +0000 (10:22 -0600)]
ioat: Fix DMA memory sync direction correct flag
commit
ac4989874af56435c308bdde9ad9c837a26f8b23 upstream.
ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated
for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug.
Fixed the dma_sync_single_for_device() call to use the correct direction.
[ 226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550()
[ 226.288948] Hardware name: ProLiant DL380p Gen8
[ 226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE]
[ 226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod
[ 226.288967] Pid: 1055, comm: work_for_cpu Tainted: G W 3.3.0-0.20.el7.x86_64 #1
[ 226.288968] Call Trace:
[ 226.288974] [<
ffffffff810644cf>] warn_slowpath_common+0x7f/0xc0
[ 226.288977] [<
ffffffff810645c6>] warn_slowpath_fmt+0x46/0x50
[ 226.288980] [<
ffffffff81345502>] check_sync+0x132/0x550
[ 226.288983] [<
ffffffff81345c9f>] debug_dma_sync_single_for_device+0x3f/0x50
[ 226.288988] [<
ffffffff81661002>] ? wait_for_common+0x72/0x180
[ 226.288995] [<
ffffffffa019590f>] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma]
[ 226.288999] [<
ffffffff811a5739>] ? kfree+0x259/0x270
[ 226.289004] [<
ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
[ 226.289008] [<
ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma]
[ 226.289011] [<
ffffffffa0195f51>] ioat3_dma_probe+0x1d5/0x2aa [ioatdma]
[ 226.289016] [<
ffffffffa0194d12>] ioat_pci_probe+0x139/0x17c [ioatdma]
[ 226.289020] [<
ffffffff81354b8c>] local_pci_probe+0x5c/0xd0
[ 226.289023] [<
ffffffff81083e50>] ? destroy_work_on_stack+0x20/0x20
[ 226.289025] [<
ffffffff81083e68>] do_work_for_cpu+0x18/0x30
[ 226.289029] [<
ffffffff8108d997>] kthread+0xb7/0xc0
[ 226.289033] [<
ffffffff8166cef4>] kernel_thread_helper+0x4/0x10
[ 226.289036] [<
ffffffff81662d20>] ? _raw_spin_unlock_irq+0x30/0x50
[ 226.289038] [<
ffffffff81663234>] ? retint_restore_args+0x13/0x13
[ 226.289041] [<
ffffffff8108d8e0>] ? kthread_worker_fn+0x1a0/0x1a0
[ 226.289044] [<
ffffffff8166cef0>] ? gs_change+0x13/0x13
[ 226.289045] ---[ end trace
e1618afc7a606089 ]---
[ 226.289047] Mapped at:
[ 226.289048] [<
ffffffff81345307>] debug_dma_map_page+0x87/0x150
[ 226.289050] [<
ffffffffa019653c>] dma_map_page.constprop.18+0x70/0xb34 [ioatdma]
[ 226.289054] [<
ffffffffa0195702>] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma]
[ 226.289058] [<
ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
[ 226.289061] [<
ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma]
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Schlichter [Fri, 18 Jan 2013 23:28:22 +0000 (00:28 +0100)]
ACPI / processor: Get power info before updating the C-states
commit
f427e5f1cf75bba84cccdac1d8a90552d9ae1065 upstream.
acpi_processor_get_power_info() has to be called before
acpi_processor_setup_cpuidle_states() to have the latest
information available. This fixes the missing C-state information
after AC-->DC transition.
Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konrad Rzeszutek Wilk [Wed, 16 Jan 2013 22:40:07 +0000 (23:40 +0100)]
ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled
commit
b88a634a903d9670aa5f2f785aa890628ce0dece upstream.
If cpuidle is disabled, that means that:
per_cpu(acpi_cpuidle_device, pr->id)
is set to NULL as the acpi_processor_power_init ends up failing at
retval = cpuidle_register_driver(&acpi_idle_driver)
(in acpi_processor_power_init) and never sets the per_cpu idle
device. So when acpi_processor_hotplug on CPU online notification
tries to reference said device it crashes:
cpu 3 spinlock event irq 62
BUG: unable to handle kernel NULL pointer dereference at
0000000000000004
IP: [<
ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105
PGD
a259b067 PUD
ab38b067 PMD 0
Oops: 0002 [#1] SMP
odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf
CPU 1
Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680)
RIP: e030:[<
ffffffff81381013>] [<
ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105
RSP: e02b:
ffff88001742dca8 EFLAGS:
00010202
RAX:
0000000000010be9 RBX:
ffff8800a0a61800 RCX:
ffff880105380000
RDX:
0000000000000003 RSI:
0000000000000200 RDI:
ffff8800a0a61800
RBP:
ffff88001742dce8 R08:
ffffffff81812360 R09:
0000000000000200
R10:
aaaaaaaaaaaaaaaa R11:
0000000000000001 R12:
ffff8800a0a61800
R13:
00000000ffffff01 R14:
0000000000000000 R15:
ffffffff81a907a0
FS:
00007fd6942f7700(0000) GS:
ffff880105280000(0000) knlGS:
0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000004 CR3:
00000000a6773000 CR4:
0000000000042660
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process bash (pid: 3047, threadinfo
ffff88001742c000, task
ffff880017944000)
Stack:
0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800
0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0
ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336
Call Trace:
[<
ffffffff813815b1>] acpi_processor_hotplug+0x7c/0x9f
[<
ffffffff810ae336>] ? schedule_delayed_work_on+0x16/0x20
[<
ffffffff8137ee8f>] acpi_cpu_soft_notify+0x90/0xca
[<
ffffffff8166023d>] notifier_call_chain+0x4d/0x70
[<
ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10
[<
ffffffff81094a4b>] __cpu_notify+0x1b/0x30
[<
ffffffff81652cf7>] _cpu_up+0x103/0x14b
[<
ffffffff81652e18>] cpu_up+0xd9/0xec
[<
ffffffff8164a254>] store_online+0x94/0xd0
[<
ffffffff814122fb>] dev_attr_store+0x1b/0x20
[<
ffffffff81216404>] sysfs_write_file+0xf4/0x170
This patch fixes it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Fri, 14 Dec 2012 22:38:28 +0000 (23:38 +0100)]
drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
commit
4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream.
Quoting from Bspec, 3D_CHICKEN1, bit 10
This bit needs to be set always to "1", Project: DevSNB "
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 22 Jan 2013 16:43:40 +0000 (17:43 +0100)]
ALSA: usb-audio: Fix regression by disconnection-race-fix patch
[NOTE: the regression below is found only in 3.2-3.4 stable trees, so
there is no upstream commit corresponding to this patch]
The recent fix for the race at disconnection of usb-audio devices
(upstream commit
978520b7) triggers Oops when a device is unplugged
while playing on 3.2 and 3.4 kernels. The culprit is that the
shutdown flag check was wrongly added around the urb deactivation code
snippet. The urb deactivation code has to be performed even after the
device disconnected. Otherwise it remains undead and pokes the wild
access in the end.
The regression fix is simply reverting the shutdown flag check in that
code.
Reported-and-tested-by: Chris J Arges <christopherarges@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Cox [Tue, 4 Sep 2012 15:25:25 +0000 (16:25 +0100)]
ahci: Add identifiers for ASM106x devices
commit
7b4f6ecacb14f384adc1a5a67ad95eb082c02bd1 upstream.
They don't always appear as AHCI class devices but instead as IDE class.
Based on an initial patch by Hiroaki Nito
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42804
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhenzhong Duan [Thu, 20 Dec 2012 23:05:14 +0000 (15:05 -0800)]
drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists
commit
9f9c9cbb60576a1518d0bf93fb8e499cffccf377 upstream.
The right dmi version is in SMBIOS if it's zero in DMI region
This issue was originally found from an oracle bug.
One customer noticed system UUID doesn't match between dmidecode & uek2.
- HP ProLiant BL460c G6 :
# cat /sys/devices/virtual/dmi/id/product_uuid
00000000-0000-4C48-3031-
4D5030333531
# dmidecode | grep -i uuid
UUID:
00000000-0000-484C-3031-
4D5030333531
From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than
network byte order.
So we need to get dmi version to distinguish. If version is 0.0, the
real version is taken from the SMBIOS version. This is part of original
kernel comment in code.
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: Feng Jin <joe.jin@oracle.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhenzhong Duan [Thu, 20 Dec 2012 23:05:13 +0000 (15:05 -0800)]
drivers/firmware/dmi_scan.c: check dmi version when get system uuid
commit
f1d8e614d74b09531b9a85e812485340f3df7b1c upstream.
As of version 2.6 of the SMBIOS specification, the first 3 fields of the
UUID are supposed to be little-endian encoded.
Also a minor fix to match variable meaning and mute checkpatch.pl
[akpm@linux-foundation.org: tweak code comment]
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: Feng Jin <joe.jin@oracle.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joel D. Diaz [Wed, 10 Oct 2012 08:36:11 +0000 (10:36 +0200)]
SCSI: sd: Reshuffle init_sd to avoid crash
commit
afd5e34b2bb34881d3a789e62486814a49b47faa upstream.
scsi_register_driver will register a prep_fn() function, which
in turn migh need to use the sd_cdp_pool for DIF.
Which hasn't been initialised at this point, leading to
a crash. So reshuffle the init_sd() and exit_sd() paths
to have the driver registered last.
Signed-off-by: Joel D. Diaz <joeldiaz@us.ibm.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Cc: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pratyush Anand [Fri, 18 Jan 2013 11:23:56 +0000 (16:53 +0530)]
usb: dwc3: gadget: fix ep->maxburst for ep0
commit
6048e4c69d80600baba35856651056860d5d8f5a upstream.
dwc3_gadget_set_ep_config expects maxburst as incremented by 1. So, by
default initialize ep->maxburst to 1 for ep0.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Tue, 22 Jan 2013 16:37:35 +0000 (11:37 -0500)]
USB: UHCI: fix IRQ race during initialization
commit
0f815a0a700bc10547449bde6c106051a035a1b9 upstream.
This patch (as1644) fixes a race that occurs during startup in
uhci-hcd. If the IRQ line is shared with other devices, it's possible
for the handler routine to be called before the data structures are
fully initialized.
The problem is fixed by adding a check to the IRQ handler routine. If
the initialization hasn't finished yet, the routine will return
immediately.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Don Zickus <dzickus@redhat.com>
Tested-by: "Huang, Adrian (ISS Linux TW)" <adrian.huang@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Fri, 11 Jan 2013 19:07:22 +0000 (12:07 -0700)]
PCI: shpchp: Handle push button event asynchronously
commit
d347e75847c1fb299c97736638f45e6ea39702d4 upstream.
Use non-ordered workqueue for attention button events.
Attention button events on each slot can be handled asynchronously. So
we should use non-ordered workqueue. This patch also removes ordered
workqueue in shpchp as a result.
486b10b9f4 ("PCI: pciehp: Handle push button event asynchronously") made
the same change to pciehp. I split this out from a patch by Yijing Wang
<wangyijing@huawei.com> so we fix one thing at a time and to make the
shpchp history correspond more closely with the pciehp history.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yijing Wang [Fri, 11 Jan 2013 02:15:54 +0000 (10:15 +0800)]
PCI: pciehp: Use per-slot workqueues to avoid deadlock
commit
c2be6f93b383c873a4f9d521afa49b1b67d06085 upstream.
When we have a hotplug-capable PCIe port with a second hotplug-capable
PCIe port below it, removing the device below the upstream port causes
a deadlock.
The deadlock happens because we use the pciehp_wq workqueue to run
pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices
below the upstream port. When we remove the downstream PCIe port, we call
pciehp_remove(), the pciehp driver's .remove() method. That calls
flush_workqueue(pciehp_wq), which deadlocks because the
pciehp_power_thread() work item is still running.
This patch avoids the deadlock by creating a workqueue for every PCIe port
and removing the single shared workqueue.
Here's the call path that leads to the deadlock:
pciehp_queue_pushbutton_work
queue_work(pciehp_wq) # queue pciehp_power_thread
...
pciehp_power_thread
pciehp_disable_slot
remove_board
pciehp_unconfigure_device
pci_stop_and_remove_bus_device
...
pciehp_remove # pciehp driver .remove method
pciehp_release_ctrl
pcie_cleanup_slot
flush_workqueue(pciehp_wq)
This is fairly urgent because it can be caused by simply unplugging a
Thunderbolt adapter, as reported by Daniel below.
[bhelgaas: changelog]
Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.com
Reported-and-tested-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Tue, 27 Nov 2012 14:09:40 +0000 (14:09 +0000)]
PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported
commit
9e16721498b0c3d3ebfa0b503c63d35c0a4c0642 upstream.
Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
ASPM is unsupported. However, the semantics of force should probably allow
for this, especially as they did before
3c076351c4 ("PCI: Rework ASPM
disable code")
This patch just skips the clearing of any ASPM setup that the firmware has
carried out on this bus if pcie_aspm=force is being used.
Reference: http://bugs.launchpad.net/bugs/962038
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Betty Dall [Sun, 13 Jan 2013 22:46:18 +0000 (15:46 -0700)]
PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put()
commit
a82b6af37d20bfe6e99a4d890f1cf1d89059929f upstream.
The function aer_recover_queue() calls pci_get_domain_bus_and_slot(), which
requires that the caller decrement the reference count with pci_dev_put().
This patch adds the missing call to pci_dev_put().
Signed-off-by: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 21 Jan 2013 19:48:17 +0000 (20:48 +0100)]
wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task
commit
9067ac85d533651b98c2ff903182a20cbb361fcb upstream.
wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
Change it to use TASK_NORMAL and add the WARN_ON().
TASK_ALL has no other users, probably can be killed.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 21 Jan 2013 19:48:00 +0000 (20:48 +0100)]
ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL
commit
9899d11f654474d2d54ea52ceaa2a1f4db3abd68 upstream.
putreg() assumes that the tracee is not running and pt_regs_access() can
safely play with its stack. However a killed tracee can return from
ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
that debugger can actually read/modify the kernel stack until the tracee
does SAVE_REST again.
set_task_blockstep() can race with SIGKILL too and in some sense this
race is even worse, the very fact the tracee can be woken up breaks the
logic.
As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
call, this ensures that nobody can ever wakeup the tracee while the
debugger looks at it. Not only this fixes the mentioned problems, we
can do some cleanups/simplifications in arch_ptrace() paths.
Probably ptrace_unfreeze_traced() needs more callers, for example it
makes sense to make the tracee killable for oom-killer before
access_process_vm().
While at it, add the comment into may_ptrace_stop() to explain why
ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
Reported-by: Salman Qazi <sqazi@google.com>
Reported-by: Suleiman Souhlal <suleiman@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 21 Jan 2013 19:47:41 +0000 (20:47 +0100)]
ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()
commit
910ffdb18a6408e14febbb6e4b6840fd2c928c82 upstream.
Cleanup and preparation for the next change.
signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
necessary mask.
Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
which adds __TASK_TRACED.
This way ptrace_signal_wake_up() can work "inside" ptrace_request()
even if the tracee doesn't have the TASK_WAKEKILL bit set.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Kasatkin [Fri, 18 Jan 2013 21:56:39 +0000 (23:56 +0200)]
evm: checking if removexattr is not a NULL
commit
a67adb997419fb53540d4a4f79c6471c60bc69b6 upstream.
The following lines of code produce a kernel oops.
fd = socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0);
fchmod(fd, 0666);
[ 139.922364] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 139.924982] IP: [< (null)>] (null)
[ 139.924982] *pde =
00000000
[ 139.924982] Oops: 0000 [#5] SMP
[ 139.924982] Modules linked in: fuse dm_crypt dm_mod i2c_piix4 serio_raw evdev binfmt_misc button
[ 139.924982] Pid: 3070, comm: acpid Tainted: G D 3.8.0-rc2-kds+ #465 Bochs Bochs
[ 139.924982] EIP: 0060:[<
00000000>] EFLAGS:
00010246 CPU: 0
[ 139.924982] EIP is at 0x0
[ 139.924982] EAX:
cf5ef000 EBX:
cf5ef000 ECX:
c143d600 EDX:
c15225f2
[ 139.924982] ESI:
cf4d2a1c EDI:
cf4d2a1c EBP:
cc02df10 ESP:
cc02dee4
[ 139.924982] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 139.924982] CR0:
80050033 CR2:
00000000 CR3:
0c059000 CR4:
000006d0
[ 139.924982] DR0:
00000000 DR1:
00000000 DR2:
00000000 DR3:
00000000
[ 139.924982] DR6:
ffff0ff0 DR7:
00000400
[ 139.924982] Process acpid (pid: 3070, ti=
cc02c000 task=
d7705340 task.ti=
cc02c000)
[ 139.924982] Stack:
[ 139.924982]
c1203c88 00000000 cc02def4 cf4d2a1c ae21eefa 471b60d5 1083c1ba c26a5940
[ 139.924982]
e891fb5e 00000041 00000004 cc02df1c c1203964 00000000 cc02df4c c10e20c3
[ 139.924982]
00000002 00000000 00000000 22222222 c1ff2222 cf5ef000 00000000 d76efb08
[ 139.924982] Call Trace:
[ 139.924982] [<
c1203c88>] ? evm_update_evmxattr+0x5b/0x62
[ 139.924982] [<
c1203964>] evm_inode_post_setattr+0x22/0x26
[ 139.924982] [<
c10e20c3>] notify_change+0x25f/0x281
[ 139.924982] [<
c10cbf56>] chmod_common+0x59/0x76
[ 139.924982] [<
c10e27a1>] ? put_unused_fd+0x33/0x33
[ 139.924982] [<
c10cca09>] sys_fchmod+0x39/0x5c
[ 139.924982] [<
c13f4f30>] syscall_call+0x7/0xb
[ 139.924982] Code: Bad EIP value.
This happens because sockets do not define the removexattr operation.
Before removing the xattr, verify the removexattr function pointer is
not NULL.
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt [Fri, 14 Dec 2012 14:48:15 +0000 (09:48 -0500)]
ftrace: Be first to run code modification on modules
commit
c1bf08ac26e92122faab9f6c32ea8aba94612dae upstream.
If some other kernel subsystem has a module notifier, and adds a kprobe
to a ftrace mcount point (now that kprobes work on ftrace points),
when the ftrace notifier runs it will fail and disable ftrace, as well
as kprobes that are attached to ftrace points.
Here's the error:
WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280()
Hardware name: Bochs
Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared]
Pid: 8068, comm: modprobe Tainted: GF 3.7.0-0.rc8.git0.1.fc19.x86_64 #1
Call Trace:
[<
ffffffff8105e70f>] warn_slowpath_common+0x7f/0xc0
[<
ffffffff81134106>] ? __probe_kernel_read+0x46/0x70
[<
ffffffffa0180000>] ? 0xffffffffa017ffff
[<
ffffffffa0180000>] ? 0xffffffffa017ffff
[<
ffffffff8105e76a>] warn_slowpath_null+0x1a/0x20
[<
ffffffff810fd189>] ftrace_bug+0x239/0x280
[<
ffffffff810fd626>] ftrace_process_locs+0x376/0x520
[<
ffffffff810fefb7>] ftrace_module_notify+0x47/0x50
[<
ffffffff8163912d>] notifier_call_chain+0x4d/0x70
[<
ffffffff810882f8>] __blocking_notifier_call_chain+0x58/0x80
[<
ffffffff81088336>] blocking_notifier_call_chain+0x16/0x20
[<
ffffffff810c2a23>] sys_init_module+0x73/0x220
[<
ffffffff8163d719>] system_call_fastpath+0x16/0x1b
---[ end trace
9ef46351e53bbf80 ]---
ftrace failed to modify [<
ffffffffa0180000>] init_once+0x0/0x20 [fat]
actual: cc:bb:d2:4b:e1
A kprobe was added to the init_once() function in the fat module on load.
But this happened before ftrace could have touched the code. As ftrace
didn't run yet, the kprobe system had no idea it was a ftrace point and
simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1).
Then when ftrace went to modify the location from a call to mcount/fentry
into a nop, it didn't see a call op, but instead it saw the breakpoint op
and not knowing what to do with it, ftrace shut itself down.
The solution is to simply give the ftrace module notifier the max priority.
This should have been done regardless, as the core code ftrace modification
also happens very early on in boot up. This makes the module modification
closer to core modification.
Link: http://lkml.kernel.org/r/20130107140333.593683061@goodmis.org
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reported-by: Frank Ch. Eigler <fche@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Hugh Daschbach [Fri, 4 Jan 2013 22:39:09 +0000 (14:39 -0800)]
libata: ahci: Add support for Enmotus Bobcat device.
commit
7f9c9f8e24590e7dcd26ca408458c43df5b83e61 upstream.
Silicon does not support standard AHCI BAR assignment. Add
vendor/device exception to force BAR 2.
Signed-off-by: Hugh Daschbach <hugh.daschbach@enmotus.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Tue, 15 Jan 2013 16:17:54 +0000 (16:17 +0000)]
drm/i915: Invalidate the relocation presumed_offsets along the slow path
commit
262b6d363fcff16359c93bd58c297f961f6e6273 upstream.
In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.
Fixes regression from commit
bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Nov 21 22:07:12 2010 +0000
drm/i915: Handle pagefaults in execbuffer user relocations
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@fwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Greg Kroah-Hartman [Mon, 21 Jan 2013 19:47:35 +0000 (11:47 -0800)]
Linux 3.4.27
Ben Hutchings [Mon, 14 Jan 2013 01:29:17 +0000 (01:29 +0000)]
staging: vt6656: Fix inconsistent structure packing
commit
1ee4c55fc9620451b2a825d793042a7e0775391b upstream.
vt6656 has several headers that use the #pragma pack(1) directive to
enable structure packing, but never disable it. The layout of
structures defined in other headers can then depend on which order the
various headers are included in, breaking the One Definition Rule.
In practice this resulted in crashes on x86_64 until the order of header
inclusion was changed for some files in commit
11d404cb56ecd ('staging:
vt6656: fix headers and add cfg80211.'). But we need a proper fix that
won't be affected by future changes to the order of inclusion.
This removes the #pragma pack(1) directives and adds __packed to the
structure definitions for which packing appears to have been intended.
Reported-and-tested-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tormod Volden [Wed, 9 Jan 2013 21:23:32 +0000 (22:23 +0100)]
staging: wlan-ng: Fix clamping of returned SSID length
commit
811a37effdb11e54e1ff1ddaa944286c88f58487 upstream.
Commit
2e254212 broke listing of available network names, since it
clamped the length of the returned SSID to WLAN_BSSID_LEN (6) instead of
WLAN_SSID_MAXLEN (32).
https://bugzilla.kernel.org/show_bug.cgi?id=52501
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maxime Ripard [Mon, 14 Jan 2013 19:09:26 +0000 (20:09 +0100)]
tty: 8250_dw: Fix inverted arguments to serial_out in IRQ handler
commit
68e56cb3a068f9c30971c6117fbbd1e32918e49e upstream.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chao bi [Wed, 12 Dec 2012 03:40:56 +0000 (11:40 +0800)]
serial:ifx6x60:Delete SPI timer when shut down port
commit
014b9b4ce84281ccb3d723c792bed19815f3571a upstream.
When shut down SPI port, it's possible that MRDY has been asserted and a SPI
timer was activated waiting for SRDY assert, in the case, it needs to delete
this timer.
Signed-off-by: Chen Jun <jun.d.chen@intel.com>
Signed-off-by: channing <chao.bi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Thu, 17 Jan 2013 14:14:22 +0000 (15:14 +0100)]
USB: option: blacklist network interface on ONDA MT8205 4G LTE
Signed-off-by: Bjørn Mork <bjorn@mork.no>
commit
2291dff02e5f8c708a46a7c4c888f2c467e26642 upstream.
The driver description files gives these names to the vendor specific
functions on this modem:
Diag VID_19D2&PID_0265&MI_00
NMEA VID_19D2&PID_0265&MI_01
AT cmd VID_19D2&PID_0265&MI_02
Modem VID_19D2&PID_0265&MI_03
Net VID_19D2&PID_0265&MI_04
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Tue, 15 Jan 2013 09:29:49 +0000 (10:29 +0100)]
USB: option: add TP-LINK HSUPA Modem MA180
commit
99beb2e9687ffd61c92a9875141eabe6f57a71b9 upstream.
The driver description files gives these names to the vendor specific
functions on this modem:
Diagnostics VID_2357&PID_0201&MI_00
NMEA VID_2357&PID_0201&MI_01
Modem VID_2357&PID_0201&MI_03
Networkcard VID_2357&PID_0201&MI_04
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frediano Ziglio [Wed, 16 Jan 2013 12:00:55 +0000 (12:00 +0000)]
xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS guests.
commit
9174adbee4a9a49d0139f5d71969852b36720809 upstream.
This fixes CVE-2013-0190 / XSA-40
There has been an error on the xen_failsafe_callback path for failed
iret, which causes the stack pointer to be wrong when entering the
iret_exc error path. This can result in the kernel crashing.
In the classic kernel case, the relevant code looked a little like:
popl %eax # Error code from hypervisor
jz 5f
addl $16,%esp
jmp iret_exc # Hypervisor said iret fault
5: addl $16,%esp
# Hypervisor said segment selector fault
Here, there are two identical addls on either option of a branch which
appears to have been optimised by hoisting it above the jz, and
converting it to an lea, which leaves the flags register unaffected.
In the PVOPS case, the code looks like:
popl_cfi %eax # Error from the hypervisor
lea 16(%esp),%esp # Add $16 before choosing fault path
CFI_ADJUST_CFA_OFFSET -16
jz 5f
addl $16,%esp # Incorrectly adjust %esp again
jmp iret_exc
It is possible unprivileged userspace applications to cause this
behaviour, for example by loading an LDT code selector, then changing
the code selector to be not-present. At this point, there is a race
condition where it is possible for the hypervisor to return back to
userspace from an interrupt, fault on its own iret, and inject a
failsafe_callback into the kernel.
This bug has been present since the introduction of Xen PVOPS support
in commit
5ead97c84 (xen: Core Xen implementation), in 2.6.23.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Wilson [Tue, 15 Jan 2013 13:21:27 +0000 (13:21 +0000)]
xen/grant-table: correctly initialize grant table version 1
commit
d0b4d64aadb9f4a90669848de9ef3819050a98cd upstream.
Commit
85ff6acb075a484780b3d763fdf41596d8fc0970 (xen/granttable: Grant
tables V2 implementation) changed the GREFS_PER_GRANT_FRAME macro from
a constant to a conditional expression. The expression depends on
grant_table_version being appropriately set. Unfortunately, at init
time grant_table_version will be 0. The GREFS_PER_GRANT_FRAME
conditional expression checks for "grant_table_version == 1", and
therefore returns the number of grant references per frame for v2.
This causes gnttab_init() to allocate fewer pages for gnttab_list, as
a frame can old half the number of v2 entries than v1 entries. After
gnttab_resume() is called, grant_table_version is appropriately
set. nr_init_grefs will then be miscalculated and gnttab_free_count
will hold a value larger than the actual number of free gref entries.
If a guest is heavily utilizing improperly initialized v1 grant
tables, memory corruption can occur. One common manifestation is
corruption of the vmalloc list, resulting in a poisoned pointer
derefrence when accessing /proc/meminfo or /proc/vmallocinfo:
[ 40.770064] BUG: unable to handle kernel paging request at
0000200200001407
[ 40.770083] IP: [<
ffffffff811a6fb0>] get_vmalloc_info+0x70/0x110
[ 40.770102] PGD 0
[ 40.770107] Oops: 0000 [#1] SMP
[ 40.770114] CPU 10
This patch introduces a static variable, grefs_per_grant_frame, to
cache the calculated value. gnttab_init() now calls
gnttab_request_version() early so that grant_table_version and
grefs_per_grant_frame can be appropriately set. A few BUG_ON()s have
been added to prevent this type of bug from reoccurring in the future.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-and-Tested-by: Steven Noonan <snoonan@amazon.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Annie Li <annie.li@oracle.com>
Cc: xen-devel@lists.xen.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Philipp Reisner [Thu, 23 Feb 2012 11:56:26 +0000 (12:56 +0100)]
drbd: add missing part_round_stats to _drbd_start_io_acct
commit
72585d2428fa3a0daab02ebad1f41e5ef517dbaa upstream.
Without this, iostat frequently sees bogus svctime and >= 100% "utilization".
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Cc: Raoul Bhatia <raoul@bhatia.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Assmann [Tue, 4 Dec 2012 06:00:17 +0000 (06:00 +0000)]
igb: release already assigned MSI-X interrupts if setup fails
commit
52285b762b3681669215bf1d17ca6143448ab7d3 upstream.
During MSI-X setup the system might run out of vectors. If this happens the
already assigned vectors for this NIC should be freed before trying the
disable MSI-X. Failing to do so results in the following oops.
kernel BUG at drivers/pci/msi.c:341!
[...]
Call Trace:
[<
ffffffff8128f39d>] pci_disable_msix+0x3d/0x60
[<
ffffffffa037d1ce>] igb_reset_interrupt_capability+0x27/0x5c [igb]
[<
ffffffffa037d229>] igb_clear_interrupt_scheme+0x26/0x2d [igb]
[<
ffffffffa0384268>] igb_request_irq+0x73/0x297 [igb]
[<
ffffffffa0384554>] __igb_open+0xc8/0x223 [igb]
[<
ffffffffa0384815>] igb_open+0x13/0x15 [igb]
[<
ffffffff8144592f>] __dev_open+0xbf/0x120
[<
ffffffff81443e51>] __dev_change_flags+0xa1/0x180
[<
ffffffff81445828>] dev_change_flags+0x28/0x70
[<
ffffffff814af537>] devinet_ioctl+0x5b7/0x620
[<
ffffffff814b01c8>] inet_ioctl+0x88/0xa0
[<
ffffffff8142e8a0>] sock_do_ioctl+0x30/0x70
[<
ffffffff8142ecf2>] sock_ioctl+0x72/0x270
[<
ffffffff8118062c>] do_vfs_ioctl+0x8c/0x340
[<
ffffffff81180981>] sys_ioctl+0xa1/0xb0
[<
ffffffff815161a9>] system_call_fastpath+0x16/0x1b
Code: 48 89 df e8 1f 40 ed ff 4d 39 e6 49 8b 45 10 75 b6 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 7b 20 e8 3e 91 db ff eb ae <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00
RIP [<
ffffffff8128e144>] free_msi_irqs+0x124/0x130
RSP <
ffff880037503bd8>
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Tom Mingarelli [Tue, 20 Nov 2012 19:43:17 +0000 (19:43 +0000)]
intel-iommu: Prevent devices with RMRRs from being placed into SI Domain
commit
ea2447f700cab264019b52e2b417d689e052dcfd upstream.
This patch is to prevent non-USB devices that have RMRRs associated with them from
being placed into the SI Domain during init. This fixes the issue where the RMRR info
for devices being placed in and out of the SI Domain gets lost.
Signed-off-by: Thomas Mingarelli <thomas.mingarelli@hp.com>
Tested-by: Shuah Khan <shuah.khan@hp.com>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Cc: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Wed, 5 Dec 2012 07:43:57 +0000 (23:43 -0800)]
target: Add link_magic for fabric allow_link destination target_items
commit
0ff8754981261a80f4b77db2536dfea92c2d4539 upstream.
This patch adds [dev,lun]_link_magic value assignment + checks within generic
target_fabric_port_link() and target_fabric_mappedlun_link() code to ensure
destination config_item *target_item sent from configfs_symlink() ->
config_item_operations->allow_link() is the underlying se_device->dev_group
and se_lun->lun_group that we expect to symlink.
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Francois Romieu [Sat, 9 Jun 2012 10:53:16 +0000 (10:53 +0000)]
r8169: avoid NAPI scheduling delay.
commit
7dbb491878a2c51d372a8890fa45a8ff80358af1 upstream.
While reworking the r8169 driver a few months ago to perform the
smallest amount of work in the irq handler, I took care of avoiding
any irq mask register operation in the slow work dedicated user
context thread. The slow work thread scheduled an extra round of NAPI
work which would ultimately set the irq mask register as required,
thus keeping such irq mask operations in the NAPI handler.
It would eventually race with the irq handler and delay NAPI execution
for - assuming no further irq - a whole ksoftirqd period. Mildly a
problem for rare link changes or corner case PCI events.
The race was always lost after the last bh disabling lock had been
removed from the work thread and people started wondering where those
pesky "NOHZ: local_softirq_pending 08" messages came from.
Actually the irq mask register _can_ be set up directly in the slow
work thread.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Reported-by: Dave Jones <davej@redhat.com>
Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Sandeen [Thu, 15 Nov 2012 03:22:05 +0000 (22:22 -0500)]
ext4: init pagevec in ext4_da_block_invalidatepages
commit
66bea92c69477a75a5d37b9bfed5773c92a3c4b4 upstream.
ext4_da_block_invalidatepages is missing a pagevec_init(),
which means that pvec->cold contains random garbage.
This affects whether the page goes to the front or
back of the LRU when ->cold makes it to
free_hot_cold_page()
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Fri, 4 Jan 2013 16:02:18 +0000 (17:02 +0100)]
ALSA: usb - fix race in creation of M-Audio Fast track pro driver
commit
b98ae2729dea161edc96c9d177459b6c28bcbba5 upstream.
A patch in the 3.2 kernel caused regression with hotplugging the
M-Audio Fast track pro, or sound after suspend. I don't have the
device so I haven't done a full analysis, but it seems userspace
(both udev and pulseaudio) got confused when a card was created,
immediately destroyed, and then created again.
However, at least one person in the bug report (martin djfun)
reports that this patch resolves the issue for him. It also leaves
a message in the log:
"snd-usb-audio: probe of 1-1.1:1.1 failed with error -5" which is
a bit misleading. It is better than non-working audio, but maybe
there's a more elegant solution?
BugLink: https://bugs.launchpad.net/bugs/1095315
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jesse Barnes [Wed, 14 Nov 2012 20:43:31 +0000 (20:43 +0000)]
x86/Sandy Bridge: reserve pages when integrated graphics is present
commit
a9acc5365dbda29f7be2884efb63771dc24bd815 upstream.
SNB graphics devices have a bug that prevent them from accessing certain
memory ranges, namely anything below 1M and in the pages listed in the
table. So reserve those at boot if set detect a SNB gfx device on the
CPU to avoid GPU hangs.
Stephane Marchesin had a similar patch to the page allocator awhile
back, but rather than reserving pages up front, it leaked them at
allocation time.
[ hpa: made a number of stylistic changes, marked arrays as static
const, and made less verbose; use "memblock=debug" for full
verbosity. ]
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Mon, 14 Jan 2013 15:55:55 +0000 (16:55 +0100)]
s390/time: fix sched_clock() overflow
commit
ed4f20943cd4c7b55105c04daedf8d63ab6d499c upstream.
Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.
To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().
Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
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>
Roland Dreier [Wed, 2 Jan 2013 20:47:59 +0000 (12:47 -0800)]
target: Release se_cmd when LUN lookup fails for TMR
commit
5a3b6fc0092c5f8dee7820064ee54d2631d48573 upstream.
When transport_lookup_tmr_lun() fails and we return a task management
response from target_complete_tmr_failure(), we need to call
transport_cmd_check_stop_to_fabric() to release the last ref to the
cmd after calling se_tfo->queue_tm_rsp(), or else we will never remove
the failed TMR from the session command list (and we'll end up waiting
forever when trying to tear down the session).
(nab: Fix minor compile breakage)
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rustad [Fri, 21 Dec 2012 18:58:19 +0000 (10:58 -0800)]
tcm_fc: Do not report target role when target is not defined
commit
edec8dfefa1f372b2dd8197da555352e76a10c03 upstream.
Clear the target role when no target is provided for
the node performing a PRLI.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Acked by Robert Love <robert.w.love@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rustad [Fri, 21 Dec 2012 18:58:14 +0000 (10:58 -0800)]
tcm_fc: Do not indicate retry capability to initiators
commit
f2eeba214bcd0215b7f558cab6420e5fd153042b upstream.
When generating a PRLI response to an initiator, clear the
FCP_SPPF_RETRY bit in the response.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Acked by Robert Love <robert.w.love@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Schwinge [Fri, 16 Nov 2012 09:46:20 +0000 (10:46 +0100)]
sh: Fix FDPIC binary loader
commit
4a71997a3279a339e7336ea5d0cd27282e2dea44 upstream.
Ensure that the aux table is properly initialized, even when optional features
are missing. Without this, the FDPIC loader did not work. This was meant to
be included in commit
d5ab780305bb6d60a7b5a74f18cf84eb6ad153b1.
Signed-off-by: Thomas Schwinge <thomas@codesourcery.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 17 Jan 2013 16:51:56 +0000 (08:51 -0800)]
Linux 3.4.26
Alan Stern [Wed, 7 Nov 2012 15:31:30 +0000 (10:31 -0500)]
USB: fix endpoint-disabling for failed config changes
commit
36caff5d795429c572443894e8789c2150dd796b upstream.
This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller. The controller needs to
be told to disable the endpoints that have been enabled for the new
config. The existing code does this, but before storing the
information about which endpoints were enabled! As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.
The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config. If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble. The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Thu, 3 Jan 2013 12:15:26 +0000 (12:15 +0000)]
staging: comedi: Kconfig: COMEDI_NI_AT_A2150 should select COMEDI_FC
commit
34ffb33e09132401872fe79e95c30824ce194d23 upstream.
The 'ni_at_a2150' module links to `cfc_write_to_buffer` in the
'comedi_fc' module, so selecting 'COMEDI_NI_AT_A2150' in the kernel config
needs to also select 'COMEDI_FC'.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 30 Mar 2012 16:14:58 +0000 (17:14 +0100)]
staging: comedi: don't hijack hardware device private data
commit
c43435d7722134ed1fda58ce1025f41029bd58ad upstream.
comedi_auto_config() associates a Comedi minor device number with an
auto-configured hardware device and comedi_auto_unconfig() disassociates
it. Currently, these use the hardware device's private data pointer to
point to some allocated storage holding the minor device number. This
is a bit of a waste of the hardware device's private data pointer,
preventing it from being used for something more useful by the low-level
comedi device drivers. For example, it would make more sense if
comedi_usb_auto_config() was passed a pointer to the struct
usb_interface instead of the struct usb_device, but this cannot be done
currently because the low-level comedi drivers already use the private
data pointer in the struct usb_interface for something more useful.
This patch stops the comedi core hijacking the hardware device's private
data pointer. Instead, comedi_auto_config() stores a pointer to the
hardware device's struct device in the struct comedi_device_file_info
associated with the minor device number, and comedi_auto_unconfig()
calls new function comedi_find_board_minor() to recover the minor device
number associated with the hardware device.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Zafman [Tue, 4 Dec 2012 03:14:05 +0000 (19:14 -0800)]
libceph: Unlock unprocessed pages in start_read() error path
Function start_read() can get an error before processing all pages.
It must not only release the remaining pages, but unlock them too.
This fixes http://tracker.newdream.net/issues/3370
Signed-off-by: David Zafman <david.zafman@inktank.com>
Reviewed-by: Alex Elder <elder@inktank.com>
(cherry picked from commit
8884d53dd63b1d9315b343564fcbe1ede004a99e)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 19 Nov 2012 02:49:09 +0000 (10:49 +0800)]
ceph: call handle_cap_grant() for cap import message
If client sends cap message that requests new max size during
exporting caps, the exporting MDS will drop the message quietly.
So the client may wait for the reply that updates the max size
forever. call handle_cap_grant() for cap import message can
avoid this issue.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit
0e5e1774a92e6fe9c511585de8f078b4c4c68dbb)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 19 Nov 2012 02:49:08 +0000 (10:49 +0800)]
ceph: Fix __ceph_do_pending_vmtruncate
we should set i_truncate_pending to 0 after page cache is truncated
to i_truncate_size
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit
a85f50b6ef93fbbb2ae932ce9b2376509d172796)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 19 Nov 2012 02:49:07 +0000 (10:49 +0800)]
ceph: Don't add dirty inode to dirty list if caps is in migration
Add dirty inode to cap_dirty_migrating list instead, this can avoid
ceph_flush_dirty_caps() entering infinite loop.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit
0685235ffd9dbdb9ccbda587f8a3c83ad1d5a921)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 19 Nov 2012 02:49:06 +0000 (10:49 +0800)]
ceph: Fix infinite loop in __wake_requests
__wake_requests() will enter infinite loop if we use it to wake
requests in the session->s_waiting list. __wake_requests() deletes
requests from the list and __do_request() adds requests back to
the list.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit
ed75ec2cd19b47efcd292b6e23f58e56f4c5bc34)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-stable.git / log