Fpin v11i - #15
Open
johnmeneghini wants to merge 27 commits into
Open
Conversation
rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting. Fixes: 9e4c596 ("Input: synaptics-rmi4 - add support for F3A") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-1-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries. Fixes: 3e64fcb ("Input: synaptics-rmi4 - limit the range of what GPIOs are buttons") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-2-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
amd_ntb_link_disable() prints "Enabling Link" which is misleading. Update the message to reflect that the link is being disabled. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
…hare BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars. Cc: stable@vger.kernel.org Fixes: e75d5ae ("NTB: epf: Allow more flexibility in the memory BAR map method") Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Correct a function name and function parameter name to avoid kernel-doc warnings: Warning: include/linux/ntb.h:575 expecting prototype for ntb_default_port_count(). Prototype was for ntb_default_peer_port_count() instead Warning: include/linux/ntb.h:590 function parameter 'pidx' not described in 'ntb_default_peer_port_number' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
The current list initialisation depends on the well hidden two zeros in the PCI_VDEVICE macro. Instead use a named initialisation that is more robust and easier to understand. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
The register descriptor presence register is a packet register, which means its bytes share a single RMI address. It does not occupy consecutive addresses, and the register structure that follows it is located at the next RMI address (presence_address + 1), not (presence_address + presence_size). Revert the incorrect address calculation introduced in commit a98518e. Reported-by: "Barry K. Nathan" <barryn@pobox.com> Tested-by: "Barry K. Nathan" <barryn@pobox.com> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some touchpads (e.g. ThinkPad T14 Gen 1) have buggy firmware that reports a register descriptor structure size that is too small for the number of registers it claims to have in the presence map. The remaining bytes in the structure are 0, which with the new strict bounds checking causes the parser to fail with -EIO, aborting the device probe. Tolerate such short reads by dropping the remaining (unparseable or 0-size) registers from the list instead of failing the probe, preventing the driver from trying to use them. Fixes: 0adb483 ("Input: rmi4 - refactor register descriptor parsing") Reported-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Commit 44f9200 ("Input: gscps2 - use guard notation when acquiring spinlock") moved the receive loop into gscps2_read_data() and gscps2_report_data(). While moving the code, it preserved the writes to buffer[ps2port->append], but omitted the following producer index update from the original loop: ps2port->append = (ps2port->append + 1) & BUFFER_SIZE; As a result, append never advances. Since gscps2_report_data() only reports bytes while act != append, the receive buffer always appears empty and no keyboard or mouse data reaches the serio core. Restore the omitted index update. Fixes: 44f9200 ("Input: gscps2 - use guard notation when acquiring spinlock") Cc: stable@vger.kernel.org # 6.13+ Signed-off-by: Xu Rao <raoxu@uniontech.com> Link: https://patch.msgid.link/460B5655BA580C60+20260624094739.850306-1-raoxu@uniontech.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
…x/kernel/git/dtor/input Pull more input updates from Dmitry Torokhov: - Updates to Synaptics RMI4 driver to fix potential OOB accesses in F30 and F3A keymap handling - A workaround in Synaptics RMI4 to tolerate buggy firmware on some touchpads (e.g. ThinkPad T14 Gen 1) that report incomplete register descriptor structures, preventing probe failures - A revert of an incorrect register descriptor address calculation in Synaptics RMI4 driver - A fix for a regression in HP GSC PS/2 (gscps2) driver where the receive buffer write index was not advanced, leaving keyboard and mouse unusable. * tag 'input-for-v7.2-rc0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: gscps2 - advance receive buffer write index Input: rmi4 - tolerate short register descriptor structure Revert "Input: rmi4 - fix register descriptor address calculation" Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
Pull NTB updates from Jon Mason: "An EPF bug fix to prevent an invalid unmap during device removal, along with documentation fixes and minor AMD driver cleanups" * tag 'ntb-7.2' of https://github.com/jonmason/ntb: ntb: amd: Use named initializer for pci_device_id::driver_data NTB: fix kernel-doc warnings in ntb.h NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR ntb_hw_amd: Fix incorrect debug message in link disable path
This reverts commit 19bc5f2. So we have been seeing failures in our internal qla2xxx FPIN testing for a while. These failures are due to this commit and has been reported internally at Red Hat. Recently Sustaining Engineering asked us to put in a patch to resolve this issue. The fix is to rever the patch: commit 19bc5f2 Author: Jiasheng Jiang <jiashengjiangcool@gmail.com> Date: Tue Jan 6 20:53:44 2026 +0000 scsi: qla2xxx: Sanitize payload size to prevent member overflow Unfortunately this fix does not work. Moveover, truncating the received FPIN data seemed like a bad idea in general. There was a previous attempt to fix this, but it did not work right either: commit 6f4b102 Author: Gustavo A. R. Silva <gustavoars@kernel.org> Date: Wed Aug 13 16:07:44 2025 -0400 scsi: qla2xxx: Fix memcpy() field-spanning write issue So John reverted it: commit 285654d Author: John Meneghini <jmeneghi@redhat.com> Date: Thu Sep 25 09:07:29 2025 -0400 Revert "scsi: qla2xxx: Fix memcpy() field-spanning write issue" Signed-off-by: John Meneghini <jmeneghi@redhat.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Reviewed-by: David Jeffery <djeffery@redhat.com>
Signed-off-by: John Meneghini <jmeneghi@redhat.com>
In qla_edif_bsg.h: `struct fc_bsg_reply` and `struct fc_bsg_request` have flexible array members, thus they must be the last member of the parent structure. Contininging in the effort to add `-Wflex-array-member-not-at-end`, move the structs to the end of the parent structures, `struct qla_bsg_auth_els_reply` and `struct qla_bsg_auth_els_request `. Suggested-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: Jesse Taube <jtaubepe@redhat.com>
Introduce 'union fc_tlv_desc' to have a common structure for all FC ELS TLV structures and avoid type casts. Fixes: 44b6169 ("scsi: fc: Avoid -Wflex-array-member-not-at-end warnings") Commit 44b6169 ("scsi: fc: Avoid -Wflex-array-member-not-at-end warnings") conflicts with this change. To solve the problem I moved the fc_els_rdf_hdr and fc_els_rdf_resp_hdr definitions out of fc_els.h and into lpfc_hw4.h. Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Co-developed-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: Hannes Reinecke <hare@kernel.org> Tested-by: Bryan Gurney <bgurney@redhat.com>
Add a new controller flag, NVME_CTRL_MARGINAL, to help multipath I/O policies to react to a path that is set to a "marginal" state. The flag is cleared on controller reset, which is often the case when faulty cabling or transceiver hardware is replaced. Signed-off-by: Bryan Gurney <bgurney@redhat.com>
FPIN LI (link integrity) messages are received when the attached fabric detects hardware errors. In response to these messages I/O should be directed away from the affected ports, and only used if no other non-marginal paths are available. To handle this a new controller flag 'NVME_CTRL_MARGINAL' is added which will cause the multipath scheduler to skip these paths when checking for 'optimized' paths. This is a distinct change from the previous version which treated marginal paths as non-optimized but still usable. This changes the priority of marginal paths to be lower than non-optimized paths. Signed-off-by: Jesse Taube <jtaubepe@redhat.com> Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Exclude marginal paths from queue-depth io policy. In the case where all paths are marginal and no optimized or non-optimized path is found, we fall back and select the best marginal path. Signed-off-by: Jesse Taube <jtaubepe@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com>
Exclude marginal paths from round-robin io policy. In the case where all paths are marginal and no optimized or non-optimized path is found, we fall back and perform round-robin on the marginal paths. Signed-off-by: Jesse Taube <jtaubepe@redhat.com>
If a controller has received a link integrity or congestion event, and has the NVME_CTRL_MARGINAL flag set, emit "marginal" in the state instead of "live", to identify the marginal paths. Co-developed-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Tested-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Bryan Gurney <bgurney@redhat.com>
Add fc_fpin_set_marginal function to evaluate the FPIN LI TLV information and set the 'marginal' path status for all affected nvme rports. Then call set_rport_marginal() callback added to fc_function_template. The implementation of set_rport_marginal() is almost identical to set_rport_dev_loss_tmo implementation. Co-developed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Hannes Reinecke <hare@kernel.org> Tested-by: Bryan Gurney <bgurney@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com> --- why do we check rport->roles & FC_PORT_ROLE_NVME_TARGET but not in the sysfs commit
Refactor and fc_rport_set_marginal_state smp safe by holding
`shost->host_lock` around all `rport->port_state` accesses.
Call nvme_fc_modify_rport_fpin_state() when FC_PORTSTATE_MARGINAL is set
or cleared. This allows the user to quickly set or clear the
NVME_CTRL_MARGINAL state from sysfs.
E.g.:
echo "Marginal" > /sys/class/fc_remote_ports/rport-13:0-5/port_state
echo "Online" > /sys/class/fc_remote_ports/rport-13:0-5/port_state
Note: nvme_fc_modify_rport_fpin_state() will only affect rports that
have FC_PORT_ROLE_NVME_TARGET set.
Signed-off-by: John Meneghini <jmeneghi@redhat.com>
Add nvme_fc_set_remoteport_fpin() and supporting functions. This function is called by the SCSI FC transport and driver layer to set or clear the 'marginal' path status for a specific rport. Co-developed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Hannes Reinecke <hare@kernel.org> Tested-by: Bryan Gurney <bgurney@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com>
Implement set_rport_marginal callback using nvme_fc_set_remoteport_fpin() to enable FPIN notifications for NVMe. Co-developed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Hannes Reinecke <hare@kernel.org> Tested-by: Bryan Gurney <bgurney@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com>
Implement set_rport_marginal callback using nvme_fc_set_remoteport_fpin() to enable FPIN notifications for NVMe. Co-developed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Hannes Reinecke <hare@kernel.org> Tested-by: Bryan Gurney <bgurney@redhat.com> Signed-off-by: John Meneghini <jmeneghi@redhat.com>
To allow testing of multipath failover, add a sysfs attribute to set a remote port as marginal. This will allow the fcloop LLDD to set the marginal flag on a remote port, simulating a marginal link. Example: Turn on marginal for a remote port matching wwnn and wwpn: `echo 'wwnn=0x200000109b5f2956,wwpn=0x100000109b5f2956,marginal=1' > /sys/class/fcloop/ctl/set_rport_marginal` Turn off marginal for a remote port matching wwnn and wwpn: `echo 'wwnn=0x200000109b5f2956,wwpn=0x100000109b5f2956,marginal=0' > /sys/class/fcloop/ctl/set_rport_marginal` Suggested-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: Jesse Taube <jtaubepe@redhat.com> (cherry picked from commit 22b51a2)
johnmeneghini
force-pushed
the
fpin_base
branch
from
August 4, 2026 20:47
9bd6ac1 to
5b49f67
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Latest FPIN-LI changes for native nvme multipath based on Linux 7.2-rc1