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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 624F0C10F03 for ; Tue, 23 Apr 2019 16:51:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2EBC42148D for ; Tue, 23 Apr 2019 16:51:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="ZNlXc0MY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728737AbfDWQvh (ORCPT ); Tue, 23 Apr 2019 12:51:37 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:36812 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728609AbfDWQvh (ORCPT ); Tue, 23 Apr 2019 12:51:37 -0400 Received: by mail-qt1-f194.google.com with SMTP id c35so2147908qtk.3 for ; Tue, 23 Apr 2019 09:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=p2qqZydyoFlB+hG1tNQ3na5BMWmg2uvLVaHF12I6Xes=; b=ZNlXc0MYPGEMCzc3cO01XZssRuVMNsCGRLiYLqfCpld64fwxjWHjIC0D12ywBrPuG9 mdqA6B2NNsJDNZOehNP+7D29grx8tc9YeWCk82zKqzfu1lFWSMRwf1k00PmzIiwQ7WAQ IWI/LPkHe2OqQG30wd5VVl7CFHv08p4j6nIqUyUovGDHFSj0xJ5SoMeZ7oKqXhznfq7K 0i9UMy5/CpQbmGrRJjGqkRknKeD9ezhmYTWnj76zQ0wkwWne3G9kCSPmLS9BEhoDuZt8 tHgzjgbFOma9+mV9c09zGCPGuGE4EiNR6IowZur2FtgVSupqY7ZemUqq6adW/jEVsueK nJ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=p2qqZydyoFlB+hG1tNQ3na5BMWmg2uvLVaHF12I6Xes=; b=egOIQBFZtsf+LnozUU/aLpaNzkIMQhZ8Pih1R3F0juuuDFxlZW2CEABT0+1CXyUiqK rgN7zs8dC6doj3EQeZsB9QEWkDwuHkpXfSq0dJUeFIvJTUMG7tnXje5fDPk4UMq+7OGb SoG2AcHPH+iU+XfOyPo5eZiTf0OfIxbrz5UwIY71CLt1VJXQsKUTXac3OOZg3uYr2m3x Myo+xemclVT1V6ufWgB6lUIexLUkJ762KJ8yVS+WUxt5X8OOphb8xRYE1TeE2NfDi1O9 PIaHDmeLO5WIBKhsATOKeMPRaSNdHSs5NZ3vodDKM00eadh73MQQEezRwTBIjCbp/Zd4 TLlw== X-Gm-Message-State: APjAAAVgitNeFIs3+4UrgF+PhyvYPT3l5+goBh4zKNmupaNldeaqhxvy LqFIS8VXbtmn+LCkeZs+hTQZrzTHLNk= X-Google-Smtp-Source: APXvYqyIe4gQEzzpYatl3/7UrVfbueM8otqsc408ZQl6IblLW6uEBFz/BvvXu5+Pnc/NwTEqd/Ha6w== X-Received: by 2002:ac8:1b38:: with SMTP id y53mr21363253qtj.130.1556038296429; Tue, 23 Apr 2019 09:51:36 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id c5sm4533897qta.15.2019.04.23.09.51.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Apr 2019 09:51:36 -0700 (PDT) Date: Tue, 23 Apr 2019 09:51:31 -0700 From: Jakub Kicinski To: Vlad Buslov Cc: "netdev@vger.kernel.org" , "jhs@mojatatu.com" , "xiyou.wangcong@gmail.com" , "jiri@resnulli.us" , "davem@davemloft.net" Subject: Re: [PATCH net-next] net: sched: flower: refactor reoffload for concurrent access Message-ID: <20190423095131.41383446@cakuba.netronome.com> In-Reply-To: References: <20190422072135.4176-1-vladbu@mellanox.com> <20190422140227.421a6e94@cakuba.netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 23 Apr 2019 07:34:20 +0000, Vlad Buslov wrote: > >> @@ -382,6 +395,8 @@ static void fl_hw_destroy_filter(struct tcf_proto *tp, struct cls_fl_filter *f, > >> > >> tc_setup_cb_call(block, TC_SETUP_CLSFLOWER, &cls_flower, false); > >> spin_lock(&tp->lock); > >> + if (!list_empty(&f->hw_list)) > >> + list_del_init(&f->hw_list); > > > > Mm. I thought list_del_init() on an empty list should be fine? > > Is it? Implementation of list_del_init() doesn't seem to check if list > is empty before re-initializing its pointers. Technically it seems like > it can work because the implementation will just set pointers of empty > list to point to itself (which is how empty list head is defined), but > should we assume this is intended behavior and not just implementation > detail? I don't see anything in comments for this function that suggests > that it is okay to call list_del_init() on empty list head. Mm.. I'd do it, IDK if there was ever an official ruling by the supreme court of Linus or any such ;) __list_del_entry_valid() looks like it'd not complain. Up to you, in general it didn't read very idiomatic, that's all.