[uml-devel] SIGSEGV and SA_NODEFER

[uml-devel] SIGSEGV and SA_NODEFER

[Jeff Dike]

It turns out that caker's crashes were being caused by the lack of SA_NODEFER
in the SIGSEGV handler registration.

I know I fixed this, and I have no idea where the fix went.  Do you have any
clue what happened to it?

Patch below...

				Jeff

Index: 2.6.10/arch/um/kernel/process.c
===================================================================
--- 2.6.10.orig/arch/um/kernel/process.c        2005-01-17 12:27:47.000000000 -0500
+++ 2.6.10/arch/um/kernel/process.c     2005-01-18 13:55:28.000000000 -0500
@@ -60,7 +60,10 @@
 {
        int flags = altstack ? SA_ONSTACK : 0;
 
-       set_handler(SIGSEGV, (__sighandler_t) sig_handler, flags,
+       /* SIGSEGV needs to be SA_NODEFER because segfaults can happen while
+        * the segfault handler is on the stack.
+        */
+       set_handler(SIGSEGV, (__sighandler_t) sig_handler, flags | SA_NODEFER,
                    SIGUSR1, SIGIO, SIGWINCH, SIGALRM, SIGVTALRM, -1);
        set_handler(SIGTRAP, (__sighandler_t) sig_handler, flags, 
                    SIGUSR1, SIGIO, SIGWINCH, SIGALRM, SIGVTALRM, -1);



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Tuesday 18 January 2005 22:28, Jeff Dike wrote:
> It turns out that caker's crashes were being caused by the lack of
> SA_NODEFER in the SIGSEGV handler registration.
As Jeff explained me on IRC, the previous patch sent about the same subject, 
actually, was correct, but not related to the caker's problem.

Since Jeff explained everything on IRC (#uml) I'm just explaining it here for 
the archives.

> I know I fixed this, and I have no idea where the fix went.  Do you have
> any clue what happened to it?

The SA_NODEFER flag was dropped from that call in 2.6.7-2um in the "random" 
patch, in 2.4.24-2um, and finally in  
uml-let-page-faults-always-be-delivered-immediately.patch in 2.6.9-rc2-mm1.

That was compensated by adding the addition of this hunk for TT mode in 
sig_handler_common_tt() :

        /* This is done because to allow SIGSEGV to be delivered inside a SEGV
         * handler.  This can happen in copy_user, and if SEGV is disabled,
         * the process will die.
         */
        if(sig == SIGSEGV)
                change_sig(SIGSEGV, 1);

But this was forgot for sig_handler_common_skas()... and this caused the 
problem.

I found this change to be done also in 2.4.24-2um; moreover, it's part of the 
patch which causes hwclock to hang on 2.4 - I'll try applying your fix to 2.4 
and retesting with hwclock.

What was discovered until now is this:

The relation is obviously hidden somehow... however I sent on the uml-devel 
list a couple of patches from after 2.4.24-1um: without them UML does not 
suffer from the Debian/hwclock crash, while it happens with them. What's 
strange is that the crash happens within TT mode, not within SKAS mode. And 
rather than a crash, it's a hang, due to an infinite number of received 
SIGSEGVs. Inside the couple of patches, there is exactly this problematic 
change.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Wednesday 19 January 2005 07:07 pm, Blaisorblade wrote:

> What was discovered until now is this:
>
> The relation is obviously hidden somehow... however I sent on the uml-devel
> list a couple of patches from after 2.4.24-1um: without them UML does not
> suffer from the Debian/hwclock crash, while it happens with them. What's
> strange is that the crash happens within TT mode, not within SKAS mode. And
> rather than a crash, it's a hang, due to an infinite number of received
> SIGSEGVs. Inside the couple of patches, there is exactly this problematic
> change.

Ooh, ooh!  Hang in TT mode is what I'm seeing with my makefile hang.  (sh -x 
dosn't help if the makefile doesn't call out to stuff with it.)

If the previous patch doesn't address it, is there a new patch I could try?

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Thursday 20 January 2005 04:52, Rob Landley wrote:
> On Wednesday 19 January 2005 07:07 pm, Blaisorblade wrote:
> > What was discovered until now is this:
> >
> > The relation is obviously hidden somehow... however I sent on the
> > uml-devel list a couple of patches from after 2.4.24-1um: without them
> > UML does not suffer from the Debian/hwclock crash, while it happens with
> > them. What's strange is that the crash happens within TT mode, not within
> > SKAS mode. And rather than a crash, it's a hang, due to an infinite
> > number of received SIGSEGVs. Inside the couple of patches, there is
> > exactly this problematic change.
>
> Ooh, ooh!  Hang in TT mode is what I'm seeing with my makefile hang.  (sh
> -x dosn't help if the makefile doesn't call out to stuff with it.)
>
> If the previous patch doesn't address it, is there a new patch I could try?
Well, you solved this problem with the 2.6.11-rc1-mm2, right (from the message 
below)?

The patch which was merged there is the one posted with title "[uml-devel] 
[PATCH] Fix stack corruption" on this list..., I guess... it will be in 
2.6.9-bs6 and 2.6.10-bb1 (both to release) - are you willing to test one of 
them, when I do the release? I'd be very thankful to accept your help...
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Friday 21 January 2005 07:35 am, Blaisorblade wrote:

> > Ooh, ooh!  Hang in TT mode is what I'm seeing with my makefile hang.  (sh
> > -x dosn't help if the makefile doesn't call out to stuff with it.)
> >
> > If the previous patch doesn't address it, is there a new patch I could
> > try?
>
> Well, you solved this problem with the 2.6.11-rc1-mm2, right (from the
> message below)?

