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
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 invarian
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);
> if (td->td_ucred) {
>
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.
I
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 tim
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 ver
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 b
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 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
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 guarde
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
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.
I
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
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 invarian
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 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
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);
> if (td->td_ucred) {
>
19 matches
Mail list logo
