Re: In-kernel process exit hooks?

Let me rephrase - this is the only explanation I'm going to provide: _I_ am not going to remove it. If others feel so strongly that they would rather remove existing functionality (as ugly as it is), then _they_ can do the deed. On Sat, 9 Jan 2016, Wolfgang Solfrank wrote: Hi, We all

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: > On Thu, Jan 07, 2016 at 07:34:33AM +0800, Paul Goyette wrote: > > Based on internal implementation of filemon(4), there is an ordering > > requirement imposed on the sequence of events that occur when a process > > using

Re: In-kernel process exit hooks?

On Sat, Jan 09, 2016 at 08:25:05AM +0100, Mateusz Guzik wrote: > On Sat, Jan 09, 2016 at 02:25:02PM +0800, Paul Goyette wrote: > > On Sat, 9 Jan 2016, Mateusz Guzik wrote: > > > > >While I don't know all the details, it is clear that the purpose would > > >be much better served by ktrace and I

Re: In-kernel process exit hooks?

On Sat, Jan 09, 2016 at 02:25:02PM +0800, Paul Goyette wrote: > On Sat, 9 Jan 2016, Mateusz Guzik wrote: > > >While I don't know all the details, it is clear that the purpose would > >be much better served by ktrace and I would argue efforts should be > >spent there. > > filemon's purpose is

Re: In-kernel process exit hooks?

Hi, We all agree that filemon(4) is an ugly hack. It probably should never have gotten committed. But it is there now, and there are a (very) few use-cases. So we don't want to remove it without having a replacement implementation. Well, can you explain? Why would we not want to remove it

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Paul Goyette wrote: Hmmm, option #3 doesn't work so well, after all! I tried it when both the target and monitor processes were children of the same shell process. Thus all three of these share the same 'struct file' for their stdout, and the filemon_fd_close() callback

Re: In-kernel process exit hooks?

On 1/7/16, David Holland wrote: > On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: > > For an example of the right way to do this kind of thing, look in > > kern_acct.c. > > Better example: sys_fktrace, since that uses a file handle. And it > does

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, bch wrote: On 1/7/16, David Holland wrote: On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: > For an example of the right way to do this kind of thing, look in > kern_acct.c. Better example: sys_fktrace, since that uses a file

Re: In-kernel process exit hooks?

On 1/8/16, Paul Goyette wrote: > On Fri, 8 Jan 2016, bch wrote: > >> On 1/7/16, David Holland wrote: >>> On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: >>> > For an example of the right way to do this kind of thing, look in >>> >

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 12:52:16PM +0700, Robert Elz wrote: > Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) > From:Paul Goyette > Message-ID: > > | Is there a "supported" interface for

Re: In-kernel process exit hooks?

On 1/8/16, Taylor R Campbell wrote: >Date: Fri, 8 Jan 2016 17:13:54 +0800 (PHT) >From: Paul Goyette > >On Fri, 8 Jan 2016, bch wrote: > >> Out of curiousity, I'm trying to use this interface, but getting: >> >>

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Taylor R Campbell wrote: Date: Fri, 8 Jan 2016 16:52:28 +0800 (PHT) From: Paul Goyette Robert Elz wrote: > That is, instead of a fd_getfile() without an (almost immediate) > fd_putfile() so keeping ff_refcount incremented, in filemon, just do

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Taylor R Campbell wrote: > Next, I'm going to have a look at fd_getfile2()/fclose() and see if that > is a viable approach. Hmmm. The comments in kern/kern_descrip.c for fd_getfile2() require that the process is not allowed to fork or exit "across this call"

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 10:47:08AM -0600, David Young wrote: > On Fri, Jan 08, 2016 at 12:52:16PM +0700, Robert Elz wrote: > > Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) > > From:Paul Goyette > > Message-ID:

Re: In-kernel process exit hooks?

