aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/atm
diff options
context:
space:
mode:
authorDaniel Borkmann <dborkman@redhat.com>2013-08-29 23:55:05 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-09-14 05:50:48 -0700
commit238d6ce5d070b4f95a3deeaf979d8c7e30d7de5d (patch)
treecc58971b5347a201b6e5da70d93ae5c23eb03341 /drivers/atm
parent6ca04e8fc4c799a55b011d489b71a5732a9ae8dd (diff)
downloadkernel_samsung_espresso10-238d6ce5d070b4f95a3deeaf979d8c7e30d7de5d.zip
kernel_samsung_espresso10-238d6ce5d070b4f95a3deeaf979d8c7e30d7de5d.tar.gz
kernel_samsung_espresso10-238d6ce5d070b4f95a3deeaf979d8c7e30d7de5d.tar.bz2
net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay
[ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ] While looking into MLDv1/v2 code, I noticed that bridging code does not convert it's max delay into jiffies for MLDv2 messages as we do in core IPv6' multicast code. RFC3810, 5.1.3. Maximum Response Code says: The Maximum Response Code field specifies the maximum time allowed before sending a responding Report. The actual time allowed, called the Maximum Response Delay, is represented in units of milliseconds, and is derived from the Maximum Response Code as follows: [...] As we update timers that work with jiffies, we need to convert it. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Cc: Linus Lüssing <linus.luessing@web.de> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/atm')
0 files changed, 0 insertions, 0 deletions