Commits · cba5bbaad62c9d72caf399646458b095a93ffea8 · Kirill Smelkov / linux

23 Aug, 2004 40 commits

[PATCH] get_random_bytes() returns the same on every boot · cba5bbaa

Bálint Márton authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

cba5bbaa

[PATCH] Subject: cdrom.c get_last_written fixup · f0828420

Samuel Thibault authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

f0828420

[PATCH] s390: Use include/asm-generic/dma-mapping-broken.h · a2a3b74d

Arthur Othieno authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

a2a3b74d

[PATCH] remove dead prototypes · 49950d2a

Carl Spalletta authored Aug 22, 2004

Remove a whole bunch of prototypes which declare no-longer-present functions.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

49950d2a

[PATCH] Fix x86-64 singlestep through sigreturn system call · cae7c30a

Roland McGrath authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

cae7c30a

[PATCH] gettimeofday nanoseconds patch · b9cbc585

Christoph Lameter authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

b9cbc585

[PATCH] Move cache_reap out of timer context · 346ed9c1

Dimitri Sivanich authored Aug 22, 2004

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: Dimitri Sivanich <sivanich@sgi.com>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

346ed9c1

[PATCH] remove sync() from panic · 6cfa4c9f

Christian Bornträger authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

6cfa4c9f

[PATCH] warning on NUMA-Q · 42e3ec01

Martin J. Bligh authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

42e3ec01

[PATCH] Enable all events for initramfs · e5f29853

Hannes Reinecke authored Aug 22, 2004

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 <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

e5f29853

[PATCH] send_IPI_mask_bitmask() build fix · 0a50caad

Andrew Morton authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

0a50caad

[PATCH] Make i/dhash_entries cmdline work as it use to. · 38612ed3

Jose R. Santos authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

38612ed3

[PATCH] split generic_file_aio_write into buffered and direct I/O parts · 350f76f1

Christoph Hellwig authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

350f76f1

[PATCH] arch/i386/kernel/smp.c gcc341 inlining fix · 581851ea

Mikael Pettersson authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

581851ea

[PATCH] clean up __always_inline__ usage · 2f85be7d

Arnd Bergmann authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

2f85be7d

[PATCH] #define inline as __attribute__((always_inline)) also for gcc >= 3.4 · 4e9d864d

Adrian Bunk authored Aug 22, 2004

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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>