On Fri, Dec 12, 2003 at 08:10:09PM +0000, Jonathan Sambrook wrote:
Hi Jonathan!
> > I totally agree that uts_sem isn't the apropriate
> > to use in this place(s), but I don't see how this
> > could cause a deadlock/panic as there is nothing
> > to lock/panic if the rw sem is held for write ...
>
> Neither do I, but the call from exit.c seems to lock.
>
> > please correct me if you see any crash/lock condition
> > there ...
>
> My machines running with these write locks replaced
> by a spinlock have been up for over two days now,
> instead of less than a minute. No other changes!
okay, after Rik opened my eyes (I was too blind
to look beyond the affected code), I now can confirm
that this actually fixes a bug (race).
for those interested:
-> vc_new_s_context {tasklist_lock[r]}
-> vx_assign_info
so vc_new_s_context() is holding the tasklist_lock
and vx_assign_info() might sleep on the uts_sem.
another bugfix release (vs1.22) will be there soon
> > what would be interesting is, how does vs1.3.0
> > behave in your tests, as it replaced the allocation
> > scheme completely (so no assign/alloc and no rw
> > uts_sem to fix ;)
>
> Yes. Will examine on Monday.
> But need to go live on some reall machines soon too...
would be still interesting to have that stuff tested
as the locking is quite different ...
thanks for spotting/fixing this,
Herbert
> Cheers,
> Jonathan
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
