1. 14 5月, 2016 1 次提交
    • G
      watchdog: core: Fix circular locking dependency · e1f30282
      Guenter Roeck 提交于
      lockdep reports the following circular locking dependency.
      
      ======================================================
      INFO: possible circular locking dependency detected ]
      4.6.0-rc3-00191-gfabf418 #162 Not tainted
      -------------------------------------------------------
      systemd/1 is trying to acquire lock:
      ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280
      
      but task is already holding lock:
      
      (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190
      
      which lock already depends on the new lock.
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wd_data->lock){+.+...}:
      	[<80662310>] mutex_lock_nested+0x64/0x4a8
      	[<804aca4c>] watchdog_ping_work+0x18/0x4c
      	[<80143128>] process_one_work+0x1ac/0x500
      	[<801434b4>] worker_thread+0x38/0x554
      	[<80149510>] kthread+0xf4/0x108
      	[<80107c10>] ret_from_fork+0x14/0x24
      
      -> #0 ((&(&wd_data->work)->work)){+.+...}:
      	[<8017c4e8>] lock_acquire+0x70/0x90
      	[<8014169c>] flush_work+0x4c/0x280
      	[<801440f8>] __cancel_work_timer+0x9c/0x1e0
      	[<804acfcc>] watchdog_release+0x3c/0x190
      	[<8022c5e8>] __fput+0x80/0x1c8
      	[<80147b28>] task_work_run+0x94/0xc8
      	[<8010b998>] do_work_pending+0x8c/0xb4
      	[<80107ba8>] slow_work_pending+0xc/0x20
      
      other info that might help us debug this:
      Possible unsafe locking scenario:
      
      CPU0                    CPU1
      ----                    ----
      lock(&wd_data->lock);
                              lock((&(&wd_data->work)->work));
                              lock(&wd_data->lock);
      lock((&(&wd_data->work)->work));
      
      *** DEADLOCK ***
      
      1 lock held by systemd/1:
      
      stack backtrace:
      CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 #162
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      [<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14)
      [<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4)
      [<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334)
      [<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8)
      [<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec)
      [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90)
      [<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280)
      [<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0)
      [<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190)
      [<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8)
      [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
      [<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4)
      [<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20)
      
      Turns out the call to cancel_delayed_work_sync() in watchdog_release()
      is not necessary and can be dropped. If the worker is no longer necessary,
      the subsequent call to watchdog_update_worker() will cancel it. If it is
      already running, it won't do anything, since the worker function checks
      if it needs to ping the watchdog or not.
      Reported-by: NClemens Gruber <clemens.gruber@pqgruber.com>
      Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com>
      Fixes: 11d7aba9 ("watchdog: imx2: Convert to use infrastructure triggered keepalives")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      Cc: stable <stable@vger.kernel.org>
      e1f30282
  2. 17 3月, 2016 6 次提交
  3. 12 1月, 2016 2 次提交
  4. 30 12月, 2015 2 次提交
    • G
      watchdog: Separate and maintain variables based on variable lifetime · b4ffb190
      Guenter Roeck 提交于
      All variables required by the watchdog core to manage a watchdog are
      currently stored in struct watchdog_device. The lifetime of those
      variables is determined by the watchdog driver. However, the lifetime
      of variables used by the watchdog core differs from the lifetime of
      struct watchdog_device. To remedy this situation, watchdog drivers
      can implement ref and unref callbacks, to be used by the watchdog
      core to lock struct watchdog_device in memory.
      
      While this solves the immediate problem, it depends on watchdog drivers
      to actually implement the ref/unref callbacks. This is error prone,
      often not implemented in the first place, or not implemented correctly.
      
      To solve the problem without requiring driver support, split the variables
      in struct watchdog_device into two data structures - one for variables
      associated with the watchdog driver, one for variables associated with
      the watchdog core. With this approach, the watchdog core can keep track
      of its variable lifetime and no longer depends on ref/unref callbacks
      in the driver. As a side effect, some of the variables originally in
      struct watchdog_driver are now private to the watchdog core and no longer
      visible in watchdog drivers.
      
      As a side effect of the changes made, an ioctl will now always fail
      with -ENODEV after a watchdog device was unregistered with the character
      device still open. Previously, it would only fail with -ENODEV in some
      situations. Also, ioctl operations are now atomic from driver perspective.
      With this change, it is now guaranteed that the driver will not unregister
      a watchdog between a timeout change and the subsequent ping.
      
      The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer
      used and marked as deprecated.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      b4ffb190
    • G
      watchdog: Create watchdog device in watchdog_dev.c · 32ecc639
      Guenter Roeck 提交于
      The watchdog character device is currently created in watchdog_dev.c,
      and the watchdog device in watchdog_core.c. This results in
      cross-dependencies, since device creation needs to know the watchdog
      character device number as well as the watchdog class, both of which
      reside in watchdog_dev.c.
      
      Create the watchdog device in watchdog_dev.c to simplify the code.
      
      Inspired by earlier patch set from Damien Riegel.
      
      Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      32ecc639
  5. 27 12月, 2015 2 次提交
  6. 03 11月, 2015 2 次提交
  7. 12 7月, 2013 1 次提交
    • H
      watchdog: core: don't try to stop device if not running · fcf95670
      Hector Palacios 提交于
      A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS
      ioctl and flag WDIOS_DISABLECARD. If the device is closed after this
      operation, watchdog_release() is called and status bits checked for
      stopping it. Besides, if the device has not been unregistered a critical
      message "watchdog did not stop!" is printed, although the ioctl may have
      successfully stopped it already.
      
      Without the patch a user application sample code like this will successfully
      stop the watchdog, but the kernel will output the message
      "watchdog did not stop!":
      
      	wd_fd = open("/dev/watchdog", O_RDWR);
      
      	flags = WDIOS_DISABLECARD;
      	ioctl(wd_fd, WDIOC_SETOPTIONS, &flags);
      
      	close(wd_fd);
      Signed-off-by: NHector Palacios <hector.palacios@digi.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      fcf95670
  8. 09 5月, 2013 1 次提交
  9. 01 3月, 2013 1 次提交
  10. 29 6月, 2012 1 次提交
    • W
      watchdog: core: fix WDIOC_GETSTATUS return value · 8b9468d4
      Wim Van Sebroeck 提交于
      In commit 7a879824 we added
      a wrapper for the WDIOC_GETSTATUS ioctl call. The code results
      however in a different behaviour: it returns an error if the
      driver doesn't support the status operation. This is not
      according to the API that says that when we don't support
      the status operation, that we just should return a 0 value.
      Only when the device isn't there anymore, we should return an
      error.
      Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      8b9468d4
  11. 30 5月, 2012 9 次提交
  12. 28 3月, 2012 3 次提交
  13. 20 9月, 2011 1 次提交
  14. 28 7月, 2011 8 次提交