With 2.6.11-rc1-mm2, my toolchain build runs through to completion under UML.  
(Very very slowly, but it does.  Tested on a 1.6 ghz 2 meg cache computer, 
which runs it under UML at about the speed of my 700 mhz 128k cache laptop 
without UML.  But hey, it's using tt mode, and completing correctly.  That's 
the important thing...)

> The patch which was merged there is the one posted with title "[uml-devel]
> [PATCH] Fix stack corruption" on this list..., I guess... it will be in
> 2.6.9-bs6 and 2.6.10-bb1 (both to release) - are you willing to test one of
> them, when I do the release? I'd be very thankful to accept your help...

I'll happily try out 2.6.10-bb1, sure.

The mm2 changelog says it has:

-uml-avoid-null-dereference-in-linec.patch
-uml-readd-config_magic_sysrq-for-uml.patch
-uml-commentary-addition-to-recent-sysemu-fix.patch
-uml-drop-unused-buffer_headh-header-from-hostfs.patch
-uml-delete-unused-header-umnh.patch
-uml-commentary-about-sigwinch-handling-for-consoles.patch
-uml-fail-xterm_open-when-we-have-no-display.patch
-uml-depend-on-usermode-in-drivers-block-kconfig-and-drop-arch-um-kconfig_block.patch
-uml-makefile-simplification-and-correction.patch
-uml-fix-compilation-for-missing-headers.patch
-uml-fix-some-uml-own-initcall-macros.patch
-uml-refuse-to-run-without-skas-if-no-tt-mode-in.patch
-uml-for-ubd-cmdline-param-use-colon-as-delimiter.patch
-uml-allow-free-ubd-flag-ordering.patch
-uml-move-code-from-ubd_user-to-ubd_kern.patch
-uml-fix-and-cleanup-code-in-ubd_kernc-coming-from-ubd_userc.patch
-uml-add-stack-content-to-dumps.patch
-uml-add-stack-addresses-to-dumps.patch
-uml-update-ld-scripts-to-newer-binutils.patch

