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 X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16A8AC282C0 for ; Wed, 23 Jan 2019 19:00:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC2DB2184B for ; Wed, 23 Jan 2019 19:00:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JJTLx3oc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726262AbfAWTAF (ORCPT ); Wed, 23 Jan 2019 14:00:05 -0500 Received: from mail-pl1-f193.google.com ([209.85.214.193]:35329 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725896AbfAWTAE (ORCPT ); Wed, 23 Jan 2019 14:00:04 -0500 Received: by mail-pl1-f193.google.com with SMTP id p8so1629829plo.2 for ; Wed, 23 Jan 2019 11:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=0r9l04WPi/heona1NFiB4lQI5ungkfSLIaTFHIei9iY=; b=JJTLx3ocC+tB0BSua/5f6B2/G/z3ANasVLGfcO5A6Y7inQlfk0imNYrRihrUmpp0Cs qNnfg222cPluc+MmF0kVZo02D1AZfytYU2vQzYpd/VlNnFQsDuDFwqw6DjjLlvo0SqXI L6HkrwNYlpCLOXQ5WURi5SvPUoH93piHwwHovHj8MdPHGWhZJSKQVLa45l2upzNqPwJZ wDJ33s5ptoAvdln4DpeRt5H8gDWVGJZjMul2C6rQwrHaUOUn1wdaDSR1RzL00xXxyFgM tmY/iHfI8z+7Ni+ihM6bmoWzIOW8RSoRqXGicL1zhlYz5qW4XbqD2jE0VX0A1+t6E1tm zAHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0r9l04WPi/heona1NFiB4lQI5ungkfSLIaTFHIei9iY=; b=eL4CW2Xrr6aW5nCIq7ur2Vx8v2gEZ0M9Wz7AdHzEWG3IQnWqeKMpxH9mZQuk4rHgMF UBYgHBWWnh2WvM7m3Sc7lL2AdcivNTPe4TcZAz8E8u8Vb90In3SREj8yP1CWwe0XY4Vz VOoXLJY8VOULkr0kuxOp2//9zc2pm8aDCil3CvuD2hh5mDz3aL/CwznROiqKXSaLLia0 +Ld2U6gvfLIRZbjz2ZhdlhaTg+Xx9GHA76P8RnoGZPJRTAY1F6r6fNoAl/29ItTtpdTK ilOaqR4sdnmg5BPBchQncaupLbIa7BwtNgiG8of+xsmu/No6o3ZfU2nt+vzbGPH6VZfU B6Uw== X-Gm-Message-State: AJcUukfUaMhkxTHGcF/ixjNIEuhZSlPBTHBtSM8C0JzQ6dcFQSvMqCJm tff4guKzIQSa+lJjDQiFbmXE5QrL X-Google-Smtp-Source: ALg8bN6nw5FORKMOj/SjPGdcJ8KO034hMlNqXohOS54P4GPW6r3uvuzhp28lqDYVlSeAVYo5TLC9kw== X-Received: by 2002:a17:902:e012:: with SMTP id ca18mr3405625plb.218.1548270003865; Wed, 23 Jan 2019 11:00:03 -0800 (PST) Received: from ?IPv6:2620:15c:2c1:200:55c7:81e6:c7d8:94b? ([2620:15c:2c1:200:55c7:81e6:c7d8:94b]) by smtp.gmail.com with ESMTPSA id z62sm32679486pfl.33.2019.01.23.11.00.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 11:00:02 -0800 (PST) Subject: Re: [PATCH] net: core: dev: Initialise napi state correctly To: David McKay , Linux Networking References: <20190118124632.17183-1-mckay.david@gmail.com> <40ec5737-8015-0a51-5ef5-2f4cce414500@gmail.com> From: Eric Dumazet Message-ID: <4342bd80-9872-ceff-4660-de710b7f7dbb@gmail.com> Date: Wed, 23 Jan 2019 11:00:01 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 01/23/2019 10:49 AM, David McKay wrote: > On Fri, 18 Jan 2019 at 17:15, Eric Dumazet wrote: >> >> >> >> On 01/18/2019 04:46 AM, Dave McKay wrote: >>> The state member of the napi_struct is not initialised correctly, it >>> sets the SCHED bit without initialising the state to zero first. This >>> results in peculiar behaviour if the original napi_struct didn't come >>> from a zero initialised region to start with. >>> >>> This patch just sets it directly using the appropriate bitfield >>> constant. >>> >>> Signed-off-by: Dave McKay >>> --- >>> net/core/dev.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/net/core/dev.c b/net/core/dev.c >>> index 82f20022259d..250f97bf1973 100644 >>> --- a/net/core/dev.c >>> +++ b/net/core/dev.c >>> @@ -6276,7 +6276,7 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi, >>> #ifdef CONFIG_NETPOLL >>> napi->poll_owner = -1; >>> #endif >>> - set_bit(NAPI_STATE_SCHED, &napi->state); >>> + napi->state = NAPIF_STATE_SCHED; >>> napi_hash_add(napi); >>> } >>> EXPORT_SYMBOL(netif_napi_add); >>> >> >> I am curious, which driver has exhibit any issue with current code ? >> > > gro_cell_init() maybe? > Perfect example of something that would break with your patch :/ alloc_percpu() clears all memory. gro_cells_init() does : set_bit(NAPI_STATE_NO_BUSY_POLL, &cell->napi.state); netif_napi_add(dev, &cell->napi, gro_cell_poll, ...) So clearing napi->state in netif_napi_add() would remove the NAPI_STATE_NO_BUSY_POLL setting.