- 18 Jan, 2010 23 commits
-
-
Sascha Hauer authored
commit 7ee3aebe upstream. lib/rational.c:62: warning: data definition has no type or storage class lib/rational.c:62: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' lib/rational.c:62: warning: parameter names (without types) in function declaration Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Oskar Schirmer <os@emlix.com> 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>
-
Dave Anderson authored
commit bd4f490a upstream. The LTP cgroup test suite generates a "kernel BUG at kernel/cgroup.c:790!" here in cgroup_diput(): /* * if we're getting rid of the cgroup, refcount should ensure * that there are no pidlists left. */ BUG_ON(!list_empty(&cgrp->pidlists)); The cgroup pidlist rework in 2.6.32 generates the BUG_ON, which is caused when pidlist_array_load() calls cgroup_pidlist_find(): (1) if a matching cgroup_pidlist is found, it down_write's the mutex of the pre-existing cgroup_pidlist, and increments its use_count. (2) if no matching cgroup_pidlist is found, then a new one is allocated, it down_write's its mutex, and the use_count is set to 0. (3) the matching, or new, cgroup_pidlist gets returned back to pidlist_array_load(), which increments its use_count -- regardless whether new or pre-existing -- and up_write's the mutex. So if a matching list is ever encountered by cgroup_pidlist_find() during the life of a cgroup directory, it results in an inflated use_count value, preventing it from ever getting released by cgroup_release_pid_array(). Then if the directory is subsequently removed, cgroup_diput() hits the BUG_ON() when it finds that the directory's cgroup is still populated with a pidlist. The patch simply removes the use_count increment when a matching pidlist is found by cgroup_pidlist_find(), because it gets bumped by the calling pidlist_array_load() function while still protected by the list's mutex. Signed-off-by:
Dave Anderson <anderson@redhat.com> Reviewed-by:
Li Zefan <lizf@cn.fujitsu.com> Acked-by:
Ben Blum <bblum@andrew.cmu.edu> Cc: Paul Menage <menage@google.com> Signed-off-by:
-
Stephen Hemminger authored
commit 5787536e upstream. menu: use proper 64 bit math The new menu governor is incorrectly doing a 64 bit divide. Compile tested only Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Len Brown <len.brown@intel.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
-
OGAWA Hirofumi authored
commit 004731b2 upstream. commit abd6633c ("pnp: add a shutdown method to pnp drivers") adds shutdown method to bus driver blindly. With it, driver->shutdown is no longer valid. Use pnp_driver->shutdown instead. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14889Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by:
Malte Schröder <maltesch@gmx.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: David Hardeman <david@hardeman.nu> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Signed-off-by:
-
Andrew Morton authored
commit 29bd0ae2 upstream. drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load': drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function Partly this is because gcc isn't smart enough. But `ll_base' does get used uninitialised in the DRM_DEBUG() call. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Zhao Yakui authored
commit e5a95eb7 upstream. Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel, the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8. At the same time the BPC will be 8 when the output device is CRT/HDMI/DP. Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
-
Zhao Yakui authored
commit 8faf3b31 upstream. Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake. Signed-off-by:
-
Zhao Yakui authored
commit 898822ce upstream. Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x platform the dithering flag is defined in LVDS register. And on the ironlake the dithering flag is defined in pipeconf register. Signed-off-by:
-
Zhenyu Wang authored
commit e6be8d9d upstream. drm_pci_alloc() has input of address mask for setting pci dma mask on the device, which should be properly setup by drm driver. And leave it as a param for drm_pci_alloc() would cause confusion or mistake would corrupt the correct dma mask setting, as seen on intel hw which set wrong dma mask for hw status page. So remove it from drm_pci_alloc() function. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Chris Wilson authored
commit e3d8affb upstream. As pinning (allocating and binding GTT memory) does not actually invoke GPU commands, it is safe, and indeed is attempted, during resumption from suspension: [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
-
Daniel Vetter authored
commit 96b47b65 upstream. i915_gem_object_unbind had the ordering wrong. The other user, i915_gem_object_put_fence_reg already has the correct ordering. Results was usually corrupted pixmaps, especially garbled font glyphs after a suspend/resume (because this evicts everything). I'm still waiting for the feedback from the bug-reporters, but because this obviously fixes a bug (at least for me) I'm already submitting it. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25406Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Zhao Yakui authored
commit a2565377 upstream. Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after close/reopen the LID. And I also reproduce this issue on another laptop. After some tests and debug, it seems that it is related with that the LVDS status is not updated in time in course of suspend/resume. Now the LID state is used to check whether the LVDS is connected or disconnected. And when the LID is closed, it means that the LVDS is disconnected. When it is reopened, it means that the LVDS is connected. At the same time on some distributions the LID event is also used to put the system into suspend state. When the LID is closed, the system will enter the suspend state. When the LID is reopened, the system will be resumed. In such case when the LID is closed, user-space script will receive the LID notification event and detect the LVDS as disconnected. Then the system will enter the suspended state. When the LID is reopened, the system will be resumed. As the LVDS status is not updated in course of resume, it will cause that the LVDS connector is marked as unused and disabled. After the resume is finished,user-space script will try to configure the display mode for LVDS. But unfortunately as the LVDS status is not updated in time and it is still marked as disconnected, the LVDS and its corresponding CRTC will be disabled again in the function of drm_helper_disable_unused_functions after changing mode for LVDS. So we had better check and update the status of LVDS connector after receiving the LID notication event. Then after the system is resumed from suspended state, we can set the display mode for LVDS correctly. Signed-off-by:
Dirk Hohndel <hohndel@infradead.org> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jeff Layton authored
commit 486bad2e upstream. When handling the gssd downcall, the kernel should distinguish between a successful downcall that contains an error code and a failed downcall (i.e. where the parsing failed or some other sort of problem occurred). In the former case, gss_pipe_downcall should be returning the number of bytes written to the pipe instead of an error. In the event of other errors, we generally want the initiating task to retry the upcall so we set msg.errno to -EAGAIN. An unexpected error code here is a bug however, so BUG() in that case. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit b891e4a0 upstream. If the context allocation fails, it will return GSS_S_FAILURE, which is neither a valid error code, nor is it even negative. Return ENOMEM instead... Reported-by:
-
Trond Myklebust authored
commit 14ace024 upstream. If the context allocation fails, the function currently returns a random error code, since the variable 'p' still points to a valid memory location. Ensure that it returns ENOMEM... Signed-off-by:
-
Xiaotian Feng authored
commit b292cf9c upstream. There're some warnings of "nfsd: peername failed (err 107)!" socket error -107 means Transport endpoint is not connected. This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c], when kernel_getpeername returns -107. This means socket might be CLOSED. And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c] if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) { <snip> newxpt = xprt->xpt_ops->xpo_accept(xprt); <snip> So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE. Let's take a look at commit b0401d72, this commit has moved the close processing after do recvfrom method, but this commit also introduces this warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should close it, not accpet then close. Signed-off-by:
Xiaotian Feng <dfeng@redhat.com> Cc: J. Bruce Fields <bfields@fieldses.org> Cc: Neil Brown <neilb@suse.de> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: David S. Miller <davem@davemloft.net> Cc: Nikola Ciprich <extmaillist@linuxbox.cz> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Christoph Hellwig authored
commit 7211a4e8 upstream. nfsd is not using vfs_fsync, so I missed it when changing the calling convention during the 2.6.32 window. This patch fixes it to not only start the data writeout, but also wait for it to complete before calling into ->fsync. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Rusty Russell authored
commit db677ffa upstream. This reverts commit ae1b22f6. As Linus said in 982d007a: "There was something really messy about cmpxchg8b and clone CPU's, so if you enable it on other CPUs later, do it carefully." This breaks lguest for those configs, but we can fix that by emulating if we have to. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14884Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Boaz Harrosh authored
commit efd124b9 upstream. exofs uses simple_write_end() for it's .write_end handler. But it is not enough because simple_write_end() does not call mark_inode_dirty() when it extends i_size. So even if we do call mark_inode_dirty at beginning of write out, with a very long IO and a saturated system we might get the .write_inode() called while still extend-writing to file and miss out on the last i_size updates. So override .write_end, call simple_write_end(), and afterwords if i_size was changed call mark_inode_dirty(). It stands to logic that since simple_write_end() was the one extending i_size it should also call mark_inode_dirty(). But it looks like all users of simple_write_end() are memory-bound pseudo filesystems, who could careless about mark_inode_dirty(). I might submit a warning-comment patch to simple_write_end() in future. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Ben Hutchings authored
commit 10b465aa upstream. Commit 35dead42 "modules: don't export section names of empty sections via sysfs" changed the set of sections that have attributes, but did not change the iteration over these attributes in add_notes_attrs(). This can lead to add_notes_attrs() creating attributes with the wrong names or with null name pointers. Introduce a sect_empty() function and use it in both add_sect_attrs() and add_notes_attrs(). Reported-by:
Martin Michlmayr <tbm@cyrius.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Tested-by:
-
Guennadi Liakhovetski authored
commit b3172f22 upstream. Sevelar ASoC codec drivers wrongly assume, that the params_rate() macro returns one of SNDRV_PCM_RATE_* defines instead of the actual numerical sampling rate. Fix them. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Linus Torvalds authored
commit 53281b6d upstream. Yes, the add and remove cases do share the same basic loop and the locking, but the compiler can inline and then CSE some of the end result anyway. And splitting it up makes the code way easier to follow, and makes it clearer exactly what the semantics are. In particular, we must make sure that the FASYNC flag in file->f_flags exactly matches the state of "is this file on any fasync list", since not only is that flag visible to user space (F_GETFL), but we also use that flag to check whether we need to remove any fasync entries on file close. We got that wrong for the case of a mixed use of file locking (which tries to remove any fasync entries for file leases) and fasync. Splitting the function up also makes it possible to do some future optimizations without making the function even messier. In particular, since the FASYNC flag has to match the state of "is this on a list", we can do the following future optimizations: - on remove, we don't even need to get the locks and traverse the list if FASYNC isn't set, since we can know a priori that there is no point (this is effectively the same optimization that we already do in __fput() wrt removing fasync on file close) - on add, we can use the FASYNC flag to decide whether we are changing an existing entry or need to allocate a new one. but this is just the cleanup + fix for the FASYNC flag. Acked-by:
Al Viro <viro@ZenIV.linux.org.uk> Tested-by:
Tavis Ormandy <taviso@google.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by:
-
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:
-
- 06 Jan, 2010 17 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:
-
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:
-
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:
-
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:
-
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:
-
