On Tue, Jan 9, 2018 at 10:21 AM, Ben Hutchings
wrote:
> Commit 15e668070a64 reordered the initialisation in inet6_init() to
> fix a crash on an error path further down the call stack. It also
> reordered cleanup on the error path in inet6_init(), but the result
> is not the reverse of the initial
On Thu, Jan 11, 2018 at 8:48 AM, Ben Hutchings
wrote:
> On Wed, 2018-01-10 at 14:25 -0800, Cong Wang wrote:
>> On Tue, Jan 9, 2018 at 10:21 AM, Ben Hutchings
>> wrote:
>> > Commit 15e668070a64 reordered the initialisation in inet6_init() to
>> > fix a crash on an error path further down the call
On Wed, 2018-01-10 at 14:25 -0800, Cong Wang wrote:
> On Tue, Jan 9, 2018 at 10:21 AM, Ben Hutchings
> wrote:
> > Commit 15e668070a64 reordered the initialisation in inet6_init() to
> > fix a crash on an error path further down the call stack. It also
> > reordered cleanup on the error path in in
On Tue, Jan 9, 2018 at 10:21 AM, Ben Hutchings
wrote:
> Commit 15e668070a64 reordered the initialisation in inet6_init() to
> fix a crash on an error path further down the call stack. It also
> reordered cleanup on the error path in inet6_init(), but the result
> is not the reverse of the initial
Commit 15e668070a64 reordered the initialisation in inet6_init() to
fix a crash on an error path further down the call stack. It also
reordered cleanup on the error path in inet6_init(), but the result
is not the reverse of the initialisation order. This presumably
can result in a resource leak o
