<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/scsi/lpfc, branch v5.10.257</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.257</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.257'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-18T08:30:49+00:00</updated>
<entry>
<title>scsi: lpfc: Properly set WC for DPP mapping</title>
<updated>2026-04-18T08:30:49+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@grsecurity.net</email>
</author>
<published>2026-02-12T19:23:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e6dc2739a5c360d40e17d461d32ddf6b245e40b3'/>
<id>urn:sha1:e6dc2739a5c360d40e17d461d32ddf6b245e40b3</id>
<content type='text'>
[ Upstream commit bffda93a51b40afd67c11bf558dc5aae83ca0943 ]

Using set_memory_wc() to enable write-combining for the DPP portion of
the MMIO mapping is wrong as set_memory_*() is meant to operate on RAM
only, not MMIO mappings. In fact, as used currently triggers a BUG_ON()
with enabled CONFIG_DEBUG_VIRTUAL.

Simply map the DPP region separately and in addition to the already
existing mappings, avoiding any possible negative side effects for
these.

Fixes: 1351e69fc6db ("scsi: lpfc: Add push-to-adapter support to sli4")
Signed-off-by: Mathias Krause &lt;minipli@grsecurity.net&gt;
Signed-off-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Reviewed-by: Mathias Krause &lt;minipli@grsecurity.net&gt;
Link: https://patch.msgid.link/20260212192327.141104-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Define size of debugfs entry for xri rebalancing</title>
<updated>2025-12-06T21:08:13+00:00</updated>
<author>
<name>Justin Tee</name>
<email>justin.tee@broadcom.com</email>
</author>
<published>2025-09-15T18:08:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=82a20f33b1f3d2d2c7ead424f93d63c438f401c9'/>
<id>urn:sha1:82a20f33b1f3d2d2c7ead424f93d63c438f401c9</id>
<content type='text'>
[ Upstream commit 5de09770b1c0e229d2cec93e7f634fcdc87c9bc8 ]

To assist in debugging lpfc_xri_rebalancing driver parameter, a debugfs
entry is used.  The debugfs file operations for xri rebalancing have
been previously implemented, but lack definition for its information
buffer size.  Similar to other pre-existing debugfs entry buffers,
define LPFC_HDWQINFO_SIZE as 8192 bytes.

Signed-off-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Message-ID: &lt;20250915180811.137530-9-justintee8345@gmail.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Fix buffer free/clear order in deferred receive path</title>
<updated>2025-09-09T16:45:21+00:00</updated>
<author>
<name>John Evans</name>
<email>evans1210144@gmail.com</email>
</author>
<published>2025-08-28T04:40:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=baa39f6ad79d372a6ce0aa639fbb2f1578479f57'/>
<id>urn:sha1:baa39f6ad79d372a6ce0aa639fbb2f1578479f57</id>
<content type='text'>
commit 9dba9a45c348e8460da97c450cddf70b2056deb3 upstream.

Fix a use-after-free window by correcting the buffer release sequence in
the deferred receive path. The code freed the RQ buffer first and only
then cleared the context pointer under the lock. Concurrent paths (e.g.,
ABTS and the repost path) also inspect and release the same pointer under
the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the
pointer under the lock, then free it after dropping the lock. The
deferred path should do the same.

Fixes: 472e146d1cf3 ("scsi: lpfc: Correct upcalling nvmet_fc transport during io done downcall")
Cc: stable@vger.kernel.org
Signed-off-by: John Evans &lt;evans1210144@gmail.com&gt;
Link: https://lore.kernel.org/r/20250828044008.743-1-evans1210144@gmail.com
Reviewed-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Fix link down processing to address NULL pointer dereference</title>
<updated>2025-08-28T14:22:55+00:00</updated>
<author>
<name>James Smart</name>
<email>jsmart2021@gmail.com</email>
</author>
<published>2025-08-12T06:08:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04c1af683270e4709a594bb1691b8800b945035a'/>
<id>urn:sha1:04c1af683270e4709a594bb1691b8800b945035a</id>
<content type='text'>
[ Upstream commit 1854f53ccd88ad4e7568ddfafafffe71f1ceb0a6 ]

