Index of the BST keys was wrongly initialized to a larger value, a
possible buffer overflow.
Reported-by: Dan Carpenter
Closes:
https://lore.kernel.org/intel-wired-lan/b1fb6ff9-b69e-4026-9988-3c783d86c2e0@stanley.mountain/
Reviewed-by: Przemek Kitszel
Fixes: 9a4c07aaa0f5 ("ice: add parser execu
On Tue, Aug 20, 2024 at 12:21:50PM +0200, Karol Kolacinski wrote:
> From: Michal Michalik
>
> Add specific functions and definitions for E830 devices to enable
> PTP support.
> Introduce new PHY model ICE_PHY_E830.
> E830 devices support direct write to GLTSYN_ registers without shadow
> register
On Tue, Aug 20, 2024 at 12:21:51PM +0200, Karol Kolacinski wrote:
> Simplify TSYN IRQ processing by moving it to a separate function and
> having appropriate behavior per PHY model, instead of multiple
> conditions not related to HW, but to specific timestamping modes.
>
> Reviewed-by: Przemek Kit
On Tue, Aug 20, 2024 at 12:21:49PM +0200, Karol Kolacinski wrote:
> Instead of using shifts and casts, use FIELD_PREP after reading 40b
> timestamp values.
>
> Signed-off-by: Karol Kolacinski
> ---
> V5 -> V6: Replaced removed macros with the new ones
Thanks for the update.
Reviewed-by: Simon H
On Tue, Aug 20, 2024 at 12:21:48PM +0200, Karol Kolacinski wrote:
> Remove unnecessary ice_is_e8xx() functions and PHY model. Instead, use
> MAC type where applicable.
>
> Signed-off-by: Karol Kolacinski
Hi Karol,
Sorry for waiting until v7 until raising this. But I feel that this patch
is doin
haps_hs_smp_defconfig gcc-13.2.0
arc nsimosci_hs_defconfig gcc-13.2.0
arc randconfig-001-20240823 gcc-13.2.0
arc randconfig-002-20240823 gcc-13.2.0
arm allmodconfig gcc-13.2.0
arm
nfig gcc-13.2.0
arc nsimosci_hs_defconfig gcc-13.2.0
arc nsimosci_hs_smp_defconfig gcc-13.2.0
arc randconfig-001-20240823 gcc-13.2.0
arc randconfig-002-20240823 gcc-13.2.0
arcvdk_hs38_smp_defconfig gcc-
haps_hs_smp_defconfig gcc-13.2.0
arc nsimosci_hs_defconfig gcc-13.2.0
arc nsimosci_hs_smp_defconfig gcc-13.2.0
arc randconfig-001-20240823 gcc-13.2.0
arc randconfig-002-20240823 gcc-13.2.0
arc
On Fri, Aug 23, 2024 at 08:23:29AM +0200, Christophe JAILLET wrote:
> In idpf_add_del_mac_filters(), filters are chunked up into multiple
> messages to avoid sending a control queue message buffer that is too large.
>
> Each chunk has up to IDPF_NUM_FILTERS_PER_MSG entries. So except for the
> las
From: Colin Ian King
Date: Thu, 22 Aug 2024 22:34:10 +0100
> Don't populate the read-only arrays tx_itr and rx_itr on the stack at
> run time, instead make them static const.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 4 ++--
> 1 file changed, 2
On Fri, Aug 23, 2024 at 11:59:29AM +0200, Larysa Zaremba wrote:
> Consider the following scenario:
>
> .ndo_bpf()| ice_prepare_for_reset() |
> |___|
> rtnl_lock() |
On Fri, Aug 23, 2024 at 11:59:27AM +0200, Larysa Zaremba wrote:
> The main threat to data consistency in ice_xdp() is a possible asynchronous
> PF reset. It can be triggered by a user or by TX timeout handler.
>
> XDP setup and PF reset code access the same resources in the following
> sections:
>
On Fri, Aug 23, 2024 at 11:59:26AM +0200, Larysa Zaremba wrote:
> Currently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is
> not rtnl-locked when called from the reset. This creates the need to take
> the rtnl_lock just for a single function and complicates the
> synchronization w
After XDP configuration is completed, we bring the interface up
unconditionally, regardless of its state before the call to .ndo_bpf().
Preserve the information whether the interface had to be brought down and
later bring it up only in such case.
Fixes: efc2214b6047 ("ice: Add support for XDP")
R
Locking used in ice_qp_ena() and ice_qp_dis() does pretty much nothing,
because ICE_CFG_BUSY is a state flag that is supposed to be set in a PF
state, not VSI one. Therefore it does not protect the queue pair from
e.g. reset.
Remove ICE_CFG_BUSY locking from ice_qp_dis() and ice_qp_ena().
Fixes:
Consider the following scenario:
.ndo_bpf() | ice_prepare_for_reset() |
|___|
rtnl_lock() | |
ice_down() | |
The main threat to data consistency in ice_xdp() is a possible asynchronous
PF reset. It can be triggered by a user or by TX timeout handler.
XDP setup and PF reset code access the same resources in the following
sections:
* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked
* ice_vs
If VSI rebuild is pending, .ndo_bpf() can attach/detach the XDP program on
VSI without applying new ring configuration. When unconfiguring the VSI, we
can encounter the state in which there is an XDP program but no XDP rings
to destroy or there will be XDP rings that need to be destroyed, but no XD
Currently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is
not rtnl-locked when called from the reset. This creates the need to take
the rtnl_lock just for a single function and complicates the
synchronization with .ndo_bpf. At the same time, there no actual need to
fill napi-to-que
PF reset can be triggered asynchronously, by tx_timeout or by a user. With some
unfortunate timings both ice_vsi_rebuild() and .ndo_bpf will try to access and
modify XDP rings at the same time, causing system crash.
The first patch factors out rtnl-locked code from VSI rebuild code to avoid
deadlo
On 21.08.2024 15:29, Alexander Lobakin wrote:
> From: Wojciech Drewek
> Date: Wed, 21 Aug 2024 14:15:27 +0200
>
>> From: Simei Su
>>
>> To support Rx timestamp offload, VIRTCHNL_OP_1588_PTP_CAPS is sent by
>> the VF to request PTP capability and responded by the PF what capability
>> is enabl
On Fri, Aug 23, 2024 at 08:23:29AM +0200, Christophe JAILLET wrote:
> In idpf_add_del_mac_filters(), filters are chunked up into multiple
> messages to avoid sending a control queue message buffer that is too large.
>
> Each chunk has up to IDPF_NUM_FILTERS_PER_MSG entries. So except for the
> las
Fri, Aug 23, 2024 at 12:25:13AM CEST, arkadiusz.kubalew...@intel.com wrote:
>Allow the user to get and set configuration of Embedded SYNC feature
>on the ice driver dpll pins.
>
>Reviewed-by: Aleksandr Loktionov
>Signed-off-by: Arkadiusz Kubalewski
Reviewed-by: Jiri Pirko
Fri, Aug 23, 2024 at 12:25:12AM CEST, arkadiusz.kubalew...@intel.com wrote:
>Implement and document new pin attributes for providing Embedded SYNC
>capabilities to the DPLL subsystem users through a netlink pin-get
>do/dump messages. Allow the user to set Embedded SYNC frequency with
>pin-set do ne
24 matches
Mail list logo
