- 04 Jan, 2005 40 commits
-
-
Roland McGrath authored
There is really no point in each task_struct having its own waitchld_exit. In the only use of it, the waitchld_exit of each thread in a group gets woken up at the same time. So, there might as well just be one wait queue for the whole thread group. This patch does that by moving the field from task_struct to signal_struct. It should have no effect on the behavior, but saves a little work and a little storage in the multithreaded case. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Roland McGrath authored
There is a BUG_ON in ptrace_stop that hits if the thread is not ptraced. However, there is no synchronization between a thread deciding to do a ptrace stop and so going here, and its ptracer dying and so detaching from it and clearing its ->ptrace field. The RHEL3 2.4-based kernel has a backport of a slightly older version of the 2.6 signals code, which has a different but equivalent BUG_ON. This actually bit users in practice (when the debugger dies), but was exceedingly difficult to reproduce in contrived circumstances. We moved forward in RHEL3 just by removing the BUG_ON, and that fixed the real user problems even though I was never able to reproduce the scenario myself. So, to my knowledge this scenario has never actually been seen in practice under 2.6. But it's plain to see from the code that it is indeed possible. This patch removes that BUG_ON, but also goes further and tries to handle this case more gracefully than simply avoiding the crash. By removing the BUG_ON alone, it becomes possible for the real parent of a process to see spurious SIGCHLD notifications intended for the debugger that has just died, and have its child wind up stopped unexpectedly. This patch avoids that possibility by detecting the case when we are about to do the ptrace stop but our ptracer has gone away, and simply eliding that ptrace stop altogether as if we hadn't been ptraced when we hit the interesting event (signal or ptrace_notify call for syscall tracing or something like that). Signed-off-by:
-
Roland McGrath authored
After my last change, there are plenty of unused bits available in the new flags word in signal_struct. This patch moves the `group_exit' flag into one of those bits, saving a word in signal_struct. Signed-off-by:
-
Roland McGrath authored
The `sig_avoid_stop_race' checks fail to catch a related race scenario that can happen. I don't think this has been seen in nature, but it could happen in the same sorts of situations where the observed problems come up that those checks work around. This patch takes a different approach to catching this race condition. The new approach plugs the hole, and I think is also cleaner. The issue is a race between one CPU processing a stop signal while another CPU processes a SIGCONT or SIGKILL. There is a window in stop-signal processing where the siglock must be released. If a SIGCONT or SIGKILL comes along here on another CPU, then the stop signal in the midst of being processed needs to be discarded rather than having the stop take place after the SIGCONT or SIGKILL has been generated. The existing workaround checks for this case explicitly by looking for a pending SIGCONT or SIGKILL after reacquiring the lock. However, there is another problem related to the same race issue. In the window where the processing of the stop signal has released the siglock, the stop signal is not represented in the pending set any more, but it is still "pending" and not "delivered" in POSIX terms. The SIGCONT coming in this window is required to clear all pending stop signals. But, if a stop signal has been dequeued but not yet processed, the SIGCONT generation will fail to clear it (in handle_stop_signal). Likewise, a SIGKILL coming here should prevent the stop processing and make the thread die immediately instead. The `sig_avoid_stop_race' code checks for this by examining the pending set to see if SIGCONT or SIGKILL is in it. But this fails to handle the case where another CPU running another thread in the same process has already dequeued the signal (so it no longer can be found in the pending set). We must catch this as well, so that the same problems do not arise when another thread on another CPU acted real fast. I've fixed this dumping the `sig_avoid_stop_race' kludge in favor of a little explicit bookkeeping. Now, dequeuing any stop signal sets a flag saying that a pending stop signal has been taken on by some CPU since the last time all pending stop signals were cleared due to SIGCONT/SIGKILL. The processing of stop signals checks the flag after the window where it released the lock, and abandons the signal the flag has been cleared. The code that clears pending stop signals on SIGCONT generation also clears this flag. The various places that are trying to ensure the process dies quickly (SIGKILL or other unhandled signals) also clear the flag. I've made this a general flags word in signal_struct, and replaced the stop_state field with flag bits in this word. Signed-off-by:
-
Coywolf Qi Hunt authored
Peter Chubb recently split out a standalone sys_ni.c file for the not implemented syscalls. This patch removes the redundant sys_delete_module() in module.c. Signed-off-by:
Coywolf Qi Hunt <coywolf@gmail.com> Signed-off-by:
-
Oleg Nesterov authored
cpu_idle() is referenced from generic code (init/main.c). It is declared/defined in init/main.c: void cpu_idle(void) i386/kernel/process.c void cpu_idle(void) i386/kernel/smpboot.c: int cpu_idle(void) i386/mach-voyager/voyager_smp.c: int cpu_idle(void) ppc/kernel/idle.c: int cpu_idle(void) ppc/kernel/smp.c: int cpu_idle(void *unused) ppc64/kernel/idle.c: int cpu_idle(void) ppc64/kernel/smp.c: int cpu_idle(void *unused) sparc/kernel/process.c: int cpu_idle(void) sparc64/kernel/process.c: int cpu_idle(void) sh/kernel/process.c: void cpu_idle(void *unused) sh/kernel/smp.c: int cpu_idle(void *unused) ia64/kernel/smpboot.c: int cpu_idle(void) ia64/kernel/process.c: void cpu_idle(void *unused) sh64/kernel/process.c: void cpu_idle(void *unused) s390/kernel/process.c: int cpu_idle(void) s390/kernel/smp.c: int cpu_idle(void * unused) m32r/kernel/process.c: void cpu_idle(void) m32r/kernel/smpboot.c int cpu_idle(void) Other arches beleive that cpu_idle is void(void). This patch puts 'void cpu_idle(void)' in include/linux/smp.h and fixes conflicting definitions. Also removes now unneeded declarations in x86_64, alpha, parisc. Only i386 part is tested. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
James Nelson authored
This patch addresses the following issues: - Fix log-spamming and cryptic error messages, and add KERN_ constants. - Convert some ints to unsigned ints. - Add checks for CAP_SYS_ADMIN for FLASH_Burn and FLASH_Erase ioctls. - Identify use of global variable. - Fix memory leak in FLASH_Burn ioctl. - Fix error return codes in lcd_ioctl(). - Move variable "index" in lcd_ioctl() to smaller scope to reduce memory usage. - Convert cli()/sti() to spin_lock_irqsave()/spin_unlock_irqrestore(). Fix legibility issues in FLASH_Burn ioctl. Signed-off-by:
James Nelson <james4765@gmail.com> Signed-off-by:
-
Werner Almesberger authored
Last but not least, move the general prio_tree code from mm/ to lib/. This patch also duplicates some macros, which are used in the VMA code for debugging purposes, so we can't properly separate them yet. Note that this patch conflicts with a patch in 2.6.10-rc3-mm1 (frv-better-mmap-support-in-uclinux.patch), which removes mm/prio_tree in systems without an MMU. Not making that other patch provide a dummy for prio_tree_init should resolve the conflict. (That's just from reading the patch - I haven't actually tried this.) Signed-off-by:
Werner Almesberger <werner@almesberger.net> Signed-off-by:
-
Werner Almesberger authored
Export prio_tree functions such that they can be used by other subsystems than only VMAs. Also adds a mode to prio_tree to use it with keys explicitly included in the prio_tree meta-data. The plan is to also consider converting VMAs to use explicit keys, so that the old "raw" mode can be removed. Signed-off-by:
-
Werner Almesberger authored
Allow prio_tree_next to be used as the only function for tree traversal, similar to how vma_prio_tree_next works. This patch isn't needed for the generalization, but since it affects the API, it's better to include it first. Signed-off-by:
-
Andrew Morton authored
Pass the "we are doing synchronous writes" hint down from msync(). Signed-off-by:
-
Zou Nanhai authored
- Merge sys32_rt_sigtimedwait function in X86_64, IA64, PPC64, MIPS, SPARC64, S390 32 bit layer into 1 compat_rt_sigtimedwait function. It will also fix a bug of copy wrong information to 32 bit userspace siginfo structure on X86_64, IA64 and SPARC64 when calling sigtimedwait on 32 bit layer. - Change all name the of siginfo_t32 structure in X86_64, IA64, MIPS, SPARC64 and S390 to the name compat_siginfo_t as used in PPC64. - Patch introduced a macro __COMPAT_ENDIAN_SWAP__ in include/asm-mips/compat.h when MIPS kernel is compiled in little-endian mode. This macro is used to do byte swapping in function sigset_from_compat. - This patch is only tested on X86_64 and IA_64. Signed-off-by:
Zou Nan hai <Nanhai.zou@intel.com> Signed-off-by:
-
Christoph Hellwig authored
ext3_put_inode has been removed a while ago. Signed-off-by:
-
Christoph Hellwig authored
UDF discards file preallocations on every ->put_inode which is totally bogus. It already discards them in ->release which makes sense for normal writes, so the only additional discard is in ->clear_inode so we make sure we don't leak any reservations for shared writeable mappings. This follows similar changes to ext2 and ext3. Signed-off-by:
-
Christoph Hellwig authored
udf_iget calls __udf_read_inode after the inode has been unlocked and other threads could access it. Switching to iget_locked() fixes this race and nicely simplifies the code. Signed-off-by:
-
Zwane Mwaikambo authored
Introduce cpu_idle_wait() on architectures requiring modification of pm_idle from modules, this will ensure that all processors have updated their cached values of pm_idle upon exit. This patch is to address the bug report at http://bugme.osdl.org/show_bug.cgi?id=1716 and replaces the current code fix which is in violation of normal RCU usage as pointed out by Stephen, Dipankar and Paul. Signed-off-by:
Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by:
-
Chris Mason authored
When a block device is accessed via read/write, it is possible for some of the buffers on a page to be mapped and others not. __getblk and friends assume this can't happen, and can end up looping forever when pages have some unmapped buffers. Picture: lseek(/dev/xxx, 2048, SEEK_SET) write(/dev/xxx, 2048 bytes) Assuming the block size is 1k, page 0 has 4 buffers, two are mapped by __block_prepare_write and two are not. Next, another process triggers getblk(/dev/xxx, blocknr = 0); __getblk_slow will loop forever. __find_get_block fails because the buffer isn't mapped. grow_dev_page does nothing because there are buffers on the page with the correct size. madhav@veritas.com and others at Veritas tracked this down. The fix below has two parts. First, it changes __find_get_block to avoid the buffer_error warnings when it finds unmapped buffers on the page. Second, it changes grow_dev_page to map the buffers on the page by calling init_page_buffers. init_page_buffers is changed so we don't stomp on uptodate bits for the buffers. Signed-off-by:
-
Kenji Kaneshige authored
This is an ia64 portion of IRQ resource deallocation. It implements pcibios_disable_device() and acpi_unregister_gsi() for ia64. o acpi_unregister_gsi() Summary of changes for implementing this interface: - Add new function iosapic_unregister_intr() into arch/ia64/kernel/iosapic.c. This function frees an interrupt vector and related data structures. - Add new function free_irq_vector() into arch/ia64/kernel/irq_ia64.c. This frees an unused vector. - Change assign_irq_vector() to be able to support free_irq_vector(). o pcibios_disable_device() This calls acpi_pci_irq_disable() to deallocate IRQ resources. Signed-off-by:Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
Architecture dependent IRQ resources such as interrupt vector for PCI devices are allocated at pci_enable_device() time on i386, x86-64 and ia64 platform. Today, however, these IRQ resources are never deallocated even if they are no longer used. The following set of patches adds supports to deallocate IRQ resources at pci_disable_device() time. The motivation of the set of patches is as follows: - IRQ resources such as interrupt vectors should be freed if they are no longer used because the amount of these resources are limited. By deallocating IRQ resources, we can recycle them. - I think some hardwares will support hot-pluggable I/O units with I/O xAPICs in the near future. So I/O xAPIC hot-plug support by OS will be needed soon. IRQ resouces deallocation will be one of the most important stuff for I/O xAPIC hot-plug. For now, the following set of patches has ia64 implementation only. i386 and x86_64 implementations are TBD. This patch is ACPI portion of IRQ deallocation. This patch defines the following new interface. The implementation of this interface depends on each platform. o void acpi_unregister_gsi(u32 gsi) This is a opposite portion of acpi_register_gsi(). This has a responsibility for deallocating IRQ resources associated with the specified GSI number. We need to consider the case of shared interrupt. In the case of shared interrupt, acpi_register_gsi() is called multiple times for one gsi. That is, registrations and unregistrations can be nested. This function undoes the effect of one call to acpi_register_gsi(). If this matches the last registration, IRQ resources associated with the specified GSI number are freed. This patch also adds the following new function. o void acpi_pci_irq_disable (struct pci_dev *dev) This function is a opposite portion of acpi_pci_enable_irq(). It clears the device's linux IRQ number and calls acpi_unregister_gsi() to deallocate IRQ resources. Signed-off-by: -
Manfred Spraul authored
My patch that removed the spin_lock calls from the tail of sys_semtimedop introduced a bug: Before my patch was merged, every operation that altered an array called update_queue. That call woke up threads that were waiting until a semaphore value becomes 0. I've accidentially removed that call. The attached patch fixes that by modifying update_queue: the function now loops internally and wakes up all threads. The patch also removes update_queue calls from the error path of sys_semtimedop: failed operations do not modify the array, no need to rescan the list of waiting threads. Signed-Off-By:
Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Andreas Gruenbacher authored
Keith Young <stripyd@stripydog.com> has reported that when ACLs are not compiled in, the default implementation of ext[23]_init_acl applies the umask to all new files, including symlinks, which is wrong. In this case the VFS already takes care of applying the umask when needed, so ext2 and ext3 need not bother about it. Remove the superfluous statements. Signed-off-by:
Andreas Gruenbacher <agruen@suse.de> Signed-off-by:
-
Andrew Morton authored
- Move prototype to genhd.h - It is only needed for /proc Signed-off-by:
-
Stephen Rothwell authored
Since asm-generic/siginfo.h was created, the architectures have been slowly fixed/modified until noone uses HAVE_ARCH_SI_CODES or HAVE_ARCH_SIGEVENT_T any more, so this patch removes the checks for them. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Franz Pletz authored
With Andries Brouwer <Andries.Brouwer@cwi.nl> Fix various recursion scenarios wherein it was possible to mount a loop device on itself, either directly or via intermediate loops devices. Signed-off-by:
-
Pekka Enberg authored
This patch removes unused includes from drivers/block/noop-iosched.c. Signed-off-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Pekka Enberg authored
This patch makes code static in drivers/block/noop-iosched.c and adds __init and __exit for module initialization and cleanup functions. Signed-off-by:
-
Randy Dunlap authored
When setting the 'cpu_isolated_map' mask, check that the user input value is valid (in range 0 .. NR_CPUS - 1). Also fix up kernel-parameters.txt for this parameter. Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Zwane Mwaikambo authored
__handle_sysrq was modified to do a spin_lock_irqsave so we were entering smp_send_stop with interrupts. So reenable interrupts to prevent the possible smp_call_function() deadlock. (It's still deadlocky if the sysrq handler is against called via an interrupt from a different device, but that seems unlikely). Signed-off-by:
Zwane Mwaikambo <zwane@holomorphy.com> Signed-off-by:
-
Prasanna Meda authored
A while back we added the PR_SET_NAME prctl, but no PR_GET_NAME. I guess we should add this, if only to enable testing of PR_SET_NAME. Signed-off-by:
Prasanna Meda <pmeda@akamai.com> Signed-off-by:
-
Randy Dunlap authored
Move 'panic_timeout' to linux/kernel.h. ipmi_watchdog.c wanted to know why panic_timeout isn't in some header file. However, ipmi_watchdog.c doesn't even use it, so that reference was deleted. Other references now use kernel.h instead of straight extern int. Signed-off-by:
-
Matt Domsch authored
EDD: add edd=off and edd=skipmbr command line options New command line options edd=off (or edd=of) edd=skipmbr (or edd=sk) runtime options for disabling all EDD int13 calls completely, or for skipping the int13 READ SECTOR calls, respectively. These are provided to allow Linux distributions to include CONFIG_EDD=m, yet allow end-users to disable parts of EDD which may not work well with their system's BIOS. I incorporated comments from Randy Dunlap, and got an ack from Andi Kleen. Signed-off-by:
Matt Domsch <Matt_Domsch@dell.com> Signed-off-by:
-
J. A. Magallon authored
I need this to make gconfig work under gtk-2.4. Without this, it just coredumps. There is some problem with pixmap creation/usage from XPM in the way it is done in gconf, so I just added some stock icons. It is even prettier..;) Could someone test this still works on gtk-2.0 or 2.2 ? Changes: - change the wiget class 'button' in glade files to something known to glade (GtkToolButton) - use 'stock-id' property for toolbar buttons instead of "stock_pixmap" - change unknown signal "pressed" to "clicked" - remove manual setting of icons in gconf.c Signed-off-by:
-
Rusty Russell authored
Return EINVAL for invalid sched_setaffinity on UP. I was a little surprised that sys_sched_setaffinity for CPU 1 didn't fail on my UP box. With CONFIG_SMP it would have. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Tvrtko A. Ursulin authored
Correctly propagate the return value from smb_open(). Signed-off-by:
-
Manfred Spraul authored
Based on an initial patch from Oleg Nesterov <oleg@tv-sign.ru> rcu_data.last_qsctr is not needed. Actually, not even a counter is needed, just a flag that indicates that there was a quiescent state. Signed-Off-By:
-
Manfred Spraul authored
The patch below makes two needlessly global structs static. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Oleg Nesterov authored
rcu_ctrlblk.lock is used to read the ->cur and ->next_pending atomically in __rcu_process_callbacks(). It can be replaced by a couple of memory barriers. rcu_start_batch: rcp->next_pending = 0; smp_wmb(); rcp->cur++; __rcu_process_callbacks: rdp->batch = rcp->cur + 1; smp_rmb(); if (!rcp->next_pending) rcu_start_batch(rcp, rsp, 1); This way, if __rcu_process_callbacks() sees incremented ->cur value, it must also see that ->next_pending == 0 (or rcu_start_batch() is already in progress on another cpu). Signed-off-by:
-
Adrian Bunk authored
drivers/char/ip2/ contained three programs. Besides shipping programs at this place doesn't sound like a good idea, they didn't even all compile. The patch below removes them. Signed-off-by:
-
Andi Kleen authored
This patch corrects a problem that was originally added with the nanosecond timestamps in stat patch. The problem is that some file systems don't have enough space in their on disk inode to save nanosecond timestamps, so they truncate the c/a/mtime to seconds when flushing an dirty node. In core the inode would have full jiffies granuality. This can be observed by programs as a timestamp that jumps backwards under specific loads when an inode is flushed and then reloaded from disk. The problem was already known when the original patch went in, but it wasn't deemed important enough at that time. So far there has been only one report of it causing problems. Now Tridge is worried that it will break running Excel over samba4 because Excel seems to do very anal timestamp checking and samba4 will supply 100ns timestamps over the network. This patch solves it by putting the time resolution into the superblock of a fs and always rounding the in core timestamps to that granuality. This also supercedes some previous ext2/3 hacks to flush the inode less often when only the subsecond timestamp changes. I tried to keep the overhead low, in particular it tries to keep divisions out of fast paths as far as possible. The patch is quite big but 99% of it is just relatively straight forward search'n'replace in a lot of fs. Unconverted filesystems will default to a 1ns granuality, but may still show the problem if they continue to use CURRENT_TIME. I converted all in tree fs. One possible future extension of this would be to have two time granualities per superblock - one that specifies the visible resolution, and the other to specify how often timestamps should be flushed to disk, which could be tuned with a mount option per fs (e.g. often m/atimes don't need to be flushed every second). Would be easy to do as an addon if someone is interested. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Martin Schwidefsky authored
I realized that the best way to get the sys_time/sys_stime problem fixed is to make sys_time 64 bit safe by using "time_t *" instead of "int *" and to introduce two proper compat functions compat_sys_time and compat_sys_stime. The prototype change of sys_time is transparent for 32 bit architectures because both "int" and "time_t" are 32 bit. For 64 bit the type change would be wrong but luckily no 64 bit architecture uses sys_time/sys_stime in 64 bit mode. The patch makes the following change: ia64 : Remove sys32_time, use compat_sys_time and add (!!) compat_sys_stime to compat syscall table. mips : Use compat_sys_time/compat_sys_stime in 32 bit syscall table. Add #ifdef magic to compile sys_time/sys_stime and compat_sys_time/compat_sys_stime only if needed. parisc : Remove sys32_time, use compat_sys_time and compat_sys_stime. ppc64 : remove sys32_time, ppc64_sys32_stime and ppc64_sys_stime. Use common compat_sys_time, compat_sys_stime and sys_stime. s390 : Use compat_sys_stime. Add #ifdef magic to compile sys_time/sys_stime and compat_sys_time/compat_sys_stime only if needed. sparc64 : Use compat_sys_time/compat_Sys_stime in 32 bit syscall table. um : Remove um_time and um_stime. Use common functions sys_time and sys_stime. This adds a CAP_SYS_TIME check to UMs stime call. x86_64 : Remove sys32_time. Use compat_sys_time and compat_sys_stime in 32 bit syscall table. The original stime bug is fixed for mips, parisc, s390, sparc64 and x86_64. Can the arch-maintainers please take a look at this? From: Martin Schwidefsky <schwidefsky@de.ibm.com> Convert compat_time_t to time_t in 32 bit emulation for sys_stime and consolidate all the different implementation of sys_time, sys_stime and their 32-bit emulation parts. Signed-off-by:Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
