netdev - Re: [PATCH net 1/2] ipv4: igmp: use alarmtimer to prevent delayed reports

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:   Wed, 13 Jun 2018 19:02:59 +0530
From:   Tejaswi Tanikella <tejaswit@...eaurora.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com, davem@...emloft.net
Subject: Re: [PATCH net 1/2] ipv4: igmp: use alarmtimer to prevent delayed
 reports

On Tue, Jun 12, 2018 at 06:28:18PM +0200, Andrew Lunn wrote:
> On Mon, Jun 11, 2018 at 05:21:05PM +0530, Tejaswi Tanikella wrote:
> > 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.
> > 
> > Use a alarmtimer instead of using a timer. Alarmtimer will wake the
> > system up from suspend to send out the IGMP report.
> 
> Hi Tejaswi
> 
> I think i must be missing something here. If we are suspended, we are
> not receiving multicast frames. If we are not receiving frames, why do
> we need to reply to the query?
> 
> Once we resume, i expect we will reply to the next query. You could
> optimise restarting the flow by immediately sending a membership
> report, same as when the setsockopt is used to join the group.
> 
> 	Andrew

Hi Andrew,


I'll try to explain my scenario. This was observed on a arm64 device.
An application registers for a mcast group, and just listens to mcast
packets. The connection is setup and mcast packets are being forwarded
by the router. Multicast packets are sent out every few minutes.
Not a very busy connection.

After some time the router sends out a IGMPv2 query. The max delay in
the header is set to 10s. The system starts a timer to send out the
response at 9s. But the device suspends and wakes up after 60s.
The response is sent out 50s late.

ftrace logs with boottime trace_clock and my igmp_logs:

4740693      kworker/0:3-395   [000] ..s2  4716.425695: igmp_log: skbaddr=ffffffc156fe6600 daddr=224.0.0.1, id=0, rc=4295217721
4740694      kworker/0:3-395   [000] d.s4  4716.425717: timer_start:timer=ffffffc217763140 function=igmp_timer_expire expires=4295218678 [timeout=957] flags=0x00000000
        timer set for 9.57 seconds.  957 jiffies

< device suspends >

< wakes up after ~60s >
4781289           <idle>-0     [000] .ns2  4779.170886: timer_expire_entry: timer=ffffffc217763140 function=igmp_timer_expire now=4295218678
4781290           <idle>-0     [000] .ns2  4779.171045: igmp_log: skbaddr=ffffffc1559d0e00 daddr=227.226.228.225, id=0, rc=4295218678

Since the response was delayed, mcast packets are not forwarded by the
router.

My changes use a alarmtimer, this will wake the system up if the timer
expires.

Thanks,
Tejaswi