[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTSdHCszjFtkZj37KE-1rfSfzYEd5oXLyKS6Kz9pdi05ReA@mail.gmail.com>
Date: Mon, 23 May 2022 09:32:02 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Yun Lu <luyun_611@....com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
davem@...emloft.net, edumazet@...gle.com, netdev@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] selftests/net: enable lo.accept_local in psock_snd test
On Mon, May 23, 2022 at 5:25 AM Yun Lu <luyun_611@....com> wrote:
>
> On 2022/5/20 下午9:52, Willem de Bruijn wrote:
>
> > On Fri, May 20, 2022 at 2:40 AM Yun Lu <luyun_611@....com> wrote:
> >> From: luyun <luyun@...inos.cn>
> >>
> >> The psock_snd test sends and recievs packets over loopback, but the
> >> parameter lo.accept_local is disabled by default, this test will
> >> fail with Resource temporarily unavailable:
> >> sudo ./psock_snd.sh
> >> dgram
> >> tx: 128
> >> rx: 142
> >> ./psock_snd: recv: Resource temporarily unavailable
> > I cannot reproduce this failure.
> >
> > Passes on a machine with accept_local 0.
> >
> > accept_local is defined as
> >
> > "
> > accept_local - BOOLEAN
> > Accept packets with local source addresses. In combination
> > with suitable routing, this can be used to direct packets
> > between two local interfaces over the wire and have them
> > accepted properly.
> > "
> I did this test on my system(Centos 8.3 X86_64):
>
> [root@...alhost net]# sysctl net.ipv4.conf.lo.accept_local
> net.ipv4.conf.lo.accept_local = 0
> [root@...alhost net]# ./psock_snd -d
> tx: 128
> rx: 142
> ./psock_snd: recv: Resource temporarily unavailable
> [root@...alhost net]# sysctl -w net.ipv4.conf.lo.accept_local=1
> net.ipv4.conf.lo.accept_local = 1
> [root@...alhost net]# ./psock_snd -d
> tx: 128
> rx: 142
> rx: 100
> OK
>
> This failure does seem to be related to accept_local.
>
> Also, it's reported on Ubuntu:
> https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1812618
That is an old kernel, 4.18 derived.
I simply am unable to reproduce this on an upstream v4.18 or v5.18.
Likely something with either the distro kernel release, or another
distro feature that interacts with this. Can you try v5.18 or another
clean upstream kernel?
Else it requires instrumenting IN_DEV_ACCEPT_LOCAL tests to understand
where this sysctl makes a meaningful change for you when running this
test.
Powered by blists - more mailing lists