Christian S.J. Peron wrote:
Group,
I've come up with a basic patch, here are the highlights as per our discussion:
- Check for the presence of socket options, if they are present duplicate
them using m_dup(9)
- Drop the INP/INFO locks after duplication
- Activate ip_output() with the cloned m
Christian S.J. Peron wrote:
Group,
I've come up with a basic patch, here are the highlights as per our discussion:
- Check for the presence of socket options, if they are present duplicate
them using m_dup(9)
- Drop the INP/INFO locks after duplication
- Activate ip_output() with the cloned m
Group,
I've come up with a basic patch, here are the highlights as per our discussion:
- Check for the presence of socket options, if they are present duplicate
them using m_dup(9)
- Drop the INP/INFO locks after duplication
- Activate ip_output() with the cloned mbuf (for socket options). Als
Christian S.J. Peron wrote:
Well, it's still the intent to keep the ability to divert and re-inject
multicast packets. This change would basically say: "You cant specify
multicast options via the divert socket". Which in practice doesn't
happen anyway (where I looked).
I dont think we should be
Christian S.J. Peron wrote:
On Tue, Jul 31, 2007 at 04:22:41PM -0700, Julian Elischer wrote:
[..]
Originally we wanted a way to be able to inject any kind of
ip packet that could be generated, because the aim was to
allow a user agent to do arbitrary processing on packets. however
to be really
On Tue, Jul 31, 2007 at 04:22:41PM -0700, Julian Elischer wrote:
[..]
>
> Originally we wanted a way to be able to inject any kind of
> ip packet that could be generated, because the aim was to
> allow a user agent to do arbitrary processing on packets. however
> to be really correct, a divert i
Bruce M. Simpson wrote:
Christian S.J. Peron wrote:
I can't think of a reason why a user would wish to supply any
multicast socket options to a divert socket, other than the 'small'
ones, i.e. IP_MULTICAST_TTL/IF/LOOP/VIF.
Why would these options ever be set on the divert socket itself t
Christian S.J. Peron wrote:
I can't think of a reason why a user would wish to supply any multicast
socket options to a divert socket, other than the 'small' ones, i.e.
IP_MULTICAST_TTL/IF/LOOP/VIF.
Why would these options ever be set on the divert socket itself though?
To me it would mak
On Tue, Jul 31, 2007 at 07:24:23PM +0100, Bruce M. Simpson wrote:
[..]
>
> The LOR is obviously being triggered by ip_output()'s acquisition of
> in_multi_mtx, due to a datagram being sent to a multicast destination
> and a subsequent lookup being required.
>
This makes sense.
> I can't think
Christian S.J. Peron wrote:
...
One idea was to duplicate the socket options mbuf and pass in a NULL pointer
for the multi-cast options. Keep in mind that these are multicast options
associated with a divert socket.
So I guess the questions:
(1) Are there any users that are specifying multicas
Christian S.J. Peron wrote:
Group,
Robert Watson and I have been discussing some of the consequences around not
having Giant picked up in the network stack for mpsafenet=0. One of the
issues that kept coming up was a number of lock ordering issues around divert:
Upon quick inspection I found:
11 matches
Mail list logo
