- 23 Mar, 2011 21 commits
-
-
Axel Lin authored
The following symbols are needlessly defined global: jornada_bl_init, jornada_bl_exit, jornada_lcd_init, jornada_lcd_exit. Make them static. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Kristoffer Ericson <kristoffer.ericson@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Randy Dunlap authored
apple_bl uses ACPI interfaces (data & code), so it should depend on ACPI. drivers/video/backlight/apple_bl.c:142: warning: 'struct acpi_device' declared inside parameter list drivers/video/backlight/apple_bl.c:142: warning: its scope is only this definition or declaration, which is probably not what you want drivers/video/backlight/apple_bl.c:201: warning: 'struct acpi_device' declared inside parameter list drivers/video/backlight/apple_bl.c:215: error: variable 'apple_bl_driver' has initializer but incomplete type drivers/video/backlight/apple_bl.c:216: error: unknown field 'name' specified in initializer ... Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Matthew Garrett authored
It works on hardware other than Macbook Pros, and it works on GPUs other than Nvidia. It should even work on iMacs, so change the name to match reality more precisely and include an alias so existing users don't get confused. Signed-off-by:
Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Mourad De Clerck <mourad@aquazul.com> Signed-off-by:
-
Matthew Garrett authored
The SMI-based backlight control functionality may fail to work if the system is running under EFI rather than BIOS. Check that the hardware responds as expected, and exit if it doesn't. Signed-off-by:
-
Matthew Garrett authored
This driver only has to deal with two different classes of hardware, but right now it needs new DMI entries for every new machine. It turns out that there's an ACPI device that uniquely identifies Apples with backlights, so this patch reworks the driver into an ACPI one, identifies the hardware by checking the PCI vendor of the root bridge and strips out all the DMI code. It also changes the config text to clarify that it works on devices other than Macbook Pros and GPUs other than nvidia. Signed-off-by:
-
Matthew Garrett authored
Dual-GPU machines may provide more than one ACPI backlight interface. Tie the backlight device to the GPU in order to allow userspace to identify the correct interface. Signed-off-by:
Sedat Dilek <sedat.dilek@googlemail.com> Signed-off-by:
-
Matthew Garrett authored
We may eventually end up with per-connector backlights, especially with ddcci devices. Make sure that the parent node for the backlight device is the connector rather than the PCI device. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
-
Michel Dänzer authored
Allows e.g. power management daemons to control the backlight level. Inspired by the corresponding code in radeonfb. [mjg@redhat.com: updated to add backlight type and make the connector the parent device] Signed-off-by:
Michel Dänzer <michel@daenzer.net> Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
-
Matthew Garrett authored
There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by:
-
Vasiliy Kulikov authored
Don't allow everybody to change LED settings. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Vasiliy Kulikov authored
Don't allow everybody to change LED settings. Signed-off-by:
-
Donghwa Lee authored
Add a ld9040 amoled panel driver. Signed-off-by:
Donghwa Lee <dh09.lee@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Uwe Kleine-König authored
And fix a typo. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Shreshtha Kumar Sahu authored
Simple backlight driver for National Semiconductor LM3530. Presently only manual mode is supported, PWM and ALS support to be added. Signed-off-by:
Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Cc: Linus Walleij <linus.walleij@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Mark Brown authored
There is a move to deprecate bus-specific PM operations and move to using dev_pm_ops instead in order to reduce the amount of boilerplate code in buses and facilitiate updates to the PM core. Do this move for the bs2802 driver. [akpm@linux-foundation.org: fix warnings] Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Kim Kyuwon <q1.kim@samsung.com> Cc: Kim Kyuwon <chammoru@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Phil Carmody authored
list_del() leaves poison in the prev and next pointers. The next list_empty() will compare those poisons, and say the list isn't empty. Any list operations that assume the node is on a list because of such a check will be fooled into dereferencing poison. One needs to INIT the node after the del, and fortunately there's already a wrapper for that - list_del_init(). Some of the dels are followed by deallocations, so can be ignored, and one can be merged with an add to make a move. Apart from that, I erred on the side of caution in making nodes list_empty()-queriable. Signed-off-by:
Phil Carmody <ext-phil.2.carmody@nokia.com> Reviewed-by:
Paul Menage <menage@google.com> Cc: Li Zefan <lizf@cn.fujitsu.com> Acked-by:
Kirill A. Shutemov <kirill@shutemov.name> Cc: <stable@kernel.org> Signed-off-by:
-
David Rientjes authored
The oom killer naturally defers killing anything if it finds an eligible task that is already exiting and has yet to detach its ->mm. This avoids unnecessarily killing tasks when one is already in the exit path and may free enough memory that the oom killer is no longer needed. This is detected by PF_EXITING since threads that have already detached its ->mm are no longer considered at all. The problem with always deferring when a thread is PF_EXITING, however, is that it may never actually exit when being traced, specifically if another task is tracing it with PTRACE_O_TRACEEXIT. The oom killer does not want to defer in this case since there is no guarantee that thread will ever exit without intervention. This patch will now only defer the oom killer when a thread is PF_EXITING and no ptracer has stopped its progress in the exit path. It also ensures that a child is sacrificed for the chosen parent only if it has a different ->mm as the comment implies: this ensures that the thread group leader is always targeted appropriately. Signed-off-by:
David Rientjes <rientjes@google.com> Reported-by:
Oleg Nesterov <oleg@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Hugh Dickins <hughd@google.com> Cc: Andrey Vagin <avagin@openvz.org> Cc: <stable@kernel.org> [2.6.38.x] Signed-off-by:
-
Andrey Vagin authored
We shouldn't defer oom killing if a thread has already detached its ->mm and still has TIF_MEMDIE set. Memory needs to be freed, so find kill other threads that pin the same ->mm or find another task to kill. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
David Rientjes authored
This patch prevents unnecessary oom kills or kernel panics by reverting two commits: 495789a5 (oom: make oom_score to per-process value) cef1d352 (oom: multi threaded process coredump don't make deadlock) First, 495789a5 (oom: make oom_score to per-process value) ignores the fact that all threads in a thread group do not necessarily exit at the same time. It is imperative that select_bad_process() detect threads that are in the exit path, specifically those with PF_EXITING set, to prevent needlessly killing additional tasks. If a process is oom killed and the thread group leader exits, select_bad_process() cannot detect the other threads that are PF_EXITING by iterating over only processes. Thus, it currently chooses another task unnecessarily for oom kill or panics the machine when nothing else is eligible. By iterating over threads instead, it is possible to detect threads that are exiting and nominate them for oom kill so they get access to memory reserves. Second, cef1d352 (oom: multi threaded process coredump don't make deadlock) erroneously avoids making the oom killer a no-op when an eligible thread other than current isfound to be exiting. We want to detect this situation so that we may allow that exiting thread time to exit and free its memory; if it is able to exit on its own, that should free memory so current is no loner oom. If it is not able to exit on its own, the oom killer will nominate it for oom kill which, in this case, only means it will get access to memory reserves. Without this change, it is easy for the oom killer to unnecessarily target tasks when all threads of a victim don't exit before the thread group leader or, in the worst case, panic the machine. Signed-off-by:
-
Mel Gorman authored
If an administrator tries to swapon a file backed by NFS, the inode mutex is taken (as it is for any swapfile) but later identified to be a bad swapfile due to the lack of bmap and tries to cleanup. During cleanup, an attempt is made to close the file but with inode->i_mutex still held. Closing an NFS file syncs it which tries to acquire the inode mutex leading to deadlock. If lockdep is enabled the following appears on the console; ============================================= [ INFO: possible recursive locking detected ] 2.6.38-rc8-autobuild #1 --------------------------------------------- swapon/2192 is trying to acquire lock: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: vfs_fsync_range+0x47/0x7c but task is already holding lock: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: sys_swapon+0x28d/0xae7 other info that might help us debug this: 1 lock held by swapon/2192: #0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: sys_swapon+0x28d/0xae7 stack backtrace: Pid: 2192, comm: swapon Not tainted 2.6.38-rc8-autobuild #1 Call Trace: __lock_acquire+0x2eb/0x1623 find_get_pages_tag+0x14a/0x174 pagevec_lookup_tag+0x25/0x2e vfs_fsync_range+0x47/0x7c lock_acquire+0xd3/0x100 vfs_fsync_range+0x47/0x7c nfs_flush_one+0x0/0xdf [nfs] mutex_lock_nested+0x40/0x2b1 vfs_fsync_range+0x47/0x7c vfs_fsync_range+0x47/0x7c vfs_fsync+0x1c/0x1e nfs_file_flush+0x64/0x69 [nfs] filp_close+0x43/0x72 sys_swapon+0xa39/0xae7 sysret_check+0x2e/0x69 system_call_fastpath+0x16/0x1b This patch releases the mutex if its held before calling filep_close() so swapon fails as expected without deadlock when the swapfile is backed by NFS. If accepted for 2.6.39, it should also be considered a -stable candidate for 2.6.38 and 2.6.37. Signed-off-by:Mel Gorman <mgorman@suse.de> Acked-by:
Hugh Dickins <hughd@google.com> Cc: <stable@kernel.org> [2.6.37+] Signed-off-by:
-
Andrew Morton authored
syncfs() is duplicating name_to_handle_at() due to a merging mistake. Cc: Sage Weil <sage@newdream.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 22 Mar, 2011 19 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6Linus Torvalds authored
* 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6: slub: Add statistics for this_cmpxchg_double failures slub: Add missing irq restore for the OOM path
-
git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fsLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs: [net/9p]: Introduce basic flow-control for VirtIO transport. 9p: use the updated offset given by generic_write_checks [net/9p] Don't re-pin pages on retrying virtqueue_add_buf(). [net/9p] Set the condition just before waking up. [net/9p] unconditional wake_up to proc waiting for space on VirtIO ring fs/9p: Add v9fs_dentry2v9ses fs/9p: Attach writeback_fid on first open with WR flag fs/9p: Open writeback fid in O_SYNC mode fs/9p: Use truncate_setsize instead of vmtruncate net/9p: Fix compile warning net/9p: Convert the in the 9p rpc call path to GFP_NOFS fs/9p: Fix race in initializing writeback fid
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: rbd: use watch/notify for changes in rbd header libceph: add lingering request and watch/notify event framework rbd: update email address in Documentation ceph: rename dentry_release -> d_release, fix comment ceph: add request to the tail of unsafe write list ceph: remove request from unsafe list if it is canceled/timed out ceph: move readahead default to fs/ceph from libceph ceph: add ino32 mount option ceph: update common header files ceph: remove debugfs debug cruft libceph: fix osd request queuing on osdmap updates ceph: preserve I_COMPLETE across rename libceph: Fix base64-decoding when input ends in newline.
-
Linus Torvalds authored
Using delayed-work for tty flip buffers ends up causing us to wait for the next tick to complete some actions. That's usually not all that noticeable, but for certain latency-critical workloads it ends up being totally unacceptable. As an extreme case of this, passing a token back-and-forth over a pty will take two ticks per iteration, so even just a thousand iterations will take 8 seconds assuming a common 250Hz configuration. Avoiding the whole delayed work issue brings that ping-pong test-case down to 0.009s on my machine. In more practical terms, this latency has been a performance problem for things like dive computer simulators (simulating the serial interface using the ptys) and for other environments (Alan mentions a CP/M emulator). Reported-by:
Jef Driesen <jefdriesen@telenet.be> Acked-by:
Greg KH <gregkh@suse.de> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Venkateswararao Jujjuri (JV) authored
Recent zerocopy work in the 9P VirtIO transport maps and pins user buffers into kernel memory for the server to work on them. Since the user process can initiate this kind of pinning with a simple read/write call, thousands of IO threads initiated by the user process can hog the system resources and could result into denial of service. This patch introduces flow control to avoid that extreme scenario. The ceiling limit to avoid denial of service attacks is set to relatively high (nr_free_pagecache_pages()/4) so that it won't interfere with regular usage, but can step in extreme cases to limit the total system hang. Since we don't have a global structure to accommodate this variable, I choose the virtio_chan as the home for this. Signed-off-by:
Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com> Reviewed-by:
Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
Eric Van Hensbergen <ericvh@gmail.com>
-
M. Mohan Kumar authored
Without this fix, even if a file is opened in O_APPEND mode, data will be written at current file position instead of end of file. Signed-off-by:
M. Mohan Kumar <mohan@in.ibm.com> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
-
Venkateswararao Jujjuri (JV) authored
Signed-off-by:
-
Venkateswararao Jujjuri (JV) authored
Given that the sprious wake-ups are common, we need to move the condition setting right next to the wake_up(). After setting the condition to req->status = REQ_STATUS_RCVD, sprious wakeups may cause the virtqueue back on the free list for someone else to use. This may result in kernel panic while relasing the pinned pages in p9_release_req_pages(). Also rearranged the while loop in req_done() for better redability. Signed-off-by:
-
Venkateswararao Jujjuri (JV) authored
Process may wait to get space on VirtIO ring to send a transaction to VirtFS server. Current code just does a conditional wake_up() which means only one process will be woken up even if multiple processes are waiting. This fix makes the wake_up unconditional. Hence we won't have any processes waiting for-ever. Signed-off-by:
-
Aneesh Kumar K.V authored
Add the new static inline and use the same Signed-off-by:
-
Aneesh Kumar K.V authored
We don't need writeback fid if we are only doing O_RDONLY open Signed-off-by:
-
Aneesh Kumar K.V authored
Older version of protocol don't support tsyncfs operation. So for them force a O_SYNC flag on the server Signed-off-by:
-
Aneesh Kumar K.V authored
convert vmtruncate usage to truncate_setsize. We also writeback all dirty pages before doing 9p operations and on success call truncate_setsize. This ensure that we continue sanely on failed truncate on the server. The disadvantage is that we are now going to write back the content that get thrown away later as a part of truncate. Signed-off-by:
-
Aneesh Kumar K.V authored
Signed-off-by:
-
Aneesh Kumar K.V authored
Without this we can cause reclaim allocation in writepage. [ 3433.448430] ================================= [ 3433.449117] [ INFO: inconsistent lock state ] [ 3433.449117] 2.6.38-rc5+ #84 [ 3433.449117] --------------------------------- [ 3433.449117] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. [ 3433.449117] kswapd0/505 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 3433.449117] (iprune_sem){+++++-}, at: [<ffffffff810ebbab>] shrink_icache_memory+0x45/0x2b1 [ 3433.449117] {RECLAIM_FS-ON-W} state was registered at: [ 3433.449117] [<ffffffff8107fe5f>] mark_held_locks+0x52/0x70 [ 3433.449117] [<ffffffff8107ff02>] lockdep_trace_alloc+0x85/0x9f [ 3433.449117] [<ffffffff810d353d>] slab_pre_alloc_hook+0x18/0x3c [ 3433.449117] [<ffffffff810d3fd5>] kmem_cache_alloc+0x23/0xa2 [ 3433.449117] [<ffffffff8127be77>] idr_pre_get+0x2d/0x6f [ 3433.449117] [<ffffffff815434eb>] p9_idpool_get+0x30/0xae [ 3433.449117] [<ffffffff81540123>] p9_client_rpc+0xd7/0x9b0 [ 3433.449117] [<ffffffff815427b0>] p9_client_clunk+0x88/0xdb [ 3433.449117] [<ffffffff811d56e5>] v9fs_evict_inode+0x3c/0x48 [ 3433.449117] [<ffffffff810eb511>] evict+0x1f/0x87 [ 3433.449117] [<ffffffff810eb5c0>] dispose_list+0x47/0xe3 [ 3433.449117] [<ffffffff810eb8da>] evict_inodes+0x138/0x14f [ 3433.449117] [<ffffffff810d90e2>] generic_shutdown_super+0x57/0xe8 [ 3433.449117] [<ffffffff810d91e8>] kill_anon_super+0x11/0x50 [ 3433.449117] [<ffffffff811d4951>] v9fs_kill_super+0x49/0xab [ 3433.449117] [<ffffffff810d926e>] deactivate_locked_super+0x21/0x46 [ 3433.449117] [<ffffffff810d9e84>] deactivate_super+0x40/0x44 [ 3433.449117] [<ffffffff810ef848>] mntput_no_expire+0x100/0x109 [ 3433.449117] [<ffffffff810f0aeb>] sys_umount+0x2f1/0x31c [ 3433.449117] [<ffffffff8102c87b>] system_call_fastpath+0x16/0x1b [ 3433.449117] irq event stamp: 192941 [ 3433.449117] hardirqs last enabled at (192941): [<ffffffff81568dcf>] _raw_spin_unlock_irq+0x2b/0x30 [ 3433.449117] hardirqs last disabled at (192940): [<ffffffff810b5f97>] shrink_inactive_list+0x290/0x2f5 [ 3433.449117] softirqs last enabled at (188470): [<ffffffff8105fd65>] __do_softirq+0x133/0x152 [ 3433.449117] softirqs last disabled at (188455): [<ffffffff8102d7cc>] call_softirq+0x1c/0x28 [ 3433.449117] [ 3433.449117] other info that might help us debug this: [ 3433.449117] 1 lock held by kswapd0/505: [ 3433.449117] #0: (shrinker_rwsem){++++..}, at: [<ffffffff810b52e2>] shrink_slab+0x38/0x15f [ 3433.449117] [ 3433.449117] stack backtrace: [ 3433.449117] Pid: 505, comm: kswapd0 Not tainted 2.6.38-rc5+ #84 [ 3433.449117] Call Trace: [ 3433.449117] [<ffffffff8107fbce>] ? valid_state+0x17e/0x191 [ 3433.449117] [<ffffffff81036896>] ? save_stack_trace+0x28/0x45 [ 3433.449117] [<ffffffff81080426>] ? check_usage_forwards+0x0/0x87 [ 3433.449117] [<ffffffff8107fcf4>] ? mark_lock+0x113/0x22c [ 3433.449117] [<ffffffff8108105f>] ? __lock_acquire+0x37a/0xcf7 [ 3433.449117] [<ffffffff8107fc0e>] ? mark_lock+0x2d/0x22c [ 3433.449117] [<ffffffff81081077>] ? __lock_acquire+0x392/0xcf7 [ 3433.449117] [<ffffffff810b14d2>] ? determine_dirtyable_memory+0x15/0x28 [ 3433.449117] [<ffffffff81081a33>] ? lock_acquire+0x57/0x6d [ 3433.449117] [<ffffffff810ebbab>] ? shrink_icache_memory+0x45/0x2b1 [ 3433.449117] [<ffffffff81567d85>] ? down_read+0x47/0x5c [ 3433.449117] [<ffffffff810ebbab>] ? shrink_icache_memory+0x45/0x2b1 [ 3433.449117] [<ffffffff810ebbab>] ? shrink_icache_memory+0x45/0x2b1 [ 3433.449117] [<ffffffff810b5385>] ? shrink_slab+0xdb/0x15f [ 3433.449117] [<ffffffff810b69bc>] ? kswapd+0x574/0x96a [ 3433.449117] [<ffffffff810b6448>] ? kswapd+0x0/0x96a [ 3433.449117] [<ffffffff810714e2>] ? kthread+0x7d/0x85 [ 3433.449117] [<ffffffff8102d6d4>] ? kernel_thread_helper+0x4/0x10 [ 3433.449117] [<ffffffff81569200>] ? restore_args+0x0/0x30 [ 3433.449117] [<ffffffff81071465>] ? kthread+0x0/0x85 [ 3433.449117] [<ffffffff8102d6d0>] ? kernel_thread_helper+0x0/0x10 Signed-off-by: -
Aneesh Kumar K.V authored
When two process open the same file we can end up with both of them allocating the writeback_fid. Add a new mutex which can be used for synchronizing v9fs_inode member values. Signed-off-by:
-
Christoph Lameter authored
Add some statistics for debugging. Signed-off-by:
Christoph Lameter <cl@linux.com> Signed-off-by:
Pekka Enberg <penberg@kernel.org>
-
Christoph Lameter authored
OOM path is missing the irq restore in the CONFIG_CMPXCHG_LOCAL case. Signed-off-by:
-
Yehuda Sadeh authored
Send notifications when we change the rbd header (e.g. create a snapshot) and wait for such notifications. This allows synchronizing the snapshot creation between different rbd clients/rools. Signed-off-by:
Yehuda Sadeh <yehuda@hq.newdream.net> Signed-off-by:
Sage Weil <sage@newdream.net>
-
