- 18 Oct, 2004 26 commits
-
-
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:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
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:
Ingo Molnar <mingo@elte.hu> Cc: <davem@davemloft.net> 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 <roland@redhat.com> 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 <benh@kernel.crashing.org> 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
-
bk://gkernel.bkbits.net/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://gkernel.bkbits.net/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Jeff Garzik authored
into pobox.com:/spare/repo/libata-2.6
-
Linus Torvalds authored
Allows us to do compile-time sparse warnings of our own.
-
bk://linux-scsi.bkbits.net/scsi-for-linus-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
James Bottomley authored
into titanic.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.6
-
James Bottomley authored
From: Luben Tuikov <luben_tuikov@adaptec.com> Fix sleeping while holding a lock on host removal and on killing the DV thread. Signed-off-by:
Luben Tuikov <luben_tuikov@adaptec.com> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com>
-
James Bottomley authored
From: James.Smart@Emulex.Com urther testing is showing that we are having some i/o threads prematurely die with the following message: "rejecting I/O to device being removed" Signed-off-by: -
Mike Miller authored
This patch changes our open specifically for clustering software. We must allow root to access any volume or device with a LUN ID. We also modified our revalidate function for this reason. If a logical is reserved, we must register it with the OS with size=0. Then the backup system can call BLKRRPART after breaking the reservation to set the device to the correct size. We also must register a controller with no logical volumes for the online utilities to function. This is the way we've done it since the 2.2 kernel. Which doesn't neccesarily make it right, but we have legacy apps to consider. Signed off by: Mike Miller <mike.miller@hp.com> Signed-off-by: -
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 19 Oct, 2004 1 commit
-
-
Ben Dooks authored
Patch from Ben Dooks Update the include/asm-arm/arch-s3c2410/regs-gpio.h with GSTATUS1 register information Signed-off-by: Ben Dooks
-
- 18 Oct, 2004 9 commits
-
-
Ben Dooks authored
Patch from Ben Dooks Fixes the following problems and ommisions: - added variable for base crystal rate - moved clock variables into clock.c - fixed bug in identifying s3c2440 cpus - added initial support for new uart registration - removed base blocks from include/asm/arch/hardware.h Signed-off-by: Ben Dooks
-
Ben Dooks authored
Patch from Ben Dooks This patch stops mtd from generating problems of casting pointers to ints, due to the memcpy_fromio and related functions all taking `unsigned long` for their IO addresses. Replace `unsigned long` with `void __iomem *` Compiled clean on arch-s3c2410 Signed-off-by: Ben Dooks
-
Christoph Hellwig authored
this also found a real bug, qla2xxx isn't iounmapping at host removal at all currently - and if the right cpp macro would have been set it'd be too late. Signed-off-by: -
Linus Torvalds authored
-
Greg Kroah-Hartman authored
Andrew requested this fix go in before 2.6.9 was out, to keep people's syslog quiet for a lot of different USB input devices. Fixes bug bugzilla.kernel.org bug #3564 Signed-off-by:
Greg Kroah-Hartman <greg@kroah.com> Signed-off-by:
-
Nicolas Pitre authored
I apparently can't copy simple obvious fixes by hand. Signed-off-by:
Nicolas Pitre <nico@cam.org> Signed-off-by:
-
Nicolas Pitre authored
This obvious missing unlock is screwing the preemption count. Fix was applied to MTD CVS already. Signed-off-by:
-
Oliver Neukum authored
The firmware loader has a security issue. Firmware on some devices can write to all memory through DMA. Therefore the ability to feed firmware to the kernel is equivalent to writing to /dev/kmem. CAP_SYS_RAWIO is needed to protect itself. [ Editors note: the firmware file is 0644, and owned by root, so this "security issue" is really only an issue for people who use capabilities explicitly, rather than the regular Unix permissions. This patch makes it do the same checks we do for /dev/mem etc. ] Signed-Off-By:
Oliver Neukum <oliver@neukum.name> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Mark Goodman authored
This patch is necessary to make NFS3 krb5 clients work on x86-64. ACK'ed by Trond Signed-off-by:
Mark Goodman <mgoodman@csua.berkeley.edu> Signed-off-by:
-
- 17 Oct, 2004 4 commits
-
-
Mike Miller authored
This patch updates our SCSI support to no longer use deprecated APIs. Signed-off-by: -
Nathan Lynch authored
This change is needed in order to allow cpus to be onlined after boot. This used to work but the declaration of pseries_secondary_smp_init in this file was changed in Ben's big cleanup patch a while back, so the cpu would start at a bad address. Signed-off-by:
Nathan Lynch <nathanl@austin.ibm.com> Signed-off-by:
-
Nick Piggin authored
Fix some bugs in the kswapd logic which can cause kswapd lockups. The balance_pgdat() logic is supposed to cause kswapd to loop across all zones in the node until each zone either a) has enough pages free or b) is deemed to be in an "all pages unreclaimable" state. In the latter case, we just give the zone a light scan on each balance_pgdat() scan and wait for the zone to come back to life again. But the zone->all_unreclaimable logic is broken - if the zone has no pages on the LRU at all, we perform no scanning of that zone (of course). So the zone->pages_scanned is not incremented and the expression if (zone->pages_scanned > zone->present_pages * 2) zone->all_unreclaimable = 1; never is satisfied. The patch changes that logic to if (zone->pages_scanned >= (zone->nr_active + zone->nr_inactive) * 4) zone->all_unreclaimable = 1; so if the zone has no LRU pages it will still enter the all_unreclaimable state. Another problem is that if the zone has no LRU pages we will tell shrink_slab() that we scanned zero LRU pages. This causes shrink_slab() to scan zero slab objects, which is obviously wrong. So change shrink_slab() to perform a decent chunk of slab scanning in this situation. And put a cond_resched() into the balance_pgdat() outer loop. Probably unnecessary, but that's what Jeff had in place when he confirmed that this patch fixed the lockup :( Signed-off-by:
-
Pavel Machek authored
In assembly code, there are some problems with "nosave" section (linker was doing something stupid, like duplicating the section). We attempted to fix it, but fix was worse then first problem. This fixes is for good: We no longer use any memory in the copy loop. (Plus it fixes indentation and uses meaningful labels.) Signed-off-by:
-
