From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net] ipv4: igmp: hold wakelock to prevent delayed reports Date: Mon, 04 Jun 2018 11:06:40 -0400 (EDT) Message-ID: <20180604.110640.184022152967598302.davem@davemloft.net> References: <20180601140532.GA13253@tejaswit-linux.qualcomm.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: tejaswit@codeaurora.org Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:48134 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753742AbeFDPGl (ORCPT ); Mon, 4 Jun 2018 11:06:41 -0400 In-Reply-To: <20180601140532.GA13253@tejaswit-linux.qualcomm.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Tejaswi Tanikella Date: Fri, 1 Jun 2018 19:35:41 +0530 > On receiving a IGMPv2/v3 query, based on max_delay set in the header a > timer is started to send out a response after a random time within > max_delay. If the system then moves into suspend state, Report is > delayed until system wakes up. > > In one reported scenario, on arm64 devices, max_delay was set to 10s, > Reports were consistantly delayed if the timer is scheduled after 5 plus > seconds. > > Hold wakelock while starting the timer to prevent moving into suspend > state. > > Signed-off-by: Tejaswi Tanikella As Florian stated, this won't be the only networking facility to hit a problem like this. So, if we go down this route, we probably want to generically solve this. But I have a deeper concern. Do we really want every timer based querying mechanism to prevent a system from being able to suspend? We get to the point where external entities can generate traffic which can prevent a remote system from entering suspend state.