From: kernel test robot <lkp@intel.com> To: Oded Gabbay <oded.gabbay@gmail.com>, linux-kernel@vger.kernel.org, SW_Drivers@habana.ai Cc: kbuild-all@lists.01.org, Ofir Bitton <obitton@habana.ai>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Daniel Vetter <daniel.vetter@ffwll.ch> Subject: Re: [PATCH 1/2] habanalabs: Replace dma-fence mechanism with completions Date: Fri, 31 Jul 2020 03:33:19 +0800 [thread overview] Message-ID: <202007310336.aLxIxZAB%lkp@intel.com> (raw) In-Reply-To: <20200730131347.30261-1-oded.gabbay@gmail.com> [-- Attachment #1: Type: text/plain, Size: 4285 bytes --] 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 <lkp@intel.com> 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 [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 65216 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com> To: kbuild-all@lists.01.org Subject: Re: [PATCH 1/2] habanalabs: Replace dma-fence mechanism with completions Date: Fri, 31 Jul 2020 03:33:19 +0800 [thread overview] Message-ID: <202007310336.aLxIxZAB%lkp@intel.com> (raw) In-Reply-To: <20200730131347.30261-1-oded.gabbay@gmail.com> [-- Attachment #1: Type: text/plain, Size: 4394 bytes --] 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 <lkp@intel.com> 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(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 65216 bytes --]
next prev parent reply other threads:[~2020-07-30 19:40 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-30 13:13 [PATCH 1/2] habanalabs: Replace dma-fence mechanism with completions Oded Gabbay 2020-07-30 13:13 ` [PATCH 2/2] habanalabs: add information about PCIe controller Oded Gabbay 2020-07-31 0:17 ` kernel test robot 2020-07-31 0:17 ` kernel test robot 2020-07-31 9:01 ` kernel test robot 2020-07-31 9:01 ` kernel test robot 2020-08-01 19:23 ` kernel test robot 2020-08-01 19:23 ` kernel test robot 2020-07-30 19:33 ` kernel test robot [this message] 2020-07-30 19:33 ` [PATCH 1/2] habanalabs: Replace dma-fence mechanism with completions kernel test robot 2020-07-30 20:43 ` Daniel Vetter 2020-08-01 17:50 ` kernel test robot 2020-08-01 17:50 ` kernel test robot 2020-08-01 17:50 ` [RFC PATCH] habanalabs: hl_fence_release() can be static kernel test robot 2020-08-01 17:50 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=202007310336.aLxIxZAB%lkp@intel.com \ --to=lkp@intel.com \ --cc=SW_Drivers@habana.ai \ --cc=daniel.vetter@ffwll.ch \ --cc=gregkh@linuxfoundation.org \ --cc=kbuild-all@lists.01.org \ --cc=linux-kernel@vger.kernel.org \ --cc=obitton@habana.ai \ --cc=oded.gabbay@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.