diff mbox series

[net-next,v3] net-loopback: set lo dev initial state to UP

Message ID 20210201233445.2044327-1-jianyang.kernel@gmail.com (mailing list archive)
State Accepted
Commit c9dca822c72914ff33593b12f9fb229f0c0afd47
Delegated to: Netdev Maintainers
Headers show
Series [net-next,v3] net-loopback: set lo dev initial state to UP | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers success CCed 3 of 3 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 1 this patch: 1
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 12 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 1 this patch: 1
netdev/header_inline success Link
netdev/stable success Stable not CCed

Commit Message

Jian Yang Feb. 1, 2021, 11:34 p.m. UTC
From: Jian Yang <jianyang@google.com>

Traditionally loopback devices come up with initial state as DOWN for
any new network-namespace. This would mean that anyone needing this
device would have to bring this UP by issuing something like 'ip link
set lo up'. This can be avoided if the initial state is set as UP.

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: Jian Yang <jianyang@google.com>
---
v3:
  * Addressed Jakub's comment to remove the sysctl knob

v2:
  * Updated sysctl name from `netdev_loopback_state` to `loopback_init_state`
  * Fixed the linking error when CONFIG_SYSCTL is not defined

 drivers/net/loopback.c | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

patchwork-bot+netdevbpf@kernel.org Feb. 5, 2021, 3 a.m. UTC | #1
Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Mon,  1 Feb 2021 15:34:45 -0800 you wrote:
> From: Jian Yang <jianyang@google.com>
> 
> Traditionally loopback devices come up with initial state as DOWN for
> any new network-namespace. This would mean that anyone needing this
> device would have to bring this UP by issuing something like 'ip link
> set lo up'. This can be avoided if the initial state is set as UP.
> 
> [...]

Here is the summary with links:
  - [net-next,v3] net-loopback: set lo dev initial state to UP
    https://git.kernel.org/netdev/net-next/c/c9dca822c729

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Petr Machata Feb. 9, 2021, 11:54 a.m. UTC | #2
Jian Yang <jianyang.kernel@gmail.com> writes:

> From: Jian Yang <jianyang@google.com>
>
> Traditionally loopback devices come up with initial state as DOWN for
> any new network-namespace. This would mean that anyone needing this
> device would have to bring this UP by issuing something like 'ip link
> set lo up'. This can be avoided if the initial state is set as UP.

This will break user scripts, and it fact breaks kernel's very own
selftest. We currently have this internally:

    diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
    index 4c7d33618437..bf8ed24ab3ba 100755
    --- a/tools/testing/selftests/net/fib_nexthops.sh
    +++ b/tools/testing/selftests/net/fib_nexthops.sh
    @@ -121,8 +121,6 @@ create_ns()
     	set -e
     	ip netns add ${n}
     	ip netns set ${n} $((nsid++))
    -	ip -netns ${n} addr add 127.0.0.1/8 dev lo
    -	ip -netns ${n} link set lo up

     	ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
     	ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
    -- 
    2.26.2

This now fails because the ip commands are run within a "set -e" block,
and kernel rejects addition of a duplicate address.
Jakub Kicinski Feb. 9, 2021, 4:23 p.m. UTC | #3
On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> Jian Yang <jianyang.kernel@gmail.com> writes:
> 
> > From: Jian Yang <jianyang@google.com>
> >
> > Traditionally loopback devices come up with initial state as DOWN for
> > any new network-namespace. This would mean that anyone needing this
> > device would have to bring this UP by issuing something like 'ip link
> > set lo up'. This can be avoided if the initial state is set as UP.  
> 
> This will break user scripts, and it fact breaks kernel's very own
> selftest. We currently have this internally:
> 
>     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
>     index 4c7d33618437..bf8ed24ab3ba 100755
>     --- a/tools/testing/selftests/net/fib_nexthops.sh
>     +++ b/tools/testing/selftests/net/fib_nexthops.sh
>     @@ -121,8 +121,6 @@ create_ns()
>      	set -e
>      	ip netns add ${n}
>      	ip netns set ${n} $((nsid++))
>     -	ip -netns ${n} addr add 127.0.0.1/8 dev lo
>     -	ip -netns ${n} link set lo up
> 
>      	ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
>      	ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> 
> This now fails because the ip commands are run within a "set -e" block,
> and kernel rejects addition of a duplicate address.

Thanks for the report, could you send a revert with this explanation?
Petr Machata Feb. 9, 2021, 5:19 p.m. UTC | #4
Jakub Kicinski <kuba@kernel.org> writes:

> Thanks for the report, could you send a revert with this explanation?

