1. 14 2月, 2011 2 次提交
  2. 26 1月, 2011 1 次提交
  3. 25 1月, 2011 2 次提交
  4. 21 1月, 2011 1 次提交
    • N
      bonding: Ensure that we unshare skbs prior to calling pskb_may_pull · b3053251
      Neil Horman 提交于
      Recently reported oops:
      
      kernel BUG at net/core/skbuff.c:813!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/devices/virtual/net/bond0/broadcast
      CPU 8
      Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
      ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
      i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
      ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas dm_mod [last unloaded: microcode]
      
      Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
      ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
      i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
      ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas dm_mod [last unloaded: microcode]
      Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22
      -[7870AC1]-
      RIP: 0010:[<ffffffff81405b16>]  [<ffffffff81405b16>]
      pskb_expand_head+0x36/0x1e0
      RSP: 0018:ffff880028303b70  EFLAGS: 00010202
      RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80
      RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64
      R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000
      R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0)
      Stack:
       ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000
      <0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00
      <0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a
      Call Trace:
      <IRQ>
       [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90
       [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360
       [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding]
       [<ffffffff814a0857>] ? packet_rcv+0x377/0x440
       [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670
       [<ffffffff8140f788>] napi_skb_finish+0x58/0x70
       [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50
       [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe]
       [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe]
       [<ffffffff8140fe53>] net_rx_action+0x103/0x210
       [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0
       [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170
       [<ffffffff810142cc>] call_softirq+0x1c/0x30
       [<ffffffff81015f35>] do_softirq+0x65/0xa0
       [<ffffffff810739d5>] irq_exit+0x85/0x90
       [<ffffffff814cf915>] do_IRQ+0x75/0xf0
       [<ffffffff81013ad3>] ret_from_intr+0x0/0x11
       <EOI>
       [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0
       [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20
       [<ffffffff81011e96>] cpu_idle+0xb6/0x110
       [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f
      
      Resulted from bonding driver registering packet handlers via dev_add_pack and
      then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET
      sockets) gets called first, the delivered skb will have a user count > 1, which
      causes pskb_may_pull to BUG halt when it does its skb_shared check.  Fix this by
      calling skb_share_check prior to the may_pull call sites in the bonding driver
      to clone the skb when needed.  Tested by myself and the reported successfully.
      
      Signed-off-by: Neil Horman
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3053251
  5. 11 1月, 2011 1 次提交
  6. 17 12月, 2010 6 次提交
  7. 11 12月, 2010 1 次提交
  8. 10 12月, 2010 1 次提交
    • N
      net: Convert netpoll blocking api in bonding driver to be a counter · fb4fa76a
      Neil Horman 提交于
      A while back I made some changes to enable netpoll in the bonding driver.  Among
      them was a per-cpu flag that indicated we were in a path that held locks which
      could cause the netpoll path to block in during tx, and as such the tx path
      should queue the frame for later use.  This appears to have given rise to a
      regression.  If one of those paths on which we hold the per-cpu flag yields the
      cpu, its possible for us to come back on a different cpu, leading to us clearing
      a different flag than we set.  This results in odd netpoll drops, and BUG
      backtraces appearing in the log, as we check to make sure that we only clear set
      bits, and only set clear bits.  I had though briefly about changing the
      offending paths so that they wouldn't sleep, but looking at my origional work
      more closely, it doesn't appear that a per-cpu flag is warranted.  We alrady
      gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
      normal tx case anyway.  And practically speaking, the normal use case for
      netpoll is to only have one client anyway, so we're not going to erroneously
      queue netpoll frames when its actually safe to do so.  As such, lets just
      convert that per-cpu flag to an atomic counter.  It fixes the rescheduling bugs,
      is equivalent from a performance perspective and actually eliminates some code
      in the process.
      
      Tested by the reporter and myself, successfully
      Reported-by: NLiang Zheng <lzheng@redhat.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb4fa76a
  9. 02 12月, 2010 1 次提交
  10. 19 11月, 2010 2 次提交
  11. 18 11月, 2010 1 次提交
  12. 09 11月, 2010 1 次提交
  13. 02 11月, 2010 1 次提交
  14. 28 10月, 2010 1 次提交
    • J
      bonding: Fix lockdep warning after bond_vlan_rx_register() · a71fb881
      Jarek Poplawski 提交于
      Fix lockdep warning:
      [   52.991402] ======================================================
      [   52.991511] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      [   52.991569] 2.6.36-04573-g4b60626-dirty #65
      [   52.991622] ------------------------------------------------------
      [   52.991696] ip/4842 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:
      [   52.991758]  (&bond->lock){++++..}, at: [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding]
      [   52.991966]
      [   52.991967] and this task is already holding:
      [   52.992008]  (&bonding_netdev_addr_lock_key){+.....}, at: [<c04e5530>] dev_mc_sync+0x50/0xa0
      [   52.992008] which would create a new lock dependency:
      [   52.992008]  (&bonding_netdev_addr_lock_key){+.....} -> (&bond->lock){++++..}
      [   52.992008]
      [   52.992008] but this new dependency connects a SOFTIRQ-irq-safe lock:
      [   52.992008]  (&(&mc->mca_lock)->rlock){+.-...}
      [   52.992008] ... which became SOFTIRQ-irq-safe at:
      [   52.992008]   [<c0272beb>] __lock_acquire+0x96b/0x1960
      [   52.992008]   [<c027415e>] lock_acquire+0x7e/0xf0
      [   52.992008]   [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
      [   52.992008]   [<c0584e40>] mld_ifc_timer_expire+0xf0/0x280
      [   52.992008]   [<c024cee6>] run_timer_softirq+0x146/0x310
      [   52.992008]   [<c024591d>] __do_softirq+0xad/0x1c0
      [   52.992008]
      [   52.992008] to a SOFTIRQ-irq-unsafe lock:
      [   52.992008]  (&bond->lock){++++..}
      [   52.992008] ... which became SOFTIRQ-irq-unsafe at:
      [   52.992008] ...  [<c0272c3b>] __lock_acquire+0x9bb/0x1960
      [   52.992008]   [<c027415e>] lock_acquire+0x7e/0xf0
      [   52.992008]   [<c05f36b8>] _raw_write_lock+0x38/0x50
      [   52.992008]   [<efe4cbe4>] bond_vlan_rx_register+0x24/0x70 [bonding]
      [   52.992008]   [<c0598010>] register_vlan_dev+0xc0/0x280
      [   52.992008]   [<c0599f3a>] vlan_newlink+0xaa/0xd0
      [   52.992008]   [<c04ed4b4>] rtnl_newlink+0x404/0x490
      [   52.992008]   [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
      [   52.992008]   [<c050424e>] netlink_rcv_skb+0x8e/0xb0
      [   52.992008]   [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
      [   52.992008]   [<c0503bfb>] netlink_unicast+0x24b/0x290
      [   52.992008]   [<c0503e37>] netlink_sendmsg+0x1f7/0x310
      [   52.992008]   [<c04cd41c>] sock_sendmsg+0xac/0xe0
      [   52.992008]   [<c04ceb80>] sys_sendmsg+0x130/0x230
      [   52.992008]   [<c04cf04e>] sys_socketcall+0xde/0x280
      [   52.992008]   [<c0202d10>] sysenter_do_call+0x12/0x36
      [   52.992008]
      [   52.992008] other info that might help us debug this:
      ...
      [ Full info at netdev: Wed, 27 Oct 2010 12:24:30 +0200
        Subject: [BUG net-2.6 vlan/bonding] lockdep splats ]
      
      Use BH variant of write_lock(&bond->lock) (as elsewhere in bond_main)
      to prevent this dependency.
      
      Fixes commit f35188fa [v2.6.36]
      Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      a71fb881
  15. 21 10月, 2010 4 次提交
  16. 20 10月, 2010 1 次提交
    • N
      netpoll: Remove netpoll blocking from uninit path · 9ff76c95
      Neil Horman 提交于
      Some recent testing in netpoll with bonding showed this backtrace
      
       ------------[ cut here ]------------
       kernel BUG at drivers/net/bonding/bonding.h:134!
       invalid opcode: 0000 [#1] SMP
       last sysfs file: /sys/devices/pci0000:00/0000:00:1d.2/usb7/devnum
       CPU 0
       Pid: 1876, comm: rmmod Not tainted 2.6.36-rc3+ #10 D26928/
       RIP: 0010:[<ffffffffa0514ba4>]  [<ffffffffa0514ba4>] bond_uninit+0x6f4/0x7a0
       RSP: 0018:ffff88003b1b5d58  EFLAGS: 00010296
       RAX: ffff88003b9b6200 RBX: ffff8800373e8e00 RCX: 00000000000f4240
       RDX: 00000000ffffffff RSI: 0000000000000286 RDI: 0000000000000286
       RBP: ffff88003b1b5dc8 R08: 0000000000000000 R09: 00000001af7de920
       R10: 0000000000000000 R11: ffff880002495e98 R12: ffff880037922700
       R13: ffff880038c31000 R14: ffff880037922730 R15: 0000000000000286
       FS:  00007f90e6d72700(0000) GS:ffff880002400000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 000000346f0d9ad0 CR3: 000000003b263000 CR4: 00000000000006f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Process rmmod (pid: 1876, threadinfo ffff88003b1b4000, task ffff88003b36aa80)
       Stack:
       00000000ffffffff ffff88003b1b5d7a ffff8800379221e8 ffff880037922000
       <0> ffff88003b1b5dc8 ffffffff813eb5fb ffff88003b1b5da8 0000000031b177a3
       <0> ffff88003b1b5da8 ffff880037922000 ffff88003b1b5e48 ffff88003b1b5e48
       Call Trace:
       [<ffffffff813eb5fb>] ? rtmsg_ifinfo+0xcb/0xf0
       [<ffffffff813daad8>] rollback_registered_many+0x168/0x280
       [<ffffffff813dac09>] unregister_netdevice_many+0x19/0x80
       [<ffffffff813e97b3>] __rtnl_kill_links+0x63/0x90
       [<ffffffff813e980b>] __rtnl_link_unregister+0x2b/0x60
       [<ffffffff813e9bde>] rtnl_link_unregister+0x1e/0x30
       [<ffffffffa052124b>] bonding_exit+0x37/0x51 [bonding]
       [<ffffffff81098b2e>] sys_delete_module+0x19e/0x270
       [<ffffffff810bb2b2>] ? audit_syscall_entry+0x252/0x280
       [<ffffffff8100b0b2>] system_call_fastpath+0x16/0x1b
       RIP  [<ffffffffa0514ba4>] bond_uninit+0x6f4/0x7a0 [bonding]
       RSP <ffff88003b1b5d58>
       ---[ end trace 1395ad691cea24d1 ]---
      
      It occurs because of my recent netpoll blocking patches, which I added to avoid
      recursive deadlock in the bonding driver.  It relies on some per cpu bits, but
      the shutdown path forces some rescheduling as we cancel workqueues for the
      driver and wait for some device refcounts.  If after the forced reschedule, we
      wind up on a different cpu we trigger the bughalt in unblock_netpoll_tx.
      
      The fix is to remove the netpoll block/unblock calls from bond_release_all.
      This is safe to do because bond_uninit, which is called via ndo_uninit in
      rollback_registered_many, doesn't occur until we send a NETDEV_UNREGISTER event,
      which triggers netconsole to remove us as a netpoll client, so we are guaranteed
      not to recurse into our own tx path here.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reviewed-by: NWANG Cong <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ff76c95
  17. 18 10月, 2010 3 次提交
    • N
      bonding: Re-enable netpoll over bonding · 45b0cb8a
      Neil Horman 提交于
      With the inclusion of previous fixup patches, netpoll over bonding apears to
      work reliably with failover conditions.  This reverts Gospos previous commit
      c22d7ac8, and allows access again to the netpoll
      functionality in the bonding driver.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45b0cb8a
    • N
      bonding: Fix deadlock in bonding driver resulting from internal locking when using netpoll · e843fa50
      Neil Horman 提交于
      The monitoring paths in the bonding driver take write locks that are shared by
      the tx path.  If netconsole is in use, these paths can call printk which puts us
      in the netpoll tx path, which, if netconsole is attached to the bonding driver,
      result in deadlock (the xmit_lock guards are useless in netpoll_send_skb, as the
      monitor paths in the bonding driver don't claim the xmit_lock, nor should they).
      The solution is to use a per cpu flag internal to the driver to indicate when a
      cpu is holding the lock in a path that might recusrse into the tx path for the
      driver via netconsole.  By checking this flag on transmit, we can defer the
      sending of the netconsole frames until a later time using the retransmit feature
      of netpoll_send_skb that is triggered on the return code NETDEV_TX_BUSY.  I've
      tested this and am able to transmit via netconsole while causing failover
      conditions on the bond slave links.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e843fa50
    • N
      bonding: Fix bonding drivers improper modification of netpoll structure · c2355e1a
      Neil Horman 提交于
      The bonding driver currently modifies the netpoll structure in its xmit path
      while sending frames from netpoll.  This is racy, as other cpus can access the
      netpoll structure in parallel. Since the bonding driver points np->dev to a
      slave device, other cpus can inadvertently attempt to send data directly to
      slave devices, leading to improper locking with the bonding master, lost frames,
      and deadlocks.  This patch fixes that up.
      
      This patch also removes the real_dev pointer from the netpoll structure as that
      data is really only used by bonding in the poll_controller, and we can emulate
      its behavior by check each slave for IS_UP.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2355e1a
  18. 07 10月, 2010 3 次提交
  19. 06 10月, 2010 3 次提交
    • F
      bonding: add retransmit membership reports tunable · c2952c31
      Flavio Leitner 提交于
      Allow sysadmins to configure the number of multicast
      membership report sent on a link failure event.
      Signed-off-by: NFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2952c31
    • F
      bonding: rejoin multicast groups on VLANs · 5a37e8ca
      Flavio Leitner 提交于
      During a failover, the IGMP membership is sent to update
      the switch restoring the traffic, but it misses groups added
      to VLAN devices running on top of bonding devices.
      
      This patch changes it to iterate over all VLAN devices
      on top of it sending IGMP memberships too.
      Signed-off-by: NFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a37e8ca
    • N
      bonding: fix WARN_ON when writing to bond_master sysfs file · 27e6f065
      Neil Horman 提交于
      Fix a WARN_ON failure in bond_masters sysfs file
      
      Got a report of this warning recently
      
      bonding: bond0 is being created...
      ------------[ cut here ]------------
      WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
      Hardware name: ProLiant BL465c G1
      proc_dir_entry 'bonding/bond0' already registered
      Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
      ipmi_si
      ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
      cc
      iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
      scsi_wai
      t_scan]
      Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
      Call Trace:
      [<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
      [<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
      [<ffffffff8114bf0b>] proc_register+0x14d/0x185
      [<ffffffff8114c20c>] proc_create_data+0x87/0xa1
      [<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
      [<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
      [<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
      [<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
      [<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
      [<ffffffff812aec85>] class_attr_store+0x27/0x29
      [<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
      [<ffffffff81101acf>] vfs_write+0xa9/0x106
      [<ffffffff81101be2>] sys_write+0x45/0x69
      [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
      ---[ end trace a677c3f7f8b16b1e ]---
      bonding: Bond creation failed.
      
      It happens because a user space writer to bond_master can try to
      register an already existing bond interface name.  Fix it by teaching
      bond_create to check for the existance of devices with that name first
      in cases where a non-NULL name parameter has been passed in
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27e6f065
  20. 27 9月, 2010 1 次提交
  21. 18 9月, 2010 1 次提交
  22. 15 9月, 2010 1 次提交
    • A
      bonding: correctly process non-linear skbs · ab12811c
      Andy Gospodarek 提交于
      It was recently brought to my attention that 802.3ad mode bonds would no
      longer form when using some network hardware after a driver update.
      After snooping around I realized that the particular hardware was using
      page-based skbs and found that skb->data did not contain a valid LACPDU
      as it was not stored there.  That explained the inability to form an
      802.3ad-based bond.  For balance-alb mode bonds this was also an issue
      as ARPs would not be properly processed.
      
      This patch fixes the issue in my tests and should be applied to 2.6.36
      and as far back as anyone cares to add it to stable.
      
      Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
      Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      CC: Alexander Duyck <alexander.h.duyck@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: stable@kerne.org
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab12811c
  23. 08 9月, 2010 1 次提交
    • J
      bonding: Fix jiffies overflow problems (again) · cb32f2a0
      Jiri Bohac 提交于
      The time_before_eq()/time_after_eq() functions operate on unsigned
      long and only work if the difference between the two compared values
      is smaller than half the range of unsigned long (31 bits on i386).
      
      Some of the variables (slave->jiffies, dev->trans_start, dev->last_rx)
      used by bonding store a copy of jiffies and may not be updated for a
      long time. With HZ=1000, time_before_eq()/time_after_eq() will start
      giving bad results after ~25 days.
      
      jiffies will never be before slave->jiffies, dev->trans_start,
      dev->last_rx by more than possibly a couple ticks caused by preemption
      of this code. This allows us to detect/prevent these overflows by
      replacing time_before_eq()/time_after_eq() with time_in_range().
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb32f2a0