2.6.9-bb1, 2.4.27-bs1, SKAS3/2.6-V7 released

2.6.9-bb1, 2.4.27-bs1, SKAS3/2.6-V7 released

[Blaisorblade]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

You can find all on http://www.user-mode-linux.org/~blaisorblade/.

The SKAS3/2.6-v7 was already released, but I probably forgot to announce it. 
So I'm announcing it now.

Changes in SKAS:
* echo 0 > /proc/sysemu on the guests works fine, finally!

Changes in both 2.6.9 and 2.4.27:
they run fine on 2.6.9 host kernels, without hanging at the exit.

Changes in 2.6.9 only:
included a large chunk of JDike tree (excluding all x86_64 related patches), 
and all the latest security patches from Bodo Stroesser; also it includes the 
-V7 skas patch in it.

Actually, however, to do this I had to include big, invasive patches from Jeff 
Dike's tree. I've done it because it's needed and because Bodo Stroesser 
worked with the incrementals very fine.

Changes in 2.4.27 only:

It's based on a fork from the official 2.4.24-1; the patches I've included 
come almost totally from there, but I dropped all the hostfs rewrite. I also 
included some incrementals, the one I thought safe.

Also, you can find on the page the instructions to avoid the "hwclock hang" in 
TT mode. I found the faulty patch, but it needs a more worse bug, which 
affects everyone running in TT mode on a 2.6 host, so it's included. You can 
revert the patch if you want, and if you have to run it on a 2.4 host. I sent 
a message about this about a week ago, but I got no answer.

Distribution:
* the patch are also in split-out form, both web-browsable and tarballed.
* md5sums are available (to test with "md5sum -c *.md5").

Any testing and report is welcome.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

SKAS3/2.6-V7 failed with 2.6.8.1

[kaz]

Hi,

Blaisorblade wrote:
> 
> The SKAS3/2.6-v7 was already released, but I probably forgot to announce it. 
> So I'm announcing it now.

host-skas3-2.6.9-v7.patch failed with 2.6.8.1.  The error message was as below;

~linux-2.6.8.1$ cat ../host-skas3-2.6.9-v7.patch | patch -p1
patching file arch/i386/kernel/entry.S
Hunk #1 succeeded at 258 with fuzz 2 (offset 2 lines).
Hunk #2 FAILED at 280.
1 out of 3 hunks FAILED -- saving rejects to file arch/i386/kernel/entry.S.rej
patching file arch/i386/kernel/ptrace.c
Hunk #2 succeeded at 358 (offset -1 lines).
Hunk #3 succeeded at 366 with fuzz 1 (offset -1 lines).
Hunk #4 succeeded at 417 (offset -3 lines).
Hunk #5 succeeded at 524 (offset -4 lines).
Hunk #6 succeeded at 589 (offset -4 lines).
Hunk #7 FAILED at 600.
Hunk #8 succeeded at 632 (offset -5 lines).
1 out of 8 hunks FAILED -- saving rejects to file arch/i386/kernel/ptrace.c.rej
patching file include/asm-i386/thread_info.h
Hunk #2 FAILED at 153.
1 out of 2 hunks FAILED -- saving rejects to file include/asm-i386/thread_info.h.rej
patching file include/linux/ptrace.h
patching file kernel/fork.c
Hunk #1 succeeded at 1008 (offset -32 lines).
patching file include/linux/mm.h
Hunk #1 succeeded at 575 (offset -48 lines).
Hunk #2 succeeded at 636 (offset -49 lines).
patching file include/linux/proc_mm.h
patching file mm/Makefile
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED -- saving rejects to file mm/Makefile.rej
patching file mm/mmap.c
Hunk #1 succeeded at 736 (offset -23 lines).
Hunk #2 succeeded at 1006 (offset -28 lines).
patching file mm/mprotect.c
Hunk #2 succeeded at 186 (offset -2 lines).
Hunk #3 succeeded at 217 (offset -2 lines).
Hunk #4 succeeded at 288 (offset -2 lines).
patching file mm/proc_mm.c
patching file arch/i386/Kconfig
Hunk #1 succeeded at 757 (offset 33 lines).
patching file arch/i386/kernel/ldt.c
Hunk #6 succeeded at 172 (offset -5 lines).
Hunk #7 succeeded at 197 (offset -5 lines).
Hunk #8 succeeded at 233 (offset -5 lines).
patching file arch/i386/kernel/sys_i386.c
patching file include/asm-i386/desc.h
Hunk #1 succeeded at 124 (offset -2 lines).
patching file include/asm-i386/ptrace.h
Hunk #1 succeeded at 59 with fuzz 1 (offset -5 lines).
patching file include/asm-i386/mmu_context.h
Hunk #3 FAILED at 66.
1 out of 3 hunks FAILED -- saving rejects to file include/asm-i386/mmu_context.h.rej
patching file arch/um/include/skas_ptrace.h
patching file localversion-skas

Re: SKAS3/2.6-V7 failed with 2.6.8.1

[Brice Goglin]

kaz wrote:
> 
> host-skas3-2.6.9-v7.patch failed with 2.6.8.1.  The error message was as below;

This is why it is called host-skas3-2.6.9-v7.patch
and not host-skas3-2.6.8.1-v7.patch

Regards
--
Brice Goglin
================================================
Ph.D Student
Laboratoire de l'Informatique et du Parallélisme
CNRS-ENS Lyon-INRIA-UCB Lyon
France

Re: 2.6.9-bb1, 2.4.27-bs1, SKAS3/2.6-V7 released

[Nuutti Kotivuori]

Blaisorblade wrote:
> Changes in both 2.6.9 and 2.4.27:
> they run fine on 2.6.9 host kernels, without hanging at the exit.

I want to get this clear:

Every older guest UML kernel will hang on exit on 2.6.9 hosts from now
on, and there's nothing to fix it but to update the guest UML patches?

This is a nasty limitation in general - because it means that on the
update to 2.6.9, every kernel binary needs to be updated - and finding
rock solid versions of kernels + UML patches is not a fast process.

-- Naked

Re: [uml-devel] Re: 2.6.9-bb1, 2.4.27-bs1, SKAS3/2.6-V7 released

[Blaisorblade]

On Monday 08 November 2004 13:28, Nuutti Kotivuori wrote:
> Blaisorblade wrote:
> > Changes in both 2.6.9 and 2.4.27:
> > they run fine on 2.6.9 host kernels, without hanging at the exit.
>
> I want to get this clear:

> Every older guest UML kernel will hang on exit on 2.6.9 hosts from now
> on, and there's nothing to fix it but to update the guest UML patches?

> This is a nasty limitation in general - because it means that on the
> update to 2.6.9, every kernel binary needs to be updated - and finding
> rock solid versions of kernels + UML patches is not a fast process.

Yes, I perfectly agree with you. However, there are, for 2.6, the security 
fixes which are needed.

Well, it is possible that 2.6.10 (or even 2.6.11) will make again old UML 
binaries work. I.e., this is my hope, but no code is ready for this, yet.

In fact, Linus always said "binary compatibility is important".

UML was using a strange undocumented, and unwanted interface, but this is not 
a good reason for the kernel to break it. I think they did not even notice 
that. Also, however, I find that the breakage is a real bug.

The splitout version of the patches is available, and the 
uml-hang-on-2.6.9-host.patch is the one to apply. For 2.4, it cannot be 
applied separately, though (it requires one of the current incrementals, 
which is included in the patchset).

Unfortunately, it does not work on most kernel versions - it can be adapted, 
though, and if I find time, I will.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729