Re: ps acting weird?
> > On Tue, 20 Jan 2009, Danny Braniss wrote: > > > I just stumbled on this, ps(1) gives different info if the user is root or > > a > > simple mortal: > > > > simple-mortal> ps p8130 > > PID TT STAT TIME COMMAND > > 8130 ?? Is 0:05.72 [java] > > > > root# ps p8130 > > > > PID TT STAT TIME COMMAND > > 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... > > > > was this always like this? > > btw, this is on 7.1-stable > > This happens when command lines are really long -- the kernel caches certain > command line data when it's short (i.e., under a couple of hundred > characters), but when it's long the only way to get it is to attach to the > process's address space using debugging interfaces and read it from there. > This requires ps(1) to have debugging rights for the target process, which > will not always be true for simple mortal users, but will often be true for > root. > > You can set the kern.ps_arg_cache_limit sysctl to increase the limit, which > will take effect when the command line is next changed (typically, when the > program is run again, but there are some programs that update their command > lines to show status information, in which case it will be when they next > update). This shows up particularly for Java command lines, which are often > long. > > I would be careful not to tune it up too high as it will use up kernel > memory/address space, but setting it to, say, 4k or 8k on modern systems > shouldn't really be a problem, especially since most commands don't have long > command lines. The problem this limit addresses is what happens when maxproc > processes all set maximally-sized command lines. I.e., if your maxproc is > 6,000, then fully filling the command line cache gives you 1.5MB of command > line in kernel address space and memory - a lot, but very little compared to > making the limit 4000 bytes, in which case it's more around 24MB. > > Robert N M Watson > Computer Laboratory > University of Cambridge > thanks Robert, it is always educational to read your answers! i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 would have been enough (excluding those pathological cases of 'command *') btw, this tomcat/java command line was 312 (why not use a config file!). which brings on another issue: ps -o command= -p 777 /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] while ps -o comm= -p 777 java thanks, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ps acting weird?
On Wed, 21 Jan 2009, Danny Braniss wrote: thanks Robert, it is always educational to read your answers! i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 would have been enough (excluding those pathological cases of 'command *') btw, this tomcat/java command line was 312 (why not use a config file!). which brings on another issue: ps -o command= -p 777 /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] while ps -o comm= -p 777 java ps distinguishes "comm", which is the binary name as stored in the process structure's p_comm field, and the command line, which is p_args. From the ps(1) man page: KEYWORDS The following is a complete list of the available keywords and their meanings. Several of them have aliases (keywords which are synonyms). ... comm command commandcommand and arguments Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
device driver: cdesw questions?
Question 1: I am writing a driver that would use per-open private data (among other features). Do I have to use D_TRACKCLOSE flag in this case? In general I am a little bit confused about when d_close is invoked. Supposing D_TRACKCLOSE is not set and multiple programs concurrently open, use and close a device - when d_close is called - when one program closes its last descriptor tied to the device or when the system-wide last such descriptor is closed? Question 2: I also would like the driver to provide a select capability quite similar to that of network (e.g. TCP) sockets using d_poll. I.e. a userland program should be able to query when it can write data to the device without blocking and when it can read data without blocking, plus when an error occurred in the device/driver, so there is no point in further waiting. At this moment I am thoroughly confused by meaning of various event masks described in poll(2). E.g. what is normal priority, non-zero priority and high priority. Which flags should I care about if all data is the same priority for me? Which flag(s) should I set when I'd like to communicate an error condition (e.g. similar to TCP connection reset)? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ps acting weird?
> On Wed, 21 Jan 2009, Danny Braniss wrote: > > > thanks Robert, it is always educational to read your answers! > > > > i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 > > would have been enough (excluding those pathological cases of 'command *') > > btw, this tomcat/java command line was 312 (why not use a config file!). > > > > which brings on another issue: > > > > ps -o command= -p 777 > > /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] > > while > > ps -o comm= -p 777 > > java > > ps distinguishes "comm", which is the binary name as stored in the process > structure's p_comm field, and the command line, which is p_args. From the > ps(1) man page: > > KEYWORDS > The following is a complete list of the available keywords and their > meanings. Several of them have aliases (keywords which are synonyms). > ... > comm command > commandcommand and arguments hehe, i read the manual :-), hence my question, the only difference, from the manual, is that command is comm and arguments, which now you explained that it's not so. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
Question 3: is it ok to use M_WAITOK in pci attach routine? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
On Wednesday 21 January 2009, Andriy Gapon wrote: > Question 3: > is it ok to use M_WAITOK in pci attach routine? Yes. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Kernel Module - GCC Requires memmove
Hi,
I'm doing the unusual task of converting some c++ code into a FreeBSD
kernel module. Now all has been going great, and thus far I've been
able to debug quite a bit of it using printfs. However, I decided to
start using a kernel debugger, and to make this easier I passed g++
the –O0 flag, to make it compile without optimisations.
Bang, I hit a problem. All of a sudden when using the –O0 my module
wouldn't load because it was missing an undefined reference to
memmove. I found the specific object file which was using memmove. I
did that by doing objdump –t *.o and finding which file had an
undefined symbol memmove. Once I found the object file I grepped the
associated source and I was sure I was not using memmove. I then got
gcc to output both the post-processed source, as well as the asm.
The .ii file (post-processed source) did NOT mention memmove at all.
So I found it very odd that an undefined symbol existed in the object
file. So then I looked in the .s file (asm), and it was clearing
making a single call to memmove.
So after a few hours of pulling my hair out I found this in the gcc manual:
"-nostdlib The compiler may generate calls to memcmp, memset,
memcpy and memmove. These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified."
So it appears that gcc may add calls to those four functions even if
you don't use them yourself? I assume this has not been a problem for
anyone yet due to only crazy people trying to use c++ in the kernel,
and the specific set of gcc options I'm using.
For the moment I have fixed this problem now by defining my own memmove like so:
extern "C" void * memmove(void * dst, const void * src, size_t len) {
bcopy(src, dst, len);
return dst;
}
But I was wondering if those four functions should be defined in the
kernel? I notice that memcpy and memset are already defined by the
kernel somewhere, so perhaps memmove and memcmp should join them?
Oh I should mention this was happening with the default gcc under FreeBSD 7.1.
Thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > > Question 1: > I am writing a driver that would use per-open private data (among other > features). > Do I have to use D_TRACKCLOSE flag in this case? No, the dtr registered with devfs_set_cdevpriv(), is called exactly once when the last close is performed, or the device is destroyed. > In general I am a little bit confused about when d_close is invoked. > Supposing D_TRACKCLOSE is not set and multiple programs concurrently > open, use and close a device - when d_close is called - when one program > closes its last descriptor tied to the device or when the system-wide > last such descriptor is closed? D_TRACKCLOSE (attempt to) tracks _file_ close, not filedescriptor close. This actually becomes quite messed up when revoke(2) or forced unmounts of the devfs mount points are mixed in. > > Question 2: > I also would like the driver to provide a select capability quite > similar to that of network (e.g. TCP) sockets using d_poll. I.e. a > userland program should be able to query when it can write data to the > device without blocking and when it can read data without blocking, plus > when an error occurred in the device/driver, so there is no point in > further waiting. > At this moment I am thoroughly confused by meaning of various event > masks described in poll(2). E.g. what is normal priority, non-zero > priority and high priority. poll(2) comes from the Streams, where the messages in the queues do have priorities. See getmsgp(2) on Solaris for the start. Most likely, you do not need any priorities except POLLXXNORM, and FreeBSD uses POLLRDBAND for OOB TCP data only. > Which flags should I care about if all data is the same priority for me? > Which flag(s) should I set when I'd like to communicate an error > condition (e.g. similar to TCP connection reset)? I believe, it is a POLLHUP. See the sys_pipe.c, pipe_poll() for the rather clean example of the poll handler. pgpZkr8CYh23H.pgp Description: PGP signature
Re: device driver: cdesw questions?
on 21/01/2009 15:35 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >> Question 1: >> I am writing a driver that would use per-open private data (among other >> features). >> Do I have to use D_TRACKCLOSE flag in this case? > No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > when the last close is performed, or the device is destroyed. Kostik, thanks a lot for the explanation! I am still a little bit confused about the term "last close" - what is it? I.e. I'd like to get an answer to the below question. >> In general I am a little bit confused about when d_close is invoked. >> Supposing D_TRACKCLOSE is not set and multiple programs concurrently >> open, use and close a device - when d_close is called - when one program >> closes its last descriptor tied to the device or when the system-wide >> last such descriptor is closed? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KLD: program.ko: depends of kernel - no avaiable
On Tue, 20 Jan 2009, M. Warner Losh wrote: In message: "Jacky Oh" writes: : Hi, : : I'm writing a syscall module and he compiles well but at load time, kldload : shows: : : KLD: program.ko: depends of kernel - no avaiable : : anyone know something about this? Yes. rebuild the kernel and modules to have the same __FreeBSD_version It would be nice if the kernel linker included version numbers, both expected and found, in these messages. Unfortunately, this code is rather well-abstracted, and the specific version numbers are rather inaccessible at the point where the error message is printed. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: > on 21/01/2009 15:35 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > >> Question 1: > >> I am writing a driver that would use per-open private data (among other > >> features). > >> Do I have to use D_TRACKCLOSE flag in this case? > > No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > > when the last close is performed, or the device is destroyed. > > Kostik, > > thanks a lot for the explanation! > I am still a little bit confused about the term "last close" - what is > it? I.e. I'd like to get an answer to the below question. > > >> In general I am a little bit confused about when d_close is invoked. > >> Supposing D_TRACKCLOSE is not set and multiple programs concurrently > >> open, use and close a device - when d_close is called - when one program > >> closes its last descriptor tied to the device or when the system-wide > >> last such descriptor is closed? The kernel data structures for the opened device are as follows: filedesc ---> struct file ---> vnode ---> cdev [cdevpriv] \ / ->- Each -> arrow represents a "many to one" relation. There may be zero or one cdevpriv datum associated with struct file. cdev maintains the si_usecount, that is an accumulation of the vref counters for all devfs vnodes that are attached to the cdev. devfs_close() vop is called when the struct file is released. When D_TRACKCLOSE is specified, d_close driver method will be called unconditionally. When D_TRACKCLOSE is not specified, d_close is called when si_usecount is exactly 1, to become zero after the last close of the file that opened a vnode referencing cdev. Also, d_close() is called if the vnode is being reclaimed. Possible causes are revoke(2) call or forced devfs mp unmount. This interferes with close counting. cdevpriv dtr is called when either struct file is released, or device is destroyed by the destroy_dev(). pgpvdwwElIPrj.pgp Description: PGP signature
Re: device driver: cdesw questions?
On Wed, 21 Jan 2009, Andriy Gapon wrote: Question 1: I am writing a driver that would use per-open private data (among other features). Do I have to use D_TRACKCLOSE flag in this case? In general I am a little bit confused about when d_close is invoked. Supposing D_TRACKCLOSE is not set and multiple programs concurrently open, use and close a device - when d_close is called - when one program closes its last descriptor tied to the device or when the system-wide last such descriptor is closed? Kostik has already pointed at the cdevpriv API, but just to reiterate his point: most people will find the semantics of D_TRACKCLOSE confusing and consider them incorrect, so I would advise against using them. I also would like the driver to provide a select capability quite similar to that of network (e.g. TCP) sockets using d_poll. I.e. a userland program should be able to query when it can write data to the device without blocking and when it can read data without blocking, plus when an error occurred in the device/driver, so there is no point in further waiting. At this moment I am thoroughly confused by meaning of various event masks described in poll(2). E.g. what is normal priority, non-zero priority and high priority. Which flags should I care about if all data is the same priority for me? Which flag(s) should I set when I'd like to communicate an error condition (e.g. similar to TCP connection reset)? I find that the description of the polling flags is at best confusing in both man pages and specifications. The best bet is to look at the existing TCP semantics, which are basically defined in sopoll_generic(): if (events & (POLLIN | POLLRDNORM)) if (soreadable(so)) revents |= events & (POLLIN | POLLRDNORM); if (events & POLLINIGNEOF) if (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || !TAILQ_EMPTY(&so->so_comp) || so->so_error) revents |= POLLINIGNEOF; if (events & (POLLOUT | POLLWRNORM)) if (sowriteable(so)) revents |= events & (POLLOUT | POLLWRNORM); if (events & (POLLPRI | POLLRDBAND)) if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) revents |= events & (POLLPRI | POLLRDBAND); A few observations: - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all protocols use sopoll_generic in practice). This is surprising given the wording in the poll(2) man page. - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference between soreadable() and the test in POLLIGNEOF is that POLLIN also considers SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but POLLIGNEOF doesn't. I think Kostik's pointer to the pipe_poll() code is a good one, but if you're looking to emulate TCP semantics a bit more exactly, these differences should be taken into account. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
on 21/01/2009 15:55 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: >> on 21/01/2009 15:35 Kostik Belousov said the following: >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: Question 1: I am writing a driver that would use per-open private data (among other features). Do I have to use D_TRACKCLOSE flag in this case? >>> No, the dtr registered with devfs_set_cdevpriv(), is called exactly once >>> when the last close is performed, or the device is destroyed. >> Kostik, >> >> thanks a lot for the explanation! >> I am still a little bit confused about the term "last close" - what is >> it? I.e. I'd like to get an answer to the below question. >> In general I am a little bit confused about when d_close is invoked. Supposing D_TRACKCLOSE is not set and multiple programs concurrently open, use and close a device - when d_close is called - when one program closes its last descriptor tied to the device or when the system-wide last such descriptor is closed? > > The kernel data structures for the opened device are as follows: > > filedesc ---> struct file ---> vnode ---> cdev > [cdevpriv] \ / > ->- > > Each -> arrow represents a "many to one" relation. There may be zero > or one cdevpriv datum associated with struct file. > > cdev maintains the si_usecount, that is an accumulation of the vref > counters for all devfs vnodes that are attached to the cdev. > devfs_close() vop is called when the struct file is released. > When D_TRACKCLOSE is specified, d_close driver method will be > called unconditionally. > When D_TRACKCLOSE is not specified, d_close is called when si_usecount > is exactly 1, to become zero after the last close of the file that > opened a vnode referencing cdev. > Also, d_close() is called if the vnode is being reclaimed. Possible > causes are revoke(2) call or forced devfs mp unmount. This interferes > with close counting. > > cdevpriv dtr is called when either struct file is released, or > device is destroyed by the destroy_dev(). Kostik, is the following true: if D_TRACKCLOSE is specified then a number of d_close() calls and a number of cdevpriv dtr calls are equal (provide each file gets cdevpriv data) ? If not, what is the case where one is called but not the other? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > >> Question 1: I am writing a driver that would use per-open private data >> (among other features). Do I have to use D_TRACKCLOSE flag in this >> case? In general I am a little bit confused about when d_close is >> invoked. Supposing D_TRACKCLOSE is not set and multiple programs >> concurrently open, use and close a device - when d_close is called - >> when one program closes its last descriptor tied to the device or when >> the system-wide last such descriptor is closed? > > Kostik has already pointed at the cdevpriv API, but just to reiterate > his point: most people will find the semantics of D_TRACKCLOSE confusing > and consider them incorrect, so I would advise against using them. Robert, Kostik, in simplistic layman's terms I need the following - when a particular program "closes my cdev" (explicitly or via exit) I need to catch that and de-allocate certain resources. There can be multiple concurrent programs opening, using and closing my cdev. I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead I should perform the resource management in cdevpriv destructor. Am I guessing correctly this time? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: device driver: cdesw questions?
On Wed, Jan 21, 2009 at 04:07:54PM +0200, Andriy Gapon wrote: > on 21/01/2009 15:55 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: > >> on 21/01/2009 15:35 Kostik Belousov said the following: > >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > Question 1: > I am writing a driver that would use per-open private data (among other > features). > Do I have to use D_TRACKCLOSE flag in this case? > >>> No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > >>> when the last close is performed, or the device is destroyed. > >> Kostik, > >> > >> thanks a lot for the explanation! > >> I am still a little bit confused about the term "last close" - what is > >> it? I.e. I'd like to get an answer to the below question. > >> > In general I am a little bit confused about when d_close is invoked. > Supposing D_TRACKCLOSE is not set and multiple programs concurrently > open, use and close a device - when d_close is called - when one program > closes its last descriptor tied to the device or when the system-wide > last such descriptor is closed? > > > > The kernel data structures for the opened device are as follows: > > > > filedesc ---> struct file ---> vnode ---> cdev > > [cdevpriv] \ / > > ->- > > > > Each -> arrow represents a "many to one" relation. There may be zero > > or one cdevpriv datum associated with struct file. > > > > cdev maintains the si_usecount, that is an accumulation of the vref > > counters for all devfs vnodes that are attached to the cdev. > > devfs_close() vop is called when the struct file is released. > > When D_TRACKCLOSE is specified, d_close driver method will be > > called unconditionally. > > When D_TRACKCLOSE is not specified, d_close is called when si_usecount > > is exactly 1, to become zero after the last close of the file that > > opened a vnode referencing cdev. > > Also, d_close() is called if the vnode is being reclaimed. Possible > > causes are revoke(2) call or forced devfs mp unmount. This interferes > > with close counting. > > > > cdevpriv dtr is called when either struct file is released, or > > device is destroyed by the destroy_dev(). > > Kostik, > > is the following true: if D_TRACKCLOSE is specified then a number of > d_close() calls and a number of cdevpriv dtr calls are equal (provide > each file gets cdevpriv data) ? > If not, what is the case where one is called but not the other? No, I already described this. See the note about vnode reclamation. Also, d_close counter would have an interacation with destroy_dev(). To give you short summary, for D_TRACKCLOSE, d_close() may be called less times then dtr. pgpDF1JxUIJC9.pgp Description: PGP signature
Re: device driver: cdesw questions?
On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: > on 21/01/2009 16:05 Robert Watson said the following: > > > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > > > >> Question 1: I am writing a driver that would use per-open private data > >> (among other features). Do I have to use D_TRACKCLOSE flag in this > >> case? In general I am a little bit confused about when d_close is > >> invoked. Supposing D_TRACKCLOSE is not set and multiple programs > >> concurrently open, use and close a device - when d_close is called - > >> when one program closes its last descriptor tied to the device or when > >> the system-wide last such descriptor is closed? > > > > Kostik has already pointed at the cdevpriv API, but just to reiterate > > his point: most people will find the semantics of D_TRACKCLOSE confusing > > and consider them incorrect, so I would advise against using them. > > Robert, Kostik, > > in simplistic layman's terms I need the following - when a particular > program "closes my cdev" (explicitly or via exit) I need to catch that > and de-allocate certain resources. There can be multiple concurrent > programs opening, using and closing my cdev. > > I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead > I should perform the resource management in cdevpriv destructor. > Am I guessing correctly this time? Yes. This is the purpose of the cdevpriv KPI. pgpQhazRA1n7T.pgp Description: PGP signature
Re: device driver: cdesw questions?
on 21/01/2009 16:15 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: >> on 21/01/2009 16:05 Robert Watson said the following: >>> On Wed, 21 Jan 2009, Andriy Gapon wrote: >>> Question 1: I am writing a driver that would use per-open private data (among other features). Do I have to use D_TRACKCLOSE flag in this case? In general I am a little bit confused about when d_close is invoked. Supposing D_TRACKCLOSE is not set and multiple programs concurrently open, use and close a device - when d_close is called - when one program closes its last descriptor tied to the device or when the system-wide last such descriptor is closed? >>> Kostik has already pointed at the cdevpriv API, but just to reiterate >>> his point: most people will find the semantics of D_TRACKCLOSE confusing >>> and consider them incorrect, so I would advise against using them. >> Robert, Kostik, >> >> in simplistic layman's terms I need the following - when a particular >> program "closes my cdev" (explicitly or via exit) I need to catch that >> and de-allocate certain resources. There can be multiple concurrent >> programs opening, using and closing my cdev. >> >> I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead >> I should perform the resource management in cdevpriv destructor. >> Am I guessing correctly this time? > > Yes. This is the purpose of the cdevpriv KPI. Thank you! Sorry for being so thick :-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
MOD_UNLOAD and driver with cdev
Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? I see in the current code that one strategy is to simply call destroy_dev(). I guess detach routines are called automatically and destroy_dev can be done there as well.. Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? How to check for that best? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: MOD_UNLOAD and driver with cdev
On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: > > Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? > I see in the current code that one strategy is to simply call > destroy_dev(). I guess detach routines are called automatically and > destroy_dev can be done there as well.. What are the detach routines ? Do you mean newbus device detach ? Yes, the usual strategy is to call destroy_dev from unload handler. > > Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? > How to check for that best? This cannot be checked race-free. pgppoux7zyErg.pgp Description: PGP signature
Re: MOD_UNLOAD and driver with cdev
on 21/01/2009 17:39 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: >> Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? >> I see in the current code that one strategy is to simply call >> destroy_dev(). I guess detach routines are called automatically and >> destroy_dev can be done there as well.. > What are the detach routines ? Do you mean newbus device detach ? Yes, device_detach. This seems to work and make_device_driver.sh also suggests it this way. But I am not sure about possible races. > Yes, the usual strategy is to call destroy_dev from unload handler. > >> Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? >> How to check for that best? > > This cannot be checked race-free. So no point in trying? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: MOD_UNLOAD and driver with cdev
On Wed, Jan 21, 2009 at 05:50:38PM +0200, Andriy Gapon wrote: > on 21/01/2009 17:39 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: > >> Do I need to code for MOD_UNLOAD for driver module that also creates a > >> cdev? > >> I see in the current code that one strategy is to simply call > >> destroy_dev(). I guess detach routines are called automatically and > >> destroy_dev can be done there as well.. > > What are the detach routines ? Do you mean newbus device detach ? > > Yes, device_detach. This seems to work and make_device_driver.sh also > suggests it this way. But I am not sure about possible races. > > > Yes, the usual strategy is to call destroy_dev from unload handler. > > > >> Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? > >> How to check for that best? > > > > This cannot be checked race-free. > > So no point in trying? I would say no. You could use count_dev(), but my own experience shown that ability to unload driver is more important then unadvertently knock out filedescriptor from under the running program. pgpQqXk8Zlocv.pgp Description: PGP signature
Re: PRINTF_BUFR_SIZE in freebsd6
On Wednesday 17 December 2008 8:52:38 am pluknet wrote: > 2008/12/17 pluknet : > > 2008/12/16 Kostik Belousov : > >> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote: > >>> Hi. > >>> > >>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without > >>> merging a possible underlining infrastructure and breaking something else? > >>> I want to use it in my custom freebsd6 because I see "interspersed strings > >>> written from different CPUs at the same time": > >>> > >>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t > >>> pde) eaxtx cfcorke1 22e3e > >>> deded ebyd by28 296898 68(h t(tpdh) att ftorkp1 22d3 > >>> ) at fork1 223 > >>> > >>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129. > >>> > >>> Thanks. > >> > >> I did a backport of the option some time ago, see > >> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch > >> > > > > Thank you! > > > > 6.3 system panics (many page faults, one after another) early at boot > > without the option, and boots with it in the QEMU environment. > > Next step to test it on a real (and SMPable) hardware. > > > > Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE enabled. > > Received the following panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x72 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07fc8c3 > stack pointer = 0x28:0xe4f56a78 > frame pointer = 0x28:0xe4f56b44 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 14 (swi4: clock sio) > [thread pid 14 tid 12 ] > Stopped at vm_fault+0x1e3: cmpw$0,0x72(%eax) > db> bt > Tracing pid 14 tid 12 td 0xc63e9c80 > vm_fault(c1066000,c009e000,2,0) at vm_fault+0x1e3 > trap_pfault(e4f56bb0,0,c009effe) at trap_pfault+0x137 > trap(410008,c63e0028,e4f50028,c009effe,c638effe,...) at trap+0x325 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc08a2cad, esp = 0xe4f56bf0, ebp = 0xe4f56c10 --- > generic_bcopy(c0a63a68,7cf,c0a63a4c,7cf,f832) at generic_bcopy+0x41 > vga_txtdraw(c0a63a40,7cf,f832,0) at vga_txtdraw+0xbe > scrn_update(c0a63a40,1) at scrn_update+0x22d > scrn_timer(c0a6c1e0) at scrn_timer+0x1e0 > softclock(0) at softclock+0x1f4 > ithread_execute_handlers(c63e8460,c6629800) at ithread_execute_handlers+0xd6 > ithread_loop(c63a7910,e4f56d38,c0a10040,0,c0922ea6,...) at ithread_loop+0x53 > fork_exit(c068d158,c63a7910,e4f56d38) at fork_exit+0x61 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4f56d6c, ebp = 0 --- > db> I've seen this panic (or varations of it) on stock 6.x for a long time. I suspect some sort of bug in syscons itself. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: usb keyboard vs btx: an SMI theory
On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: > Again, I am very fuzzy about the exact details, but I think that this is > something that could be happening and I think that SMI is of primary > interest here. I also think that this might explain to a certain degree > the difference in behavior between "older" btx and "newer" btx. One thing to keep in mind is that when an SMI# is delivered, the processor enters System Management Mode (SMM). In SMM, the CPU actually uses a different set of memory for its RAM. It also runs in a sort of weird 32-bit real mode. It is not going to call the stock IRQ 1 handler. Instead, it passes data back to "normal" mode by changing the values restored into registers when exiting SMM. Typically doing an I/O port access to the ports backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler emulates the inb/outb request by storing the resulting data for an inb in the %ax register the "normal" mode sees once it resumes execution after the 'inb' instruction. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to "detach" a foreign driver from a device so my driver can attach?
On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote:
> On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote:
> > Hello all,
> >
> > I am writing a driver which attaches to the Host-PCI bridge. When
> > compiled into the kernel or loaded by the loader everything works
> > and the driver gets attached. This is due to the fact that I return
> > BUS_PROBE_SPECIFIC in my probe routine which gains over the -1
> > returned by pci_hostb_probe() in i386/pci/pci_bus.c.
> >
> > However, when I want to load my driver via kldload this fails since
> > the hostb device has already been attached during kernel load (when
> > my driver was not present):
> >
> > hos...@pci0:0:0:class=0x06 card=0x11d510cf chip=0x35808086
rev=0x02 hdr=0x00
> >
> > What can I do to make my driver load via kldload?
> > Is there a way to detach the hostb0 from the Host-PCI bridge?
>
> Found the answer myself but will post it here in case anyone
> got a similar problem one day: I added the device detach method
> for the hostb driver to sys/i386/pci/pci_bus.c:
>
> --- sys/i386/pci/pci_bus.c.ORI2007-08-17 08:12:33.0 +0200
> +++ sys/i386/pci/pci_bus.c2008-12-23 13:34:35.0 +0100
> @@ -619,10 +619,13 @@
> return 0;
> }
>
> +static int pci_hostb_detach(device_t dev) { return 0; }
> +
> static device_method_t pci_hostb_methods[] = {
> /* Device interface */
> DEVMETHOD(device_probe, pci_hostb_probe),
> DEVMETHOD(device_attach,pci_hostb_attach),
> + DEVMETHOD(device_detach,pci_hostb_detach),
> DEVMETHOD(device_shutdown, bus_generic_shutdown),
> DEVMETHOD(device_suspend, bus_generic_suspend),
> DEVMETHOD(device_resume,bus_generic_resume),
>
> Now, when kldload'ing my driver, it can walk through all devices
> and detach hostb using device_detach().
In the case of hostb, this is wrong however. You want to attach as a child of
hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as
well.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote:
> On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote:
> > Brian Fundakowski Feldman wrote:
> > > Could you, and anyone else who would care to, check this out? It's a
> > regression
> >> fix but it also makes the code a little bit clearer. Thanks!
> >>
> >> Index: lib/libc/stdlib/malloc.c
> >
> > Why does malloc need to change for this? Unless there's a really good
> > reason, I don't want the extra branches in the locking functions.
>
> Because malloc is the thing causing the regression. It is easy enough
> to optimize out the one extra fetch and branch in the single-threaded case
> if I can get some consensus that the fix to it is actually fine.
Pessimization removed:
Index: lib/libc/stdlib/malloc.c
===
--- lib/libc/stdlib/malloc.c(revision 187160)
+++ lib/libc/stdlib/malloc.c(working copy)
@@ -1217,6 +1217,13 @@
_SPINUNLOCK(&mutex->lock);
}
+static inline void
+malloc_mutex_always_unlock(malloc_mutex_t *mutex)
+{
+
+ _SPINUNLOCK(&mutex->lock);
+}
+
/*
* End mutex.
*/
@@ -1300,6 +1307,13 @@
_pthread_mutex_unlock(lock);
}
+static inline void
+malloc_spin_always_unlock(pthread_mutex_t *lock)
+{
+
+ _pthread_mutex_unlock(lock);
+}
+
/*
* End spin lock.
*/
@@ -5515,9 +5529,8 @@
void
_malloc_prefork(void)
{
+ arena_t *larenas[narenas];
bool again;
- unsigned i, j;
- arena_t *larenas[narenas], *tarenas[narenas];
/* Acquire all mutexes in a safe order. */
@@ -5530,19 +5543,23 @@
*/
memset(larenas, 0, sizeof(arena_t *) * narenas);
do {
+ unsigned int i;
+
again = false;
malloc_spin_lock(&arenas_lock);
for (i = 0; i < narenas; i++) {
if (arenas[i] != larenas[i]) {
+ arena_t *tarenas[narenas];
+ unsigned int j;
+
memcpy(tarenas, arenas, sizeof(arena_t *) *
narenas);
malloc_spin_unlock(&arenas_lock);
for (j = 0; j < narenas; j++) {
if (larenas[j] != tarenas[j]) {
larenas[j] = tarenas[j];
- malloc_spin_lock(
- &larenas[j]->lock);
+
malloc_spin_lock(&larenas[j]->lock);
}
}
again = true;
@@ -5569,19 +5586,24 @@
/* Release all mutexes, now that fork() has completed. */
#ifdef MALLOC_DSS
- malloc_mutex_unlock(&dss_mtx);
+ malloc_mutex_always_unlock(&dss_mtx);
#endif
- malloc_mutex_unlock(&huge_mtx);
+ malloc_mutex_always_unlock(&huge_mtx);
- malloc_mutex_unlock(&base_mtx);
+ malloc_mutex_always_unlock(&base_mtx);
memcpy(larenas, arenas, sizeof(arena_t *) * narenas);
- malloc_spin_unlock(&arenas_lock);
+ malloc_spin_always_unlock(&arenas_lock);
for (i = 0; i < narenas; i++) {
if (larenas[i] != NULL)
- malloc_spin_unlock(&larenas[i]->lock);
+ malloc_spin_always_unlock(&larenas[i]->lock);
}
+ /*
+* This ends the special post-__isthreaded exemption behavior for
+* malloc stuff. We should really be single threaded right now
+* in effect regardless of __isthreaded status.
+*/
}
/*
Index: lib/libthr/thread/thr_fork.c
===
--- lib/libthr/thread/thr_fork.c(revision 187160)
+++ lib/libthr/thread/thr_fork.c(working copy)
@@ -105,7 +105,7 @@
struct pthread_atfork *af;
pid_t ret;
int errsave;
- int unlock_malloc;
+ int was_threaded;
int rtld_locks[MAX_RTLD_LOCKS];
if (!_thr_is_inited())
@@ -122,16 +122,16 @@
}
/*
-* Try our best to protect memory from being corrupted in
-* child process because another thread in malloc code will
-* simply be kill by fork().
+* All bets are off as to what should happen soon if the parent
+* process was not so kindly as to set up pthread fork hooks to
+* relinquish all running threads.
*/
if (_thr_isthreaded() != 0) {
- unlock_malloc = 1;
+ was_threaded = 1;
_malloc_prefork();
_rtld_atfork_pre(rtld_locks);
} else {
- unlock_malloc = 0;
+ was_threaded = 0;
}
/*
@@ -159,7 +159,7 @@
Re: Kernel Module - GCC Requires memmove
On Wed, Jan 21, 2009 at 4:12 AM, Andrew Brampton
wrote:
> Hi,
> I'm doing the unusual task of converting some c++ code into a FreeBSD
> kernel module. Now all has been going great, and thus far I've been
> able to debug quite a bit of it using printfs. However, I decided to
> start using a kernel debugger, and to make this easier I passed g++
> the –O0 flag, to make it compile without optimisations.
>
> Bang, I hit a problem. All of a sudden when using the –O0 my module
> wouldn't load because it was missing an undefined reference to
> memmove. I found the specific object file which was using memmove. I
> did that by doing objdump –t *.o and finding which file had an
> undefined symbol memmove. Once I found the object file I grepped the
> associated source and I was sure I was not using memmove. I then got
> gcc to output both the post-processed source, as well as the asm.
>
> The .ii file (post-processed source) did NOT mention memmove at all.
> So I found it very odd that an undefined symbol existed in the object
> file. So then I looked in the .s file (asm), and it was clearing
> making a single call to memmove.
>
> So after a few hours of pulling my hair out I found this in the gcc manual:
> "-nostdlib The compiler may generate calls to memcmp, memset,
> memcpy and memmove. These entries are usually resolved by entries in
> libc. These entry points should be supplied through some other
> mechanism when this option is specified."
>
> So it appears that gcc may add calls to those four functions even if
> you don't use them yourself? I assume this has not been a problem for
> anyone yet due to only crazy people trying to use c++ in the kernel,
> and the specific set of gcc options I'm using.
>
> For the moment I have fixed this problem now by defining my own memmove like
> so:
>
> extern "C" void * memmove(void * dst, const void * src, size_t len) {
>bcopy(src, dst, len);
>return dst;
> }
>
> But I was wondering if those four functions should be defined in the
> kernel? I notice that memcpy and memset are already defined by the
> kernel somewhere, so perhaps memmove and memcmp should join them?
>
> Oh I should mention this was happening with the default gcc under FreeBSD 7.1.
>
> Thanks
> Andrew
And you #include'd string.h?
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Wed, 21 Jan 2009, Brian Fundakowski Feldman wrote: On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote: On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: Brian Fundakowski Feldman wrote: > Could you, and anyone else who would care to, check this out? It's a regression fix but it also makes the code a little bit clearer. Thanks! Index: lib/libc/stdlib/malloc.c Why does malloc need to change for this? Unless there's a really good reason, I don't want the extra branches in the locking functions. Because malloc is the thing causing the regression. It is easy enough to optimize out the one extra fetch and branch in the single-threaded case if I can get some consensus that the fix to it is actually fine. The changes to thr_fork.c seem gratuituous; they don't affect any functionality, and I don't see the difference between the flag saying "unlock the malloc mutex" or "I was threaded". Clearly, it is set in "if (__isthreaded)", so it is obvious that it indeed was threaded. I can't speak to the malloc changes... -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel Module - GCC Requires memmove
On 2009-01-21 13:12, Andrew Brampton wrote:
> The .ii file (post-processed source) did NOT mention memmove at all.
> So I found it very odd that an undefined symbol existed in the object
> file. So then I looked in the .s file (asm), and it was clearing
> making a single call to memmove.
This can (amongst others) occur if you assign structs, e.g.:
int test(void)
{
struct foo {
char bar[100];
} a, b;
b = a;
}
Compile this with gcc -O0 -S, and you'll see it generates a call to
memcpy().
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel Module - GCC Requires memmove
On Thu, 22 Jan 2009 00:44:23 +0100
Dimitry Andric wrote:
> On 2009-01-21 13:12, Andrew Brampton wrote:
> > The .ii file (post-processed source) did NOT mention memmove at all.
> > So I found it very odd that an undefined symbol existed in the
> > object file. So then I looked in the .s file (asm), and it was
> > clearing making a single call to memmove.
>
> This can (amongst others) occur if you assign structs, e.g.:
>
> int test(void)
> {
> struct foo {
> char bar[100];
> } a, b;
>
> b = a;
> }
>
> Compile this with gcc -O0 -S, and you'll see it generates a call to
> memcpy().
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscr...@freebsd.org"
From GCC's info pages:
Most of the compiler support routines used by GCC are present in
`libgcc', but there are a few exceptions. GCC requires the
freestanding environment provide `memcpy', `memmove', `memset' and
`memcmp'.
We do not provide all necessary functions in kernel and mostly depend
on luck for the kernel to link. Your luck apparently ran out :(
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Kernel Module - GCC Requires memmove
2009/1/21 Alexander Kabaev : > From GCC's info pages: > > Most of the compiler support routines used by GCC are present in > `libgcc', but there are a few exceptions. GCC requires the > freestanding environment provide `memcpy', `memmove', `memset' and > `memcmp'. > > > We do not provide all necessary functions in kernel and mostly depend > on luck for the kernel to link. Your luck apparently ran out :( > Thanks for the info, good thing I'm not a gambling man. Anyway I also read that part of the GCC manual, so my next question is: If code can be generated with those four functions, why are they not exported by the kernel? Surely another kernel module will at some point also be hit by this? thanks Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel Module - GCC Requires memmove
On Thu, 22 Jan 2009 00:52:13 + Andrew Brampton wrote: > 2009/1/21 Alexander Kabaev : > > From GCC's info pages: > > > > Most of the compiler support routines used by GCC are present in > > `libgcc', but there are a few exceptions. GCC requires the > > freestanding environment provide `memcpy', `memmove', `memset' and > > `memcmp'. > > > > > > We do not provide all necessary functions in kernel and mostly > > depend on luck for the kernel to link. Your luck apparently ran > > out :( > > > > Thanks for the info, good thing I'm not a gambling man. Anyway I also > read that part of the GCC manual, so my next question is: If code can > be generated with those four functions, why are they not exported by > the kernel? Surely another kernel module will at some point also be > hit by this? > > thanks > Andrew Very good question and the answer is simple: we do not export these functions because nobody needed them yet :) Historically we have grown these functions on an 'as needed' basis. I am sure the patch to add missing functions would get committed if it were made available. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Kernel Module - GCC Requires memmove
On Thu, 22 Jan 2009, Andrew Brampton wrote: 2009/1/21 Alexander Kabaev : From GCC's info pages: Most of the compiler support routines used by GCC are present in `libgcc', but there are a few exceptions. GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'. We do not provide all necessary functions in kernel and mostly depend on luck for the kernel to link. Your luck apparently ran out :( Thanks for the info, good thing I'm not a gambling man. Anyway I also read that part of the GCC manual, so my next question is: If code can be generated with those four functions, why are they not exported by the kernel? Surely another kernel module will at some point also be hit by this? Possibly because the kernel is usually compiled with optimization, in which case the compiler presumably generates inline code for these functions. I vaguely recall Linux having a policy that compiling the kernel without optimization was not supported, possibly because of situations like this. -- Nate Eldredge neldre...@math.ucsd.edu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
I think there *is* a real bug here, but there's two distinct ways to fix it. When a threaded process forks, malloc acquires all its locks so that its state is consistent after a fork. However, the post-fork hook that's supposed to release these locks fails to do so in the child because the child process isn't threaded, and malloc_mutex_unlock() is optimized to be a no-op in single-threaded processes. If the child *stays* single-threaded, malloc() works by accident even with all the locks held because malloc_mutex_lock() is also a no-op in single-threaded processes. But if the child goes multi-threaded, then things break. Solution 1 is to actually unlock the locks in the child process, which is what Brian is proposing. Solution 2 is to take the position that all of this pre- and post-fork bloat in the fork() path is gratuitous and should be removed. The rationale here is that if you fork with multiple running threads, there's scads of ways in which the child's heap could be inconsistent; fork hooks would be needed not just in malloc(), but in stdio, third party libraries, etc. Why should malloc() be special? It's the programmer's job to quiesce all the threads before calling fork(), and if the programmer doesn't do this, then POSIX only guarantees that async-signal-safe functions will work. Note that Solution 2 also fixes Brian's problem if he quiesces all of his worker threads before forking (as he should!) With the pre-fork hook removed, all the locks will start out free in the child. So that's what I vote for... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Wed, 21 Jan 2009, David Schultz wrote:
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork. However, the
post-fork hook that's supposed to release these locks fails to do
so in the child because the child process isn't threaded, and
malloc_mutex_unlock() is optimized to be a no-op in
single-threaded processes. If the child *stays* single-threaded,
malloc() works by accident even with all the locks held because
malloc_mutex_lock() is also a no-op in single-threaded processes.
But if the child goes multi-threaded, then things break.
Solution 1 is to actually unlock the locks in the child process,
which is what Brian is proposing.
Solution 2 is to take the position that all of this pre- and
post-fork bloat in the fork() path is gratuitous and should be
removed. The rationale here is that if you fork with multiple
running threads, there's scads of ways in which the child's heap
could be inconsistent; fork hooks would be needed not just in
malloc(), but in stdio, third party libraries, etc. Why should
malloc() be special? It's the programmer's job to quiesce all the
threads before calling fork(), and if the programmer doesn't do
this, then POSIX only guarantees that async-signal-safe functions
will work.
Note that Solution 2 also fixes Brian's problem if he quiesces all
of his worker threads before forking (as he should!) With the
pre-fork hook removed, all the locks will start out free in the
child. So that's what I vote for...
The problem is that our own libraries (libthr included)
need to malloc() for themselves, even after a fork() in
the child. After a fork(), the malloc locks should be
reinitialized in the child if it was threaded, so that
our implementation actually works for all the async
signal calls, fork(), exec(), etc. I forget the exact
failure modes for very common cases, but if you remove
the re-initialization of the malloc locks, I'm sure
you will have problems.
Perhaps much of this malloc() stuff goes away when we
move to pthread locks that are not pointers to allocated
objects, but instead are actual objects/structures.
This needs to be done in order for mutexes/CVs/etc
to be PTHREAD_PROCESS_SHARED (placed in shared memory
and used by multiple processes). In other words,
pthread_mutex_t goes from this:
typedef struct pthread_mutex *pthread_mutex_t;
to something like this:
struct __pthread_mutex {
uint32_tlock;
...
}
typedef struct __pthread_mutex pthread_mutex_t;
Same thing for CVs, and we probably should convert any other
locks used internally by libc/libpthread (spinlocks).
So after a fork(), there is no need to reallocate anything,
it can just be reinitialized if necessary.
--
DE
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Thu, Jan 22, 2009, Daniel Eischen wrote: > On Wed, 21 Jan 2009, David Schultz wrote: > > >I think there *is* a real bug here, but there's two distinct ways > >to fix it. When a threaded process forks, malloc acquires all its > >locks so that its state is consistent after a fork. However, the > >post-fork hook that's supposed to release these locks fails to do > >so in the child because the child process isn't threaded, and > >malloc_mutex_unlock() is optimized to be a no-op in > >single-threaded processes. If the child *stays* single-threaded, > >malloc() works by accident even with all the locks held because > >malloc_mutex_lock() is also a no-op in single-threaded processes. > >But if the child goes multi-threaded, then things break. > > > >Solution 1 is to actually unlock the locks in the child process, > >which is what Brian is proposing. > > > >Solution 2 is to take the position that all of this pre- and > >post-fork bloat in the fork() path is gratuitous and should be > >removed. The rationale here is that if you fork with multiple > >running threads, there's scads of ways in which the child's heap > >could be inconsistent; fork hooks would be needed not just in > >malloc(), but in stdio, third party libraries, etc. Why should > >malloc() be special? It's the programmer's job to quiesce all the > >threads before calling fork(), and if the programmer doesn't do > >this, then POSIX only guarantees that async-signal-safe functions > >will work. > > > >Note that Solution 2 also fixes Brian's problem if he quiesces all > >of his worker threads before forking (as he should!) With the > >pre-fork hook removed, all the locks will start out free in the > >child. So that's what I vote for... > > The problem is that our own libraries (libthr included) > need to malloc() for themselves, even after a fork() in > the child. After a fork(), the malloc locks should be > reinitialized in the child if it was threaded, so that > our implementation actually works for all the async > signal calls, fork(), exec(), etc. I forget the exact > failure modes for very common cases, but if you remove > the re-initialization of the malloc locks, I'm sure > you will have problems. If you can't implement functions that are required to be async-signal-safe like fork() and exec() without malloc(), then for now I guess we should go for something along the lines of what Brian is proposing. If the app programmer has taken special pains to ensure that all other threads are stopped when a fork happens, the fork() call shouldn't return in the child with all the malloc locks bogusly held. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to "detach" a foreign driver from a device so my driver can attach?
On Wed, 21-Jan-2009 at 14:08:37 -0500, John Baldwin wrote:
> On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote:
> > On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote:
> > > Hello all,
> > >
> > > I am writing a driver which attaches to the Host-PCI bridge. When
> > > compiled into the kernel or loaded by the loader everything works
> > > and the driver gets attached. This is due to the fact that I return
> > > BUS_PROBE_SPECIFIC in my probe routine which gains over the -1
> > > returned by pci_hostb_probe() in i386/pci/pci_bus.c.
> > >
> > > However, when I want to load my driver via kldload this fails since
> > > the hostb device has already been attached during kernel load (when
> > > my driver was not present):
> > >
> > > hos...@pci0:0:0:class=0x06 card=0x11d510cf chip=0x35808086
> rev=0x02 hdr=0x00
> > >
> > > What can I do to make my driver load via kldload?
> > > Is there a way to detach the hostb0 from the Host-PCI bridge?
> >
> > Found the answer myself but will post it here in case anyone
> > got a similar problem one day: I added the device detach method
> > for the hostb driver to sys/i386/pci/pci_bus.c:
> >
> > --- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.0 +0200
> > +++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.0 +0100
> > @@ -619,10 +619,13 @@
> > return 0;
> > }
> >
> > +static int pci_hostb_detach(device_t dev) { return 0; }
> > +
> > static device_method_t pci_hostb_methods[] = {
> > /* Device interface */
> > DEVMETHOD(device_probe, pci_hostb_probe),
> > DEVMETHOD(device_attach,pci_hostb_attach),
> > + DEVMETHOD(device_detach,pci_hostb_detach),
> > DEVMETHOD(device_shutdown, bus_generic_shutdown),
> > DEVMETHOD(device_suspend, bus_generic_suspend),
> > DEVMETHOD(device_resume,bus_generic_resume),
> >
> > Now, when kldload'ing my driver, it can walk through all devices
> > and detach hostb using device_detach().
>
> In the case of hostb, this is wrong however. You want to attach as a child
> of
As I learned in the meanwhile, yes. But it was quite
interesting to learn how things work when you have
never been into FreeBSD driver hacking before ;-).
> hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as
> well.
Would this work in 6.x as well? You wrote in another mail that
in 7.0 agp attaches to hostb. This makes me think that in 6.x
things are handled differently.
If not, I will stick to my detaching while I am on 6.x
(don't need agp on my 440BXs) and do it right when
I have migrated to 7.x...
Thanks,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Thu, Jan 22, 2009, David Schultz wrote: > If you can't implement functions that are required to be > async-signal-safe like fork() and exec() without malloc(), then > for now I guess we should go for something along the lines of what > Brian is proposing. If the app programmer has taken special pains > to ensure that all other threads are stopped when a fork happens, > the fork() call shouldn't return in the child with all the malloc > locks bogusly held. Note that even with Brian's patch, the memory associated with the all the parent's threads' stacks is leaked, and libthr can't be expected to be in a particularly happy state after all of its threads disappear. It just happens to (sort of) work for now. In any case, it's clearly a bug that libthr's fork handler calls _malloc_postfork() in the child even when _malloc_postfork() doesn't work properly in the (now single-threaded) child. Which way to fix it is up to you guys... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
