Not if you use my 2.2 tree or any recent 2.4 out there. I mean that's
not an apache mistake, you shouldn't backout that change because of a
kernel race condition.
> i'm guessing from your description that the missed event will be noticed
> when the next socket arrives. i.e. if the server is pretty busy then the
yes, it will handle the missed connect only when the next connect
request arrives.
> missed events are not important. but if it's not a busy server, like a
> hit every hour, then the missed event may be noticeable to browsers (as a
> timeout waiting for server activity).
>
> does that pretty much sum it up?
I'm not sure what apache does exactly while handling new connections but
your above description of the sympthoms sounds ok.
> > Furthmore the exclusive wakeup logic with the exclusive information
> > per-task and not per wait_queue_t will screwup if the tasks registers
> > itself like a wakeall after it was just registered as wakeone somewhere
> > else (however this second thing is more a theorical issue that shouldn't
> > trigger in 2.2).
>
> i.e. if the socket was used both in accept() and in select() at the same
> time? (which apache doesn't do)
No because the same task cannot run accept() and select() at the same
time, that's a per-task vs per-waitqueue_t issue (not per-socket),
imagine it like accept() calling select() interally in the kernel, which
doesn't happen of course and that's why it cannot trigger in real life,
you cannot exploit it from userspace, it's a kernel internal issue. So
don't worry about it ;) My patch has the bonus to fix it as well though
(like 2.4).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/