1. 09 Mar, 2021 2 commits
    • Alexander Aring's avatar
      fs: dlm: fix mark setting deadlock · e125fbeb
      Alexander Aring authored
      This patch fixes an deadlock issue when dlm_lowcomms_close() is called.
      When dlm_lowcomms_close() is called the clusters_root.subsys.su_mutex is
      held to remove configfs items. At this time we flushing (e.g.
      cancel_work_sync()) the workers of send and recv workqueue. Due the fact
      that we accessing configfs items (mark values), these workers will lock
      clusters_root.subsys.su_mutex as well which are already hold by
      dlm_lowcomms_close() and ends in a deadlock situation.
      
      [67170.703046] ======================================================
      [67170.703965] WARNING: possible circular locking dependency detected
      [67170.704758] 5.11.0-rc4+ #22 Tainted: G        W
      [67170.705433] ------------------------------------------------------
      [67170.706228] dlm_controld/280 is trying to acquire lock:
      [67170.706915] ffff9f2f475a6948 ((wq_completion)dlm_recv){+.+.}-{0:0}, at: __flush_work+0x203/0x4c0
      [67170.708026]
                     but task is already holding lock:
      [67170.708758] ffffffffa132f878 (&clusters_root.subsys.su_mutex){+.+.}-{3:3}, at: configfs_rmdir+0x29b/0x310
      [67170.710016]
                     which lock already depends on the new lock.
      
      The new behaviour adds the mark value to the node address configuration
      which doesn't require to held the clusters_root.subsys.su_mutex by
      accessing mark values in a separate datastructure. However the mark
      values can be set now only after a node address was set which is the
      case when the user is using dlm_controld.
      Signed-off-by: default avatarAlexander Aring <aahringo@redhat.com>
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      e125fbeb
    • Alexander Aring's avatar
      fs: dlm: fix debugfs dump · 92c48950
      Alexander Aring authored
      This patch fixes the following message which randomly pops up during
      glocktop call:
      
      seq_file: buggy .next function table_seq_next did not update position index
      
      The issue is that seq_read_iter() in fs/seq_file.c also needs an
      increment of the index in an non next record case as well which this
      patch fixes otherwise seq_read_iter() will print out the above message.
      Signed-off-by: default avatarAlexander Aring <aahringo@redhat.com>
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      92c48950
  2. 06 Mar, 2021 4 commits
  3. 05 Mar, 2021 33 commits
  4. 04 Mar, 2021 1 commit
    • Jens Axboe's avatar
      kernel: provide create_io_thread() helper · cc440e87
      Jens Axboe authored
      Provide a generic helper for setting up an io_uring worker. Returns a
      task_struct so that the caller can do whatever setup is needed, then call
      wake_up_new_task() to kick it into gear.
      
      Add a kernel_clone_args member, io_thread, which tells copy_process() to
      mark the task with PF_IO_WORKER.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      cc440e87