On 09-Feb-02 Julian Elischer wrote:
I'm a little worried about invariants because the behaviour when
INVARIANTS is set wil be different to teh behaviour when it is off, which
is 'strange' to say the least. Normally the behaviour si the same but you
just check for invariant conditions.
In
John, (peter? others?)
How is it that getting a ucred reference is guarded by PROC_LOCK(p)
but freeing it is guarded by mtx_lock(Giant);
?
Call me naive, but shouldn't they be guarded by the same thing?
Julian
On Fri, 8 Feb 2002, Julian Elischer wrote:
I'm a little worried about
I'm a little worried about invariants because the behaviour when
INVARIANTS is set wil be different to teh behaviour when it is off, which
is 'strange' to say the least. Normally the behaviour si the same but you
just check for invariant conditions.
On Fri, 8 Feb 2002, John Baldwin wrote:
On Fri, 8 Feb 2002, Julian Elischer wrote:
I'd like to commit the code to keep the ucred across userland,
with the code to clear it to NULL kept under DEBUG ifdefs.
i.e.
in trap(), ast() and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
On Fri, 8 Feb 2002, Julian Elischer wrote:
John, (peter? others?)
How is it that getting a ucred reference is guarded by PROC_LOCK(p)
but freeing it is guarded by mtx_lock(Giant);
?
Call me naive, but shouldn't they be guarded by the same thing?
In fact, if we had good atomic
On Fri, 8 Feb 2002, Julian Elischer wrote:
I'd like to commit the code to keep the ucred across userland,
with the code to clear it to NULL kept under DEBUG ifdefs.
i.e.
in trap(), ast() and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
On 09-Feb-02 Julian Elischer wrote:
I'm a little worried about invariants because the behaviour when
INVARIANTS is set wil be different to teh behaviour when it is off, which
is 'strange' to say the least. Normally the behaviour si the same but you
just check for invariant conditions.
In
On 09-Feb-02 Julian Elischer wrote:
John, (peter? others?)
How is it that getting a ucred reference is guarded by PROC_LOCK(p)
but freeing it is guarded by mtx_lock(Giant);
?
Call me naive, but shouldn't they be guarded by the same thing?
Naive, maybe. :-P The actual refcount for a
On 09-Feb-02 Julian Elischer wrote:
On Fri, 8 Feb 2002, Julian Elischer wrote:
John, (peter? others?)
How is it that getting a ucred reference is guarded by PROC_LOCK(p)
but freeing it is guarded by mtx_lock(Giant);
?
Call me naive, but shouldn't they be guarded by the same
On Sun, 10 Feb 2002, Bruce Evans wrote:
On Fri, 8 Feb 2002, Julian Elischer wrote:
I'd like to commit the code to keep the ucred across userland,
with the code to clear it to NULL kept under DEBUG ifdefs.
i.e.
in trap(), ast() and syscall()
if (td-td_ucred !=
On Sat, 9 Feb 2002, Julian Elischer wrote:
On Sun, 10 Feb 2002, Bruce Evans wrote:
On Fri, 8 Feb 2002, Julian Elischer wrote:
...
and in userret() and ast()
#ifdef DEBUG /*your choice of variable here*/
if (td-td_ucred != NULL) {
On Sun, 10 Feb 2002, Bruce Evans wrote:
On Sat, 9 Feb 2002, Julian Elischer wrote:
AST is not always called
and userret is always called, but unfortunatly sometimes multiple times
userret() isn't always called either in my version :-). When I'm
finished, it will never be called
On Sat, 9 Feb 2002, Julian Elischer wrote:
On Sun, 10 Feb 2002, Bruce Evans wrote:
On Sat, 9 Feb 2002, Julian Elischer wrote:
AST is not always called
and userret is always called, but unfortunatly sometimes multiple times
userret() isn't always called either in my version :-).
On Sun, 10 Feb 2002, Bruce Evans wrote:
On Sat, 9 Feb 2002, Julian Elischer wrote:
On Sun, 10 Feb 2002, Bruce Evans wrote:
On Sat, 9 Feb 2002, Julian Elischer wrote:
AST is not always called
and userret is always called, but unfortunatly sometimes multiple times
On 08-Feb-02 Julian Elischer wrote:
I'd like to commit the code to keep the ucred across userland,
with the code to clear it to NULL kept under DEBUG ifdefs.
Use INVARIANTS for the ifdef macro name, but sure.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users
I'm a little worried about invariants because the behaviour when
INVARIANTS is set wil be different to teh behaviour when it is off, which
is 'strange' to say the least. Normally the behaviour si the same but you
just check for invariant conditions.
On Fri, 8 Feb 2002, John Baldwin wrote:
John, (peter? others?)
How is it that getting a ucred reference is guarded by PROC_LOCK(p)
but freeing it is guarded by mtx_lock(Giant);
?
Call me naive, but shouldn't they be guarded by the same thing?
Julian
On Fri, 8 Feb 2002, Julian Elischer wrote:
I'm a little worried about
17 matches
Mail list logo
