- 08 Mar, 2005 40 commits
-
-
Paul Mackerras authored
This patch is from John Rose <johnrose@austin.ibm.com> This patch changes the rtas wrapper functions in rtas.c to map RTAS failure codes to conventional error values. The goal is to make failure conditions obvious in the wrapper functions and in the caller code. Signed-off-by:
John Rose <johnrose@austin.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Stephen Rothwell authored
This patch "inverts" the PPC64 dma mapping routines so that the pci_ and vio_ ... routines are implemented in terms of the dma_ ... routines (the vio_ routines disappear anyway as noone uses them directly any more). The most noticable change after this patch is applied will be that the flags passed to dma_alloc_coherent will now be honoured (whereas they were previously silently ignored since we used to just call pci_alloc_consistent). Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Andrea Arcangeli authored
Now that we cleaned up the guard page handling in vmalloc, we have to remove the p-PAGE_SIZE hack that was put in there for the original guard page handling. This also removes some spurious tab. Signed-off-by:
Andrea Arcangeli <andrea@suse.de> Signed-off-by:
-
Roland McGrath authored
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit, it occurred to me that the normal setting of this limit is bizarrely low. The initial hard limit setting (MAX_SIGPENDING) was taken from the old max_queued_signals parameter, which was for the entire system in aggregate. But even as a per-user limit, the 1024 value is incongruously low for this. On my machine, RLIMIT_NPROC allows me 8192 processes, but only 1024 queued signals, i.e. fewer even than one pending signal in each process. (To me, this really puts in doubt the sensibility of using a per-user limit for this rather than a per-process one, i.e. counted in sighand_struct or signal_struct, which could have a much smaller reasonable value. I don't recall the rationale for making this new limit per-user in the first place.) This patch sets the default RLIMIT_SIGPENDING limit at boot time, using the calculation that decides the default RLIMIT_NPROC limit. This uses the same value for those two limits, which I think is still pretty conservative on the RLIMIT_SIGPENDING value. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Roland McGrath authored
Jeremy mentioned the aggravation of not being able to tell when your processes are using up signal queue entries and hitting the RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status showing how many queue items are in use, and allowed, for your uid. I can certainly see the appeal of having a display of the number of queued items specific to each process, and even the items within the process broken down per signal number. However, those are not things that are directly counted, and ascertaining them requires iterating through the queue. This patch instead gives what can be readily determined in constant time using the accounting already done. I'm not sure something more complex is warranted just to facilitate one particular debugging need. With this, you can see quickly that this particular problem has come up. Then examination of each process's SigPnd/ShdPnd lines ought to give you an indication of which processes have any queued RT signals sitting around for a long time, and you can then attack those programs directly, though there is no way after the fact to determine how many queued signals with the same number a given process has (short of killing it and seeing the usage drop). Note you may still have a mystery if the leaking programs are not leaving pending RT signals queued, but rather preallocating queue items via timer_create. That usage is not readily apparent in any /proc information. Signed-off-by:
-
Roland McGrath authored
I can read POSIX to say that the siginfo_t data must be available when `kill' was used, as well. This patch makes it allocate the siginfo_t, even when that exceeds {RLIMIT_SIGPENDING}, for any non-RT signal (< SIGRTMIN) not sent by sigqueue (actually, any signal that couldn't have been faked by a sigqueue call). Of course, in an extreme memory shortage situation, you are SOL and violate POSIX a little before you die horribly from being out of memory anyway. The LEGACY_QUEUE logic already ensures that, for non-RT signals, at most one is ever on the queue. So there really is no risk at all of unbounded resource consumption; the usage can reach {RLIMIT_SIGPENDING} + 31, is all. It's already the case that the limit can be exceeded by (in theory) up to {RLIMIT_NPROC}-1 in race conditions because the bump and the limit check are not atomic. (Obviously you can only get anywhere near that many with assloads of preemption, but exceeding it by a few is not too unlikely.) This patch also fixes that accounting so that it should not be possible to exceed {RLIMIT_SIGPENDING} + SIGRTMIN-1 queue items per user in races. Signed-off-by: -
Roland McGrath authored
POSIX requires that the RLIMIT_CPU resource limit that generates SIGXCPU be counted on a per-process basis. Currently, Linux implements this for individual threads. This patch fixes the semantics to conform with POSIX. The essential machinery for the process CPU limit is is tied into the new posix-timers code for process CPU clocks and timers. Signed-off-by:
-
Roland McGrath authored
POSIX requires that setitimer, getitimer, and alarm work on a per-process basis. Currently, Linux implements these for individual threads. This patch fixes these semantics for the ITIMER_PROF timer (which generates SIGPROF) and the ITIMER_VIRTUAL timer (which generates SIGVTALRM), making them shared by all threads in a process (thread group). This patch should be applied after the one that fixes ITIMER_REAL. The essential machinery for these timers is tied into the new posix-timers code for process CPU clocks and timers. This patch requires the cputimers patch and its dependencies. Signed-off-by:
-
Roland McGrath authored
POSIX requires that setitimer, getitimer, and alarm work on a per-process basis. Currently, Linux implements these for individual threads. This patch fixes these semantics for the ITIMER_REAL timer (which generates SIGALRM), making it shared by all threads in a process (thread group). Signed-off-by:
-
Roland McGrath authored
It was intended that such things would not be possible because getting into that code in the first place should be ruled out while exiting. That removes the requirement for any special case check in the common path. But, it was done too late since it hadn't occurred to me that ->live going zero itself created a problem. Signed-off-by:
-
Roland McGrath authored
POSIX requires that when you claim _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME, not only the clock_* calls but also timer_* calls must support the thread and process CPU time clocks. This patch provides that support, building on my recent additions to support these clocks in the POSIX clock_* interfaces. This patch will not work without those changes, as well as the patch fixing the timer lock-siglock deadlock problem. The apparent pervasive changes to posix-timers.c are simply that some fields of struct k_itimer have changed name and moved into a union. This was appropriate since the data structures required for the existing real-time timer support and for the new thread/process CPU-time timers are quite different. The glibc patches to support CPU time clocks using the new kernel support is in http://people.redhat.com/roland/glibc/kernel-cpuclocks.patch, and that includes tests for the timer support (if you build glibc with NPTL). From: Christoph Lameter <clameter@sgi.com> Your patch breaks the mmtimer driver because it used k_itimer values for its own purposes. Here is a fix by defining an additional structure in k_itimer (same approach for mmtimer as the cpu timers): From: Roland McGrath <roland@redhat.com> Fix bug identified by Alexander Nyberg <alexn@dsv.su.se> > The problem arises from code touching the union in alloc_posix_timer() > which makes firing go non-zero. When firing is checked in > posix_cpu_timer_set() it will be positive causing an infinite loop. > > So either the below fix or preferably move the INIT_LIST_HEAD(x) from > alloc_posix_timer() to somewhere later where it doesn't disturb the other > union members. Thanks for finding this problem. The latter is what I think is the right solution. This patch does that, and also removes some superfluous rezeroing. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Roland McGrath authored
The posix-timers code establishes the locking order that k_itimer locks are outside siglocks. However, when the signal code calls back into the posix-timers code to reload a timer after its signal is dequeued, it holds a siglock while calling do_schedule_next_timer, which gets a timer lock. I'm not sure there is any deadlock scenario possible using the real-time POSIX timers, because of the intricate arrangement of timer firing and resetting synchronization. But with the new CPU timers code, this deadlock pops up right away. Dropping the siglock here certainly doesn't hurt in the real-time timer cases, and it really seems like the right thing here to keep the locking details in the interface between signals and posix-timers code comprehensible. Signed-off-by:
-
Roland McGrath authored
> We do need to do one or the other. I assume the current indecision is > pending some benchmarking work? That was more or less the idea. But I kind of figured someone would just tell me which one to do without actually doing any timings. This patch (applies after the cpuclocks patch) makes the one decision, to use conditional branches rather than indirect calls in the common case. That is consistent with what the old code did. Signed-off-by:
-
Roland McGrath authored
This patch provides support for thread and process CPU time clocks in the POSIX clock interface. Both the existing utime and utime+stime information (already available via getrusage et al) can be used, as well as a new (potentially) more precise and accurate clock (which cannot distinguish user from system time). The clock used is that provided by the `sched_clock' function already used internally by the scheduler. This gives a way for platforms to provide the highest-resolution CPU time tracking that is available cheaply, and some already do so (such as x86 using TSC). Because this clock is already sampled internally by the scheduler, this new tracking adds only the tiniest new overhead to accomplish the bookkeeping. Some notes: This allows per-thread clocks to be accessed only by other threads in the same process. The only POSIX calls that access these are defined only for in-process use, and having this check is necessary for the userland implementations of the POSIX clock functions to robustly refuse stale clockid_t's in the face of potential PID reuse. This makes no constraint on who can see whose per-process clocks. This information is already available for the VIRT and PROF (i.e. utime and stime) information via /proc. I am open to suggestions on if/how security constraints on who can see whose clocks should be imposed. The SCHED clock information is now available only via clock_* syscalls. This means that per-thread information is not available outside the process. Perhaps /proc should show sched_time as well? This would let ps et al show this more-accurate information. When this code is merged, it will be supported in glibc. I have written the support and added some test programs for glibc, which are what I mainly used to test the new kernel code. You can get those here: http://people.redhat.com/roland/glibc/kernel-cpuclocks.patchSigned-off-by:
-
Roland McGrath authored
This patch cleans up the posix-timers interfaces for defining clocks, and the calls to them. It fixes some sloppy types, adds a clockid_t parameter to the calls that lacked it, and adds a function pointer that can be used for clock_getres. It further cleans up the posix-timers.c code using the k_clock function pointers or default functions when no hooks are supplied, consolidating repeated code into shared inline functions or macros. This paves the way for adding the CPU clock hooks. The mmtimer.c changes are untested, but obviously can't be wrong. There aren't any other struct k_clock definitions in the tree, but any others would need to be updated for the function signature changes. Signed-off-by:
-
Prasanna Meda authored
This patch uses find_vma() to improve the read response of /proc/pid/maps. It attempts to make the liner scan instead of quadratic walk and utilise rb tree. Reading the file was doing sequential scan from the begining to file position all the time, and taking a quite long time. The improvements came from f_version/m_version and resulting in mmap_cache match. Even if mmap_cache does not match, rb tree walk should be faster than sequential walk. First attempt was to put the state across read system calls into private data. Later got inspiration from wli's pid patch using f_version in readdir of /proc. Other advantage is, f_version will be cleared automatically by lseek. The test program creates 32K maps and splits them into two(limited by max_map_count sysctl) using mprotect(0). After the patch, the read time improves from many seconds to milliseconds, and does not grow superlinearly with number of read calls. Help taken from Peter Swain in idea and testing. After the patch: Reading /proc/self/maps:65528 time: 0 secs and 780728 usecs buf:4096 bytes:3811362 Reading /proc/self/maps:65528 time: 1 secs and 117573 usecs buf:1024 bytes:3866627 Reading /proc/self/maps:65528 time: 0 secs and 473459 usecs buf: 256 bytes:3866627 Reading /proc/self/maps:65528 time: 0 secs and 901288 usecs buf: 64 bytes:3866627 Reading /proc/self/maps:65528 time: 1 secs and 480185 usecs buf: 16 bytes:3866627 Reading /proc/self/maps:65528 time: 1 secs and 636268 usecs buf: 4 bytes:3866627 Reading /proc/self/maps:65528 time: 4 secs and 118327 usecs buf: 1 bytes:3866627 Before the patch: Reading /proc/self/maps:65528 time: 4 secs and 359556 usecs buf:4096 bytes:3866647 Reading /proc/self/maps:65528 time:16 secs and 218584 usecs buf:1024 bytes:3866688 Reading /proc/self/maps:65528 time:67 secs and 870200 usecs buf: 256 bytes:3866688 Reading /proc/self/maps:65528 time:255 secs and 186934 usecs buf: 64 bytes:3866688 Small reads never completed. Signed-off-by:
Prasanna Meda <pmeda@akamai.com> Signed-off-by:
-
Andrew Morton authored
It's possible to define .configs in which there are no references in vmlinux to lib/parser.o. So you cannot load any filesystem modules. Arrange for parser.o to be statically linked. Signed-off-by:
-
Matt Mackall authored
Move syncookie code off to networking land. Signed-off-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Matt Mackall authored
Simplify syncookie initialization Refactor syncookie code with separate hash function Signed-off-by:
-
Matt Mackall authored
Replace duplicate halfMD4 code with call to lib/ Signed-off-by:
-
Matt Mackall authored
Move half-MD4 hash to /lib where we can share it with htree. Signed-off-by:
-
Matt Mackall authored
Drop the cryptolib SHA implementation and use the faster and much smaller SHA implementation from lib/. Saves about 5K. This also saves time by doing one memset per update call rather than one per SHA block. Signed-off-by:
-
Matt Mackall authored
A replacement SHA routine that's slightly larger, but over twice as fast. It's also faster and much smaller than the cryptolib version. size speed buffer size original: 350B 2.3us 320B cryptolib: 5776B 1.2us 80B this code: 466B 1.0us 320B alternate: 2112B 1.0us 80B Signed-off-by: -
Matt Mackall authored
Move random SHA code to lib/. Signed-off-by:
-
Matt Mackall authored
Clean up SHA hash function for moving to lib/ Do proper endian conversion Provide sha_init function Add kerneldoc Signed-off-by:
-
Matt Mackall authored
Kill the unrolled SHA variants, they're unused and duplicate code in cryptoapi. Signed-off-by:
-
Matt Mackall authored
Move users of private rotl/rotr functions to rol32/ror32. Crypto bits verified with tcrypt. Signed-off-by:
-
Matt Mackall authored
Add rol32 and ror32 bitops to bitops.h Signed-off-by:
-
Matt Mackall authored
Rather than batching up entropy samples, resulting in longer lock hold times when we actually process the samples, mix in samples immediately. The trickle code should eliminate almost all the additional interrupt-time overhead this would otherwise incur, with or without locking. Signed-off-by:
-
Matt Mackall authored
Clean up buffer usage for SHA and reseed. This makes the code more readable and reduces worst-case stack usage. Signed-off-by:
-
Matt Mackall authored
Simplify output hash folding Signed-off-by:
-
Matt Mackall authored
Remove long-dead md5 code. Signed-off-by:
-
Matt Mackall authored
Break apart extract_entropy into kernel and user versions, remove last extract flag and some unnecessary variables. This makes the code more readable and amenable to sparse. Signed-off-by:
-
Matt Mackall authored
Put pointer to reseed pool in pool struct and automatically pull entropy from it if it is set. This lets us remove the EXTRACT_SECONDARY flag. Signed-off-by:
-
Matt Mackall authored
Move the limit flag to the pool struct, begin process of eliminating extract flags. Signed-off-by:
-
Matt Mackall authored
Additional parameter to allow keeping an entropy reserve in the input pool. Groundwork for proper /dev/urandom vs /dev/random starvation prevention. Signed-off-by:
-
Matt Mackall authored
When reseeding, we must always do a "catastrophic reseed" where we pull enough new bits to make the new state unguessable from outputs even if we knew the old state. So we must do the checks against the minimum reseed amount under the pool lock in extract_entropy. Signed-off-by:
-
Matt Mackall authored
Static initialization for sysctl support Signed-off-by:
-
Matt Mackall authored
As we no longer allow resizing of pools, it makes sense to allocate and initialize them statically. Remove create_entropy_store and simplify rand_initialize. Signed-off-by:
-
Matt Mackall authored
Give pools more meaningful names. Signed-off-by:
-