If an FC link down transition while PLOGIs are outstanding to fabric well
known addresses, outstanding ABTS requests may result in a NULL pointer
dereference. Driver unload requests may hang with repeated "2878" log
messages.

The Link down processing results in ABTS requests for outstanding ELS
requests. The Abort WQEs are sent for the ELSs before the driver had set
the link state to down. Thus the driver is sending the Abort with the
expectation that an ABTS will be sent on the wire. The Abort request is
stalled waiting for the link to come up. In some conditions the driver may
auto-complete the ELSs thus if the link does come up, the Abort completions
may reference an invalid structure.

Fix by ensuring that Abort set the flag to avoid link traffic if issued due
to conditions where the link failed.

Link: https://lore.kernel.org/r/20211020211417.88754-7-jsmart2021@gmail.com
Co-developed-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Signed-off-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Signed-off-by: James Smart &lt;jsmart2021@gmail.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
[Shivani: Modified to apply on 5.10.y]
Signed-off-by: Shivani Agarwal &lt;shivani.agarwal@broadcom.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Remove redundant assignment to avoid memory leak</title>
<updated>2025-08-28T14:22:47+00:00</updated>
<author>
<name>Jiasheng Jiang</name>
<email>jiashengjiangcool@gmail.com</email>
</author>
<published>2025-08-01T18:52:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8797e9a827678773fa2465cda8ca1bd6134c952a'/>
<id>urn:sha1:8797e9a827678773fa2465cda8ca1bd6134c952a</id>
<content type='text'>
[ Upstream commit eea6cafb5890db488fce1c69d05464214616d800 ]

Remove the redundant assignment if kzalloc() succeeds to avoid memory
leak.

Fixes: bd2cdd5e400f ("scsi: lpfc: NVME Initiator: Add debugfs support")
Signed-off-by: Jiasheng Jiang &lt;jiashengjiangcool@gmail.com&gt;
Link: https://lore.kernel.org/r/20250801185202.42631-1-jiashengjiangcool@gmail.com
Reviewed-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure</title>
<updated>2025-08-28T14:22:45+00:00</updated>
<author>
<name>Justin Tee</name>
<email>justin.tee@broadcom.com</email>
</author>
<published>2025-06-18T19:21:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74bdf54a847dab209d2a8f65852f59b7fa156175'/>
<id>urn:sha1:74bdf54a847dab209d2a8f65852f59b7fa156175</id>
<content type='text'>
[ Upstream commit 6698796282e828733cde3329c887b4ae9e5545e9 ]

If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the
resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may
occur before sli4_hba.hdwqs are allocated.  This may result in a null
pointer dereference when attempting to take the abts_io_buf_list_lock for
the first hardware queue.  Fix by adding a null ptr check on
phba-&gt;sli4_hba.hdwq and early return because this situation means there
must have been an error during port initialization.

Signed-off-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250618192138.124116-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Use memcpy() for BIOS version</title>
<updated>2025-06-27T10:04:19+00:00</updated>
<author>
<name>Daniel Wagner</name>
<email>wagi@kernel.org</email>
</author>
<published>2025-04-09T11:34:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b699bda5db818b684ff62d140defd6394f38f3d6'/>
<id>urn:sha1:b699bda5db818b684ff62d140defd6394f38f3d6</id>
<content type='text'>
[ Upstream commit ae82eaf4aeea060bb736c3e20c0568b67c701d7d ]

The strlcat() with FORTIFY support is triggering a panic because it
thinks the target buffer will overflow although the correct target
buffer size is passed in.

Anyway, instead of memset() with 0 followed by a strlcat(), just use
memcpy() and ensure that the resulting buffer is NULL terminated.

BIOSVersion is only used for the lpfc_printf_log() which expects a
properly terminated string.