Sure.
Mahesh Bandewar Feb. 9, 2021, 6:49 p.m. UTC | #5
On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> > Jian Yang <jianyang.kernel@gmail.com> writes:
> >
> > > From: Jian Yang <jianyang@google.com>
> > >
> > > Traditionally loopback devices come up with initial state as DOWN for
> > > any new network-namespace. This would mean that anyone needing this
> > > device would have to bring this UP by issuing something like 'ip link
> > > set lo up'. This can be avoided if the initial state is set as UP.
> >
> > This will break user scripts, and it fact breaks kernel's very own
> > selftest. We currently have this internally:
> >
> >     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> >     index 4c7d33618437..bf8ed24ab3ba 100755
> >     --- a/tools/testing/selftests/net/fib_nexthops.sh
> >     +++ b/tools/testing/selftests/net/fib_nexthops.sh
> >     @@ -121,8 +121,6 @@ create_ns()
> >       set -e
> >       ip netns add ${n}
> >       ip netns set ${n} $((nsid++))
> >     - ip -netns ${n} addr add 127.0.0.1/8 dev lo
> >     - ip -netns ${n} link set lo up
> >
> >       ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
> >       ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> >
> > This now fails because the ip commands are run within a "set -e" block,
> > and kernel rejects addition of a duplicate address.
>
> Thanks for the report, could you send a revert with this explanation?
Rather than revert, shouldn't we just fix the self-test in that regard?
Jakub Kicinski Feb. 9, 2021, 7:04 p.m. UTC | #6
On Tue, 9 Feb 2021 10:49:23 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:  
> > > This will break user scripts, and it fact breaks kernel's very own
> > > selftest. We currently have this internally:
> > >
> > >     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> > >     index 4c7d33618437..bf8ed24ab3ba 100755
> > >     --- a/tools/testing/selftests/net/fib_nexthops.sh
> > >     +++ b/tools/testing/selftests/net/fib_nexthops.sh
> > >     @@ -121,8 +121,6 @@ create_ns()
> > >       set -e
> > >       ip netns add ${n}
> > >       ip netns set ${n} $((nsid++))
> > >     - ip -netns ${n} addr add 127.0.0.1/8 dev lo
> > >     - ip -netns ${n} link set lo up
> > >
> > >       ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
> > >       ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> > >
> > > This now fails because the ip commands are run within a "set -e" block,
> > > and kernel rejects addition of a duplicate address.  
> >
> > Thanks for the report, could you send a revert with this explanation?  
> Rather than revert, shouldn't we just fix the self-test in that regard?

The selftest is just a messenger. We all know Linus's stand on
regressions, IMO we can't make an honest argument that the change
does not break user space after it broke our own selftest. Maybe 
others disagree..
Ido Schimmel Feb. 9, 2021, 7:06 p.m. UTC | #7
On Tue, Feb 09, 2021 at 10:49:23AM -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> > > Jian Yang <jianyang.kernel@gmail.com> writes:
> > >
> > > > From: Jian Yang <jianyang@google.com>
> > > >
> > > > Traditionally loopback devices come up with initial state as DOWN for
> > > > any new network-namespace. This would mean that anyone needing this
> > > > device would have to bring this UP by issuing something like 'ip link
> > > > set lo up'. This can be avoided if the initial state is set as UP.
> > >
> > > This will break user scripts, and it fact breaks kernel's very own
> > > selftest. We currently have this internally:
> > >
> > >     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> > >     index 4c7d33618437..bf8ed24ab3ba 100755
> > >     --- a/tools/testing/selftests/net/fib_nexthops.sh
> > >     +++ b/tools/testing/selftests/net/fib_nexthops.sh
> > >     @@ -121,8 +121,6 @@ create_ns()
> > >       set -e
> > >       ip netns add ${n}
> > >       ip netns set ${n} $((nsid++))
> > >     - ip -netns ${n} addr add 127.0.0.1/8 dev lo
> > >     - ip -netns ${n} link set lo up
> > >
> > >       ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
> > >       ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> > >
> > > This now fails because the ip commands are run within a "set -e" block,
> > > and kernel rejects addition of a duplicate address.
> >
> > Thanks for the report, could you send a revert with this explanation?
> Rather than revert, shouldn't we just fix the self-test in that regard?

I reviewed such a patch internally and asked Petr to report it as a
regression instead. At the time the new behavior was added under a
sysctl, but nobody had examples for behavior that will break, so the
sysctl was removed. Now we have such an example, so the revert / sysctl
are needed.
Mahesh Bandewar Feb. 9, 2021, 7:18 p.m. UTC | #8
On Tue, Feb 9, 2021 at 11:04 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 9 Feb 2021 10:49:23 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> > > > This will break user scripts, and it fact breaks kernel's very own
> > > > selftest. We currently have this internally:
> > > >
> > > >     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> > > >     index 4c7d33618437..bf8ed24ab3ba 100755
> > > >     --- a/tools/testing/selftests/net/fib_nexthops.sh
> > > >     +++ b/tools/testing/selftests/net/fib_nexthops.sh
> > > >     @@ -121,8 +121,6 @@ create_ns()
> > > >       set -e
> > > >       ip netns add ${n}
> > > >       ip netns set ${n} $((nsid++))
> > > >     - ip -netns ${n} addr add 127.0.0.1/8 dev lo
> > > >     - ip -netns ${n} link set lo up
> > > >
> > > >       ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
> > > >       ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> > > >
> > > > This now fails because the ip commands are run within a "set -e" block,
> > > > and kernel rejects addition of a duplicate address.
> > >
> > > Thanks for the report, could you send a revert with this explanation?
> > Rather than revert, shouldn't we just fix the self-test in that regard?
>
> The selftest is just a messenger. We all know Linus's stand on
> regressions, IMO we can't make an honest argument that the change
> does not break user space after it broke our own selftest. Maybe
> others disagree..

