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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