cacheline-aligned locks [was Re: RFC: gif(4) MP-ify]

Date: Wed, 6 Jan 2016 14:19:01 +0900 From: Kengo NAKAHARA I have a question for confirmation. If the struct has two locks for different purposes, is the COHERENCY_UNIT padding required between the locks isn't it? E.g. in my old patch(gif-mp-ify.patch), is the

Re: How to identify specific wait-state for a "DE" process?

Date: Wed, 6 Jan 2016 09:22:44 -0800 From: Brian Buhrow hello. Is there a particular reason file descriptors are closed in ascending order? Traditionally, file descriptors 2, 1 and 0 are always in use and it seems like it might be a good idea to have

Re: workqueue semantics [was Re: How to identify specific wait-state for a "DE" process?]

hello. Is there a particular reason file descriptors are closed in ascending order? Traditionally, file descriptors 2, 1 and 0 are always in use and it seems like it might be a good idea to have those be the last to get closed. I've seen some applications that close all their

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

In-kernel process exit hooks?

Please see references [1], [2], and [3] for details on this issue ... 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: How to identify specific wait-state for a "DE" process?

On Wed, 6 Jan 2016, David Holland wrote: On Wed, Jan 06, 2016 at 08:10:36AM +0800, Paul Goyette wrote: > Does anyone have any good suggestions for how to arrange for another > thread/lwp to run so it can remove the extra reference to the logging > descriptor? A better suggestion: remove the

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?

On Wed, 6 Jan 2016, Terry Moore wrote: You may well be right. From looking at the man page, fd_getfile() assumes the the file is already open. Is there an additional spec_write() after the fd_getfile()? I don't see it in you patch. spec_write() is called via the dereferencing at the end of

Re: cacheline-aligned locks [was Re: RFC: gif(4) MP-ify]

Hi, On 2016/01/07 0:26, Taylor R Campbell wrote: >Date: Wed, 6 Jan 2016 14:19:01 +0900 >From: Kengo NAKAHARA > >I have a question for confirmation. If the struct has two locks for >different purposes, is the COHERENCY_UNIT padding required between >the

RE: In-kernel process exit hooks?

I'm pretty sure that the mode check done at the beginning of spec_write() will ensure that the file is opened with write access. :) On Wed, 6 Jan 2016, Terry Moore wrote: Isn't there a security risk with the fd_getfile() approach? This sounds (on the face of it) similar to the kinds of

Device driver attachment when using module(7)

Hi all, I have one question about how device drivers are supposed to be configured when loaded as modules. I've noticed this is the most commonly used method of attachment throughout the kernel: ... switch (cmd) { case MODULE_CMD_INIT: #ifdef _MODULE error =

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

Re: How to identify specific wait-state for a "DE" process?

On Wed, Jan 06, 2016 at 08:10:36AM +0800, Paul Goyette wrote: > Does anyone have any good suggestions for how to arrange for another > thread/lwp to run so it can remove the extra reference to the logging > descriptor? A better suggestion: remove the broken behavior of close(). -- David A.