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=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_MED,USER_IN_DEF_DKIM_WL 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 03DF6C28CC5 for ; Wed, 5 Jun 2019 03:44:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BFB9720717 for ; Wed, 5 Jun 2019 03:44:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fk9ti/KU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726532AbfFEDn7 (ORCPT ); Tue, 4 Jun 2019 23:43:59 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:40083 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726488AbfFEDn7 (ORCPT ); Tue, 4 Jun 2019 23:43:59 -0400 Received: by mail-wr1-f66.google.com with SMTP id p11so13059469wre.7 for ; Tue, 04 Jun 2019 20:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UaH5smIaZBgencuuSoX6er5NTyn5JhNaoaLpkVh/ukE=; b=fk9ti/KUyJjNb32DipntkblgLRjHv07L/7eqjXSkIqxspSsu9ViYJnHaBmnsHzTNwT GwQo24QMSKYqB2xzVBAMbnvjR1b+g5ufq/CsKZHSgpP5s8xY8MiBMPxCkh/nRTauz5za di2cIu8ylMMgWrBqCEmpXmV2Zq0Qk4KqvT5tKJ9SlDruwXwjuR1LVHn2LOydqTmvHpu3 nJ9rWuxpI0hRzN1bzzTvww6RNk6vuXzbwrWtEmhNJKTTmZ9Xx0o/kAs77rgQyBrF39V3 MVjvkvEgqNqh2N3ZaBoQpimHYX1MHcIsv7F2Ub6te/+R5kztv44iDezg0fwgYTsFqFK+ 2o7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UaH5smIaZBgencuuSoX6er5NTyn5JhNaoaLpkVh/ukE=; b=BLeCVGw1mTuN2RyIX05xJi+2JcYp+OcSU3qvKFgqRI0WqGjEt9/sK96O/XYPNkWioH V437QehdZaroLQ6/yCoXO9UUqFkNrHRCscMhHrOXhz5TKBTUseZsKg6XfH1gBDzHWSey ES2Vgsmxb2YGrJ1JtC/dnsMjgojFGEJDyPNH2q4Md4z2gD4QKCTMU7vshfLcHxKLdKcJ Z7D8N6DDu+lZsqFjvtjX6Es/XnQXmiW64bu6yZWGeS4JeQUn1GTBklzSPeiyourn3jwc 6hMlGkNH1A/ofawfntmO1nf0zRXiXA7alILYumDAycxJRvZOUBR7qr3bQxpPRk3A1Gqj irJw== X-Gm-Message-State: APjAAAVrrN99iFbvS/Y0nloHRajrTZ9u98b903AkG7ozODkTvKHHPYo6 Zrct/FpZqUlXvWvskh3cvWMXXbIpmupsdpy+L2fe9Q== X-Google-Smtp-Source: APXvYqz2fGJyHWBLimWwW66KA2p2XB4+0HJQ7SFx5T2A+GF5c2e19FuWDAfYUuebSSX5iJwbXLtHraObP4lITFtIqfw= X-Received: by 2002:adf:8183:: with SMTP id 3mr9115040wra.181.1559706236552; Tue, 04 Jun 2019 20:43:56 -0700 (PDT) MIME-Version: 1.0 References: <20190507091118.24324-1-liuhangbin@gmail.com> <20190508.093541.1274244477886053907.davem@davemloft.net> <20190605014344.GY18865@dhcp-12-139.nay.redhat.com> <20190605021533.GZ18865@dhcp-12-139.nay.redhat.com> <20190605032926.GA18865@dhcp-12-139.nay.redhat.com> In-Reply-To: <20190605032926.GA18865@dhcp-12-139.nay.redhat.com> From: Lorenzo Colitti Date: Wed, 5 Jun 2019 12:43:44 +0900 Message-ID: Subject: Re: [PATCH net] fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied To: Hangbin Liu Cc: David Ahern , David Miller , Yaro Slav , Thomas Haller , Alistair Strachan , Greg KH , Linux NetDev , David Ahern , =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jun 5, 2019 at 12:29 PM Hangbin Liu wrote: > > We rely on being able to add a rule and either have a dup be created > > (in which case we'll remove it later) or have it fail with EEXIST (in > > which case we won't remove it later). > > With Maciej said, how about add NLM_F_EXCL flag when you add a new rule. > If it returned EEXIST, which means there is an dup rule, you just do not > remove it later. > > Would that fix your issue? We can't do that without rewriting our code and making it more complex. The way the code is structured is that an update is "add all new rules; delete all old rules". To do what you suggest we would need to either change that to "for rule in rules; add newrule; delete oldrule" or we'd need to keep state on which rules already existed. The previous behaviour provided semantics that are useful to userspace, and this commit broke those semantics. Please revert.