More later, lunch is over...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Friday 21 January 2005 19:18, Rob Landley wrote:
> On Friday 21 January 2005 07:35 am, Blaisorblade wrote:
> > > Ooh, ooh!  Hang in TT mode is what I'm seeing with my makefile hang. 
> > > (sh -x dosn't help if the makefile doesn't call out to stuff with it.)
> > >
> > > If the previous patch doesn't address it, is there a new patch I could
> > > try?
> >
> > Well, you solved this problem with the 2.6.11-rc1-mm2, right (from the
> > message below)?
>
> With 2.6.11-rc1-mm2, my toolchain build runs through to completion under
> UML. (Very very slowly, but it does.  Tested on a 1.6 ghz 2 meg cache
> computer, which runs it under UML at about the speed of my 700 mhz 128k
> cache laptop without UML.  But hey, it's using tt mode, and completing
> correctly.  That's the important thing...)
>
> > The patch which was merged there is the one posted with title
> > "[uml-devel] [PATCH] Fix stack corruption" on this list..., I guess... it
> > will be in 2.6.9-bs6 and 2.6.10-bb1 (both to release) - are you willing
> > to test one of them, when I do the release? I'd be very thankful to
> > accept your help...
>
> I'll happily try out 2.6.10-bb1, sure.

> The mm2 changelog says it has:

That is -mm1, I've already looked at both... the patches listed below are 
minor fixes / improvements...

The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue is:

uml-fix-a-stack-corruption-crash.patch

If it's not a problem, try removing it from -mm2 and recompiling, and test if 
you get the crash with the new kernel (which is what I expect)...
>
> More later, lunch is over...
Here, now, I must go to dinner... bye!
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Friday 21 January 2005 02:58 pm, Blaisorblade wrote:

> That is -mm1, I've already looked at both... the patches listed below are
> minor fixes / improvements...
>
> The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue is:
>
> uml-fix-a-stack-corruption-crash.patch

I reverted that patch, rebuilt vmlinux, tried again, and it's happily halfway 
through the binutils build as I type.  That fix doesn't seem to be it.  
(Makes a certain amount of sense, since I wasn't seeing a crash, I was seeing 
a hang.)

> If it's not a problem, try removing it from -mm2 and recompiling, and test
> if you get the crash with the new kernel (which is what I expect)...
>
> > More later, lunch is over...
>
> Here, now, I must go to dinner... bye!

Another interesting point is that with -mm2 (patched or unpatched), I'm seeing 
output hiccups when the system swaps.  Here's a cut and paste of a section 
where it was extracting the binutils tarball:

binutils-2.14/gas/testsuite/gas/hppa/unsorted/common.s
binutils-2.14/gas/testsuite/gas/hppa/unsorted/fragbug.s
binutils-2.14/gas/testsuite/gas/hppa/unsorteortedrted/ted/ged/gld/glo/globglobalobalobalbbalbualbuglbug.bug.sug.sg.s.ss
binutils-2.14/gas/testsuite/gas/hppa/unsorted/importbug.s

And later on...

binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.dd
binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd
binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss
binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//ld/tld/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.sd4.sd.sdsd
binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td
binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic32.s
binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic64.s
binutils-2.14/ld/testsuite/ld-sparc/tlssunnopic32.dd

It did it about five or six times, that I noticed.  (And it did it before I 
reverted the stack fix patch, so that's not it.)

I had all that output piped to tee, which output it to out.txt, and the 
corresponding line of out.txt isn't glitched, so it seems to just be a 
cosmetic bug in the display code.  But I thought I'd report it anyway.  I'm 
using stdin/stdout as the console.  (And even though you put it into raw 
mode, I still can't ctrl-c out of the processs I'm running, either.)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Saturday 22 January 2005 17:34, Rob Landley wrote:
> On Friday 21 January 2005 02:58 pm, Blaisorblade wrote:
> > That is -mm1, I've already looked at both... the patches listed below are
> > minor fixes / improvements...
> >
> > The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue is:
> >
> > uml-fix-a-stack-corruption-crash.patch
>
> I reverted that patch, rebuilt vmlinux, tried again, and it's happily
> halfway through the binutils build as I type.  That fix doesn't seem to be
> it. (Makes a certain amount of sense, since I wasn't seeing a crash, I was
> seeing a hang.)
Hmm, and so what is fixing your problem? It's difficult to tell in this 
case...
> > If it's not a problem, try removing it from -mm2 and recompiling, and
> > test if you get the crash with the new kernel (which is what I expect)...
> >
> > > More later, lunch is over...
> >
> > Here, now, I must go to dinner... bye!
>
> Another interesting point is that with -mm2 (patched or unpatched), I'm
> seeing output hiccups when the system swaps.
Host or guest? If it's the host system, then my idea about it (a locking 
problem) is a good explaination, but if it's the guest system to swap I 
haven't clear why it works (not investigated well yet, through).
> Here's a cut and paste of a 
> section where it was extracting the binutils tarball:
>
> binutils-2.14/gas/testsuite/gas/hppa/unsorted/common.s
> binutils-2.14/gas/testsuite/gas/hppa/unsorted/fragbug.s
> binutils-2.14/gas/testsuite/gas/hppa/unsorteortedrted/ted/ged/gld/glo/globg
>lobalobalobalbbalbualbuglbug.bug.sug.sg.s.ss
> binutils-2.14/gas/testsuite/gas/hppa/unsorted/importbug.s
>
> And later on...
>
> binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.dd
> binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd
> binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/tlc
>/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss
> binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//ld/tl
>d/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-spa-s
>parsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64
>.s64.sd4.sd.sdsd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td
> binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic32.s
> binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic64.s
> binutils-2.14/ld/testsuite/ld-sparc/tlssunnopic32.dd
>
> It did it about five or six times, that I noticed.  (And it did it before I
> reverted the stack fix patch, so that's not it.)
>
> I had all that output piped to tee, which output it to out.txt, and the
> corresponding line of out.txt isn't glitched, so it seems to just be a
> cosmetic bug in the display code.  But I thought I'd report it anyway.
Good thing, thanks...
> I'm 
> using stdin/stdout as the console.  (And even though you put it into raw
> mode, I still can't ctrl-c out of the processs I'm running, either.)

Does this happen in -bb4 too? Also, does it happen even if you use a xterm 
console?

> Rob

Well, am I right if I suppose the other version you tested (with success) is 
only 2.6.9-bb4, for this console issue?

There is a patch which was merged in 2.6.10-mm1 (IIRC), which changes heavily 
the I/O core... I'm CC:ing the author for more investigation.

However, I'm not sure that patch is at fault... there is a locking problem 
which *could* maybe be responsible of this...; I actually wonder about why 
this locking problem has never shown up in reports or in testing (it exists, 
only it's a race condition)... there is a situation where it shows up with a 
side effect, indeed, so the problem exists...


-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Monday 24 January 2005 02:45 pm, Blaisorblade wrote:
> On Saturday 22 January 2005 17:34, Rob Landley wrote:
> > On Friday 21 January 2005 02:58 pm, Blaisorblade wrote:
> > > That is -mm1, I've already looked at both... the patches listed below
> > > are minor fixes / improvements...
> > >
> > > The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue
> > > is:
> > >
> > > uml-fix-a-stack-corruption-crash.patch
> >
> > I reverted that patch, rebuilt vmlinux, tried again, and it's happily
> > halfway through the binutils build as I type.  That fix doesn't seem to
> > be it. (Makes a certain amount of sense, since I wasn't seeing a crash, I
> > was seeing a hang.)
>
> Hmm, and so what is fixing your problem? It's difficult to tell in this
> case...

I know.

I can try a binary search, but the work week has returned, and with it the 
dreaded day job...

> > Another interesting point is that with -mm2 (patched or unpatched), I'm
> > seeing output hiccups when the system swaps.
>
> Host or guest? If it's the host system, then my idea about it (a locking
> problem) is a good explaination, but if it's the guest system to swap I
> haven't clear why it works (not investigated well yet, through).

The host system is swapping.  The guest is configured without swap support.

> > I'm
> > using stdin/stdout as the console.  (And even though you put it into raw
> > mode, I still can't ctrl-c out of the processs I'm running, either.)
>
> Does this happen in -bb4 too? Also, does it happen even if you use a xterm
> console?

I didn't see it in -bb4 (doesn't prove it didn't happen, but it's pretty 
noticeable in -rc1-mm2).  I haven't tried an xterm console yet.

By the way, just confirming: file I/O support is now compiled in all the time, 
right?  (I noticed that there's no longer a config option for them, but 
setting console to fd0/fd1 seems to be working.  Well, run as root anyway, 
there's some kind of permissions problem if I fire up hostfs as a normal user 
that makes the console refuse to open.  I'm off completely rewriting busybox 
mount now that UML revealed that --bind and --move mounts don't work with 
busybox mount if /proc/filesystems consists entirely of "nodev" filesystems, 
so it'll take me a bit to come back to thumping on this...)

> > Rob
>
> Well, am I right if I suppose the other version you tested (with success)
> is only 2.6.9-bb4, for this console issue?

I didn't see it on -bb4.  I could try again and stress the system a bit, but I 
suspect it wasn't there.

> There is a patch which was merged in 2.6.10-mm1 (IIRC), which changes
> heavily the I/O core... I'm CC:ing the author for more investigation.
>
> However, I'm not sure that patch is at fault... there is a locking problem
> which *could* maybe be responsible of this...; I actually wonder about why
> this locking problem has never shown up in reports or in testing (it
> exists, only it's a race condition)... there is a situation where it shows
> up with a side effect, indeed, so the problem exists...

Okay, a little about me.

I am the "linux on the desktop" nightmare scenario.  I buy cheap used hardware 
(currently using a thinkpad with 128 megs of ram which I got for $400), and 
then stress it way beyond its limits.

For example, I use Konqueror for my web browsing, which is very nice from a 
user perspective but has a couple of really HORRIBLE internal design issues 
to do with opening lots of windows/tabs at once.  (Which I do.)  It cycles 
through all the open windows/tabs for various things, swapping through memory 
round-robin.  Opening a new window has been known to make the VM sit there 
and swap for 30 seconds, so badly that the mouse cursor doesn't move at all.

Currently, konqueror only has 17 tabs open, in only one window, which is 
actually fairly light for me.  (I'm fairly certain konqueror pins memory 
somehow, and I know it never actually frees any until you exit the darn 
thing.)

On top of that, kmail is up.  I have over 10,000 threaded messages in the 
linux-kernel mailing list alone.  (I have to catch up soon and delete the 
excess, kmail used to corrupt its indexing if you deleted messages from a 
mbox folder with over about 20,000 of them.  And, of course, I have xmms up 
to play mp3's.)

Strangely enough, compiling software in a background window adds negligible 
load, it's all the desktop stuff I'm doing that makes it swap its brains out.

Back under the 2.4.4 kernel or so, it took me about 15 seconds to make the 
system swap so badly I could go to lunch and come back with it still frozen 
and swapping.  Now in the 2.6 series, the swap is _much_ better, it's never 
completely frozen for longer than about 45 seconds.

The early releases of XFree86 4.something had a bug where if an internal wait 
timed out the X server would exit back to text mode.  I used to hit that 
_daily_.

So if there are any weird latency bugs lurking where inserting a second or 
three delay somewhere causes something to hiccup, I bump into them as a 
matter of course. :)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Tuesday 25 January 2005 09:45, Gerd Knorr wrote:
> > > binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.dd
> > > binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd
> > > binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc
> > >/tlc /tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss
> > > binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//l
> > >d/tl
> > > d/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-
> > >spa-s
> > > parsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in6
> > >4.n64 .s64.sd4.sd.sdsd
> > > binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td
> > > binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic32.s
> > > binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic64.s
> > > binutils-2.14/ld/testsuite/ld-sparc/tlssunnopic32.dd
> > >
> > > I had all that output piped to tee, which output it to out.txt, and the
> > > corresponding line of out.txt isn't glitched, so it seems to just be a
> > > cosmetic bug in the display code.  But I thought I'd report it anyway.
> >
> > Good thing, thanks...

> I remember having seen a comment (and patch?) on one of the lists for
> the tty line buffering, because of data loss in case the buffers are
> full.  Don't remember the details but this could be related.

> > > I'm using stdin/stdout as the console.  (And even though you put it
> > > into raw mode, I still can't ctrl-c out of the processs I'm running,
> > > either.)

> Hmm, ^C works perfectly fine for me.  Usually I work with a virtual
> serial line as console ("console=ttyS0 ssl0=fd:0,fd:1 con=pts"), works
> better than the uml console as applications don't expect the linux vt
> ioctls work on these devices ;)

About this, Rob: do you use /dev/console in the inittab line? If you do, then 
that's the problem - it should become a FAQ somewhere I guess.

> I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2.

> > However, I'm not sure that patch is at fault... there is a locking
> > problem which *could* maybe be responsible of this...; I actually wonder
> > about why this locking problem has never shown up in reports or in
> > testing (it exists, only it's a race condition)... there is a situation
> > where it shows up with a side effect, indeed, so the problem exists...

> Heavy swapping (see other mail) and thus some stuff running _very_ slow
> might open such race windows wide enougth that one actually hits them.

Yes, my only doubt was that he seemed to mean that the guest was swapping, and 
*this* different situation would have the opposite effect, probably.

> The uml-terminal-cleanup patch doesn't touch how the uml terminal lines
> output (xterm, pty, ...) works, it's more the input side which has been
> reworked a bit, especially the console handling (console meaning the
> device the kernel sends the printk messages to, not the linux vt
> subsystem).

>   Gerd

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Tuesday 25 January 2005 05:16 am, Blaisorblade wrote:
> > > > I'm using stdin/stdout as the console.  (And even though you put it
> > > > into raw mode, I still can't ctrl-c out of the processs I'm running,
> > > > either.)
> >
> > Hmm, ^C works perfectly fine for me.  Usually I work with a virtual
> > serial line as console ("console=ttyS0 ssl0=fd:0,fd:1 con=pts"), works
> > better than the uml console as applications don't expect the linux vt
> > ioctls work on these devices ;)
>
> About this, Rob: do you use /dev/console in the inittab line? If you do,
> then that's the problem - it should become a FAQ somewhere I guess.

I'm not using init, I'm running my script as init.  So I'd guess it's 
using /dev/console, yes.

I know that /dev/console is funky.  That's why I want the option to let ctrl-c 
kill the whole vmlinux instance.  (Possibly as a command line option.)  I'll 
look into that later...

> > I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2.
> >
> > > However, I'm not sure that patch is at fault... there is a locking
> > > problem which *could* maybe be responsible of this...; I actually
> > > wonder about why this locking problem has never shown up in reports or
> > > in testing (it exists, only it's a race condition)... there is a
> > > situation where it shows up with a side effect, indeed, so the problem
> > > exists...
> >
> > Heavy swapping (see other mail) and thus some stuff running _very_ slow
> > might open such race windows wide enougth that one actually hits them.
>
> Yes, my only doubt was that he seemed to mean that the guest was swapping,
> and *this* different situation would have the opposite effect, probably.

Host is swapping, client configured without even support for swap.  (If I can 
get the darn client vmlinux down to 1 megabyte, I'd be thrilled.  Didn't 
somebody once make the entire block layer configurable out once?  With 
hostfs, I don't need it...)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Tuesday 25 January 2005 11:16, Rob Landley wrote:
> On Tuesday 25 January 2005 05:16 am, Blaisorblade wrote:
> > > > > I'm using stdin/stdout as the console.  (And even though you put it
> > > > > into raw mode, I still can't ctrl-c out of the processs I'm
> > > > > running, either.)
> > >
> > > Hmm, ^C works perfectly fine for me.  Usually I work with a virtual
> > > serial line as console ("console=ttyS0 ssl0=fd:0,fd:1 con=pts"), works
> > > better than the uml console as applications don't expect the linux vt
> > > ioctls work on these devices ;)

