All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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: link
Be 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.