summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-10netfilter: nf_tables: Carry reset flag in nft_rule_dump_ctxPhil Sutter
This relieves the dump callback from having to check nlmsg_type upon each call and instead performs the check once in .start callback. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10netfilter: nf_tables: Drop pointless memset when dumping rulesPhil Sutter
None of the dump callbacks uses netlink_callback::args beyond the first element, no need to zero the data. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10netfilter: nf_tables: Always allocate nft_rule_dump_ctxPhil Sutter
It will move into struct netlink_callback's scratch area later, just put nf_tables_dump_rules_start in shape to reduce churn later. Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10Revert "btrfs: reject unknown mount options early"David Sterba
This reverts commit 5f521494cc73520ffac18ede0758883b9aedd018. The patch breaks mounts with security mount options like $ mount -o context=system_u:object_r:root_t:s0 /dev/sdX /mn mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdX, missing codepage or helper program, ... We cannot reject all unknown options in btrfs_parse_subvol_options() as intended, the security options can be present at this point and it's not possible to enumerate them in a future proof way. This means unknown mount options are silently accepted like before when the filesystem is mounted with either -o subvol=/path or as followup mounts of the same device. Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com Signed-off-by: David Sterba <dsterba@suse.com>
2023-10-10net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestampWill Mortensen
Commit 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") seems to have accidentally inverted the logic added in commit 0bc73ad46a76 ("net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp"). The impact of this is a little unclear since it seems the FCS scattered with RX-FCS is (usually?) correct regardless. Fixes: 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") Tested-by: Charlotte Tan <charlotte@extrahop.com> Reviewed-by: Charlotte Tan <charlotte@extrahop.com> Cc: Adham Faris <afaris@nvidia.com> Cc: Aya Levin <ayal@nvidia.com> Cc: Tariq Toukan <tariqt@nvidia.com> Cc: Moshe Shemesh <moshe@nvidia.com> Cc: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Will Mortensen <will@extrahop.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20231006053706.514618-1-will@extrahop.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10drm/atomic-helper: relax unregistered connector checkSimon Ser
The driver might pull connectors which weren't submitted by user-space into the atomic state. For instance, intel_dp_mst_atomic_master_trans_check() pulls in connectors sharing the same DP-MST stream. However, if the connector is unregistered, this later fails with: [ 559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered Skip the unregistered connector check to allow user-space to turn off connectors one-by-one. See this wlroots issue: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407 Previous discussion: https://lore.kernel.org/intel-gfx/Y6GX7z17WmDSKwta@ideak-desk.fi.intel.com/ Signed-off-by: Simon Ser <contact@emersion.fr> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231005131623.114379-1-contact@emersion.fr
2023-10-10atm: fore200e: Drop unnecessary of_match_device()Rob Herring
It is not necessary to call of_match_device() in probe. If we made it to probe, then we've already successfully matched. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231006214421.339445-1-robh@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10powerpc/85xx: Fix math emulation exceptionChristophe Leroy
Booting mpc85xx_defconfig kernel on QEMU leads to: Bad trap at PC: fe9bab0, SR: 2d000, vector=800 awk[82]: unhandled trap (5) at 0 nip fe9bab0 lr fe9e01c code 5 in libc-2.27.so[fe5a000+17a000] awk[82]: code: 3aa00000 3a800010 4bffe03c 9421fff0 7ca62b78 38a00000 93c10008 83c10008 awk[82]: code: 38210010 4bffdec8 9421ffc0 7c0802a6 <fc00048e> d8010008 4815190d 93810030 Trace/breakpoint trap WARNING: no useful console This is because allthough CONFIG_MATH_EMULATION is selected, Exception 800 calls unknown_exception(). Call emulation_assist_interrupt() instead. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/066caa6d9480365da9b8ed83692d7101e10ac5f8.1695657339.git.christophe.leroy@csgroup.eu
2023-10-10Merge branch 'mlxsw-fix-wformat-truncation-warnings'Paolo Abeni
Petr Machata says: ==================== mlxsw: Fix -Wformat-truncation warnings Ido Schimmel writes: Commit 6d4ab2e97dcf ("extrawarn: enable format and stringop overflow warnings in W=1") enabled format warnings as part of W=1 builds, resulting in two new warnings in mlxsw. Fix both and target at net-next as the warnings are not indicative of actual bugs. ==================== Link: https://lore.kernel.org/r/cover.1696600763.git.petrm@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10mlxsw: spectrum_ethtool: Fix -Wformat-truncation warningIdo Schimmel
Ethtool stats strings cannot be longer than 32 characters ('ETH_GSTRING_LEN'), including the terminating null byte. The format string '%.29s_%.1d' can exceed this limitation if the per-TC counter name exceeds 28 characters. Together with the underscore, the two digits of the TC (bounded at 16) and the terminating null byte, more than 32 characters will be used. Fix this by bounding the counter name at 28 characters which suppresses the following build warning [1]. This does not affect ethtool output since the longest counter name does not exceed this limitation. [1] drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c: In function ‘mlxsw_sp_port_get_strings’: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:58: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^ In function ‘mlxsw_sp_port_get_tc_strings’, inlined from ‘mlxsw_sp_port_get_strings’ at drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:677:4: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:17: note: ‘snprintf’ output between 3 and 33 bytes into a destination of size 32 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 623 | mlxsw_sp_port_hw_tc_stats[i].str, tc); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c: In function ‘mlxsw_sp_port_get_strings’: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:58: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^ In function ‘mlxsw_sp_port_get_tc_strings’, inlined from ‘mlxsw_sp_port_get_strings’ at drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:677:4: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:17: note: ‘snprintf’ output between 3 and 33 bytes into a destination of size 32 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 623 | mlxsw_sp_port_hw_tc_stats[i].str, tc); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> # build-tested Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10mlxsw: core_thermal: Fix -Wformat-truncation warningIdo Schimmel
The name of a thermal zone device cannot be longer than 19 characters ('THERMAL_NAME_LENGTH - 1'). The format string 'mlxsw-lc%d-gearbox%d' can exceed this limitation if the maximum number of line cards and the maximum number of gearboxes on each line card cannot be represented using a single digit. This is not the case with current systems nor future ones. Therefore, increase the size of the result buffer beyond 'THERMAL_NAME_LENGTH' and suppress the following build warning [1]. If this limitation is ever exceeded, we will know about it since the thermal core validates the thermal device's name during registration. [1] drivers/net/ethernet/mellanox/mlxsw/core_thermal.c: In function ‘mlxsw_thermal_gearboxes_init.constprop’: drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:543:71: error: ‘%d’ directive output may be truncated writing between 1 and 3 bytes into a region of size between 1 and 3 [-Werror=format-truncation=] 543 | snprintf(tz_name, sizeof(tz_name), "mlxsw-lc%d-gearbox%d", | ^~ In function ‘mlxsw_thermal_gearbox_tz_init’, inlined from ‘mlxsw_thermal_gearboxes_init.constprop’ at drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:611:9: drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:543:52: note: directive argument in the range [1, 255] 543 | snprintf(tz_name, sizeof(tz_name), "mlxsw-lc%d-gearbox%d", | ^~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:543:17: note: ‘snprintf’ output between 19 and 23 bytes into a destination of size 20 543 | snprintf(tz_name, sizeof(tz_name), "mlxsw-lc%d-gearbox%d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 544 | gearbox_tz->slot_index, gearbox_tz->module + 1); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> # build-tested Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10net/smc: Fix dependency of SMC on ISMGerd Bayer
When the SMC protocol is built into the kernel proper while ISM is configured to be built as module, linking the kernel fails due to unresolved dependencies out of net/smc/smc_ism.o to ism_get_smcd_ops, ism_register_client, and ism_unregister_client as reported via the linux-next test automation (see link). This however is a bug introduced a while ago. Correct the dependency list in ISM's and SMC's Kconfig to reflect the dependencies that are actually inverted. With this you cannot build a kernel with CONFIG_SMC=y and CONFIG_ISM=m. Either ISM needs to be 'y', too - or a 'n'. That way, SMC can still be configured on non-s390 architectures that do not have (nor need) an ISM driver. Fixes: 89e7d2ba61b7 ("net/ism: Add new API for client registration") Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/linux-next/d53b5b50-d894-4df8-8969-fd39e63440ae@infradead.org/ Co-developed-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> # build-tested Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Link: https://lore.kernel.org/r/20231006125847.1517840-1-gbayer@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10ixgbe: fix crash with empty VF macvlan listDan Carpenter
The adapter->vf_mvs.l list needs to be initialized even if the list is empty. Otherwise it will lead to crashes. Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Link: https://lore.kernel.org/r/ZSADNdIw8zFx1xw2@kadam Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10net: dsa: microchip: Fix uninitialized var in ksz9477_acl_move_entries()Oleksij Rempel
Address an issue in ksz9477_acl_move_entries() where, in the scenario (src_idx == dst_idx), ksz9477_validate_and_get_src_count() returns 0, leading to usage of uninitialized src_count and dst_count variables, which causes undesired behavior as it attempts to move ACL entries around. Fixes: 002841be134e ("net: dsa: microchip: Add partial ACL support for ksz9477 switches") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20231006115822.144152-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10drm/panel: boe-tv101wum-nl6: Completely pull GPW to VGL before TP termRuihai Zhou
The sta_himax83102 panel sometimes shows abnormally flickering horizontal lines. The front gate output will precharge the X point of the next pole circuit before TP(TouchPanel Enable) term starts, and wait until the end of the TP term to resume the CLK. For this reason, the X point must be maintained during the TP term. In abnormal case, we measured a slight leakage at point X. This because during the TP term, the GPW does not fully pull the VGL low, causing the TFT to not be closed tightly. To fix this, we completely pull GPW to VGL before entering the TP term. This will ensure that the TFT is closed tightly and prevent the abnormal display. Fixes: 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel") Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231007064949.22668-1-zhouruihai@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231007064949.22668-1-zhouruihai@huaqin.corp-partner.google.com
2023-10-10Merge branch 'add-update_pn-flag'Paolo Abeni
Radu Pirea says: ==================== Add update_pn flag Patches extracted from https://lore.kernel.org/all/20230928084430.1882670-1-radu-nicolae.pirea@oss.nxp.com/ Update_pn flag will let the offloaded MACsec implementations to know when the PN is updated. ==================== Link: https://lore.kernel.org/r/20231005180636.672791-1-radu-nicolae.pirea@oss.nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10net/mlx5e: macsec: use update_pn flag instead of PN comparationRadu Pirea (NXP OSS)
When updating the SA, use the new update_pn flags instead of comparing the new PN with the initial one. Comparing the initial PN value with the new value will allow the user to update the SA using the initial PN value as a parameter like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 off Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10net: phy: mscc: macsec: reject PN update requestsRadu Pirea (NXP OSS)
Updating the PN is not supported. Return -EINVAL if update_pn is true. The following command succeeded, but it should fail because the driver does not update the PN: ip macsec set macsec0 tx sa 0 pn 232 on Fixes: 28c5107aa904 ("net: phy: mscc: macsec support") Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10octeontx2-pf: mcs: update PN only when update_pn is trueRadu Pirea (NXP OSS)
When updating SA, update the PN only when the update_pn flag is true. Otherwise, the PN will be reset to its previous value using the following command and this should not happen: $ ip macsec set macsec0 tx sa 0 on Fixes: c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading") Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10net: macsec: indicate next pn update when offloadingRadu Pirea (NXP OSS)
Indicate next PN update using update_pn flag in macsec_context. Offloaded MACsec implementations does not know whether or not the MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume that next PN should always updated, but this is not always true. The PN can be reset to its initial value using the following command: $ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case Or, the update PN command will succeed even if the driver does not support PN updates. $ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case Comparing the initial PN with the new PN value is not a solution. When the user updates the PN using its initial value the command will succeed, even if the driver does not support it. Like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10Merge branch 'tcp-save-flowlabel-and-use-for-receiver-repathing'Paolo Abeni
David Morley says: ==================== tcp: save flowlabel and use for receiver repathing This patch series stores the last received ipv6 flowlabel. This last received flowlabel is then used to help decide whether a packet is likely an RTO retransmit or the result of a TLP. This new information is used to better inform the flowlabel change decision for data receivers. ==================== Link: https://lore.kernel.org/r/20231006011841.3558307-1-morleyd.kernel@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10tcp: change data receiver flowlabel after one dupDavid Morley
This commit changes the data receiver repath behavior to occur after receiving a single duplicate. This can help recover ACK connectivity quicker if a TLP was sent along a nonworking path. For instance, consider the case where we have an initially nonworking forward path and reverse path and subsequently switch to only working forward paths. Before this patch we would have the following behavior. +---------+--------+--------+----------+----------+----------+ | Event | For FL | Rev FL | FP Works | RP Works | Data Del | +---------+--------+--------+----------+----------+----------+ | Initial | A | 1 | N | N | 0 | +---------+--------+--------+----------+----------+----------+ | TLP | A | 1 | N | N | 0 | +---------+--------+--------+----------+----------+----------+ | RTO 1 | B | 1 | Y | N | 1 | +---------+--------+--------+----------+----------+----------+ | RTO 2 | C | 1 | Y | N | 2 | +---------+--------+--------+----------+----------+----------+ | RTO 3 | D | 2 | Y | Y | 3 | +---------+--------+--------+----------+----------+----------+ This patch gets rid of at least RTO 3, avoiding additional unnecessary repaths of a working forward path to a (potentially) nonworking one. In addition, this commit changes the behavior to avoid repathing upon rx of duplicate data if the local endpoint is in CA_Loss (in which case the RTOs will already be changing the outgoing flowlabel). Signed-off-by: David Morley <morleyd@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Tested-by: David Morley <morleyd@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10tcp: record last received ipv6 flowlabelDavid Morley
In order to better estimate whether a data packet has been retransmitted or is the result of a TLP, we save the last received ipv6 flowlabel. To make space for this field we resize the "ato" field in inet_connection_sock as the current value of TCP_DELACK_MAX can be fully contained in 8 bits and add a compile_time_assert ensuring this field is the required size. v2: addressed kernel bot feedback about dccp_delack_timer() v3: addressed build error introduced by commit bbf80d713fe7 ("tcp: derive delack_max from rto_min") Signed-off-by: David Morley <morleyd@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Tested-by: David Morley <morleyd@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-10net: ipv4: fix return value check in esp_remove_trailerMa Ke
In esp_remove_trailer(), to avoid an unexpected result returned by pskb_trim, we should check the return value of pskb_trim(). Signed-off-by: Ma Ke <make_ruc2021@163.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2023-10-10net: ipv6: fix return value check in esp_remove_trailerMa Ke
In esp_remove_trailer(), to avoid an unexpected result returned by pskb_trim, we should check the return value of pskb_trim(). Signed-off-by: Ma Ke <make_ruc2021@163.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2023-10-10scsi: Do not rescan devices with a suspended queueDamien Le Moal
Commit ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices") modified scsi_rescan_device() to avoid attempting rescanning a suspended device. However, the modification added a check to verify that a SCSI device is in the running state without checking if the device request queue (in the case of block device) is also running, thus allowing the exectuion of internal requests. Without checking the device request queue, commit ff48b37802e5 fix is incomplete and deadlocks on resume can still happen. Use blk_queue_pm_only() to check if the device request queue allows executing commands in addition to checking the SCSI device state. Reported-by: Petr Tesarik <petr@tesarici.cz> Fixes: ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices") Cc: stable@vger.kernel.org Tested-by: Petr Tesarik <petr@tesarici.cz> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2023-10-10ata: pata_parport: fit3: implement IDE command set registersOndrej Zary
fit3 protocol driver does not support accessing IDE control registers (device control/altstatus). The DOS driver does not use these registers either (as observed from DOSEMU trace). But the HW seems to be capable of accessing these registers - I simply tried bit 3 and it works! The control register is required to properly reset ATAPI devices or they will be detected only once (after a power cycle). Tested with EXP Computer CD-865 with MC-1285B EPP cable and TransDisk 3000. Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2023-10-10ata: pata_parport: add custom version of wait_after_resetOndrej Zary
Some parallel adapters (e.g. EXP Computer MC-1285B EPP Cable) return bogus values when there's no master device present. This can cause reset to fail, preventing the lone slave device (such as EXP Computer CD-865) from working. Add custom version of wait_after_reset that ignores master failure when a slave device is present. The custom version is also needed because the generic ata_sff_wait_after_reset uses direct port I/O for slave device detection. Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2023-10-10ata: pata_parport: implement set_devctlOndrej Zary
Add missing ops->sff_set_devctl implementation. Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2023-10-10ata: pata_parport: fix pata_parport_devchkOndrej Zary
There's a 'x' missing in 0x55 in pata_parport_devchk(), causing the detection to always fail. Fix it. Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2023-10-10hv/hv_kvp_daemon:Support for keyfile based connection profileShradha Gupta
Ifcfg config file support in NetworkManger is deprecated. This patch provides support for the new keyfile config format for connection profiles in NetworkManager. The patch modifies the hv_kvp_daemon code to generate the new network configuration in keyfile format(.ini-style format) along with a ifcfg format configuration. The ifcfg format configuration is also retained to support easy backward compatibility for distro vendors. These configurations are stored in temp files which are further translated using the hv_set_ifconfig.sh script. This script is implemented by individual distros based on the network management commands supported. For example, RHEL's implementation could be found here: https://gitlab.com/redhat/centos-stream/src/hyperv-daemons/-/blob/c9s/hv_set_ifconfig.sh Debian's implementation could be found here: https://github.com/endlessm/linux/blob/master/debian/cloud-tools/hv_set_ifconfig The next part of this support is to let the Distro vendors consume these modified implementations to the new configuration format. Tested-on: Rhel9(Hyper-V, Azure)(nm and ifcfg files verified) Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Signed-off-by: Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/1696847920-31125-1-git-send-email-shradhagupta@linux.microsoft.com
2023-10-09net: refine debug info in skb_checksum_help()Eric Dumazet
syzbot uses panic_on_warn. This means that the skb_dump() I added in the blamed commit are not even called. Rewrite this so that we get the needed skb dump before syzbot crashes. Fixes: eeee4b77dc52 ("net: add more debug info in skb_checksum_help()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20231006173355.2254983-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09tools: ynl-gen: handle do ops with no input attrsJakub Kicinski
The code supports dumps with no input attributes currently thru a combination of special-casing and luck. Clean up the handling of ops with no inputs. Create empty Structs, and skip printing of empty types. This makes dos with no inputs work. Tested-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Link: https://lore.kernel.org/r/20231006135032.3328523-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09Merge branch 'tools-ynl-gen-lift-type-requirement-for-attribute-subsets'Jakub Kicinski
Jiri Pirko says: ==================== tools: ynl-gen: lift type requirement for attribute subsets Remove the requirement from schema files to specify the "type" for attribute subsets and adjust existing schema files. ==================== Link: https://lore.kernel.org/r/20231006114436.1725425-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09netlink: specs: remove redundant type keys from attributes in subsetsJiri Pirko
No longer needed to define type for subset attributes. Remove those. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231006114436.1725425-3-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09tools: ynl-gen: lift type requirement for attribute subsetsJiri Pirko
In case an attribute is used in a subset, the type has to be currently specified. As the attribute is already defined in the original set, this is a redundant information in yaml file, moreover, may lead to inconsistencies. Example: attribute-sets: ... name: pin enum-name: dpll_a_pin attributes: ... - name: parent-id type: u32 ... - name: pin-parent-device subset-of: pin attributes: - name: parent-id type: u32 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Remove the requirement from schema files to specify the "type" for attribute subsets. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231006114436.1725425-2-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09cavium/liquidio: replace deprecated strncpy with strscpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect `app_name` to be NUL-terminated: dev_info(&oct->pci_dev->dev, "Running %s (%llu Hz)\n", app_name, CVM_CAST64(cs->corefreq)); ... and it seems NUL-padding is not required, let's opt for strscpy(). For `oct->boardinfo.name/serial_number` let's opt for strscpy() as well since it is expected to be NUL-terminated and does not require NUL-padding as `oct` is zero-initialized in octeon_device.c +707: | buf = vzalloc(size); | if (!buf) | return NULL; | | oct = (struct octeon_device *)buf; Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-octeon_device-c-v1-1-9a207cef9438@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09liquidio: replace deprecated strncpy with strscpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. NUL-padding is not required as rep_cfg is memset to 0: | memset(&rep_cfg, 0, sizeof(rep_cfg)); A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_vf_rep-c-v1-1-92123a747780@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09net: liquidio: replace deprecated strncpy with strscpy_padJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We know `fw_type` must be NUL-terminated based on use here: | static bool fw_type_is_auto(void) | { | return strncmp(fw_type, LIO_FW_NAME_TYPE_AUTO, | sizeof(LIO_FW_NAME_TYPE_AUTO)) == 0; | } ...and here | module_param_string(fw_type, fw_type, sizeof(fw_type), 0444); Let's opt to NUL-pad the destination buffer as well so that we maintain the same exact behavior that `strncpy` provided here. A suitable replacement is `strscpy_pad` due to the fact that it guarantees both NUL-termination and NUL-padding on the destination buffer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_main-c-v1-1-663e3f1d8f99@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09liquidio: replace deprecated strncpy/strcpy with strscpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. NUL-padding is not required as drvinfo is memset to 0: | memset(drvinfo, 0, sizeof(struct ethtool_drvinfo)); A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_ethtool-c-v1-1-ab565ab4d197@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09bcm63xx_enet: replace deprecated strncpy with strscpyJustin Stitt
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. A suitable replacement is strscpy() [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. bcm_enet_get_drvinfo() already uses strscpy(), let's match it's implementation: | static void bcm_enet_get_drvinfo(struct net_device *netdev, | struct ethtool_drvinfo *drvinfo) | { | strscpy(drvinfo->driver, bcm_enet_driver_name, sizeof(drvinfo->driver)); | strscpy(drvinfo->bus_info, "bcm63xx", sizeof(drvinfo->bus_info)); | } Note that now bcm_enet_get_drvinfo() and bcm_enetsw_get_drvinfo() do the exact same thing. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-broadcom-bcm63xx_enet-c-v1-1-6823b3c3c443@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-09scsi: ufs: core: Correct clear TM error logPeter Wang
The clear TM function error log status was inverted. Fixes: 4693fad7d6d4 ("scsi: ufs: core: Log error handler activity") Signed-off-by: Peter Wang <peter.wang@mediatek.com> Link: https://lore.kernel.org/r/20231003022002.25578-1-peter.wang@mediatek.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-10-09Merge branch 'bpf: Fix src IP addr related limitation in bpf_*_fib_lookup()'Martin KaFai Lau
Martynas Pumputis says: ==================== The patchset fixes the limitation of bpf_*_fib_lookup() helper, which prevents it from being used in BPF dataplanes with network interfaces which have more than one IP addr. See the first patch for more details. Thanks! * v2->v3: Address Martin KaFai Lau's feedback * v1->v2: Use IPv6 stubs to fix compilation when CONFIG_IPV6=m. ==================== Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-10-09selftests/bpf: Add BPF_FIB_LOOKUP_SRC testsMartynas Pumputis
This patch extends the existing fib_lookup test suite by adding two test cases (for each IP family): * Test source IP selection from the egressing netdev. * Test source IP selection when an IP route has a preferred src IP addr. Signed-off-by: Martynas Pumputis <m@lambda.lt> Link: https://lore.kernel.org/r/20231007081415.33502-3-m@lambda.lt Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-10-09bpf: Derive source IP addr via bpf_*_fib_lookup()Martynas Pumputis
Extend the bpf_fib_lookup() helper by making it to return the source IPv4/IPv6 address if the BPF_FIB_LOOKUP_SRC flag is set. For example, the following snippet can be used to derive the desired source IP address: struct bpf_fib_lookup p = { .ipv4_dst = ip4->daddr }; ret = bpf_skb_fib_lookup(skb, p, sizeof(p), BPF_FIB_LOOKUP_SRC | BPF_FIB_LOOKUP_SKIP_NEIGH); if (ret != BPF_FIB_LKUP_RET_SUCCESS) return TC_ACT_SHOT; /* the p.ipv4_src now contains the source address */ The inability to derive the proper source address may cause malfunctions in BPF-based dataplanes for hosts containing netdevs with more than one routable IP address or for multi-homed hosts. For example, Cilium implements packet masquerading in BPF. If an egressing netdev to which the Cilium's BPF prog is attached has multiple IP addresses, then only one [hardcoded] IP address can be used for masquerading. This breaks connectivity if any other IP address should have been selected instead, for example, when a public and private addresses are attached to the same egress interface. The change was tested with Cilium [1]. Nikolay Aleksandrov helped to figure out the IPv6 addr selection. [1]: https://github.com/cilium/cilium/pull/28283 Signed-off-by: Martynas Pumputis <m@lambda.lt> Link: https://lore.kernel.org/r/20231007081415.33502-2-m@lambda.lt Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-10-09drm/amdgpu: fix SI failure due to doorbells allocationIcenowy Zheng
SI hardware does not have doorbells at all, however currently the code will try to do the allocation and thus fail, makes SI AMDGPU not usable. Fix this failure by skipping doorbells allocation when doorbells count is zero. Fixes: 54c30d2a8def ("drm/amdgpu: create kernel doorbell pages") Reviewed-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-10-09drm/amdgpu: add missing NULL checkChristian König
bo->tbo.resource can easily be NULL here. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2902 Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org
2023-10-09drm/amd/display: Don't set dpms_off for seamless bootDaniel Miess
[Why] eDPs fail to light up with seamless boot enabled [How] When seamless boot is enabled don't configure dpms_off in disable_vbios_mode_if_required. Reviewed-by: Charlene Liu <charlene.liu@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Daniel Miess <daniel.miess@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-10-09selftests/bpf: Add testcase for async callback return value failureDavid Vernet
A previous commit updated the verifier to print an accurate failure message for when someone specifies a nonzero return value from an async callback. This adds a testcase for validating that the verifier emits the correct message in such a case. Signed-off-by: David Vernet <void@manifault.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231009161414.235829-2-void@manifault.com
2023-10-09bpf: Fix verifier log for async callback return valuesDavid Vernet
The verifier, as part of check_return_code(), verifies that async callbacks such as from e.g. timers, will return 0. It does this by correctly checking that R0->var_off is in tnum_const(0), which effectively checks that it's in a range of 0. If this condition fails, however, it prints an error message which says that the value should have been in (0x0; 0x1). This results in possibly confusing output such as the following in which an async callback returns 1: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1) The fix is easy -- we should just pass the tnum_const(0) as the correct range to verbose_invalid_scalar(), which will then print the following: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0) Fixes: bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.") Signed-off-by: David Vernet <void@manifault.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231009161414.235829-1-void@manifault.com
generated by cgit (git 2.34.1) at 2025-09-14 10:02:26 +0000