accept_filter, accf_http, setsockopt and the EINVAL error

[Sverre Froyen]

(1) It seems to me that adding the "httpready" filter a second time is
not really an error and I'm wondering if setsockopt could be modified to
silently ignore the second attempt.

I see the following code in kern/uipc_accf.c
/*
* Require a listen socket; don't try to replace an existing filter
* without first removing it.
*/
solock(so);
if ((so->so_options & SO_ACCEPTCONN) == 0 || so->so_accf != NULL) {
error = EINVAL;
goto out;
}
which seems to imply that the behaviour you see is purposeful.. does
FreeBSD allow implicit replacement of the filter?

FreeBSD's code is identical. Despite that fact, I've attached a patch that
makes setsockopt silently ignore the second call. Please note that I do not
allow replacing a filter with a different type, only adding the same type
twice.

Regards,

Sverre

[Thor Lancelot Simon]

Post by Sverre Froyen
FreeBSD's code is identical. Despite that fact, I've attached a patch that
makes setsockopt silently ignore the second call. Please note that I do not
allow replacing a filter with a different type, only adding the same type
twice.

If FreeBSD's code is identical, then Apache is broken, right? Why shouldn't
we just patch Apache in pkgsrc and feed the fix back to its maintainers?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Sverre Froyen]

Post by Thor Lancelot Simon

Post by Sverre Froyen
FreeBSD's code is identical. Despite that fact, I've attached a patch
that makes setsockopt silently ignore the second call. Please note that
I do not allow replacing a filter with a different type, only adding the
same type twice.

If FreeBSD's code is identical, then Apache is broken, right? Why
shouldn't we just patch Apache in pkgsrc and feed the fix back to its
maintainers?

That would be fine. My original message had a slightly different angle,
however. It was based on the following series of events:

I see the Apache warning in the log and I'm concerned that it means that
accept filters are not being used. I then look for EINVAL in the man page for
setsockopt. Nothing there, or in any of the accept filter man pages. I then
examine that Apache calls. They all look fine. Finally, tracing the calls
reveals the double calls to setsockopt and examining the kernel code shows
that the warning can be safely ignored.

I was looking for ways to get to that conclusion more easily. Updating the
man pages would help. Changing the kernel code means I would not even have
looked.

Regards,
Sverre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de