On Sat, 9 Jan 2016, Mateusz Guzik wrote: While I don't know all the details, it is clear that the purpose would be much better served by ktrace and I would argue efforts should be spent there. filemon's purpose is somewhat different than that of ktrace. There is a limited set of events that

Re: In-kernel process exit hooks?

I'm not going to address individual points We all agree that filemon(4) is an ugly hack. It probably should never have gotten committed. But it is there now, and there are a (very) few use-cases. So we don't want to remove it without having a replacement implementation. (Although some of

Re: In-kernel process exit hooks?

On Sat, Jan 09, 2016 at 08:25:05AM +0100, Mateusz Guzik wrote: > >if (!mutex_tryenter(parent->p_lock)) { > >mutex_exit(t->p_lock); > >mutex_enter(parent->p_lock); > > As a side note this looks like a bug. t->p_lock

Re: In-kernel process exit hooks?

So I reiterate my suggestion to use fd_getfile2: fd = *((int *)data); if ((filemon->fm_fp = fd_getfile2(curproc, fd)) == NULL) { error = EBADF; break; } Ack - let me test and confirm that it works. Yes, it works just fine. Revised

Re: In-kernel process exit hooks?

Date: Fri, 8 Jan 2016 16:52:28 +0800 (PHT) From: Paul Goyette Robert Elz wrote: > That is, instead of a fd_getfile() without an (almost immediate) > fd_putfile() so keeping ff_refcount incremented, in filemon, just do > >fp = fd_getfile(...); >

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 12:26:14PM +0700, Robert Elz wrote: > Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) > From:Paul Goyette > Message-ID: > > | Is there a "supported" interface for

Re: In-kernel process exit hooks?

Date: Fri, 8 Jan 2016 17:13:54 +0800 (PHT) From: Paul Goyette On Fri, 8 Jan 2016, bch wrote: > Out of curiousity, I'm trying to use this interface, but getting: > > /usr/include/sys/ktrace.h:83:20: error: field '_ts' has incomplete type >struct

Re: In-kernel process exit hooks?

Date: Fri, 8 Jan 2016 09:00:03 +0800 (PHT) From: Paul Goyette On Fri, 8 Jan 2016, Paul Goyette wrote: > The saga continues! :) > > > > Next, I'm going to have a look at fd_getfile2()/fclose() and see if that > is a viable approach. Hmmm. The

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Paul Goyette wrote: The saga continues! :) Next, I'm going to have a look at fd_getfile2()/fclose() and see if that is a viable approach. Hmmm. The comments in kern/kern_descrip.c for fd_getfile2() require that the process is not allowed to fork or exit "across this

Re: In-kernel process exit hooks?

The saga continues! :) I previously posted one set of patches that changes filemon to use fd_{get,put}file() only when the activity-log file is actually being accessed. This works, but doesn't prevent or detect when the application program closes-and-reopens that fd. Attached to this

RE: In-kernel process exit hooks?

pbell <campbell+netbsd-tech-k...@mumble.net> > Cc: tech-kern@netbsd.org > Subject: Re: In-kernel process exit hooks? > > On Fri, 8 Jan 2016, Paul Goyette wrote: > > > The saga continues! :) > > > > > > > > Next, I'm going to have a look

Re: In-kernel process exit hooks?

Date:Fri, 8 Jan 2016 09:00:03 +0800 (PHT) From:Paul Goyette Message-ID: | Any other suggestions would be appreciated. Another possibility would be to detach the logged-to file from the

Re: In-kernel process exit hooks?

On Fri, 8 Jan 2016, Robert Elz wrote: Another possibility would be to detach the logged-to file from the process when logging is enabled (making the ioctl that attaches it also be notionally a close from the process point of view). But keeping the reference in kernel. When logging is

Re: In-kernel process exit hooks?

OK, I now have a third way of handling the problem. To recap the three options (refer to the attachments) 1. fd_getfile This option calls fd_getfile() each time it needs to access the activity log, and calls fd_putfile() after each use. This way, the additional reference on the file

Re: In-kernel process exit hooks?

On 1/7/16, Paul Goyette wrote: > On Fri, 8 Jan 2016, Paul Goyette wrote: > >> The saga continues! :) >> >> >> >> Next, I'm going to have a look at fd_getfile2()/fclose() and see if that >> is a viable approach. > > Hmmm. The comments in kern/kern_descrip.c for fd_getfile2()

RE: In-kernel process exit hooks?

On Thu, 7 Jan 2016, Terry Moore wrote: Will the hang occur if make dies due to a signal (control-C, or kill -9, for example)? It depends on which fd is numerically lower. If the /dev/filemon fd is lower, it will get closed first, which removes the reference to the log-file fd. If the

Re: In-kernel process exit hooks?

On Thu, Jan 07, 2016 at 07:34:33AM +0800, Paul Goyette wrote: > Based on internal implementation of filemon(4), there is an ordering > requirement imposed on the sequence of events that occur when a process > using /dev/filemon exits. In particular, the file descriptor on which the > device

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 11:22:28AM +0800, Paul Goyette wrote: > Yeah, I was trying to avoid the change in semantics. :) The fewer things > I touch, the fewer things will go wrong, and I definitely don't want to > break make, which would result in difficulties making[sic] a new version. > :)

Re: In-kernel process exit hooks?

Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) From:Paul Goyette Message-ID: | Is there a "supported" interface for detaching the file (or descriptor) | from the process without closing it?

Re: In-kernel process exit hooks?

Date:Fri, 8 Jan 2016 11:22:28 +0800 (PHT) From:Paul Goyette Message-ID: | Is there a "supported" interface for detaching the file (or descriptor) | from the process without closing it?

Re: In-kernel process exit hooks?

Hmmm, option #3 doesn't work so well, after all! I tried it when both the target and monitor processes were children of the same shell process. Thus all three of these share the same 'struct file' for their stdout, and the filemon_fd_close() callback cannot tell which one is being closed.

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: > For an example of the right way to do this kind of thing, look in > kern_acct.c. Better example: sys_fktrace, since that uses a file handle. And it does virtually the same thing that filemon's trying to do, except much more

Re: In-kernel process exit hooks?

On Thu, 7 Jan 2016, Taylor R Campbell wrote: > Another possibility would be to change filemon(4) to do fd_getfile > each it needs to use the file descriptor. This makes it a little more > brittle (fails if you close the descriptor), but would sidestep the > problem. Hmmm, perhaps.

Re: In-kernel process exit hooks?

On Wed, 6 Jan 2016, Taylor R Campbell wrote: Another possibility would be to change filemon(4) to do fd_getfile each it needs to use the file descriptor. This makes it a little more brittle (fails if you close the descriptor), but would sidestep the problem. Hmmm, perhaps. Failure would not

Re: In-kernel process exit hooks?

> Another possibility would be to change filemon(4) to do fd_getfile > each it needs to use the file descriptor. This makes it a little > more brittle (fails if you close the descriptor), but would sidestep > the problem. Hmmm, perhaps. Failure would not be a problem, since we would just

RE: In-kernel process exit hooks?

ern-ow...@netbsd.org] On Behalf Of Paul Goyette Sent: Wednesday, January 6, 2016 16:55 To: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> Cc: tech-kern@netbsd.org Subject: Re: In-kernel process exit hooks? Another possibility would be to change filemon(4) to do fd_getfile each it

RE: In-kernel process exit hooks?

Of Paul Goyette Sent: Wednesday, January 6, 2016 16:55 To: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> Cc: tech-kern@netbsd.org Subject: Re: In-kernel process exit hooks? Another possibility would be to change filemon(4) to do fd_getfile each it needs to use the file desc

Re: In-kernel process exit hooks?

Another possibility would be to change filemon(4) to do fd_getfile each it needs to use the file descriptor. This makes it a little more brittle (fails if you close the descriptor), but would sidestep the problem. Another possibility would be to use fd_getfile2/closef, which holds a reference