- 21 May, 2012 35 commits
-
-
Alexander Clouter authored
commit 1ebfefcf upstream. Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks into undefined exports. ---- MODPOST 81 modules Kernel: arch/arm/boot/Image is ready AS arch/arm/boot/compressed/head.o GZIP arch/arm/boot/compressed/piggy.gzip CC arch/arm/boot/compressed/misc.o CC arch/arm/boot/compressed/decompress.o ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 make: *** Waiting for unfinished jobs.... ---- Signed-off-by:
Alexander Clouter <alex@digriz.org.uk> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chris Metcalf authored
commit a134d228 upstream. This passes siginfo and mcontext to tilegx32 signal handlers that don't have SA_SIGINFO set just as we have been doing for tilegx64. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Josh Cartwright authored
commit 226bb7df upstream. The locking policy is such that the erase_complete_block spinlock is nested within the alloc_sem mutex. This fixes a case in which the acquisition order was erroneously reversed. This issue was caught by the following lockdep splat: ======================================================= [ INFO: possible circular locking dependency detected ] 3.0.5 #1 ------------------------------------------------------- jffs2_gcd_mtd6/299 is trying to acquire lock: (&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890 but task is already holding lock: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}: [<c008bec4>] validate_chain+0xe6c/0x10bc [<c008c660>] __lock_acquire+0x54c/0xba4 [<c008d240>] lock_acquire+0xa4/0x114 [<c046780c>] _raw_spin_lock+0x3c/0x4c [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890 [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc [<c0071a68>] kthread+0x98/0xa0 [<c000f264>] kernel_thread_exit+0x0/0x8 -> #0 (&c->alloc_sem){+.+.+.}: [<c008ad2c>] print_circular_bug+0x70/0x2c4 [<c008c08c>] validate_chain+0x1034/0x10bc [<c008c660>] __lock_acquire+0x54c/0xba4 [<c008d240>] lock_acquire+0xa4/0x114 [<c0466628>] mutex_lock_nested+0x74/0x33c [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890 [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc [<c0071a68>] kthread+0x98/0xa0 [<c000f264>] kernel_thread_exit+0x0/0x8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&c->erase_completion_lock)->rlock); lock(&c->alloc_sem); lock(&(&c->erase_completion_lock)->rlock); lock(&c->alloc_sem); *** DEADLOCK *** 1 lock held by jffs2_gcd_mtd6/299: #0: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890 stack backtrace: [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24) [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc) [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4) [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114) [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c) [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0) [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8) This was introduce in '81cfc9f1 jffs2: Fix serious write stall due to erase'. Signed-off-by:
Josh Cartwright <joshc@linux.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Russ Anderson authored
commit 6bc2e853 upstream. Systems with 8 TBytes of memory or greater can hit a problem where only the the first 8 TB of memory shows up. This is due to "int i" being smaller than "unsigned long start_aligned", causing the high bits to be dropped. The fix is to change `i' to unsigned long to match start_aligned and end_aligned. Thanks to Jack Steiner for assistance tracking this down. Signed-off-by:
Russ Anderson <rja@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Gavin Shan <shangw@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:
-
Chris Metcalf authored
commit 4998a6c0 upstream. Commit 66aebce7 ("hugetlb: fix race condition in hugetlb_fault()") added code to avoid a race condition by elevating the page refcount in hugetlb_fault() while calling hugetlb_cow(). However, one code path in hugetlb_cow() includes an assertion that the page count is 1, whereas it may now also have the value 2 in this path. The consensus is that this BUG_ON has served its purpose, so rather than extending it to cover both cases, we just remove it. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Acked-by:
Hillf Danton <dhillf@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Tejun Heo authored
commit 42b64281 upstream. pcpu_embed_first_chunk() allocates memory for each node, copies percpu data and frees unused portions of it before proceeding to the next group. This assumes that allocations for different nodes doesn't overlap; however, depending on memory topology, the bootmem allocator may end up allocating memory from a different node than the requested one which may overlap with the portion freed from one of the previous percpu areas. This leads to percpu groups for different nodes overlapping which is a serious bug. This patch separates out copy & partial free from the allocation loop such that all allocations are complete before partial frees happen. This also fixes overlapping frees which could happen on allocation failure path - out_free_areas path frees whole groups but the groups could have portions freed at that point. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
"Pavel V. Panteleev" <pp_84@mail.ru> Tested-by:
-
Dan Williams authored
commit 4e6304b8 upstream. Needs to be tagged with FLAG_WWAN, which since it has generic descriptors, won't happen if we don't override the generic driver info. Cc: Oliver Neukum <oliver@neukum.org> Cc: stable@vger.kernel.org Signed-off-by:
Dan Williams <dcbw@redhat.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Bjørn Mork authored
commit 6eddcb4c upstream. Some RNDIS devices include a bogus CDC Union descriptor pointing to non-existing interfaces. The RNDIS code is already prepared to handle devices without a CDC Union descriptor by hardwiring the driver to use interfaces 0 and 1, which is correct for the devices with the bogus descriptor as well. So we can reuse the existing workaround. Cc: Markus Kolb <linux-201011@tower-net.de> Cc: Iker Salmón San Millán <shaola@esdebian.org> Cc: Jonathan Nieder <jrnieder@gmail.com> Cc: Oliver Neukum <oliver@neukum.org> Cc: 655387@bugs.debian.org Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Luis Henriques authored
commit 9ef449c6 upstream. An early registration of an ISR was causing a crash to several users (for example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723). The reason was that IRQs were being triggered before a driver initialisation was completed. This patch fixes this by moving the invocation to request_irq() and to request_region() to a later stage on the driver probe function. Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Russell King authored
commit 9b61a4d1 upstream. Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
David S. Miller authored
[ Upstream commit a5a737e0 ] %g2 is meant to hold the CPUID number throughout this routine, since at the very beginning, and at the very end, we use %g2 to calculate indexes into per-cpu arrays. However we erroneously clobber it in order to hold the %cwp register value mid-stream. Fix this code to use %g3 for the %cwp read and related calulcations instead. Reported-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
-
Mike Galbraith authored
commit 5e2bf014 upstream. Fork() failure post namespace creation for a child cloned with CLONE_NEWPID leaks pid_namespace/mnt_cache due to proc being mounted during creation, but not unmounted during cleanup. Call pid_ns_release_proc() during cleanup. Signed-off-by:
Mike Galbraith <efault@gmx.de> Acked-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Louis Rilling <louis.rilling@kerlabs.com> Signed-off-by:
-
Ming Lei authored
commit 5b6e9bcd upstream. Commit 4231d47e(net/usbnet: avoid recursive locking in usbnet_stop()) fixes the recursive locking problem by releasing the skb queue lock before unlink, but may cause skb traversing races: - after URB is unlinked and the queue lock is released, the refered skb and skb->next may be moved to done queue, even be released - in skb_queue_walk_safe, the next skb is still obtained by next pointer of the last skb - so maybe trigger oops or other problems This patch extends the usage of entry->state to describe 'start_unlink' state, so always holding the queue(rx/tx) lock to change the state if the referd skb is in rx or tx queue because we need to know if the refered urb has been started unlinking in unlink_urbs. The other part of this patch is based on Huajun's patch: always traverse from head of the tx/rx queue to get skb which is to be unlinked but not been started unlinking. Signed-off-by:
Huajun Li <huajun.li.lee@gmail.com> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
David Henningsson authored
commit 32cf4023 upstream. When an IRQ for some reason gets lost, we wait up to a second using udelay, which is CPU intensive. This patch improves the situation by waiting about 30 ms in the CPU intensive mode, then stepping down to using msleep(2) instead. In essence, we trade some granularity in exchange for less CPU consumption when the waiting time is a bit longer. As a result, PulseAudio should no longer be killed by the kernel for taking up to much RT-prio CPU time. At least not for *this* reason. Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Tested-by:
Arun Raghavan <arun.raghavan@collabora.co.uk> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Hills authored
commit c914f55f upstream. This assertion seems to imply that chip->dsp_code_to_load is a pointer. It's actually an integer handle on the actual firmware, and 0 has no special meaning. The assertion prevents initialisation of a Darla20 card, but would also affect other models. It seems it was introduced in commit dd7b254d. ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting... ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000 ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware... ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20 ------------[ cut here ]------------ WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]() Hardware name: Dell DM051 BUG? (!chip->dsp_code_to_load || !chip->comm_page) Signed-off-by:
Mark Hills <mark@pogo.org.uk> Signed-off-by:
-
Josh Boyer authored
commit 6fe6ae56 upstream. When the keyboard backlight support was originally added, the commit said to default it to on with a 10 second timeout. That actually wasn't the case, as the default value is commented out for the kbd_backlight parameter. Because it is a static variable, it gets set to 0 by default without some other form of initialization. However, it seems the function to set the value wasn't actually called immediately, so whatever state the keyboard was in initially would remain. Then commit df410d52 was introduced during the 2.6.39 timeframe to immediately set whatever value was present (as well as attempt to restore/reset the state on module removal or resume). That seems to have now forced the light off immediately when the module is loaded unless the option kbd_backlight=1 is specified. Let's enable it by default again (for the first time). This should solve https://bugzilla.redhat.com/show_bug.cgi?id=728478Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Acked-by:
Mattia Dongili <malattia@linux.it> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit b49960a0 ] tcp_adv_win_scale default value is 2, meaning we expect a good citizen skb to have skb->len / skb->truesize ratio of 75% (3/4) In 2.6 kernels we (mis)accounted for typical MSS=1460 frame : 1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392. So these skbs were considered as not bloated. With recent truesize fixes, a typical MSS=1460 frame truesize is now the more precise : 2048 + 256 = 2304. But 2304 * 3/4 = 1728. So these skb are not good citizen anymore, because 1460 < 1728 (GRO can escape this problem because it build skbs with a too low truesize.) This also means tcp advertises a too optimistic window for a given allocated rcvspace : When receiving frames, sk_rmem_alloc can hit sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often, especially when application is slow to drain its receive queue or in case of losses (netperf is fast, scp is slow). This is a major latency source. We should adjust the len/truesize ratio to 50% instead of 75% This patch : 1) changes tcp_adv_win_scale default to 1 instead of 2 2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account better truesize tracking and to allow autotuning tcp receive window to reach same value than before. Note that same amount of kernel memory is consumed compared to 2.6 kernels. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Gerard Lledo authored
[ Upstream commit 5a8887d3 ] WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5). gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting gp->wake_on_lan to bool. Tested on an iBook G4. Signed-off-by:
Gerard Lledo <gerard.lledo@gmail.com> Signed-off-by:
-
Matt Carlson authored
[ Upstream commit f891ea16 ] When RSS is enabled, interrupt vector 0 does not receive any rx traffic. The rx producer index fields for vector 0's status block should be considered reserved in this case. This patch changes the code to respect these reserved fields, which avoids a kernel panic when these fields take on non-zero values. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit e072b3fa ] Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older supported chips. Sometimes the VLAN bit is not set for valid VLAN packets and also sometimes the VLAN bit is set for non-VLAN packets that came after a VLAN packet. This results in a receive length error when VLAN hardware tagging is enabled. Fix: Variation on original fix proposed by Mirko. The VLAN information is decoded in the status loop, and can be applied to the received SKB there. This eliminates the need for the separate tag field in the interface data structure. The tag has to be copied and cleared if packet is copied. This version checked out with vlan and normal traffic. Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that is outside scope of this. Reported-by:
Mirko Lindner <mlindner@marvell.com> Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit 3f42941b ] When a small packet is received, the driver copies it to a new skb to allow reusing the full size Rx buffer. The copy was propogating the checksum offload but not the receive hash information. The bug is impact was mostly harmless and therefore not observed until reviewing this area of code. Signed-off-by:
-
Sasha Levin authored
[ Upstream commit 84768edb ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270f ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Acked-by:
-
Eric W. Biederman authored
[ Upstream commit 7d3d43da ] We already synthesize events in register_netdevice_notifier and synthesizing events in unregister_netdevice_notifier allows to us remove the need for special case cleanup code. This change should be safe as it adds no new cases for existing callers of unregiser_netdevice_notifier to handle. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 116a0fc3 ] skb_checksum_help(skb) can return an error, we must free skb in this case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if skb_unshare() failed), so lets use this generic helper. Signed-off-by:
-
Ingo van Lil authored
[ Upstream commit 2a580949 ] The asix.c USB Ethernet driver avoids ending a tx transfer with a zero- length packet by appending a four-byte padding to transfers whose length is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket length is valid for high-speed USB only; full-speed USB uses 64 byte packets. Signed-off-by:
Ingo van Lil <inguin@gmx.de> Signed-off-by:
-
Ben Hutchings authored
commit 48d99f47 upstream. Commit 554cdaef ('ARM: orion5x: Refactor mpp code to use common orion platform mpp.') seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error: [ 12.711476] leds-gpio: probe of leds-gpio failed with error -22 Reported-by:
Henry von Tresckow <hvontres@gmail.com> References: http://bugs.debian.org/667446Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Tested-by:
-
Axel Lin authored
commit f55205f4 upstream. I think this is a typo. To ensure new voltage setting won't greater than desc->max, the equation should be desc->min + desc->step * new_val <= desc->max. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Colin Cross authored
commit fde165b2 upstream. Commit 4e8ee7de (ARM: SMP: use idmap_pgd for mapping MMU enable during secondary booting) switched secondary boot to use idmap_pgd, which is initialized during early_initcall, instead of a page table initialized during __cpu_up. This causes idmap_pgd to contain the static mappings but be missing all dynamic mappings. If a console is registered that creates a dynamic mapping, the printk in secondary_start_kernel will trigger a data abort on the missing mapping before the exception handlers have been initialized, leading to a hang. Initial boot is not affected because no consoles have been registered, and resume is usually not affected because the offending console is suspended. Onlining a cpu with hotplug triggers the problem. A workaround is to the printk in secondary_start_kernel until after the page tables have been switched back to init_mm. Signed-off-by:
Colin Cross <ccross@android.com> Signed-off-by:
-
Tim Bird authored
commit e787ec13 upstream. The inline assembly in kernel_execve() uses r8 and r9. Since this code sequence does not return, it usually doesn't matter if the register clobber list is accurate. However, I saw a case where a particular version of gcc used r8 as an intermediate for the value eventually passed to r9. Because r8 is used in the inline assembly, and not mentioned in the clobber list, r9 was set to an incorrect value. This resulted in a kernel panic on execution of the first user-space program in the system. r9 is used in ret_to_user as the thread_info pointer, and if it's wrong, bad things happen. Signed-off-by:
Tim Bird <tim.bird@am.sony.com> Signed-off-by:
-
Linus Torvalds authored
commit 2f624278 upstream. We really need to use a ACCESS_ONCE() on the sequence value read in __read_seqcount_begin(), because otherwise the compiler might end up reloading the value in between the test and the return of it. As a result, it might end up returning an odd value (which means that a write is in progress). If the reader is then fast enough that that odd value is still the current one when the read_seqcount_retry() is done, we might end up with a "successful" read sequence, even despite the concurrent write being active. In practice this probably never really happens - there just isn't anything else going on around the read of the sequence count, and the common case is that we end up having a read barrier immediately afterwards. So the code sequence in which gcc might decide to reaload from memory is small, and there's no reason to believe it would ever actually do the reload. But if the compiler ever were to decide to do so, it would be incredibly annoying to debug. Let's just make sure. Signed-off-by:
-
H. Peter Anvin authored
commit f5c2347e upstream. <asm-generic/statfs.h> is exported to userspace, so using BITS_PER_LONG is invalid. We need to use __BITS_PER_LONG instead. This is kernel bugzilla 43165. Reported-by:
H.J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/1335465916-16965-1-git-send-email-hpa@linux.intel.comAcked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Tejun Heo authored
commit d5e28005 upstream. With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE or PMD_SIZE for atom_size. PMD_SIZE is used when CPU supports PSE so that percpu areas are aligned to PMD mappings and possibly allow using PMD mappings in vmalloc areas in the future. Using larger atom_size doesn't waste actual memory; however, it does require larger vmalloc space allocation later on for !first chunks. With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem but x86_32 at this point is anything but reasonable in terms of address space and using larger atom_size reportedly leads to frequent percpu allocation failures on certain setups. As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space is aplenty and most x86_64 configurations support PSE, fix the issue by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32. v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and x86_32 PAGE_SIZE as suggested by hpa. Signed-off-by:
Yanmin Zhang <yanmin.zhang@intel.com> Reported-by:
ShuoX Liu <shuox.liu@intel.com> Acked-by:
H. Peter Anvin <hpa@zytor.com> LKML-Reference: <4F97BA98.6010001@intel.com> Signed-off-by:
-
David Vrabel authored
commit 76a8df7b upstream. The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. Acked-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> [v1: Fixed compile error when CONFIG_PCI is not set] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit b7e5ffe5 upstream. If I try to do "cat /sys/kernel/debug/kernel_page_tables" I end up with: BUG: unable to handle kernel paging request at ffffc7fffffff000 IP: [<ffffffff8106aa51>] ptdump_show+0x221/0x480 PGD 0 Oops: 0000 [#1] SMP CPU 0 .. snip.. RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000 RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000 which is due to the fact we are trying to access a PFN that is not accessible to us. The reason (at least in this case) was that PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the hypervisor) to point to a read-only linear map of the MFN->PFN array. During our parsing we would get the MFN (a valid one), try to look it up in the MFN->PFN tree and find it invalid and return ~0 as PFN. Then pte_mfn_to_pfn would happilly feed that in, attach the flags and return it back to the caller. 'ptdump_show' bitshifts it and gets and invalid value that it tries to dereference. Instead of doing all of that, we detect the ~0 case and just return !_PAGE_PRESENT. This bug has been in existence .. at least until 2.6.37 (yikes!) Signed-off-by:
-
Paolo Pisati authored
commit 07d69d42 upstream. Without this patch sysfs reports the cable as present flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier 1 while it's not: flag@flag-desktop:~$ sudo mii-tool eth0 eth0: no link Tested on my Beagle XM. v2: added mantainer to the list of recipient Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by:
-
- 07 May, 2012 5 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
commit 6f24f892 upstream. Commit ec81aecb ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by:
Timo Warns <warns@pre-sense.de> Acked-by:
WANG Cong <amwang@redhat.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Sage Weil <sage@newdream.net> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Peter Zijlstra authored
commit c308b56b upstream. [ backported to 3.0 by Kerin Millar <kerframil@gmail.com>] Various people reported nohz load tracking still being wrecked, but Doug spotted the actual problem. We fold the nohz remainder in too soon, causing us to loose samples and under-account. So instead of playing catch-up up-front, always do a single load-fold with whatever state we encounter and only then fold the nohz remainder and play catch-up. Reported-by:
Doug Smythies <dsmythies@telus.net> Reported-by:
LesÅ=82aw Kope=C4=87 <leslaw.kopec@nasza-klasa.pl> Reported-by:
Aman Gupta <aman@tmm1.net> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Kerin Millar <kerframil@gmail.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 4c1bcdb5 upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 328c32f0 upstream. Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Signed-off-by:
-
