Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7bec731c-f650-3c03-05d3-d1d430751179@intel.com>
Date:   Tue, 8 Nov 2022 08:40:44 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: [PATCH net] iavf: Do not restart Tx queues after reset task
 failure
Content-Language: en-US
To:     Ivan Vecera <ivecera@redhat.com>, <netdev@vger.kernel.org>
CC:     <sassmann@redhat.com>,
        Patryk Piotrowski <patryk.piotrowski@intel.com>,
        SlawomirX Laba <slawomirx.laba@intel.com>,
        Jesse Brandeburg <jesse.brandeburg@intel.com>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "moderated list:INTEL ETHERNET DRIVERS" 
        <intel-wired-lan@lists.osuosl.org>,
        open list <linux-kernel@vger.kernel.org>
References: <20221108102502.2147389-1-ivecera@redhat.com>
From:   Jacob Keller <jacob.e.keller@intel.com>
In-Reply-To: <20221108102502.2147389-1-ivecera@redhat.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YnpXaWFtYlY2VFVmMUFOY1JUcGdpZ0liNjBBSVBUdlNaaGRZWXRYQS95bVRh?=
 =?utf-8?B?dXZOOWRyTDJPbU5ObzRlV2g2Q1pPbU9VZmFvZnlOaUg0Rm8ySzNHc2g0aHZ2?=
 =?utf-8?B?UkpzWHhmUHdJYlhkdWRSUWU4Y24wZmZyNTRtdGUrcHF6V3pNVHcrelcrTDM2?=
 =?utf-8?B?T05GOHFycFlOWkptWVVVUSsyMmhTUnJTbzduWHpLbFdDcmhYS2xmWTMyMXN0?=
 =?utf-8?B?dEkxMjhYdEJGNE1NU1hEdVYzd1d1VHdSbUI0SFB1UmttMHFMVXB6UmlpdndU?=
 =?utf-8?B?b1pKWTB6dXdCbnQvOXRpUS9oYzFScVhVc3NlSm1HRlpYN3lHSVJocFo3Zloy?=
 =?utf-8?B?QlAwL0t5d2J3SXdTRUFTdVR5U01UMkRXd0tuVDdHWDNzamJQaHhBblI5aXU1?=
 =?utf-8?B?TTFQYXg1cFVoWXo3WjlHdnJyTzFSZVdkcHRmR2tyVjdWSWpFL29nOGY1R2Nz?=
 =?utf-8?B?MXpOYzA1UmNxaFQ1S3kzY1J4UVBkbDNxNktqSzI5Z0pXSHZlT21ISW12aW1V?=
 =?utf-8?B?RXJUK05PVEdRN3pZZ1g1MllzeUQwSzNEZ3BMbHgrVzVMZy9BdWQzVlViVGNu?=
 =?utf-8?B?VjIyMVFqODNiUGhBQzN1Qy9LRlF6UjFqR1ppV25nZmZaWG5NSTVzcVBHZ3NN?=
 =?utf-8?B?cjRFc0FiOU9uNFlidk9kSmpkQzVDbWJhL1FzenZMR1dqdFpPc3lwYjVvbkU4?=
 =?utf-8?B?N1dNdlNBRjRDNFVmN0Rya3dZTUNzaHIrNXk5UEVCZDNLZTdKY3JNTjR4T3Y0?=
 =?utf-8?B?Q25EaU5pVDhJQkRGL0hoZVpjaTZJenpvTXA1MXRSQkFONmpIdnZMb1VGdXJv?=
 =?utf-8?B?OTdHbGd0RlAwdzZ6bnRuMmNPSGhJTnRCNGs5MlZqdUhqZHBZcmtQWDVnTnBa?=
 =?utf-8?B?bVdOaElkUmNlejhDeFJ4Und5N1M1aFZCUmdqdmxYMHkzVEx1bHp4YnBQL3ZQ?=
 =?utf-8?B?eE42TGliK3hsaVAwZFczVVRZU3hvR3JlaXJPM2gveXBVaVc5L2Q0U3JqMG1C?=
 =?utf-8?B?Y3hzVEkyVFFyRlFDU3VPbTZMRFMweFJzSkg1N3ZEUTRTME9hRUdONmtpYjNH?=
 =?utf-8?B?eVRPdk5TWUI5Q0ZoTzFYenlCcXFWRnYzakV2RXRCblNFRldQejFzNksvbWsr?=
 =?utf-8?B?SmtKL2paaXY1NlZ4U3VQUHZLb2dadkNtZjRWYWVlNytUUldvTCtHbGhIUXgw?=
 =?utf-8?B?bllBMVpaM1dJRjRwanBoVkZ1SHQ0b1VEZmNIMGVHRXVmZnFZNVpkbXdYUUJX?=
 =?utf-8?B?UmhmMW9hM0RDR2ZIMXgrYVNRZU1oWTI2MWYycHJXUTVHK2RNODYwb2p2UDdp?=
 =?utf-8?B?eWFFdWU3ZTQ1UU1CaFVaUG5XYVZNSkxHK0tPRm84ekwxUDYvcXZ4Ym5Bb1Qw?=
 =?utf-8?B?SXFmazJpN09oeDQ0M016SGxJQ3hGUi9sUFpSTThxUFZ5Wk1iS1pFMkUzUWd2?=
 =?utf-8?B?SWR2VXU1TTZlYlViYUdyVFAzSktrVUdNQjkzNDdEWWZYZ3Y0aFRvdGkrYmdq?=
 =?utf-8?B?bXdXMlJ0eXN2VndIWHFjaU5zVkRUVU9jQjRHWXpQZEhPQXVXNjY3ajFIa0Rq?=
 =?utf-8?B?QVMyTDR6c2pLNi9HcVpGTzVNSkFNdkw1bk1sNXNadUVKUm0zditZNVcxNG16?=
 =?utf-8?B?ZVFGZXlRbmFXRGJsbm14T2tkT2xZanVKL1RRRGcxTWhpKzB1dnN5THQrTkxF?=
 =?utf-8?B?ZWpqRDY2ckRXSUNsN0ZETHplaUpBbitXdE90eithZzlZOHR0Z3g2cFZOSVlq?=
 =?utf-8?B?V21iV0hpVWlEUzFCcG1uMjlobXY0NFErWC91THFFbFRtVHMrT3oyNUFtTmln?=
 =?utf-8?B?TDhobytPa3JTT0ZjUEZ1emc1Qk10azIxY1ZmMmxDdzU5WktCQ2hMUmJyazlI?=
 =?utf-8?B?eFFXeXRZaFJ4L3dlMmpWaXk4OWg4S2JJaDZucVNDb0RwTkZQKzJMMFBDam0z?=
 =?utf-8?B?ZUV1OTJEK2pPdlBMMWtFRlU3WThKVHlaTzE4VzViRGtVSFJHVXpCWEVlRUZG?=
 =?utf-8?B?NTZtenR5cFJlOS90anpMSVAxbUxEbnFMS0pnRjFvVzR6TzVNeVhIbVRGajZm?=
 =?utf-8?B?N3VBbklESVU4d002TFREQlo0aVVna3NjSG5ibjVmV1pWcFBpN2hqUG9MZ1h5?=
 =?utf-8?B?bDFqR0VCb0NIb0ttZjFTMXhRT29QRXJWN09nMlVncnJiR1VUTDRzRytqT3h1?=
 =?utf-8?B?VGc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 535a79e9-8ead-4229-5a01-08dac1a7fd0f
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5089.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2022 16:40:47.7262
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: b3E4fONHEmplPHkxYFCq4Rxy2+0pvs3P5dY9WZbl/vtladofMdaI+nsXyDuVN4p4E0z+BsspXHJKRKpO/U4NjgXjN8ydI2ua4TL637kznUs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6442
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 11/8/2022 2:25 AM, Ivan Vecera wrote:
> After commit aa626da947e9 ("iavf: Detach device during reset task")
> the device is detached during reset task and re-attached at its end.
> The problem occurs when reset task fails because Tx queues are
> restarted during device re-attach and this leads later to a crash.
> 
> To resolve this issue properly close the net device in cause of
> failure in reset task to avoid restarting of tx queues at the end.
> Also replace the hacky manipulation with IFF_UP flag by device close
> that clears properly both IFF_UP and __LINK_STATE_START flags.
> In these case iavf_close() does not do anything because the adapter
> state is already __IAVF_DOWN.

Thanks for fixing this. I thought we'd removed the last such use of 
incorrect IFF_UP munging in 7d59706dbef8 ("Revert "iavf: Fix deadlock 
occurrence during resetting VF interface""), but apparently we had 
missed one...

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>