- 04 Dec, 2013 40 commits
-
-
Alex Deucher authored
commit d5693761 upstream. Typo in the register offset. Noticed-by:
Sylvain BERTRAND <sylware@legeek.net> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Skeggs authored
commit 9360bd11 upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Daniel Vetter authored
commit b2ea8ef5 upstream. Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by:
Thomas Richter <thor@math.tu-berlin.de> Cc: Thomas Richter <thor@math.tu-berlin.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jakob Bornecrantz authored
commit 9a0599dd upstream. Fix the case where the ttm pointer may be NULL causing a NULL pointer dereference. Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
Thomas Hellström <thellstrom@vmware.com> Signed-off-by:
-
Dan Williams authored
commit 8e3ffa47 upstream. Userspace uses the netdev devtype for stuff like device naming and type detection. Be nice and set it. Remove the pointless #if/#endif around SET_NETDEV_DEV too. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Andreas Bießmann authored
commit d617b338 upstream. This patch fixes following error (for big kernels): ---8<--- arch/avr32/boot/u-boot/head.o: In function `no_tag_table': (.init.text+0x44): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o arch/avr32/kernel/built-in.o: In function `bad_return': (.ex.text+0x236): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o --->8--- It comes up when the kernel increases and 'panic()' is too far away to fit in the +/- 2MiB range. Which in turn issues from the 21-bit displacement in 'br{cond4}' mnemonic which is one of the two ways to do jumps (rjmp has just 10-bit displacement and therefore a way smaller range). This fact was stated before in 8d29b7b9. One solution to solve this is to add a local storage for the symbol address and just load the $pc with that value. Signed-off-by:
Andreas Bießmann <andreas@biessmann.de> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Signed-off-by:
-
Andreas Bießmann authored
commit 7a2a74f4 upstream. Before the CRT was (fully) set up in kernel_entry (bss cleared before in _start, but also not before jump to panic() in no_tag_table case). This patch fixes this up to have a fully working CRT when branching to panic() in no_tag_table. Signed-off-by:
-
Paul Moore authored
commit 42d64e1a upstream. The SELinux/NetLabel glue code has a locking bug that affects systems with NetLabel enabled, see the kernel error message below. This patch corrects this problem by converting the bottom half socket lock to a more conventional, and correct for this call-path, lock_sock() call. =============================== [ INFO: suspicious RCU usage. ] 3.11.0-rc3+ #19 Not tainted ------------------------------- net/ipv4/cipso_ipv4.c:1928 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by ping/731: #0: (slock-AF_INET/1){+.-...}, at: [...] selinux_netlbl_socket_connect #1: (rcu_read_lock){.+.+..}, at: [<...>] netlbl_conn_setattr stack backtrace: CPU: 1 PID: 731 Comm: ping Not tainted 3.11.0-rc3+ #19 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff88006f659d28 ffffffff81726b6a ffff88003732c500 ffff88006f659d58 ffffffff810e4457 ffff88006b845a00 0000000000000000 000000000000000c ffff880075aa2f50 ffff88006f659d90 ffffffff8169bec7 Call Trace: [<ffffffff81726b6a>] dump_stack+0x54/0x74 [<ffffffff810e4457>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff8169bec7>] cipso_v4_sock_setattr+0x187/0x1a0 [<ffffffff8170f317>] netlbl_conn_setattr+0x187/0x190 [<ffffffff8170f195>] ? netlbl_conn_setattr+0x5/0x190 [<ffffffff8131ac9e>] selinux_netlbl_socket_connect+0xae/0xc0 [<ffffffff81303025>] selinux_socket_connect+0x135/0x170 [<ffffffff8119d127>] ? might_fault+0x57/0xb0 [<ffffffff812fb146>] security_socket_connect+0x16/0x20 [<ffffffff815d3ad3>] SYSC_connect+0x73/0x130 [<ffffffff81739a85>] ? sysret_check+0x22/0x5d [<ffffffff810e5e2d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81373d4e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff815d52be>] SyS_connect+0xe/0x10 [<ffffffff81739a59>] system_call_fastpath+0x16/0x1b Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Yinghai Lu authored
commit e7cc5cf7 upstream. The pcie_portdrv .probe() method calls pci_enable_device() once, in pcie_port_device_register(), but the .remove() method calls pci_disable_device() twice, in pcie_port_device_remove() and in pcie_portdrv_remove(). That causes a "disabling already-disabled device" warning when removing a PCIe port device. This happens all the time when removing Thunderbolt devices, but is also easy to reproduce with, e.g., "echo 0000:00:1c.3 > /sys/bus/pci/drivers/pcieport/unbind" This patch removes the disable from pcie_portdrv_remove(). [bhelgaas: changelog, tag for stable] Reported-by:
David Bulkow <David.Bulkow@stratus.com> Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Mathias Krause authored
commit 64fbff9a upstream. We leak 4 bytes of kernel stack in response to an AUDIT_GET request as we miss to initialize the mask member of status_set. Fix that. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Mathias Krause authored
commit 4d8fe737 upstream. Using the nlmsg_len member of the netlink header to test if the message is valid is wrong as it includes the size of the netlink header itself. Thereby allowing to send short netlink messages that pass those checks. Use nlmsg_len() instead to test for the right message length. The result of nlmsg_len() is guaranteed to be non-negative as the netlink message already passed the checks of nlmsg_ok(). Also switch to min_t() to please checkpatch.pl. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
-
Tyler Hicks authored
commit 0868a5e1 upstream. When the audit=1 kernel parameter is absent and auditd is not running, AUDIT_USER_AVC messages are being silently discarded. AUDIT_USER_AVC messages should be sent to userspace using printk(), as mentioned in the commit message of 4a4cd633 ("AUDIT: Optimise the audit-disabled case for discarding user messages"). When audit_enabled is 0, audit_receive_msg() discards all user messages except for AUDIT_USER_AVC messages. However, audit_log_common_recv_msg() refuses to allocate an audit_buffer if audit_enabled is 0. The fix is to special case AUDIT_USER_AVC messages in both functions. It looks like commit 50397bd1 ("[AUDIT] clean up audit_receive_msg()") introduced this bug. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Cc: linux-audit@redhat.com Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Avinash Patil authored
commit d03b4aa7 upstream. While receiving a packet on SDIO interface, we allocate skb with size multiple of SDIO block size. We need to resize this skb after RX using packet length from RX header. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Aaron Lu authored
commit fd432b9f upstream. When system has a lot of highmem (e.g. 16GiB using a 32 bits kernel), the code to calculate how much memory we need to preallocate in normal zone may cause overflow. As Leon has analysed: It looks that during computing 'alloc' variable there is overflow: alloc = (3943404 - 1970542) - 1978280 = -5418 (signed) And this function goes to err_out. Fix this by avoiding that overflow. References: https://bugzilla.kernel.org/show_bug.cgi?id=60817Reported-and-tested-by:
Leon Drugi <eyak@wp.pl> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Mikulas Patocka authored
commit f36afb39 upstream. dm-mpath and dm-thin must process messages even if some device is suspended, so we allocate argv buffer with GFP_NOIO. These messages have a small fixed number of arguments. On the other hand, dm-switch needs to process bulk data using messages so excessive use of GFP_NOIO could cause trouble. The patch also lowers the default number of arguments from 64 to 8, so that there is smaller load on GFP_NOIO allocations. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Acked-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 2bf127a5 upstream. RSSI value is provided on word3 not on word2. Signed-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
Ursula Braun authored
commit 6fb392b1 upstream. Check user-defined length in snmp ioctl request and allow request only if it fits into a qeth command buffer. Signed-off-by:
Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by:
Frank Blaschka <frank.blaschka@de.ibm.com> Reviewed-by:
Heiko Carstens <heicars2@linux.vnet.ibm.com> Reported-by:
Nico Golde <nico@ngolde.de> Reported-by:
Fabian Yamaguchi <fabs@goesec.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Larry Finger authored
commit 78dbfecb 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:
-
Larry Finger authored
commit b4ade797 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:
Matthieu Baerts <matttbe@gmail.com> Signed-off-by:
-
Larry Finger authored
commit 3545f3d5 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:
-
Malcolm Priestley authored
commit 9df68292 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:
-
Vegard Nossum authored
commit ea5ec76d 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 604c499c (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:
-
Theodore Ts'o authored
commit dcb9917b upstream. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Huang Shijie authored
commit 7b3d2fb9 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:
-
Wang Haitao authored
commit a4d62bab 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 authored
commit 4355b70c 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:
-
Mikulas Patocka authored
commit 3ec981e3 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:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jan Kara authored
commit 4adcf7fb 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:
-
Eric Seppanen authored
commit 86784c6b 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:
-
Eric Seppanen authored
commit 369653e4 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:
-
Samir Benmendil authored
commit 6d5278a6 upstream. Tested with a DAWICONTROL DC-624e on 3.10.10 Signed-off-by:
Samir Benmendil <samir.benmendil@gmail.com> Signed-off-by:
Levente Kurusa <levex@linux.com> Signed-off-by:
-
xiangliang yu authored
commit 89dafa20 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:
-
Larry Finger authored
commit eafbdde9 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:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by:
-
Felipe Pena authored
commit 3aef7dde 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:
-
Ryan Mallon authored
commit 312b4e22 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:
-
Shan Hai authored
commit 0523f037 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:
-
Gwendal Grignou authored
commit 3e85c3ec 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:
-
Marc Kleine-Budde authored
commit 0d1862ea upstream. In the flexcan_chip_start() function first the flexcan core is going through the soft reset sequence, then the RX FIFO is enabled. With the hardware is put into FIFO mode, message buffers 1...7 are reserved by the FIFO engine. The remaining message buffers are in reset default values. This patch removes the bogus initialization of the message buffers, as it causes an imprecise external abort on imx6. Reported-by:
Lothar Waßmann <LW@KARO-electronics.de> Tested-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Ilija Hadzic authored
commit 66da0e1f 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:
-
KOSAKI Motohiro authored
commit 98d6f4dd 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 1c6b39ad (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:
-
