- 21 Nov, 2014 9 commits
-
-
Jesse Gross authored
[ Upstream commit cfdf1e1b ] When doing GRO processing for UDP tunnels, we never add SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol is added (such as SKB_GSO_TCPV4). The result is that if the packet is later resegmented we will do GSO but not treat it as a tunnel. This results in UDP fragmentation of the outer header instead of (i.e.) TCP segmentation of the inner header as was originally on the wire. Signed-off-by:
Jesse Gross <jesse@nicira.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Karl Beldan authored
[ Upstream commit 2c2a9cbd ] ATM, txq_reclaim will dequeue and free an skb for each tx desc released by the hw that has TX_LAST_DESC set. However, in case of TSO, each hw desc embedding the last part of a segment has TX_LAST_DESC set, losing the one-to-one 'last skb frag'/'TX_LAST_DESC set' correspondance, which causes data corruption. Fix this by checking TX_ENABLE_INTERRUPT instead of TX_LAST_DESC, and warn when trying to dequeue from an empty txq (which can be symptomatic of releasing skbs prematurely). Fixes: 3ae8f4e0 ('net: mv643xx_eth: Implement software TSO') Reported-by:
Slawomir Gajzner <slawomir.gajzner@gmail.com> Reported-by:
Julien D'Ascenzio <jdascenzio@yahoo.fr> Signed-off-by:
Karl Beldan <karl.beldan@rivierawaves.com> Cc: Ian Campbell <ijc@hellion.org.uk> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit f03eb128 ] Otherwise it gets overwritten by register_netdev(). Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit ebe084aa ] ipip6_tunnel_init() sets the dev->iflink via a call to ipip6_tunnel_bind_dev(). After that, register_netdevice() sets dev->iflink = -1. So we loose the iflink configuration for ipv6 tunnels. Fix this by using ipip6_tunnel_init() as the ndo_init function. Then ipip6_tunnel_init() is called after dev->iflink is set to -1 from register_netdevice(). Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit 16a0231b ] vti6_dev_init() sets the dev->iflink via a call to vti6_link_config(). After that, register_netdevice() sets dev->iflink = -1. So we loose the iflink configuration for vti6 tunnels. Fix this by using vti6_dev_init() as the ndo_init function. Then vti6_dev_init() is called after dev->iflink is set to -1 from register_netdevice(). Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit 6c6151da ] ip6_tnl_dev_init() sets the dev->iflink via a call to ip6_tnl_link_config(). After that, register_netdevice() sets dev->iflink = -1. So we loose the iflink configuration for ipv6 tunnels. Fix this by using ip6_tnl_dev_init() as the ndo_init function. Then ip6_tnl_dev_init() is called after dev->iflink is set to -1 from register_netdevice(). Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit d70127e8 ] The WARN_ON in inet_evict_bucket can be triggered by a valid case: inet_frag_kill and inet_evict_bucket can be running in parallel on the same queue which means that there has been at least one more ref added by a previous inet_frag_find call, but inet_frag_kill can delete the timer before inet_evict_bucket which will cause the WARN_ON() there to trigger since we'll have refcnt!=1. Now, this case is valid because the queue is being "killed" for some reason (removed from the chain list and its timer deleted) so it will get destroyed in the end by one of the inet_frag_put() calls which reaches 0 i.e. refcnt is still valid. CC: Florian Westphal <fw@strlen.de> CC: Eric Dumazet <eric.dumazet@gmail.com> CC: Patrick McLean <chutzpah@gentoo.org> Fixes: b13d3cbf ("inet: frag: move eviction of queues to work queue") Reported-by:
Patrick McLean <chutzpah@gentoo.org> Signed-off-by:
Nikolay Aleksandrov <nikolay@redhat.com> Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit 65ba1f1e ] When the evictor is running it adds some chosen frags to a local list to be evicted once the chain lock has been released but at the same time the *frag_queue can be running for some of the same queues and it may call inet_frag_kill which will wait on the chain lock and will then delete the queue from the wrong list since it was added in the eviction one. The fix is simple - check if the queue has the evict flag set under the chain lock before deleting it, this is safe because the evict flag is set only under that lock and having the flag set also means that the queue has been detached from the chain list, so no need to delete it again. An important note to make is that we're safe w.r.t refcnt because inet_frag_kill and inet_evict_bucket will sync on the del_timer operation where only one of the two can succeed (or if the timer is executing - none of them), the cases are: 1. inet_frag_kill succeeds in del_timer - then the timer ref is removed, but inet_evict_bucket will not add this queue to its expire list but will restart eviction in that chain 2. inet_evict_bucket succeeds in del_timer - then the timer ref is kept until the evictor "expires" the queue, but inet_frag_kill will remove the initial ref and will set INET_FRAG_COMPLETE which will make the frag_expire fn just to remove its ref. In the end all of the queue users will do an inet_frag_put and the one that reaches 0 will free it. The refcount balance should be okay. CC: Florian Westphal <fw@strlen.de> CC: Eric Dumazet <eric.dumazet@gmail.com> CC: Patrick McLean <chutzpah@gentoo.org> Fixes: b13d3cbf ("inet: frag: move eviction of queues to work queue") Suggested-by:
Eric Dumazet <eric.dumazet@gmail.com> Reported-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Shuah Khan authored
commit 4ea48a01 upstream. The following generated files are missing from gitignore and show up in git status after x86_64 build. Add them to gitignore. arch/x86/purgatory/kexec-purgatory.c arch/x86/purgatory/purgatory.ro Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Link: http://lkml.kernel.org/r/1412016116-7213-1-git-send-email-shuahkh@osg.samsung.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
- 14 Nov, 2014 31 commits
-
-
Greg Kroah-Hartman authored
-
Nadav Amit authored
commit 7e46dddd upstream. Commit d1442d85 ("KVM: x86: Handle errors when RIP is set during far jumps") introduced a bug that caused the fix to be incomplete. Due to incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may not trigger #GP. As we know, this imposes a security problem. In addition, the condition for two warnings was incorrect. Fixes: d1442d85Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Nadav Amit <namit@cs.technion.ac.il> [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Olivier Gay authored
commit f974008f upstream. Add keyboard input assist controls usages from approved hid usage table request HUTTR42: http://www.usb.org/developers/hidpage/HUTRR42c.pdfSigned-off-by:
Olivier Gay <ogay@logitech.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Dave Chinner authored
commit 00275899 upstream. The bulkstat main loop progress is tracked by the "lastino" variable, which is a full 64 bit inode. However, the loop actually works on agno/agino pairs, and so there's a significant disconnect between the rest of the loop and the main cursor. Convert this to use the agino, and pass the agino into the chunk formatting function and convert it too. This gets rid of the inconsistency in the loop processing, and finally makes it simple for us to skip inodes at any point in the loop simply by incrementing the agino cursor. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Dave Chinner authored
commit febe3cbe upstream. The error propagation is a horror - xfs_bulkstat() returns a rval variable which is only set if there are formatter errors. Any sort of btree walk error or corruption will cause the bulkstat walk to terminate but will not pass an error back to userspace. Worse is the fact that formatter errors will also be ignored if any inodes were correctly formatted into the user buffer. Hence bulkstat can fail badly yet still report success to userspace. This causes significant issues with xfsdump not dumping everything in the filesystem yet reporting success. It's not until a restore fails that there is any indication that the dump was bad and tha bulkstat failed. This patch now triggers xfsdump to fail with bulkstat errors rather than silently missing files in the dump. This now causes bulkstat to fail when the lastino cookie does not fall inside an existing inode chunk. The pre-3.17 code tolerated that error by allowing the code to move to the next inode chunk as the agino target is guaranteed to fall into the next btree record. With the fixes up to this point in the series, xfsdump now passes on the troublesome filesystem image that exposes all these bugs. Signed-off-by:
-
Dave Chinner authored
commit 6e57c542 upstream. There are a bunch of variables tha tare more wildy scoped than they need to be, obfuscated user buffer checks and tortured "next inode" tracking. This all needs cleaning up to expose the real issues that need fixing. Signed-off-by:
-
Dave Chinner authored
commit 2b831ac6 upstream. The loop construct has issues: - clustidx is completely unused, so remove it. - the loop tries to be smart by terminating when the "freecount" tells it that all inodes are free. Just drop it as in most cases we have to scan all inodes in the chunk anyway. - move the "user buffer left" condition check to the only point where we consume space int eh user buffer. - move the initialisation of agino out of the loop, leaving just a simple loop control logic using the clusteridx. Also, double handling of the user buffer variables leads to problems tracking the current state - use the cursor variables directly rather than keeping local copies and then having to update the cursor before returning. Signed-off-by:
-
Dave Chinner authored
commit bf4a5af2 upstream. The xfs_bulkstat_agichunk formatting cursor takes buffer values from the main loop and passes them via the structure to the chunk formatter, and the writes the changed values back into the main loop local variables. Unfortunately, this complex dance is full of corner cases that aren't handled correctly. The biggest problem is that it is double handling the information in both the main loop and the chunk formatting function, leading to inconsistent updates and endless loops where progress is not made. To fix this, push the struct xfs_bulkstat_agichunk outwards to be the primary holder of user buffer information. this removes the double handling in the main loop. Also, pass the last inode processed by the chunk formatter as a separate parameter as it purely an output variable and is not related to the user buffer consumption cursor. Finally, the chunk formatting code is not shared by anyone, so make it local to xfs_itable.c. Signed-off-by:
-
Dave Chinner authored
commit afa947cb upstream. The bulkstat code has several different ways of detecting the end of an AG when doing a walk. They are not consistently detected, and the code that checks for the end of AG conditions is not consistently coded. Hence the are conditions where the walk code can get stuck in an endless loop making no progress and not triggering any termination conditions. Convert all the "tmp/i" status return codes from btree operations to a common name (stat) and apply end-of-ag detection to these operations consistently. Signed-off-by:
-
Jan Kara authored
commit 7a19dee1 upstream. xfs_bulkstat() doesn't check error return from xfs_btree_increment(). In case of specific fs corruption that could result in xfs_bulkstat() entering an infinite loop because we would be looping over the same chunk over and over again. Fix the problem by checking the return value and terminating the loop properly. Coverity-id: 1231338 Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Jie Liu <jeff.u.liu@gmail.com> Signed-off-by:
-
Dave Chinner authored
commit a6bbce54 upstream. The recent refactoring of the bulkstat code left a small landmine in the code. If a inobt read fails, then the tree walk is aborted and returns without releasing the AGI buffer or freeing the cursor. This can lead to a subsequent bulkstat call hanging trying to grab the AGI buffer again. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Chris Mason authored
commit 6e5aafb2 upstream. If we hit any errors in btrfs_lookup_csums_range, we'll loop through all the csums we allocate and free them. But the code was using list_entry incorrectly, and ended up trying to free the on-stack list_head instead. This bug came from commit 0678b618 btrfs: Don't BUG_ON kzalloc error in btrfs_lookup_csums_range() Signed-off-by:
Chris Mason <clm@fb.com> Reported-by:
Erik Berg <btrfs@slipsprogrammoer.no> Signed-off-by:
-
Grant Likely authored
commit a87fa1d8 upstream. The string property read helpers will run off the end of the buffer if it is handed a malformed string property. Rework the parsers to make sure that doesn't happen. At the same time add new test cases to make sure the functions behave themselves. The original implementations of of_property_read_string_index() and of_property_count_strings() both open-coded the same block of parsing code, each with it's own subtly different bugs. The fix here merges functions into a single helper and makes the original functions static inline wrappers around the helper. One non-bugfix aspect of this patch is the addition of a new wrapper, of_property_read_string_array(). The new wrapper is needed by the device_properties feature that Rafael is working on and planning to merge for v3.19. The implementation is identical both with and without the new static inline wrapper, so it just got left in to reduce the churn on the header file. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Darren Hart <darren.hart@intel.com> Signed-off-by:
-
Andreas Färber authored
commit 92c9e0c7 upstream. The Parallella board comes with a U-Boot bootloader that loads one of two predefined FPGA bitstreams before booting the kernel. Both define an AXI interface to the on-board Epiphany processor. Enable clocks FCLK0..FCLK3 for the Programmable Logic by default. Otherwise accessing, e.g., the ESYSRESET register freezes the board, as seen with the Epiphany SDK tools e-reset and e-hw-rev, using /dev/mem. Signed-off-by:
Andreas Färber <afaerber@suse.de> Acked-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Yijing Wang authored
commit e4a60d13 upstream. There is a race condition when removing glue directory. It can be reproduced in following test: path 1: Add first child device device_add() get_device_parent() /*find parent from glue_dirs.list*/ list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) if (k->parent == parent_kobj) { kobj = kobject_get(k); break; } .... class_dir_create_and_add() path2: Remove last child device under glue dir device_del() cleanup_device_parent() cleanup_glue_dir() kobject_put(glue_dir); If path2 has been called cleanup_glue_dir(), but not call kobject_put(glue_dir), the glue dir is still in parent's kset list. Meanwhile, path1 find the glue dir from the glue_dirs.list. Path2 may release glue dir before path1 call kobject_get(). So kernel will report the warning and bug_on. This is a "classic" problem we have of a kref in a list that can be found while the last instance could be removed at the same time. This patch reuse gdp_mutex to fix this race condition. The following calltrace is captured in kernel 3.4, but the latest kernel still has this bug. ----------------------------------------------------- <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40() <4>[ 3965.441474] Hardware name: Romley <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)... ... <4>[ 3965.441605] Call Trace: <4>[ 3965.441611] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0 <4>[ 3965.441615] [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20 <4>[ 3965.441618] [<ffffffff81215963>] kobject_get+0x33/0x40 <4>[ 3965.441624] [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0 <4>[ 3965.441627] [<ffffffff812d22d4>] device_add+0xd4/0x6d0 <4>[ 3965.441631] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40 .... <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65! <4>[ 3965.441915] invalid opcode: 0000 [#1] SMP ... <4>[ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10 <4>[ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20 <4>[ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120 <4>[ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490 .... ------------------------------------------------------- Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
Weng Meiling <wengmeiling.weng@huawei.com> Signed-off-by:
-
Wolfram Sang authored
commit 11cfbfb0 upstream. iowait is for blkio [1]. I2C shouldn't use it. [1] https://lkml.org/lkml/2014/11/3/317Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Grzegorz Jaszczyk authored
commit 758e8366 upstream. In both Armada-375 and Armada-38x MPIC interrupts should be identified by reading cause register multiplied by the interrupt mask. A lack of above mentioned multiplication resulted in a bug, caused by the fact that in Armada-375 and Armada-38x some of the interrupts (e.g. network interrupts) can be handled either as a GIC or MPIC interrupts. Therefore during MPIC interrupts handling, cause register shows hits from interrupts even if they are masked for MPIC but unmasked for a GIC. This resulted in 'bad IRQ' error, because masked MPIC interrupt without registered interrupt handler, was trying to be handled during interrupt handling procedure of some other unmasked MPIC interrupt (e.g. local timer irq). This commit fixes that by ensuring that during MPIC interrupt handling only interrupts that are unmasked for MPIC are processed. Signed-off-by:
Grzegorz Jaszczyk <jaz@semihalf.com> Reviewed-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes: bc69b8ad ("irqchip: armada-370-xp: Setup a chained handler for the MPIC") Acked-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Link: https://lkml.kernel.org/r/1411643839-64925-3-git-send-email-jaz@semihalf.comSigned-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Grzegorz Jaszczyk authored
commit 298dcb2d upstream. The MSI interrupts use the 16 high doorbells, which are notified by using IRQ1 of the main interrupt controller. The MSI interrupts were handled correctly for Armada-XP and Armada-370 but not for Armada-375 and Armada-38x, which use chained handler for the MPIC. This commit fixes that by checking proper interrupt number in chained handler for the MPIC. Signed-off-by:
-
Krzysztof Kozlowski authored
commit ca0c37a0 upstream. Driver allocated on stack struct regulator_config but didn't initialize it fully. Few fields (driver_data, ena_gpio) were left untouched. This lead to using random ena_gpio values as GPIOs for max77693 regulators. On occasion these values could match real GPIO numbers leading to interfering with other drivers and to unsuccessful enable/disable of regulator. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 80b022e2 ("regulator: max77693: Add max77693 regualtor driver.") Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Hui Wang authored
commit c922c4e8 upstream. Without the fix, the mute led can't work on these three machines. After apply this fix, these three machines will fall back on the led control quirk as below, and through testing, the mute led works very well. PIN_QUIRK(0x10ec0282, 0x103c, "HP", ALC269_FIXUP_HP_LINE1_MIC1_LED, ALC282_STANDARD_PINS, {0x12, 0x90a60140}, ... BugLink: https://bugs.launchpad.net/bugs/1389497Tested-by:
TieFu Chen <tienfu.chen@canonical.com> Cc: Kailang Yang <kailang@realtek.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Anton Blanchard authored
commit 808be314 upstream. Back in 7230c564 ("powerpc: Rework lazy-interrupt handling") we added a call out to restore_interrupts() (written in c) before calling do_notify_resume: bl restore_interrupts addi r3,r1,STACK_FRAME_OVERHEAD bl do_notify_resume Unfortunately do_notify_resume takes two arguments, the second one being the thread_info flags: void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags) We do populate r4 (the second argument) earlier, but restore_interrupts() is free to muck it up all it wants. My guess is the gcc compiler gods shone down on us and its register allocator never used r4. Sometimes, rarely, luck is on our side. LLVM on the other hand did trample r4. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 325e4114 upstream. Endian is hard, especially when I designed a stupid FW interface, and I should know better... oh well, this is attempt #2 at fixing this properly. This time it seems to work with all access sizes and I can run my flashing tool (which exercises all sort of access sizes and types to access the SPI controller in the BMC) just fine. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Dan Streetman authored
commit 10ccaf17 upstream. In powerpc pseries platform dlpar operations, use device_online() and device_offline() instead of cpu_up() and cpu_down(). Calling cpu_up/down() directly does not update the cpu device offline field, which is used to online/offline a cpu from sysfs. Calling device_online/offline() instead keeps the sysfs cpu online value correct. The hotplug lock, which is required to be held when calling device_online/offline(), is already held when dlpar_online/offline_cpu() are called, since they are called only from cpu_probe|release_store(). This patch fixes errors on phyp (PowerVM) systems that have cpu(s) added/removed using dlpar operations; without this patch, the /sys/devices/system/cpu/cpuN/online nodes do not correctly show the online state of added/removed cpus. Signed-off-by:
Dan Streetman <ddstreet@ieee.org> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com> Fixes: 0902a904 ("Driver core: Use generic offline/online for CPU offline/online") Signed-off-by:
-
Robert Jarzmik authored
commit cde7fc87 upstream. The commit 2111667b ("ARM: pxa: call debug_ll_io_init for earlyprintk") triggers in the current kernel the attached backtrace on PXA/tosa early in the boot time when DEBUG_LL is enabled. It is due to overlap between uart virtual memory defined in DEBUG_UART_VIRT and mapped by debug_ll_io_init() and peripheral bus mapped by pxa_map_io at the same address, 0xf2100000. As hinted by Arnd, map early virtual memory for low level debug on address 0xf6200000, even if that means 2 virtual mappings will give access to the pxa internal UARTs (FFUART, BTUART, STUART, ...). ------------[ cut here ]------------ kernel BUG at /home/lumag/linux/mm/vmalloc.c:1143! Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-00032-g8e0d202-dirty #23 task: c062a5a8 ti: c0620000 task.ti: c0620000 PC is at vm_area_add_early+0x54/0x84 LR is at add_static_vm_early+0xc/0x60 pc : [<c03e1100>] lr : [<c03d9ef4>] psr: 800001d3 sp : c0621f04 ip : c03efa74 fp : c03edf84 r10: c0637e98 r9 : 40000001 r8 : c03da57c r7 : c3ffcfb0 r6 : 00000000 r5 : c3ffcfb0 r4 : 02000000 r3 : c3ffcfd8 r2 : f2100000 r1 : f4000000 r0 : c3ffcfb0 Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00007977 Table: a0004000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc06201c8) Stack: (0xc0621f04 to 0xc0622000) 1f00: c3ffcfd8 40000001 c3ffcfd8 c03ee08c c03da570 c03db90c c0637d24 1f20: 00000000 c03ec7cc c066e654 a0700000 000a0700 c03db914 c03db90c c03daf84 1f40: 00000000 000a0000 c0000000 c03ec7cc 000a0700 c0700000 ffff1000 000a3fff 1f60: 00001000 00000007 00000000 c03ec7cc c0008000 c03ed748 c0621fd4 c03d5d18 1f80: 69052d00 a03ec48c 00000000 c03d8ad0 0000006c 00007977 c036c6e8 00000001 1fa0: c0621fd4 c03ed744 c0628000 a0004000 69052d00 a03ec48c 00000000 c03d68d4 1fc0: 00000000 00000000 00000000 00000000 00000000 c03ed748 c0649894 c062801c 1fe0: c03ed744 c062b2f0 a0004000 69052d00 a03ec48c a0008040 00000000 00000000 [<c03e1100>] (vm_area_add_early) from [<c03d9ef4>] (add_static_vm_early+0xc/0x60) [<c03d9ef4>] (add_static_vm_early) from [<c03da570>] (iotable_init.part.6+0xa8/0xb4) [<c03da570>] (iotable_init.part.6) from [<c03db914>] (pxa25x_map_io+0x8/0x24) [<c03db914>] (pxa25x_map_io) from [<c03daf84>] (paging_init+0x744/0x8d8) [<c03daf84>] (paging_init) from [<c03d8ad0>] (setup_arch+0x354/0x608) [<c03d8ad0>] (setup_arch) from [<c03d68d4>] (start_kernel+0xa8/0x3dc) [<c03d68d4>] (start_kernel) from [<a0008040>] (0xa0008040) Code: e5904008 e0811004 e1520001 2a000005 (e7f001f2) ---[ end trace f24b6c88ae00fa9a ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! Reported-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David Cohen authored
commit d90c3381 upstream. Even if a gpio pin is set to output, we still need to set INPUT_EN functionality (by clearing INPUT_EN bit) to be able to read the pin's level. E.g. without this change, we'll always read low level state from sysfs. Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Reviewed-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Al Viro authored
commit 7e8631e8 upstream. uninitialized msghdr. Broken in "ocfs2: don't open-code kernel_recvmsg()" by me ;-/ Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Hans de Goede authored
commit 5a1426c9 upstream. The acpi-video backlight interface on the NC210 does not work, blacklist it and use the samsung-laptop interface instead. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=861573Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
commit 183fd8fc upstream. The acpi-video backlight interface on the Acer KAV80 is broken, and worse it causes the entire machine to slow down significantly after a suspend/resume. Blacklist it, and use the acer-wmi backlight interface instead. Note that the KAV80 is somewhat unique in that it is the only Acer model where we fall back to acer-wmi after blacklisting, rather then using the native (e.g. intel) backlight driver. This is done because there is no native backlight interface on this model. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1128309Signed-off-by:
-
Jan Kara authored
commit a8d42056 upstream. When we fail to allocate page vector in rbd_obj_read_sync() we just basically ignore the problem and continue which will result in an oops later. Fix the problem by returning proper error. CC: Yehuda Sadeh <yehuda@inktank.com> CC: Sage Weil <sage@inktank.com> CC: ceph-devel@vger.kernel.org Coverity-id: 1226882 Signed-off-by:
Ilya Dryomov <idryomov@redhat.com> Signed-off-by:
-
Laurent Pinchart authored
commit f022d8cb upstream. If activation of the CMA area fails its mutex won't be initialized, leading to an oops at allocation time when trying to lock the mutex. Fix this by setting the cma area count field to 0 when activation fails, leading to allocation returning NULL immediately. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
jens stein authored
commit b2a9601c upstream. commit c675949e Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT check so backlight is set up properly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438Signed-off-by:
Jens Stein Jørgensen <jens.s.stein@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
