From: Nikolay Aleksandrov
Date: Wed, 31 Jan 2018 16:29:30 +0200
> When we dump the ip6mr mfc entries via proc, we initialize an iterator
> with the table to dump but we don't clear the cache pointer which might
> be initialized from a prior read on the same descriptor that ended. This
> can resul
From: Dmitry Vyukov
Date: Wed, 31 Jan 2018 15:49:15 +0100
> Don't we need to Cc stable 2.6 in this case or something like this. We
> want it to be backported.
Networking changes do not CC: stable.
Please read the netdev FAQ, thank you.
On Wed, Jan 31, 2018 at 3:52 PM, Nikolay Aleksandrov
wrote:
> On 31/01/18 16:49, Dmitry Vyukov wrote:
>> On Wed, Jan 31, 2018 at 3:29 PM, Nikolay Aleksandrov
>> wrote:
>>> When we dump the ip6mr mfc entries via proc, we initialize an iterator
>>> with the table to dump but we don't clear the cach
On 31/01/18 16:49, Dmitry Vyukov wrote:
> On Wed, Jan 31, 2018 at 3:29 PM, Nikolay Aleksandrov
> wrote:
>> When we dump the ip6mr mfc entries via proc, we initialize an iterator
>> with the table to dump but we don't clear the cache pointer which might
>> be initialized from a prior read on the sa
On Wed, Jan 31, 2018 at 3:29 PM, Nikolay Aleksandrov
wrote:
> When we dump the ip6mr mfc entries via proc, we initialize an iterator
> with the table to dump but we don't clear the cache pointer which might
> be initialized from a prior read on the same descriptor that ended. This
> can result in
When we dump the ip6mr mfc entries via proc, we initialize an iterator
with the table to dump but we don't clear the cache pointer which might
be initialized from a prior read on the same descriptor that ended. This
can result in lock imbalance (an unnecessary unlock) leading to other
crashes and h
