Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Aug 2008 21:42:00 +0200
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        "Bruce M. Simpson" <bms@freebsd.org>
Cc:        gnn@freebsd.org, net@freebsd.org
Subject:   Re: Small patch to multicast code...
Message-ID:  <20080822194200.GC63527@onelab2.iet.unipi.it>
In-Reply-To: <48AF08B7.4090804@FreeBSD.org>
References:  <m27iaa6v43.wl%gnn@neville-neil.com> <20080821203519.GA51534@onelab2.iet.unipi.it> <m23aky6ncl.wl%gnn@neville-neil.com> <48AE23FF.9070009@FreeBSD.org> <m2tzdd6j36.wl%gnn@neville-neil.com> <48AF08B7.4090804@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
> gnn@FreeBSD.org wrote:
> >I gather you mean that a fast link on which also we're looping back
> >the packet will be an issue?  Since this packet is only going into the
> >simloop() routine.
> >  
> 
> We end up calling if_simloop() from a few "interesting" places, in 
> particular the kernel PIM packet handler.
> 
> In this particular case we're going to take a full mbuf chain copy every 
> time we send a packet which needs to be looped back to userland.
...
> In the case of ip_mloopback(), somehow we are stomping on a read-only 
> copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine 
> according to the documented uses of mbuf(9), although as Luigi pointed 
> out, most likely we need to look at the upper-layer protocol too, e.g. 
> where UDP checksums are also being offloaded.

in fact, george, if you have an easy way to reproduce the error,
could you see if reverting your change and instead adding
sizeof(struct udphdr) to the length argument in the call to m_pullup()
fixes the problem ?

	cheers
	luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080822194200.GC63527>