- 09 Feb, 2010 40 commits
-
-
Uwe Kleine-König authored
commit 1ec56203 upstream. The probe function passes a pointer to a struct fb_info to platform_set_drvdata(), so don't interpret the return value of platform_get_drvdata() as a pointer to struct imxfb_info. The original imxfb_info *fbi backlight_power was NULL but in imxfb_suspend it was 4 resulting in an oops as imxfb_suspend calls imxfb_disable_controller(fbi) which in turn has if (fbi->backlight_power) fbi->backlight_power(0); Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Sascha Hauer <kernel@pengutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zhu Yi authored
commit 3092ad05 upstream. I got below kernel oops when I try to bring down the network interface if ftrace is enabled. The root cause is drv_ampdu_action() is passed with a NULL ssn pointer in the BA session tear down case. We need to check and avoid dereferencing it in trace entry assignment. BUG: unable to handle kernel NULL pointer dereference Modules linked in: at (null) IP: [<f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211] *pde = 00000000 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [...] Call Trace: [<f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211] [<f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211] [<f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211] [<f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211] [<f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211] [<f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211] [<f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211] [<f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211] [<f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211] Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
anfei zhou authored
commit 931e80e4 upstream. The cache alias problem will happen if the changes of user shared mapping is not flushed before copying, then user and kernel mapping may be mapped into two different cache line, it is impossible to guarantee the coherence after iov_iter_copy_from_user_atomic. So the right steps should be: flush_dcache_page(page); kmap_atomic(page); write to page; kunmap_atomic(page); flush_dcache_page(page); More precisely, we might create two new APIs flush_dcache_user_page and flush_dcache_kern_page to replace the two flush_dcache_page accordingly. Here is a snippet tested on omap2430 with VIPT cache, and I think it is not ARM-specific: int val = 0x11111111; fd = open("abc", O_RDWR); addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); *(addr+0) = 0x44444444; tmp = *(addr+0); *(addr+1) = 0x77777777; write(fd, &val, sizeof(int)); close(fd); The results are not always 0x11111111 0x77777777 at the beginning as expected. Sometimes we see 0x44444444 0x77777777. Signed-off-by:
Anfei <anfei.zhou@gmail.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: <linux-arch@vger.kernel.org> Signed-off-by:
-
David S. Miller authored
commit d291b9af upstream. Noticed by Ben Hutchings. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ajit Khaparde authored
commit 7b139c83 upstream. Bug fix in be2net for newer generation of BladeEngine ASIC. Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
-
Evgeniy Polyakov authored
commit f98bfbd7 upstream. On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote: > > There are at least two ways to fix it: using a big cannon and a small > > one. The former way is to disable notification registration, since it is > > not used by anyone at all. Second way is to check whether calling > > process is root and its destination group is -1 (kind of priveledged > > one) before command is dispatched to workqueue. > > Well if no one is using it, removing it makes the most sense, right? > > No objection from me, care to make up a patch either way for this? Getting it is not used, let's drop support for notifications about (un)registered events from connector. Another option was to check credentials on receiving, but we can always restore it without bugs if needed, but genetlink has a wider code base and none complained, that userspace can not get notification when some other clients were (un)registered. Kudos for Sebastian Krahmer <krahmer@suse.de>, who found a bug in the code. Signed-off-by:
Evgeniy Polyakov <zbr@ioremap.net> Acked-by:
-
Magnus Damm authored
commit e5ff15be upstream. This patch improves disable_controller() in the r8a66597-hdc driver to disable all interrupts and clear status flags. It also makes sure that disable_controller() is called during probe(). This fixes the relatively rare case of unexpected pending interrupts after kexec reboot. Signed-off-by:
Magnus Damm <damm@opensource.se> Acked-by:
Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Chuck Ebbert authored
commit 9e9432c2 upstream. Fix two bugs in the bio integrity code: use_bip_pool() always returns 0 because it checks against the wrong limit, causing the mempool to be used only when regular allocation fails. When the mempool is used as a fallback we don't free the data properly. Signed-Off-By:
Chuck Ebbert <cebbert@redhat.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Herbert Xu authored
commit cd1510cb upstream. The previous changeset left behind an unused inode variable. This patch removes it. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Matt Mackall authored
commit a996996d upstream. No other driver does anything remotely like this that I know of except for the tty drivers, and I can't see any reason for random/urandom to do it. In fact, it's a (trivial, harmless) timing information leak. And obviously, it generates power- and flash-cycle wasting I/O, especially if combined with something like hwrngd. Also, it breaks ubifs's expectations. Signed-off-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Linus Torvalds authored
commit 7ab02af4 upstream. Commit 221af7f8 ("Split 'flush_old_exec' into two functions") split the function at the point of no return - ie right where there were no more error cases to check. That made sense from a technical standpoint, but when we then also combined it with the actual personality setting going in between flush_old_exec() and setup_new_exec(), it needs to be a bit more careful. In particular, we need to make sure that we really flush the old personality bits in the 'flush' stage, rather than later in the 'setup' stage, since otherwise we might be flushing the _new_ personality state that we're just setting up. So this moves the flags and personality flushing (and 'flush_thread()', which is the arch-specific function that generally resets lazy FP state etc) of the old process into flush_old_exec(), so that it doesn't affect any state that execve() is setting up for the new process environment. This was reported by Michal Simek as breaking his Microblaze qemu environment. Reported-and-tested-by:
Michal Simek <michal.simek@petalogix.com> Cc: Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Dmitry Monakhov authored
commit 1d616585 upstream. We have to properly decrease bi_size in order to merge_bvec_fn return right result. Otherwise this result in false merge rejects for two absolutely valid bio_vecs. This may cause significant performance penalty for example fs_block_size == 1k and block device is raid0 with small chunk_size = 8k. Then it is impossible to merge 7-th fs-block in to bio which already has 6 fs-blocks. Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Nick Piggin authored
commit 02b709df upstream. Improve handling of fragmented per-CPU vmaps. We previously don't free up per-CPU maps until all its addresses have been used and freed. So fragmented blocks could fill up vmalloc space even if they actually had no active vmap regions within them. Add some logic to allow all CPUs to have these blocks purged in the case of failure to allocate a new vm area, and also put some logic to trim such blocks of a current CPU if we hit them in the allocation path (so as to avoid a large build up of them). Christoph reported some vmap allocation failures when using the per CPU vmap APIs in XFS, which cannot be reproduced after this patch and the previous bug fix. Cc: linux-mm@kvack.org Tested-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Nick Piggin authored
commit de560423 upstream. RCU list walking of the per-cpu vmap cache was broken. It did not use RCU primitives, and also the union of free_list and rcu_head is obviously wrong (because free_list is indeed the list we are RCU walking). While we are there, remove a couple of unused fields from an earlier iteration. These APIs aren't actually used anywhere, because of problems with the XFS conversion. Christoph has now verified that the problems are solved with these patches. Also it is an exported interface, so I think it will be good to be merged now (and Christoph wants to get the XFS changes into their local tree). Cc: linux-mm@kvack.org Tested-by:
-
Tejun Heo authored
commit 5040ab67 upstream. Interestingly, when SIDPR is used in ata_piix, writes to DET in SControl sometimes get ignored leading to detection failure. Update sata_link_resume() such that it reads back SControl after clearing DET and retry if it's not clear. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
fengxiangjun <fengxiangjun@neusoft.com> Reported-by:
Jim Faulkner <jfaulkne@ccs.neu.edu> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Suravee Suthikulpanit authored
commit d8cc108f upstream. With multiplexing enabled oprofile crashs when profiling more than 28 events. This patch fixes this. Signed-off-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Andi Kleen authored
commit e83e452b upstream. Add Xeon 7500 series support to oprofile. Straight forward: it's the same as Core i7, so just detect the model number. No user space changes needed. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Glauber Costa authored
(cherry picked from afbcf7ab) When we migrate a kvm guest that uses pvclock between two hosts, we may suffer a large skew. This is because there can be significant differences between the monotonic clock of the hosts involved. When a new host with a much larger monotonic time starts running the guest, the view of time will be significantly impacted. Situation is much worse when we do the opposite, and migrate to a host with a smaller monotonic clock. This proposed ioctl will allow userspace to inform us what is the monotonic clock value in the source host, so we can keep the time skew short, and more importantly, never goes backwards. Userspace may also need to trigger the current data, since from the first migration onwards, it won't be reflected by a simple call to clock_gettime() anymore. [marcelo: future-proof abi with a flags field] [jan: fix KVM_GET_CLOCK by clearing flags field instead of checking it] Signed-off-by:
Glauber Costa <glommer@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit d00c362f ] Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can cause timer oopses (first reported with 2.6.29.6 kernel). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905Reported-by:
Bernard Pidoux <bpidoux@free.fr> Tested-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit eb70df13 ] tpacket_snd() can change and kfree an skb after dev_queue_xmit(), which is illegal. With debugging by: Stephen Hemminger <shemminger@vyatta.com> Reported-by:
Michael Breuer <mbreuer@majjas.com> With help from: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jamal Hadi Salim authored
[ Upstream commit 28f6aeea ] when using policy routing and the skb mark: there are cases where a back path validation requires us to use a different routing table for src ip validation than the one used for mapping ingress dst ip. One such a case is transparent proxying where we pretend to be the destination system and therefore the local table is used for incoming packets but possibly a main table would be used on outbound. Make the default behavior to allow the above and if users need to turn on the symmetry via sysctl src_valid_mark Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit 9db2f1be ] During TX timeout procedure dev could be awoken too early, e.g. by sky2_complete_tx() called from sky2_down(). Then sky2_xmit_frame() can run while buffers are freed causing an oops. This patch fixes it by adding netif_device_present() test in sky2_tx_complete(). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14925 With debugging by: Mike McCormack <mikem@ring3k.org> Reported-by:
Berck E. Nash <flyboy@gmail.com> Tested-by:
-
Octavian Purdila authored
[ Upstream commit 704da560 ] This fixes a netstamp_needed accounting issue when the listen socket has SO_TIMESTAMP set: s = socket(AF_INET, SOCK_STREAM, 0); setsockopt(s, SOL_SOCKET, SO_TIMESTAMP, 1); -> netstamp_needed = 1 bind(s, ...); listen(s, ...); s2 = accept(s, ...); -> netstamp_needed = 1 close(s2); -> netstamp_needed = 0 close(s); -> netstamp_needed = -1 Signed-off-by:
Octavian Purdila <opurdila@ixiacom.com> Signed-off-by:
-
Aaro Koskinen authored
commit a362c638 upstream Commit a9238ce3 broke compilation on platforms that do not implement GENERIC_TIME (e.g. iop32x): kernel/time/clocksource.c: In function 'clocksource_register': kernel/time/clocksource.c:556: error: implicit declaration of function 'clocksource_max_deferment' Provide the implementation of clocksource_max_deferment() also for such platforms. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Joerg Roedel authored
commit d91afd15 upstream. The variable i in this function could be increased to over 2**32 which would result in an integer overflow when using int. Fix it by changing i to unsigned long. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
David Härdeman authored
commit 7c099ce1 upstream. Commit 6aa542a6 added a quirk for the Intel DG45ID board due to low memory corruption. The Intel DG45FC shares the same BIOS (and the same bug) as noted in: http://bugzilla.kernel.org/show_bug.cgi?id=13736Signed-off-by:
David Härdeman <david@hardeman.nu> LKML-Reference: <20100128200254.GA9134@hardeman.nu> Cc: Alexey Fisher <bug-track@fisher-privat.net> Cc: ykzhao <yakui.zhao@intel.com> Cc: Tony Bones <aabonesml@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Leann Ogasawara authored
commit 35ea63d7 upstream. Dell OptiPlex 760 hangs on reboot unless reboot=bios is used. Add quirk to reboot through the BIOS. BugLink: https://bugs.launchpad.net/bugs/488319Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> LKML-Reference: <1264634958.27335.1091.camel@emiko> Signed-off-by:
-
Mark Brown authored
commit a2fad9bf upstream. The WM8350 LED driver needs to be able to enable and disable the regulators it is using. Previously the core wasn't properly enforcing status change constraints so the driver was able to function but this has always been intended to be required. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Jiri Slaby authored
commit 17740d89 upstream. Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in selinux_bprm_committing_creds, since update_rlimit_cpu expects RLIMIT_CPU limit. Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Acked-by:
James Morris <jmorris@namei.org> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Eric Paris <eparis@parisplace.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Stefan Richter authored
Backport of commit e300839d upstream. Presently, firewire-core only checks whether descriptors that are to be added by userspace drivers to the local node's config ROM do not exceed a size of 256 quadlets. However, the sum of the bare minimum ROM plus all descriptors (from firewire-core, from firewire-net, from userspace) must not exceed 256 quadlets. Otherwise, the bounds of a statically allocated buffer will be overwritten. If the kernel survives that, firewire-core will subsequently be unable to parse the local node's config ROM. (Note, userspace drivers can add descriptors only through device files of local nodes. These are usually only accessible by root, unlike device files of remote nodes which may be accessible to lesser privileged users.) Therefore add a test which takes the actual present and required ROM size into account for all descriptors of kernelspace and userspace drivers. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Jesse Barnes authored
commit b01f2c3a upstream. This patch changes around our hotplug enable code a bit to only enable it for ports we actually detect and initialize. This prevents problems with stuck or spurious interrupts on outputs that aren't actually wired up, and is generally more correct. Fixes FDO bug #23183. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Wey-Yi Guy authored
commit 4d80d721 upstream. Multiple MPDUs can be aggregated, transmitted, and finally acknowledged together using a single BA frame. Block ACK (BA) contains bitmap size of 64*16 bits so the maximum frame count is 64. The default value of aggregation frame count suggested by uCode is 31 to achieve best performance. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Venkatesh Pallipadi authored
commit 73472a46 upstream HPET MSI on platforms with ATI SB700/SB800 as they seem to have some side-effects on floppy DMA. Do not use HPET MSI on such platforms. Original problem report from Mark Hounschell http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01118.htmlTested-by:
Mark Hounschell <markh@compro.net> Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: <stable@kernel.org> LKML-Reference: <20100121190952.GA32523@linux-os.sc.intel.com> Signed-off-by:
-
David Härdeman authored
commit 93fb84b5 upstream. I missed converting one dev_info call to deb_dbg before submitting the driver. Without this change, a message will be printed to dmesg for each button press if a RC6 remote is used. Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
H. Peter Anvin authored
commit 05d43ed8 upstream. Now that the previous commit made it possible to do the personality setting at the point of no return, we do just that for ELF binaries. And suddenly all the reasons for that insane TIF_ABI_PENDING bit go away, and we can just make SET_PERSONALITY() just do the obvious thing for a 32-bit compat process. Everything becomes much more straightforward this way. Signed-off-by:
-
David Miller authored
commit 94673e96 upstream. Here are the sparc bits to remove TIF_ABI_PENDING now that set_personality() is called at the appropriate place in exec. Signed-off-by:
-
Linus Torvalds authored
commit 221af7f8 upstream. 'flush_old_exec()' is the point of no return when doing an execve(), and it is pretty badly misnamed. It doesn't just flush the old executable environment, it also starts up the new one. Which is very inconvenient for things like setting up the new personality, because we want the new personality to affect the starting of the new environment, but at the same time we do _not_ want the new personality to take effect if flushing the old one fails. As a result, the x86-64 '32-bit' personality is actually done using this insane "I'm going to change the ABI, but I haven't done it yet" bit (TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the personality, but just the "pending" bit, so that "flush_thread()" can do the actual personality magic. This patch in no way changes any of that insanity, but it does split the 'flush_old_exec()' function up into a preparatory part that can fail (still called flush_old_exec()), and a new part that will actually set up the new exec environment (setup_new_exec()). All callers are changed to trivially comply with the new world order. Signed-off-by:
-
Mike Frysinger authored
commit 04e4f2b1 upstream. The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Hugh Dickins authored
commit a7016235 upstream. After memory pressure has forced it to dip into the reserves, 2.6.32's 5f8dcc21 "page-allocator: split per-cpu list into one-list-per-migrate-type" has been returning MIGRATE_RESERVE pages to the MIGRATE_MOVABLE free_list: in some sense depleting reserves. Fix that in the most straightforward way (which, considering the overheads of alternative approaches, is Mel's preference): the right migratetype is already in page_private(page), but free_pcppages_bulk() wasn't using it. How did this bug show up? As a 20% slowdown in my tmpfs loop kbuild swapping tests, on PowerMac G5 with SLUB allocator. Bisecting to that commit was easy, but explaining the magnitude of the slowdown not easy. The same effect appears, but much less markedly, with SLAB, and even less markedly on other machines (the PowerMac divides into fewer zones than x86, I think that may be a factor). We guess that lumpy reclaim of short-lived high-order pages is implicated in some way, and probably this bug has been tickling a poor decision somewhere in page reclaim. But instrumentation hasn't told me much, I've run out of time and imagination to determine exactly what's going on, and shouldn't hold up the fix any longer: it's valid, and might even fix other misbehaviours. Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Acked-by:
Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Al Viro authored
commit 12e9a456 upstream. deactivate_locked_super() will be done by caller of fill_super, doing it there as well is b0rken. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
