BSD Accept filters

[Dirk-Willem van Gulik <di...@covalent.net>]

I am getting more than a bit anoyed by the BSD accept filters; when you
have them in a binary; they are always on. And if the setsockopt()
fails things bomb wiht an exit(1).

Which is a bit of a pain if you move them between machines and/or have
kernels which (sometimes) do not have them plugged in.

What is the best strategy:

0	Change the 'exit' when the sockopt fails for SO_ACCEPTFILTER
	to a warning;.
1	Leave as is; but provide an AcceptFilter on/off directive
	to switch it off - if SO_ACCPETFILTER is defined.
2.	Have AcceptFitler on/off on all platforms; it is just a
	NOP unless SO_ACCEPTFILTER is defined. THis makes your
	config file more portable (as an <if core> module selector
	is not going to work).
3.	As '2' - but give a warning if someone sets it to 'on'
	on a platform which does not support it.

I think 0 or 2 is best. Opinions before I commit something ?

Dw

Re: BSD Accept filters

[dean gaudet <dg...@arctic.org>]

On Tue, 10 Jul 2001, Dirk-Willem van Gulik wrote:

> 0	Change the 'exit' when the sockopt fails for SO_ACCEPTFILTER
> 	to a warning;.
> 1	Leave as is; but provide an AcceptFilter on/off directive
> 	to switch it off - if SO_ACCPETFILTER is defined.
> 2.	Have AcceptFitler on/off on all platforms; it is just a
> 	NOP unless SO_ACCEPTFILTER is defined. THis makes your
> 	config file more portable (as an <if core> module selector
> 	is not going to work).
> 3.	As '2' - but give a warning if someone sets it to 'on'
> 	on a platform which does not support it.

3.

once "AcceptFilter" has support on linux, i think we will want an on/off
(default to on) because there's a possibility the current implementation
isn't up to snuff on large n-way SMP boxes, and those folks will want it
turned off.  (but i want the default "on" because that's better for most
people.)

i don't think failing to turn on the accept filter should be an error at
all.

-dean

Re: BSD Accept filters

[Dirk-Willem van Gulik <di...@covalent.net>]

> another 1.3 tree.  I didn't commit to 2.0, because I forgot.  :-(  The
> problem is that we are checking for the wrong errno when the setsockopt
> fails.  The errno we check for should never be returned by setsockopt.  If
> we change the errno to the correct one (I have to look at my patch),

Hmm - I found that to be a) inconsistent across the machines I have here;
and one specific machine actually kernel-panic's :-) (it is running a
CVS snapshot). For those cases it is still very usefull to be able to
switch it on/off at install/run time. (And not to mention if you want to
do quick comparisons).

So I've popped in a quick patch that scratches my itch. If you could
commit a patch to fix the error code check.  Though I may add that

       if (setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, &af, sizeof(af)) < 0
            && errno != ENOENT) {

is what freebsd gives back if it is not there. ENOPROTOOPT is what the
newer FreeBSD on -HEAD system gave me back I think. Or did I swap them.
Fix appreciared.

Dw

Re: BSD Accept filters

[rb...@covalent.net]

On Tue, 10 Jul 2001, Dirk-Willem van Gulik wrote:

>
> I am getting more than a bit anoyed by the BSD accept filters; when you
> have them in a binary; they are always on. And if the setsockopt()
> fails things bomb wiht an exit(1).
>
> Which is a bit of a pain if you move them between machines and/or have
> kernels which (sometimes) do not have them plugged in.
>
> What is the best strategy:
>
> 0	Change the 'exit' when the sockopt fails for SO_ACCEPTFILTER
> 	to a warning;.
> 1	Leave as is; but provide an AcceptFilter on/off directive
> 	to switch it off - if SO_ACCPETFILTER is defined.
> 2.	Have AcceptFitler on/off on all platforms; it is just a
> 	NOP unless SO_ACCEPTFILTER is defined. THis makes your
> 	config file more portable (as an <if core> module selector
> 	is not going to work).
> 3.	As '2' - but give a warning if someone sets it to 'on'
> 	on a platform which does not support it.
>
> I think 0 or 2 is best. Opinions before I commit something ?

I have a patch that fixes this already.  I didn't commit it to 1.3,
because I was under the impression that we weren't going to release
another 1.3 tree.  I didn't commit to 2.0, because I forgot.  :-(  The
problem is that we are checking for the wrong errno when the setsockopt
fails.  The errno we check for should never be returned by setsockopt.  If
we change the errno to the correct one (I have to look at my patch),
everything just works correctly.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------