Please review this patch. I haven't looked at BDE's patch but this was
so simple I decided to just go do it.
There are many situations where the allocation of a system structure can
be safely done with Giant, but deallocation occurs dangerously deep
in the call stack. For
Julian Elischer wrote:
This makes little sense to me.
Maybe I'm missing something, but by virtue of ownership we don't
have to worry about the ucred's refcount on entry into the kernel
because it is the owner and no one else is allowed to change our
privledges besideds ourselves via
On 11-Feb-02 Julian Elischer wrote:
here is the BDE version ready to commit.
Extended to other architectures.
Bruce, John, comments?
As I was adding a prototype to ucred.h I stripped the __Ps of the others in
that
section
(in the spirit of change it when editing it anyhow
Hmm,
On 11-Feb-02 Alfred Perlstein wrote:
* Julian Elischer [EMAIL PROTECTED] [020211 15:00] wrote:
In the current world, when the thread enters userland, it does:
lock giant
crfree() (which includes mutexes)
unlock giant
This isn't needed afaik.
Yes, calling free() without Giant is about
On 12-Feb-02 Julian Elischer wrote:
The proclock is needed to get the reference,
guarding against other threads, and giant is needed fo rnot to free it
because if it reaches a refcount of 0 it needs to call free(). (which john
assures me needs Giant at this time).
We could avoid the
On 12-Feb-02 Terry Lambert wrote:
Julian Elischer wrote:
This makes little sense to me.
Maybe I'm missing something, but by virtue of ownership we don't
have to worry about the ucred's refcount on entry into the kernel
because it is the owner and no one else is allowed to change our
On Mon, 11 Feb 2002, John Baldwin wrote:
On 11-Feb-02 Julian Elischer wrote:
here is the BDE version ready to commit.
Extended to other architectures.
Bruce, John, comments?
As I was adding a prototype to ucred.h I stripped the __Ps of the others in
that
section
(in the
On Mon, 11 Feb 2002, Terry Lambert wrote:
Julian Elischer wrote:
This makes little sense to me.
Maybe I'm missing something, but by virtue of ownership we don't
have to worry about the ucred's refcount on entry into the kernel
because it is the owner and no one else is allowed
On 11-Feb-02 Julian Elischer wrote:
here is the BDE version ready to commit.
Extended to other architectures.
Bruce, John, comments?
As I was adding a prototype to ucred.h I stripped the __Ps of the others in
that
section
(in the spirit of change it when editing it anyhow
Hmm,
On 12-Feb-02 Julian Elischer wrote:
The proclock is needed to get the reference,
guarding against other threads, and giant is needed fo rnot to free it
because if it reaches a refcount of 0 it needs to call free(). (which john
assures me needs Giant at this time).
We could avoid the
On 11-Feb-02 Alfred Perlstein wrote:
* Julian Elischer [EMAIL PROTECTED] [020211 15:00] wrote:
In the current world, when the thread enters userland, it does:
lock giant
crfree() (which includes mutexes)
unlock giant
This isn't needed afaik.
Yes, calling free() without Giant is about
* Julian Elischer [EMAIL PROTECTED] [020211 15:00] wrote:
In the current world, when the thread enters userland, it does:
lock giant
crfree() (which includes mutexes)
unlock giant
This isn't needed afaik.
if there are ASTs it does this once again for each AST waiting as well.
And on
On Mon, 11 Feb 2002, Alfred Perlstein wrote:
* Julian Elischer [EMAIL PROTECTED] [020211 15:00] wrote:
In the current world, when the thread enters userland, it does:
lock giant
crfree() (which includes mutexes)
unlock giant
This isn't needed afaik.
Argue with jhb.
if
On Mon, 11 Feb 2002, John Baldwin wrote:
On 12-Feb-02 Julian Elischer wrote:
The proclock is needed to get the reference,
guarding against other threads, and giant is needed fo rnot to free it
because if it reaches a refcount of 0 it needs to call free(). (which john
assures me
John Baldwin wrote:
Yes, calling free() without Giant is about as good as calling fdrop() without
Giant Alfred. :)
Alfred would be right, for per processor memory pools. 8-).
And on the way into the system it does:
lock process
crhold() (which includes mutex ops)
unlock process
Julian Elischer wrote:
The multiple threads argument is bogus, since the calls
to [gs]et[ug]id() are on a per process, not a per thread
basis.
there is no such thing as a per process syscall.
Two threads can always do the same syscall at the same time.
there needs to be a proc-lock to
John Baldwin wrote:
The multiple threads argument is bogus, since the calls
to [gs]et[ug]id() are on a per process, not a per thread
basis.
Thread 1 makes a syscall that blocks. Say it blocks in one of 3 VOP's all of
which need a credential. Thread 2 changes the credentials of the
On 12-Feb-02 Julian Elischer wrote:
On Mon, 11 Feb 2002, John Baldwin wrote:
On 12-Feb-02 Julian Elischer wrote:
The proclock is needed to get the reference,
guarding against other threads, and giant is needed fo rnot to free it
because if it reaches a refcount of 0 it needs to
On 12-Feb-02 Terry Lambert wrote:
Julian Elischer wrote:
The multiple threads argument is bogus, since the calls
to [gs]et[ug]id() are on a per process, not a per thread
basis.
there is no such thing as a per process syscall.
Two threads can always do the same syscall at the same
On 12-Feb-02 Terry Lambert wrote:
Then the combination of calls fails. There is no case where
it will succeed when previously it would not. I would argue
that the failure is a lost race condition that exists in the
code anyway, and that this approach merely makes the race
failure more
20 matches
Mail list logo
