summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-10Merge tag 'v6.6-p4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in dm-crypt" * tag 'v6.6-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: dm crypt: Fix reqsize in crypt_iv_eboiv_gen
2023-10-10Merge tag 'sound-6.6-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of pending fixes since a couple of weeks ago, which became slightly bigger than usual due to my vacation. Most of changes are about ASoC device-specific fixes while USB- and HD-audio received quirks as usual. All fixes, including two ASoC core changes, are reasonably small and safe to apply" * tag 'sound-6.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (23 commits) ALSA: usb-audio: Fix microphone sound on Nexigo webcam. ALSA: hda/realtek: Change model for Intel RVP board ALSA: usb-audio: Fix microphone sound on Opencomm2 Headset ALSA: hda: cs35l41: Cleanup and fix double free in firmware request ASoC: dt-bindings: fsl,micfil: Document #sound-dai-cells ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM ASoC: tlv320adc3xxx: BUG: Correct micbias setting ASoC: rt5682: Fix regulator enable/disable sequence ASoC: hdmi-codec: Fix broken channel map reporting ASoC: core: Do not call link_exit() on uninitialized rtd objects ASoC: core: Print component name when printing log ASoC: SOF: amd: fix for firmware reload failure after playback ASoC: fsl-asoc-card: use integer type for fll_id and pll_id ASoC: fsl_sai: Don't disable bitclock for i.MX8MP dt-bindings: ASoC: rockchip: Add compatible for RK3128 spdif ASoC: soc-generic-dmaengine-pcm: Fix function name in comment ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP ASoC: simple-card: fixup asoc_simple_probe() error handling ASoC: simple-card-utils: fixup simple_util_startup() error handling ASoC: Intel: sof_sdw: add support for SKU 0B14 ...
2023-10-10netfilter: cleanup struct nft_tableGeorge Guo
Add comments for nlpid, family, udlen and udata in struct nft_table, and afinfo is no longer a member of struct nft_table, so remove the comment for it. Signed-off-by: George Guo <guodongtai@kylinos.cn> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10netfilter: conntrack: prefer tcp_error_log to pr_debugFlorian Westphal
pr_debug doesn't provide any information other than that a packet did not match existing state but also was found to not create a new connection. Replaces this with tcp_error_log, which will also dump packets' content so one can see if this is a stray FIN or RST. Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10netfilter: conntrack: simplify nf_conntrack_alter_replyFlorian Westphal
nf_conntrack_alter_reply doesn't do helper reassignment anymore. Remove the comments that make this claim. Furthermore, remove dead code from the function and place ot in nf_conntrack.h. Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10netfilter: nf_tables: Don't allocate nft_rule_dump_ctxPhil Sutter
Since struct netlink_callback::args is not used by rule dumpers anymore, use it to hold nft_rule_dump_ctx. Add a build-time check to make sure it won't ever exceed the available space. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-10-10netfilter: nf_tables: Carry s_idx in nft_rule_dump_ctxPhil Sutter
In order to move the context into struct netlink_callback's scratch area, the latter must be unused first. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
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-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-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-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-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-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
2023-10-09xdp: Fix zero-size allocation warning in xskq_create()Andrew Kanner
Syzkaller reported the following issue: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2807 at mm/vmalloc.c:3247 __vmalloc_node_range (mm/vmalloc.c:3361) Modules linked in: CPU: 0 PID: 2807 Comm: repro Not tainted 6.6.0-rc2+ #12 Hardware name: Generic DT based system unwind_backtrace from show_stack (arch/arm/kernel/traps.c:258) show_stack from dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) dump_stack_lvl from __warn (kernel/panic.c:633 kernel/panic.c:680) __warn from warn_slowpath_fmt (./include/linux/context_tracking.h:153 kernel/panic.c:700) warn_slowpath_fmt from __vmalloc_node_range (mm/vmalloc.c:3361 (discriminator 3)) __vmalloc_node_range from vmalloc_user (mm/vmalloc.c:3478) vmalloc_user from xskq_create (net/xdp/xsk_queue.c:40) xskq_create from xsk_setsockopt (net/xdp/xsk.c:953 net/xdp/xsk.c:1286) xsk_setsockopt from __sys_setsockopt (net/socket.c:2308) __sys_setsockopt from ret_fast_syscall (arch/arm/kernel/entry-common.S:68) xskq_get_ring_size() uses struct_size() macro to safely calculate the size of struct xsk_queue and q->nentries of desc members. But the syzkaller repro was able to set q->nentries with the value initially taken from copy_from_sockptr() high enough to return SIZE_MAX by struct_size(). The next PAGE_ALIGN(size) is such case will overflow the size_t value and set it to 0. This will trigger WARN_ON_ONCE in vmalloc_user() -> __vmalloc_node_range(). The issue is reproducible on 32-bit arm kernel. Fixes: 9f78bf330a66 ("xsk: support use vaddr as ring") Reported-by: syzbot+fae676d3cf469331fc89@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000c84b4705fb31741e@google.com/T/ Reported-by: syzbot+b132693e925cbbd89e26@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000e20df20606ebab4f@google.com/T/ Signed-off-by: Andrew Kanner <andrew.kanner@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: syzbot+fae676d3cf469331fc89@syzkaller.appspotmail.com Acked-by: Magnus Karlsson <magnus.karlsson@intel.com> Link: https://syzkaller.appspot.com/bug?extid=fae676d3cf469331fc89 Link: https://lore.kernel.org/bpf/20231007075148.1759-1-andrew.kanner@gmail.com
2023-10-09Merge tag 'irqchip-fixes-6.6-2' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zyngier: - DT binding updates for Renesas r8a779f0 and rzg2l - Let GICv3 honor the "dma-non-coherent" attribute for systems that rely on SW guessing what the HW supports - Fix the RISC-V INTC probing by marking all devices as initialised at once - Properly translate interrupt numbers from DT on stm32-exti - Use irq_data_get_irq_chip_data() in the rzg2l driver instead of blindly dereferencing the irq_data structure - Add a MAINTAINERS entry for the various ARM GIC irqchip drivers - Remove myself as the top-level irqchip/irqdomain maintainer Link: https://lore.kernel.org/all/20231007121933.3840357-1-maz@kernel.org
2023-10-09riscv, bpf: Track both a0 (RISC-V ABI) and a5 (BPF) return valuesBjörn Töpel
The RISC-V BPF uses a5 for BPF return values, which are zero-extended, whereas the RISC-V ABI uses a0 which is sign-extended. In other words, a5 and a0 can differ, and are used in different context. The BPF trampoline are used for both BPF programs, and regular kernel functions. Make sure that the RISC-V BPF trampoline saves, and restores both a0 and a5. Fixes: 49b5e77ae3e2 ("riscv, bpf: Add bpf trampoline support for RV64") Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231004120706.52848-3-bjorn@kernel.org
2023-10-09riscv, bpf: Sign-extend return valuesBjörn Töpel
The RISC-V architecture does not expose sub-registers, and hold all 32-bit values in a sign-extended format [1] [2]: | The compiler and calling convention maintain an invariant that all | 32-bit values are held in a sign-extended format in 64-bit | registers. Even 32-bit unsigned integers extend bit 31 into bits | 63 through 32. Consequently, conversion between unsigned and | signed 32-bit integers is a no-op, as is conversion from a signed | 32-bit integer to a signed 64-bit integer. While BPF, on the other hand, exposes sub-registers, and use zero-extension (similar to arm64/x86). This has led to some subtle bugs, where a BPF JITted program has not sign-extended the a0 register (return value in RISC-V land), passed the return value up the kernel, e.g.: | int from_bpf(void); | | long foo(void) | { | return from_bpf(); | } Here, a0 would be 0xffff_ffff, instead of the expected 0xffff_ffff_ffff_ffff. Internally, the RISC-V JIT uses a5 as a dedicated register for BPF return values. Keep a5 zero-extended, but explicitly sign-extend a0 (which is used outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs, a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL). Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2] Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2] Link: https://lore.kernel.org/bpf/20231004120706.52848-2-bjorn@kernel.org
2023-10-09printk: flush consoles before checking progressJohn Ogness
Commit 9e70a5e109a4 ("printk: Add per-console suspended state") removed console lock usage during resume and replaced it with the clearly defined console_list_lock and srcu mechanisms. However, the console lock usage had an important side-effect of flushing the consoles. After its removal, consoles were no longer flushed before checking their progress. Add the console_lock/console_unlock dance to the beginning of __pr_flush() to actually flush the consoles before checking their progress. Also add comments to clarify this additional usage of the console lock. Note that console_unlock() does not guarantee flushing all messages since the commit dbdda842fe96f89 ("printk: Add console owner and waiter logic to load balance console writes"). Reported-by: Todd Brandt <todd.e.brandt@intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217955 Fixes: 9e70a5e109a4 ("printk: Add per-console suspended state") Co-developed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20231006082151.6969-2-pmladek@suse.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 07:11:03 +0000