Hi David Ahern,
On Fri, May 31, 2019 at 06:43:42PM -0700, Maciej Żenczykowski wrote:
> FYI, this userspace visible change in behaviour breaks Android.
>
> 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).
>
> Returning 0 makes atomically changing a rule difficult.
>
> Please revert.
What do you think? Should I rever this commit?
Although I'm still not clear what's the difference between
a) adding a dup rule and remove it later
and
b) return 0 directly if the rule exactally the same.
Thanks
Hangbin
>
> On Wed, May 8, 2019 at 9:39 AM David Miller <da...@davemloft.net> wrote:
> >
> > From: Hangbin Liu <liuhang...@gmail.com>
> > Date: Tue, 7 May 2019 17:11:18 +0800
> >
> > > With commit 153380ec4b9 ("fib_rules: Added NLM_F_EXCL support to
> > > fib_nl_newrule") we now able to check if a rule already exists. But this
> > > only works with iproute2. For other tools like libnl, NetworkManager,
> > > it still could add duplicate rules with only NLM_F_CREATE flag, like
> > >
> > > [localhost ~ ]# ip rule
> > > 0: from all lookup local
> > > 32766: from all lookup main
> > > 32767: from all lookup default
> > > 100000: from 192.168.7.5 lookup 5
> > > 100000: from 192.168.7.5 lookup 5
> > >
> > > As it doesn't make sense to create two duplicate rules, let's just return
> > > 0 if the rule exists.
> > >
> > > Fixes: 153380ec4b9 ("fib_rules: Added NLM_F_EXCL support to
> > > fib_nl_newrule")
> > > Reported-by: Thomas Haller <thal...@redhat.com>
> > > Signed-off-by: Hangbin Liu <liuhang...@gmail.com>
> >
> > Applied and queued up for -stable, thanks.
