netdev - Re: 'iw events' stops receiving events after a while on 4.9 + hacks

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: <fa96dfad-8d1b-c48f-df3b-3df0d548a5c6@candelatech.com>
Date:   Wed, 17 May 2017 08:22:40 -0700
From:   Ben Greear <greearb@...delatech.com>
To:     Johannes Berg <johannes@...solutions.net>,
        Bastian Bittorf <bb@....de>
Cc:     netdev <netdev@...r.kernel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: Re: 'iw events' stops receiving events after a while on 4.9 + hacks

On 05/17/2017 06:30 AM, Johannes Berg wrote:
> On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
>> * Ben Greear <greearb@...delatech.com> [17.05.2017 11:51]:
>>> I have been keeping an 'iw events' program running with a perl
>>> script gathering its
>>> output and post-processing it.  This has been working for several
>>> years on 4.7 and earlier
>>> kernels, but when testing on 4.9 overnight, I notice that 'iw
>>> events' is not showing any input.  'strace' shows
>>> that it is waiting on recvmsg.  If I start a second 'iw events'
>>> then it will get
>>> wifi events as expected.
>>
>> me too, also seen on 4.4 - i'am happy for debug ideas.
>
> I've never seen this.
>
> Does it happen when it's very long-running? Or when there are lots of
> events?
>
> Perhaps something in the socket buffer accounting is going wrong, so
> that it's slowly decreasing to 0?

I saw it exactly once so far, and it happened overnight,
but we have not been doing a lot of work with the 4.9 kernel until recently.

I don't think there were many messages on this system, and certainly
others have run much longer on systems that should be generating many more
events without trouble.

Is there any way to dump out the socket information if we reproduce
the problem?

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com