On Thu, 4 May 2000, Manfred Spraul wrote:
> From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
> >
>
> > > My box agrees with you that my attempt is wrong. Moving the task_lock()
> > > back too it's original position (up one) works best here, but it looks
> > > like it was moved intentionally so I keep trying to make it act right
> > > where it is. (Even with it back in original position, my box isn't very
> > > stable atm)
> >
> > Moving the task lock back solves some problems and adds others.
> >
>
> I couldn't find the beginng of the thread, but what about using the same
> locking as access_process_vm [kernel/ptrace.c] in proc_exe_link?
>
> get_task_struct(); /* in proc_pid_make_inode */
> task_lock();
> /* task->mm can still change due to daemonize(), start_lazy_tlb() */
> lock_kernel();
> mm = task->mm;
> if(!mm)
> goto out;
> atomic_inc(&mm->mm_users);
> unlock_kernel();
>
> down(&mm->mmap_sem);
> ...
Minus lock_kernel(), that's what I tried (UP box).
<Andrea>
I think that's not the correct fix though because there's probably still a
window for a race if you happen to increase the mmap_sem when it was just
zero (too late).
</Andrea>
Only relevant on SMP?
The troubles I'm seeing begin with a reference to a freed task_struct
and things go down hill rapidly from there.
-Mike
c015268f proc_exe_link +<13/1ac> (2.08) pid(291)
base.c:68 if (!task_lock(task))
base.c:69 return result;
sched.h:844 static inline int task_lock(struct task_struct *p)
sched.h:845 {
sched.h:846 down(&p->exit_sem);
c01094d7 __down +<13/2ec> (3.45) pid(291)
semaphore.c:74 struct task_struct *tsk = current;
semaphore.c:75 DECLARE_WAITQUEUE(wait, tsk);
semaphore.c:76 CHECK_ALLOC(sem); <CHECKPOINT: passed>
.....
semaphore.c:88 for (;;) {
semaphore.c:89 int sleepers = sem->sleepers;
semaphore.c:90
semaphore.c:91 CHECK_ALLOC(sem); <CHECKPOINT: passed>
semaphore.c:104 spin_unlock_irq(&semaphore_lock);
semaphore.c:105
semaphore.c:106 schedule();
c0115197 schedule +<13/3ec> (1.14) pid(291->0) <it's downed, we sleep>
c0109280 __switch_to +<10/c4> (1.09) pid(0) <why idle?>
.....
c010b1eb system_call +<23/44> (0.46) pid(161) <meanwhile task exits>
c011cc6d sys_exit +<d/1c> (0.49) pid(161)
.....
c0117942 __mmdrop +<e/79> (0.60) pid(161)
c012db07 __free_pages_ok +<13/328> (6.85) pid(161)
c012c0b3 kmem_cache_free +<13/2fc> (2.22) pid(161->291)
c0109280 __switch_to +<10/c4> (0.72) pid(291)
semaphore.c:106 schedule();
semaphore.c:107 CHECK_ALLOC(sem); <CHECKPOINT: freed!>
c011829b printk +<13/16c> (0.92) pid(291)
Rabid Pointer at semaphore.c:107!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:16 EST