1. 28 Oct, 2009 32 commits
  2. 27 Oct, 2009 6 commits
  3. 26 Oct, 2009 2 commits
    • Michal Ostrowski's avatar
      PPPoE: Fix flush/close races. · fb64bb56
      Michal Ostrowski authored
      Be more careful about the state of pointers during tear-down.
      The "pppoe_dev" field can only be looked at safely while holding socket locks.
      This subsequently allows for the flush_lock to be killed.
      
      We depend on the PPPOX_CONNECTED state to tell us that that those fields are
      valid, so whoever clears that state (pppox_unbind_sock()) is responsible for
      the dev_put() call.
      
      We also have to ensure that we delete_item() on all sockets before they are
      cleaned up.
      
      The need for these changes has been exposed by scenarios wherein namespace
      bindings of ethernet devices change while there are ongoing PPPoE sessions,
      which resulted in oopses due to unusual socket connection termination paths,
      exposing these issues.
      Signed-off-by: default avatarMichal Ostrowski <mostrows@gmail.com>
      Reviewed-by: default avatarCyril Gorcunov <gorcunov@gmail.com>
      Reported-by: default avatarDenys Fedoryschenko <denys@visp.net.lb>
      Tested-by: default avatarDenys Fedoryschenko <denys@visp.net.lb>
      fb64bb56
    • Bruce Allan's avatar
      e1000e: allow for swflag to be held over consecutive PHY accesses · 5ccdcecb
      Bruce Allan authored
      PCH-based parts (82577/82578) and some ICH8-based parts (82566) need to
      hold the swflag (sw/fw/hw hardware semaphore) over consecutive PHY accesses
      in order to perform sw-driven PHY configuration during initialization to
      workaround known hardware issues (see follow-on patch).  This patch
      provides new PHY read/write functions (and function pointers) that will
      allow accessing the PHY registers assuming the swflag has already been
      acquired.  The actual PHY register access code has moved into helper
      functions that are called with a flag indicating whether or not the swflag
      has already been acquired and acquires/releases it if not.
      
      The functions called from within the updated PHY access functions had to be
      updated to assume the swflag was already acquired, and other functions that
      called those functions were also updated to acquire/release the swflag.
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ccdcecb