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
