Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, Jul 07, 2001 at 06:54:53PM -0700, Mike Smith wrote: > Yelling at people won't solve the problem, nor will trying to hold the > project to ransom. These are things that you need to take into > consideration. You can take over Gcc and Binutils maintenance at any time. I doubt you or any k00l d00d kernel hak0rs will step away from kernel development. My attempts to find anyone that wants to help maintain these contrib bits (and have the skills) have turned up zilch. Sorry you feel I am holding the project to ransom. But dealing with a 3 month old cycle of breakages just isn't in the least bit fun or even mildly enjoyable. Of course you mentioned you gave your Alpha away, so I know you aren't even trying to run FreeBSD on multiple platforms. So maybe you should keep that in mind when seeing the frustration of those that do. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010713 07:00] wrote: > On Fri, 13 Jul 2001 19:49:25 +0900, > Seigo Tanimura said: > > Alfred> Certain operations, such as: > Alfred> kq = (struct kqueue *)fp->f_data; > Alfred> should not really require that the file be locked, it's implicitly frozen > Alfred> at creation time (i think) > > Seigo> Yes. > > Only one exception beats off everything. union_dircheck() in > fs/unionfs/union_subr.c may replace f_data with a new vnode. That code really scared me, but on careful inspection, the f_data is actually protected by the vnode exclusive lock from concurrant getdirentries() calls. (getdirentries() calls union_dircheck()) The code is still troublesome for mixing read() and getdirentries() at the same time, but since union mounts are rare we should leave it along and possibly revisit this later. My opinion is that you never need a lock for an assignment, unless that assignment spans multiple dependant operations or is dependant on some pre-condition, cases: /* no lock */ foo->a = 5; /* needs lock */ if (foo->b) foo->a = 5; /* might need lock to protect agianst inconsistant view */ foo->a = 5; foo->b = c; -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On 11-Jul-01 Seigo Tanimura wrote: > On Mon, 9 Jul 2001 03:20:44 -0500, > Alfred Perlstein <[EMAIL PROTECTED]> said: > > Alfred> I'm also quite sure that you can't call the ktrace functions with > Alfred> any mutexes held so the code is doing to need some help, basically > Alfred> the trick in trapsig() and postsig() is to generate the ktrace > Alfred> IO after the locks have been dropped, this means somehow caching > Alfred> the info sent to ktrace where it's currently called, and calling > Alfred> it later with the cached info after the locks are dropped. > > We can cache ktrace information into struct proc and mark the > existence of cache in p_traceflag. Then we send the information to > ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). Jake is working on porting the BSD/OS ktrace code, which uses a ring buffer of events that get handed off to a worker background thread that does the actual I/O. This way, ktrace won't sleep and you won't have these problems. I wouldn't expend lots of effort attempting to fix the current ktrace. > Another problem I noticed is bogus unlock and lock around call of > machine-and-maybe-executable-format-dependent sendsig(), found in > sys/*/*/machdep.c. Instead of locking curproc in sendsig() once again, > we should call sendsig() with curproc locked, and release the lock > only in sendsig(). That is probably fine. -- 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: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, 13 Jul 2001 19:49:25 +0900, Seigo Tanimura said: Alfred> Certain operations, such as: Alfred> kq = (struct kqueue *)fp->f_data; Alfred> should not really require that the file be locked, it's implicitly frozen Alfred> at creation time (i think) Seigo> Yes. Only one exception beats off everything. union_dircheck() in fs/unionfs/union_subr.c may replace f_data with a new vnode. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, 13 Jul 2001 04:25:04 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> This is just about completely file locking related, Alfred> however I do have a question about PGRP locking, in Alfred> a certain part you may have to lock two pgrps, how do you Alfred> deal with deadlock? Lock the session to which the pgrps belong first, then lock the pgrps. AFAIK, there are only two places to lock two pgrps, namely enterpgrp() and fixjobc() with an argument 'entering' set to nonzero. In both cases, either the pgrps belong to the same session or one of the pgrps belongs to a brand-new session with no other pgrps. Alfred> getvnode() Alfred> should FHOLD returned fp. Alfred> ibcs2_getdents(), ibcs2_statfs(), __acl_get_fd, __acl_set_fd, Alfred> __acl_aclcheck_fd(), __acl_delete_fd() Alfred> depends on getvnode doing FHOLD, once done needs fdrop() added Aaugh, I finished that work two hours ago :) Alfred> getvnode() Alfred> should actually be turned into "holdvnode" (implicit VREF) to do Alfred> reference holding. (later) Fine. Alfred> Certain operations, such as: Alfred> kq = (struct kqueue *)fp->f_data; Alfred> should not really require that the file be locked, it's implicitly frozen Alfred> at creation time (i think) Yes. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: > The patch and the results of build test are now on the web page. > > The discussion of ktrace(2) problem does not cover the solution of > BSD/OS, so it needs updating. Here's some more commentary and a pointer to some work done. This is just about completely file locking related, however I do have a question about PGRP locking, in a certain part you may have to lock two pgrps, how do you deal with deadlock? getvnode() should FHOLD returned fp. should actually be turned into "holdvnode" (implicit VREF) to do reference holding. (later) ibcs2_getdents(), ibcs2_statfs(), __acl_get_fd, __acl_set_fd, __acl_aclcheck_fd(), __acl_delete_fd() depends on getvnode doing FHOLD, once done needs fdrop() added Certain operations, such as: kq = (struct kqueue *)fp->f_data; should not really require that the file be locked, it's implicitly frozen at creation time (i think) Work is here, it's a diff relative to FreeBSD-current + your patch. http://sneakerz.org/~bright/pg_mine.diff thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 12 Jul 2001 01:44:44 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> * Alfred Perlstein <[EMAIL PROTECTED]> [010712 01:42] wrote: >> * Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: >> > >> > The patch and the results of build test are now on the web page. >> > >> > The discussion of ktrace(2) problem does not cover the solution of >> > BSD/OS, so it needs updating. >> >> I'm just reviewing the file stuff, I have a number of updates mainly >> in the areas of needing FFIND_HOLD/fdrop rather than just a simple >> FFIND. >> >> getvnode(p->p_fd, args->fd, &fp); >> >> I'm quite sure should implicitly do a FHOLD operation on the returned >> struct file, i don't see this, at least not in linux_getdents() >> (compat/linux/linux_file.c). Alfred> Or at least an fhold needs to be done before relasing the lock Alfred> on the struct file. Some functions modify a file descriptor, while others do not. At that point, what we need is a pair of FFIND and FFIND_LOCK. Both of them hold a file descriptor. FFIND_LOCK locks a file descriptor, while FFIND does not. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote:
>
> The patch and the results of build test are now on the web page.
>
> The discussion of ktrace(2) problem does not cover the solution of
> BSD/OS, so it needs updating.
Right now I'm only reviewing the file part and
I'm only up to 'sys/i386/ibcs2/ibcs2_misc.c' in the diff.
Here's a diff against your version and some comments so far:
svr4_sys_putmsg
svr4_sys_getmsg
should not use FFIND, needs FFIND_HOLD
fdesc_lookup
probably should FFIND_HOLD to make sure the file doesn't go away.
locking filedesc is probably not sufficient
ibcs2_ioctl
needs to be converted to FFIND_HOLD like linux's ioctl
Basically, I'm pretty sure you need to FFIND_HOLD a lot more
than you're doing in order to protect against shared file
descriptor tables getting corrupted.
diff --exclude=CVS -ur ./alpha/osf1/osf1_misc.c /usr/src/sys/alpha/osf1/osf1_misc.c
--- ./alpha/osf1/osf1_misc.cThu Jul 12 08:04:26 2001
+++ /usr/src/sys/alpha/osf1/osf1_misc.c Thu Jul 12 06:21:21 2001
@@ -670,11 +670,12 @@
struct osf1_stat oub;
int error;
- FFIND(fp, p, SCARG(uap, fd));
+ FFIND_HOLD(fp, p, uap->fd);
if (fp == NULL)
return (EBADF);
error = fo_stat(fp, &ub, p);
+ fdrop(fp, p);
cvtstat2osf1(&ub, &oub);
if (error == 0)
error = copyout((caddr_t)&oub, (caddr_t)SCARG(uap, sb),
diff --exclude=CVS -ur ./alpha/osf1/osf1_mount.c /usr/src/sys/alpha/osf1/osf1_mount.c
--- ./alpha/osf1/osf1_mount.c Thu Jul 12 08:04:26 2001
+++ /usr/src/sys/alpha/osf1/osf1_mount.cThu Jul 12 06:20:50 2001
@@ -154,7 +154,7 @@
struct statfs *sp;
struct osf1_statfs osfs;
- error = getvnode(p->p_fd, SCARG(uap, fd), &fp);
+ error = getvnode(p->p_fd, uap->fd, &fp);
if (error)
return (error);
mp = ((struct vnode *)fp->f_data)->v_mount;
diff --exclude=CVS -ur ./compat/linux/linux_file.c
/usr/src/sys/compat/linux/linux_file.c
--- ./compat/linux/linux_file.c Thu Jul 12 08:04:27 2001
+++ /usr/src/sys/compat/linux/linux_file.c Thu Jul 12 06:46:27 2001
@@ -139,11 +139,12 @@
SESS_LEADER(p) && !(p->p_flag & P_CONTROLT)) {
struct file *fp;
- FFIND(fp, p, p->p_retval[0]);
+ FFIND_HOLD(fp, p, p->p_retval[0]);
SESS_UNLOCK(p->p_session);
PROC_UNLOCK(p);
if (fp->f_type == DTYPE_VNODE)
fo_ioctl(fp, TIOCSCTTY, (caddr_t) 0, p);
+ fdrop(fp, p);
} else {
SESS_UNLOCK(p->p_session);
PROC_UNLOCK(p);
@@ -309,15 +310,19 @@
* significant effect for pipes (SIGIO is not delivered for
* pipes under Linux-2.2.35 at least).
*/
- FFIND(fp, p, args->fd);
+ FFIND_HOLD(fp, p, args->fd);
if (fp == NULL)
return EBADF;
- if (fp->f_type == DTYPE_PIPE)
+ if (fp->f_type == DTYPE_PIPE) {
+ fdrop(fp, p);
return EINVAL;
+ }
fcntl_args.cmd = F_SETOWN;
fcntl_args.arg = args->arg;
- return fcntl(p, &fcntl_args);
+ error = fcntl(p, &fcntl_args);
+ fdrop(fp, p);
+ return (error);
}
return EINVAL;
}
diff --exclude=CVS -ur ./compat/linux/linux_ioctl.c
/usr/src/sys/compat/linux/linux_ioctl.c
--- ./compat/linux/linux_ioctl.cThu Jul 12 08:04:27 2001
+++ /usr/src/sys/compat/linux/linux_ioctl.c Thu Jul 12 07:52:31 2001
@@ -1437,10 +1437,12 @@
printf(ARGS(ioctl, "%d, %04lx, *"), args->fd, args->cmd);
#endif
- FFIND_LOCK(fp, p, args->fd);
- if (fp == NULL || (fp->f_flag & (FREAD|FWRITE)) == 0) {
- if (fp != NULL)
- FILE_UNLOCK(fp);
+ FFIND_HOLD(fp, p, args->fd);
+ if (fp == NULL)
+ return (EBADF);
+ FILE_LOCK(fp);
+ if ((fp->f_flag & (FREAD|FWRITE)) == 0) {
+ FILE_UNLOCK(fp);
return (EBADF);
}
FILE_UNLOCK(fp);
@@ -1451,9 +1453,11 @@
if (cmd >= he->low && cmd <= he->high) {
error = (*he->func)(p, args);
if (error != ENOIOCTL)
+ fdrop(fp, p);
return (error);
}
}
+ fdrop(fp, p);
printf("linux: 'ioctl' fd=%d, cmd=0x%x ('%c',%d) not implemented\n",
args->fd, (int)(args->cmd & 0x),
diff --exclude=CVS -ur ./compat/linux/linux_stats.c
/usr/src/sys/compat/linux/linux_stats.c
--- ./compat/linux/linux_stats.cThu Jul 12 08:04:27 2001
+++ /usr/src/sys/compat/linux/linux_stats.c Thu Jul 12 06:12:11 2001
@@ -218,11 +218,12 @@
printf(ARGS(newfstat, "%d, *"), args->fd);
#endif
- FFIND(fp, p, args->fd);
+ FFIND_HOLD(fp, p, args->fd);
if (fp == NULL)
return (EBADF);
error = fo_stat(fp, &buf, p);
+ fdrop(fp, p);
if (!error)
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Alfred Perlstein <[EMAIL PROTECTED]> [010712 01:45] wrote: > * Alfred Perlstein <[EMAIL PROTECTED]> [010712 01:42] wrote: > > * Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: > > > > > > The patch and the results of build test are now on the web page. > > > > > > The discussion of ktrace(2) problem does not cover the solution of > > > BSD/OS, so it needs updating. > > > > I'm just reviewing the file stuff, I have a number of updates mainly > > in the areas of needing FFIND_HOLD/fdrop rather than just a simple > > FFIND. > > > > getvnode(p->p_fd, args->fd, &fp); > > > > I'm quite sure should implicitly do a FHOLD operation on the returned > > struct file, i don't see this, at least not in linux_getdents() > > (compat/linux/linux_file.c). > > Or at least an fhold needs to be done before relasing the lock > on the struct file. Furthermore, all the fo_* functions should not be calling FHOLD themselves, the fhold needs to have been done by whomever calls them to make sure that the 'fp' doesn't disapear out from under the fo_ function. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Alfred Perlstein <[EMAIL PROTECTED]> [010712 01:42] wrote: > * Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: > > > > The patch and the results of build test are now on the web page. > > > > The discussion of ktrace(2) problem does not cover the solution of > > BSD/OS, so it needs updating. > > I'm just reviewing the file stuff, I have a number of updates mainly > in the areas of needing FFIND_HOLD/fdrop rather than just a simple > FFIND. > > getvnode(p->p_fd, args->fd, &fp); > > I'm quite sure should implicitly do a FHOLD operation on the returned > struct file, i don't see this, at least not in linux_getdents() > (compat/linux/linux_file.c). Or at least an fhold needs to be done before relasing the lock on the struct file. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010711 19:08] wrote: > > The patch and the results of build test are now on the web page. > > The discussion of ktrace(2) problem does not cover the solution of > BSD/OS, so it needs updating. I'm just reviewing the file stuff, I have a number of updates mainly in the areas of needing FFIND_HOLD/fdrop rather than just a simple FFIND. getvnode(p->p_fd, args->fd, &fp); I'm quite sure should implicitly do a FHOLD operation on the returned struct file, i don't see this, at least not in linux_getdents() (compat/linux/linux_file.c). How can I present you a delta in a good way? -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Tue, 10 Jul 2001 18:03:40 +0900, Seigo Tanimura said: >>> >> I'm going to be giving this code some testing, not that you have to >>> >> wait for me to finish, but it seems like no one has stepped forward >>> >> to review this. I'd like to see it committed, so either go ahead >>> >> or wait for my review if it makes you more comfortable. >>> >> >>> >> Since I was working on the filedesc stuff I'll take a shot at reviewing >>> >> it, by way of the diff it looks somewhat ok, I just want to make sure >>> >> you're getting the fhold/fdrop stuff right. >>> Alfred> There's a merged diff here: >>> Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff >>> >>> It is rather hard for me to dig up what you merged out of that >>> patch. Could you please give me unmerged one? Alfred> What I did was try to merge the work you've done into the latest Alfred> -current, it didn't work out too well. Perhaps you can remerge Alfred> it and pass it to me for testing? Seigo> I have already begun merging -current an hour ago. It would take Seigo> another 3-4 hours to test builing kernels, so could you please be Seigo> patient until the latest one gets ready to go? The patch and the results of build test are now on the web page. The discussion of ktrace(2) problem does not cover the solution of BSD/OS, so it needs updating. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Wed, 11 Jul 2001 01:44:55 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> I'm also quite sure that you can't call the ktrace functions with Alfred> any mutexes held so the code is doing to need some help, basically Alfred> the trick in trapsig() and postsig() is to generate the ktrace Alfred> IO after the locks have been dropped, this means somehow caching Alfred> the info sent to ktrace where it's currently called, and calling Alfred> it later with the cached info after the locks are dropped. >> Seigo> We can cache ktrace information into struct proc and mark the Seigo> existence of cache in p_traceflag. Then we send the information to Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). >> >> msleep() and cv_*wait*() might receive a mutex held by curproc. As we >> cannot release the mutex to sleep in ktrwrite() during msleep() or >> cv_*wait*(), it is also necessary to cache information sent to >> ktrcsw(). >> >> Is it not feasible to examine the existence of cached ktrcsw() >> information upon every single call of msleep() and cv_*wait*() in >> order to flush the cached information. Instead of that, we should >> watch for release of mutexes. When a process no longer holds any >> mutexes except for Giant, it is safe to flush cached information to >> ktrace. Alfred> Yes, it's pretty gross. :( A problem of checking the cache upon release of a mutex is that we do not record the mutexes a process holds, which sounds expensive. BSD/OS solves that problem by a queue of ktrace data, which is what we refer to as cache, and by a helper kernel thread. A ktrace queue of BSD/OS, namely struct ktrace_control, is per vnode of a trace file, allocated dynamically. A record of trace data, also dynamically allocated, attaches to the queue of a trace file first. A kernel thread forked in ktrace(2) pulls records out of the queue, followed by writing them to the vnode of the trace file. The queue also holds free records of ktrace data so that a process holding mutexes can call ktrace_*(), The solution of BSD/OS looks promising in general. The only one issue I notice is that they do not allocate free records until the first call of ktrace_getxheader(). That would be fatal if a process holding mutexes records the first trace data for the queue. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010711 01:39] wrote: > On Wed, 11 Jul 2001 10:44:21 +0900, > Seigo Tanimura <[EMAIL PROTECTED]> said: > > Alfred> I'm also quite sure that you can't call the ktrace functions with > Alfred> any mutexes held so the code is doing to need some help, basically > Alfred> the trick in trapsig() and postsig() is to generate the ktrace > Alfred> IO after the locks have been dropped, this means somehow caching > Alfred> the info sent to ktrace where it's currently called, and calling > Alfred> it later with the cached info after the locks are dropped. > > Seigo> We can cache ktrace information into struct proc and mark the > Seigo> existence of cache in p_traceflag. Then we send the information to > Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). > > The problem has turned out to be even worse. > > msleep() and cv_*wait*() might receive a mutex held by curproc. As we > cannot release the mutex to sleep in ktrwrite() during msleep() or > cv_*wait*(), it is also necessary to cache information sent to > ktrcsw(). > > Is it not feasible to examine the existence of cached ktrcsw() > information upon every single call of msleep() and cv_*wait*() in > order to flush the cached information. Instead of that, we should > watch for release of mutexes. When a process no longer holds any > mutexes except for Giant, it is safe to flush cached information to > ktrace. Yes, it's pretty gross. :( -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Wed, 11 Jul 2001 10:44:21 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Alfred> I'm also quite sure that you can't call the ktrace functions with Alfred> any mutexes held so the code is doing to need some help, basically Alfred> the trick in trapsig() and postsig() is to generate the ktrace Alfred> IO after the locks have been dropped, this means somehow caching Alfred> the info sent to ktrace where it's currently called, and calling Alfred> it later with the cached info after the locks are dropped. Seigo> We can cache ktrace information into struct proc and mark the Seigo> existence of cache in p_traceflag. Then we send the information to Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). The problem has turned out to be even worse. msleep() and cv_*wait*() might receive a mutex held by curproc. As we cannot release the mutex to sleep in ktrwrite() during msleep() or cv_*wait*(), it is also necessary to cache information sent to ktrcsw(). Is it not feasible to examine the existence of cached ktrcsw() information upon every single call of msleep() and cv_*wait*() in order to flush the cached information. Instead of that, we should watch for release of mutexes. When a process no longer holds any mutexes except for Giant, it is safe to flush cached information to ktrace. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 9 Jul 2001 03:20:44 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> I'm also quite sure that you can't call the ktrace functions with Alfred> any mutexes held so the code is doing to need some help, basically Alfred> the trick in trapsig() and postsig() is to generate the ktrace Alfred> IO after the locks have been dropped, this means somehow caching Alfred> the info sent to ktrace where it's currently called, and calling Alfred> it later with the cached info after the locks are dropped. We can cache ktrace information into struct proc and mark the existence of cache in p_traceflag. Then we send the information to ktrace upon returning from trapsignal() or CURSIG(), or in sigexit(). Another problem I noticed is bogus unlock and lock around call of machine-and-maybe-executable-format-dependent sendsig(), found in sys/*/*/machdep.c. Instead of locking curproc in sendsig() once again, we should call sendsig() with curproc locked, and release the lock only in sendsig(). -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Tue, 10 Jul 2001 03:53:47 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: Alfred> * Seigo Tanimura <[EMAIL PROTECTED]> [010710 03:46] wrote: >> On Mon, 9 Jul 2001 03:20:44 -0500, >> Alfred Perlstein <[EMAIL PROTECTED]> said: >> >> >> I'm going to be giving this code some testing, not that you have to >> >> wait for me to finish, but it seems like no one has stepped forward >> >> to review this. I'd like to see it committed, so either go ahead >> >> or wait for my review if it makes you more comfortable. >> >> >> >> Since I was working on the filedesc stuff I'll take a shot at reviewing >> >> it, by way of the diff it looks somewhat ok, I just want to make sure >> >> you're getting the fhold/fdrop stuff right. >> Alfred> There's a merged diff here: >> Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff >> >> It is rather hard for me to dig up what you merged out of that >> patch. Could you please give me unmerged one? Alfred> What I did was try to merge the work you've done into the latest Alfred> -current, it didn't work out too well. Perhaps you can remerge Alfred> it and pass it to me for testing? I have already begun merging -current an hour ago. It would take another 3-4 hours to test builing kernels, so could you please be patient until the latest one gets ready to go? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010710 03:46] wrote: > On Mon, 9 Jul 2001 03:20:44 -0500, > Alfred Perlstein <[EMAIL PROTECTED]> said: > > >> I'm going to be giving this code some testing, not that you have to > >> wait for me to finish, but it seems like no one has stepped forward > >> to review this. I'd like to see it committed, so either go ahead > >> or wait for my review if it makes you more comfortable. > >> > >> Since I was working on the filedesc stuff I'll take a shot at reviewing > >> it, by way of the diff it looks somewhat ok, I just want to make sure > >> you're getting the fhold/fdrop stuff right. > > Alfred> There's a merged diff here: > > Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff > > It is rather hard for me to dig up what you merged out of that > patch. Could you please give me unmerged one? What I did was try to merge the work you've done into the latest -current, it didn't work out too well. Perhaps you can remerge it and pass it to me for testing? Basically, changes in -current conflict with your patch, I was unable to get a stable merge with your patches and -current. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 9 Jul 2001 03:20:44 -0500, Alfred Perlstein <[EMAIL PROTECTED]> said: >> I'm going to be giving this code some testing, not that you have to >> wait for me to finish, but it seems like no one has stepped forward >> to review this. I'd like to see it committed, so either go ahead >> or wait for my review if it makes you more comfortable. >> >> Since I was working on the filedesc stuff I'll take a shot at reviewing >> it, by way of the diff it looks somewhat ok, I just want to make sure >> you're getting the fhold/fdrop stuff right. Alfred> There's a merged diff here: Alfred> http://people.freebsd.org/~alfred/pg_fd2.diff It is rather hard for me to dig up what you merged out of that patch. Could you please give me unmerged one? Thanks. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Alfred Perlstein <[EMAIL PROTECTED]> [010707 16:43] wrote: > * Seigo Tanimura <[EMAIL PROTECTED]> [010702 03:13] wrote: > > On Mon, 18 Jun 2001 19:04:31 +0900, > > Seigo Tanimura said: > > > > Seigo> The results of build test with the latest patch are now at: > > > > Seigo> http://people.FreeBSD.org/~tanimura/pg_fd/ > > > > Seigo> As it is likely to take quite a while to fix alpha, I am going to > > Seigo> update the patch every few days. > > > > The latest test on alpha shows successful build of a kernel. Is alpha > > fixed and working now? > > I'm going to be giving this code some testing, not that you have to > wait for me to finish, but it seems like no one has stepped forward > to review this. I'd like to see it committed, so either go ahead > or wait for my review if it makes you more comfortable. > > Since I was working on the filedesc stuff I'll take a shot at reviewing > it, by way of the diff it looks somewhat ok, I just want to make sure > you're getting the fhold/fdrop stuff right. There's a merged diff here: http://people.freebsd.org/~alfred/pg_fd2.diff I'm not sure if kern_sig.c is merged properly. I'm also quite sure that you can't call the ktrace functions with any mutexes held so the code is doing to need some help, basically the trick in trapsig() and postsig() is to generate the ktrace IO after the locks have been dropped, this means somehow caching the info sent to ktrace where it's currently called, and calling it later with the cached info after the locks are dropped. Want to give this another spin? -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
> > David - this conversation is not productive, and you're not helping > > anyone, including yourself, going off like this. > > Care to address Alfred's going off also? Since it's your incessant carping that's the source of this shameful little flamwar, no. > > Please tone it down, ok? > > Fine, if you'd rather address me rather than the problem that the Alpha > isn't usable right now I have nothing to say on that issue. I do, however, consider your behaviour entirely unappropriate for this forum. Yelling at people won't solve the problem, nor will trying to hold the project to ransom. These are things that you need to take into consideration. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, Jul 07, 2001 at 06:44:45PM -0700, Mike Smith wrote: > > > Finally, if you're so damn concerned about your precious alpha I > > > expect you or at least ANYONE WHO CARES ABOUT ALPHA TO ASSIST IN > > > TESTING THESE DIFFS. > > > > HOW THE FSCK AM I TO TEST THEM WHEN I CANNOT EVEN GET TO SINGLE USER?? > > By testing them before they're committed, obviously. > > David - this conversation is not productive, and you're not helping > anyone, including yourself, going off like this. Care to address Alfred's going off also? > Please tone it down, ok? Fine, if you'd rather address me rather than the problem that the Alpha isn't usable right now (ask Andrew yourself since you take him as a voice of reason above myself). If I cannot get a usable Alpha this week, GCC 3.0 will not be in FreeBSD 5.0-RELEASE; plain and simple. Now people can either pitch in to help ensure a usable testing platform; or they can do with out a compiler upgrade. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
> > Finally, if you're so damn concerned about your precious alpha I > > expect you or at least ANYONE WHO CARES ABOUT ALPHA TO ASSIST IN > > TESTING THESE DIFFS. > > HOW THE FSCK AM I TO TEST THEM WHEN I CANNOT EVEN GET TO SINGLE USER?? By testing them before they're committed, obviously. David - this conversation is not productive, and you're not helping anyone, including yourself, going off like this. Please tone it down, ok? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, Jul 07, 2001 at 08:13:57PM -0500, Alfred Perlstein wrote: > I'm not interested in wasting time tracking down bugs for your > arch. *My* arch?? _OUR_ arches. > Anyhow, the simple fact is that if you're unable to cope with some > instability for a short amount of time you shouldn't be running > -current. You should be sticking to -stable. Short time?? The 5-CURRENT Alpha has been useless for going 3 months now. So I think I will take your advice. BTW, this means no GCC 3.0 for 5.0-RELEASE. Makes my life easier. THNX. > Finally, if you're so damn concerned about your precious alpha I > expect you or at least ANYONE WHO CARES ABOUT ALPHA TO ASSIST IN > TESTING THESE DIFFS. HOW THE FSCK AM I TO TEST THEM WHEN I CANNOT EVEN GET TO SINGLE USER?? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* David O'Brien <[EMAIL PROTECTED]> [010707 20:01] wrote: > On Sat, Jul 07, 2001 at 07:11:28PM -0500, Alfred Perlstein wrote: > > * David O'Brien <[EMAIL PROTECTED]> [010707 18:06] wrote: > > > On Sat, Jul 07, 2001 at 04:42:49PM -0500, Alfred Perlstein wrote: > > > > I'm going to be giving this code some testing, not that you have to > > > > wait for me to finish, but it seems like no one has stepped forward > > > > to review this. I'd like to see it committed, so either go ahead > > > > or wait for my review if it makes you more comfortable. > > > > > > Uh.. your "go ahead" attitude is what made the Alpha so damned unstable. > > > We don't need an encore from you. > > > > Piss off david, with everything under giant there's still problems. > > Go blame someone else. > > Ok, then honestly. Tell me what commit made it so unstable. It was very > stable right before your commit and hasn't been since. I am willing to > except that some commit after your exposed some dormant bug if you can > point out the commit. A stock kernel on June 28th couldn't even make it > to single user. I'm not interested in wasting time tracking down bugs for your arch. I agree that there were problems with the vm commit, but with everything back under Giant again, as well as the code recently backed out by Dillon, I really don't see how I could still be causing you any misery. Anyhow, the simple fact is that if you're unable to cope with some instability for a short amount of time you shouldn't be running -current. You should be sticking to -stable. There's a war going on between people trying to get new code into the base and those simplifying/tidying the code. I'm 100% sure it's not malicious, however the fact is that Seigo's patch is horribly broken now because of a lot of minor cleanups, if the massive amount of work he's done is tossed in the trash because he allows his work to get too out of date to ever make it into the base system it would be quite a loss. Finally, if you're so damn concerned about your precious alpha I expect you or at least ANYONE WHO CARES ABOUT ALPHA TO ASSIST IN TESTING THESE DIFFS. thank you very much, -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, Jul 07, 2001 at 07:11:28PM -0500, Alfred Perlstein wrote: > * David O'Brien <[EMAIL PROTECTED]> [010707 18:06] wrote: > > On Sat, Jul 07, 2001 at 04:42:49PM -0500, Alfred Perlstein wrote: > > > I'm going to be giving this code some testing, not that you have to > > > wait for me to finish, but it seems like no one has stepped forward > > > to review this. I'd like to see it committed, so either go ahead > > > or wait for my review if it makes you more comfortable. > > > > Uh.. your "go ahead" attitude is what made the Alpha so damned unstable. > > We don't need an encore from you. > > Piss off david, with everything under giant there's still problems. > Go blame someone else. Ok, then honestly. Tell me what commit made it so unstable. It was very stable right before your commit and hasn't been since. I am willing to except that some commit after your exposed some dormant bug if you can point out the commit. A stock kernel on June 28th couldn't even make it to single user. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* David O'Brien <[EMAIL PROTECTED]> [010707 18:06] wrote: > On Sat, Jul 07, 2001 at 04:42:49PM -0500, Alfred Perlstein wrote: > > I'm going to be giving this code some testing, not that you have to > > wait for me to finish, but it seems like no one has stepped forward > > to review this. I'd like to see it committed, so either go ahead > > or wait for my review if it makes you more comfortable. > > Uh.. your "go ahead" attitude is what made the Alpha so damned unstable. > We don't need an encore from you. Piss off david, with everything under giant there's still problems. Go blame someone else. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, Jul 07, 2001 at 04:42:49PM -0500, Alfred Perlstein wrote: > I'm going to be giving this code some testing, not that you have to > wait for me to finish, but it seems like no one has stepped forward > to review this. I'd like to see it committed, so either go ahead > or wait for my review if it makes you more comfortable. Uh.. your "go ahead" attitude is what made the Alpha so damned unstable. We don't need an encore from you. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
* Seigo Tanimura <[EMAIL PROTECTED]> [010702 03:13] wrote: > On Mon, 18 Jun 2001 19:04:31 +0900, > Seigo Tanimura said: > > Seigo> The results of build test with the latest patch are now at: > > Seigo> http://people.FreeBSD.org/~tanimura/pg_fd/ > > Seigo> As it is likely to take quite a while to fix alpha, I am going to > Seigo> update the patch every few days. > > The latest test on alpha shows successful build of a kernel. Is alpha > fixed and working now? I'm going to be giving this code some testing, not that you have to wait for me to finish, but it seems like no one has stepped forward to review this. I'd like to see it committed, so either go ahead or wait for my review if it makes you more comfortable. Since I was working on the filedesc stuff I'll take a shot at reviewing it, by way of the diff it looks somewhat ok, I just want to make sure you're getting the fhold/fdrop stuff right. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 18 Jun 2001 19:04:31 +0900, Seigo Tanimura said: Seigo> The results of build test with the latest patch are now at: Seigo> http://people.FreeBSD.org/~tanimura/pg_fd/ Seigo> As it is likely to take quite a while to fix alpha, I am going to Seigo> update the patch every few days. The latest test on alpha shows successful build of a kernel. Is alpha fixed and working now? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, 04 Jun 2001 16:48:30 +0900, Seigo Tanimura said: David> It would also be nice to get a timeline on the commit schedule for this. >>> Test of 2 weeks should be enough, followed by commit in 15 June. David> I request that this be on hold until we actually get -current Alphas David> usable again. Seigo> OK, then we can test on pc98 and ia64 to wait for that. The results of build test with the latest patch are now at: http://people.FreeBSD.org/~tanimura/pg_fd/ As it is likely to take quite a while to fix alpha, I am going to update the patch every few days. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 16:31:21 +0900, Seigo Tanimura said: Seigo> Lock of struct filedesc, file, pgrp, session and sigio is now ready Seigo> for testing. Although the patch is still under test, a new task proposal comes to my mind. A new task: lock underlying objects of struct file, namely a vnode, a socket, a pipe, a fifo and an event queue. A socket and a pipe is not mpsafe for now. A vnode (and a fifo) has an interlock, so it might already be mpsafe. An event queue is... up to jlemon? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Mon, Jun 04, 2001 at 04:48:30PM +0900, Seigo Tanimura wrote: > >> Test of 2 weeks should be enough, followed by commit in 15 June. > > David> I request that this be on hold until we actually get -current Alphas > David> usable again. > > OK, then we can test on pc98 and ia64 to wait for that. > > Now what do I have to do to test on ia64? JHB is aware of your patch, so he can either pre-test it on ia64; or since we don't run on HW and you really don't have a chance to mess up users just don't worry about that platform for now. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Sat, 2 Jun 2001 12:52:23 -0700, "David O'Brien" <[EMAIL PROTECTED]> said: David> On Fri, Jun 01, 2001 at 09:28:57PM +0900, Seigo Tanimura wrote: David> It would also be nice to get a timeline on the commit schedule for this. >> Test of 2 weeks should be enough, followed by commit in 15 June. David> I request that this be on hold until we actually get -current Alphas David> usable again. OK, then we can test on pc98 and ia64 to wait for that. Now what do I have to do to test on ia64? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, Jun 01, 2001 at 09:28:57PM +0900, Seigo Tanimura wrote: > David> It would also be nice to get a timeline on the commit schedule for this. > Test of 2 weeks should be enough, followed by commit in 15 June. I request that this be on hold until we actually get -current Alphas usable again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, 1 Jun 2001 05:44:17 -0700, Kris Kennaway <[EMAIL PROTECTED]> said: David> Committers do not need Alpha users to verify that a patch compiles, David> Beast.freebsd.org can be used for that. Testing on a running system is David> of course a different matter. >> >> I will test building a GENERIC kernel with COMPAT_OSF1 after I get >> home, in a couple of hours. Kris> I think you misunderstand; David was referring to testing compilation Kris> on the alpha platform. beast.freebsd.org is available for FreeBSD Kris> committers for this purpose. I meant that I cannot start testing *right now* because I have to go back from my lab to my home in a few minutes, during which I will be offline. The test is going to be on beast, of course. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Fri, Jun 01, 2001 at 09:28:57PM +0900, Seigo Tanimura wrote: > David> Committers do not need Alpha users to verify that a patch compiles, > David> Beast.freebsd.org can be used for that. Testing on a running system is > David> of course a different matter. > > I will test building a GENERIC kernel with COMPAT_OSF1 after I get > home, in a couple of hours. I think you misunderstand; David was referring to testing compilation on the alpha platform. beast.freebsd.org is available for FreeBSD committers for this purpose. Kris PGP signature
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 13:01:56 -0700, "David O'Brien" <[EMAIL PROTECTED]> said: David> On Thu, May 31, 2001 at 12:54:26PM -0700, John Baldwin wrote: >> >> Lock of struct filedesc, file, pgrp, session and sigio is now ready >> >> for testing. >> >> >> >> The patch is at >> >> >> >> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz >> > >> > Compiled on Alpha? >> >> I think that's what he means by "testing". :) I.e., he's ready for >> people to compile it and report problems, etc. David> Committers do not need Alpha users to verify that a patch compiles, David> Beast.freebsd.org can be used for that. Testing on a running system is David> of course a different matter. I will test building a GENERIC kernel with COMPAT_OSF1 after I get home, in a couple of hours. David> It would also be nice to get a timeline on the commit schedule for this. Test of 2 weeks should be enough, followed by commit in 15 June. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 01:46:00PM -0700, John Baldwin wrote: > It doesn't hurt to help distribute the load some, though. Requiring > each person who makes a change to compile it on every possible arch is > not something that will scale as more and more archs are added. If a > committer can get someone else to perform some of these test compiles > and fix any brokenness that > comes up I think that is adequate. Forgot to add, if others use the Alpha owners as simple test-compile resources, (1) the Alpha owners will not get any other work done, (2) will get quite tired of testing things that the patch author could easily test himself. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 01:46:00PM -0700, John Baldwin wrote: > It doesn't hurt to help distribute the load some, though. Requiring > each person who makes a change to compile it on every possible arch is > not something that will scale as more and more archs are added. It isn't that hard to put the bits on Freefall and test on all arches. Especially for a _KERNEL_ patch that touches this many files -- some Alpha specific. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On 31-May-01 David O'Brien wrote: > On Thu, May 31, 2001 at 12:54:26PM -0700, John Baldwin wrote: >> >> Lock of struct filedesc, file, pgrp, session and sigio is now ready >> >> for testing. >> >> >> >> The patch is at >> >> >> >> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz >> > >> > Compiled on Alpha? >> >> I think that's what he means by "testing". :) I.e., he's ready for >> people to compile it and report problems, etc. > > Committers do not need Alpha users to verify that a patch compiles, > Beast.freebsd.org can be used for that. Testing on a running system is > of course a different matter. It doesn't hurt to help distribute the load some, though. Requiring each person who makes a change to compile it on every possible arch is not something that will scale as more and more archs are added. If a committer can get someone else to perform some of these test compiles and fix any brokenness that comes up I think that is adequate. -- 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: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 12:54:26PM -0700, John Baldwin wrote: > >> Lock of struct filedesc, file, pgrp, session and sigio is now ready > >> for testing. > >> > >> The patch is at > >> > >> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz > > > > Compiled on Alpha? > > I think that's what he means by "testing". :) I.e., he's ready for > people to compile it and report problems, etc. Committers do not need Alpha users to verify that a patch compiles, Beast.freebsd.org can be used for that. Testing on a running system is of course a different matter. It would also be nice to get a timeline on the commit schedule for this. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On 31-May-01 David O'Brien wrote: > On Thu, May 31, 2001 at 04:31:21PM +0900, Seigo Tanimura wrote: >> Lock of struct filedesc, file, pgrp, session and sigio is now ready >> for testing. >> >> The patch is at >> >> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz > > Compiled on Alpha? I think that's what he means by "testing". :) I.e., he's ready for people to compile it and report problems, etc. -- 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: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 04:31:21PM +0900, Seigo Tanimura wrote: > Lock of struct filedesc, file, pgrp, session and sigio is now ready > for testing. > > The patch is at > > http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Compiled on Alpha? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 16:31:21 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said: Seigo> Lock of struct filedesc, file, pgrp, session and sigio is now ready Seigo> for testing. Seigo> The patch is at Seigo> http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz WARNING: rebuild any modules that provide filesystems if you are using them. getpid(2) should now be *really* mpsafe. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock of struct filedesc, file, pgrp, session and sigio
Lock of struct filedesc, file, pgrp, session and sigio is now ready for testing. The patch is at http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Below is the brief description of locking. 1. struct filedesc and struct file - fd_mtx protects struct filedesc. - f_mtx protects struct file. Refer to sys/file.h for detail. - Do not look up a file descriptor table directly but use FFIND* macros defined in sys/filedesc.h. They handle locking a file descriptor table and a file descriptor. - getvnode() locks a file descriptor. - p_fd may change during the life of a process if it is sharing its file descriptor table when the process calls execve(2). As nobody except curproc and the parent process in fork1() touches the file descriptor table of a process, the lock type of p_fd should be "(a) only touched by curproc or parent during fork/wait." 2. struct proc, struct pgrp and struct session - pgrphash_lock and pg_mtx protects struct pgrp. Refer to sys/proc.h for detail. - s_mtx protects struct session. Refer to sys/proc.h for detail. - Introduce p_pgrpmtx to protect p_pgrp of struct proc in cooperation with p_mtx. This allows locking of a process in a process group without lock order reversal. The lock order of them is shown below. 1st: p_pgrpmtx 2st: pg_mtx 3rd: p_mtx - You may lock more than one process groups provided that they belong to an identical session and you lock the session in advance. - psignal() requires the lock of the process group to which a destination process belongs if the property of a signal includes SA_STOP. PROC_LOCK_PSIGNAL() and PROC_UNLOCK_PSIGNAL() handle those lock and unlock. TODO: Pass a signal to PROC_(UN)LOCK_PSIGNAL() to avoid unnecessary lock. - pgsignal() requires the lock of a destination process group. 3. struct sigio - struct sigio forms a list(struct sigiolst), residing in a process or a process group. p_mtx of a process or pg_mtx of a process group is responsible to lock struct sigiolst. The members of struct sigio other than sio_pgsigio never change. - A macro FUNSETOWN locks the list of struct sigio, calls funsetown() and unlocks the list. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
