Date: Wed, 09 Oct 2002 16:07:45 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Stefan Farfeleder <e0026813@stud3.tuwien.ac.at> Cc: Don Lewis <dl-freebsd@catspoiler.org>, jhb@FreeBSD.ORG, jmallett@FreeBSD.ORG, current@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: [PATCH] Re: Junior Kernel Hacker page updated... Message-ID: <3DA4B6C1.ED1BACEB@mindspring.com> References: <20021008204605.GA252@frog.fafoe> <200210090426.g994QTvU037393@gw.catspoiler.org> <20021009225606.GC306@frog.fafoe>
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Farfeleder wrote: > Is it just a warning or does it pose a real problem? > > I think the problem with the current code is that knote_{en,de}queue can > be executed in parallel (on another CPU, spl*() can't prevent that, can > it?) with kqueue_scan and that kq->kq_head thus can be corrupted. > Or am I totally wrong? My patch would have worked, in that case, since it would ensure one marker entry with a unique stack address per simultaneous scanner. It has to be that the queue itself is being deleted out from under it: the problem is not the scan, nor the insert or the delete. Most likely, this is for an object whose queue is not tracked by process, or for a process queue that's being examined by another process (e.g. kevent's on fork/exit/etc.). You can verify this for your own satisfaction by looking at the pointer manipulation order for the insertion and deletion; the insertion sets the next pointer before setting the pointer to the inserted object, and the deletion sets the pointer that used to point to the deleted object to the delete object's next, before deleting the object. Thus, traversals in progress should not result in an error. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA4B6C1.ED1BACEB>