netdev - Re: unregister_netdevice warnings when deleting netns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGGTERkduFPmoiRJ+oUQ02kXe+dbOW=5e9W3f71=9hTjG_amVA@mail.gmail.com>
Date:	Tue, 29 Sep 2015 21:42:57 +0530
From:	Anand Gurram <anandarao.gurram@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Julian Anastasov <ja@....bg>, NETDEV <netdev@...r.kernel.org>
Subject: Re: unregister_netdevice warnings when deleting netns

Hi Julian and Eric

I tried both the patches which you have suggested, the issue is still
seen, I am observing same warning message thrown on the console
  "unregister_netdevice: waiting for lo to become free. Usage count = 1".

>Sometimes people have addressed this class of issue with code review,
>but with a slow cleanup you can't catch this by finding a missing
>dev_put.

Yeah, currently since slow cleanup is happening I am unable to trace
just by having count for dev_hold and dev_put.

Actually at the time of tearing down the name space there is an active
TCP connection present.
When this TCP connection is not present then we are not seeing this issue.

Any additional ideas and suggestions on debugging in above scenario?

Best Regards,
Anand

On Tue, Sep 29, 2015 at 12:14 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Anand Gurram <anandarao.gurram@...il.com> writes:
>
>>>If the message just spits out a few times and then goes away it simply
>>>means that something is taking a while to cleanup and drop it's
>>>reference.
>>
>> The message just spits out few times and then goes away, I am trying
>> to debug why cleanup is taking long,
>> and where it is still referenced. Any pointers in debugging such
>> issues will be of great help.
>
> The one thing I have done in the past is to instrument dev_hold
> and dev_put and look where in the code the stragglers are coming from
> (when I can reproduce the issue reliably).
>
> Sometimes people have addressed this class of issue with code review,
> but with a slow cleanup you can't catch this by finding a missing
> dev_put.
>
> It takes some creativity to find these as people rarely make the same
> mistake twice.
>
> Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html