On Thu, 7 Feb 2002, Julian Elischer wrote:
> As part of the KSe stuff I ended up changing ht ebehaviour of threads with
> respect to their ucreds. Previously, they freed their ucred reference when
> they entered user space and picked them up again when they re-entered the
> kernel. It there was a
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred t
On Fri, 8 Feb 2002, Bruce Evans wrote:
[...]
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucred);
> > td->td_ucred = NULL;
> > }
> >
On 08-Feb-02 Terry Lambert wrote:
> John Baldwin wrote:
>> No, an unlocked compare is _not_ ok. What if the p_ucred pointer was
>> changed
>> on some other processor by another thread from this processor?
>
> I saw your response to Julian... I understand the concern,
> but I think it's unfounde
Julian Elischer wrote:
> Terry I don't have time to work on it now, but if you would like to take a
> -current system
> and apply the threading KSE diffs from my web page,
> then maybe you can investigate whether I really ned the if clause or
> not..
> I don't have time now to go back to it for
On 08-Feb-02 Julian Elischer wrote:
>
> As part of the KSe stuff I ended up changing ht ebehaviour of threads with
> respect to their ucreds. Previously, they freed their ucred reference when
> they entered user space and picked them up again when they re-entered the
> kernel. It there was an AS
John Baldwin wrote:
> No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed
> on some other processor by another thread from this processor?
I saw your response to Julian... I understand the concern,
but I think it's unfounded. Let me explain.
> Without a lock
> you don
Terry I don't have time to work on it now, but if you would like to take a
-current system
and apply the threading KSE diffs from my web page,
then maybe you can investigate whether I really ned the if clause or
not..
I don't have time now to go back to it for a while
On Thu, 7 Feb 2002, Terr
Julian Elischer wrote:
> yes.. well in booting yuo can have a null ucred. ( I know,s
> I've hit it), but in general you are correct.
[ ... ]
> > What is the default state of td->td_ucred?
>
> on creation, NULL followed very rapidly with being set to
> p->p_ucred. (via crhold)
Non-problem, then
On Thu, 7 Feb 2002, Terry Lambert wrote:
> Julian Elischer wrote:
> > In the KSE code I have:
> > in trap(), and syscall()
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucre
Julian Elischer wrote:
> In the KSE code I have:
> in trap(), and syscall()
>
> if (td->td_ucred != p->p_ucred) {
> PROC_LOCK(p);
> if (td->td_ucred) {
> crfree(td->td_ucred);
> td->td_ucred = NULL;
>
On Fri, 8 Feb 2002, Bruce Evans wrote:
[...]
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucred);
> > td->td_ucred = NULL;
> > }
> >
On 08-Feb-02 Terry Lambert wrote:
> John Baldwin wrote:
>> No, an unlocked compare is _not_ ok. What if the p_ucred pointer was
>> changed
>> on some other processor by another thread from this processor?
>
> I saw your response to Julian... I understand the concern,
> but I think it's unfounde
On Thu, 7 Feb 2002, Julian Elischer wrote:
> As part of the KSe stuff I ended up changing ht ebehaviour of threads with
> respect to their ucreds. Previously, they freed their ucred reference when
> they entered user space and picked them up again when they re-entered the
> kernel. It there was a
John Baldwin wrote:
> No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed
> on some other processor by another thread from this processor?
I saw your response to Julian... I understand the concern,
but I think it's unfounded. Let me explain.
> Without a lock
> you don
On Thu, 7 Feb 2002, John Baldwin wrote:
>
>
> This code is not safe on SMP non-i386 machines (i.e. ia64, sparc64, alpha, and
> possibly p3 and later i386's) because the p_ucred value you read could easily
> be a stale value, thus rendering the test invalid. You need the lock for the
> compar
On 08-Feb-02 Terry Lambert wrote:
> Since the reference count is positive in both cases, an
> unlocked pointer comparison is fine. In the case where
> there is a race on a credential change in the unlocked
> value, that race exists in the calling code, anyway. The
> failure case in a change for
On 08-Feb-02 Julian Elischer wrote:
>
> As part of the KSe stuff I ended up changing ht ebehaviour of threads with
> respect to their ucreds. Previously, they freed their ucred reference when
> they entered user space and picked them up again when they re-entered the
> kernel. It there was an AS
Julian Elischer wrote:
> Terry I don't have time to work on it now, but if you would like to take a
> -current system
> and apply the threading KSE diffs from my web page,
> then maybe you can investigate whether I really ned the if clause or
> not..
> I don't have time now to go back to it for
Terry I don't have time to work on it now, but if you would like to take a
-current system
and apply the threading KSE diffs from my web page,
then maybe you can investigate whether I really ned the if clause or
not..
I don't have time now to go back to it for a while
On Thu, 7 Feb 2002, Terr
Julian Elischer wrote:
> yes.. well in booting yuo can have a null ucred. ( I know,s
> I've hit it), but in general you are correct.
[ ... ]
> > What is the default state of td->td_ucred?
>
> on creation, NULL followed very rapidly with being set to
> p->p_ucred. (via crhold)
Non-problem, then
On Thu, 7 Feb 2002, Terry Lambert wrote:
> Julian Elischer wrote:
> > In the KSE code I have:
> > in trap(), and syscall()
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucre
Julian Elischer wrote:
> In the KSE code I have:
> in trap(), and syscall()
>
> if (td->td_ucred != p->p_ucred) {
> PROC_LOCK(p);
> if (td->td_ucred) {
> crfree(td->td_ucred);
> td->td_ucred = NULL;
>
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred t
24 matches
Mail list logo
