On Thursday 26 April 2007 19:49, John Baldwin wrote:
On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote:
Hello,
I googled but found nothing about the usage of the kern_* functions
(kern_open, kern_close, kern_pwritev, kern_preadv) that are located in
vfs_syscalls.c
When I use
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer [EMAIL PROTECTED]:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind manner.. in other words, it doesn't know it is
On Thursday 26 April 2007 23:52, Bosko Milekic wrote:
On 4/26/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
Hi,
In the new USB stack I have defined the following:
Could you perhaps describe some of the codepaths in the USB stack that
require this behavior?
There are no requirements
Hans Petter Selasky wrote this message on Fri, Apr 27, 2007 at 07:50 +0200:
On Thursday 26 April 2007 23:52, Bosko Milekic wrote:
On 4/26/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
Hi,
In the new USB stack I have defined the following:
Could you perhaps describe some of the
Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer [EMAIL PROTECTED]:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind manner.. in other
On 4/26/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
Hi,
In the new USB stack I have defined the following:
Could you perhaps describe some of the codepaths in the USB stack that
require this behavior?
--
Bosko Milekic [EMAIL PROTECTED]
http://www.crowdedweb.com/
On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer [EMAIL PROTECTED]:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind
Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer [EMAIL PROTECTED]:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind manner.. in other
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated procedure has no
clue as to
Hans Petter Selasky wrote:
First of all: Where is FreeBSD's locking strategy document?
It is just started..
man 9 locking. it needs a lot of work still.
We should have a
global strategy when we write device drivers, so that various modules can be
connected together without races and
Matthew Dillon wrote:
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated
Julian Elischer wrote:
I think trying to sleep with a recursed mutex should be an instant panic,
even if the mutex IS marked as being allowed to sleep.
I mean marked as being able to recurse.
___
freebsd-hackers@freebsd.org mailing list
On Friday 27 April 2007 19:39, Matthew Dillon wrote:
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding
On Friday 27 April 2007 15:14, Daniel Eischen wrote:
On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer [EMAIL PROTECTED]:
The reason that mutexes ever recurse in the first place is usually
because one piece of
On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
On Friday 27 April 2007 15:14, Daniel Eischen wrote:
When you hold a mutex, it should be for a very short time. And
I agree with the other comment that all drivers should be multi-thread
safe, so we shouldn't add cruft to allow for non MT-safe
On Thursday 26 April 2007 03:36:33 pm Hans Petter Selasky wrote:
Are there any comments on integrating this functionality into msleep(), and
adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel?
Nope. Fix the code to not recurse instead, or to know it has a recursed mutex
On Friday 27 April 2007 02:43:16 am Marc Lörner wrote:
On Thursday 26 April 2007 19:49, John Baldwin wrote:
On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote:
Hello,
I googled but found nothing about the usage of the kern_* functions
(kern_open, kern_close, kern_pwritev,
On Friday 27 April 2007 20:01, Julian Elischer wrote:
Hans Petter Selasky wrote:
First of all: Where is FreeBSD's locking strategy document?
It is just started..
man 9 locking. it needs a lot of work still.
Excellent.
We should have a
global strategy when we write device drivers, so
For core files and checkpoints that isn't possible.
-Kip
On 4/27/07, John Baldwin [EMAIL PROTECTED] wrote:
On Friday 27 April 2007 02:43:16 am Marc Lörner wrote:
On Thursday 26 April 2007 19:49, John Baldwin wrote:
On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote:
Hello,
I
From: Julian Elischer [EMAIL PROTECTED]
Basically you shouldn't have a recursed mutex FULL STOP. We have a couple
of instances in the kernel where we allow a mutex to recurse, but they had to
be
hard fought, and the general rule is Don't. If you are recursing on
a mutex you need to switch to
20 matches
Mail list logo
