- 27 Aug, 2004 40 commits
-
-
Peter Oberparleiter authored
sclp driver changes: - Add reboot notifier to reset the sclp send/receive masks on shutdown. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Steffen Thoss authored
common i/o layer change: - Correct check in qdio_stop_polling to avoid loosing initiative on the qdio inbound queue. Signed-off-by:
-
Frank Pavlic authored
lcs network driver changes: - Allocate the reply structure instead of taking it from the stack. - Use del_timer_sync instead of del_timer. - Clean up helper threads creation/shutdown. - Split lcs_register_mc_addresses to make it readable again. - Free multicast list entries when device is going down. - Retransmit multicast list in device recovery. Signed-off-by:
-
Thomas Richter authored
Add support for netmos devices to the parallel port driver. NetMOS 9805 support is already in the kernel, this patch adds the support for the missing 9735,9855,9755 and 9715 chips. And another remark: The 9735 and 9835 seem to be chips with serial *and* parallel interfaces, so I suppose they are already claimed somewhere in the serial driver. I don't know whether this causes any problems. I'm sorry that I can't test, I've only a 9805 here. Any idea how these "dual" chips have to be handled by the kernel? Signed-off-by:
-
Torben Mathiasen authored
Patch brings devices.txt up-to-date with LANANA. Signed-off-by:
-
Torben Mathiasen authored
I took over LANANA maintainership from John Cagle. Patch updates MAINTAINERS accordingly. Signed-off-by:
-
Andrew Morton authored
As David M-T points out, the default per-user mlock limit should be at least a single page. Signed-off-by:
-
William Lee Irwin III authored
Unaccount VM_DONTCOPY vmas properly; the child inherits the whole of the parent's virtual accounting from the memcpy() in copy_mm(), but the VM_DONTCOPY check here is where a decision is made for the child not to inherit the vmas corresponding to some accounted memory usages. Hence, unaccount them when skipping over them here. Signed-off-by:
-
William Lee Irwin III authored
Account reserved memory properly as per acahalan's speecified semantics. Signed-off-by:
-
William Lee Irwin III authored
Remove the accounting overhead when CONFIG_PROC_FS is not defined. Signed-off-by:
-
William Lee Irwin III authored
Some kind of brainfart happened here, though it's not visible on the default display from top(1) etc. This patch fixes up the gibberish I mistakenly put down for text with the proper text size, and subtracts it from data as per the O(vmas) code beforehand. Signed-off-by:
-
William Lee Irwin III authored
Merely removing down_read(&mm->mmap_sem) from task_vsize() is too half-assed to let stand. The following patch removes the vma iteration as well as the down_read(&mm->mmap_sem) from both task_mem() and task_statm() and callers for the CONFIG_MMU=y case in favor of accounting the various stats reported at the times of vma creation, destruction, and modification. Unlike the 2.4.x patches of the same name, this has no per-pte-modification overhead whatsoever. This patch quashes end user complaints of top(1) being slow as well as kernel hacker complaints of per-pte accounting overhead simultaneously. Signed-off-by:
-
William Lee Irwin III authored
task_vsize() doesn't need mm->mmap_sem for the CONFIG_MMU case; the semaphore doesn't prevent mm->total_vm from going stale or getting inconsistent with other numbers regardless. Also, KSTK_EIP() and KSTK_ESP() don't want or need protection from mm->mmap_sem either. So this pushes mm->mmap_sem to task_vsize() in the CONFIG_MMU=n task_vsize(). Also, hoist the prototype of task_vsize() into proc_fs.h The net result of this is a small speedup of procps for CONFIG_MMU. Signed-off-by:
-
Dave Hansen authored
asm/page.h seems to be the accepted place to declare virt_to_page() on a vast majority of architectures. This patch makes sure that a few files which use that function also directly include the header. Signed-off-by:
Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
-
Dave Hansen authored
__pa() is always be consistent inside of a single page. The next thing virt_to_page() does after that is shift down the address, killing the bits that __change_page_attr() just masked off. Remove the superfluous masking. Signed-off-by:
-
Dave Hansen authored
Store the physical pgd address in a different variable than the virtual address. There's no real reason to only use 1 variable here, other than saving a line of code. But, the types really are different and we might as well just spell that out explicitly. Signed-off-by:
-
Dave Hansen authored
I'm sure there's a good reason for these functions to take virtual addresses as unsigned longs, so suppress the warnings and cast them to the proper types before calling the virt/phys conversion functions A perfectly acceptable alternative would be to go and change free_pages() to stop taking unsigned longs for virtual addresses, but this has a much smaller impact. Signed-off-by:
-
Dave Hansen authored
__pa() should take a void*. This adds the proper cast. Signed-off-by:
-
Dave Hansen authored
Ran across this because it's another place where an unsigned long is passed directly to __pa(). Making the "page" variable a void* seems a bit more natural than an unsigned long and reduces the net number of casts by 1. Without it, we probably need another (void *) cast in the __pa() call. For more explanation as to why this was probably done originally, see this post: http://marc.theaimsgroup.com/?l=linux-mm&m=109155379124628&w=2Signed-off-by:
-
Pierre Ossman authored
The kernel currently allocates the range 0x40-0x5f for timer calls. This causes conflicts with other hardware using these ports (In my case a Winbond W83L519D SD/MMC card reader). This patch splits the resource into the ports actually needed. Signed-off-by:
-
John Levon authored
Anton prompted me to get this patch merged. It changes the core buffer sync algorithm of OProfile to avoid global locks wherever possible. Anton tested an earlier version of this patch with some success. I've lightly tested this applied against 2.6.8.1-mm3 on my two-way machine. The changes also have the happy side-effect of losing less samples after munmap operations, and removing the blind spot of tasks exiting inside the kernel. Signed-off-by:
-
Andrew Morton authored
davem says that copy_mount_options is failing in obscure ways if the architecture's copy_from_user() doesn't return an exact count of the number of uncopied bytes. Fixing that up in each architecture is a pain - it involves falling back to byte-at-a-time copies. It's simple to open-code this in namespace.c. If we find other places in the kernel which care about this we can promote this to a global function. Signed-off-by:
-
Roland McGrath authored
When the initial thread in a multi-threaded program dies (the thread group leader), its child processes are wrongly orphaned, and thereafter when other threads die their child processes are also orphaned even though live threads remain in the parent process that can call wait. I have a small (under 100 lines), POSIX-compliant test program that demonstrates this using -lpthread (NPTL) if anyone is interested in seeing it. The bug is that forget_original_parent moves children to the dead parent's group leader if it's alive, but if not it orphans them. I've changed it so it instead reparents children to any other live thread in the dead parent's group (not even preferring the group leader). Children go to init only if there are no live threads in the parent's group at all. These are the correct semantics for fork children of POSIX threads. The second part of the change is to do the CLONE_PARENT behavior always for CLONE_THREAD, i.e. make sure that each new thread's parent link points to the real parent of the process and never another thread in its own group. Without this, when the group leader dies leaving a sole live thread in the group, forget_original_parent will try to reparent that thread to itself because it's a child of the dying group leader. Rather handling this case specially to reparent to the group leader's parent instead, it's more efficient just to make sure that noone ever has a parent link to inside his own thread group. Now the reparenting work never needs to be done for threads created in the same group when their creator thread dies. The only change from losing the who-created-whom information is when you look at "PPid:" in /proc/PID/task/TID/status. For purposes of all direct system calls, it was already as if CLONE_THREAD threads had the parent of the group leader. (POSIX provides no way to keep track of which thread created which other thread with pthread_create.) Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Rusty Russell authored
MODULE_PARM() was marked obsolete. Remove it from everything except drivers/ and arch/. Naturally, such a widespread change may introduce bugs for some of the non-trivial cases, and where in doubt I used "0" as permissions arg (ie. won't appear in sysfs). Individual authors should think about whether that would be useful. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Jeff Mahoney authored
I saw a recent bug report that showed when a process set up a dnotify against the autofs root and then attempted an access(2) call inside the autofs namespace on a mount that would fail, it would create a signal/restart loop. The cause is that the autofs code checks to see if any signals are pending after it waits on a response from the autofs daemon. If it finds any, it assumes that autofs_wait was interrupted, and that it should return -ERESTARTNOINTR. The problem with this is that a signal_pending(current) check will return true if *any* signals were received, not just if a signal that interrupted the wait was received. autofs_wait explicitly blocks all signals except for SIGKILL, SIGQUIT, and SIGINT before calling interruptible_sleep_on. The effect is that if a dnotify is set against the autofs root, when the autofs daemon creates the directory, a dnotify event will be sent to the originating process. Since the code in autofs_root_lookup doesn't check to see what signals are actually pending, it bails early, telling the caller to try again. The loop goes on forever until interrupted via one of the actual interrupting signals. The following patch makes both autofs_root_lookup and autofs4_root_lookup verify that one of its defined "shutdown" signals are pending before bailing out early. Any other signal should be delivered later, as expected. It doesn't matter if the signal occured outside of the sleep in autofs_wait. The calling process will either go away or try again. Signed-off-by:
-
Hugh Dickins authored
tmpfs must use __copy_from_user_inatomic now, to avoid might_sleep warning, when knowingly using __copy_from_user with an atomic kmap. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Ingo Molnar authored
Add a whole bunch more might_sleep() checks. We also enable might_sleep() checking in copy_*_user(). This was non-trivial because of the "copy_*_user() in atomic regions" trick would generate false positives. Fix that up by adding a new __copy_*_user_inatomic(), which avoids the might_sleep() check. Only i386 is supported in this patch. With: Arjan van de Ven <arjanv@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
David Gibson authored
After the recent SLB and STAB cleanups, the ppc64 KERNEL_CONTEXT() macro is no longer used anywhere. This patch removes it. Signed-off-by:
David Gibson <dwg@au1.ibm.com> Signed-off-by:
-
Kumar Gala authored
Refefactor common Book-E exception handling macros into a single file to reduce code duplication. Signed-off-by:
Kumar Gala <kumar.gala@freescale.com> Signed-off-by:
-
Anton Blanchard authored
Reduce the size of struct inode on 64bit architectures by reducing padding. This assumes spinlocks are 32bit or less which is the case on most architectures. This reduces inode structs by 24 bytes on ppc64, and on ext2 increases the number of inodes in a 4kB slab from 5 to 6. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Andrew Morton authored
The megaraid driver is calling these, but they don't exist if !CONFIG_COMPAT. Add the necessary stubs, and clean a few things up. Signed-off-by:
-
William Lee Irwin III authored
From: Anton Blanchard <anton@samba.org> - Remove iseries specific profiling, there were no complaints when I suggested removal on the linuxppc64 list a few weeks ago. - Also remove another instance of that pesky abs() function. Signed-off-by:
-
William Lee Irwin III authored
Convert prof_buffer to an array of atomic_t instead of sometimes atomic_t, sometimes unsigned int. Also, bootmem rounds up internally, so blow away some crap code there. Signed-off-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
William Lee Irwin III authored
Make the various bits of state no longer used anywhere else static to kernel/profile.c Signed-off-by:
-
William Lee Irwin III authored
proc_misc.c is a trainwreck. Move the file_operations for /proc/profile into kernel/profile.c and call the profiling setup via initcall. Signed-off-by:
-
William Lee Irwin III authored
With prof_cpu_mask and profile_pc() in hand, the core is now able to perform all the profile accounting work on behalf of arches. Consolidate the profile accounting and convert all arches to call the core function. Signed-off-by:
-
William Lee Irwin III authored
The program counter calculation from pt_regs is the only portion of profile accounting that differs across various architectures. This is usually instruction_pointer(regs), but to handle the few arches where it isn't, introduce profile_pc(). Signed-off-by:
-
William Lee Irwin III authored
Handling of prof_cpu_mask is grossly inconsistent. Some arches have it as a cpumask_t, others unsigned long, and even within arches it's treated inconsistently. This makes it cpumask_t across the board, and consolidates the handling in kernel/profile.c Signed-off-by:
-
Arjan van de Ven authored
From: William Lee Irwin III <wli@holomorphy.com> The patch (from Ingo) below is quite interesting, it allows the use of readprofile not for statistical tine sampling, but for seeing where calls to schedule() come from, so it can give some insight to the "where do my context switches come from" question. Boot with `profile=schedul2' to activate this feature. Signed-off-by:
-
Rusty Russell authored
release_task can sleep. Sleeping allows a CPU to go down underneath you. release_task removes you from the tasklist, so you don't get migrated off the CPU: BUG() in sched.c. In last week's episode, our dashing hero (Ingo Molnar) solved this for self-reaping tasks by grabbing the hotplug cpu lock to prevent this. However, in an unexpected twist, the problem remains for tasks whose parents call release_task on them: the zombies are off the task list, and lurk on the dead CPU. Fortunately, the comedic sidekick (Rusty Russell) has an answer: let's make the hotplug callback walk the runqueue of the dead CPU as well, taking care of the zombies. 1) Restore exit.c to its former form. The comment is incorrect: sched.c checks PF_DEAD, not the state, to decide to do the final put_task_struct(), and it does it for all tasks, self-reaping or no. 2) Implement migrate_dead_tasks() in the sched.c hotplug CPU callback. 3) Rename migrate_all_tasks() to migrate_live_tasks(). Signed-off-by:
-
