[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+arcDq=-kDn=y6oRFRSMApKKA7GrfAg_svTtLOVnnaVDA@mail.gmail.com>
Date: Tue, 3 Nov 2015 09:48:22 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: syzkaller <syzkaller@...glegroups.com>
Cc: David Miller <davem@...emloft.net>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Al Viro <viro@...iv.linux.org.uk>, Thomas Graf <tgraf@...g.ch>,
Cong Wang <xiyou.wangcong@...il.com>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>, jmorris@...ei.org,
yoshfuji@...ux-ipv6.org, Patrick McHardy <kaber@...sh.net>,
Kostya Serebryany <kcc@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Eric Dumazet <edumazet@...gle.com>,
Kees Cook <keescook@...gle.com>,
Julien Tinnes <jln@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: Resource leak in unshare
On Mon, Nov 2, 2015 at 8:01 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Dmitry Vyukov <dvyukov@...gle.com> writes:
>
>> Hello,
>>
>> I am hitting the following warnings on
>> bcee19f424a0d8c26ecf2607b73c690802658b29 (4.3):
>
> Do you have any trace of the earlier failures?
>
> This appears to be something caused by an earlier failure (possibly
> whatever fails to allocate memory). Having network devices present
> but being in the generic cleanup routines is wrong.
>
> If there is no additional information can you please rerun with the
> following change applied? That should at least report which function is
> failing, and give us a good clue where to start debugging this.
So is it all fixed now? Or it is still clear how it can happen?
Eric (Dumazet), do you see how the WARNING can fire?
I don't have any logs at the moment, but I can run fuzzer for longer
to reproduce it again if necessary.
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 2c2eb1b629b1..125c94af22b8 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -292,6 +292,7 @@ out:
> return error;
>
> out_undo:
> + WARN(1, "net ops->init %pF returned with %d\n", ops->init, error);
> /* Walk through the list backwards calling the exit functions
> * for the pernet modules whose init functions did not fail.
> */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists