On Wed, 2007-06-06 at 01:00 +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > We actually need to do something about this, as we might loop for ever
> > there. The robust cleanup code can fail (e.g. due to list corruption)
> > and we would see exit_state != 0 and the OWNER_DIED bit would never be
> >
Hello!
> We actually need to do something about this, as we might loop for ever
> there. The robust cleanup code can fail (e.g. due to list corruption)
> and we would see exit_state != 0 and the OWNER_DIED bit would never be
> set, so we are stuck in a busy loop.
Yes...
It is possible to take
On Tue, 2007-06-05 at 20:48 +0200, Thomas Gleixner wrote:
> > > This does not really explain, why you do prevent the -ESRCH return value
> > > in the next cycle,
> >
> > Because right curval is refetched, it already has FUTEX_OWNER_DIED bit set
> > and we succesfully take the lock.
>
> Ok,
On Tue, 2007-06-05 at 21:39 +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > Hmm, what means not expected ? -ESRCH is returned, when the owner task
> > is not found.
>
> This is not supposed to happen with robust futexes.
Hmm, right.
> > This does not really explain, why you do prevent the
Hello!
> Hmm, what means not expected ? -ESRCH is returned, when the owner task
> is not found.
This is not supposed to happen with robust futexes.
glibs aborts (which is correct), or for build with disabled debugging
enters simulated deadlock (which is confusing).
> lock. Also using uval is
Hi,
On Wed, 2007-05-23 at 15:51 +0400, Alexey Kuznetsov wrote:
> The first chunk: results in self-inflicted deadlock inside glibc.
> Sometimes futex_lock_pi returns -ESRCH, when it is not expected
> and glibc enters to for(;;) sleep() to simulate deadlock. This problem
> is quite obvious and I
Hi,
On Wed, 2007-05-23 at 15:51 +0400, Alexey Kuznetsov wrote:
The first chunk: results in self-inflicted deadlock inside glibc.
Sometimes futex_lock_pi returns -ESRCH, when it is not expected
and glibc enters to for(;;) sleep() to simulate deadlock. This problem
is quite obvious and I think
Hello!
Hmm, what means not expected ? -ESRCH is returned, when the owner task
is not found.
This is not supposed to happen with robust futexes.
glibs aborts (which is correct), or for build with disabled debugging
enters simulated deadlock (which is confusing).
lock. Also using uval is
On Tue, 2007-06-05 at 21:39 +0400, Alexey Kuznetsov wrote:
Hello!
Hmm, what means not expected ? -ESRCH is returned, when the owner task
is not found.
This is not supposed to happen with robust futexes.
Hmm, right.
This does not really explain, why you do prevent the -ESRCH return
On Tue, 2007-06-05 at 20:48 +0200, Thomas Gleixner wrote:
This does not really explain, why you do prevent the -ESRCH return value
in the next cycle,
Because right curval is refetched, it already has FUTEX_OWNER_DIED bit set
and we succesfully take the lock.
Ok,
Hello!
We actually need to do something about this, as we might loop for ever
there. The robust cleanup code can fail (e.g. due to list corruption)
and we would see exit_state != 0 and the OWNER_DIED bit would never be
set, so we are stuck in a busy loop.
Yes...
It is possible to take
On Wed, 2007-06-06 at 01:00 +0400, Alexey Kuznetsov wrote:
Hello!
We actually need to do something about this, as we might loop for ever
there. The robust cleanup code can fail (e.g. due to list corruption)
and we would see exit_state != 0 and the OWNER_DIED bit would never be
set, so
Hello!
> #2 crash be explained via any of the bugs you fixed? (i.e. memory
> corruption?)
Yes, I found the reason, it is really fixed by taking tasklist_lock.
This happens after task struct with not cleared pi_state_list is freed
and the list of futex_pi_state's is corrupted.
Meanwhile... two
* Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> 1. New entries can be added to tsk->pi_state_list after task completed
>exit_pi_state_list(). The result is memory leakage and deadlocks.
>
> 2. handle_mm_fault() is called under spinlock. The result is obvious.
>
> 3. State
* Alexey Kuznetsov [EMAIL PROTECTED] wrote:
Hello!
1. New entries can be added to tsk-pi_state_list after task completed
exit_pi_state_list(). The result is memory leakage and deadlocks.
2. handle_mm_fault() is called under spinlock. The result is obvious.
3. State machine is
Hello!
#2 crash be explained via any of the bugs you fixed? (i.e. memory
corruption?)
Yes, I found the reason, it is really fixed by taking tasklist_lock.
This happens after task struct with not cleared pi_state_list is freed
and the list of futex_pi_state's is corrupted.
Meanwhile... two
16 matches
Mail list logo
