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
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;
>
22 matches
Mail list logo