Actually that was the reason behind encompassing this behavior change
with a sysctl.
Mahesh Bandewar Feb. 9, 2021, 7:19 p.m. UTC | #9
On Tue, Feb 9, 2021 at 11:06 AM Ido Schimmel <idosch@idosch.org> wrote:
>
> On Tue, Feb 09, 2021 at 10:49:23AM -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > >
> > > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> > > > Jian Yang <jianyang.kernel@gmail.com> writes:
> > > >
> > > > > From: Jian Yang <jianyang@google.com>
> > > > >
> > > > > Traditionally loopback devices come up with initial state as DOWN for
> > > > > any new network-namespace. This would mean that anyone needing this
> > > > > device would have to bring this UP by issuing something like 'ip link
> > > > > set lo up'. This can be avoided if the initial state is set as UP.
> > > >
> > > > This will break user scripts, and it fact breaks kernel's very own
> > > > selftest. We currently have this internally:
> > > >
> > > >     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> > > >     index 4c7d33618437..bf8ed24ab3ba 100755
> > > >     --- a/tools/testing/selftests/net/fib_nexthops.sh
> > > >     +++ b/tools/testing/selftests/net/fib_nexthops.sh
> > > >     @@ -121,8 +121,6 @@ create_ns()
> > > >       set -e
> > > >       ip netns add ${n}
> > > >       ip netns set ${n} $((nsid++))
> > > >     - ip -netns ${n} addr add 127.0.0.1/8 dev lo
> > > >     - ip -netns ${n} link set lo up
> > > >
> > > >       ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
> > > >       ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> > > >
> > > > This now fails because the ip commands are run within a "set -e" block,
> > > > and kernel rejects addition of a duplicate address.
> > >
> > > Thanks for the report, could you send a revert with this explanation?
> > Rather than revert, shouldn't we just fix the self-test in that regard?
>
> I reviewed such a patch internally and asked Petr to report it as a
> regression instead. At the time the new behavior was added under a
> sysctl, but nobody had examples for behavior that will break, so the
> sysctl was removed. Now we have such an example, so the revert / sysctl
> are needed.

OK, in that case I would prefer to send an incremental patch to
enclose the new behavior with the sysctl (proposed earlier) rather
than the revert. Would that help?
Jakub Kicinski Feb. 9, 2021, 7:43 p.m. UTC | #10
On Tue, 9 Feb 2021 11:18:05 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> On Tue, Feb 9, 2021 at 11:04 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Tue, 9 Feb 2021 10:49:23 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:  
> > > On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski <kuba@kernel.org> wrote:  
> > > > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:  
> > > > > This will break user scripts, and it fact breaks kernel's very own
> > > > > selftest. We currently have this internally:
> > > > >
> > > > >     diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> > > > >     index 4c7d33618437..bf8ed24ab3ba 100755
> > > > >     --- a/tools/testing/selftests/net/fib_nexthops.sh
> > > > >     +++ b/tools/testing/selftests/net/fib_nexthops.sh
> > > > >     @@ -121,8 +121,6 @@ create_ns()
> > > > >       set -e
> > > > >       ip netns add ${n}
> > > > >       ip netns set ${n} $((nsid++))
> > > > >     - ip -netns ${n} addr add 127.0.0.1/8 dev lo
> > > > >     - ip -netns ${n} link set lo up
> > > > >
> > > > >       ip netns exec ${n} sysctl -qw net.ipv4.ip_forward=1
> > > > >       ip netns exec ${n} sysctl -qw net.ipv4.fib_multipath_use_neigh=1
> > > > >
> > > > > This now fails because the ip commands are run within a "set -e" block,
> > > > > and kernel rejects addition of a duplicate address.  
> > > >
> > > > Thanks for the report, could you send a revert with this explanation?  
> > > Rather than revert, shouldn't we just fix the self-test in that regard?  
> >
> > The selftest is just a messenger. We all know Linus's stand on
> > regressions, IMO we can't make an honest argument that the change
> > does not break user space after it broke our own selftest. Maybe
> > others disagree..  
> 
> Actually that was the reason behind encompassing this behavior change
> with a sysctl.

Which as I explained to you is pointless for portable applications.
diff mbox series

Patch

diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index a1c77cc00416..24487ec17f8b 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -219,6 +219,12 @@  static __net_init int loopback_net_init(struct net *net)
 
 	BUG_ON(dev->ifindex != LOOPBACK_IFINDEX);
 	net->loopback_dev = dev;
+
+	/* bring loopback device UP */
+	rtnl_lock();
+	dev_open(dev, NULL);
+	rtnl_unlock();
+
 	return 0;
 
 out_free_netdev: