Stefan Farfeleder wrote:
> Imagine this scenario where CPU 0 inserts a knote kn1 (the marker) in
> knote_scan and CPU 1 kn2 in kqueue_enqueue:
>
> CPU 0 | CPU 1
> +---
> kn1->kn_tqe.tqe_next = NULL;
On Wed, Oct 09, 2002 at 04:07:45PM -0700, Terry Lambert wrote:
> 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 tha
On 10 Oct, Stefan Farfeleder wrote:
> On Tue, Oct 08, 2002 at 09:26:29PM -0700, Don Lewis wrote:
>> On 8 Oct, Stefan Farfeleder wrote:
>> > However, WITNESS complains (only once) about this:
>> > lock order reversal
>> > 1st 0xc662140c kqueue mutex (kqueue mutex) @
>/freebsd/current/src/sys/ke
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
On Tue, Oct 08, 2002 at 09:26:29PM -0700, Don Lewis wrote:
> On 8 Oct, Stefan Farfeleder wrote:
> > On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote:
>
> > Following the advice from the spl* man page I turned the spl* calls to a
> > mutex and was surprised to see it working. My SMP
On 8 Oct, Stefan Farfeleder wrote:
> On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote:
> Following the advice from the spl* man page I turned the spl* calls to a
> mutex and was surprised to see it working. My SMP -current survived a 'make
> -j16 buildworld' with make using kqueue()
On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote:
>
> *** OK, it's very hard to believe you didn't break into the
> *** debugger and manually call "pnaic" to get this to happen.
You're right, this is exactly what I did.
> I can't personally repeat the problem, so you're elected to
On Mon, 7 Oct 2002, Terry Lambert wrote:
> Stefan Farfeleder wrote:
> >
> > I'm confused why marker - if it was removed by TAILQ_REMOVE - hasn't
> > kn_tqe.tqe_next and kn_tqe.tqe_prev set to (void *)-1.
because that only happens if the debug code in queue.h is enabled, which
it is not..
>
Stefan Farfeleder wrote:
> On Sun, Oct 06, 2002 at 11:14:26PM -0700, Terry Lambert wrote:
> > Stefan: Did the patch fix it, or not?
>
> Sorry for the long delay. No, it did not. But I now have a rather
> interesting core dump. I inserted a KASSERT, so that the code looks like
> this:
>
> TAI
On Sun, Oct 06, 2002 at 11:14:26PM -0700, Terry Lambert wrote:
>
> Stefan: Did the patch fix it, or not?
Sorry for the long delay. No, it did not. But I now have a rather
interesting core dump. I inserted a KASSERT, so that the code looks like
this:
TAILQ_INSERT_TAIL(&kq->kq_head, &marker,
Terry Lambert wrote:
> Stefan Farfeleder wrote:
> > (kgdb) l *kqueue_scan+0x242
> > 0xc01a1212 is in kqueue_scan
> > (/freebsd/current/src/sys/kern/kern_event.c:716).
> > 713 TAILQ_INSERT_TAIL(&kq->kq_head, &marker, kn_tqe);
> > 714 while (count) {
> > 715
Stefan Farfeleder wrote:
> (kgdb) l *kqueue_scan+0x242
> 0xc01a1212 is in kqueue_scan
> (/freebsd/current/src/sys/kern/kern_event.c:716).
> 713 TAILQ_INSERT_TAIL(&kq->kq_head, &marker, kn_tqe);
> 714 while (count) {
> 715 kn = TAILQ_FIRST(&kq->kq_head);
12 matches
Mail list logo
