Hi Oded, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on char-misc/char-misc-testing] [also build test WARNING on next-20200730] [cannot apply to linux/master linus/master v5.8-rc7] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Oded-Gabbay/habanalabs-Replace-dma-fence-mechanism-with-completions/20200730-211536 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 22362aa30bad6f03b5bcbbeee3cdc61950d40086 config: riscv-allyesconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> drivers/misc/habanalabs/common/command_submission.c:41:6: warning: no previous prototype for 'hl_fence_release' [-Wmissing-prototypes] 41 | void hl_fence_release(struct kref *kref) | ^~~~~~~~~~~~~~~~ >> drivers/misc/habanalabs/common/command_submission.c:101:6: warning: no previous prototype for 'hl_fence_init' [-Wmissing-prototypes] 101 | void hl_fence_init(struct hl_fence *fence) | ^~~~~~~~~~~~~ vim +/hl_fence_release +41 drivers/misc/habanalabs/common/command_submission.c 40 > 41 void hl_fence_release(struct kref *kref) 42 { 43 struct hl_fence *fence = 44 container_of(kref, struct hl_fence, refcount); 45 struct hl_cs_compl *hl_cs_cmpl = 46 container_of(fence, struct hl_cs_compl, base_fence); 47 struct hl_device *hdev = hl_cs_cmpl->hdev; 48 49 /* EBUSY means the CS was never submitted and hence we don't have 50 * an attached hw_sob object that we should handle here 51 */ 52 if (fence->error == -EBUSY) 53 goto free; 54 55 if ((hl_cs_cmpl->type == CS_TYPE_SIGNAL) || 56 (hl_cs_cmpl->type == CS_TYPE_WAIT)) { 57 58 dev_dbg(hdev->dev, 59 "CS 0x%llx type %d finished, sob_id: %d, sob_val: 0x%x\n", 60 hl_cs_cmpl->cs_seq, 61 hl_cs_cmpl->type, 62 hl_cs_cmpl->hw_sob->sob_id, 63 hl_cs_cmpl->sob_val); 64 65 /* 66 * A signal CS can get completion while the corresponding wait 67 * for signal CS is on its way to the PQ. The wait for signal CS 68 * will get stuck if the signal CS incremented the SOB to its 69 * max value and there are no pending (submitted) waits on this 70 * SOB. 71 * We do the following to void this situation: 72 * 1. The wait for signal CS must get a ref for the signal CS as 73 * soon as possible in cs_ioctl_signal_wait() and put it 74 * before being submitted to the PQ but after it incremented 75 * the SOB refcnt in init_signal_wait_cs(). 76 * 2. Signal/Wait for signal CS will decrement the SOB refcnt 77 * here. 78 * These two measures guarantee that the wait for signal CS will 79 * reset the SOB upon completion rather than the signal CS and 80 * hence the above scenario is avoided. 81 */ 82 kref_put(&hl_cs_cmpl->hw_sob->kref, hl_sob_reset); 83 } 84 85 free: 86 kfree_rcu(hl_cs_cmpl, base_fence.rcu); 87 } 88 89 void hl_fence_put(struct hl_fence *fence) 90 { 91 if (fence) 92 kref_put(&fence->refcount, hl_fence_release); 93 } 94 95 void hl_fence_get(struct hl_fence *fence) 96 { 97 if (fence) 98 kref_get(&fence->refcount); 99 } 100 > 101 void hl_fence_init(struct hl_fence *fence) 102 { 103 kref_init(&fence->refcount); 104 fence->error = 0; 105 init_completion(&fence->completion); 106 } 107 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org