- 18 Jan, 2010 1 commit
-
-
Al Viro authored
This backports the following upstream commits all as one patch: 54f5de70 ecc1a899 1a0ef85f f106af4e 097eed10 93587414 0ec62d29 c4caa778 2ea1d13f 570dcf2c 564b3bff 0067bd8a f8b72560 8c7b49b3 9206de95 2c6a1016 05d72faa bb52d669 e77414e0 aa656073 Backport done by Greg Kroah-Hartman. Only minor tweaks were needed. Cc: David S. Miller <davem@davemloft.net> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 06 Jan, 2010 39 commits
-
-
Greg Kroah-Hartman authored
-
Serge E. Hallyn authored
commit 7ea66001 upstream. generic_permission was refusing CAP_DAC_READ_SEARCH-enabled processes from opening DAC-protected files read-only, because do_filp_open adds MAY_OPEN to the open mask. Ignore MAY_OPEN. After this patch, CAP_DAC_READ_SEARCH is again sufficient to open(fname, O_RDONLY) on a file to which DAC otherwise refuses us read permission. Reported-by:
Mike Kazantsev <mk.fraggod@gmail.com> Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Gertjan van Wingerde authored
commit 93b6bd26 upstream. We've had many reports of rt61pci failures with powersaving enabled. Therefore, as a stop-gap measure, disable powersaving of the rt61pci until we have found a proper solution. Also disable powersaving on rt2800pci as it most probably will show the same problem. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Hugh Dickins authored
2.6.33-rc1 commit 73848b46, adjusted to include 31e855ea's movement of the unlock_page(oldpage), but omit other intervening cleanups. When KSM merges an mlocked page, it has been forgetting to munlock it: that's been left to free_page_mlock(), which reports it in /proc/vmstat as unevictable_pgs_mlockfreed instead of unevictable_pgs_munlocked, which indicates that such pages _might_ be left unevictable for long after they should be evictable. Call munlock_vma_page() to fix that. Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
-
Rik van Riel authored
commit b39415b2 upstream. In AIM7 runs, recent kernels start swapping out anonymous pages well before they should. This is due to shrink_list falling through to shrink_inactive_list if !inactive_anon_is_low(zone, sc), when all we really wanted to do is pre-age some anonymous pages to give them extra time to be referenced while on the inactive list. The obvious fix is to make sure that shrink_list does not fall through to scanning/reclaiming inactive pages when we called it to scan one of the active lists. This change should be safe because the loop in shrink_zone ensures that we will still shrink the anon and file inactive lists whenever we should. [kosaki.motohiro@jp.fujitsu.com: inactive_file_is_low() should be inactive_anon_is_low()] Reported-by:
Larry Woodman <lwoodman@redhat.com> Signed-off-by:
Rik van Riel <riel@redhat.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Tomasz Chmielewski <mangoo@wpkg.org> Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Rusty Russell authored
commit 3e27249c upstream. We kill the guest, but then we blatt random stuff. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Fang Wenqi authored
commit 6d3b82f2 upstream. Per commit 240799cd, the option name for readahead should be inode_readahead_blks, not inode_readahead. Signed-off-by:
Fang Wenqi <antonf@turbolinux.com.cn> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Peter Zijlstra authored
commit 047106ad upstream. Heiko reported a case where a timer interrupt managed to reference a root_domain structure that was already freed by a concurrent hot-un-plug operation. Solve this like the regular sched_domain stuff is also synchronized, by adding a synchronize_sched() stmt to the free path, this ensures that a root_domain stays present for any atomic section that could have observed it. Reported-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Borislav Petkov authored
commit 43f5e687 upstream. Clear the override flag after force-loading the module. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
-
Borislav Petkov authored
commit 56b34b91 upstream. Currently, the module does not initialize fully when the DIMMs aren't ECC but remains still loaded. Propagate the error when no instance of the driver is properly initialized and prevent further loading. Reorganize and polish error handling in amd64_edac_init() while at it. Signed-off-by:
-
Borislav Petkov authored
commit 8f68ed97 upstream. Fix use-after-free errors by pushing all memory-freeing calls to the end of amd64_remove_one_instance(). Reported-by:
Darren Jenkins <darrenrjenkins@gmail.com> LKML-Reference: <1261370306.11354.52.camel@ICE-BOX> Signed-off-by:
-
Borislav Petkov authored
commit 6ede31e0 upstream. Randy Dunlap reported the following build error: "When CONFIG_SMP=n, CONFIG_X86_MSR=m: ERROR: "msrs_free" [drivers/edac/amd64_edac_mod.ko] undefined! ERROR: "msrs_alloc" [drivers/edac/amd64_edac_mod.ko] undefined!" This is due to the fact that <arch/x86/lib/msr.c> is conditioned on CONFIG_SMP and in the UP case we have only the stubs in the header. Fork off SMP functionality into a new file (msr-smp.c) and build msrs_{alloc,free} unconditionally. Reported-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Borislav Petkov <petkovbb@gmail.com> LKML-Reference: <20091216231625.GD27228@liondog.tnic> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Borislav Petkov authored
commit 50542251 upstream. The current rd/wrmsr_on_cpus helpers assume that the supplied cpumasks are contiguous. However, there are machines out there like some K8 multinode Opterons which have a non-contiguous core enumeration on each node (e.g. cores 0,2 on node 0 instead of 0,1), see http://www.gossamer-threads.com/lists/linux/kernel/1160268. This patch fixes out-of-bounds writes (see URL above) by adding per-CPU msr structs which are used on the respective cores. Additionally, two helpers, msrs_{alloc,free}, are provided for use by the callers of the MSR accessors. Cc: H. Peter Anvin <hpa@zytor.com> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Aristeu Rozanski <aris@redhat.com> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
Borislav Petkov authored
commit f6d6ae96 upstream. Unify almost identical code into one function and remove NUMA-specific usage (specifically cpumask_of_node()) in favor of generic topology methods. Remove unused defines, while at it. Signed-off-by:
-
Rusty Russell authored
commit ba578cb3 upstream. cpumask_t -> struct cpumask, and don't put one on the stack. (Note: this is actually on the stack unless CONFIG_CPUMASK_OFFSTACK=y). Signed-off-by:
-
Borislav Petkov authored
commit b8a47541 upstream. Since rdmsr_on_cpus and wrmsr_on_cpus are almost identical, unify them into a common __rwmsr_on_cpus helper thus avoiding code duplication. While at it, convert cpumask_t's to const struct cpumask *. Signed-off-by:
-
Dmitry Monakhov authored
commit 39bc680a upstream. Unlock i_block_reservation_lock before vfs_dq_reserve_block(). This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=14739 Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Dmitry Monakhov authored
commit a9e7f447 upstream. This patch also fixes write vs chown race condition. Acked-by:
-
Dmitry Monakhov authored
commit fd8fbfc1 upstream. Currently inode_reservation is managed by fs itself and this reservation is transfered on dquot_transfer(). This means what inode_reservation must always be in sync with dquot->dq_dqb.dqb_rsvspace. Otherwise dquot_transfer() will result in incorrect quota(WARN_ON in dquot_claim_reserved_space() will be triggered) This is not easy because of complex locking order issues for example http://bugzilla.kernel.org/show_bug.cgi?id=14739 The patch introduce quota reservation field for each fs-inode (fs specific inode is used in order to prevent bloating generic vfs inode). This reservation is managed by quota code internally similar to i_blocks/i_bytes and may not be always in sync with internal fs reservation. Also perform some code rearrangement: - Unify dquot_reserve_space() and dquot_reserve_space() - Unify dquot_release_reserved_space() and dquot_free_space() - Also this patch add missing warning update to release_rsv() dquot_release_reserved_space() must call flush_warnings() as dquot_free_space() does. Signed-off-by:
-
Dmitry Monakhov authored
commit b462707e upstream. Quota code requires unlocked version of this function. Off course we can just copy-paste the code, but copy-pasting is always an evil. Signed-off-by:
-
Jan Kara authored
commit e971b0b9 upstream. Some disks do not contain VAT inode in the last recorded block as required by the standard but a few blocks earlier (or the number of recorded blocks is wrong). So look for the VAT inode a bit before the end of the media. Signed-off-by:
-
Andrey Borzenkov authored
commit 5b069150 upstream. orinoco_set_key is called from two places both with interrupts disabled (under orinoco_lock). Use GFP_ATOMIC instead of GFP_KERNEL. Fixes following warning: [ 77.254109] WARNING: at /home/bor/src/linux-git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x9a/0xa0() [ 77.254109] Hardware name: PORTEGE 4000 [ 77.254109] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod loop nvram toshiba cryptomgr aead pcompress crypto_blkcipher michael_mic crypto_hash crypto_algapi orinoco_cs orinoco cfg80211 smsc_ircc2 pcmcia irda toshiba_acpi yenta_socket video i2c_ali1535 backlight rsrc_nonstatic ali_agp pcmcia_core psmouse output crc_ccitt i2c_core alim1535_wdt rfkill sg evdev ohci_hcd agpgart usbcore pata_ali libata reiserfs [last unloaded: scsi_wait_scan] [ 77.254109] Pid: 2296, comm: wpa_supplicant Not tainted 2.6.32-1avb #1 [ 77.254109] Call Trace: [ 77.254109] [<c011f0ad>] warn_slowpath_common+0x6d/0xa0 [ 77.254109] [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0 [ 77.254109] [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0 [ 77.254109] [<c011f0f5>] warn_slowpath_null+0x15/0x20 [ 77.254109] [<c014206a>] lockdep_trace_alloc+0x9a/0xa0 [ 77.254109] [<c018d296>] __kmalloc+0x36/0x130 [ 77.254109] [<dffcb6a8>] ? orinoco_set_key+0x48/0x1c0 [orinoco] [ 77.254109] [<dffcb6a8>] orinoco_set_key+0x48/0x1c0 [orinoco] [ 77.254109] [<dffcb9fc>] orinoco_ioctl_set_encodeext+0x1dc/0x2d0 [orinoco] [ 77.254109] [<c035b117>] ioctl_standard_call+0x207/0x3b0 [ 77.254109] [<dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco] [ 77.254109] [<c0307f1f>] ? rtnl_lock+0xf/0x20 [ 77.254109] [<c0307f1f>] ? rtnl_lock+0xf/0x20 [ 77.254109] [<c02fb115>] ? __dev_get_by_name+0x85/0xb0 [ 77.254109] [<c035b616>] wext_handle_ioctl+0x176/0x200 [ 77.254109] [<dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco] [ 77.254109] [<c030020f>] dev_ioctl+0x6af/0x730 [ 77.254109] [<c02eec65>] ? move_addr_to_kernel+0x55/0x60 [ 77.254109] [<c02eed59>] ? sys_sendto+0xe9/0x130 [ 77.254109] [<c02ed77e>] sock_ioctl+0x7e/0x250 [ 77.254109] [<c02ed700>] ? sock_ioctl+0x0/0x250 [ 77.254109] [<c019cf4c>] vfs_ioctl+0x1c/0x70 [ 77.254109] [<c019d1fa>] do_vfs_ioctl+0x6a/0x590 [ 77.254109] [<c0178e50>] ? might_fault+0x90/0xa0 [ 77.254109] [<c0178e0a>] ? might_fault+0x4a/0xa0 [ 77.254109] [<c02ef90e>] ? sys_socketcall+0x17e/0x280 [ 77.254109] [<c019d759>] sys_ioctl+0x39/0x60 [ 77.254109] [<c0102e3b>] sysenter_do_call+0x12/0x32 [ 77.254109] ---[ end trace 95ef563548d21efd ]--- Signed-off-by:
Andrey Borzenkov <arvidjaar@mail.ru> Signed-off-by:
-
Paolo Bonzini authored
commit ae788801 upstream. Increases the device timeout from 10s to 5 minutes, giving the user a visual indication during that time in case there are problems. The patch is a backport of changesets 144 and 150 in the Xenbits tree. Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Paolo Bonzini authored
commit f8dc3308 upstream. When printing a warning about a timed-out device, print the current state of both ends of the device connection (i.e., backend as well as frontend). This backports half of changeset 146 from the Xenbits tree. Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Paolo Bonzini authored
commit c6e19711 upstream. The logic of is_disconnected_device/exists_disconnected_device is wrong in that they are used to test whether a device is trying to connect (i.e. connecting). For this reason the patch fixes them to not consider a Closing or Closed device to be connecting. At the same time the patch also renames the functions according to what they really do; you could say a closed device is "disconnected" (the old name), but not "connecting" (the new name). This patch is a backport of changeset 909 from the Xenbits tree. Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Stefan Weinhuber authored
commit 22825ab7 upstream. When a DASD device is used with the DIAG discipline, the DIAG initialization will indicate success or error with a respective return code. So far we have interpreted a return code of 4 as error, but it actually means that the initialization was successful, but the device is read-only. To allow read-only devices to be used with DIAG we need to accept a return code of 4 as success. Re-initialization of the DIAG access is also part of the DIAG error recovery. If we find that the access mode of a device has been changed from writable to read-only while the device was in use, we print an error message. Signed-off-by:
Stefan Weinhuber <wein@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Stephen Powell <zlinuxman@wowway.com> Signed-off-by:
-
Zhao Yakui authored
commit b16d9acb upstream. Sometimes we will use a crtc for integerated LVDS, which is different with that assigned by BIOS. If we want to get flicker-free transitions, then we could read out the current state for it and set our current state accordingly. But it is true that if we aren't reading current state out, we do need to turn everything off before modesetting. Otherwise the clocks can get very angry and we get things worse than a flicker at boot. In fact we also do the similar thing in UMS mode. We will disable all the possible outputs/crtcs for the first modesetting. So we disable all the possible outputs/crtcs before entering the KMS mode. Before we configure connector/encoder/crtc, the function of drm_helper_disable_unused_function can disable all the possible outputs/crtcs. Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Rafal Milecki <zajec5@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
In 2.6.32.2 r600 had no IRQ support, however the patch in 500b7587 to fix vblanks on avivo cards, needs irqs. So check for an R600 card and avoid this path if so. This is a stable only patch for 2.6.32.2 as 2.6.33 has IRQs for r600. Signed-off-by:
-
Peter Zijlstra authored
commit 6ad4c188 upstream. Since (e761b772: cpu hotplug, sched: Introduce cpu_active_map and redo sched domain managment) we have cpu_active_mask which is suppose to rule scheduler migration and load-balancing, except it never (fully) did. The particular problem being solved here is a crash in try_to_wake_up() where select_task_rq() ends up selecting an offline cpu because select_task_rq_fair() trusts the sched_domain tree to reflect the current state of affairs, similarly select_task_rq_rt() trusts the root_domain. However, the sched_domains are updated from CPU_DEAD, which is after the cpu is taken offline and after stop_machine is done. Therefore it can race perfectly well with code assuming the domains are right. Cure this by building the domains from cpu_active_mask on CPU_DOWN_PREPARE. Signed-off-by:
-
Geert Uytterhoeven authored
commit a00ae4d2 upstream. As of commit ee18d64c ("KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]"), CONFIG_KEYS=y fails to build on architectures that haven't implemented TIF_NOTIFY_RESUME yet: security/keys/keyctl.c: In function 'keyctl_session_to_parent': security/keys/keyctl.c:1312: error: 'TIF_NOTIFY_RESUME' undeclared (first use in this function) security/keys/keyctl.c:1312: error: (Each undeclared identifier is reported only once security/keys/keyctl.c:1312: error: for each function it appears in.) Make KEYCTL_SESSION_TO_PARENT depend on TIF_NOTIFY_RESUME until m68k, and xtensa have implemented it. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
James Morris <jmorris@namei.org> Acked-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Larry Finger authored
commit c2ff581a upstream. The routine b43_is_hw_radio_enabled() has long been a problem. For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status() returns a value of 2 (B43_STAT_STARTED) (BUG 14181). Fixing that results in Bug 14538 in which the driver is unable to reassociate after resuming from hibernation because b43_status() returns 0. The correct fix would be to determine why the status is 0; however, I have not yet found why that happens. The correct value is found for my device, which has PHY revision >= 3. Returning TRUE when the PHY revision < 3 and b43_status() returns 0 fixes the regression for 2.6.32. This patch fixes the problem in Red Hat Bugzilla #538523. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by:
Christian Casteyde <casteyde.christian@free.fr> Signed-off-by:
-
Jonathan Cameron authored
commit 4235f684 upstream. Fix an off-by-one error in array index + incorrect constants. Signed-off-by:
Christoph Walser <walser@tik.ee.ethz.ch> Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Patrick McHardy authored
commit 8fa9ff68 upstream. When fragments from bridge netfilter are passed to IPv4 or IPv6 conntrack and a reassembly queue with the same fragment key already exists from reassembling a similar packet received on a different device (f.i. with multicasted fragments), the reassembled packet might continue on a different codepath than where the head fragment originated. This can cause crashes in bridge netfilter when a fragment received on a non-bridge device (and thus with skb->nf_bridge == NULL) continues through the bridge netfilter code. Add a new reassembly identifier for packets originating from bridge netfilter and use it to put those packets in insolated queues. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14805Reported-and-Tested-by:
Chong Qiao <qiaochong@loongson.cn> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Patrick McHardy authored
commit 0b5ccb2e upstream. Currently the same reassembly queue might be used for packets reassembled by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT), as well as local delivery. This can cause "packet jumps" when the fragment completing a reassembled packet is queued from a different position in the stack than the previous ones. Add a "user" identifier to the reassembly queue key to seperate the queues of each caller, similar to what we do for IPv4. Signed-off-by:
-
Roger Oksanen authored
commit 70abc8cb upstream. Alan Stern noticed that e100 caused slab corruption. commit 98468efd changed the allocation of cbs to use dma pools that don't return zeroed memory, especially the cb->status field used to track which cb to clean, causing (the visible) double freeing of skbs and a wrong free cbs count. Now the cbs are explicitly zeroed at allocation time. Reported-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Roger Oksanen <roger.oksanen@cs.helsinki.fi> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Daisuke Nishimura authored
commit d31f56db upstream. task_in_mem_cgroup(), which is called by select_bad_process() to check whether a task can be a candidate for being oom-killed from memcg's limit, checks "curr->use_hierarchy"("curr" is the mem_cgroup the task belongs to). But this check return true(it's false positive) when: <some path>/aa use_hierarchy == 0 <- hitting limit <some path>/aa/00 use_hierarchy == 1 <- the task belongs to This leads to killing an innocent task in aa/00. This patch is a fix for this bug. And this patch also fixes the arg for mem_cgroup_print_oom_info(). We should print information of mem_cgroup which the task being killed, not current, belongs to. Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by:
Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
-
Linus Torvalds authored
commit 04a1e62c upstream. The loop condition is fragile: we compare an unsigned value to zero, and then decrement it by something larger than one in the loop. All the callers should be passing in appropriately aligned buffer lengths, but it's better to just not rely on it, and have some appropriate defensive loop limits. Acked-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Dan Carpenter authored
commit 50e9d311 upstream. This was found with a static checker and has not been tested, but it seems pretty clear that the mutex_lock() was supposed to be mutex_unlock() Signed-off-by:
Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Brandon Philips <brandon@ifup.org> Signed-off-by:
-
WANG Cong authored
commit 3e26120c upstream. It is a mistake that we used 'proc_dointvec', it should be 'proc_dointvec_minmax', as in the original patch. Signed-off-by:
WANG Cong <amwang@redhat.com> Signed-off-by:
-
