Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755103AbdCTWZa (ORCPT <rfc822;w@1wt.eu>);
        Mon, 20 Mar 2017 18:25:30 -0400
Received: from mail-pf0-f194.google.com ([209.85.192.194]:36444 "EHLO
        mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753046AbdCTWZ2 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 20 Mar 2017 18:25:28 -0400
Message-ID: <1490048171.16816.85.camel@edumazet-glaptop3.roam.corp.google.com>
Subject: Re: [net-next PATCH 1/2] net: Busy polling should ignore sender CPUs
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        sridhar.samudrala@intel.com, edumazet@google.com, davem@davemloft.net
Date: Mon, 20 Mar 2017 15:16:11 -0700
In-Reply-To: <20170320214848.13922.79201.stgit@localhost.localdomain>
References: <20170320214643.13922.51284.stgit@localhost.localdomain>
         <20170320214848.13922.79201.stgit@localhost.localdomain>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1254
Lines: 31

On Mon, 2017-03-20 at 14:48 -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> This patch is a cleanup/fix for NAPI IDs following the changes that made it
> so that sender_cpu and napi_id were doing a better job of sharing the same
> location in the sk_buff.
> 
> One issue I found is that we weren't validating the napi_id as being valid
> before we started trying to setup the busy polling.  This change corrects
> that by using the MIN_NAPI_ID value that is now used in both allocating the
> NAPI IDs, as well as validating them.
> 
> Fixes: 52bd2d62ce675 ("net: better skb->sender_cpu and skb->napi_id cohabitation")
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---

This Fixes: tag seems not really needed here.

If really busy polling is attempted to a socket with a <wrong> napi id,
nothing bad happens. This fits the advisory model of busy polling...

Otherwise, your patch would be a candidate for net tree.

Also note that as soon as sk_can_busy_loop(sk) returns some status,
another cpu might already have changed sk->sk_napi_id to something else,
possibly with a <wrong> napi id again.

If your upcoming code depends on sk->sk_napi_id being verified, then
you need to read it once.