On Wed, Oct 21, 2015 at 2:19 PM, Florian Westphal wrote:
> Ani Sinha wrote:
>> >> > commit c6825c0976fa7893692e0e43b09740b419b23c09
>> >> > Author: Andrey Vagin
>> >> > Date: Wed Jan 29 19:34:14 2014 +0100
>> >> > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get
>> >> >
>> >
Ani Sinha wrote:
> >> > commit c6825c0976fa7893692e0e43b09740b419b23c09
> >> > Author: Andrey Vagin
> >> > Date: Wed Jan 29 19:34:14 2014 +0100
> >> > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get
> >> >
> >> > and a followup patch :
> >> >
> >> > commit e53376bef2cd97d3e3
On Sun, Oct 18, 2015 at 1:07 AM, Florian Westphal wrote:
> Ani Sinha wrote:
>> Coming back to this crash, I see something interesting in the
>> conntrack code in linux 3.4.109 (a supported kernel version). I see
>> that the hash table manipulations are protected by a spinlock. Also
>> lookups/rea
On Mon, Oct 19, 2015 at 1:33 PM, Florian Westphal wrote:
> Ani Sinha wrote:
>> On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal wrote:
>> > Ani Sinha wrote:
>> >> Indeed. So it seems to me that we have run into one another such case.
>> >> In patch c6825c0976fa7893692, I see we have added an a
Ani Sinha wrote:
> On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal wrote:
> > Ani Sinha wrote:
> >> Indeed. So it seems to me that we have run into one another such case.
> >> In patch c6825c0976fa7893692, I see we have added an additional check
> >> (along with comparing tuple and zone) to v
On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal wrote:
> Ani Sinha wrote:
>> Indeed. So it seems to me that we have run into one another such case.
>> In patch c6825c0976fa7893692, I see we have added an additional check (along
>> with comparing tuple and zone) to verify that if the conntrack
Ani Sinha wrote:
> Indeed. So it seems to me that we have run into one another such case.
> In patch c6825c0976fa7893692, I see we have added an additional check (along
> with comparing tuple and zone) to verify that if the conntrack is confirmed.
>
> + return nf_ct_tuple_equal(tuple, &h-
>
> On Sun, Oct 18, 2015 at 1:07 AM, Florian Westphal wrote:
> > Ani Sinha wrote:
> >> Coming back to this crash, I see something interesting in the
> >> conntrack code in linux 3.4.109 (a supported kernel version). I see
> >> that the hash table manipulations are protected by a spinlock. Also
Ani Sinha wrote:
> Coming back to this crash, I see something interesting in the
> conntrack code in linux 3.4.109 (a supported kernel version). I see
> that the hash table manipulations are protected by a spinlock. Also
> lookups/reads are protected by RCU. However allocation and
> deallocation o
Hi guys,
Coming back to this crash, I see something interesting in the
conntrack code in linux 3.4.109 (a supported kernel version). I see
that the hash table manipulations are protected by a spinlock. Also
lookups/reads are protected by RCU. However allocation and
deallocation of conntrack object
Hi guys :
We encountered a kernel crash on one of our boxes running 3.4.43
kernel in the conntrack code. We are using dnsmasq as a proxy to relay
our dns requests to the real dns server. We verified that the
conntrack tables were not full. running conntrack -L around the time
of the crash showed t
11 matches
Mail list logo
