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

 
 

bug #15317: FS server crashs a subhurd

Submitter:  Samuel Thibault <sthibaul>
Submitted:  Thu 29 Dec 2005 08:54:25 PM UTC
   
 
Category:  Hurd Servers Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Need Info Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Reproducibility:  None
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

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: -email is 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: -email is 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>, -email is 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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2005-12-30 ams StatusNone Need Info

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code