Signed-off-by: Daniel Wagner &lt;wagi@kernel.org&gt;
Link: https://lore.kernel.org/r/20250409-fix-lpfc-bios-str-v1-1-05dac9e51e13@kernel.org
Reviewed-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Fix lpfc_check_sli_ndlp() handling for GEN_REQUEST64 commands</title>
<updated>2025-06-27T10:04:19+00:00</updated>
<author>
<name>Justin Tee</name>
<email>justin.tee@broadcom.com</email>
</author>
<published>2025-04-25T19:47:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f3bfbf87c3f72a37396875a80d189c3ae908f6af'/>
<id>urn:sha1:f3bfbf87c3f72a37396875a80d189c3ae908f6af</id>
<content type='text'>
[ Upstream commit 05ae6c9c7315d844fbc15afe393f5ba5e5771126 ]

In lpfc_check_sli_ndlp(), the get_job_els_rsp64_did remote_id assignment
does not apply for GEN_REQUEST64 commands as it only has meaning for a
ELS_REQUEST64 command.  So, if (iocb-&gt;ndlp == ndlp) is false, we could
erroneously return the wrong value.  Fix by replacing the fallthrough
statement with a break statement before the remote_id check.

Signed-off-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250425194806.3585-2-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Handle duplicate D_IDs in ndlp search-by D_ID routine</title>
<updated>2025-06-04T12:37:05+00:00</updated>
<author>
<name>Justin Tee</name>
<email>justin.tee@broadcom.com</email>
</author>
<published>2025-01-31T00:05:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8281d8f5ca9ed7069de89b7d400754726dbcde4f'/>
<id>urn:sha1:8281d8f5ca9ed7069de89b7d400754726dbcde4f</id>
<content type='text'>
[ Upstream commit 56c3d809b7b450379162d0b8a70bbe71ab8db706 ]

After a port swap between separate fabrics, there may be multiple nodes in
the vport's fc_nodes list with the same fabric well known address.
Duplication is temporary and eventually resolves itself after dev_loss_tmo
expires, but nameserver queries may still occur before dev_loss_tmo.  This
possibly results in returning stale fabric ndlp objects.  Fix by adding an
nlp_state check to ensure the ndlp search routine returns the correct newer
allocated ndlp fabric object.

Signed-off-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250131000524.163662-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: lpfc: Fix a possible data race in lpfc_unregister_fcf_rescan()</title>
<updated>2025-05-02T05:41:08+00:00</updated>
<author>
<name>Tuo Li</name>
<email>islituo@gmail.com</email>
</author>
<published>2023-06-30T02:47:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=192fff6c78231a47f5372ae1411a5a1a81615814'/>
<id>urn:sha1:192fff6c78231a47f5372ae1411a5a1a81615814</id>
<content type='text'>
commit 0e881c0a4b6146b7e856735226208f48251facd8 upstream.

The variable phba-&gt;fcf.fcf_flag is often protected by the lock
phba-&gt;hbalock() when is accessed. Here is an example in
lpfc_unregister_fcf_rescan():

  spin_lock_irq(&amp;phba-&gt;hbalock);
  phba-&gt;fcf.fcf_flag |= FCF_INIT_DISC;
  spin_unlock_irq(&amp;phba-&gt;hbalock);

However, in the same function, phba-&gt;fcf.fcf_flag is assigned with 0
without holding the lock, and thus can cause a data race:

  phba-&gt;fcf.fcf_flag = 0;

To fix this possible data race, a lock and unlock pair is added when
accessing the variable phba-&gt;fcf.fcf_flag.

Reported-by: BassCheck &lt;bass@buaa.edu.cn&gt;
Signed-off-by: Tuo Li &lt;islituo@gmail.com&gt;
Link: https://lore.kernel.org/r/20230630024748.1035993-1-islituo@gmail.com
Reviewed-by: Justin Tee &lt;justin.tee@broadcom.com&gt;
Reviewed-by: Laurence Oberman &lt;loberman@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Bin Lan &lt;bin.lan.cn@windriver.com&gt;
Signed-off-by: He Zhe &lt;zhe.he@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
