1. 23 7月, 2014 1 次提交
  2. 22 7月, 2014 37 次提交
  3. 21 7月, 2014 2 次提交
    • T
      tracing: Fix wraparound problems in "uptime" trace clock · 58d4e21e
      Tony Luck 提交于
      The "uptime" trace clock added in:
      
          commit 8aacf017
          tracing: Add "uptime" trace clock that uses jiffies
      
      has wraparound problems when the system has been up more
      than 1 hour 11 minutes and 34 seconds. It converts jiffies
      to nanoseconds using:
              (u64)jiffies_to_usecs(jiffy) * 1000ULL
      but since jiffies_to_usecs() only returns a 32-bit value, it
      truncates at 2^32 microseconds.  An additional problem on 32-bit
      systems is that the argument is "unsigned long", so fixing the
      return value only helps until 2^32 jiffies (49.7 days on a HZ=1000
      system).
      
      Avoid these problems by using jiffies_64 as our basis, and
      not converting to nanoseconds (we do convert to clock_t because
      user facing API must not be dependent on internal kernel
      HZ values).
      
      Link: http://lkml.kernel.org/p/99d63c5bfe9b320a3b428d773825a37095bf6a51.1405708254.git.tony.luck@intel.com
      
      Cc: stable@vger.kernel.org # 3.10+
      Fixes: 8aacf017 "tracing: Add "uptime" trace clock that uses jiffies"
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      58d4e21e
    • A
      batman-adv: fix TT VLAN inconsistency on VLAN re-add · 35df3b29
      Antonio Quartulli 提交于
      When a VLAN interface (on top of batX) is removed and
      re-added within a short timeframe TT does not have enough
      time to properly cleanup. This creates an internal TT state
      mismatch as the newly created softif_vlan will be
      initialized from scratch with a TT client count of zero
      (even if TT entries for this VLAN still exist). The
      resulting TT messages are bogus due to the counter / tt
      client listing mismatch, thus creating inconsistencies on
      every node in the network
      
      To fix this issue destroy_vlan() has to not free the VLAN
      object immediately but it has to be kept alive until all the
      TT entries for this VLAN have been removed. destroy_vlan()
      still removes the sysfs folder so that the user has the
      feeling that everything went fine.
      
      If the same VLAN is re-added before the old object is free'd,
      then the latter is resurrected and re-used.
      
      Implement such behaviour by increasing the reference counter
      of a softif_vlan object every time a new local TT entry for
      such VLAN is created and remove the object from the list
      only when all the TT entries have been destroyed.
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      35df3b29