Re: kqueue: SIGIO?
On Wed, Sep 30, 2015 at 11:28:35PM +0700, Robert Elz wrote: > It also fits with the only safe thing that's really possible to do in a > single handler being to set a variable and return (or exit the process) > (ie: the main loop has to check a variable anyway, whether signal delivery > is traditional, or via Mouse's suggested mechanism). > > The issue with it is how one would ever safely clear the variable again, > while avoiding race conditions - An atomic read-modify-write cycle; other than vintage cpus have these in hardware. Anyhow, infiniband had to come up with some scheme for this; borrowing that rather than reinventing it (or not borrowing it if it sucks, instead of reinventing it by accident) seems like a good starting point. -- David A. Holland dholl...@netbsd.org
Re: Killing a zombie process?
On Fri, 2 Oct 2015, Paul Goyette wrote: Still trying to track this down A modified version of ps(1) shows that the process state is clearly LSZOMB and not LSDEAD. Furthermore, "ps -s" doesn't show any LWP for the zombie process, so it would seem that process clean up has progressed relatively far. I was able to use "ps axl -O paddr" to get the address of the process's struct proc, but I don't seem to be able to examine it with gdb. # ps axl -O paddr | grep Z UID PIDPADDR PPID CPU PRI NI VSZRSS WCHAN STAT TTY TIME COMMAND 1000 25032 fe810f45ea40 2214 0 43 02240 48 - R+ pts/1 0:00.00 grep Z 0 21120 fe81f578ba70 1 0 0 0 0 0 - Z pts/2 0:00.00 (sh) # gdb /dev/mem GNU gdb (GDB) 7.9.1 ... This GDB was configured as "x86_64--netbsd". ... (gdb) symbol-file /netbsd.gdb Reading symbols from /netbsd.gdb...done. (gdb) print (struct proc *) 0xfe81f578ba70 warning: value truncated $1 = (struct proc *) 0xfe81f578ba70 (gdb) Any clue on how to properly access kernel memory here, without having the address truncated to 32-bits? TIA For now, I took a quick look into the zombie's struct proc. p_exitsig = 0x14 = SIGCHILD p_flag= 0x0 p_sflag = 0x2000 = PS_WEXIT p_slflag = 0x0 p_lflag = 0x2= PL_CONTROLT p_stflag = 0x0 p_stat= 0x5= SZOMB p_trace_enabled = 0x0 p_pid = 0x5280 = 21120 (the same value shown by ps) I don't see anything unusual here. I have attached the hex-dump in case anyone wants to look a little bit closer. +--+--+-+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--+-+fe81f578ba70: 0 0 806be7000 0 fbb7a840fe81 fe81f578ba90: 801 0 0 0 0 0 f578baa0fe81 fe81f578bab0: 804d542e0 0 f578bab8fe81804e7f9a fe81f578bad0: ef0106c0fe81f46f680 fe810 0 e00b5700fe81 fe81f578baf0: 55fe8de8fe8180722de0 3be9b258fe800 0 fe81f578bb10: 0 7f7f0 0 fff014 0 fe81f578bb30: 20000 2 0 f683000552800 0 fe81f578bb50: eab655b0fe81f45ecd0 fe81 1de352a0fe82fc805108fe81 fe81f578bb70: 0 0 21ccb560fe800 0 1 1 fe81f578bb90: 0 0 0 1 0 0 0 0 fe81f578bbb0: 0 0 0 0 0 900045b20 fe81f578bbd0: 0 0 0 0 0 0 0 0 fe81f578bbf0: 0 0 0 0 0 0 0 0 fe81f578bc10: 0 0 e6023190fe81 806b63000 0 fe81f578bc30: 808be0e00 0 0 0 0 0 fe81f578bc50: f578bc48fe810 0 0 0 0 0 fe81f578bc70: 1 0 0 0 0 0 0 0 fe81f578bc90: 0 0 0 0 fe81f578bcb0: 687314 656b0 0 0 0 eab655b0fe81 fe81f578bcd0: ffe07f7f0 1 0 7f7f8012f010 fe81f578bcf0: 0 7f80f683b8e67f7f deaddeadfe810 0 fe81f578bd10: f578b558fe8124bf9400fe80 fff00 0 fe81f578bd30: 0 0 f578bd30fe81 8049abd40 0 fe81f578bd50: f578bd48fe818049abd4 e50db0c0fe81f79e380 fe81 fe81f578bd70: 0 0 f48a4c48fe81 8072312080722de0 fe81f578bd90: 213f4228fe810 0 0 7f7f0 0 fe81f578bdb0:
Re: Killing a zombie process?
Still trying to track this down A modified version of ps(1) shows that the process state is clearly LSZOMB and not LSDEAD. Furthermore, "ps -s" doesn't show any LWP for the zombie process, so it would seem that process clean up has progressed relatively far. I was able to use "ps axl -O paddr" to get the address of the process's struct proc, but I don't seem to be able to examine it with gdb. # ps axl -O paddr | grep Z UID PIDPADDR PPID CPU PRI NI VSZRSS WCHAN STAT TTY TIME COMMAND 1000 25032 fe810f45ea40 2214 0 43 02240 48 - R+ pts/1 0:00.00 grep Z 0 21120 fe81f578ba70 1 0 0 0 0 0 - Z pts/2 0:00.00 (sh) # gdb /dev/mem GNU gdb (GDB) 7.9.1 ... This GDB was configured as "x86_64--netbsd". ... (gdb) symbol-file /netbsd.gdb Reading symbols from /netbsd.gdb...done. (gdb) print (struct proc *) 0xfe81f578ba70 warning: value truncated $1 = (struct proc *) 0xfe81f578ba70 (gdb) Any clue on how to properly access kernel memory here, without having the address truncated to 32-bits? TIA +--+--+-+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--+-+
