On 10.12.15 23:02, Mark Johnston wrote:
>> some time ago Mark Johnston has published there the patch related to
>> this problem:
>> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html
>>
>> Maybe Mark has something to say about it.
>
> I started trying to push this work in wi
On Wed, Dec 09, 2015 at 11:45:46AM +0300, Andrey V. Elsukov wrote:
> On 08.12.15 08:32, Jason wrote:
> > Hi,
> >
> > It appears the IPv6 router advertisement code paths were written fairly
> > lockless, assuming you would never process multiples concurrently. We
> > are seeing multiple page fault
Word around town is Kubilay Kocak leaked this on Wed, Dec 09, 2015 at
09:02:48PM +1100:
> On 9/12/2015 7:58 PM, Andrey V. Elsukov wrote:
> > On 09.12.15 11:54, Kubilay Kocak wrote:
> >>> some time ago Mark Johnston has published there the patch related to
> >>> this problem:
> >>> https://lists.fr
On 9/12/2015 7:58 PM, Andrey V. Elsukov wrote:
> On 09.12.15 11:54, Kubilay Kocak wrote:
>>> some time ago Mark Johnston has published there the patch related to
>>> this problem:
>>> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html
>>>
>>> Maybe Mark has something to say a
On 09.12.15 11:54, Kubilay Kocak wrote:
>> some time ago Mark Johnston has published there the patch related to
>> this problem:
>> https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html
>>
>> Maybe Mark has something to say about it.
>>
>
> Is it worth creating an issue report
On 9/12/2015 7:45 PM, Andrey V. Elsukov wrote:
> On 08.12.15 08:32, Jason wrote:
>> Hi,
>>
>> It appears the IPv6 router advertisement code paths were written fairly
>> lockless, assuming you would never process multiples concurrently. We
>> are seeing multiple page faults in various places proces
On 08.12.15 08:32, Jason wrote:
> Hi,
>
> It appears the IPv6 router advertisement code paths were written fairly
> lockless, assuming you would never process multiples concurrently. We
> are seeing multiple page faults in various places processing the
> messages and modifying the routing table.
I believe I've found a way to reproduce this, simply an rtsol against 2
interfaces in isolated loops, which elicits a broadcasted RA. I am able
to deadlock the system fairly quickly, which finally results in a core
after __rw_wunlock_hard steps in. We have seen this deadlock in one
other case
Hi,
It appears the IPv6 router advertisement code paths were written fairly
lockless, assuming you would never process multiples concurrently. We
are seeing multiple page faults in various places processing the
messages and modifying the routing table. We have multiple L3 devices
and multip
