Re: pci arbiter being killed

Joan Lledó, le sam. 17 avril 2021 12:12:45 +0200, a ecrit: > Hi, > > El 7/3/21 a les 20:33, Samuel Thibault ha escrit: > > You could e.g. put mach_prints in glibc's sysdeps/mach/hurd/kill.c's > > SIGKILL case. > > > > Possibly better also add a mach_print in hurd/hurdsig.c SIGKILL on > > _hurd_or

Re: [PATCH 3/4] proc: Follow p_parent to root for checking startup process

Damien Zammit, le sam. 17 avril 2021 21:02:15 +1000, a ecrit: > On 17/4/21 7:40 pm, Samuel Thibault wrote: > > Damien Zammit, le sam. 17 avril 2021 19:12:11 +1000, a ecrit: > >> Since the bootstrap filesystem is no longer a single process, > >> but can be spread among eg, pci-arbiter and rumpdisk,

Re: [PATCH 3/4] proc: Follow p_parent to root for checking startup process

Hi, On 17/4/21 7:40 pm, Samuel Thibault wrote: > Damien Zammit, le sam. 17 avril 2021 19:12:11 +1000, a ecrit: >> Since the bootstrap filesystem is no longer a single process, >> but can be spread among eg, pci-arbiter and rumpdisk, we cannot >> just check the p_parent of the process > > ? Aren't

Re: pci arbiter being killed

Hi, On 17/4/21 8:12 pm, Joan Lledó wrote: > I spent too much time on this and still haven't found the problem, need > some help. I suspect the problem is in the kernel b/c it's the part I'm > less competent. I'm attaching a patch with the changes I made on the > memory object proxy logic. Could

Re: pci arbiter being killed

Hi, El 7/3/21 a les 20:33, Samuel Thibault ha escrit: You could e.g. put mach_prints in glibc's sysdeps/mach/hurd/kill.c's SIGKILL case. Possibly better also add a mach_print in hurd/hurdsig.c SIGKILL on _hurd_orphaned. I tried but I saw nothing, is it supposed to show the messages in the c

Re: [PATCH 3/4] proc: Follow p_parent to root for checking startup process

Damien Zammit, le sam. 17 avril 2021 19:12:11 +1000, a ecrit: > Since the bootstrap filesystem is no longer a single process, > but can be spread among eg, pci-arbiter and rumpdisk, we cannot > just check the p_parent of the process ? Aren't all of pci-arbiter, rumpdisk, ext2fs, proc, auth all chi

Re: [PATCH 2/4] libmachdev: Add proc_set_arg_locations

Damien Zammit, le sam. 17 avril 2021 19:12:10 +1000, a ecrit: > index bbd73555..05dc7279 100644 > --- a/libmachdev/trivfs_server.c > +++ b/libmachdev/trivfs_server.c > @@ -332,6 +332,8 @@ trivfs_S_fsys_init (struct trivfs_control *fsys, >assert_perror_backtrace (err); >err = proc_set_exe (p

Re: [PATCH 1/4] startup: Mark all essential tasks as our children

Damien Zammit, le sam. 17 avril 2021 19:12:09 +1000, a ecrit: > + err = proc_getallpids (procserver, &pp, &npids); That looks lame, don't we already have the list through record_essential_task? > + /* ignore startup, proc, auth and kernel */ > + if (task != mach_task_self () > +

[PATCH 2/4] libmachdev: Add proc_set_arg_locations

--- libmachdev/trivfs_server.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libmachdev/trivfs_server.c b/libmachdev/trivfs_server.c index bbd73555..05dc7279 100644 --- a/libmachdev/trivfs_server.c +++ b/libmachdev/trivfs_server.c @@ -332,6 +332,8 @@ trivfs_S_fsys_init (struct trivfs_contr

[PATCH x4: hurd] - Almost fixing the rumpdisk stat issue

Hi, [PATCH 1/4] startup: Mark all essential tasks as our children This patch loops through the processes and determines which ones are important, and then marks them as child processes of startup. [PATCH 2/4] libmachdev: Add proc_set_arg_locations I'm not sure if this patch is needed. [PATCH 3/4

[PATCH 4/4] procfs: Add debug for failing EIO

--- procfs/process.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/procfs/process.c b/procfs/process.c index 6e4c1515..61e7cde4 100644 --- a/procfs/process.c +++ b/procfs/process.c @@ -387,9 +387,12 @@ process_file_get_contents (void *hook, char **contents, ssize_t *c

[PATCH 1/4] startup: Mark all essential tasks as our children

--- startup/startup.c | 49 +++ 1 file changed, 49 insertions(+) diff --git a/startup/startup.c b/startup/startup.c index 9faeb462..4278954a 100644 --- a/startup/startup.c +++ b/startup/startup.c @@ -831,6 +831,52 @@ main (int argc, char **argv, char **

[PATCH 3/4] proc: Follow p_parent to root for checking startup process

Since the bootstrap filesystem is no longer a single process, but can be spread among eg, pci-arbiter and rumpdisk, we cannot just check the p_parent of the process but need to follow to the root of the process namespace to check if it belongs to startup. --- proc/mgt.c | 12 +++- 1 file c