- 23 Aug, 2004 40 commits
-
-
Dimitri Sivanich authored
Here is another cache_reap optimization that reduces latency when applied after the 'Move cache_reap out of timer context' patch I submitted on 7/14 (for inclusion in -mm next week). Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Bálint Márton authored
At boot time, get_random_bytes always returns the same random data, as if there were a constant random seed. For example, if I use the kernel level ip autoconfiguration with dhcp, the kernel will create a dhcp request packet with always the same transaction ID. (If you have more than one computers, and they are booting at the same time, then this is a big problem) That happens, because only the primary entropy pool is initialized with the system time, in function rand_initialize. The secondary pool is only cleared. In this early stage of booting, there is usually no user interaction, or usable disk interrupts, so the kernel can't add any real random bytes to the primary pool. And altough the system time is in the primary pool, the kernel does not consider it real random data, so you can't read from the primary pool, before at least a part of it will be filled with some real randomness (interrupt timing). Therefore all random data will come from the secondary pool, and the kernel cannot reseed the secondary pool, because there is no real randomness in the primary one. The solution is simple: Initialize not just the primary, but also the secondary pool with the system time. Signed-off-by:
-
Samuel Thibault authored
There's something wrong in cdrom.c: cdrom_get_last_written() for instance calls cdrom_get_disc_info() and cdrom_get_track_info() to get information about tracks, but these functions don't ensure that all the track_information or disc_information structure is filled: /* (buflen was first set to 8 to get track_information_length field) */ if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; cgc.buflen = be16_to_cpu(ti->track_information_length) + sizeof(ti->track_information_length); if (cgc.buflen > sizeof(track_information)) cgc.buflen = sizeof(track_information); cgc.cmd[8] = cgc.buflen; return cdo->generic_packet(cdi, &cgc); The second test ensures that at least we won't overflow the structure, but nothing ensures that all the structure will be filled. And indeed, we have a drive here that won't fill it all: the returned track_information_length field will be *less than* sizeof(track_information) - sizeof(ti->track_information_length), so that cdrom_get_last_written() reads values that weren't filled in! As a result, we are sometimes unable to read some parts of CDROMs, depending on the uninitialized state of the structure... Here is a patch that adds filling checks: cdrom_get_disc_info() and cdrom_get_track_info() return the actual filled length, and it's up to the caller to check that this is enough for him to get the values it wants. Note: adding something like a #define spanof(TYPE, MEMBER) ((size_t) ((&((TYPE *)0)->MEMBER)+1)) definition just near that of offsetof() in include/linux/stddef.h would make it more pretty, but still it won't help for bitfields :/ Signed-off-by:
-
Arthur Othieno authored
ChangeSet 1.1371.413.23 [1] introduced the file include/asm-generic/dma-mapping-broken.h for architectures that don't support the new DMA API. I don't know if this is the case with s390, however, ChangeSet 1.1371.445.6 [2] introduced a set of changes that duplicate those in include/asm-generic/dma-mapping-broken.h. This patch squishes that duplication by simply including include/asm-generic/dma-mapping-broken.h in include/asm-s390/dma-mapping.h. Signed-off-by:
Arthur Othieno <a.othieno@bluewin.ch> Signed-off-by:
-
Carl Spalletta authored
Remove a whole bunch of prototypes which declare no-longer-present functions. Signed-off-by:
-
Roland McGrath authored
This patch just directly clones Davide Libenzi's i386 code for x86-64 in both 64-bit and 32-bit cases. With this, the behavior of single-stepping all system calls is consistent. The syscall exit tracing caused by TIF_SINGLESTEP is superfluous in the case of sysret returns, but harmlessly so (since continuing afterward with PTRACE_CONT will have cleared TF as well as TIF_SINGLESTEP). I figured that little bit of extra processing in the single-step case was better than adding code to ignore the flag in the sysret case. Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: <ak@muc.de> Signed-off-by:
-
Christoph Lameter authored
This issue was discussed on lkml and linux-ia64. The patch introduces "getnstimeofday" and removes all the code scaling gettimeofday to nanoseoncs. It makes it possible for the posix-timer functions to return higher accuracy. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Dimitri Sivanich authored
I'm submitting two patches associated with moving cache_reap functionality out of timer context. Note that these patches do not make any further optimizations to cache_reap at this time. The first patch adds a function similiar to schedule_delayed_work to allow work to be scheduled on another cpu. The second patch makes use of schedule_delayed_work_on to schedule cache_reap to run from keventd. Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Christian Bornträger authored
Various people have reported deadlocks and it has aways seemed a bit risky to try to sync the filesystems at this stage anyway. "I have seen panic failing two times lately on an SMP system. The box panic'ed but was running happily on the other cpus. The culprit of this failure is the fact, that these panics have been caused by a block device or a filesystem (e.g. using errors=panic). In these cases the likelihood of a failure/hang of sys_sync() is high. This is exactly what happened in both cases I have seen. Meanwhile the other cpus are happily continuing destroying data as the kernel has a severe problem but its not aware of that as smp_send_stop happens after sys_sync." Signed-off-by:
-
Martin J. Bligh authored
arch-i386-kernel-smpc-gcc341-inlining-fix.patch seems to cause the following warning: include/asm-i386/mach-numaq/mach_ipi.h:4: warning: static declaration for `send_ IPI_mask_sequence' follows non-static. This should fix it (and make it match the other subarches): Signed-off-by:
-
Hannes Reinecke authored
Currently most driver events are not sent out when using initramfs as driver_init() (which triggers the events) is called before init_workqueues. This patch rearranges the init calls so that the hotplug event queue is enabled prior to calling driver_init(), hence we're getting all hotplug events again. Signed-off-by:
-
Andrew Morton authored
With gcc-3.4.1: arch/i386/kernel/smp.c: In function `flush_tlb_others': arch/i386/kernel/smp.c:161: sorry, unimplemented: inlining failed in call to 'send_IPI_mask_bitmask': function not considered for inlining arch/i386/kernel/smp.c:9: sorry, unimplemented: called from here Signed-off-by:
-
Jose R. Santos authored
I was looking at the recent for >MAX_ORDER hash tables but it seems that the patch limits the number of entries to what it thinks are good values and the i/dhash_entries cmdline options can not exceed this. This seems to limit the usability of the patch on systems were larger allocations that the ones the kernel calculates are desired. - Make ihash_entries and dhash_entries cmdline option behave like it use to. - Remove MAX_SYS_HASH_TABLE_ORDER. Limit the max size to 1/16 the total number of pages. Signed-off-by:
-
Christoph Hellwig authored
If the generic code falls back to buffered I/O on a hole XFS needs to relock, so we need to have separate functions to call unless we want to duplicate everything. The XFS patch still needs some cleaning up, but I'll try to get it in before 2.6.8. Signed-off-by:
-
Mikael Pettersson authored
gcc-3.4.1 errors out in 2.6.8-rc1-mm1 at arch/i386/kernel/smp.c: arch/i386/kernel/smp.c: In function `flush_tlb_others': arch/i386/kernel/smp.c:161: sorry, unimplemented: inlining failed in call to 'send_IPI_mask_bitmask': function not considered for inlining arch/i386/kernel/smp.c:9: sorry, unimplemented: called from here make[1]: *** [arch/i386/kernel/smp.o] Error 1 make: *** [arch/i386/kernel] Error 2 The <mach_ipi.h> inlines depend on functions defined further down in smp.c. Moving the #include eliminates the problem. Signed-off-by:
Mikael Pettersson <mikpe@csd.uu.se> Signed-off-by:
-
Arnd Bergmann authored
I find it somewhat annoying that the preprocessor expands every "inline" to "__inline__ __attribute__((always_inline)) __attribute__((always_inline))" in the current code. Fix that up. Signed-off-by:
-
Adrian Bunk authored
Rationale: - if gcc 3.4 can't inline a function marked as "inline" that's a strong hint that further investigation is required - I strongly prefer a compile error over a potential runtime problem Signed-off-by:
Adrian Bunk <bunk@fs.tum.de> Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Not strictly needed, since we're forcing `inline' to always_inline, but it's good for documentation purposes - This function needs the always_inline otherwise you get a link error when the compile time test is not optimized away. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Andi Kleen authored
Trivial gcc-3.5 build fixes. Signed-off-by:
-
Shai Fultheim authored
Use the percpu infrastructure rather than open-coded array[NR_CPUS]. Signed-off-by:
-
Shai Fultheim authored
Use the percpu infrastructure rather than open-coded array[NR_CPUS]. Signed-off-by:
-
Shai Fultheim authored
Use the percpu infrastructure rather than open-coded array[NR_CPUS]. Signed-off-by:
-
Christoph Hellwig authored
The generation counters were removed from the idr code. Update idr.c comments, now uses doc-book style API documentation. Signed-off-by:
-
Takashi Iwai authored
The patch adds the check of return value from resquest_region() to avoid the confliction of resource management with ALSA intel8x0 driver. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Manfred Spraul authored
Attached is a cleanup of the main loops in sys_msgrcv and sys_msgsnd, based on ipc_lock_by_ptr(). Most backward gotos are gone, instead normal "for(;;)" loops until a suitable message is found. Description: - General cleanup of sys_msgrcv and sys_msgsnd: the function were too convoluted. - Enable lockless receive, update comments. - Use ipc_getref for sys_msgsnd(), it's better than rechecking that the msqid is still valid. Signed-Off-By:
-
Manfred Spraul authored
Independent from the other patches: undo operations should not result in out of range semaphore values. The test for newval > SEMVMX is missing. The attached patch adds the test and a comment. Signed-Off-By:
-
Manfred Spraul authored
The attached patch removes sem_revalidate and replaces it with ipc_rcu_getref() calls followed by ipc_lock_by_ptr(). Signed-Off-By:
-
Manfred Spraul authored
The lifetime of the ipc objects (sem array, msg queue, shm mapping) is controlled by kern_ipc_perms->lock - a spinlock. There is no simple way to reacquire this spinlock after it was dropped to schedule()/kmalloc/copy_{to,from}_user/whatever. The attached patch adds a reference count as a preparation to get rid of sem_revalidate(). Signed-Off-By:
-
