Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Tyrel Datwyler <tyreld@linux.ibm.com>
To: Dave Marquardt <davemarq@linux.ibm.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, Brian King <brking@linux.ibm.com>,
	Greg Joyce <gjoyce@linux.ibm.com>,
	Kyle Mahlkuch <kmahlkuc@linux.ibm.com>
Subject: Re: [PATCH v2 1/7] ibmvfc: add basic FPIN support
Date: Mon, 15 Jun 2026 15:10:23 -0700	[thread overview]
Message-ID: <d8ad1826-5e13-446d-98ce-e7d6dd5c8f73@linux.ibm.com> (raw)
In-Reply-To: <87o6hbo7z5.fsf@linux.ibm.com>

On 6/15/26 1:37 PM, Dave Marquardt wrote:
> Tyrel Datwyler <tyreld@linux.ibm.com> writes:
> 
>> On 6/8/26 11:30 AM, Dave Marquardt via B4 Relay wrote:
>>> From: Dave Marquardt <davemarq@linux.ibm.com>
>>>
>>> Add support for basic FPIN messages to the ibmvfc driver. This includes
>>>
>>> - adding FPIN handling support to the async event handler
>>> - offloading processing of FPIN messages to a work queue
>>> - converting the VIOS FPIN message to a struct fc_els_fpin as used by
>>>   the Linux kernel
>>> - passing the converted struct fc_els_fpin to fc_host_fpin_rcv for
>>>   processing
>>>

<snip>

>>> +static void ibmvfc_process_async_work(struct work_struct *work)
>>> +{
>>> +	struct ibmvfc_async_work *aw;
>>> +	struct ibmvfc_async_crq *crq;
>>> +	struct ibmvfc_target *tgt;
>>> +	struct ibmvfc_host *vhost;
>>> +	struct fc_els_fpin *fpin;
>>> +
>>> +	aw = container_of(work, struct ibmvfc_async_work, async_work_s);
>>> +	crq = aw->crq;
>>> +	vhost = aw->vhost;
>>> +
>>> +	if (!crq->scsi_id && !crq->wwpn && !crq->node_name)
>>> +		goto end;
>>> +	list_for_each_entry(tgt, &vhost->targets, queue) {
>>
>> Should we be holding the host lock when iterateing targets?
> 
> fc_host_fpin_rcv assumes no locks are held. I built a kernel with
> LOCKDEP, PROVE_LOCKING, DEBUG_SPINLOCK et al defined, and got some
> deadlocks. Some of the routines fc_host_fpin_rcv call acquire the host
> lock also.
> 
> I'l change this code to use list_for_each_entry_safe. Is that enough for
> safety in this case?
> 

No, the _safe version is only if you are potentially doing removals in the code
block while iterating the list.

Can't we assume every target in our tgt list is unique and we only need to
iterate until we find the matching target? In that case you can take the lock
iterate the list, break on a found match, copy whatever data is necessary from
the tgt, and then drop the lock and call fc_host_fpin_rcv.

-Tyrel

  reply	other threads:[~2026-06-15 22:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08 18:30 [PATCH v2 0/7] ibmvfc: make ibmvfc support FPIN messages Dave Marquardt via B4 Relay
2026-06-08 18:30 ` [PATCH v2 1/7] ibmvfc: add basic FPIN support Dave Marquardt via B4 Relay
2026-06-12 22:35   ` Tyrel Datwyler
2026-06-15 20:37     ` Dave Marquardt
2026-06-15 22:10       ` Tyrel Datwyler [this message]
2026-06-15 23:38   ` Tyrel Datwyler
2026-06-08 18:30 ` [PATCH v2 2/7] ibmvfc: Add NOOP command support Dave Marquardt via B4 Relay
2026-06-08 18:30 ` [PATCH v2 3/7] ibmvfc: make ibmvfc login to fabric Dave Marquardt via B4 Relay
2026-06-12 23:11   ` Tyrel Datwyler
2026-06-15 13:42     ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 4/7] ibmvfc: define asynchronous sub-queue Dave Marquardt via B4 Relay
2026-06-15 19:27   ` Tyrel Datwyler
2026-06-15 20:15     ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 5/7] ibmvfc: allocate " Dave Marquardt via B4 Relay
2026-06-15 19:54   ` Tyrel Datwyler
2026-06-08 18:30 ` [PATCH v2 6/7] ibmvfc: register and use " Dave Marquardt via B4 Relay
2026-06-15 20:58   ` Tyrel Datwyler
2026-06-08 18:30 ` [PATCH v2 7/7] ibmvfc: handle extended FPIN events Dave Marquardt via B4 Relay
2026-06-15 21:52   ` Tyrel Datwyler

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=d8ad1826-5e13-446d-98ce-e7d6dd5c8f73@linux.ibm.com \
    --to=tyreld@linux.ibm.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=brking@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=davemarq@linux.ibm.com \
    --cc=gjoyce@linux.ibm.com \
    --cc=kmahlkuc@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=martin.petersen@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox