- 18 Oct, 2004 40 commits
-
-
Paul Mundt authored
This updates some of the sh DMA drivers and core API. Previously modules had to register for the channels they were interested in, but now it's dealt with transparently by the API with only the number of physical channels needing to be specified by each module. Signed-off-by:
Paul Mundt <paul.mundt@nokia.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Paul Mundt authored
Nothing exciting here.. random defconfig updates, as well as a few new ones for microdev and ctp/pci-sh03. Signed-off-by:
-
Paul Mundt authored
This gets rid of the hardcoded workarounds for the Dreamcast in the dma-mapping code, and now wraps into the common consistent_alloc() and consistent_free() routines if the ones in the machvec aren't interested in handling it. Signed-off-by:
-
Paul Mundt authored
This basically follows the same change as for sh64 and adds asm-offsets to sh. Some hardcoded thread_info struct offsets get cleaned up by this. Signed-off-by:
-
Paul Mundt authored
This fixes up the existing SH7705 support and enables the 32k cache mode for the processor. Signed-off-by:
Alex Song <songqf9@yahoo.ca> Signed-off-by:
-
Paul Mundt authored
This adds support for the SH73180 subtype (sh4a). Signed-off-by:
Hiroshi DOYU <Hiroshi_DOYU@montavista.co.jp> Signed-off-by:
-
Paul Mackerras authored
This patch fixes a problem where my new powerbook would sometimes hang or crash when changing CPU speed. We had schedule_timeout(HZ/1000) in there, intended to provide a delay of one millisecond. However, even with HZ=1000, it was (I believe) only waiting for the next jiffy before proceeding, which could be less than a millisecond. Changing the code to use msleep, and specifying a time of 1 jiffy + 1ms has fixed the problem. (When I looked at the msleep code, it appeared to me that msleep(1) with HZ=1000 would sleep for between 0 and 1ms.) Ben also asked me to remove the code that changes the AACK delay enable, after looking in the Darwin sources and seeing that Darwin does not change this in its corresponding code. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Matt Porter authored
This patch enables/disables the PPC440GX L2 cache based on errata which prevents reliable operation on certain CPU revisions and speed grades. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Matt Porter authored
Add a missing include file for gen550. Signed-off-by:
-
Matt Porter authored
Use gen550 for early PPC progress messages and for the in-kernel ppc-stub.c on PPC44x. Signed-off-by:
-
Andrei Konovalov authored
Adds minimal Xilinx ML300 board support (enough to boot with ramdisk). The only peripheral devices supported are 16x50 compatible UARTs. Signed-off-by:
Andrei Konovalov <akonovalov@ru.mvista.com> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
-
Jens Axboe authored
invalidate_inode_pages() and invalidate_inode_pages2() can mark pages not uptodate while read() is trying to read from them. This is interpreted as an I/O error. Fix that by teaching the invalidate code to leave the page alone if someone else has a ref on it. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Ingo Molnar authored
The patch below removes stale references to kernel/hardirq.c in comments, remnants of the earlier iterations of the generic irq subsystem code. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ingo Molnar authored
ppc64 port of generic hardirq handling. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Ingo Molnar authored
ppc32 port of generic hardirq handling. Signed-off-by:
-
Ingo Molnar authored
x86_64 port of generic hardirq handling. Signed-off-by:
-
Ingo Molnar authored
x86 port of generic hardirq handling. akpm: (in response to build errors) - remove APIC_MISMATCH_DEBUG altogether. Just make it synonymous with CONFIG_X86_IO_APIC - Move the definition of irq_mis_count over to io_apic.c Signed-off-by:
-
Ingo Molnar authored
The main goal of this patch is to consolidate all the different but still fundamentally similar arch/*/kernel/irq.c code into the kernel/irq/ subsystem. There are 4 new files in the kernel/irq/ directory: - handle.c: core bits: __do_IRQ() and handle_IRQ_event(), callable from arch-specific irq.c code. - manage.c: the main driver apis - spurious.c: the handling of buggy interrupt sources. - autoprobe.c: probing of interrupts - older code but still in use. - proc.c: /proc/irq/ code. - internals.h for irq-core-internal interfaces not visible to drivers nor arch PIC code. An architecture enables the generic hardirq code by defining CONFIG_GENERIC_HARDIRQS in its arch Kconfig. People doing this conversion should check out the x86/x64/ppc/ppc64 patches for details - the conversion is quite straightforward but every converted function (i.e. every function removed from the arch irq.c) _must_ be matched to the generic version and if there is any detail that the generic code should do it has to be added to the generic code. All of the currently converted 4 architectures were converted like that, and the generic code was extended/fixed along the way. Other changes related to this patchset: - clean up the irq include files (linux/irq.h, linux/interrupt.h, linux/hardirq.h) and consolidate asm-*/[hard]irq.h. Note, to keep all non-touched architectures in an untouched state this consolidation is done carefully and strictly under CONFIG_GENERIC_HARDIRQS. Once the consolidation is done we can do a couple of final cleanups to reach the following logical splitup of 3 include files: linux/interrupt.h: driver-visible APIs and details linux/irq.h: core irq and arch-PIC code, internals asm-*/irq.h: arch PIC and irq delivery details the following include files will likely vanish: linux/hardirq.h merges into linux/irq.h asm-*/hardirq.h: merges into asm-*/irq.h asm-*/hw_irq.h: merges into asm-*/irq.h Christoph would like to do these once the current wave of cleanups gets in. Signed-off-by: -
Gregory Kurz authored
Take a process P1 that spawns a thread T (aka. a clone with CLONE_FILES). If P1 forks another process P2 (aka. not a clone) while T is blocked in a open() that should return file descriptor FD, then FD will be unusable in P2. This leads to strange behaviors in the context of P2: close(FD) returns EBADF, while dup2(a_valid_fd, FD) returns EBUSY and of course FD is never returned again by any syscall... testcase: #include <errno.h> #include <fcntl.h> #include <sched.h> #include <signal.h> #include <string.h> #include <sys/stat.h> #include <sys/types.h> #include <unistd.h> #include <asm/page.h> #define FIFO "/tmp/bug_fifo" #define FD 0 /* * This program is meant to show that calling fork() while a clone spawned * with CLONE_FILES is blocked in open() makes a fd number unusable in the * child. * * * Parent Clone Child * | * clone(CLONE_FILES)-
-
Ingo Molnar authored
Fix mismerge of the "prof=schedule" feature. Without this patch the output is a boring empty profile. Signed-off-by:
-
Chris Mason authored
On small filesystems (<128M), make sure not to reference bitmap blocks that don't exist. Thanks to Jan Kara for finding this bug. Signed-off-by:
-
Hugh Dickins authored
Marcelo noticed that the BUG_ON in __set_page_dirty_nobuffers doesn't make much sense: it lost its way in 2.6.7, amidst so many page_mappings! It's supposed to be checking that, although page->mapping may suddenly go NULL from truncation, and although tmpfs swizzles page_mapping(page) between tmpfs inode address_space and swapper_space, there's sufficient stabilization while here in __set_page_dirty_nobuffers that the mapping after we locked mapping->tree_lock is the same as the mapping before we locked mapping->tree_lock i.e. the lock we hold is the right one. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Roland McGrath authored
I've found some problems with exec and fixed them with this patch to de_thread. The second problem is that a multithreaded exec loses all pending signals. This is violation of POSIX rules. But a moment's thought will show it's also just not desireable: if you send a process a SIGTERM while it's in the middle of calling exec, you expect either the original program in that process or the new program being exec'd to handle that signal or be killed by it. As it stands now, you can try to kill a process and have that signal just evaporate if it's multithreaded and calls exec just then. I really don't know what the rationale was behind the de_thread code that allocates a new signal_struct. It doesn't make any sense now. The other code there ensures that the old signal_struct is no longer shared. Except for posix-timers, all the state there is stuff you want to keep. So my changes just keep the old structs when they are no longer shared, and all the right state is retained (after clearing out posix-timers). The final bug is that the cumulative statistics of dead threads and dead child processes are lost in the abandoned signal_struct. This is also fixed by holding on to it instead of replacing it. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Lev Makhlis authored
Add up resource usage counters for live and dead threads to show aggregate per-process usage in /proc/<pid>/stat. This mirrors the new getrusage() semantics. /proc/<pid>/task/<tid>/stat still has the per-thread usage. After moving the counter aggregation loop inside a task->sighand lock to avoid nasty race conditions, it has survived stress-testing with '(while true; do sleep 1 & done) & top -d 0.1' Signed-off-by:
Lev Makhlis <mlev@despammed.com> Signed-off-by:
-
Albert Cahalan authored
This patch adjusts /proc/*/stat to have distinct per-process and per-thread CPU usage, faults, and wchan. Signed-off-by:
Albert Cahalan <albert@users.sf.net> Signed-off-by:
-
Arnd Bergmann authored
I found that the prototypes for sys_waitid and sys_fcntl in <linux/syscalls.h> don't match the implementation. In order to keep all prototypes in sync in the future, now include the header from each file implementing any syscall. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ingo Molnar authored
The attached patch fixes a local_bh_enable() buglet: we first enabled softirqs then did we do local_softirq_pending() - often this is preemptible code. So this task could be preempted and there's no guarantee that softirq processing will occur (except the periodic timer tick). The race window is small but existent. This could result in packet processing latencies or timer expiration latencies - hard to detect and annoying bugs. The fix is to invoke softirqs with softirqs enabled but preemption still disabled. Patch is against 2.6.9-rc2-mm1. Signed-off-by:
-
Roland McGrath authored
There is a race between PTRACE_ATTACH and the real parent calling wait. For a moment, the task is put in PT_PTRACED but with its parent still pointing to its real_parent. In this circumstance, if the real parent calls wait without the WUNTRACED flag, he can see a stopped child status, which wait should never return without WUNTRACED when the caller is not using ptrace. Here it is not the caller that is using ptrace, but some third party. This patch avoids this race condition by adding the PT_ATTACHED flag to distinguish a real parent from a ptrace_attach parent when PT_PTRACED is set, and then having wait use this flag to confirm that things are in order and not consider the child ptraced when its ->ptrace flags are set but its parent links have not yet been switched. (ptrace_check_attach also uses it similarly to rule out a possible race with a bogus ptrace call by the real parent during ptrace_attach.) While looking into this, I noticed that every arch's sys_execve has: current->ptrace &= ~PT_DTRACE; with no locking at all. So, if an exec happens in a race with PTRACE_ATTACH, you could wind up with ->ptrace not having PT_PTRACED set because this store clobbered it. That will cause later BUG hits because the parent links indicate ptracedness but the flag is not set. The patch corrects all the places I found to use task_lock around diddling ->ptrace when it's possible to be racing with ptrace_attach. (The ptrace operation code itself doesn't have this issue because it already excludes anyone else being in ptrace_attach.) Signed-off-by:
-
Roland McGrath authored
POSIX specifies the new WCONTINUED flag for waitpid, not just for waitid. I overlooked this addition when I implemented waitid. The real work was already done to support waitid, but waitpid needs to report the results Signed-off-by:
-
Roland McGrath authored
POSIX specifies that the limit settings provided by getrlimit/setrlimit are shared by the whole process, not specific to individual threads. This patch changes the behavior of those calls to comply with POSIX. I've moved the struct rlimit array from task_struct to signal_struct, as it has the correct sharing properties. (This reduces kernel memory usage per thread in multithreaded processes by around 100/200 bytes for 32/64 machines respectively.) I took a fairly minimal approach to the locking issues with the newly shared struct rlimit array. It turns out that all the code that is checking limits really just needs to look at one word at a time (one rlim_cur field, usually). It's only the few places like getrlimit itself (and fork), that require atomicity in accessing a whole struct rlimit, so I just used a spin lock for them and no locking for most of the checks. If it turns out that readers of struct rlimit need more atomicity where they are now cheap, or less overhead where they are now atomic (e.g. fork), then seqcount is certainly the right thing to use for them instead of readers using the spin lock. Though it's in signal_struct, I didn't use siglock since the access to rlimits never needs to disable irqs and doesn't overlap with other siglock uses. Instead of adding something new, I overloaded task_lock(task->group_leader) for this; it is used for other things that are not likely to happen simultaneously with limit tweaking. To me that seems preferable to adding a word, but it would be trivial (and arguably cleaner) to add a separate lock for these users (or e.g. just use seqlock, which adds two words but is optimal for readers). Most of the changes here are just the trivial s/->rlim/->signal->rlim/. I stumbled across what must be a long-standing bug, in reparent_to_init. It does: memcpy(current->rlim, init_task.rlim, sizeof(*(current->rlim))); when surely it was intended to be: memcpy(current->rlim, init_task.rlim, sizeof(current->rlim)); As rlim is an array, the * in the sizeof expression gets the size of the first element, so this just changes the first limit (RLIMIT_CPU). This is for kernel threads, where it's clear that resetting all the rlimits is what you want. With that fixed, the setting of RLIMIT_FSIZE in nfsd is superfluous since it will now already have been reset to RLIM_INFINITY. The other subtlety is removing: tsk->rlim[RLIMIT_CPU].rlim_cur = RLIM_INFINITY; in exit_notify, which was to avoid a race signalling during self-reaping exit. As the limit is now shared, a dying thread should not change it for others. Instead, I avoid that race by checking current->state before the RLIMIT_CPU check. (Adding one new conditional in that path is now required one way or another, since if not for this check there would also be a new race with self-reaping exit later on clearing current->signal that would have to be checked for.) The one loose end left by this patch is with process accounting. do_acct_process temporarily resets the RLIMIT_FSIZE limit while writing the accounting record. I left this as it was, but it is now changing a limit that might be shared by other threads still running. I left this in a dubious state because it seems to me that processing accounting may already be more generally a dubious state when it comes to NPTL threads. I would think you would want one record per process, with aggregate data about all threads that ever lived in it, not a separate record for each thread. I don't use process accounting myself, but if anyone is interested in testing it out I could provide a patch to change it this way. One final note, this is not 100% to POSIX compliance in regards to rlimits. POSIX specifies that RLIMIT_CPU refers to a whole process in aggregate, not to each individual thread. I will provide patches later on to achieve that change, assuming this patch goes in first. Signed-off-by:
-
Ingo Molnar authored
Remove the unused lcall7/lcall27 code. Signed-off-by:
-
Pavel Machek authored
Propagate the software_suspend() return value. Signed-off-by:
-
Pavel Machek authored
swsusp currently has very poor progress indication. Thanks to Erik Rigtorp <erik@rigtorp.com>, we have percentages there, so people know how long wait to expect. Please apply, From: Erik Rigtorp <erik@rigtorp.com> Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Andrea Arcangeli authored
This patch fixes some troubles that somebody reported me with the superio chips. In short rmmod parport_pc && cat /proc/iomem was good enough for crashing the box hard on some machine (and hwscan --printer was doing just that). The way the oops triggers is that iomem tries to vsprintf the p->name, but the p->name was a static string in the module address (now unloaded). The reason is that the superio chip scanning leaves up to two persistent ranges claimed. But the second (legacy) pass has no way to notice the resources are already reclaimed. Plus if the superio->io was different than the "io" variable (the range to scan for superio chips) the "io" range would generate a leak of the original "io" range too. I simply make sure to always release the requested space during the superio scan, and I make sure not to istantiate new ranges in the p->base that would cause the later parport scan to fail too (plus leaving up to leaked resources). The previous code that was returning values and was leaving garbage in there made no sense to me. My best guess (assuming I didn't misread it ;) is that probably somebody added the request_region without realizing they're pointing to the very same address that would be requested later (and nobody does accesses on those ranges until later, so it was very safe to claim it later). Disclaimer: I don't have the specs of the winbond and smsc at hand, I just guessed what they do from the code (nothing checks superio->io except get_superio_dma get_superio_irq, which made the thing enough self explainatory to fix it without specs) Signed-off-by:
Andrea Arcangeli <andrea@novell.com> Signed-off-by:
-
Seth Rohit authored
Add a new system call setaltroot(2). Currently, using the altroot feature is accessible only via the set_personality() system call. It is accessible to user space only if there is more than one exec domain in the system. This patch allows using the altroot feature on systems where there is only one exec domain. It is possible to work around the issue by adding a dummy exec domain, but it was rejected for not being very elegant. If this feature is implemented in userspace, it adds a 16% overhead on a test case which greps for a single word in the kernel source tree. Signed-off-by:
Zou Nanhai <nanhai.zou@intel.com> Signed-off-by:
Gordon Jin <gordon.jin@intel.com> Signed-off-by:
Arun Sharma <arun.sharma@intel.com> Signed-off-by:
-
Linus Torvalds authored
None of the compatibility defines make sense for assembly files, and gcc has trouble with vararg macros when using "-traditional" (which is used for asm), to the point of ICE'ing.
-
Linus Torvalds authored
Paul cares. I think there's something in the water at IBM that makes people sticklers ;)
-
Benjamin Herrenschmidt authored
The move of iomap out of eeh inadvertently broke iSeries ... Fixed like this. Signed-off-by:
-
Benjamin Herrenschmidt authored
This fixes some issues with restoring the altivec and/or FPU registers upon return from a signal or when setting a context. It also add a proper stack backlink to the signal frames created for 64 bits applications. Signed-off-by:
-
Linus Torvalds authored
-
