Sven Killig [Fri, 1 Feb 2013 22:43:06 +0000 (23:43 +0100)]
USB: ftdi_sio: add PID/VID entries for ELV WS 300 PC II
commit
c249f911406efcc7456cb4af79396726bf7b8c57 upstream.
Add PID/VID entries for ELV WS 300 PC II weather station
Signed-off-by: Sven Killig <sven@killig.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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 [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 [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>
Greg Kroah-Hartman [Mon, 4 Feb 2013 00:22:00 +0000 (18:22 -0600)]
Linux 3.0.62
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>
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>
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>
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>
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>
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>
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>
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:52:34 +0000 (20:52 -0800)]
Linux 3.0.61
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>
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>
Robin Holt [Thu, 20 Dec 2012 23:05:50 +0000 (15:05 -0800)]
SGI-XP: handle non-fatal traps
commit
891348ca0f66206f1dc0e30d63757e3df1ae2d15 upstream.
We found a user code which was raising a divide-by-zero trap. That trap
would lead to XPC connections between system-partitions being torn down
due to the die_chain notifier callouts it received.
This also revealed a different issue where multiple callers into
xpc_die_deactivate() would all attempt to do the disconnect in parallel
which would sometimes lock up but often overwhelm the console on very
large machines as each would print at least one line of output at the
end of the deactivate.
I reviewed all the users of the die_chain notifier and changed the code
to ignore the notifier callouts for reasons which will not actually lead
to a system to continue on to call die().
[akpm@linux-foundation.org: fix ia64]
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@vger.kernel.org>
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>
Kees Cook [Thu, 24 Jan 2013 20:14:20 +0000 (14:14 -0600)]
x86: Use enum instead of literals for trap values [PARTIAL]
[Based on commit
c94082656dac74257f63e91f78d5d458ac781fa5 upstream, only
taking the traps.h portion.]
The traps are referred to by their numbers and it can be difficult to
understand them while reading the code without context. This patch adds
enumeration of the trap numbers and replaces the numbers with the correct
enum for x86.
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: http://lkml.kernel.org/r/20120310000710.GA32667@www.outflux.net
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Robin Holt <holt@sgi.com>
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>
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>
Bart Westgeest [Mon, 23 Jan 2012 15:55:46 +0000 (10:55 -0500)]
staging: usbip: changed function return type to void
commit
ac2b41acfa3efe4650102067a99251587a806d70 upstream.
The function usbip_pad_iso never returns anything but 0 (success).
Signed-off-by: Bart Westgeest <bart@elbrys.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Sun, 5 Jun 2011 20:51:49 +0000 (22:51 +0200)]
serial: 8250, increase PASS_LIMIT
commit
e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 upstream.
With virtual machines like qemu, it's pretty common to see "too much
work for irq4" messages nowadays. This happens when a bunch of output
is printed on the emulated serial console. This is caused by too low
PASS_LIMIT. When ISR loops more than the limit, it spits the message.
I've been using a kernel with doubled the limit and I couldn't see no
problems. Maybe it's time to get rid of the message now?
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Ram Gupta <ram.gupta5@gmail.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>
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>
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>
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>
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:48:40 +0000 (11:48 -0800)]
Linux 3.0.60
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>
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>
Julius Werner [Thu, 1 Nov 2012 19:47:59 +0000 (12:47 -0700)]
xhci: fix null-pointer dereference when destroying half-built segment rings
commit
68e5254adb88bede68285f11fb442a4d34fb550c upstream.
xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.
Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
This patch should be backported to kernels as old as 2.6.31, that
contains the commit
0ebbab37422315a5d0cb29792271085bafdf38c0 "USB: xhci:
Ring allocation and initialization."
A separate patch will need to be developed for kernels older than 3.4,
since the ring allocation code was refactored in that kernel.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
[bwh: Backported to 3.2:
- Adjust context
- Since segment allocation is done directly in xhci_ring_alloc(), walk
the list starting from ring->first_seg when freeing]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: CAI Qian <caiqian@redhat.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>
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>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Shuah Khan [Wed, 12 Dec 2012 23:27:51 +0000 (16:27 -0700)]
powerpc: fix wii_memory_fixups() compile error on 3.0.y tree
[not upstream as the code involved was removed in the 3.3.0 release]
Fix wii_memory_fixups() the following compile error on 3.0.y tree with
wii_defconfig on 3.0.y tree.
CC arch/powerpc/platforms/embedded6xx/wii.o
arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’:
arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format]
arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format]
arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format]
arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format]
cc1: all warnings being treated as errors
make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1
make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2
make: *** [arch/powerpc/platforms] Error 2
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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>
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:48:09 +0000 (08:48 -0800)]
Linux 3.0.59
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>
Daniel Vetter [Mon, 7 Jan 2013 09:27:13 +0000 (10:27 +0100)]
Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"
commit
48e858340dae43189a4e55647f6eac736766f828 upstream.
This reverts commit
9756fe38d10b2bf90c81dc4d2f17d5632e135364.
The bogus lvds output is actually a lvds->hdmi bridge, which we don't
really support. But unconditionally disabling it breaks some existing
setups.
Reported-by: John Tapsell <johnflux@gmail.com>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Graf [Sat, 6 Oct 2012 01:56:35 +0000 (03:56 +0200)]
KVM: PPC: 44x: fix DCR read/write
commit
e43a028752fed049e4bd94ef895542f96d79fa74 upstream.
When remembering the direction of a DCR transaction, we should write
to the same variable that we interpret on later when doing vcpu_run
again.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Woodhouse, David [Wed, 19 Dec 2012 13:25:35 +0000 (13:25 +0000)]
intel-iommu: Free old page tables before creating superpage
commit
6491d4d02893d9787ba67279595990217177b351 upstream.
The dma_pte_free_pagetable() function will only free a page table page
if it is asked to free the *entire* 2MiB range that it covers. So if a
page table page was used for one or more small mappings, it's likely to
end up still present in the page tables... but with no valid PTEs.
This was fine when we'd only be repopulating it with 4KiB PTEs anyway
but the same virtual address range can end up being reused for a
*large-page* mapping. And in that case were were trying to insert the
large page into the second-level page table, and getting a complaint
from the sanity check in __domain_mapping() because there was already a
corresponding entry. This was *relatively* harmless; it led to a memory
leak of the old page table page, but no other ill-effects.
Fix it by calling dma_pte_clear_range (hopefully redundant) and
dma_pte_free_pagetable() before setting up the new large page.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Ravi Murty <Ravi.Murty@intel.com>
Tested-by: Sudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Marzinski [Wed, 7 Nov 2012 06:38:06 +0000 (00:38 -0600)]
GFS2: Test bufdata with buffer locked and gfs2_log_lock held
commit
96e5d1d3adf56f1c7eeb07258f6a1a0a7ae9c489 upstream.
In gfs2_trans_add_bh(), gfs2 was testing if a there was a bd attached to the
buffer without having the gfs2_log_lock held. It was then assuming it would
stay attached for the rest of the function. However, without either the log
lock being held of the buffer locked, __gfs2_ail_flush() could detach bd at any
time. This patch moves the locking before the test. If there isn't a bd
already attached, gfs2 can safely allocate one and attach it before locking.
There is no way that the newly allocated bd could be on the ail list,
and thus no way for __gfs2_ail_flush() to detach it.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Sarah Sharp [Mon, 17 Dec 2012 22:12:35 +0000 (14:12 -0800)]
xhci: Handle HS bulk/ctrl endpoints that don't NAK.
commit
55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream.
A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK. If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).
The xHCI code to compute the NAK interval does not handle the special
case of zero properly. The current code unconditionally subtracts one
from bInterval and uses it as an exponent. This causes a very large
bInterval to be used, and warning messages like these will be printed:
usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.
This patch should be backported to kernels as old as 2.6.31, that contain
commit
dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".
Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Thu, 29 Nov 2012 14:05:57 +0000 (15:05 +0100)]
USB: hub: handle claim of enabled remote wakeup after reset
commit
07e72b95f5038cc82304b9a4a2eb7f9fc391ea68 upstream.
Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Thu, 15 Nov 2012 01:16:52 +0000 (17:16 -0800)]
USB: Increase reset timeout.
commit
77c7f072c87fa951e9a74805febf26466f31170c upstream.
John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete. The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.
This commit should be backported to kernels as old as 3.2, that contain
the commit
75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Tue, 20 Nov 2012 12:23:15 +0000 (13:23 +0100)]
usb: gadget: dummy: fix enumeration with g_multi
commit
1d16638e3b9cc195bac18a8fcbca748f33c1bc24 upstream.
If we do have endpoints named like "ep-a" then bEndpointAddress is
counted internally by the gadget framework.
If we do have endpoints named like "ep-1" then bEndpointAddress is
assigned from the digit after "ep-".
If we do have both, then it is likely that after we used up the
"generic" endpoints we will use the digits and thus assign one
bEndpointAddress to multiple endpoints.
This theory can be proofed by using the completely enabled g_multi.
Without this patch, the mass storage won't enumerate and times out
because it shares endpoints with RNDIS.
This patch also adds fills up the endpoints list so we have in total
endpoints 1 to 15 in + out available while some of them are restricted
to certain types like BULK or ISO. Without this change the nokia gadget
won't load because the system does not provide enough (BULK) endpoints
but it did before ep-a - ep-f were removed.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Denis N Ladin [Wed, 26 Dec 2012 13:29:44 +0000 (18:29 +0500)]
USB: cdc-acm: Add support for "PSC Scanning, Magellan 800i"
commit
036915a7a402753c05b8d0529f5fd08805ab46d0 upstream.
Adding support "PSC Scanning, Magellan 800i" in cdc-acm
Very simple, but very necessary.
Suitable for all versions of the kernel > 2.6
Signed-off-by: Denis N Ladin <denladin@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomasz Mloduchowski [Sun, 13 Jan 2013 22:32:53 +0000 (23:32 +0100)]
usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added
commit
8cf65dc386f3634a43312f436cc7a935476a40c4 upstream.
Simple fix to add support for Crucible Technologies COMET Caller ID
USB decoder - a device containing FTDI USB/Serial converter chip,
handling 1200bps CallerID messages decoded from the phone line -
adding correct USB PID is sufficient.
Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
and 3.8.0-rc3 on both amd64 and x86 arches.
Signed-off-by: Tomasz Mloduchowski <q@qdot.me>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Fri, 28 Dec 2012 16:29:52 +0000 (17:29 +0100)]
USB: option: add Telekom Speedstick LTE II
commit
5ec0085440ef8c2cf50002b34d5a504ee12aa2bf upstream.
also known as Alcatel One Touch L100V LTE
The driver description files gives these names to the vendor specific
functions on this modem:
Application1: VID_1BBB&PID_011E&MI_00
Application2: VID_1BBB&PID_011E&MI_01
Modem: VID_1BBB&PID_011E&MI_03
Ethernet: VID_1BBB&PID_011E&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>
Quentin.Li [Wed, 26 Dec 2012 08:58:22 +0000 (16:58 +0800)]
USB: option: Add new MEDIATEK PID support
commit
94a85b633829b946eef53fc1825d526312fb856f upstream.
In option.c, add some new MEDIATEK PIDs support for MEDIATEK new products. This
is a MEDIATEK inc. release patch.
Signed-off-by: Quentin.Li <snowmanli88@163.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Wed, 19 Dec 2012 14:15:17 +0000 (15:15 +0100)]
USB: option: blacklist network interface on ZTE MF880
commit
fab38246f318edcd0dcb8fd3852a47cf8938878a upstream.
The driver description files gives these names to the vendor specific
functions on this modem:
diag: VID_19D2&PID_0284&MI_00
nmea: VID_19D2&PID_0284&MI_01
at: VID_19D2&PID_0284&MI_02
mdm: VID_19D2&PID_0284&MI_03
net: VID_19D2&PID_0284&MI_04
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dzianis Kahanovich [Mon, 3 Dec 2012 13:06:26 +0000 (16:06 +0300)]
USB: option: add Nexpring NP10T terminal id
commit
ad86e58661b38b279b7519d4e49c7a19dc1654bb upstream.
Hyundai Petatel Inc. Nexpring NP10T terminal (EV-DO rev.A USB modem) ID
Signed-off-by: Denis Kaganovich <mahatma@eu.by>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Thu, 13 Dec 2012 22:08:52 +0000 (23:08 +0100)]
mac80211: use del_timer_sync for final sta cleanup timer deletion
commit
a56f992cdabc63f56b4b142885deebebf936ff76 upstream.
This is a very old bug, but there's nothing that prevents the
timer from running while the module is being removed when we
only do del_timer() instead of del_timer_sync().
The timer should normally not be running at this point, but
it's not clearly impossible (or we could just remove this.)
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Glisse [Tue, 8 Jan 2013 23:41:01 +0000 (18:41 -0500)]
radeon/kms: force rn50 chip to always report connected on analog output
commit
51861d4eebc2ddc25c77084343d060fa79f6e291 upstream.
Those rn50 chip are often connected to console remoting hw and load
detection often fails with those. Just don't try to load detect and
report connect.
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>
Samuel Thibault [Mon, 7 Jan 2013 21:03:51 +0000 (22:03 +0100)]
staging: speakup: avoid out-of-range access in synth_add()
commit
6102c48bd421074a33e102f2ebda3724e8d275f9 upstream.
Check that array index is in-bounds before accessing the synths[] array.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nickolai Zeldovich [Sat, 5 Jan 2013 19:17:45 +0000 (14:17 -0500)]
staging: speakup: avoid out-of-range access in synth_init()
commit
ae428655b826f2755a8101b27beda42a275ef8ad upstream.
Check that array index is in-bounds before accessing the synths[] array.
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Sat, 29 Dec 2012 17:36:53 +0000 (11:36 -0600)]
staging: r8712u: Add new device ID
commit
da849a92d3bafaf24d770e971c2c9e5c3f60b5d1 upstream.
The ISY IWL 1000 USB WLAN stick with USB ID 050d:11f1 is a clone of
the Belkin F7D1101 V1 device.
Reported-by: Thomas Hartmann <hartmann@ict.tuwien.ac.at>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Thomas Hartmann <hartmann@ict.tuwien.ac.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 4 Jan 2013 11:33:21 +0000 (11:33 +0000)]
staging: comedi: comedi_test: fix race when cancelling command
commit
c0729eeefdcd76db338f635162bf0739fd2c5f6f upstream.
Éric Piel reported a kernel oops in the "comedi_test" module. It was a
NULL pointer dereference within `waveform_ai_interrupt()` (actually a
timer function) that sometimes occurred when a running asynchronous
command is cancelled (either by the `COMEDI_CANCEL` ioctl or by closing
the device file).
This seems to be a race between the caller of `waveform_ai_cancel()`
which on return from that function goes and tears down the running
command, and the timer function which uses the command. In particular,
`async->cmd.chanlist` gets freed (and the pointer set to NULL) by
`do_become_nonbusy()` in "comedi_fops.c" but a previously scheduled
`waveform_ai_interrupt()` timer function will dereference that pointer
regardless, leading to the oops.
Fix it by replacing the `del_timer()` call in `waveform_ai_cancel()`
with `del_timer_sync()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reported-by: Éric Piel <piel@delmic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Tue, 4 Dec 2012 15:59:55 +0000 (15:59 +0000)]
staging: comedi: prevent auto-unconfig of manually configured devices
commit
7d3135af399e92cf4c9bbc5f86b6c140aab3b88c upstream.
When a low-level comedi driver auto-configures a device, a `struct
comedi_dev_file_info` is allocated (as well as a `struct
comedi_device`) by `comedi_alloc_board_minor()`. A pointer to the
hardware `struct device` is stored as a cookie in the `struct
comedi_dev_file_info`. When the low-level comedi driver
auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie
to find the `struct comedi_dev_file_info` so it can detach the comedi
device from the driver, clean it up and free it.
A problem arises if the user manually unconfigures and reconfigures the
comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer
associated with the original hardware device. The problem is that the
cookie is not cleared, so that a call to `comedi_auto_unconfig()` from
the low-level driver will still find it, detach it, clean it up and free
it.
Stop this problem occurring by always clearing the `hardware_device`
cookie in the `struct comedi_dev_file_info` whenever the
`COMEDI_DEVCONFIG` ioctl call is successful.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Dunn [Mon, 7 Jan 2013 21:55:12 +0000 (13:55 -0800)]
ALSA: pxa27x: fix ac97 cold reset
commit
41b645c8624df6ace020a8863ad1449d69140f7d upstream.
Cold reset on the pxa27x currently fails and
pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44)
appears in the kernel log. Through trial-and-error (the pxa270 developer's
manual is mostly incoherent on the topic of ac97 reset), I got cold reset to
complete by setting the WARM_RST bit in the GCR register (and later noticed that
pxa3xx does this for cold reset as well). Also, a timeout loop is needed to
wait for the reset to complete.
Tested on a palm treo 680 machine.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Brown [Fri, 4 Jan 2013 21:18:12 +0000 (21:18 +0000)]
ASoC: wm2000: Fix sense of speech clarity enable
commit
267f8fa2e1eef0612b2007e1f1846bcbc35cc1fa upstream.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Wong [Tue, 1 Jan 2013 21:20:27 +0000 (21:20 +0000)]
epoll: prevent missed events on EPOLL_CTL_MOD
commit
128dd1759d96ad36c379240f8b9463e8acfd37a1 upstream.
EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to
ensure events are not missed. Since the modifications to the interest
mask are not protected by the same lock as ep_poll_callback, we need to
ensure the change is visible to other CPUs calling ep_poll_callback.
We also need to ensure f_op->poll() has an up-to-date view of past
events which occured before we modified the interest mask. So this
barrier also pairs with the barrier in wq_has_sleeper().
This should guarantee either ep_poll_callback or f_op->poll() (or both)
will notice the readiness of a recently-ready/modified item.
This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in:
http://thread.gmane.org/gmane.linux.kernel/1408782/
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Voellmy <andreas.voellmy@yale.edu>
Tested-by: "Junchang(Jason) Wang" <junchang.wang@yale.edu>
Cc: netdev@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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>
Eric Dumazet [Fri, 4 Jan 2013 00:34:22 +0000 (00:34 +0000)]
rtnetlink: fix rtnl_calcit() and rtnl_dump_ifinfo()
commit
a4b64fbe482c7766f7925f03067fc637716bfa3f upstream.
nlmsg_parse() might return an error, so test its return value before
potential random memory accesses.
Errors introduced in commit
115c9b81928 (rtnetlink: Fix problem with
buffer allocation)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Rose [Fri, 4 Jan 2013 00:33:34 +0000 (00:33 +0000)]
rtnetlink: Fix problem with buffer allocation
commit
115c9b81928360d769a76c632bae62d15206a94a upstream.
Implement a new netlink attribute type IFLA_EXT_MASK. The mask
is a 32 bit value that can be used to indicate to the kernel that
certain extended ifinfo values are requested by the user application.
At this time the only mask value defined is RTEXT_FILTER_VF to
indicate that the user wants the ifinfo dump to send information
about the VFs belonging to the interface.
This patch fixes a bug in which certain applications do not have
large enough buffers to accommodate the extra information returned
by the kernel with large numbers of SR-IOV virtual functions.
Those applications will not send the new netlink attribute with
the interface info dump request netlink messages so they will
not get unexpectedly large request buffers returned by the kernel.
Modifies the rtnl_calcit function to traverse the list of net
devices and compute the minimum buffer size that can hold the
info dumps of all matching devices based upon the filter passed
in via the new netlink attribute filter mask. If no filter
mask is sent then the buffer allocation defaults to NLMSG_GOODSIZE.
With this change it is possible to add yet to be defined netlink
attributes to the dump request which should make it fairly extensible
in the future.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.0:
- Adjust context
- Drop the change in do_setlink() that reverts commit
f18da1456581
('net: RTNETLINK adjusting values of min_ifinfo_dump_size'), which
was never applied here]
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Rose [Fri, 4 Jan 2013 00:32:54 +0000 (00:32 +0000)]
rtnetlink: Compute and store minimum ifinfo dump size
commit
c7ac8679bec9397afe8918f788cbcef88c38da54 upstream.
The message size allocated for rtnl ifinfo dumps was limited to
a single page. This is not enough for additional interface info
available with devices that support SR-IOV and caused a bug in
which VF info would not be displayed if more than approximately
40 VFs were created per interface.
Implement a new function pointer for the rtnl_register service that will
calculate the amount of data required for the ifinfo dump and allocate
enough data to satisfy the request.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhang Rui [Tue, 4 Dec 2012 22:23:16 +0000 (23:23 +0100)]
ACPI : do not use Lid and Sleep button for S5 wakeup
commit
b7e383046c2c7c13ad928cd7407eafff758ddd4b upstream.
When system enters power off, the _PSW of Lid device is enabled.
But this may cause the system to reboot instead of power off.
A proper way to fix this is to always disable lid wakeup capability for S5.
References: https://bugzilla.kernel.org/show_bug.cgi?id=35262
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andre Przywara [Wed, 31 Oct 2012 16:20:50 +0000 (17:20 +0100)]
x86, amd: Disable way access filter on Piledriver CPUs
commit
2bbf0a1427c377350f001fbc6260995334739ad7 upstream.
The Way Access Filter in recent AMD CPUs may hurt the performance of
some workloads, caused by aliasing issues in the L1 cache.
This patch disables it on the affected CPUs.
The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
This new patch does not replace the old one, we just need another
quirk for newer CPUs.
The performance penalty without the patch depends on the
circumstances, but is a bit less than the last year's 3%.
The workloads affected would be those that access code from the same
physical page under different virtual addresses, so different
processes using the same libraries with ASLR or multiple instances of
PIE-binaries. The code needs to be accessed simultaneously from both
cores of the same compute unit.
More details can be found here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf
CPUs affected are anything with the core known as Piledriver.
That includes the new parts of the AMD A-Series (aka Trinity) and the
just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2,
A-Series has model 10h, with possible extensions to 1Fh. Hence the
range of model ids.
Signed-off-by: Andre Przywara <osp@andrep.de>
Link: http://lkml.kernel.org/r/1351700450-9277-1-git-send-email-osp@andrep.de
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Rientjes [Tue, 29 May 2012 22:06:23 +0000 (15:06 -0700)]
thp, memcg: split hugepage for memcg oom on cow
commit
1f1d06c34f7675026326cd9f39ff91e4555cf355 upstream.
On COW, a new hugepage is allocated and charged to the memcg. If the
system is oom or the charge to the memcg fails, however, the fault
handler will return VM_FAULT_OOM which results in an oom kill.
Instead, it's possible to fallback to splitting the hugepage so that the
COW results only in an order-0 page being allocated and charged to the
memcg which has a higher liklihood to succeed. This is expensive
because the hugepage must be split in the page fault handler, but it is
much better than unnecessarily oom killing a process.
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
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>
Namjae Jeon [Tue, 9 Oct 2012 15:09:12 +0000 (00:09 +0900)]
udf: don't increment lenExtents while writing to a hole
commit
fb719c59bdb4fca86ee1fd1f42ab3735ca12b6b2 upstream.
Incrementing lenExtents even while writing to a hole is bad
for performance as calls to udf_discard_prealloc and
udf_truncate_tail_extent would not return from start if
isize != lenExtents
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Namjae Jeon [Tue, 9 Oct 2012 15:08:56 +0000 (00:08 +0900)]
udf: fix memory leak while allocating blocks during write
commit
2fb7d99d0de3fd8ae869f35ab682581d8455887a upstream.
Need to brelse the buffer_head stored in cur_epos and next_epos.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ed Cashin [Sat, 12 Jan 2013 11:43:35 +0000 (06:43 -0500)]
aoe: do not call bdi_init after blk_alloc_queue
commit
0a41409c518083133e79015092585d68915865be upstream, but doesn't
apply, so this version is different for older kernels than 3.7.x
blk_alloc_queue has already done a bdi_init, so do not bdi_init
again in aoeblk_gdalloc. The extra call causes list corruption
in the per-CPU backing dev info stats lists.
Affected users see console WARNINGs about list_del corruption on
percpu_counter_destroy when doing "rmmod aoe" or "aoeflush -a"
when AoE targets have been detected and initialized by the
system.
The patch below applies to v3.6.11, with its v47 aoe driver. It
is expected to apply to all currently maintained stable kernels
except 3.7.y. A related but different fix has been posted for
3.7.y.
References:
RedHat bugzilla ticket with original report
https://bugzilla.redhat.com/show_bug.cgi?id=853064
LKML discussion of bug and fix
http://thread.gmane.org/gmane.linux.kernel/1416336/focus=1416497
Reported-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Ed Cashin <ecashin@coraid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Thu, 27 Dec 2012 06:42:48 +0000 (01:42 -0500)]
ext4: lock i_mutex when truncating orphan inodes
commit
721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream.
Commit
c278531d39 added a warning when ext4_flush_unwritten_io() is
called without i_mutex being taken. It had previously not been taken
during orphan cleanup since races weren't possible at that point in
the mount process, but as a result of this
c278531d39, we will now see
a kernel WARN_ON in this case. Take the i_mutex in
ext4_orphan_cleanup() to suppress this warning.
Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Tokarev [Tue, 25 Dec 2012 19:08:16 +0000 (14:08 -0500)]
ext4: do not try to write superblock on ro remount w/o journal
commit
d096ad0f79a782935d2e06ae8fb235e8c5397775 upstream.
When a journal-less ext4 filesystem is mounted on a read-only block
device (blockdev --setro will do), each remount (for other, unrelated,
flags, like suid=>nosuid etc) results in a series of scary messages
from kernel telling about I/O errors on the device.
This is becauese of the following code ext4_remount():
if (sbi->s_journal == NULL)
ext4_commit_super(sb, 1);
at the end of remount procedure, which forces writing (flushing) of
a superblock regardless whenever it is dirty or not, if the filesystem
is readonly or not, and whenever the device itself is readonly or not.
We only need call ext4_commit_super when the file system had been
previously mounted read/write.
Thanks to Eric Sandeen for help in diagnosing this issue.
Signed-off-By: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Fri, 21 Dec 2012 05:15:51 +0000 (00:15 -0500)]
jbd2: fix assertion failure in jbd2_journal_flush()
commit
d7961c7fa4d2e3c3f12be67e21ba8799b5a7238a upstream.
The following race is possible between start_this_handle() and someone
calling jbd2_journal_flush().
Process A Process B
start_this_handle().
if (journal->j_barrier_count) # false
if (!journal->j_running_transaction) { #true
read_unlock(&journal->j_state_lock);
jbd2_journal_lock_updates()
jbd2_journal_flush()
write_lock(&journal->j_state_lock);
if (journal->j_running_transaction) {
# false
... wait for committing trans ...
write_unlock(&journal->j_state_lock);
...
write_lock(&journal->j_state_lock);
if (!journal->j_running_transaction) { # true
jbd2_get_transaction(journal, new_transaction);
write_unlock(&journal->j_state_lock);
goto repeat; # eventually blocks on j_barrier_count > 0
...
J_ASSERT(!journal->j_running_transaction);
# fails
We fix the race by rechecking j_barrier_count after reacquiring j_state_lock
in exclusive mode.
Reported-by: yjwsignal@empal.com
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forrest Liu [Mon, 17 Dec 2012 14:55:39 +0000 (09:55 -0500)]
ext4: fix extent tree corruption caused by hole punch
commit
c36575e663e302dbaa4d16b9c72d2c9a913a9aef upstream.
When depth of extent tree is greater than 1, logical start value of
interior node is not correctly updated in ext4_ext_rm_idx.
Signed-off-by: Forrest Liu <forrestl@synology.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Ashish Sangwan <ashishsangwan2@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lothar Waßmann [Thu, 22 Nov 2012 12:49:14 +0000 (13:49 +0100)]
video: mxsfb: fix crash when unblanking the display
commit
6c1ecba8d84841277d68140ef485335d5be28485 upstream.
The VDCTRL4 register does not provide the MXS SET/CLR/TOGGLE feature.
The write in mxsfb_disable_controller() sets the data_cnt for the LCD
DMA to 0 which obviously means the max. count for the LCD DMA and
leads to overwriting arbitrary memory when the display is unblanked.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: Juergen Beisert <jbe@pengutronix.de>
Tested-by: Lauri Hintsala <lauri.hintsala@bluegiga.net>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Sun, 11 Nov 2012 16:07:57 +0000 (16:07 +0000)]
staging: vt6656: 64bit fixes: vCommandTimerWait change calculation of timer.
commit
70e227790d4ee4590023d8041a3485f8053593fc upstream.
The timer appears to run too fast/race on 64 bit systems.
Using msecs_to_jiffies seems to cause a deadlock on 64 bit.
A calculation of (MSecond * HZ) / 1000 appears to run satisfactory.
Change BSSIDInfoCount to u32.
After this patch the driver can be successfully connect on little endian 64/32 bit systems.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Sun, 11 Nov 2012 15:49:59 +0000 (15:49 +0000)]
staging: vt6656: 64bit fixes: key.c/h change unsigned long to u32
commit
c0d05b305b00c698b0a8c1b3d46c9380bce9db45 upstream.
Fixes long issues.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>