From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6CEA0CD128A for ; Sun, 31 Mar 2024 18:27:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DF08B605E7; Sun, 31 Mar 2024 18:27:56 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id ayA2qqyEjFRz; Sun, 31 Mar 2024 18:27:56 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.34; helo=ash.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1D355605E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1711909676; bh=g9nFqd5ZPhf0MrivK8X8qxssKBX7o+CwVZoQKkpqZAE=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=BcT7vhlMhTRNjYU2bHHp4msIebGUFCfp4g0oMZHOC9cplAkE8p/UW3/kywLI4Xm6z OiGeoJlGyrIgc41EAr4CCFuaOEMBMU3dnD2NBf+Q6l2MuQA70V43ZKUOjqY1EYoOH8 SinRRadWRvpVGmOB9w0VOWEq0pBFYbA/hRWTxv/wazvt3P9HT7POZn32IpUwaFYdMT rfLNVVw5QxA1mxm2GrKsB9zzGeGPmaJh1Y7WdPCjZHi1e/ZlqvxPlhvoHEzZNzhnkk 7mhidoIcVDIm/2k97oJajihIWhOX0/4PoelThm7AH452yT3lCktWLdzbTFJI9s5gLS V5r+AJaAbNDsA== Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp3.osuosl.org (Postfix) with ESMTP id 1D355605E9; Sun, 31 Mar 2024 18:27:56 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 939981BF3CE for ; Sun, 31 Mar 2024 18:27:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 79DB34050B for ; Sun, 31 Mar 2024 18:27:54 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id acs53Wp3draQ for ; Sun, 31 Mar 2024 18:27:53 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=horms@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp4.osuosl.org 7C1B9404BF DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7C1B9404BF Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7C1B9404BF for ; Sun, 31 Mar 2024 18:27:52 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6BD2760AE4; Sun, 31 Mar 2024 18:27:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EF88C433C7; Sun, 31 Mar 2024 18:27:49 +0000 (UTC) Date: Sun, 31 Mar 2024 19:27:47 +0100 From: Simon Horman To: Marcin Szycik Message-ID: <20240331182747.GC26556@kernel.org> References: <20240326164455.735739-1-marcin.szycik@linux.intel.com> <20240328173450.GH651713@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711909671; bh=mqV57eRZ6VoXvr3aBmrVYg1f738OdoqmYDtIlFCSrY8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HL8hyC0WsH91RQqowJxxTGHU1PH70duMJZ96hHGu8QSp7WQbKC6XNFX4o9/PWJt8n pxRmcI7c9hKqMLSja7rizQVs48arwZvX3x7xBq5TmfwAbBiMkj654x47C0CBHS6BEV K1jVqR+FZKOp7Rb4lO4KS72T9swsVW274A4O1GM91c+Ac5F8VeW38+eUT1BmqEm0Li 3VMR2TkFjHgp+v+03tEj5fNC4+Ox+w2XDnDq2wGGEs2DZ8sUdvcW+EdSm7xStjjg8x i6wT9or1a3BAT0bNEzvuOXBu5TSD3IKnPR/taVevfRKXui6Ix57VZWKH08YiIl6yXl i1a4R2aZbv+7Q== X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dmarc=pass (p=none dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=HL8hyC0W Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] ice: Reset VF on Tx MDD event X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wojciech Drewek , netdev@vger.kernel.org, pawel.chmielewski@intel.com, anthony.l.nguyen@intel.com, Liang-Min Wang , intel-wired-lan@lists.osuosl.org Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Fri, Mar 29, 2024 at 12:31:58PM +0100, Marcin Szycik wrote: > > > On 28.03.2024 18:34, Simon Horman wrote: > > On Tue, Mar 26, 2024 at 05:44:55PM +0100, Marcin Szycik wrote: > >> In cases when VF sends malformed packets that are classified as malicious, > >> sometimes it causes Tx queue to freeze. This frozen queue can be stuck > >> for several minutes being unusable. This behavior can be reproduced with > >> a faulty userspace app running on VF. > >> > >> When Malicious Driver Detection event occurs and the mdd-auto-reset-vf > >> private flag is set, perform a graceful VF reset to quickly bring VF back > >> to operational state. Add a log message to notify about the cause of > >> the reset. Add a helper for this to be reused for both TX and RX events. > >> > >> Reviewed-by: Wojciech Drewek > >> Co-developed-by: Liang-Min Wang > >> Signed-off-by: Liang-Min Wang > >> Signed-off-by: Marcin Szycik > > > > Hi Marcin, > > > > If I read this correctly then a reset may be performed for several > > different conditions - values of different registers - for a VF > > as checked in a for loop. > > > > I am wondering if multiple resets could occur for the same VF within > > an iteration of the for loop - because more than one of the conditions is > > met. And, if so, is this ok? > > Hi Simon, > > Good point. Nothing too bad should happen, as ice_reset_vf() acquires mutex lock > (in fact two locks), so several resets would just happen in sequence. However, > it doesn't make much sense to reset VF multiple times, so maybe instead of issuing > reset on each condition, I'll set some flag, and after checking all registers I'll > trigger reset if that flag is set. What do you think? Thanks Marcin, FWIIW, that sounds like a good approach to me. -- pw-bot: changes-requested