Larry Finger [Tue, 5 Nov 2013 21:15:29 +0000 (15:15 -0600)]
rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP
commit
78dbfecb95be4635b995af3bd29fa10013409fcd upstream.
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Tue, 5 Nov 2013 21:15:28 +0000 (15:15 -0600)]
rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP
commit
b4ade797668e33b4e8353c2701ce01d7084dfafa upstream.
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=63881.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Matthieu Baerts <matttbe@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Tue, 5 Nov 2013 21:15:30 +0000 (15:15 -0600)]
rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP
commit
3545f3d5f4af715c914394123ce7725a9cf0a1c4 upstream.
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vegard Nossum [Thu, 5 Sep 2013 11:00:14 +0000 (13:00 +0200)]
xen/blkback: fix reference counting
commit
ea5ec76d76da9279d12027c1828544c5ccbe7932 upstream.
If the permission check fails, we drop a reference to the blkif without
having taken it in the first place. The bug was introduced in commit
604c499cbbcc3d5fe5fb8d53306aa0fae1990109 (xen/blkback: Check device
permissions before allowing OP_DISCARD).
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Fri, 1 Nov 2013 03:00:24 +0000 (23:00 -0400)]
ext4: avoid bh leak in retry path of ext4_expand_extra_isize_ea()
commit
dcb9917ba041866686fe152850364826c4622a36 upstream.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huang Shijie [Tue, 12 Nov 2013 04:23:08 +0000 (12:23 +0800)]
mtd: gpmi: fix the NULL pointer
commit
885d71e5838f68d5dbee92ab952cc90ad6c1dc6b upstream.
The imx23 board will check the fingerprint, so it will call the
mx23_check_transcription_stamp. This function will use @chip->buffers->databuf
as its buffer which is allocated in the nand_scan_tail().
Unfortunately, the mx23_check_transcription_stamp is called before the
nand_scan_tail(). So we will meet a NULL pointer bug:
--------------------------------------------------------------------
[ 1.150000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xd7 (Samsung NAND 4GiB 3,3V 8-bit), 4096MiB, page size: 4096, OOB size: 8
[ 1.160000] Unable to handle kernel NULL pointer dereference at virtual address
000005d0
[ 1.170000] pgd =
c0004000
[ 1.170000] [
000005d0] *pgd=
00000000
[ 1.180000] Internal error: Oops: 5 [#1] ARM
[ 1.180000] Modules linked in:
[ 1.180000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0 #89
[ 1.180000] task:
c7440000 ti:
c743a000 task.ti:
c743a000
[ 1.180000] PC is at memcmp+0x10/0x54
[ 1.180000] LR is at gpmi_nand_probe+0x42c/0x894
[ 1.180000] pc : [<
c025fcb0>] lr : [<
c02f6a68>] psr:
20000053
[ 1.180000] sp :
c743be2c ip :
600000d3 fp :
ffffffff
[ 1.180000] r10:
000005d0 r9 :
c02f5f08 r8 :
00000000
[ 1.180000] r7 :
c75858a8 r6 :
c75858a8 r5 :
c7585b18 r4 :
c7585800
[ 1.180000] r3 :
000005d0 r2 :
00000004 r1 :
c05c33e4 r0 :
000005d0
[ 1.180000] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 1.180000] Control:
0005317f Table:
40004000 DAC:
00000017
[ 1.180000] Process swapper (pid: 1, stack limit = 0xc743a1c0)
--------------------------------------------------------------------
This patch rearrange the init procedure:
Set the NAND_SKIP_BBTSCAN to skip the nand scan firstly, and after we
set the proper settings, we will call the chip->scan_bbt() manually.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Reported-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huang Shijie [Mon, 11 Nov 2013 04:13:45 +0000 (12:13 +0800)]
mtd: gpmi: fix kernel BUG due to racing DMA operations
commit
7b3d2fb92067bcb29f0f085a9fa9fa64920a6646 upstream.
[1] The gpmi uses the nand_command_lp to issue the commands to NAND chips.
The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles
a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0)
from the NAND, we may send two DMA operations back-to-back.
If we do not serialize the two DMA operations, we will meet a bug when
1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG,
and CONFIG_DEBUG_SG.
1.2) Use the following commands in an UART console and a SSH console:
cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done
cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done
The kernel log shows below:
-----------------------------------------------------------------
kernel BUG at lib/scatterlist.c:28!
Unable to handle kernel NULL pointer dereference at virtual address
00000000
.........................
[<
80044a0c>] (__bug+0x18/0x24) from [<
80249b74>] (sg_next+0x48/0x4c)
[<
80249b74>] (sg_next+0x48/0x4c) from [<
80255398>] (debug_dma_unmap_sg+0x170/0x1a4)
[<
80255398>] (debug_dma_unmap_sg+0x170/0x1a4) from [<
8004af58>] (dma_unmap_sg+0x14/0x6c)
[<
8004af58>] (dma_unmap_sg+0x14/0x6c) from [<
8027e594>] (mxs_dma_tasklet+0x18/0x1c)
[<
8027e594>] (mxs_dma_tasklet+0x18/0x1c) from [<
8007d444>] (tasklet_action+0x114/0x164)
-----------------------------------------------------------------
1.3) Assume the two DMA operations is X (first) and Y (second).
The root cause of the bug:
Assume process P issues DMA X, and sleep on the completion
@this->dma_done. X's tasklet callback is dma_irq_callback. It firstly
wake up the process sleeping on the completion @this->dma_done,
and then trid to unmap the scatterlist S. The waked process P will
issue Y in another ARM core. Y initializes S->sg_magic to zero
with sg_init_one(), while dma_irq_callback is unmapping S at the same
time.
See the diagram:
ARM core 0 | ARM core 1
-------------------------------------------------------------
(P issues DMA X, then sleep) --> |
|
(X's tasklet wakes P) --> |
|
| <-- (P begin to issue DMA Y)
|
(X's tasklet unmap the |
scatterlist S with dma_unmap_sg) --> | <-- (Y calls sg_init_one() to init
| scatterlist S)
|
[2] This patch serialize both the X and Y in the following way:
Unmap the DMA scatterlist S firstly, and wake up the process at the end
of the DMA callback, in such a way, Y will be executed after X.
After this patch:
ARM core 0 | ARM core 1
-------------------------------------------------------------
(P issues DMA X, then sleep) --> |
|
(X's tasklet unmap the |
scatterlist S with dma_unmap_sg) --> |
|
(X's tasklet wakes P) --> |
|
| <-- (P begin to issue DMA Y)
|
| <-- (Y calls sg_init_one() to init
| scatterlist S)
|
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Wu [Tue, 5 Nov 2013 09:59:07 +0000 (17:59 +0800)]
mtd: atmel_nand: fix bug driver will in a dead lock if no nand detected
commit
a749d13acd8e079ed4c77a9456d842dc94af8f17 upstream.
In the atmel driver probe function, the code shows like following:
atmel_nand_probe(...) {
...
err_nand_ioremap:
platform_driver_unregister(&atmel_nand_nfc_driver);
return res;
}
If no nand flash detected, the driver probe function will goto
err_nand_ioremap label.
Then platform_driver_unregister() will be called. It will get the
lock of atmel_nand device since it is parent of nfc_device. The
problem is the lock is already hold by atmel_nand_probe itself.
So system will be in a dead lock.
This patch just simply removed to platform_driver_unregister() call.
When atmel_nand driver is quit the platform_driver_unregister() will
be called in atmel_nand_remove().
[Brian: the NAND platform probe really has no business
registering/unregistering another driver; this fixes the deadlock, but
we should follow up the likely racy behavior here with a better
architecture]
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang Haitao [Thu, 22 Aug 2013 11:32:38 +0000 (19:32 +0800)]
mtd: map: fixed bug in 64-bit systems
commit
a4d62babf988fe5dfde24437fa135ef147bc7aa0 upstream.
Hardware:
CPU: XLP832,the 64-bit OS
NOR Flash:S29GL128S 128M
Software:
Kernel:2.6.32.41
Filesystem:JFFS2
When writing files, errors appear:
Write len 182 but return retlen 180
Write of 182 bytes at 0x072c815c failed. returned -5, retlen 180
Write len 186 but return retlen 184
Write of 186 bytes at 0x072caff4 failed. returned -5, retlen 184
These errors exist only in 64-bit systems,not in 32-bit systems. After analysis, we
found that the left shift operation is wrong in map_word_load_partial. For instance:
unsigned char buf[3] ={0x9e,0x3a,0xea};
map_bankwidth(map) is 4;
for (i=0; i < 3; i++) {
int bitpos;
bitpos = (map_bankwidth(map)-1-i)*8;
orig.x[0] &= ~(0xff << bitpos);
orig.x[0] |= buf[i] << bitpos;
}
The value of orig.x[0] is expected to be 0x9e3aeaff, but in this situation(64-bit
System) we'll get the wrong value of 0xffffffff9e3aeaff due to the 64-bit sign
extension:
buf[i] is defined as "unsigned char" and the left-shift operation will convert it
to the type of "signed int", so when left-shift buf[i] by 24 bits, the final result
will get the wrong value: 0xffffffff9e3aeaff.
If the left-shift bits are less than 24, then sign extension will not occur. Whereas
the bankwidth of the nor flash we used is 4, therefore this BUG emerges.
Signed-off-by: Pang Xunlei <pang.xunlei@zte.com.cn>
Signed-off-by: Zhang Yi <zhang.yi20@zte.com.cn>
Signed-off-by: Lu Zhongjun <lu.zhongjun@zte.com.cn>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Thu, 25 Jul 2013 01:32:07 +0000 (18:32 -0700)]
mtd: m25p80: fix allocation size
commit
778d226a1462572b51d6777cdb1d611543410cb4 upstream.
This patch fixes two memory errors:
1. During a probe failure (in mtd_device_parse_register?) the command
buffer would not be freed.
2. The command buffer's size is determined based on the 'fast_read'
boolean, but the assignment of fast_read is made after this
allocation. Thus, the buffer may be allocated "too small".
To fix the first, just switch to the devres version of kzalloc.
To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth
saving a byte to fiddle around with the conditions here.
This problem was reported by Yuhang Wang a while back.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Yuhang Wang <wangyuhang2014@gmail.com>
Reviewed-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Wed, 28 Aug 2013 01:45:10 +0000 (18:45 -0700)]
mtd: nand: hack ONFI for non-power-of-2 dimensions
commit
4355b70cf48363c50a9de450b01178c83aba8f6a upstream.
Some bright specification writers decided to write this in the ONFI spec
(from ONFI 3.0, Section 3.1):
"The number of blocks and number of pages per block is not required to
be a power of two. In the case where one of these values is not a
power of two, the corresponding address shall be rounded to an
integral number of bits such that it addresses a range up to the
subsequent power of two value. The host shall not access upper
addresses in a range that is shown as not supported."
This breaks every assumption MTD makes about NAND block/chip-size
dimensions -- they *must* be a power of two!
And of course, an enterprising manufacturer has made use of this lovely
freedom. Exhibit A: Micron MT29F32G08CBADAWP
"- Plane size: 2 planes x 1064 blocks per plane
- Device size: 32Gb: 2128 blockss [sic]"
This quickly hits a BUG() in nand_base.c, since the extra dimensions
overflow so we think it's a second chip (on my single-chip setup):
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x44 (Micron MT29F32G08CBADAWP), 4256MiB, page size: 8192, OOB size: 744
------------[ cut here ]------------
kernel BUG at drivers/mtd/nand/nand_base.c:203!
Internal error: Oops - BUG: 0 [#1] SMP ARM
[... trim ...]
[<
c02cf3e4>] (nand_select_chip+0x18/0x2c) from [<
c02d25c0>] (nand_do_read_ops+0x90/0x424)
[<
c02d25c0>] (nand_do_read_ops+0x90/0x424) from [<
c02d2dd8>] (nand_read+0x54/0x78)
[<
c02d2dd8>] (nand_read+0x54/0x78) from [<
c02ad2c8>] (mtd_read+0x84/0xbc)
[<
c02ad2c8>] (mtd_read+0x84/0xbc) from [<
c02d4b28>] (scan_read.clone.4+0x4c/0x64)
[<
c02d4b28>] (scan_read.clone.4+0x4c/0x64) from [<
c02d4c88>] (search_bbt+0x148/0x290)
[<
c02d4c88>] (search_bbt+0x148/0x290) from [<
c02d4ea4>] (nand_scan_bbt+0xd4/0x5c0)
[... trim ...]
---[ end trace
0c9363860d865ff2 ]---
So to fix this, just truncate these dimensions down to the greatest
power-of-2 dimension that is less than or equal to the specified
dimension.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Tue, 15 Oct 2013 20:14:38 +0000 (14:14 -0600)]
loop: fix crash when using unassigned loop device
commit
ef7e7c82e02b602f29c2b87f42dcd6143a6777da upstream.
When the loop module is loaded, it creates 8 loop devices /dev/loop[0-7].
The devices have no request routine and thus, when they are used without
being assigned, a crash happens.
For example, these commands cause crash (assuming there are no used loop
devices):
Kernel Fault: Code=26 regs=
000000007f420980 (Addr=
0000000000000010)
CPU: 1 PID: 50 Comm: kworker/1:1 Not tainted 3.11.0 #1
Workqueue: ksnaphd do_metadata [dm_snapshot]
task:
000000007fcf4078 ti:
000000007f420000 task.ti:
000000007f420000
[ 116.319988]
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW:
00001000000001001111111100001111 Not tainted
r00-03
000000ff0804ff0f 00000000408bf5d0 00000000402d8204 000000007b7ff6c0
r04-07
00000000408a95d0 000000007f420950 000000007b7ff6c0 000000007d06c930
r08-11
000000007f4205c0 0000000000000001 000000007f4205c0 000000007f4204b8
r12-15
0000000000000010 0000000000000000 0000000000000000 0000000000000000
r16-19
000000001108dd48 000000004061cd7c 000000007d859800 000000000800000f
r20-23
0000000000000000 0000000000000008 0000000000000000 0000000000000000
r24-27
00000000ffffffff 000000007b7ff6c0 000000007d859800 00000000408a95d0
r28-31
0000000000000000 000000007f420950 000000007f420980 000000007f4208e8
sr00-03
0000000000000000 0000000000000000 0000000000000000 0000000000303000
sr04-07
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 117.549988]
IASQ:
0000000000000000 0000000000000000 IAOQ:
00000000402d82fc 00000000402d8300
IIR:
53820020 ISR:
0000000000000000 IOR:
0000000000000010
CPU: 1 CR30:
000000007f420000 CR31:
ffffffffffffffff
ORIG_R28:
0000000000000001
IAOQ[0]: generic_make_request+0x11c/0x1a0
IAOQ[1]: generic_make_request+0x120/0x1a0
RP(r2): generic_make_request+0x24/0x1a0
Backtrace:
[<
00000000402d83f0>] submit_bio+0x70/0x140
[<
0000000011087c4c>] dispatch_io+0x234/0x478 [dm_mod]
[<
0000000011087f44>] sync_io+0xb4/0x190 [dm_mod]
[<
00000000110883bc>] dm_io+0x2c4/0x310 [dm_mod]
[<
00000000110bfcd0>] do_metadata+0x28/0xb0 [dm_snapshot]
[<
00000000401591d8>] process_one_work+0x160/0x460
[<
0000000040159bc0>] worker_thread+0x300/0x478
[<
0000000040161a70>] kthread+0x118/0x128
[<
0000000040104020>] end_fault_vector+0x20/0x28
[<
0000000040177220>] task_tick_fair+0x420/0x4d0
[<
00000000401aa048>] invoke_rcu_core+0x50/0x60
[<
00000000401ad5b8>] rcu_check_callbacks+0x210/0x8d8
[<
000000004014aaa0>] update_process_times+0xa8/0xc0
[<
00000000401ab86c>] rcu_process_callbacks+0x4b4/0x598
[<
0000000040142408>] __do_softirq+0x250/0x2c0
[<
00000000401789d0>] find_busiest_group+0x3c0/0xc70
[ 119.379988]
Kernel panic - not syncing: Kernel Fault
Rebooting in 1 seconds..
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Mon, 14 Oct 2013 16:12:24 +0000 (12:12 -0400)]
loop: fix crash if blk_alloc_queue fails
commit
3ec981e30fae1f3c8728a05c730acaa1f627bcfb upstream.
loop: fix crash if blk_alloc_queue fails
If blk_alloc_queue fails, loop_add cleans up, but it doesn't clean up the
identifier allocated with idr_alloc. That causes crash on module unload in
idr_for_each(&loop_index_idr, &loop_exit_cb, NULL); where we attempt to
remove non-existed device with that id.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000380
IP: [<
ffffffff812057c9>] del_gendisk+0x19/0x2d0
PGD
43d399067 PUD
43d0ad067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: loop(-) dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_loop dm_mod ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_userspace cpufreq_stats cpufreq_ondemand cpufreq_conservative cpufreq_powersave spadfs fuse hid_generic usbhid hid raid0 md_mod dmi_sysfs nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc lm85 hwmon_vid snd_hwdep snd_usbmidi_lib snd_rawmidi snd soundcore acpi_cpufreq ohci_hcd freq_table tg3 ehci_pci mperf ehci_hcd kvm_amd kvm sata_svw serverworks libphy libata ide_core k10temp usbcore hwmon microcode ptp pcspkr pps_core e100 skge mii usb_common i2c_piix4 floppy evdev rtc_cmos i2c_core processor but!
ton unix
CPU: 7 PID: 2735 Comm: rmmod Tainted: G W 3.10.15-devel #15
Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009
task:
ffff88043d38e780 ti:
ffff88043d21e000 task.ti:
ffff88043d21e000
RIP: 0010:[<
ffffffff812057c9>] [<
ffffffff812057c9>] del_gendisk+0x19/0x2d0
RSP: 0018:
ffff88043d21fe10 EFLAGS:
00010282
RAX:
ffffffffa05102e0 RBX:
0000000000000000 RCX:
0000000000000000
RDX:
0000000000000000 RSI:
ffff88043ea82800 RDI:
0000000000000000
RBP:
ffff88043d21fe48 R08:
0000000000000000 R09:
0000000000000001
R10:
0000000000000001 R11:
0000000000000000 R12:
00000000000000ff
R13:
0000000000000080 R14:
0000000000000000 R15:
ffff88043ea82800
FS:
00007ff646534700(0000) GS:
ffff880447000000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000000380 CR3:
000000043e9bf000 CR4:
00000000000007e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Stack:
ffffffff8100aba4 0000000000000092 ffff88043d21fe48 ffff88043ea82800
00000000000000ff ffff88043d21fe98 0000000000000000 ffff88043d21fe60
ffffffffa05102b4 0000000000000000 ffff88043d21fe70 ffffffffa05102ec
Call Trace:
[<
ffffffff8100aba4>] ? native_sched_clock+0x24/0x80
[<
ffffffffa05102b4>] loop_remove+0x14/0x40 [loop]
[<
ffffffffa05102ec>] loop_exit_cb+0xc/0x10 [loop]
[<
ffffffff81217b74>] idr_for_each+0x104/0x190
[<
ffffffffa05102e0>] ? loop_remove+0x40/0x40 [loop]
[<
ffffffff8109adc5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<
ffffffffa05135dc>] loop_exit+0x34/0xa58 [loop]
[<
ffffffff810a98ea>] SyS_delete_module+0x13a/0x260
[<
ffffffff81221d5e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<
ffffffff813cff16>] system_call_fastpath+0x1a/0x1f
Code: f0 4c 8b 6d f8 c9 c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56 41 55 4c 8d af 80 00 00 00 41 54 53 48 89 fb 48 83 ec 18 <48> 83 bf 80 03 00
00 00 74 4d e8 98 fe ff ff 31 f6 48 c7 c7 20
RIP [<
ffffffff812057c9>] del_gendisk+0x19/0x2d0
RSP <
ffff88043d21fe10>
CR2:
0000000000000380
---[ end trace
64ec069ec70f1309 ]---
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Thu, 10 Oct 2013 11:53:25 +0000 (13:53 +0200)]
IB/srp: Report receive errors correctly
commit
cd4e38542a5c2cab94e5410fb17c1cc004a60792 upstream.
The IB spec does not guarantee that the opcode is available in error
completions. Hence do not rely on it. See also commit
948d1e889e5b
("IB/srp: Introduce srp_handle_qp_err()").
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Thu, 10 Oct 2013 11:52:33 +0000 (13:52 +0200)]
IB/srp: Avoid offlining operational SCSI devices
commit
99b6697a50c2acbe3ca2772d359fc9a28835dc84 upstream.
If SCSI commands are submitted with a SCSI request timeout that is
lower than the the IB RC timeout, it can happen that the SCSI error
handler has already started device recovery before transport layer
error handling starts. So it can happen that the SCSI error handler
tries to abort a SCSI command after it has been reset by
srp_rport_reconnect().
Tell the SCSI error handler that such commands have finished and that
it is not necessary to continue its recovery strategy for commands
that have been reset by srp_rport_reconnect().
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vu Pham [Thu, 10 Oct 2013 11:50:29 +0000 (13:50 +0200)]
IB/srp: Remove target from list before freeing Scsi_Host structure
commit
65d7dd2f3479ef5aec1d9ddd1481cb7851c11af6 upstream.
Remove an SRP target from the SRP target list before invoking the last
scsi_host_put() call. This change is necessary because that last put
frees the memory that holds the srp_target_port structure.
This patch prevents the following kernel oops:
RIP: 0010:[<
ffffffff810b00d0>] __lock_acquire+0x500/0x1570
Call Trace:
[<
ffffffff810b11e4>] lock_acquire+0xa4/0x120
[<
ffffffff81531206>] _spin_lock+0x36/0x70
[<
ffffffffa01b6d8f>] srp_remove_work+0xef/0x180 [ib_srp]
[<
ffffffff8109125c>] worker_thread+0x21c/0x3d0
[<
ffffffff81096e86>] kthread+0x96/0xa0
[<
ffffffff8100c20a>] child_rip+0xa/0x20
Signed-off-by: Vu Pham <vuhuong@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ bvanassche - Modified path description and CC'ed stable. ]
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Mike Marciniszyn [Fri, 25 Oct 2013 15:17:59 +0000 (11:17 -0400)]
IB/qib: Fix txselect regression
commit
2fadd83184d58701f1116ca578465b5a75f9417c upstream.
Commit
7fac33014f54("IB/qib: checkpatch fixes") was overzealous in
removing a simple_strtoul for a parse routine, setup_txselect(). That
routine is required to handle a multi-value string.
Unwind that aspect of the fix.
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Fri, 4 Oct 2013 13:29:12 +0000 (09:29 -0400)]
IB/qib: Convert qib_user_sdma_pin_pages() to use get_user_pages_fast()
commit
603e7729920e42b3c2f4dbfab9eef4878cb6e8fa upstream.
qib_user_sdma_queue_pkts() gets called with mmap_sem held for
writing. Except for get_user_pages() deep down in
qib_user_sdma_pin_pages() we don't seem to need mmap_sem at all. Even
more interestingly the function qib_user_sdma_queue_pkts() (and also
qib_user_sdma_coalesce() called somewhat later) call copy_from_user()
which can hit a page fault and we deadlock on trying to get mmap_sem
when handling that fault.
So just make qib_user_sdma_pin_pages() use get_user_pages_fast() and
leave mmap_sem locking for mm.
This deadlock has actually been observed in the wild when the node
is under memory pressure.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Fri, 4 Oct 2013 13:29:06 +0000 (09:29 -0400)]
IB/ipath: Convert ipath_user_sdma_pin_pages() to use get_user_pages_fast()
commit
4adcf7fb6783e354aab38824d803fa8c4f8e8a27 upstream.
ipath_user_sdma_queue_pkts() gets called with mmap_sem held for
writing. Except for get_user_pages() deep down in
ipath_user_sdma_pin_pages() we don't seem to need mmap_sem at all.
Even more interestingly the function ipath_user_sdma_queue_pkts() (and
also ipath_user_sdma_coalesce() called somewhat later) call
copy_from_user() which can hit a page fault and we deadlock on trying
to get mmap_sem when handling that fault. So just make
ipath_user_sdma_pin_pages() use get_user_pages_fast() and leave
mmap_sem locking for mm.
This deadlock has actually been observed in the wild when the node
is under memory pressure.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Merged in fix for call to get_user_pages_fast from Tetsuo Handa
<penguin-kernel@I-love.SAKURA.ne.jp>. - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Seppanen [Wed, 20 Nov 2013 22:19:52 +0000 (14:19 -0800)]
iscsi-target: chap auth shouldn't match username with trailing garbage
commit
86784c6bdeeef78eed94d298be7a8879f6a97ee2 upstream.
In iSCSI negotiations with initiator CHAP enabled, usernames with
trailing garbage are permitted, because the string comparison only
checks the strlen of the configured username.
e.g. "usernameXXXXX" will be permitted to match "username".
Just check one more byte so the trailing null char is also matched.
Signed-off-by: Eric Seppanen <eric@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Seppanen [Wed, 20 Nov 2013 22:19:51 +0000 (14:19 -0800)]
iscsi-target: fix extract_param to handle buffer length corner case
commit
369653e4fb511928511b0ce81f41c812ff1f28b6 upstream.
extract_param() is called with max_length set to the total size of the
output buffer. It's not safe to allow a parameter length equal to the
buffer size as the terminating null would be written one byte past the
end of the output buffer.
Signed-off-by: Eric Seppanen <eric@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Wed, 13 Nov 2013 01:54:56 +0000 (17:54 -0800)]
iscsi-target: Fix mutex_trylock usage in iscsit_increment_maxcmdsn
commit
5e8e6b4b3adebf01a9d97056cbbfd8c44330df99 upstream.
This patch fixes a >= v3.10 regression bug with mutex_trylock() usage
within iscsit_increment_maxcmdsn(), that was originally added to allow
for a special case where ->cmdsn_mutex was already held from the
iscsit_execute_cmd() exception path for ib_isert.
When !mutex_trylock() was occuring under contention during normal RX/TX
process context codepaths, the bug was manifesting itself as the following
protocol error:
Received CmdSN: 0x000fcbb7 is greater than MaxCmdSN: 0x000fcbb6, protocol error.
Received CmdSN: 0x000fcbb8 is greater than MaxCmdSN: 0x000fcbb6, protocol error.
This patch simply avoids the direct ib_isert callback in lio_queue_status()
for the special iscsi_execute_cmd() exception cases, that allows the problematic
mutex_trylock() usage in iscsit_increment_maxcmdsn() to go away.
Reported-by: Moussa Ba <moussaba@micron.com>
Tested-by: Moussa Ba <moussaba@micron.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Samir Benmendil [Sun, 17 Nov 2013 22:56:17 +0000 (23:56 +0100)]
ahci: add Marvell 9230 to the AHCI PCI device list
commit
6d5278a68a75891db1df5ae1ecf83d288fc58c65 upstream.
Tested with a DAWICONTROL DC-624e on 3.10.10
Signed-off-by: Samir Benmendil <samir.benmendil@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Levente Kurusa <levex@linux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xiangliang yu [Sun, 27 Oct 2013 12:03:04 +0000 (08:03 -0400)]
ahci: disabled FBS prior to issuing software reset
commit
89dafa20f3daab5b3e0c13d0068a28e8e64e2102 upstream.
Tested with Marvell 88se9125, attached with one port mulitplier(5 ports)
and one disk, we will get following boot log messages if using current
code:
ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
ata8.15: Port Multiplier 1.2, 0x1b4b:0x9715 r160, 5 ports, feat 0x1/0x1f
ahci 0000:03:00.0: FBS is enabled
ata8.00: hard resetting link
ata8.00: SATA link down (SStatus 0 SControl 330)
ata8.01: hard resetting link
ata8.01: SATA link down (SStatus 0 SControl 330)
ata8.02: hard resetting link
ata8.02: SATA link down (SStatus 0 SControl 330)
ata8.03: hard resetting link
ata8.03: SATA link up 6.0 Gbps (SStatus 133 SControl 133)
ata8.04: hard resetting link
ata8.04: failed to resume link (SControl 133)
ata8.04: failed to read SCR 0 (Emask=0x40)
ata8.04: failed to read SCR 0 (Emask=0x40)
ata8.04: failed to read SCR 1 (Emask=0x40)
ata8.04: failed to read SCR 0 (Emask=0x40)
ata8.03: native sectors (2) is smaller than sectors (
976773168)
ata8.03: ATA-8: ST3500413AS, JC4B, max UDMA/133
ata8.03:
976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata8.03: configured for UDMA/133
ata8.04: failed to IDENTIFY (I/O error, err_mask=0x100)
ata8.15: hard resetting link
ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
ata8.15: PMP revalidation failed (errno=-19)
ata8.15: hard resetting link
ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
ata8.15: PMP revalidation failed (errno=-19)
ata8.15: limiting SATA link speed to 3.0 Gbps
ata8.15: hard resetting link
ata8.15: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
ata8.15: PMP revalidation failed (errno=-19)
ata8.15: failed to recover PMP after 5 tries, giving up
ata8.15: Port Multiplier detaching
ata8.03: disabled
ata8.00: disabled
ata8: EH complete
The reason is that current detection code doesn't follow AHCI spec:
First,the port multiplier detection process look like this:
ahci_hardreset(link, class, deadline)
if (class == ATA_DEV_PMP) {
sata_pmp_attach(dev) /* will enable FBS */
sata_pmp_init_links(ap, nr_ports);
ata_for_each_link(link, ap, EDGE) {
sata_std_hardreset(link, class, deadline);
if (link_is_online) /* do soft reset */
ahci_softreset(link, class, deadline);
}
}
But, according to chapter 9.3.9 in AHCI spec: Prior to issuing software
reset, software shall clear PxCMD.ST to '0' and then clear PxFBS.EN to
'0'.
The patch test ok with kernel 3.11.1.
tj: Patch white space contaminated, applied manually with trivial
updates.
Signed-off-by: Xiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Ralston [Mon, 4 Nov 2013 17:24:58 +0000 (09:24 -0800)]
ahci: Add Device IDs for Intel Wildcat Point-LP
commit
9f961a5f6efc87a79571d7166257b36af28ffcfe upstream.
This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH.
Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Tue, 12 Nov 2013 23:11:47 +0000 (15:11 -0800)]
ipc, msg: fix message length check for negative values
commit
4e9b45a19241354daec281d7a785739829b52359 upstream.
On 64 bit systems the test for negative message sizes is bogus as the
size, which may be positive when evaluated as a long, will get truncated
to an int when passed to load_msg(). So a long might very well contain a
positive value but when truncated to an int it would become negative.
That in combination with a small negative value of msg_ctlmax (which will
be promoted to an unsigned type for the comparison against msgsz, making
it a big positive value and therefore make it pass the check) will lead to
two problems: 1/ The kmalloc() call in alloc_msg() will allocate a too
small buffer as the addition of alen is effectively a subtraction. 2/ The
copy_from_user() call in load_msg() will first overflow the buffer with
userland data and then, when the userland access generates an access
violation, the fixup handler copy_user_handle_tail() will try to fill the
remainder with zeros -- roughly 4GB. That almost instantly results in a
system crash or reset.
,-[ Reproducer (needs to be run as root) ]--
| #include <sys/stat.h>
| #include <sys/msg.h>
| #include <unistd.h>
| #include <fcntl.h>
|
| int main(void) {
| long msg = 1;
| int fd;
|
| fd = open("/proc/sys/kernel/msgmax", O_WRONLY);
| write(fd, "-1", 2);
| close(fd);
|
| msgsnd(0, &msg, 0xfffffff0, IPC_NOWAIT);
|
| return 0;
| }
'---
Fix the issue by preventing msgsz from getting truncated by consistently
using size_t for the message length. This way the size checks in
do_msgsnd() could still be passed with a negative value for msg_ctlmax but
we would fail on the buffer allocation in that case and error out.
Also change the type of m_ts from int to size_t to avoid similar nastiness
in other code paths -- it is used in similar constructs, i.e. signed vs.
unsigned checks. It should never become negative under normal
circumstances, though.
Setting msg_ctlmax to a negative value is an odd configuration and should
be prevented. As that might break existing userland, it will be handled
in a separate commit so it could easily be reverted and reworked without
reintroducing the above described bug.
Hardening mechanisms for user copy operations would have catched that bug
early -- e.g. checking slab object sizes on user copy operations as the
usercopy feature of the PaX patch does. Or, for that matter, detect the
long vs. int sign change due to truncation, as the size overflow plugin
of the very same patch does.
[akpm@linux-foundation.org: fix i386 min() warnings]
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Pax Team <pageexec@freemail.hu>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Mon, 11 Nov 2013 04:11:16 +0000 (22:11 -0600)]
rtlwifi: rtl8192cu: Fix more pointer arithmetic errors
commit
eafbdde9c5629bea58df07275c5917eb42afbbe7 upstream.
This driver uses a number of macros to get and set various fields in the
RX and TX descriptors. To work correctly, a u8 pointer to the descriptor
must be used; however, in some cases a descriptor structure pointer is used
instead. In addition, a duplicated statement is removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Pena [Sat, 19 Oct 2013 00:52:40 +0000 (21:52 -0300)]
rtlwifi: rtl8192se: Fix wrong assignment
commit
3aef7dde8dcf09e0124f0a2665845a507331972b upstream.
There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.
Signed-off-by: Felipe Pena <felipensp@gmail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Cave-Ayland [Sat, 2 Nov 2013 19:28:35 +0000 (14:28 -0500)]
rtlwifi: Fix endian error in extracting packet type
commit
0c5d63f0ab6728f05ddefa25aff55e31297f95e6 upstream.
All of the rtlwifi drivers have an error in the routine that tests if
the data is "special". If it is, the subsequant transmission will be
at the lowest rate to enhance reliability. The 16-bit quantity is
big-endian, but was being extracted in native CPU mode. One of the
effects of this bug is to inhibit association under some conditions
as the TX rate is too high.
Based on suggestions by Joe Perches, the entire routine is rewritten.
One of the local headers contained duplicates of some of the ETH_P_XXX
definitions. These are deleted.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Wed, 25 Sep 2013 17:57:48 +0000 (12:57 -0500)]
rtlwifi: rtl8188ee: Fix smatch warning in rtl8188ee/hw.c
commit
dab3df5e88b979f8d09860f873ccfaa7a55758d2 upstream.
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code.
This info message is the result of a real error due to a missing break statement
in a "while (1)" loop.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ryan Mallon [Tue, 12 Nov 2013 23:08:51 +0000 (15:08 -0800)]
vsprintf: check real user/group id for %pK
commit
312b4e226951f707e120b95b118cbc14f3d162b2 upstream.
Some setuid binaries will allow reading of files which have read
permission by the real user id. This is problematic with files which
use %pK because the file access permission is checked at open() time,
but the kptr_restrict setting is checked at read() time. If a setuid
binary opens a %pK file as an unprivileged user, and then elevates
permissions before reading the file, then kernel pointer values may be
leaked.
This happens for example with the setuid pppd application on Ubuntu 12.04:
$ head -1 /proc/kallsyms
00000000 T startup_32
$ pppd file /proc/kallsyms
pppd: In file /proc/kallsyms: unrecognized option '
c1000000'
This will only leak the pointer value from the first line, but other
setuid binaries may leak more information.
Fix this by adding a check that in addition to the current process having
CAP_SYSLOG, that effective user and group ids are equal to the real ids.
If a setuid binary reads the contents of a file which uses %pK then the
pointer values will be printed as NULL if the real user is unprivileged.
Update the sysctl documentation to reflect the changes, and also correct
the documentation to state the kptr_restrict=0 is the default.
This is a only temporary solution to the issue. The correct solution is
to do the permission check at open() time on files, and to replace %pK
with a function which checks the open() time permission. %pK uses in
printk should be removed since no sane permission check can be done, and
instead protected by using dmesg_restrict.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Joe Perches <joe@perches.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shan Hai [Mon, 28 Oct 2013 08:08:01 +0000 (16:08 +0800)]
drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH drive
commit
0523f037f65dba10191b0fa9c51266f90ba64630 upstream.
The "Slimtype DVD A DS8A9SH" drive locks up with following backtrace when
the max sector is smaller than 65535 bytes, fix it by adding a quirk to set
the max sector to 65535 bytes.
INFO: task flush-11:0:663 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
flush-11:0 D
00000000ffff5ceb 0 663 2 0x00000000
ffff88026d3b1710 0000000000000046 0000000000000001 0000000000000000
ffff88026f2530c0 ffff88026d365860 ffff88026d3b16e0 ffffffff812ffd52
ffff88026d4fd3d0 0000000100000001 ffff88026d3b16f0 ffff88026d3b1fd8
Call Trace:
[<
ffffffff812ffd52>] ? cfq_may_queue+0x52/0xf0
[<
ffffffff81604338>] schedule+0x18/0x30
[<
ffffffff81604392>] io_schedule+0x42/0x60
[<
ffffffff812f22bb>] get_request_wait+0xeb/0x1f0
[<
ffffffff81065660>] ? autoremove_wake_function+0x0/0x40
[<
ffffffff812eb382>] ? elv_merge+0x42/0x210
[<
ffffffff812f26ae>] __make_request+0x8e/0x4e0
[<
ffffffff812f068e>] generic_make_request+0x21e/0x5e0
[<
ffffffff812f0aad>] submit_bio+0x5d/0xd0
[<
ffffffff81141422>] submit_bh+0xf2/0x130
[<
ffffffff8114474c>] __block_write_full_page+0x1dc/0x3a0
[<
ffffffff81143f60>] ? end_buffer_async_write+0x0/0x120
[<
ffffffff811474e0>] ? blkdev_get_block+0x0/0x70
[<
ffffffff811474e0>] ? blkdev_get_block+0x0/0x70
[<
ffffffff81143f60>] ? end_buffer_async_write+0x0/0x120
[<
ffffffff811449ee>] block_write_full_page_endio+0xde/0x100
[<
ffffffff81144a20>] block_write_full_page+0x10/0x20
[<
ffffffff81148703>] blkdev_writepage+0x13/0x20
[<
ffffffff810d7525>] __writepage+0x15/0x40
[<
ffffffff810d7c0f>] write_cache_pages+0x1cf/0x3e0
[<
ffffffff810d7510>] ? __writepage+0x0/0x40
[<
ffffffff810d7e42>] generic_writepages+0x22/0x30
[<
ffffffff810d7e6f>] do_writepages+0x1f/0x40
[<
ffffffff8113ae67>] writeback_single_inode+0xe7/0x3b0
[<
ffffffff8113b574>] writeback_sb_inodes+0x184/0x280
[<
ffffffff8113bedb>] writeback_inodes_wb+0x6b/0x1a0
[<
ffffffff8113c24b>] wb_writeback+0x23b/0x2a0
[<
ffffffff8113c42d>] wb_do_writeback+0x17d/0x190
[<
ffffffff8113c48b>] bdi_writeback_task+0x4b/0xe0
[<
ffffffff810e82a0>] ? bdi_start_fn+0x0/0x100
[<
ffffffff810e8321>] bdi_start_fn+0x81/0x100
[<
ffffffff810e82a0>] ? bdi_start_fn+0x0/0x100
[<
ffffffff8106522e>] kthread+0x8e/0xa0
[<
ffffffff81039274>] ? finish_task_switch+0x54/0xc0
[<
ffffffff81003334>] kernel_thread_helper+0x4/0x10
[<
ffffffff810651a0>] ? kthread+0x0/0xa0
[<
ffffffff81003330>] ? kernel_thread_helper+0x0/0x10
The above trace was triggered by
"dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768"
Signed-off-by: Shan Hai <shan.hai@windriver.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gwendal Grignou [Fri, 25 Oct 2013 23:28:57 +0000 (16:28 -0700)]
libata: Fix display of sata speed
commit
3e85c3ecbc520751324a191d23bb94873ed01b10 upstream.
6.0 Gbps link speed was not decoded properly:
speed was reported at 3.0 Gbps only.
Tested: On a machine where libata reports 6.0 Gbps in
/var/log/messages:
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Before:
cat /sys/class/ata_link/link1/sata_spd
3.0 Gbps
After:
cat /sys/class/ata_link/link1/sata_spd
6.0 Gbps
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 7 Nov 2013 07:56:51 +0000 (10:56 +0300)]
gpio: rcar: NULL dereference on error in probe()
commit
0c8aab8e65e450f2bfea494c1b6a86ded653f88c upstream.
It's not obvious from the label name but "err1" tries to release
"p->irq_domain" which leads to a NULL dereference.
Fixes:
119f5e448d32 ('gpio: Renesas R-Car GPIO driver V3')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 7 Nov 2013 07:51:34 +0000 (10:51 +0300)]
gpio: msm: make msm_gpio.summary_irq signed for error handling
commit
bfea603bc54c0a736d45bc60b188a8cdae9aaaa3 upstream.
There is a bug in msm_gpio_probe() where we do:
msm_gpio.summary_irq = platform_get_irq(pdev, 0);
if (msm_gpio.summary_irq < 0) {
The problem is that "msm_gpio.summary_irq" is unsigned so the error
handling doesn't work. I've fixed it by making it signed.
Fixes:
43f68444bce7 ('gpio: msm: Add device tree and irqdomain support for gpio-msm-v2')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 7 Nov 2013 07:50:19 +0000 (10:50 +0300)]
gpio: mvebu: make mvchip->irqbase signed for error handling
commit
d535922691fc026479fcc03e78ac3d931a54e75a upstream.
There is a bug in mvebu_gpio_probe() where we do:
mvchip->irqbase = irq_alloc_descs(-1, 0, ngpios, -1);
if (mvchip->irqbase < 0) {
The problem is that mvchip->irqbase is unsigned so the error handling
doesn't work. I have changed it to be a regular int.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Lindgren [Mon, 18 Nov 2013 23:22:49 +0000 (15:22 -0800)]
gpio: twl4030: Fix regression for twl gpio output
commit
0b2aa8bed3e13892fcac77e4f50ec6e80125469d upstream.
Commit
c111feabe2e2 (gpio: twl4030: Cache the direction and output
states in private data) improved things in general, but caused a
regression for setting the GPIO output direction.
The change reorganized twl_direction_out() and twl_set() and swapped
the function names around in the process. While doing that, a bug got
introduced that's not obvious while reading the patch as it appears
as no change to the code.
The bug is we now call function twl4030_set_gpio_dataout() twice in
both twl_direction_out() and twl_set(). Instead, we should first
call twl_direction_out() in twl_direction_out() followed by
twl4030_set_gpio_dataout() in twl_set().
This regression probably has gone unnoticed for a long time as the
bootloader may have set the GPIO direction properly in many cases.
This fixes at least the LCD panel not turning on omap3 LDP for
example.
Cc: linux-gpio@vger.kernel.org
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Mon, 21 Oct 2013 09:33:35 +0000 (11:33 +0200)]
cfg80211: fix scheduled scan pointer access
commit
79845c662eeb95c9a180b9bd0d3ad848ee65b94c upstream.
Since rdev->sched_scan_req is dereferenced outside the
lock protecting it, this might be done at the wrong
time, causing crashes. Move the dereference to where
it should be - inside the RTNL locked section.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Warren [Tue, 26 Nov 2013 03:35:42 +0000 (20:35 -0700)]
ARM: bcm2835: add missing #xxx-cells to I2C nodes
commit
a31ab44ef5d07c6707df4a9ad2c8affd2d62ff4b upstream.
The I2C controller node needs #address-cells and #size-cells properties,
but these are currently missing. Add them. This allows child nodes to be
parsed correctly.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Doug Anderson [Wed, 23 Oct 2013 13:11:01 +0000 (06:11 -0700)]
ARM: dts: Add max77686 RTC interrupt to cros5250-common
commit
c61248afa8190ae3f47ee67f46e3c9b584a73d31 upstream.
Without the interrupt you'll get problems if you enable
CONFIG_RTC_DRV_MAX77686. Setup the interrupt properly in the device
tree.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ionut Nicu [Fri, 11 Oct 2013 12:17:10 +0000 (14:17 +0200)]
i2c: mux: gpio: use gpio_set_value_cansleep()
commit
250ad590d6f12d93f4d85be305b0a598d609232e upstream.
Some gpio chips may have get/set operations that
can sleep. gpio_set_value() only works for chips
which do not sleep, for the others we will get a
kernel warning. Using gpio_set_value_cansleep()
will work for both chips that do sleep and those
who don't.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Acked-by: Peter Korsgaard <peter.korsgaard@barco.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ionut Nicu [Fri, 11 Oct 2013 10:09:57 +0000 (12:09 +0200)]
i2c: mux: gpio: use reg value for i2c_add_mux_adapter
commit
8c0ec2500eeb89749341884a972860d7f9e56f9c upstream.
The i2c-mux driver requires that the chan_id parameter
passed to the i2c_add_mux_adapter() function is equal
to the reg value for that adapter:
for_each_child_of_node(mux_dev->of_node, child) {
ret = of_property_read_u32(child, "reg", ®);
if (ret)
continue;
if (chan_id == reg) {
priv->adap.dev.of_node = child;
break;
}
}
The i2c-mux-gpio driver uses an internal logical index
for chan_id when calling i2c_add_mux_adapter() instead
of using the reg value.
Because of this, there will problems in selecting the
right adapter when the i2c-mux-gpio's index into
mux->data.values doesn't match the reg value.
An example of such a case:
mux->data.values = { 1, 0 }
For chan_id = 0, i2c-mux will bind the adapter to the
of_node with reg = <0>, but when it will call the
select() callback with chan_id set to 0, the i2c-mux-gpio
will use it as an index into mux->data.values and it will
actually select the bus with reg = <1>.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Acked-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Yongjun [Mon, 11 Nov 2013 14:23:50 +0000 (22:23 +0800)]
i2c: wmt: add missing clk_disable_unprepare() on error
commit
2dc9688a106886db7191d30f30ffd61fde827efd upstream.
Add the missing clk_disable_unprepare() before return
from wmt_i2c_reset_hardware() in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Mon, 14 Oct 2013 19:04:13 +0000 (21:04 +0200)]
parisc: break out SOCK_NONBLOCK define to own asm header file
commit
38c7937379276a5ea8c54481205003af2f2b5694 upstream.
Break SOCK_NONBLOCK out to its own asm-file as other arches do. This
fixes build errors with auditd and probably other packages.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilija Hadzic [Tue, 12 Nov 2013 23:11:45 +0000 (15:11 -0800)]
devpts: plug the memory leak in kill_sb
commit
66da0e1f9034140ae2f571ef96e254a25083906c upstream.
When devpts is unmounted, there may be a no-longer-used IDR tree hanging
off the superblock we are about to kill. This needs to be cleaned up
before destroying the SB.
The leak is usually not a big deal because unmounting devpts is typically
done when shutting down the whole machine. However, shutting down an LXC
container instead of a physical machine exposes the problem (the garbage
is detectable with kmemleak).
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Tue, 12 Nov 2013 23:11:19 +0000 (15:11 -0800)]
rbtree: fix rbtree_postorder_for_each_entry_safe() iterator
commit
1310a5a99d900ee30b9f171146406bde0c6c2bd4 upstream.
The iterator rbtree_postorder_for_each_entry_safe() relies on pointer
underflow behavior when testing for loop termination. In particular it
expects that
&rb_entry(NULL, type, field)->field
is NULL. But the result of this expression is not defined by a C standard
and some gcc versions (e.g. 4.3.4) assume the above expression can never
be equal to NULL. The net result is an oops because the iteration is not
properly terminated.
Fix the problem by modifying the iterator to avoid pointer underflows.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Theodore Ts'o <tytso@mit.edu>
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>
Nishanth Menon [Fri, 11 Oct 2013 10:04:12 +0000 (05:04 -0500)]
regulator: ti-abb: Fix operator precedence typo
commit
9a633a2bced158c57b73cf4d8e87be60473de1d2 upstream.
commit
40b1936e (regulator: Introduce TI Adaptive Body Bias(ABB) on-chip
LDO driver) missed a pair of brackets which cause the wrong vset data to be
picked up from efuse, resulting in bad VBB voltage values.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roel Kluin [Sun, 13 Oct 2013 23:27:27 +0000 (01:27 +0200)]
pinctrl: dove: unset twsi option3 for gconfig as well
commit
6d0a4ed2b90a12e1403d3e7d9d8c2cc7fdc301b5 upstream.
This fixes a typo which left twsi config3 option enabled.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KOSAKI Motohiro [Mon, 14 Oct 2013 21:33:16 +0000 (17:33 -0400)]
alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist
commit
98d6f4dd84a134d942827584a3c5f67ffd8ec35f upstream.
Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)
Because of, commit
1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
RTC device is present) intruduced to return ENOTSUPP when
clock_get{time,res} can't find a RTC device. However this is incorrect.
First, ENOTSUPP isn't exported to userland (ENOTSUP or EOPNOTSUP are the
closest userland equivlents).
Second, Posix and Linux man pages agree that clock_gettime and
clock_getres should return EINVAL if clk_id argument is invalid.
While the arugment that the clockid is valid, but just not supported
on this hardware could be made, this is just a technicality that
doesn't help userspace applicaitons, and only complicates error
handling.
Thus, this patch changes the code to use EINVAL.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Reported-by: Vit Ondruch <v.ondruch@tiscali.cz>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
[jstultz: Tweaks to commit message to include full rational]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don Zickus [Wed, 13 Nov 2013 18:32:06 +0000 (15:32 -0300)]
perf tools: Synthesize anon MMAP records again
commit
9d4ecc8893832337daf241236841db966fa53489 upstream.
When introducing the PERF_RECORD_MMAP2 in:
5c5e854bc760 perf tools: Add attr->mmap2 support
A check for the number of entries parsed by sscanf was introduced that
assumed all of the 8 fields needed to be correctly parsed so that
particular /proc/pid/maps line would be considered synthesizable.
That broke anon records synthesizing, as it doesn't have the 'execname'
field.
Fix it by keeping the sscanf return check, changing it to not require
that the 'execname' variable be parsed, so that the preexisting logic
can kick in and set it to '//anon'.
This should get things like JIT profiling working again.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Cc: Bill Gray <bgray@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
Cc: Richard Fowles <rfowles@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-bo4akalno7579shpz29u867j@git.kernel.org
[ commit log message is mine, dzickus reported the problem with a patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Hudson-Doyle [Thu, 31 Oct 2013 23:47:45 +0000 (16:47 -0700)]
perf tools: Remove cast of non-variadic function to variadic
commit
53805eca3d89b095062c11a6798689bb0af09216 upstream.
The
4fb71074a570 (perf ui/hist: Consolidate hpp helpers) cset introduced
a cast of percent_color_snprintf to a function pointer type with
varargs. Change percent_color_snprintf to be variadic and remove the
cast.
The symptom of this was all percentages being reported as 0.00% in perf
report --stdio output on the armhf arch.
Signed-off-by: Michael Hudson-Doyle <michael.hudson@linaro.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Jean Pihet <jean.pihet@linaro.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Link: http://lkml.kernel.org/r/87zjppvw7y.fsf@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Pfaff [Fri, 11 Oct 2013 11:00:40 +0000 (13:00 +0200)]
genirq: Set the irq thread policy without checking CAP_SYS_NICE
commit
bbfe65c219c638e19f1da5adab1005b2d68ca810 upstream.
In commit
ee23871389 ("genirq: Set irq thread to RT priority on
creation") we moved the assigment of the thread's priority from the
thread's function into __setup_irq(). That function may run in user
context for instance if the user opens an UART node and then driver
calls requests in the ->open() callback. That user may not have
CAP_SYS_NICE and so the irq thread won't run with the SCHED_OTHER
policy.
This patch uses sched_setscheduler_nocheck() so we omit the CAP_SYS_NICE
check which is otherwise required for the SCHED_OTHER policy.
[bigeasy: Rewrite the changelog]
Signed-off-by: Thomas Pfaff <tpfaff@pcs.com>
Cc: Ivo Sieben <meltedpianoman@gmail.com>
Link: http://lkml.kernel.org/r/1381489240-29626-1-git-send-email-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Charles Keepax [Tue, 19 Nov 2013 10:51:29 +0000 (10:51 +0000)]
ASoC: wm5110: Add post SYSCLK register patch for rev D chip
commit
f69f86b1ba6493126a7f093a65a8952bcb183de2 upstream.
Certain registers require patching after the SYSCLK has been brought up
add support for this into the CODEC driver.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Fitzgerald [Wed, 20 Nov 2013 14:37:09 +0000 (14:37 +0000)]
ASoC: arizona: Set FLL to free-run before disabling
commit
3e68ce1bc72e5d6615677ec5a8b0a9bcb6c7a490 upstream.
The FLL must be placed into free-run mode before disabling
to allow it to entirely shut down.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oskar Schirmer [Tue, 12 Nov 2013 15:46:38 +0000 (15:46 +0000)]
ASoC: fsl: imx-pcm-fiq: omit fiq counter to avoid harm in unbalanced situations
commit
fc7dc61d9a87011aaf8a6eb3144ebf9552adf5d2 upstream.
Unbalanced calls to snd_imx_pcm_trigger() may result in endless
FIQ activity and thus provoke eternal sound. While on the first glance,
the switch statement looks pretty symmetric, the SUSPEND/RESUME
pair is not: the suspend case comes along snd_pcm_suspend_all(),
which for fsl/imx-pcm-fiq is called only at snd_soc_suspend(),
but the resume case originates straight from the SNDRV_PCM_IOCTL_RESUME.
This way userland may provoke an unbalanced resume, which might cause
the fiq_enable counter to increase and never return to zero again,
so eventually imx_pcm_fiq is never disabled.
Simply removing the fiq_enable will solve the problem, as long as
one never goes play and capture game simultaneously, but beware
trying both at once, the early TRIGGER_STOP will cut off the other
activity prematurely. So now playing and capturing is scrutinized
separately, instead of by counting.
Signed-off-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 13 Nov 2013 16:15:00 +0000 (17:15 +0100)]
ASoC: blackfin: Fix missing break
commit
afed4dbe3a043dbd833a53b6b4951e155708afd2 upstream.
Fixes:
4b2ffc205cb9 ('ASoC: Blackfin I2S: add 8-bit sample support')
Reported-by: David Binderman
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolin Chen [Thu, 14 Nov 2013 03:59:21 +0000 (11:59 +0800)]
ASoC: wm8962: Turn on regcache_cache_only before disabling regulator
commit
50bfcf2df2fadf77e143d6099150e6fa7ef4d78c upstream.
It's safer to turn on regcache_cache_only before disabling regulator since
the driver will turn off the regcache_cache_only after enabling regulator.
If we remain cache_only false, some command like 'amixer cset' would get
failure if being run before wm8962_resume().
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Austin [Thu, 14 Nov 2013 17:46:12 +0000 (11:46 -0600)]
ASoC: cs42l52: Correct MIC CTL mask
commit
3d800c6d75b8c92fa928a0bcaf95cd7ac5fd1ce5 upstream.
The mask for CS42L52_MIC_CTL_TYPE_MASK was wrong keeping the mic config
from being set correctly.
Signed-off-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phil Edworthy [Fri, 1 Nov 2013 06:06:17 +0000 (23:06 -0700)]
ASoC: ak4642: prevent un-necessary changes to SG_SL1
commit
7b5bfb82882b9b1c8423ce0ed6852ca3762d967a upstream.
If you record the sound during playback,
the playback sound becomes silent.
Modify so that the codec driver does not clear
SG_SL1::DACL bit which is controlled under widget
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nariman Poushin [Mon, 4 Nov 2013 12:03:44 +0000 (12:03 +0000)]
ASoC: wm_adsp: Interpret ADSP memory region lengths as 32 bit words
commit
c01422a4a184a183b03fb3046af88d61828f6d56 upstream.
Pad the ADSP word (3 bytes) to 4 bytes in the kernel and calculate
lengths based on padded ADSP words instead of treating them as bytes
Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 12 Nov 2013 23:09:38 +0000 (15:09 -0800)]
backlight: atmel-pwm-bl: fix reported brightness
commit
185d91442550110db67a7dc794a32efcea455a36 upstream.
The driver supports 16-bit brightness values, but the value returned
from get_brightness was truncated to eight bits.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 12 Nov 2013 23:09:39 +0000 (15:09 -0800)]
backlight: atmel-pwm-bl: fix gpio polarity in remove
commit
ad5066d4c2b1d696749f8d7816357c23b648c4d3 upstream.
Make sure to honour gpio polarity also at remove so that the backlight is
actually disabled on boards with active-low enable pin.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Sun, 17 Nov 2013 19:32:15 +0000 (13:32 -0600)]
staging: r8188eu: Fix AP mode
commit
9ecfc0f45033584ec58617cf6ec37f75833d97e8 upstream.
Two code lines were accidentally deleted. Restore them.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Thu, 7 Nov 2013 21:49:04 +0000 (21:49 +0000)]
staging: vt6656: [BUG] Fix for TX USB resets from vendors driver.
commit
9df682927c2e3a92f43803d6b52095992e3b2ab8 upstream.
This fixes resets on heavy TX data traffic.
Vendor driver
VT6656_Linux_src_v1.21.03_x86_11.04.zip
http://www.viaembedded.com/servlet/downloadSvl?id=1890&download_file_id=14704
This is GPL-licensed code.
original code
BBbVT3184Init
...
//2007-0725, RobertChang add, Enable Squelch detect reset option(SQ_RST_Opt), USB (register4, bit1)
CONTROLnsRequestIn(pDevice,
MESSAGE_TYPE_READ,
(WORD)0x600+4, // USB's Reg4's bit1
MESSAGE_REQUEST_MEM,
1,
(PBYTE) &byData);
byData = byData|2 ;
CONTROLnsRequestOut(pDevice,
MESSAGE_TYPE_WRITE,
(WORD)0x600+4, // USB's Reg4's bit1
MESSAGE_REQUEST_MEM,
1,
(PBYTE) &byData);
return TRUE;//ntStatus;
....
A back port patch is needed for kernels less than 3.10.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rashika Kheria [Sun, 10 Nov 2013 16:43:53 +0000 (22:13 +0530)]
Staging: zram: Fix memory leak by refcount mismatch
commit
1b672224d128ec2570eb37572ff803cfe452b4f7 upstream.
As suggested by Minchan Kim and Jerome Marchand "The code in reset_store
get the block device (bdget_disk()) but it does not put it (bdput()) when
it's done using it. The usage count is therefore incremented but never
decremented."
This patch also puts bdput() for all error cases.
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Olav Haugan [Fri, 22 Nov 2013 17:30:41 +0000 (09:30 -0800)]
staging: zsmalloc: Ensure handle is never 0 on success
commit
67296874eb1cc80317bf2a8fba22b494e21eb29b upstream.
zsmalloc encodes a handle using the pfn and an object
index. On hardware platforms with physical memory starting
at 0x0 the pfn can be 0. This causes the encoded handle to be
0 and is incorrectly interpreted as an allocation failure.
This issue affects all current and future SoCs with physical
memory starting at 0x0. All MSM8974 SoCs which includes
Google Nexus 5 devices are affected.
To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peng Tao [Thu, 21 Nov 2013 14:42:45 +0000 (22:42 +0800)]
staging/lustre/ptlrpc: fix ptlrpc_stop_pinger logic
commit
b39f15c972c462903208531b82f9b34ba8ef3ec0 upstream.
It was introduced due to a patch hunk when porting
commit
20802057 (staging/lustre/ptlrpc: race in pinger).
Cc: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 27 Nov 2013 17:32:49 +0000 (09:32 -0800)]
Staging: tidspbridge: disable driver
commit
930ba4a374b96560ef9fde2145cdc454a164ddcc upstream.
There seems to be no active maintainer for the driver, and there is an
unfixed security bug, so disable the driver for now.
Hopefully someone steps up to be the maintainer, and works to get this
out of staging, otherwise it will be deleted soon.
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Omar Ramirez Luna <omar.ramirez@copitl.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Kanigeri, Hari <h-kanigeri2@ti.com>
Cc: Ameya Palande <ameya.palande@nokia.com>
Cc: Guzman Lugo, Fernando <fernando.lugo@ti.com>
Cc: Hebbar, Shivananda <x0hebbar@ti.com>
Cc: Ramos Falcon, Ernesto <ernesto@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Anna, Suman <s-anna@ti.com>
Cc: Gupta, Ramesh <grgupta@ti.com>
Cc: Gomez Castellanos, Ivan <ivan.gomez@ti.com>
Cc: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
Cc: Armando Uribe De Leon <x0095078@ti.com>
Cc: Deepak Chitriki <deepak.chitriki@ti.com>
Cc: Menon, Nishanth <nm@ti.com>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiada Wang [Wed, 30 Oct 2013 11:25:51 +0000 (04:25 -0700)]
ARM: i.MX6q: fix the wrong parent of can_root clock
commit
9b3d423707c3b1f6633be1be7e959623e10c596b upstream.
instead of pll3_usb_otg the parent of can_root clock
should be pll3_60m.
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 16 Oct 2013 09:56:15 +0000 (11:56 +0200)]
ARM: at91: fix hanged boot due to early rtt-interrupt
commit
94c4c79f2f1acca6e69a50bff5a7d9027509c16b upstream.
Make sure the RTT-interrupts are masked at boot by adding a new helper
function to be used at SOC-init.
This fixes hanged boot on all AT91 SOCs with an RTT, for example, if an
RTT-alarm goes off after a non-clean shutdown (e.g. when using RTC
wakeup).
The RTC and RTT-peripherals are powered by backup power (VDDBU) (on all
AT91 SOCs but RM9200) and are not reset on wake-up, user, watchdog or
software reset. This means that their interrupts may be enabled during
early boot if, for example, they where not disabled during a previous
shutdown (e.g. due to a buggy driver or a non-clean shutdown such as a
user reset). Furthermore, an RTC or RTT-alarm may also be active.
The RTC and RTT-interrupts use the shared system-interrupt line, which
is also used by the PIT, and if an interrupt occurs before a handler
(e.g. RTC-driver) has been installed this leads to the system interrupt
being disabled and prevents the system from booting.
Note that when boot hangs due to an early RTC or RTT-interrupt, the only
way to get the system to start again is to remove the backup power (e.g.
battery) or to disable the interrupt manually from the bootloader. In
particular, a user reset is not sufficient.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 16 Oct 2013 09:56:14 +0000 (11:56 +0200)]
ARM: at91: fix hanged boot due to early rtc-interrupt
commit
6de714c21a8ea315fffba6a93bbe537f4c1bf4f0 upstream.
Make sure the RTC-interrupts are masked at boot by adding a new helper
function to be used at SOC-init.
This fixes hanged boot on all AT91 SOCs with an RTC (but RM9200), for
example, after a reset during an RTC-update or if an RTC-alarm goes off
after shutdown (e.g. when using RTC wakeup).
The RTC and RTT-peripherals are powered by backup power (VDDBU) (on all
AT91 SOCs but RM9200) and are not reset on wake-up, user, watchdog or
software reset. This means that their interrupts may be enabled during
early boot if, for example, they where not disabled during a previous
shutdown (e.g. due to a buggy driver or a non-clean shutdown such as a
user reset). Furthermore, an RTC or RTT-alarm may also be active.
The RTC and RTT-interrupts use the shared system-interrupt line, which
is also used by the PIT, and if an interrupt occurs before a handler
(e.g. RTC-driver) has been installed this leads to the system interrupt
being disabled and prevents the system from booting.
Note that when boot hangs due to an early RTC or RTT-interrupt, the only
way to get the system to start again is to remove the backup power (e.g.
battery) or to disable the interrupt manually from the bootloader. In
particular, a user reset is not sufficient.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nishanth Menon [Thu, 14 Nov 2013 17:05:16 +0000 (11:05 -0600)]
ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
commit
3522bf7bfa248b99eafa2f4872190699a808c7d9 upstream.
OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using omap_device_idle/enable as part of
the last stage of suspend activity.
For a device such as i2c who uses autosuspend, it is possible to enter
the suspend path with dev->power.runtime_status = RPM_ACTIVE.
As part of the suspend flow, the generic runtime logic would increment
it's dev->power.disable_depth to 1. This should prevent further
pm_runtime_get_sync from succeeding once the runtime_status has been
set to RPM_SUSPENDED.
Now, as part of the suspend_noirq handler in omap_device, we force the
following: if the device status is !suspended, we force the device
to idle using omap_device_idle (clocks are cut etc..). This ensures
that from a hardware perspective, the device is "suspended". However,
runtime_status is left to be active.
*if* an operation is attempted after this point to
pm_runtime_get_sync, runtime framework depends on runtime_status to
indicate accurately the device status, and since it sees it to be
ACTIVE, it assumes the module is functional and returns a non-error
value. As a result the user will see pm_runtime_get succeed, however a
register access will crash due to the lack of clocks.
To prevent this from happening, we should ensure that runtime_status
exactly indicates the device status. As a result of this change
any further calls to pm_runtime_get* would return -EACCES (since
disable_depth is 1). On resume, we restore the clocks and runtime
status exactly as we suspended with. These operations are not expected
to fail as we update the states after the core runtime framework has
suspended itself and restore before the core runtime framework has
resumed.
Reported-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Austin [Thu, 29 Aug 2013 17:41:11 +0000 (18:41 +0100)]
ARM: integrator_cp: Set LCD{0,1} enable lines when turning on CLCD
commit
30aeadd44deea3f3b0df45b9a70ee0fd5f8d6dc2 upstream.
This turns on the internal integrator LCD display(s). It seems that the code
to do this got lost in refactoring of the CLCD driver.
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Mon, 4 Nov 2013 10:42:29 +0000 (11:42 +0100)]
ARM: 7876/1: clear Thumb-2 IT state on exception handling
commit
e16b31bf47738f4498d7ce632e12d7d2a6a2492a upstream.
The exception handling code fails to clear the IT state, potentially
leading to incorrect execution of the fixup if the size of the IT
block is more than one.
Let fixup_exception do the IT sanitizing if a fixup has been found,
and restore CPSR from the stack when returning from a data abort.
Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Tue, 15 Oct 2013 23:09:02 +0000 (00:09 +0100)]
ARM: sa11x0/assabet: ensure CS2 is configured appropriately
commit
f3964fe1c9d9a887d65faf594669852e4dec46e0 upstream.
The CS2 region contains the Assabet board configuration and status
registers, which are 32-bit. Unfortunately, some boot loaders do not
configure this region correctly, leaving it setup as a 16-bit region.
Fix this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Markus Pargmann [Thu, 17 Oct 2013 07:18:38 +0000 (09:18 +0200)]
ARM: OMAP2+: irq, AM33XX add missing register check
commit
0bebda684857f76548ea48c8886785198701d8d3 upstream.
am33xx has a INTC_PENDING_IRQ3 register that is not checked for pending
interrupts. This patch adds AM33XX to the ifdef of SOCs that have to
check this register.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Wed, 6 Nov 2013 22:38:59 +0000 (23:38 +0100)]
parisc: sticon - unbreak on 64bit kernel
commit
0219132fe7c26574371232b50db085573f6fbd3f upstream.
STI text console (sticon) was broken on 64bit machines with more than
4GB RAM and this lead in some cases to a kernel crash.
Since sticon uses the 32bit STI API it needs to keep pointers to memory
below 4GB. But on a 64bit kernel some memory regions (e.g. the kernel
stack) might be above 4GB which then may crash the kernel in the STI
functions.
Additionally sticon didn't selected the built-in framebuffer fonts by
default. This is now fixed.
On a side-note: Theoretically we could enhance the sticon driver to
use the 64bit STI API. But - beside the fact that some machines don't
provide a 64bit STI ROM - this would just add complexity.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 29 Nov 2013 19:28:26 +0000 (11:28 -0800)]
Linux 3.12.2
Mauro Carvalho Chehab [Tue, 12 Nov 2013 23:06:49 +0000 (15:06 -0800)]
cris: media platform drivers: fix build
commit
72a0c5571351f5184195754d23db3e14495b2080 upstream.
On cris arch, the functions below aren't defined:
drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read':
drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write':
drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup':
drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop':
drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
Yet, they're available, as CONFIG_GENERIC_IOMAP is defined. What happens
is that asm/io.h was not including asm-generic/iomap.h.
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miklos Szeredi [Mon, 23 Sep 2013 12:21:04 +0000 (13:21 +0100)]
GFS2: fix dentry leaks
commit
5ca1db41ecdeb0358b968265fadb755213558a85 upstream.
We need to dput() the result of d_splice_alias(), unless it is passed to
finish_no_open().
Edited by Steven Whitehouse in order to make it apply to the current
GFS2 git tree, and taking account of a prerequisite patch which hasn't
been applied.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miklos Szeredi [Mon, 16 Sep 2013 12:52:00 +0000 (14:52 +0200)]
GFS2: d_splice_alias() can't return error
commit
0d0d110720d7960b77c03c9f2597faaff4b484ae upstream.
unless it was given an IS_ERR(inode), which isn't the case here. So clean
up the unnecessary error handling in gfs2_create_inode().
This paves the way for real fixes (hence the stable Cc).
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Junxiao Bi [Thu, 21 Nov 2013 22:31:56 +0000 (14:31 -0800)]
configfs: fix race between dentry put and lookup
commit
76ae281f6307331aa063288edb6422ae99f435f0 upstream.
A race window in configfs, it starts from one dentry is UNHASHED and end
before configfs_d_iput is called. In this window, if a lookup happen,
since the original dentry was UNHASHED, so a new dentry will be
allocated, and then in configfs_attach_attr(), sd->s_dentry will be
updated to the new dentry. Then in configfs_d_iput(),
BUG_ON(sd->s_dentry != dentry) will be triggered and system panic.
sys_open: sys_close:
... fput
dput
dentry_kill
__d_drop <--- dentry unhashed here,
but sd->dentry still point
to this dentry.
lookup_real
configfs_lookup
configfs_attach_attr---> update sd->s_dentry
to new allocated dentry here.
d_kill
configfs_d_iput <--- BUG_ON(sd->s_dentry != dentry)
triggered here.
To fix it, change configfs_d_iput to not update sd->s_dentry if
sd->s_count > 2, that means there are another dentry is using the sd
beside the one that is going to be put. Use configfs_dirent_lock in
configfs_attach_attr to sync with configfs_d_iput.
With the following steps, you can reproduce the bug.
1. enable ocfs2, this will mount configfs at /sys/kernel/config and
fill configure in it.
2. run the following script.
while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done &
while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done &
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
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>
Martin Schwidefsky [Mon, 28 Oct 2013 11:15:32 +0000 (12:15 +0100)]
s390/vtime: correct idle time calculation
commit
4560e7c3317c7a2b370e36dadd3a3bac2ed70818 upstream.
Use the ACCESS_ONCE macro for both accesses to idle->sequence in the
loops to calculate the idle time. If only one access uses the macro,
the compiler is free to cache the value for the second access which
can cause endless loops.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Schwidefsky [Mon, 28 Oct 2013 10:17:10 +0000 (11:17 +0100)]
s390/time: fix get_tod_clock_ext inline assembly
commit
7ab64a85e1a009046f97413a573e83fd85f7804d upstream.
The get_tod_clock_ext inline assembly does not specify its output
operands correctly. This can cause incorrect code to be generated.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Wed, 16 Oct 2013 10:50:06 +0000 (12:50 +0200)]
usb: musb: core: properly free host / device structs in err path
commit
0d2dd7eaed1dac07b266ca2c662ff4a184a3060f upstream.
The patch fixes two issues in the error path cleanup:
- in MUSB_PORT_MODE_DUAL_ROLE mode, if musb_gadget_setup() fails we
never cleanup the host struct earlier allocated.
- if musb_init_debugfs() or sysfs_create_group() fails, then we never
free the host part initialization, only device part.
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Tue, 15 Oct 2013 16:29:25 +0000 (18:29 +0200)]
usb: musb: dsps: redo the otg timer
commit
0f901c980110cd69b63670096465b35377e73b1c upstream.
According to the comments, we rely on the OTG timer because the core
does not expose some important OTG details. So far this is all I
know. After playing with OTG I stumbled over a problem:
musb is recognized as a B-device without a problem. Whenever a cable is
plugged, the VBUS rises, musb recognizes this as a starting session,
sets the MUSB_DEVCTL_SESSION bit by itself and a RESET interrupt occurs,
the session starts. Good.
After a disconnect, the timer is started and re-starts itself because
it remains in B_IDLE with the BDEVICE set. I didn't figure the the
reason or the need for it. Nothing changes here except for OTG state
from B to A device if the BDEVICE bit disappears. This doesn't make much
sense to me because nothing happens after this. _IF_ we receive an
interrupt before the state change then we may act on wrong condition.
Plugging a B-device (and letting MUSB act as host) doesn't work here.
The reason seems to be that the MUSB tries to start a session, it fails
and then it removes the bit. So we never start as a host.
This patch sets the MUSB_DEVCTL_SESSION bit in the IDLE state so musb
can try to establish a session as host. After the bit is set, musb tries
to start a session and if it fails it clears the bit. Therefore it will
try over and over again until a session either as host or as device is
established.
The readout of the MUSB_DEVCTL register after the removal the
MUSB_DEVCTL_SESSION (in A_WAIT_BCON) has been removed because it did not
contain the BDEVICE bit set (in the second read) leading to A_IDLE. After
plugging a host musb assumed that it is also a host and complained about
a missing reset. However a third read of the register has has the BDEVICE
bit set so it seems that it is not stable.
This mostly what da8xx.c is doing except that we set the timer also
after A_WAIT_BCON so the session bit can be triggered.
Whit this change I was able to keep am335x-evm in OTG mode and plug in
either a HOST or a DEVICE and in a random order and the device was
recognized.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Tue, 15 Oct 2013 16:29:23 +0000 (18:29 +0200)]
usb: musb: dsps: move try_idle to start hook
commit
8b9fcce2d88586b9a120ff3e039d8f42413f0bb0 upstream.
The timer is initialized right after musb is probed. There is actually
no need to have this timer running because _nothing_ will happen until
we have the gadget loaded. Also we need this timer only if we run in OTG
mode _and_ we need it also after the gadget has been replaced with
another one.
I've been looking at am35x.c, da8xx.c, omap2430.c, tusb6010.c. da8xx
seem to have the same problem as dsps and doing mostly the same thing.
tusb6010 seem to do something different and do some actual "idle / power
saving" work so I am not too comfortable to remove
musb_platform_try_idle() from musb_gadget_setup().
Therefore this patch does not start the timer if there is no gadget
active (which is at musb_gadget_setup() at time). In order to have the
timer active after the gadget is loaded it will be triggered from
dsps_musb_enable().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Tue, 15 Oct 2013 16:29:22 +0000 (18:29 +0200)]
usb: musb: call musb_start() only once in OTG mode
commit
ae44df2e21b50f9fff28ac75c57e399c04df812c upstream.
In commit 001dd84 ("usb: musb: start musb on the udc side, too") it was
ensured that the state engine is started also in OTG mode after a
removal / insertion of the gadget.
Unfortunately this change also introduced a bug: If the device is
configured as OTG and it connected with a remote host _without_ loading
a gadget then we bug() later (because musb->otg->gadget is not
initialized).
Initially I assumed it might be nice to have the host part of musb in
OTG mode working without having a gadget loaded. This bug and fact that
it wasn't working like this before the host/gadget split made me realize
that this was a silly idea.
This patch now introduces back the old behavior where in OTG mode the
host mode is only working after the gadget has been loaded.
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Thu, 10 Oct 2013 16:26:59 +0000 (18:26 +0200)]
usb: musb: cancel work on removal
commit
c5340bd14336b902604ab95212a8877de109d9ae upstream.
So I captured this:
|WARNING: CPU: 0 PID: 2078 at /home/bigeasy/work/new/TI/linux/lib/debugobjects.c:260 debug_print_object+0x94/0xc4()
|ODEBUG: free active (active state 0) object type: work_struct hint: musb_irq_work+0x0/0x38 [musb_hdrc]
|CPU: 0 PID: 2078 Comm: rmmod Not tainted 3.12.0-rc4+ #338
|[<
c0014d38>] (unwind_backtrace+0x0/0xf4) from [<
c001249c>] (show_stack+0x14/0x1c)
|[<
c001249c>] (show_stack+0x14/0x1c) from [<
c0037720>] (warn_slowpath_common+0x64/0x84)
|[<
c0037720>] (warn_slowpath_common+0x64/0x84) from [<
c00377d4>] (warn_slowpath_fmt+0x30/0x40)
|[<
c00377d4>] (warn_slowpath_fmt+0x30/0x40) from [<
c022ae90>] (debug_print_object+0x94/0xc4)
|[<
c022ae90>] (debug_print_object+0x94/0xc4) from [<
c022b7e0>] (debug_check_no_obj_freed+0x1c0/0x228)
|[<
c022b7e0>] (debug_check_no_obj_freed+0x1c0/0x228) from [<
c00f1f38>] (kfree+0xf8/0x228)
|[<
c00f1f38>] (kfree+0xf8/0x228) from [<
c02921c4>] (release_nodes+0x1a8/0x248)
|[<
c02921c4>] (release_nodes+0x1a8/0x248) from [<
c028f70c>] (__device_release_driver+0x98/0xf0)
|[<
c028f70c>] (__device_release_driver+0x98/0xf0) from [<
c028f840>] (device_release_driver+0x24/0x34)
|[<
c028f840>] (device_release_driver+0x24/0x34) from [<
c028ebe8>] (bus_remove_device+0x148/0x15c)
|[<
c028ebe8>] (bus_remove_device+0x148/0x15c) from [<
c028d120>] (device_del+0x104/0x1c0)
|[<
c028d120>] (device_del+0x104/0x1c0) from [<
c02911e4>] (platform_device_del+0x18/0xac)
|[<
c02911e4>] (platform_device_del+0x18/0xac) from [<
c029179c>] (platform_device_unregister+0xc/0x18)
|[<
c029179c>] (platform_device_unregister+0xc/0x18) from [<
bf1902fc>] (dsps_remove+0x20/0x4c [musb_dsps])
|[<
bf1902fc>] (dsps_remove+0x20/0x4c [musb_dsps]) from [<
c0290d7c>] (platform_drv_remove+0x1c/0x24)
|[<
c0290d7c>] (platform_drv_remove+0x1c/0x24) from [<
c028f704>] (__device_release_driver+0x90/0xf0)
|[<
c028f704>] (__device_release_driver+0x90/0xf0) from [<
c028f818>] (driver_detach+0xb4/0xb8)
|[<
c028f818>] (driver_detach+0xb4/0xb8) from [<
c028e6e8>] (bus_remove_driver+0x98/0xec)
|[<
c028e6e8>] (bus_remove_driver+0x98/0xec) from [<
c008fc70>] (SyS_delete_module+0x1e0/0x24c)
|[<
c008fc70>] (SyS_delete_module+0x1e0/0x24c) from [<
c000e680>] (ret_fast_syscall+0x0/0x48)
|---[ end trace
d79045419a3e51ec ]---
The workqueue is only scheduled from the ep0 and never canceled in case
the musb is removed before the work has a chance to run.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Fri, 18 Oct 2013 09:36:54 +0000 (11:36 +0200)]
rt2800usb: slow down TX status polling
commit
36165fd5b00bf8163f89c21bb16a3e9834555b10 upstream.
Polling TX statuses too frequently has two negative effects. First is
randomly peek CPU usage, causing overall system functioning delays.
Second bad effect is that device is not able to fill TX statuses in
H/W register on some workloads and we get lot of timeouts like below:
ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
This not only cause flood of messages in dmesg, but also bad throughput,
since rate scaling algorithm can not work optimally.
In the future, we should probably make polling interval be adjusted
automatically, but for now just increase values, this make mentioned
problems gone.
Resolve:
https://bugzilla.kernel.org/show_bug.cgi?id=62781
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>
Thomas Pugliese [Wed, 23 Oct 2013 19:44:26 +0000 (14:44 -0500)]
usb: wusbcore: set the RPIPE wMaxPacketSize value correctly
commit
7b6bc07ab554e929c85d51b3d5b26cf7f12c6a3b upstream.
For isochronous endpoints, set the RPIPE wMaxPacketSize value using
wOverTheAirPacketSize from the endpoint companion descriptor instead of
wMaxPacketSize from the normal endpoint descriptor.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julius Werner [Wed, 16 Oct 2013 00:45:00 +0000 (17:45 -0700)]
usb: hub: Clear Port Reset Change during init/resume
commit
e92aee330837e4911553761490a8fb843f2053a6 upstream.
This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around with USB devices without cleaning up
correctly. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Mon, 30 Sep 2013 14:26:29 +0000 (17:26 +0300)]
usb: Disable USB 2.0 Link PM before device reset.
commit
dcc01c0864823f91c3bf3ffca6613e2351702b87 upstream.
Before the USB core resets a device, we need to disable the L1 timeout
for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may
transition into L1 in between descriptor fetches, before we know if the
USB device descriptors changed. LPM will be re-enabled after the
full device descriptors are fetched, and we can confirm the device still
supports USB 2.0 LPM after the reset.
We don't need to wait for the USB device to exit L1 before resetting the
device, since the xHCI roothub port diagrams show a transition to the
Reset state from any of the Ux states (see Figure 34 in the 2012-08-14
xHCI specification update).
This patch should be backported to kernels as old as 3.2, that contain
the commit
65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM". That was the first commit to enable USB 2.0
hardware-driven Link Power Management.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Tue, 8 Oct 2013 00:17:20 +0000 (17:17 -0700)]
xhci: Set L1 device slot on USB2 LPM enable/disable.
commit
58e21f73975ec927119370635bf68b9023831c56 upstream.
To enable USB 2.0 Link Power Management (LPM), the xHCI host controller
needs the device slot ID to generate the device address used in L1 entry
tokens. That information is set in the L1 device slot ID field of the
USB 2.0 LPM registers.
Currently, the L1 device slot ID is overwritten when the xHCI driver
initiates the software test of USB 2.0 Link PM in
xhci_usb2_software_lpm_test. It is never cleared when USB 2.0 Link PM
is disabled for the device. That should be harmless, because the
Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is
disabled, so the host should not pay attention to the slot ID.
This patch should have no effect on host behavior, but since
xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch,
we need to move that code to the function that enables and disables USB
2.0 Link PM.
This patch should be backported to kernels as old as 3.11, that contain
the commit
a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2
Link power management BESL support". The upcoming bug fix patch is also
marked for that stable kernel.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Mon, 30 Sep 2013 14:26:31 +0000 (17:26 +0300)]
xhci: Enable LPM support only for hardwired or BESL devices
commit
890dae88672175f1d39f6105444d9bdc71c89258 upstream.
Some usb3 devices falsely claim they support usb2 hardware Link PM
when connected to a usb2 port. We only trust hardwired devices
or devices with the later BESL LPM support to be LPM enabled as default.
[Note: Sarah re-worked the original patch to move the code into the USB
core, and updated it to check whether the USB device supports BESL,
instead of checking if the xHCI port it's connected to supports BESL
encoding.]
This patch should be backported to kernels as old as 3.11, that
contain the commit
a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support". Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Mon, 30 Sep 2013 14:26:28 +0000 (17:26 +0300)]
usb: Don't enable USB 2.0 Link PM by default.
commit
de68bab4fa96014cfaa6fcbcdb9750e32969fb86 upstream.
How it's supposed to work:
--------------------------
USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support. USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used. USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.
USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically. The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.
...but hardware is broken:
--------------------------
It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly. This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.
These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0. They
only start to break when L1 entry is interleaved with transfers.
Some devices then fail to respond to the next control transfer (usually
a Set Configuration). This results in devices never enumerating.
Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers. They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers. However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request. Then it never responds to the data phase of the
READ10 command. This results in not being able to read from the drive.
Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved. They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.
Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I
suspect that means the device isn't certified.
What do we do about it?
-----------------------
There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.
This patch should be backported to kernels as old as 3.11, that
contain the commit
a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support". Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Mon, 21 Oct 2013 19:05:38 +0000 (22:05 +0300)]
mei: nfc: fix memory leak in error path
commit
4bff7208f332b2b1d7cf1338e50527441283a198 upstream.
The flow may reach the err label without freeing cl and cl_info
cl and cl_info weren't assigned to ndev->cl and cl_info
so they weren't freed in mei_nfc_free called on error path
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 12 Nov 2013 22:24:36 +0000 (17:24 -0500)]
SUNRPC: Avoid deep recursion in rpc_release_client
commit
d07ba8422f1e58be94cc98a1f475946dc1b89f1b upstream.
In cases where an rpc client has a parent hierarchy, then
rpc_free_client may end up calling rpc_release_client() on the
parent, thus recursing back into rpc_free_client. If the hierarchy
is deep enough, then we can get into situations where the stack
simply overflows.
The fix is to have rpc_release_client() loop so that it can take
care of the parent rpc client hierarchy without needing to
recurse.
Reported-by: Jeff Layton <jlayton@redhat.com>
Reported-by: Weston Andros Adamson <dros@netapp.com>
Reported-by: Bruce Fields <bfields@fieldses.org>
Link: http://lkml.kernel.org/r/2C73011F-0939-434C-9E4D-13A1EB1403D7@netapp.com
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Fri, 8 Nov 2013 21:03:50 +0000 (16:03 -0500)]
SUNRPC: Fix a data corruption issue when retransmitting RPC calls
commit
a6b31d18b02ff9d7915c5898c9b5ca41a798cd73 upstream.
The following scenario can cause silent data corruption when doing
NFS writes. It has mainly been observed when doing database writes
using O_DIRECT.
1) The RPC client uses sendpage() to do zero-copy of the page data.
2) Due to networking issues, the reply from the server is delayed,
and so the RPC client times out.
3) The client issues a second sendpage of the page data as part of
an RPC call retransmission.
4) The reply to the first transmission arrives from the server
_before_ the client hardware has emptied the TCP socket send
buffer.
5) After processing the reply, the RPC state machine rules that
the call to be done, and triggers the completion callbacks.
6) The application notices the RPC call is done, and reuses the
pages to store something else (e.g. a new write).
7) The client NIC drains the TCP socket send buffer. Since the
page data has now changed, it reads a corrupted version of the
initial RPC call, and puts it on the wire.
This patch fixes the problem in the following manner:
The ordering guarantees of TCP ensure that when the server sends a
reply, then we know that the _first_ transmission has completed. Using
zero-copy in that situation is therefore safe.
If a time out occurs, we then send the retransmission using sendmsg()
(i.e. no zero-copy), We then know that the socket contains a full copy of
the data, and so it will retransmit a faithful reproduction even if the
RPC call completes, and the application reuses the O_DIRECT buffer in
the meantime.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Mon, 28 Oct 2013 22:41:44 +0000 (18:41 -0400)]
SUNRPC: gss_alloc_msg - choose _either_ a v0 message or a v1 message
commit
5fccc5b52ee07d07a74ce53c6f174bff81e26a16 upstream.
Add the missing 'break' to ensure that we don't corrupt a legacy 'v0' type
message by appending the 'v1'.
Cc: Bruce Fields <bfields@fieldses.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>