New strategy of locking a process group
For now, p_mtx protects p_pgrp in struct proc. This is quite
troublesome for the following reason:
In some cases, we grab a p_pgrp via struct proc in order to, say,
access the session information of the process group. In other cases,
we traverse the members of a process group in order to, say, send a
signal to the process group. Those cases imply that it is likely to
end up with lock order reversal if we adopt p_mtx to protect a process
group.
The lock of process groups should hence not in a certain struct but
global. Although proc.h suggests locking by proctree_lock, it is
actually not a good candidate of the process group lock because the
hierarchy of processes does not affect the process group membership of
a process provided that security constraints satisfy.
I have thus introduced a new sx lock, pgrpsess_lock to protect data
regarding process groups, namely the following ones:
global:
pgrphashtbl
struct proc:
p_pglist, p_pgrp
struct pgrp:
pg_hash, pg_members, pg_session
pg_session is here for the case where we attempt to confirm whether
two processes or process groups belong to an identical session, eg:
if (p-p_session == curproc-p_session) {...}
The lock order of pgrpsess_lock is between proctree_lock and p_mtx for
now.
The major impact of pgrpsess_lock is that you must slock pgrpsess_lock
to call psignal() and issignal() (not only pgsignal()!) because both
of them may read the data of a process group.
We may also have to introduce something like pfind_lockpgrp(), which
locks pgrpsess_lock upon returning. This eliminates a sequence of
PROC_UNLOCK() - sx_slock(pgrpsess_lock) - PROC_LOCK() to avoid
unlocking a process.
Implementation of pgrpsess_lock is almost finished. The rest of the
work includes protection of the members in struct pgrp and session not
covered by pgrpsess_lock.
--
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
world broken
Latest CVS (about 30 minutes ago) In file included from /usr/src/sbin/vinum/v.c:57: /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory In file included from /usr/src/sbin/vinum/list.c:59: /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory In file included from /usr/src/sbin/vinum/../../sys/dev/vinum/vinumutil.c:44: /usr/src/sbin/vinum/../../sys/dev/vinum/vinumhdr.h:78: dev/vinum/vinumutil.h: No such file or directory In file included from /usr/src/sbin/vinum/commands.c:56: /usr/src/sbin/vinum/vext.h:77: dev/vinum/vinumutil.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sbin/vinum. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No Subject
Hey there, I found a great retail site with all kinds of products. Home decor, office decor, travel, outdoors, kitchen, etc... Take a look around at http://www.merchandisewholesale.com just click on the images of the product to enlarge it for a better view. Sincerely, John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: New strategy of locking a process group
On 22-May-01 Seigo Tanimura wrote: For now, p_mtx protects p_pgrp in struct proc. This is quite troublesome for the following reason: Err, it doesn't really. It's mostly undecided at this point. Also, have you looked at the BSD/OS code on builder? They have process groups and sessions already locked not using global locks but using per-data structure locks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 04:48:38 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John On 22-May-01 Seigo Tanimura wrote: For now, p_mtx protects p_pgrp in struct proc. This is quite troublesome for the following reason: John Err, it doesn't really. It's mostly undecided at this point. Also, have you John looked at the BSD/OS code on builder? They have process groups and sessions John already locked not using global locks but using per-data structure locks. If you do not protect both p_pgrp and p_pglist in struct proc by an identical lock, you end up with breaking either setpgid(2) or kill(2) for a process group. The following scenario depicts an example of the breakage: There is a process p that belongs to a process group G. A process q issues setpgid(2) to move p into a process group H, when the process p sends a signal to the process group to which p belongs by kill(2) with pid of zero. In this case, if p takes its new p_pgrp (which points to H) during which q attempts to remove p from G (this is possible if we lock p and G individually), p might fail to send the signal to p itself and the processes in H might receive a spurious signal. You might state that locking p_pgrp of p by p_mtx first and pg_members in G by pg_mtx (process group mutex) next should solve that problem. This method actually breaks kill(2) for a process group because our start point is now not a process but a process group. In this case, we should lock a process group first, followed by a process. The result is a lock order reversal and potential deadlock between setpgid(2) and kill(2). Of course, not all members of struct pgrp needs to be locked by a global lock. A lock per a process group is enough to protect pg_sigiolst and pg_jobc. Implementation of per-data structure locks is done for pgrp and in progress for session. Finally, a fact missing in my last mail. psignal() actually checks for the parent of a process, possibly sending SIGCHLD to it. This implies that we have to slock proctree_lock so that the process hierarchy does not change. Now that psignal() calls for both pgrpsess_lock and proctree_lock, it should be cheaper to have only proctree_lock than both of them. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: New strategy of locking a process group
On Tue, 22 May 2001 21:58:10 +0900, Seigo Tanimura tanimura said: Seigo On Tue, 22 May 2001 04:48:38 -0700 (PDT), Seigo John Baldwin [EMAIL PROTECTED] said: John On 22-May-01 Seigo Tanimura wrote: For now, p_mtx protects p_pgrp in struct proc. This is quite troublesome for the following reason: John Err, it doesn't really. It's mostly undecided at this point. Also, have you John looked at the BSD/OS code on builder? They have process groups and sessions John already locked not using global locks but using per-data structure locks. Seigo If you do not protect both p_pgrp and p_pglist in struct proc by an Seigo identical lock, you end up with breaking either setpgid(2) or kill(2) Seigo for a process group. The following scenario depicts an example of the Seigo breakage: BSD/OS seems to solve that problem by having p_session in struct proc, and protecting p_pgrp by the mutex of both a process and a session. Then you have to lock a session as well as a process prior to reading p_pgrp, as I locked proctree_lock. I chose proctree_lock because deleting a process group may call funsetown(), which calls free(9). Maybe we can reconsider protecting by a session lock when free(9) becomes not to lock lockmgr. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's causing troubles with pcm?
On Tue, May 22, 2001 at 04:13:47PM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: I know that -current is very fragile to say at least, but what's specifically causing it? Using simple for ((i=1;i=300;i++)); do sync; done does the trick, my system spends more than 50% in system, according to top. Vmstat shows ~300 page faults per second and about same for freed pages. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On 21 May 2001, Cyrille Lefevre wrote: Bruce Evans [EMAIL PROTECTED] writes: Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. some times ago, I've ported linux fdisk to native freebsd. if you really need it, I could make it a port ? I don't need it myself (I only ran it to see if it supported Linux extended partitions (it didn't, at least in it's list of known partition types)). This is for the old Linux fdisk with a dumb terminal interface which hadn't changed much (in 1997) since it was first implemented in 1991 or 1992. It doesn't have a good interface, but I rather like it since most of it was apparently copied from the one I implemented in Minix fdisk in 1988 or 1989 :-). Others might prefer a more graphical interface. Which version did you port? Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: New strategy of locking a process group
On 22-May-01 Seigo Tanimura wrote: On Tue, 22 May 2001 04:48:38 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John On 22-May-01 Seigo Tanimura wrote: For now, p_mtx protects p_pgrp in struct proc. This is quite troublesome for the following reason: John Err, it doesn't really. It's mostly undecided at this point. Also, have you John looked at the BSD/OS code on builder? They have process groups and sessions John already locked not using global locks but using per-data structure locks. If you do not protect both p_pgrp and p_pglist in struct proc by an identical lock, you end up with breaking either setpgid(2) or kill(2) for a process group. The following scenario depicts an example of the breakage: I'll have to look over the code in more detail, but I would encourage you to check the BSD/OS code. Finally, a fact missing in my last mail. psignal() actually checks for the parent of a process, possibly sending SIGCHLD to it. This implies that we have to slock proctree_lock so that the process hierarchy does not change. Now that psignal() calls for both pgrpsess_lock and proctree_lock, it should be cheaper to have only proctree_lock than both of them. Actually, psignal does _not_ use proctree_lock. p_pptr is locked by both p_mtx and the proctree lock (writes to it require both locks) so either lock is sufficient to read the value. As a result, psignal() simply acquires p_mtx and doesn't go near proctree. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken (vinum)
Hello Greg and others, Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it is not there in the cvsweb interface either. However, I can confirm that /usr/src/sys/dev/vinum/vinumhdr.h contains a reference to it. So? -- regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken (vinum)
Date: Tue, 22 May 2001 17:22:12 +0200 From: Szilveszter Adam [EMAIL PROTECTED] Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it is not there in the cvsweb interface either. However, I can confirm that /usr/src/sys/dev/vinum/vinumhdr.h contains a reference to it. Confirmed over here, as well. Recent CVSup history: CVSup begin from cvsup14.freebsd.org at Sun May 20 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun May 20 03:53:25 PDT 2001 CVSup begin from cvsup14.freebsd.org at Mon May 21 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Mon May 21 03:52:21 PDT 2001 CVSup begin from cvsup14.freebsd.org at Tue May 22 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 22 03:52:32 PDT 2001 Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Bruce Evans wrote: On 21 May 2001, Cyrille Lefevre wrote: [snip] I don't need it myself (I only ran it to see if it supported Linux extended partitions (it didn't, at least in it's list of known partition types)). This is for the old Linux fdisk with a dumb terminal interface which hadn't changed much (in 1997) since it was first implemented in 1991 or 1992. It doesn't have a good interface, but I rather like it since most of it was apparently copied from the one I implemented in Minix fdisk in 1988 or 1989 :-). Others might prefer a more graphical interface. Which version did you port? the ones from util-linux-2.10s.tar.gz (or .src.rpm?) cfdisk and fdisk seems to work good. for instance, sfdisk make a core! I did need it in the past, but in fact, I've done what I want w/ the bsd one. it was when I upgrade MaxBlast which is a software BIOS to see large drives. it changed the IDs of all (DOS?) primary and partitions to 0x55 and FreeBSD didn't like it at all. the problem is that ID didn't make a difference between primary (0xC) and extended (0xF) partitions... CC shortened. Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken
In answer to Greg's query What happens if you try building in sys/modules/vinum?: dhcp-133[3] pushd sys/modules/vinum/ /usr/src/sys/modules/vinum /usr/src dhcp-133[4] make Warning: Object directory not changed from original /usr/src/sys/modules/vinum @ - /usr/src/sys machine - /usr/src/sys/i386/include touch opt_vinum.h perl @/kern/vnode_if.pl -h @/kern/vnode_if.src cc -O -pipe -DVINUMDEBUG -g -O -D_KERNEL -Wall -Wredundant-decls -Wnested-exte rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu al -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/. ./include -I/usr/include -mpreferred-stack-boundary=2 -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -fformat-extensions -ansi -c /usr/src/sys/modules/vinum/../../de v/vinum/vinum.c In file included from /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:44: @/dev/vinum/vinumhdr.h:78: dev/vinum/vinumutil.h: No such file or directory *** Error code 1 Stop in /usr/src/sys/modules/vinum. dhcp-133[5] [The good news is that, although I wasn't yet willing to try building -CURRENT under X, I was able to get through the buildworld in multi- user mode OK.] Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new function for libdevstat
Sergey A. Osokin writes: I have rewritten devstat_compute_statistics(). Please see the attachment. Add ``break'' in each ``case''. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: HEADS UP: I broke swapping
On 20-May-01 Alfred Perlstein wrote: I broke swapping with the vm mutex. Hopefully I should have this fixed up within a couple of days tops. No, I'm not heading off to Aruba or someplace after this intrusive change, I am working on it. Your kernel may panic, but I hope you all keep a level head about this and don't follow suit. :) Patches, suggestions and crashdumps would be helpful. Bruce has been giving me some helpful tracebacks that I'm planning to use to stabilize the system. I am currently running X on my laptop with a current kernel with the patch http://www.FreeBSD.org/~jhb/patches/vm.patch. It is swapping, and I've tested out exhausting all the swap and mem at least which worked. swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/ad0s2b266112 16 266096 0%Interleaved vmstat -s 659683 cpu context switches 547856 device interrupts 5289 software interrupts 269300 traps 1492219 system calls 26 kernel threads created 710 fork() calls 59 vfork() calls 0 rfork() calls 15 swap pager pageins 17 swap pager pages paged in 524 swap pager pageouts 7923 swap pager pages paged out 803 vnode pager pageins 6173 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 253 page daemon wakeups ... vm.vm_faults_no_vm_mtx: 209859 vm.vm_faults_no_giant: 0 vm.stats.vm.v_vm_faults: 227165 The patch still needs some cleanups, and there are some lock order reversals I still need to work on, but it might be worth testing. :) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: HEADS UP: I broke swapping
On 22-May-01 John Baldwin wrote: On 20-May-01 Alfred Perlstein wrote: I broke swapping with the vm mutex. Hopefully I should have this fixed up within a couple of days tops. No, I'm not heading off to Aruba or someplace after this intrusive change, I am working on it. Your kernel may panic, but I hope you all keep a level head about this and don't follow suit. :) Patches, suggestions and crashdumps would be helpful. Bruce has been giving me some helpful tracebacks that I'm planning to use to stabilize the system. I am currently running X on my laptop with a current kernel with the patch http://www.FreeBSD.org/~jhb/patches/vm.patch. It is swapping, and I've tested out exhausting all the swap and mem at least which worked. Also, to clarify a point here and vindicate Alfred some since some people are calling for his head: Alfred didn't entirely break swapping, I helped. Revision 1.112 #if 0'd out code to lock the vm_map of a process when we were swapping it out. At the time I thought that we locked the map and immediately released the lock. However, we also bumped the refcount on the vmspace, but didn't call vmspace_free() until later after swapout(). I #if 0'd out the bump of the refcount, but not the vmspace_free(), thus when swapping out processes, we would release a vmspace out from under a process giving vmdaemon a heart attack later on. I think we still leak a vmspace refcount if we fail the swap_idle_threadhold2 test in swapout_procs(), and I'm going to test out a fix for that as well. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: HEADS UP: I broke swapping
On 22-May-01 John Baldwin wrote: On 20-May-01 Alfred Perlstein wrote: I broke swapping with the vm mutex. Hopefully I should have this fixed up within a couple of days tops. No, I'm not heading off to Aruba or someplace after this intrusive change, I am working on it. Your kernel may panic, but I hope you all keep a level head about this and don't follow suit. :) Patches, suggestions and crashdumps would be helpful. Bruce has been giving me some helpful tracebacks that I'm planning to use to stabilize the system. I am currently running X on my laptop with a current kernel with the patch http://www.FreeBSD.org/~jhb/patches/vm.patch. It is swapping, and I've tested out exhausting all the swap and mem at least which worked. Well, I've cleaned out all but one lock order reversal (the race between faultin() and swapout() needs to be fixed in a more proper fashion) and tried to push Giant back down some by re-enabling all the MPSAFE syscalls in Alfred's commit, but now I can deadlock (well, livelock actually) my laptop in single user via a simple memkill program that basically does this: for (;;) *(char *)malloc(1) = 1; If I have swap (i.e. I've run swapon on a swap partition) the program is killed by the system fine. If I don't have swap, then both the memkill process adn the swapper process (proc0) are stuck in the vmwait wait channel used by VM_WAIT. Any ideas? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: I broke swapping
John Baldwin wrote: If I have swap (i.e. I've run swapon on a swap partition) the program is kill ed by the system fine. If I don't have swap, then both the memkill process adn the swapper process (proc0) are stuck in the vmwait wait channel used by VM_WAIT. Any ideas? This may not be a new problem. I have seen a lot of machines hit this sort of thing at work. It can end up in the majority of processes on the system in this state. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: merge_inode_lists+0x86: movl %eax,0x10(%edx)
Just upgraded to latest sources, doesn't look like the swap issue ... was
performing a 'make -j16 buildworld' when it panic'd ...
Fataltrap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x11
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc020d646
stack pointer = 0x10:0xcce9ac04
frame pointer = 0x10:0xcce9ac0c
code segmnt = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 62131 (sh)
kernel: type 12 trap, code=0
Stopped at merge_inode_lists+0x86: movl%eax,0x10(%edx)
db trace
merge_inode_lists+0x86
softdep_setup_freeblocks+0x21c
ffs_truncate+0x1d0
ufs_inactive+0x9a
ufs_vnoperate+0x15
vrele+0x16e
ufs_close+0x198
ufs_vnoperate+0x15
vn_close+0x40
vn_closefile+0x23
fdrop+0xb9
closef+0x9b
fdfree+0x44
exit1+0x5eb
sys_exit+0x15
syscall+0x645
syscall_with_err_pushed+0x1b
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
