> -Original Message-
> I am aware of the implications, but unfortunately it did
> not help either.
>
> # ls -l /dev/*random*
> crw-rw-rw- 1 root root 1, 8 2008-08-05 17:41 /dev/oldrandom
> lrwxrwxrwx 1 root root7 2008-08-05 17:41 /dev/random -> urandom
> crw-rw-rw- 1 root root 1, 9 200
>From 3d5ede6f776bdb1483bcd086f79c3bf41fed3865
We lost the marking of SIGWINCH as being OK to receive during stub
execution, causing a panic should that happen.
Cc: Benedict Verheyen <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>From 8bfd04b974689f700bbd053ad6e66b0a95fb80c9
x86_64 defines either memcpy or __memcpy depending on the gcc version, and
it looks like UML needs to follow that in its exporting.
Cc: Gabriel C <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PR
>From 60a2988aea701a6424809a5432bf068667aac177
The top of physical memory should be below the initial process stack, not the
top of the address space, at least for as long as the stack isn't known to the
kernel VM system and appropriately reserved.
Cc: "Christopher S. Aker" <[EMAIL PROTECTED]>
Si
>From b6d8adf477439e7086224bc9674c6b6638780783
From: Ingo Molnar <[EMAIL PROTECTED]>
Include limits.h to get a definition of PATH_MAX.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus
>From 7c1fed03b9fa32d4323d5caa6a9c7dcdd7eba767
My copying of linux/init.h didn't go far enough. The definition of
__used singled out gcc minor version 3, but didn't care what the major
version was. This broke when unit-at-a-time was added and gcc started
throwing out initcalls.
This results in
>From f1ef9167ca4494a8c6d71d0031c73e9c8841eadd
Fedora broke PTRACE_SYSEMU again, and UML crashes as a result when it
doesn't need to. This patch makes the PTRACE_SYSEMU check fail gracefully
and makes UML fall back to PTRACE_SYSCALL.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: An
>From 43f5b3085fdd27c4edf535d938b2cb0ccead4f75
Reintroduce uml_kmalloc for the benefit of UML libc code. The
previous tactic of declaring __kmalloc so it could be called directly
from the libc side of the house turned out to be getting too intimate
with slab, and it doesn't work with slob.
So, t
Here's my 2.6.25 patchset again. I've rebased against 2.6.25.14 and
included the correct commit ids this time.
Jeff
--
Work email - jdike at linux dot intel dot com
-
This SF.Net email is sp
>From 296cd66f7f6e130fe08e6880ecb13c3fc615a8db
From: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
arch/um/drivers/pcap_user.c |2 +-
1 files changed, 1 insertions(+), 1 del
>From 40fb16a360d9c6459afee91dc793c1e3374feb94
From: Tom Spink <[EMAIL PROTECTED]>
This patch makes os_get_task_size locate the bottom of the address space,
as well as the top. This is for systems which put a lower limit on mmap
addresses. It works by manually scanning pages from zero onwards u
>From 3e3b48e5198544dd90e27265a70c1a834139e025
From: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
arch/um/sys-x86_64/ksyms.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/um/sys-x86_64
>From 06e1e4ffbd1932e288839b3140cda6b8141eb684
Protection against the host's time going backwards (eg, ntp activity on
the host) by keeping track of the time at the last tick and if it's
greater than the current time, keep time stopped until the host catches
up.
Cc: Nix <[EMAIL PROTECTED]>
Signed
>From fe2cc53ee013a4d4d0317d418e7019fe6533a5a8
Alarm delivery could be noticably late in the !CONFIG_NOHZ case because lost
ticks weren't being taken into account. This is now treated more carefully,
with the time between ticks being calculated and the appropriate number of
ticks delivered to the
>From 4f81c5350b44bcc501ab6f8a089b16d064b4d2f6
There are various constraints on the use of unit-at-a-time:
- i386 uses no-unit-at-a-time for pre-4.0 (not 4.3)
- x86_64 uses unit-at-a-time always
Uli reported a crash on x86_64 with gcc 4.1.2 with unit-at-a-time,
resulting in commit c0a18111e5711
>From cfd28f6695d0fc047478480791a21bdd4967f98e
UML's supposed nanosecond clock interacts badly with NTP when NTP
decides that the clock has drifted ahead and needs to be slowed down.
Slowing down the clock is done by decrementing the cycle-to-nanosecond
multiplier, which is 1. Decrementing that g
Jeff Dike wrote:
> If nothing else works, I suppose a nasty workaround might be to
> replace /dev/random with dev/urandom, but that has security
> implications.
I am aware of the implications, but unfortunately it did
not help either.
# ls -l /dev/*random*
crw-rw-rw- 1 root root 1, 8 2008-08-05
On Tue, Aug 05, 2008 at 06:37:18PM +0200, [EMAIL PROTECTED] wrote:
> I'm glad to here that the bug has been fixed. Anyway, it does not work
> with my configuration:
>
> - CentOS 5.1 as host system and UML root fs
> - Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
> - GCC 4.1.2
[EMAIL PROTECTED] wrote:
> Boaz Harrosh wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> Hi!
>>>
>>> I've compiled an UML kernel based on 2.6.25 but loading kernel modules
>>> seems to be broken. No matter which module I try to load the output
>>> looks similar to this:
>>>
>>> overflow in relocati
Boaz Harrosh wrote:
[EMAIL PROTECTED] wrote:
Hi!
I've compiled an UML kernel based on 2.6.25 but loading kernel modules
seems to be broken. No matter which module I try to load the output
looks similar to this:
overflow in relocation type 11 val 80836d41
'loop' likely not compiled with
Hi!
I've compiled an UML kernel based on 2.6.25 but loading kernel modules
seems to be broken. No matter which module I try to load the output
looks similar to this:
overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel
After searching for a while I foun
On Fri, Aug 01, 2008 at 06:41:25PM -0400, Jeff Dike wrote:
>From 94409ded7768e15b0d0a5a172d611073c72308de Mon Sep 17 00:00:00 2001
>
>Reintroduce uml_kmalloc for the benefit of UML libc code. The
>previous tactic of declaring __kmalloc so it could be called directly
>from the libc side of the hous
22 matches
Mail list logo
