On Tue, May 01, 2018 at 07:08:59PM +0200, Theo Buehler wrote:
> I tested this as well as I could, but I don't usually use IPv6, so I
> dabbled a bit with it on my home network and I tried to use the netinet6
> regress tests, only with moderate success.
>
> A test from people who actually use IPv6
On 01/05/18(Tue) 19:08, Theo Buehler wrote:
> On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote:
> > On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> > > With mpi's encouragement and guidance, here's a diff that reduces the
> > > scope of the NET_LOCK() a bit.
> > >
> > > in_control() i
looks reasonable to me.
OK
On Tue, May 01, 2018 at 07:08:59PM +0200, Theo Buehler wrote:
> On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote:
> > On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> > > With mpi's encouragement and guidance, here's a diff that reduces the
> > > scope of the
On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote:
> On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> > With mpi's encouragement and guidance, here's a diff that reduces the
> > scope of the NET_LOCK() a bit.
> >
> > in_control() is the only caller of mrt_ioctl() and the latter is a
> >
On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> With mpi's encouragement and guidance, here's a diff that reduces the
> scope of the NET_LOCK() a bit.
>
> in_control() is the only caller of mrt_ioctl() and the latter is a
> simple function only requiring a read lock.
>
> There are only a handful ca
With mpi's encouragement and guidance, here's a diff that reduces the
scope of the NET_LOCK() a bit.
in_control() is the only caller of mrt_ioctl() and the latter is a
simple function only requiring a read lock.
There are only a handful callers of in_ioctl(). The two switches create
relatively ta
