1. 10 10月, 2017 4 次提交
  2. 09 10月, 2017 6 次提交
  3. 07 10月, 2017 1 次提交
    • G
      ppp: fix race in ppp device destruction · 6151b8b3
      Guillaume Nault 提交于
      ppp_release() tries to ensure that netdevices are unregistered before
      decrementing the unit refcount and running ppp_destroy_interface().
      
      This is all fine as long as the the device is unregistered by
      ppp_release(): the unregister_netdevice() call, followed by
      rtnl_unlock(), guarantee that the unregistration process completes
      before rtnl_unlock() returns.
      
      However, the device may be unregistered by other means (like
      ppp_nl_dellink()). If this happens right before ppp_release() calling
      rtnl_lock(), then ppp_release() has to wait for the concurrent
      unregistration code to release the lock.
      But rtnl_unlock() releases the lock before completing the device
      unregistration process. This allows ppp_release() to proceed and
      eventually call ppp_destroy_interface() before the unregistration
      process completes. Calling free_netdev() on this partially unregistered
      device will BUG():
      
       ------------[ cut here ]------------
       kernel BUG at net/core/dev.c:8141!
       invalid opcode: 0000 [#1] SMP
      
       CPU: 1 PID: 1557 Comm: pppd Not tainted 4.14.0-rc2+ #4
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
      
       Call Trace:
        ppp_destroy_interface+0xd8/0xe0 [ppp_generic]
        ppp_disconnect_channel+0xda/0x110 [ppp_generic]
        ppp_unregister_channel+0x5e/0x110 [ppp_generic]
        pppox_unbind_sock+0x23/0x30 [pppox]
        pppoe_connect+0x130/0x440 [pppoe]
        SYSC_connect+0x98/0x110
        ? do_fcntl+0x2c0/0x5d0
        SyS_connect+0xe/0x10
        entry_SYSCALL_64_fastpath+0x1a/0xa5
      
       RIP: free_netdev+0x107/0x110 RSP: ffffc28a40573d88
       ---[ end trace ed294ff0cc40eeff ]---
      
      We could set the ->needs_free_netdev flag on PPP devices and move the
      ppp_destroy_interface() logic in the ->priv_destructor() callback. But
      that'd be quite intrusive as we'd first need to unlink from the other
      channels and units that depend on the device (the ones that used the
      PPPIOCCONNECT and PPPIOCATTACH ioctls).
      
      Instead, we can just let the netdevice hold a reference on its
      ppp_file. This reference is dropped in ->priv_destructor(), at the very
      end of the unregistration process, so that neither ppp_release() nor
      ppp_disconnect_channel() can call ppp_destroy_interface() in the interim.
      Reported-by: NBeniamino Galvani <bgalvani@redhat.com>
      Fixes: 8cb775bc ("ppp: fix device unregistration upon netns deletion")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6151b8b3
  4. 06 10月, 2017 1 次提交
    • J
      dm raid: fix incorrect status output at the end of a "recover" process · 41dcf197
      Jonathan Brassow 提交于
      There are three important fields that indicate the overall health and
      status of an array: dev_health, sync_ratio, and sync_action.  They tell
      us the condition of the devices in the array, and the degree to which
      the array is synchronized.
      
      This commit fixes a condition that is reported incorrectly.  When a member
      of the array is being rebuilt or a new device is added, the "recover"
      process is used to synchronize it with the rest of the array.  When the
      process is complete, but the sync thread hasn't yet been reaped, it is
      possible for the state of MD to be:
       mddev->recovery = [ MD_RECOVERY_RUNNING MD_RECOVERY_RECOVER MD_RECOVERY_DONE ]
       curr_resync_completed = <max dev size> (but not MaxSector)
       and all rdevs to be In_sync.
      This causes the 'array_in_sync' output parameter that is passed to
      rs_get_progress() to be computed incorrectly and reported as 'false' --
      or not in-sync.  This in turn causes the dev_health status characters to
      be reported as all 'a', rather than the proper 'A'.
      
      This can cause erroneous output for several seconds at a time when tools
      will want to be checking the condition due to events that are raised at
      the end of a sync process.  Fix this by properly calculating the
      'array_in_sync' return parameter in rs_get_progress().
      
      Also, remove an unnecessary intermediate 'recovery_cp' variable in
      rs_get_progress().
      Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      41dcf197
  5. 05 10月, 2017 14 次提交
  6. 04 10月, 2017 14 次提交