- 15 Jan, 2005 40 commits
-
-
Gabor Egry authored
Here are some Kconfig fixes: - typo fixes - unused token removes (empty or duplicated 'help') - non ASCII characters replaces - e-mail address and URL format corrections Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Matt Mackall authored
The input layer wants to send us an entropy event per input event and who are we to argue? Create add_input_randomness with an input-friendly interface and kill the remaining two keyboard and mouse sources. This eliminates lots of duplicate entropy events while covering all the input bases nicely. We now get two events per keystroke as we should, one down and one up. Signed-off-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Matt Mackall authored
The input layer is now sending us a bunch of events in a row for each actual event. This shows up weaknesses in the periodicity detector and using the high clock rate from get_clock: each keystroke is getting accounted as 10 different maximal-entropy events. A brief touch on a trackpad will generate as much as 2000 maximal entropy events which is more than 2k of /dev/random output. IOW, we're WAY overestimating input entropy. Here's one keystroke: random 0024 0000 0000: mouse event random 0035 0000 0000: added 11 entropy credits to input random 0035 0000 0000: mouse event random 0046 0000 0000: added 11 entropy credits to input random 0046 0000 0000: mouse event random 0056 0000 0000: added 10 entropy credits to input random 0056 0000 0000: keyboard event random 0067 0000 0000: added 11 entropy credits to input random 0067 0000 0000: mouse event random 0078 0000 0000: added 11 entropy credits to input random 0078 0000 0000: awake random 0078 0000 0000: reading 128 bits random 0078 0000 0000: going to reseed blocking with 128 bits (128 of 0 requested) random 0078 0000 0000: trying to extract 128 bits from input random 0006 0000 0000: debiting 72 entropy credits from input random 0006 0072 0000: added 72 entropy credits to blocking random 0006 0072 0000: trying to extract 128 bits from blocking random 0006 0000 0000: debiting 72 entropy credits from blocking random 0006 0000 0000: read got 72 bits (56 still needed) random 0006 0000 0000: reading 56 bits random 0006 0000 0000: going to reseed blocking with 64 bits (56 of 0 requested random 0006 0000 0000: trying to extract 64 bits from input random 0006 0000 0000: debiting 0 entropy credits from input random 0006 0000 0000: trying to extract 56 bits from blocking random 0006 0000 0000: debiting 0 entropy credits from blocking random 0006 0000 0000: read got 0 bits (56 still needed) random 0006 0000 0000: sleeping random 0006 0000 0000: mouse event random 0017 0000 0000: added 11 entropy credits to input random 0017 0000 0000: mouse event random 0028 0000 0000: added 11 entropy credits to input random 0028 0000 0000: mouse event random 0038 0000 0000: added 10 entropy credits to input random 0038 0000 0000: keyboard event random 0049 0000 0000: added 11 entropy credits to input random 0049 0000 0000: mouse event random 0060 0000 0000: added 11 entropy credits to input The first step to fixing this is to check periodicity and estimate entropy against a slow clock like jiffies. We continue to mix in get_clock() rather than jiffies where available. This throws away most of the duplicate events and gives us more sensible entropy estimates, but we still duplicates from input.c and keyboard.c. Signed-off-by:
-
Matt Mackall authored
Add run-time switchable entropy debugging. Entire debug infrastructure remains compiled out by default. Signed-off-by:
-
Matt Mackall authored
Print pool entropy counts in all entropy debugging messages Signed-off-by:
-
Matt Mackall authored
Someone actually spotted this already. Signed-off-by:
-
Vadim Lobanov authored
Signed-off-by:
Vadim Lobanov <vlobanov@speakeasy.net> Signed-off-by:
-
Antonino Daplas authored
Add a framebuffer driver for the ATI w100 as found on several Sharp PDAs Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Antonino Daplas authored
From: Andrew Zabolotny Here's a patch that adds basic support for controlling backlight lamps and lcd panels. The drivers can be controlled via sysfs, which makes it easy to use both from scripts and programs. Signed-off-by:
-
Antonino Daplas authored
Reorder add_wait_queue() and set_current_state() as a signal could be lost in between the two functions. Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by:
Domen Puncer <domen@coderock.org> Signed-off-by:
-
Antonino Daplas authored
Reorder set_current_state() and add_wait_queue(). There is a chance that a signal could be missed in between the two functions currently. Signed-off-by:
-
Antonino Daplas authored
Fix 3 instances of calling exit section function from text or init: Error: ./drivers/video/aty/radeon_base.o .text refers to 000029e5 R_386_PC32 .exit.text Error: ./drivers/video/aty/radeon_base.o .text refers to 00002a60 R_386_PC32 .exit.text Error: ./drivers/video/aty/radeon_base.o .init.text refers to 00000192 R_386_PC32 .exit.text Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Antonino Daplas authored
This patch syncs up the module parameter descriptions in aty128fb for module parameters "mode_option" and "nomtrr". Without the patch bad parameter names are used with MODULE_PARM_DESC(). Signed-off-by:
Magnus Damm <damm@opensource.se> Signed-off-by:
-
Antonino Daplas authored
Last parameter is file permition in sysfs, not default value. (If 0, file is not accessible trough sysfs, and that's what i did.) Signed-off-by:
-
Antonino Daplas authored
While browsing the video/fbcon.c source file (Linux 2.6.10-rc3) I found some possible cleanups. Patch follows, feel free to apply all or parts of it if it looks OK to you. Remove unnecessary bit operations. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Antonino Daplas authored
Fix missing symbol (fb_con) Signed-off-by:
-
Antonino Daplas authored
Call fb_blank() instead of info->fbops->fb_blank() to capture events on both device and console level. Signed-off-by:
-
Antonino Daplas authored
Check first if EDID block came from a broken display before fixing. Signed-off-by:
-
Mark A. Greer authored
Patch for the Marvell MultiProtocol Serial Controller (MPSC). This ctlr is on a series of host bridges (and other things) for PPC and MIPS processors. The ctlr operates similar to a typical network controller with send and receive rings. Unfortunately there are many errata so you will see some "unusual" things in the code. For example: a) An erratum prevents the reading of several registers on the ctlr (writing is okay). To work around that, a local copy of what the registers are is kept and special macros are used to access those mirrored values. b) Another erratum says that the MPSC cannot be used to access cache coherent memory (and many of the systems I use are cache coherent). However, it seems to work okay as long as there are no snoop hits so there are macros in the code to manually manage the caches to prevent snoop hits. Each macro checks a flag to see if the manual cache mgmt is necessary as not all versions have the erratum. The driver seems to work well but more testing is needed and it is lacking KGDB support. I will get to both of those in time. Signed-off-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
-
Dominik Brodowski authored
Remove #includes in rsrc_mgr which are no longer needed. Signed-off-by:
Dominik Brodowski <linux@brodo.de> Signed-off-by:
-
Dominik Brodowski authored
Allow to modify the per-socket irq_mask via sysfs. Note that you can only clear bits from the mask, but not re-add bits. Signed-off-by:
-
Dominik Brodowski authored
Remove the racy try_irq/check_irq/undo_irq interface, and try to register the correct handler directly in pcmcia_request_irq(). Also, simplify the IRQ usage database, but avoid using the same IRQ twice. Signed-off-by:
-
Dominik Brodowski authored
Unset bits in the per-socket irq_mask to mark IRQs as unusable, if asked to do so by the user in /etc/pcmcia/config.opts Signed-off-by:
-
Dominik Brodowski authored
Remove the now useless irq_mask and irq_list parameters from PCMCIA drivers. Users should use either the socket driver's irq_mask / irq_list parameter or use /sys/class/pcmcia_socket/pcmcia_socket%n/card_irq_mask which will be added in a subsequent patch. Signed-off-by:
-
Dominik Brodowski authored
As its just one pin which can be used for IRQs on PCMCIA/CardBus cards, and only the _socket drivers_ care with which IRQ this pin is connected, only the socket drivers (assisted by the PCCARD core) should care about which IRQ to use. Therefore, ignore the information passed to pcmcia_request_irq() in IRQInfo2. In additional patches, all in-kernel users of IRQInfo2 will be removed; users wishing to influence the usage of IRQs can do so by modifying several driver's irq_mask parameter and/or by adding "exclude irq 3" to /etc/pcmcia/config.opts. Note that a new sysfs-based interface to do so will be added in subsequent patches. Signed-off-by:
-
Dominik Brodowski authored
IRQ_TYPE_TIME is unused in the whole kernel, so remove it. Signed-off-by:
-
Roland McGrath authored
When kill is used to force a core dump, __group_complete_signal uses the group_stop_count machinery to stop other threads from doing anything more before the signal-taking thread starts the coredump synchronization. This intentionally results in group_stop_count always still being > 0 when the signal-taking thread gets into do_coredump. However, that has the unintended effect that signal_pending can return true when called from the filesystem code while writing the core dump file. For NFS mounts using the "intr" option, this results in NFS operations bailing out before they even try, so core files never get successfully dumped on such a filesystem when the crash was induced by an asynchronous process-wide signal. This patch fixes the problem by clearing group_stop_count after the coredump synchronization is complete. The locking I threw in is not directly related, but always should have been there and may avoid some potential races with kill. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Prasanna Meda authored
Since Roland changed now to wakeup tracee with kill, I guess this needs to be fixed. http://linus.bkbits.net:8080/linux-2.5/gnupatch@41e3fe5fIRH-W3aDnXZgfQ-qIvuXYg ptrace_setsiginfo/ptrace_getsiginfo need to do locked access to last_siginfo. ptrace_notify()/ptrace_stop() sets the current->last_siginfo and sleeps on schedule(). It can be waked up by kill signal from signal_wake_up before debugger wakes it up. On return from schedule(), the current->last_siginfo is reset. Signed-off-by:
Prasanna Meda <pmeda@akamai.com> Acked-by:
-
Roland McGrath authored
If one thread uses ptrace on another thread in the same thread group, there can be a deadlock when calling exec. The ptrace_stop change ensures that no tracing stop can be entered for a queued signal, or exit tracing, if the tracer is part of the same dying group. The exit_notify change prevents a ptrace zombie from sticking around if its tracer is in the midst of a group exit (which an exec fakes), so these zombies don't hold up de_thread's synchronization. The de_thread change ensures the new thread group leader doesn't wind up ptracing itself, which would produce its own deadlocks. Signed-off-by:
-
Roland McGrath authored
When threads are sharing mm via CLONE_VM (linuxthreads, vfork), there is a race condition where one thread doing a core dump and synchronizing all mm-sharing threads for it can deadlock waiting for another thread that just did an exec and will never synchronize. This patch makes the exec_mmap check for a pending core dump and punt the exec to synchronize with that, as if the core dump had struck before entering the execve system call at all. Signed-off-by:
-
Roland McGrath authored
In the oddball situation where one thread is using ptrace on another thread sharing the same mm, and then someone sharing that mm causes a coredump, there is a deadlock possible if the traced thread is in TASK_TRACED state. It leaves all the threads sharing that mm wedged and permanently unkillable. This patch checks for that situation and brings a thread out of TASK_TRACED if its tracer is part of the same coredump (i.e. shares the same mm). It's not pretty, but it does the job. Signed-off-by:
-
Michael S. Tsirkin authored
To make life bearable for out-of kernel modules, the following patch adds 2 macros so that existance of unlocked_ioctl and ioctl_compat can be easily detected. Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
-
Christoph Hellwig authored
- add ->unlocked_ioctl method and a do_ioctl wrapper in ioctl.c so all places calling ->ioctl get it. THis provides us a patch to migrate away from holding bkl across ioctl implementations. - add ->compat_ioctl method and call it in compat_sys_ioctl before doing the hash lookup for registered handlers. - streamline compat_sys_ioctl and move the complex error reporting into a function of its own From: "Michael S. Tsirkin" <mst@mellanox.co.il> Handle generic ioctl commands by falling back on static conversion functions in fs/compat_ioctl.c on -ENOIOCTLCMD code. From: "Michael S. Tsirkin" <mst@mellanox.co.il> With new unlocked_ioctl and ioctl_compat, ioctls can now be as fast as read/write. So lets use fget_light/fput_light there, to get some speedup in common case on SMP. Signed-off-by:
-
Andreas Gruenbacher authored
This started of as a patch by Alex Tomas <alex@clusterfs.com> and got an overhaul by me. The on-disk structure used is the same as in Alex's original patch. Signed-off-by:
Andreas Gruenbacher <agruen@suse.de> Signed-off-by:
-
Andreas Gruenbacher authored
The in_mem optimization in ext3_get_inode_loc avoids a disk read when only the requested inode in the block group is allocated: In that case ext3_get_inode_loc assumes that it can recreate the inode from the in-memory inode. This is incorrect with in-inode extended attributes, which don't have a shadow copy in memory. Hide the in_mem option and clarify comments; the subsequent ea-in-inode changes the in_mem check as required. Signed-off-by:
-
Andreas Gruenbacher authored
Clean up several things in the xattr code, and prepare it for in-inode attributes: * Add the ext3_xattr_check_names, ext3_xattr_check_block, and ext3_xattr_check_entry functions for checking xattr data structures. * Add the ext3_xattr_find_entry, ext3_xattr_list_entries, and ext3_xattr_set_entry functions for manipulating xattr entries. Switch to using these functions in ext3_xattr_get, ext3_xattr_list, and ext3_xattr_set_handle. * Merge ext3_xattr_set_handle and ext3_xattr_set_handle2. * Rename the HDR and FIRST_ENTRY macros. * We have no way to deal with a ext3_xattr_cache_insert failure, so make it return void. * Make the debug messages more useful. Signed-off-by:
-
Andreas Gruenbacher authored
The ext3_xattr_set_handle2 and ext3_xattr_delete_inode functions contain duplicate code to decrease the reference count of an xattr block. Move this to a separate function. Also we know we have exclusive access to the inode in ext3_xattr_delete_inode; there is no need to grab the xattr_sem lock. Signed-off-by:
-
Andreas Gruenbacher authored
The ext3_xattr_set_handle2 and ext3_xattr_delete_inode functions contain duplicate code to decrease the reference count of an xattr block. Move this to a separate function. Also we know we have exclusive access to the inode in ext3_xattr_delete_inode; there is no need to grab the xattr_sem lock. Signed-off-by:
-
Andreas Gruenbacher authored
The use of journal_release_buffer is unsafe; it can overflow the journal: When a buffer is stolen from a transaction and later removed from that transaction with journal_release_buffer, the buffer is not accounted to the transaction that now "owns" the buffer, and one extra credit appears to be available. Don't use journal_release_buffer: We did rely on the buffer lock to synchronize xattr block accesses, and get write access to the buffer first to get atomicity. Return the mb_cache_entry from ext3_xattr_cache_find instead, and do the check/update under its lock. Only get write access when we know we will use the buffer. Signed-off-by:
-
Andreas Gruenbacher authored
Andrew Tridgell and Stephen C. Tweedie have reported two different Oopses caused by a race condition in the mbcache, which is responsible for extended attribute sharing in ext2 and ext3. Stephen tracked down the bug; I did the fix. Explanation: The mbcache caches the locations and content hashes of xattr blocks. There are two access strategies: [1] xattr block disposal via mb_cache_entry_get(), [2] xattr block reuse (sharing) via mb_cache_entry_find_{first,next}(). There is no locking between the two methods, so between one mb_cache_entry_find_x and the next, a mb_cache_entry_get might come in, unhash the cache entry, and change the journaling state of the xattr buffer. Subsequently, two things can happen: [a] the next mb_cache_entry_find_x may try to follow the mbcache hash chain starting from the entry that has become unhashed, which now is a stale pointer, [b] the block may have become deallocated, and then we try to reuse it. Fix this by converting the mbcache into a readers-writer style lock, and protect all block accesses in ext2/ext3 by the mbcache entry lock. This ensures that destroying blocks is an exclusive operation that may not overlap xattr block reuse, while allowing multiple "re-users". Write access to the xattr block's buffer is protected by the buffer lock. Signed-off-by:
-
