From: kernel test robot <lkp@intel.com>
To: Saurav Kashyap <skashyap@marvell.com>, martin.petersen@oracle.com
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
GR-QLogic-Storage-Upstream@marvell.com,
linux-scsi@vger.kernel.org, Saurav Kashyap <skashyap@marvell.com>,
Nilesh Javali <njavali@marvell.com>
Subject: Re: [PATCH 2/3] qedf: Wait for stag work during unload.
Date: Sat, 16 Mar 2024 09:34:01 +0800 [thread overview]
Message-ID: <202403160959.uNobO4UE-lkp@intel.com> (raw)
In-Reply-To: <20240315100600.19568-3-skashyap@marvell.com>
Hi Saurav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on jejb-scsi/for-next linus/master v6.8 next-20240315]
[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#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Saurav-Kashyap/qedf-Don-t-process-stag-work-during-unload-and-recovery/20240315-180830
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
patch link: https://lore.kernel.org/r/20240315100600.19568-3-skashyap%40marvell.com
patch subject: [PATCH 2/3] qedf: Wait for stag work during unload.
config: x86_64-allmodconfig (https://download.01.org/0day-ci/archive/20240316/202403160959.uNobO4UE-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240316/202403160959.uNobO4UE-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403160959.uNobO4UE-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/scsi/qedf/qedf_main.c:923:37: warning: variable 'qedf' is uninitialized when used here [-Wuninitialized]
923 | clear_bit(QEDF_STAG_IN_PROGRESS, &qedf->flags);
| ^~~~
drivers/scsi/qedf/qedf_main.c:919:23: note: initialize the variable 'qedf' to silence this warning
919 | struct qedf_ctx *qedf;
| ^
| = NULL
1 warning generated.
vim +/qedf +923 drivers/scsi/qedf/qedf_main.c
915
916 /* Performs soft reset of qedf_ctx by simulating a link down/up */
917 void qedf_ctx_soft_reset(struct fc_lport *lport)
918 {
919 struct qedf_ctx *qedf;
920 struct qed_link_output if_link;
921
922 if (lport->vport) {
> 923 clear_bit(QEDF_STAG_IN_PROGRESS, &qedf->flags);
924 printk_ratelimited("Cannot issue host reset on NPIV port.\n");
925 return;
926 }
927
928 qedf = lport_priv(lport);
929
930 qedf->flogi_pending = 0;
931 /* For host reset, essentially do a soft link up/down */
932 atomic_set(&qedf->link_state, QEDF_LINK_DOWN);
933 QEDF_INFO(&qedf->dbg_ctx, QEDF_LOG_DISC,
934 "Queuing link down work.\n");
935 queue_delayed_work(qedf->link_update_wq, &qedf->link_update,
936 0);
937
938 if (qedf_wait_for_upload(qedf) == false) {
939 QEDF_ERR(&qedf->dbg_ctx, "Could not upload all sessions.\n");
940 WARN_ON(atomic_read(&qedf->num_offloads));
941 }
942
943 /* Before setting link up query physical link state */
944 qed_ops->common->get_link(qedf->cdev, &if_link);
945 /* Bail if the physical link is not up */
946 if (!if_link.link_up) {
947 QEDF_INFO(&qedf->dbg_ctx, QEDF_LOG_DISC,
948 "Physical link is not up.\n");
949 clear_bit(QEDF_STAG_IN_PROGRESS, &qedf->flags);
950 return;
951 }
952 /* Flush and wait to make sure link down is processed */
953 flush_delayed_work(&qedf->link_update);
954 msleep(500);
955
956 atomic_set(&qedf->link_state, QEDF_LINK_UP);
957 qedf->vlan_id = 0;
958 QEDF_INFO(&qedf->dbg_ctx, QEDF_LOG_DISC,
959 "Queue link up work.\n");
960 queue_delayed_work(qedf->link_update_wq, &qedf->link_update,
961 0);
962 clear_bit(QEDF_STAG_IN_PROGRESS, &qedf->flags);
963 }
964
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2024-03-16 1:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 10:05 [PATCH 0/3] qedf misc bug fixes Saurav Kashyap
2024-03-15 10:05 ` [PATCH 1/3] qedf: Don't process stag work during unload and recovery Saurav Kashyap
2024-03-15 10:05 ` [PATCH 2/3] qedf: Wait for stag work during unload Saurav Kashyap
2024-03-16 1:34 ` kernel test robot [this message]
2024-03-15 10:06 ` [PATCH 3/3] qedf: Memset qed_slowpath_params to zero before use Saurav Kashyap
2024-03-15 20:45 ` [PATCH 0/3] qedf misc bug fixes Martin Wilck
2024-05-01 22:28 ` Lee Duncan
2024-05-08 10:15 ` Martin Wilck
2024-05-08 12:32 ` Martin K. Petersen
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=202403160959.uNobO4UE-lkp@intel.com \
--to=lkp@intel.com \
--cc=GR-QLogic-Storage-Upstream@marvell.com \
--cc=linux-scsi@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=martin.petersen@oracle.com \
--cc=njavali@marvell.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=skashyap@marvell.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.