bugThe GNU Hurd - Bugs: bug #15317, FS server crashs a subhurd

 
 

bug #15317: FS server crashs a subhurd

Submitted by:  Samuel Thibault <sthibaul>
Submitted on:  Thu 29 Dec 2005 08:54:25 PM UTC  
 
Category: Hurd ServersSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: Need InfoPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: OpenReproducibility: None
Size (loc): NonePlanned Release: None
Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 30 Dec 2005 06:13:02 PM UTC, comment #1:

Can this still be reproduced? If so, a explanation on why it happens is needed to satifsy the hunger of the Gods.

Alfred M. Szmidt <ams>
Thu 29 Dec 2005 08:54:25 PM UTC, original submission:

From http://bugs.debian.org/110015

From: Moritz Schulte <moritz@chaosdorf.de>
To: -unavailable-
Subject: FS server crashs a subhurd
Date: 25 Aug 2001 16:42:51 +0200

Package: Hurd
Version: N/A
Severity: important

Hi,
i can simply crash my subhurd by doing:

for i in $(seq 4); do
settrans -afg /foo /hurd/ext2fs /dev/bar
done

Here's a log:

--------------------------------
eris2:~# for i in $(seq 4); do settrans -afg foo /hurd/ext2fs /dev/hd0s6; done
ext2fs: /dev/hd0s6: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEASE fsck
ext2fs: /dev/hd0s6: warning: MOUNTED READ-ONLY; MUST USE `fsysopts --writable'
ext2fs: /dev/hd0s6: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEASE fsck
ext2fs: /dev/hd0s6: warning: MOUNTED READ-ONLY; MUST USE `fsysopts --writable'
/hurd/init: Crashing system; essential task kernel diederis2:~#
init: notifying ext2fs /dev/hd0s6 of shutdown...done
init: notifying ext2fs /dev/hd0s6 of shutdown...(no longer present)
init: notifying pfinet of shutdown...done
init: notifying ext2fs.static hd0s5 of shutdown...done
init: Killing pid 40
[...]
init: Killing pid 115
/hurd/init: Getting procinfo for pid 117: No such process
/hurd/init: Getting task for pid 118: No such process
init: Killing pid 119
init: Killing pid 129
init: Killing pid 135
init: Killing proc server
init: Exitinginit: Would reboot Mach with flags 0
bye
--------------------------------

I'll try to debug that.

moritz

From: Moritz Schulte <moritz@chaosdorf.de>
To: -unavailable-
Subject: Re: Bug #110015: FS server crashs a subhurd
Date: 25 Aug 2001 19:21:14 +0200

Hi again,

the following change in init/init.c works:

--- init.c.orig Sat Aug 25 19:12:13 2001
+++ init.c Sat Aug 25 19:12:26 2001
@@ -1182,7 +1182,8 @@ S_startup_essential_task (mach_port_t se
startup_essential_task_reply (reply, replytype, 0);

init_stdarrays ();
- frob_kernel_process ();
+ if (! fakeboot)
+ frob_kernel_process ();

launch_system ();

But i don't know wether that's the right fix. The problem is that
frob_kernel_process() tries to register the kernel task (pid 2) as an
essential task:

err = proc_pid2task (procserver, 2, &task);
if (err)
{
error (0, err, "cannot get kernel task port");
return;
}
err = proc_task2proc (procserver, task, &proc);
if (err)
{
error (0, err, "cannot get kernel task's proc server port");
mach_port_deallocate (mach_task_self (), task);
return;
}

/* Mark the kernel task as an essential task so that we never
want to task_terminate it. */
err = record_essential_task ("kernel", task);
assert_perror (err);

This doesn't work right in a subhurd.

Btw, I find the mixture of parent-Hurd-processes and
child-Hurd-processes quite confusing. Is it difficult to modify proc
so that you can not see the processes from parent Hurds? IMHO, this
would be better.

moritz

From: Roland McGrath <roland@gnu.org>
To: Moritz Schulte <moritz@chaosdorf.de>, -unavailable-
Subject: Re: Bug #110015: FS server crashs a subhurd
Date: Sat, 25 Aug 2001 18:19:13 -0400 (EDT)

Hmm. So what is PID 2 in your sub-hurd, if it's not the kernel? It's true
that a sub-hurd should probably not diddle the kernel task as the boot hurd
does--but I don't know a reason it shouldn't work. I am still confused as
to how this crash happened.

> Btw, I find the mixture of parent-Hurd-processes and child-Hurd-processes
> quite confusing. Is it difficult to modify proc so that you can not see
> the processes from parent Hurds? IMHO, this would be better.


Just use ps options to ignore unregistered tasks when you are looking.

At some point we might want to make `boot' give a fake host-priv port and
then do things like report a subset of tasks to the sub-hurd.

Samuel Thibault <sthibaul>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follows 1 latest change.

Date Changed By Updated Field Previous Value => Replaced By
Fri 30 Dec 2005 06:20:28 PM UTCamsStatusNone=>Need Info

Back to the top


Powered by Savane 3.1-cleanup