> > About this, Rob: do you use /dev/console in the inittab line? If you do,
> > then that's the problem - it should become a FAQ somewhere I guess.

> I'm not using init, I'm running my script as init.  So I'd guess it's
> using /dev/console, yes.

> I know that /dev/console is funky.  That's why I want the option to let
> ctrl-c kill the whole vmlinux instance.  (Possibly as a command line
> option.)  I'll look into that later...

> > > I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2.

> > > > However, I'm not sure that patch is at fault... there is a locking
> > > > problem which *could* maybe be responsible of this...; I actually
> > > > wonder about why this locking problem has never shown up in reports
> > > > or in testing (it exists, only it's a race condition)... there is a
> > > > situation where it shows up with a side effect, indeed, so the
> > > > problem exists...
> > >
> > > Heavy swapping (see other mail) and thus some stuff running _very_ slow
> > > might open such race windows wide enougth that one actually hits them.
> >
> > Yes, my only doubt was that he seemed to mean that the guest was
> > swapping, and *this* different situation would have the opposite effect,
> > probably.
>
> Host is swapping, client configured without even support for swap.  (If I
> can get the darn client vmlinux down to 1 megabyte, I'd be thrilled. 
> Didn't somebody once make the entire block layer configurable out once? 
> With hostfs, I don't need it...)

Do you trust hostfs so much? You don't need user IDs on your FS, I guess. I'm 
not at all happy with this, but I don't want someone using hostfs over its 
possibilities. NFS is much better, anyway. And somebody says it's also faster 
(and since hostfs does limited caching, it makes sense - hostfs must avoid 
having any inode cache, since it closes the host fd only when the inode is 
evicted from the cache; I don't think it's possible to cache data without an 
inode to link to, so it's clear it's slow).
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Tuesday 25 January 2005 06:40 am, Blaisorblade wrote:

> > Host is swapping, client configured without even support for swap.  (If I
> > can get the darn client vmlinux down to 1 megabyte, I'd be thrilled.
> > Didn't somebody once make the entire block layer configurable out once?
> > With hostfs, I don't need it...)
>
> Do you trust hostfs so much? You don't need user IDs on your FS, I guess.

Once I get /dev on ramfs managed by udev?  Not really, no.  I need the 
permissions to be right, but just about everything else should belong to 
root.  (Yeah, there are a couple fun tricks where files change their 
ownership to some variant of "nobody" to do chroot jails and stuff, but they 
do that at runtime...) 

I've probably missed one or two instances, but I expect I can work around 
'em...

> I'm not at all happy with this, but I don't want someone using hostfs over
> its possibilities. NFS is much better, anyway.

NFS gives me hives (a stateless fileserver: okay, spot the contradiction in 
terms here), although I must admit I haven't tried the new TCP/IP based 
version (V4?) yet because it wasn't finished last time I tried.

> And somebody says it's also 
> faster (and since hostfs does limited caching, it makes sense - hostfs must
> avoid having any inode cache, since it closes the host fd only when the
> inode is evicted from the cache; I don't think it's possible to cache data
> without an inode to link to, so it's clear it's slow).

Since the host is cacheing the data for us, not having a redundant cache 
sounds like a good idea to me.  Admittedly, it's more syscalls, but less 
memory consumption...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Tuesday 25 January 2005 18:30, Rob Landley wrote:
> On Tuesday 25 January 2005 06:40 am, Blaisorblade wrote:
> > > Host is swapping, client configured without even support for swap.  (If
> > > I can get the darn client vmlinux down to 1 megabyte, I'd be thrilled.
> > > Didn't somebody once make the entire block layer configurable out once?
> > > With hostfs, I don't need it...)
> >
> > Do you trust hostfs so much? You don't need user IDs on your FS, I guess.
>
> Once I get /dev on ramfs managed by udev?  Not really, no.  I need the
> permissions to be right, but just about everything else should belong to
> root.  (Yeah, there are a couple fun tricks where files change their
> ownership to some variant of "nobody" to do chroot jails and stuff, but
> they do that at runtime...)
I don't expect chown to work at all - i.e. it's not "it forgets it at reboot", 
it's "it forgets it immediately"... If you see it working, maybe you are 
seeing the more precise behaviour "it forgets it As Soon as the file is 
closed".
> I've probably missed one or two instances, but I expect I can work around
> 'em...
>
> > I'm not at all happy with this, but I don't want someone using hostfs
> > over its possibilities. NFS is much better, anyway.
>
> NFS gives me hives
?? What's hives?
> (a stateless fileserver: okay, spot the contradiction in 
> terms here), although I must admit I haven't tried the new TCP/IP based
> version (V4?) yet because it wasn't finished last time I tried.
>
> > And somebody says it's also
> > faster (and since hostfs does limited caching, it makes sense - hostfs
> > must avoid having any inode cache, since it closes the host fd only when
> > the inode is evicted from the cache; I don't think it's possible to cache
> > data without an inode to link to, so it's clear it's slow).
>
> Since the host is cacheing the data for us, not having a redundant cache
> sounds like a good idea to me.  Admittedly, it's more syscalls, but less
> memory consumption...

The problem is that its slower than NFS!
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Tuesday 25 January 2005 02:34 pm, Blaisorblade wrote:
> > Once I get /dev on ramfs managed by udev?  Not really, no.  I need the
> > permissions to be right, but just about everything else should belong to
> > root.  (Yeah, there are a couple fun tricks where files change their
> > ownership to some variant of "nobody" to do chroot jails and stuff, but
> > they do that at runtime...)
>
> I don't expect chown to work at all - i.e. it's not "it forgets it at
> reboot", it's "it forgets it immediately"... If you see it working, maybe
> you are seeing the more precise behaviour "it forgets it As Soon as the
> file is closed".

Actually, I don't think I've tried to do a chown on UML at all.  As I said, 
the files I care about the ownership of being right (the /dev directory) are 
all in a ramfs.  Everything else should belong to root, I just care that the 
permissions are right.  (A user can set the suid bit on their own files, 
right?)

And what I meant to say earlier is that some programs chuser (like bind and 
httpd and such), which they do at runtime

Still, good point.  I'm doing a rebuild without UML and I'll run "find . -not 
-uid 0" on the result to see what comes up...

> > I've probably missed one or two instances, but I expect I can work around
> > 'em...
> >
> > > I'm not at all happy with this, but I don't want someone using hostfs
> > > over its possibilities. NFS is much better, anyway.
> >
> > NFS gives me hives
>
> ?? What's hives?

An NFS server can't be exposed to the internet securely.  (To add insult to 
injury, for _years_ Red Hat exposed portmap and such to the outside world and 
there was absolutely no way to tell it not to install/run that crud, and you 
had to go in by hand and rip them out of each new install if you wanted it on 
the net.)

NFS was designed to be a stateless protocol, yet the point of a filesystem is 
to maintain state.  It DIDN'T just do a TCP/IP connection to a client, 
instead it did weird UDP stuff so the server doesn't have to know which files 
the client has open and 8 gazillion other strange corner cases that I stopped 
trying to pay attention to more than 5 years ago.

I'm told the most recent version of NFS has been redesigned to work like 
Samba: a client that mounts one of these things opens a TCP/IP session, and 
if it gets closed the client re-opens it.  I should look into that, but the 
last time I did support for the new way of doing it it wasn't in the kernel 
yet.

> > > And somebody says it's also
> > > faster (and since hostfs does limited caching, it makes sense - hostfs
> > > must avoid having any inode cache, since it closes the host fd only
> > > when the inode is evicted from the cache; I don't think it's possible
> > > to cache data without an inode to link to, so it's clear it's slow).
> >
> > Since the host is cacheing the data for us, not having a redundant cache
> > sounds like a good idea to me.  Admittedly, it's more syscalls, but less
> > memory consumption...
>
> The problem is that its slower than NFS!

Okay, remember how my build process is designed to be packaged up, exported to 
some random Linux system out there, and run as a normal user without root 
access?  HostFS is exactly what I need.  Even assuming an NFS server is 
installed on the target system, a normal user can't run nfsd if it isn't 
already running on the system, and can't control what it exports if it is. 

Maybe I'll profile it and look at speeding it up later, but not anytime 
soon...

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Tuesday 25 January 2005 20:30, Rob Landley wrote:
> On Tuesday 25 January 2005 02:34 pm, Blaisorblade wrote:
> > > Once I get /dev on ramfs managed by udev?  Not really, no.  I need the
> > > permissions to be right, but just about everything else should belong
> > > to root.  (Yeah, there are a couple fun tricks where files change their
> > > ownership to some variant of "nobody" to do chroot jails and stuff, but
> > > they do that at runtime...)

> > I don't expect chown to work at all - i.e. it's not "it forgets it at
> > reboot", it's "it forgets it immediately"... If you see it working, maybe
> > you are seeing the more precise behaviour "it forgets it As Soon as the
> > file is closed".

> Actually, I don't think I've tried to do a chown on UML at all.  As I said,
> the files I care about the ownership of being right (the /dev directory)
> are all in a ramfs.  Everything else should belong to root, I just care
> that the permissions are right.  (A user can set the suid bit on their own
> files, right?)
Theoretically yes... however, sadly, chmod 4777 /mnt/host/bin/dash works and 
is a suitable exploit... with other shells, it depends (bash refuses to work 
as setuid)...
> And what I meant to say earlier is that some programs chuser (like bind and
> httpd and such), which they do at runtime
You mean they call setuid() / setgid() or such, which should be ok... but you 
get 
> Still, good point.  I'm doing a rebuild without UML and I'll run "find .
> -not -uid 0" on the result to see what comes up...

> > > > I'm not at all happy with this, but I don't want someone using hostfs
> > > > over its possibilities. NFS is much better, anyway.
> > >
> > > NFS gives me hives
> >
> > ?? What's hives?
I've searched for it - is not "hive" the place for bees? I understand you mean 
something like "issues"...
> An NFS server can't be exposed to the internet securely.
Agreed... you cannot rely on root access on the host, otherwise what you would 
do likely is to add some firewall rules (and to ask it to listen on the "lo" 
interface only, if possible).

> (To add insult to 
> injury, for _years_ Red Hat exposed portmap and such to the outside world
> and there was absolutely no way to tell it not to install/run that crud,
> and you had to go in by hand and rip them out of each new install if you
> wanted it on the net.)

> NFS was designed to be a stateless protocol, yet the point of a filesystem
> is to maintain state.  It DIDN'T just do a TCP/IP connection to a client,
> instead it did weird UDP stuff so the server doesn't have to know which
> files the client has open and 8 gazillion other strange corner cases that I
> stopped trying to pay attention to more than 5 years ago.

> I'm told the most recent version of NFS has been redesigned to work like
> Samba: a client that mounts one of these things opens a TCP/IP session, and
> if it gets closed the client re-opens it.  I should look into that, but the
> last time I did support for the new way of doing it it wasn't in the kernel
> yet.
Well, IIRC NFS over TCP/IP exists and works also for NFSv3 (maybe 
EXPERIMENTAL, but it's included since some time, even in 2.4 I think, and 
probably is more reliable than hostfs). NFSv4 is the only real secure-thought 
protocol, and it's experimental like you say.

> > > > And somebody says it's also
> > > > faster (and since hostfs does limited caching, it makes sense -
> > > > hostfs must avoid having any inode cache, since it closes the host fd
> > > > only when the inode is evicted from the cache; I don't think it's
> > > > possible to cache data without an inode to link to, so it's clear
> > > > it's slow).

> > > Since the host is cacheing the data for us, not having a redundant
> > > cache sounds like a good idea to me.  Admittedly, it's more syscalls,
> > > but less memory consumption...
> >
> > The problem is that its slower than NFS!
>
> Okay, remember how my build process is designed to be packaged up, exported
> to some random Linux system out there, and run as a normal user without
> root access?  HostFS is exactly what I need.  Even assuming an NFS server
> is installed on the target system, a normal user can't run nfsd if it isn't
> already running on the system, and can't control what it exports if it is.
>
> Maybe I'll profile it and look at speeding it up later, but not anytime
> soon...
In that case, you could maybe see humfs ready (which is a hostfs with an added 
support for storing metadatas on the host filesystem). I guess it won't be 
before 2.6.13.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Tuesday 25 January 2005 03:50 pm, Blaisorblade wrote:

> > Actually, I don't think I've tried to do a chown on UML at all.  As I
> > said, the files I care about the ownership of being right (the /dev
> > directory) are all in a ramfs.  Everything else should belong to root, I
> > just care that the permissions are right.  (A user can set the suid bit
> > on their own files, right?)
>
> Theoretically yes... however, sadly, chmod 4777 /mnt/host/bin/dash works
> and is a suitable exploit... with other shells, it depends (bash refuses to
> work as setuid)...

I was thinking more along the lines of installing the "su" binary and such 
correctly and having the permissions retained long enough to make the 
squashfs image out of it.

I'm not worried about security within the UML instance.  It's running as a 
normal user, and it's running a build script.  When the script exits, the VM 
exits.  It's not a server or anything, it's basically an runtime for a batch 
file.

> > And what I meant to say earlier is that some programs chuser (like bind
> > and httpd and such), which they do at runtime
>
> You mean they call setuid() / setgid() or such, which should be ok... but
> you get
>
> > Still, good point.  I'm doing a rebuild without UML and I'll run "find .
> > -not -uid 0" on the result to see what comes up...

Speaking of which, I did this and there wasn't anything that didn't belong to 
root.  (Okay, /proc and /dev/pts showed plenty of stuff, but that's because I 
forgot and left them mounted after the build.  And several group ids were 
nonzero in /dev, but I expected that...)

> > > > > I'm not at all happy with this, but I don't want someone using
> > > > > hostfs over its possibilities. NFS is much better, anyway.
> > > >
> > > > NFS gives me hives
> > >
> > > ?? What's hives?
>
> I've searched for it - is not "hive" the place for bees? I understand you
> mean something like "issues"...

American colloquialism.  "gives me hives" also means it makes you break out in 
a rash, and the meaning's wandered a bit towards "makes my skin crawl"...

> > An NFS server can't be exposed to the internet securely.
>
> Agreed... you cannot rely on root access on the host, otherwise what you
> would do likely is to add some firewall rules (and to ask it to listen on
> the "lo" interface only, if possible).

I could beat it into submission, but it's not worth the performance boost or 
the conceptual complexity.  One advantage of UML is that I have to build the 
linux kernel _anyway_, so it's not an extra package I need to include in the 
build process and make sure I keep up to date.  I'll happily milk that for 
all it's worth.

> > I'm told the most recent version of NFS has been redesigned to work like
> > Samba: a client that mounts one of these things opens a TCP/IP session,
> > and if it gets closed the client re-opens it.  I should look into that,
> > but the last time I did support for the new way of doing it it wasn't in
> > the kernel yet.
>
> Well, IIRC NFS over TCP/IP exists and works also for NFSv3 (maybe
> EXPERIMENTAL, but it's included since some time, even in 2.4 I think, and
> probably is more reliable than hostfs). NFSv4 is the only real
> secure-thought protocol, and it's experimental like you say.

I think v3 was the one I looked at, and it didn't do what I was looking for, 
and the NFS guys I talked to told me that how I _wanted_ it to work was 
pretty close to a description of NVSv4.

> > > The problem is that its slower than NFS!
> >
> > Okay, remember how my build process is designed to be packaged up,
> > exported to some random Linux system out there, and run as a normal user
> > without root access?  HostFS is exactly what I need.  Even assuming an
> > NFS server is installed on the target system, a normal user can't run
> > nfsd if it isn't already running on the system, and can't control what it
> > exports if it is.
> >
> > Maybe I'll profile it and look at speeding it up later, but not anytime
> > soon...
>
> In that case, you could maybe see humfs ready (which is a hostfs with an
> added support for storing metadatas on the host filesystem). I guess it
> won't be before 2.6.13.

Sounds like fun.  When you've got something for me to test, I'll be here. :)

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

On Thursday 20 January 2005 01:07, you wrote:
> On Tuesday 18 January 2005 22:28, Jeff Dike wrote:
> > It turns out that caker's crashes were being caused by the lack of
> > SA_NODEFER in the SIGSEGV handler registration.
>
> As Jeff explained me on IRC, the previous patch sent about the same
> subject, actually, was correct, but not related to the caker's problem.
>
> Since Jeff explained everything on IRC (#uml) I'm just explaining it here
> for the archives.
>
> > I know I fixed this, and I have no idea where the fix went.  Do you have
> > any clue what happened to it?
>
> The SA_NODEFER flag was dropped from that call in 2.6.7-2um in the "random"
> patch, in 2.4.24-2um, and finally in
> uml-let-page-faults-always-be-delivered-immediately.patch in 2.6.9-rc2-mm1.
>
> That was compensated by adding the addition of this hunk for TT mode in
> sig_handler_common_tt() :

Are we sure it is a compensation? I started having the doubt that enabling the 
signal inside the handler is not the same thing... because otherwise we don't 
understand why the patch in 2.4 makes difference in TT mode.

Indeed, the blocking is done in the same way, but probably the timing is 
different - i.e. we unblock the signal only after unprotect_kernel_mem() in 
the new code, which somehow *makes* a difference.

I'm going to choose the SA_NODEFER instead of adding the explicit check, at 
least for 2.4. I'd do it for 2.6 too, only that I'm not too sure.

Jeff, what is your suggestion?
>         /* This is done because to allow SIGSEGV to be delivered inside a
> SEGV * handler.  This can happen in copy_user, and if SEGV is disabled, *
> the process will die.
>          */
>         if(sig == SIGSEGV)
>                 change_sig(SIGSEGV, 1);
>

> The relation is obviously hidden somehow... however I sent on the uml-devel
> list a couple of patches from after 2.4.24-1um: without them UML does not
> suffer from the Debian/hwclock crash, while it happens with them. What's
> strange is that the crash happens within TT mode, not within SKAS mode. And
> rather than a crash, it's a hang, due to an infinite number of received
> SIGSEGVs. Inside the couple of patches, there is exactly this problematic
> change.


-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] SIGSEGV and SA_NODEFER

[Jeff Dike]

blaisorblade@yahoo.it said:
> Are we sure it is a compensation? I started having the doubt that
> enabling the  signal inside the handler is not the same thing...
> because otherwise we don't  understand why the patch in 2.4 makes
> difference in TT mode.

Well, it clearly does something very close to SA_NODEFER, so it's compensation
in that sense.

> Indeed, the blocking is done in the same way, but probably the timing
> is  different - i.e. we unblock the signal only after
> unprotect_kernel_mem() in  the new code, which somehow *makes* a
> difference.

Maybe.  If unprotect_kernel_mem has anything to do with it, then it can
only affect jail mode in tt, which I'm planning on doing away with anyway
at some point.

> I'm going to choose the SA_NODEFER instead of adding the explicit
> check, at  least for 2.4. I'd do it for 2.6 too, only that I'm not too
> sure. 

My preference would be SA_NODEFER.  Do we know who was having problems that
were fixed by this?  Maybe we could see what exactly SA_NODEFER does there.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel