netdev - Re: VRF and/or cgroups problem on Fedora-30, 5.2.21+ kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ffbeb74f-09d5-e854-190e-5362cc703a10@candelatech.com>
Date:   Fri, 22 Nov 2019 16:23:51 -0800
From:   Ben Greear <greearb@...delatech.com>
To:     David Ahern <dsahern@...il.com>, netdev <netdev@...r.kernel.org>
Subject: Re: VRF and/or cgroups problem on Fedora-30, 5.2.21+ kernel

On 11/22/19 4:17 PM, David Ahern wrote:
> On 11/22/19 5:14 PM, Ben Greear wrote:
>> On 11/22/19 4:06 PM, David Ahern wrote:
>>> On 11/22/19 5:03 PM, Ben Greear wrote:
>>>> Hello,
>>>>
>>>> We see a problem on a particular system when trying to run 'ip vrf exec
>>>> _vrf1 ping 1.1.1.1'.
>>>> This system reproduces the problem all the time, but other systems with
>>>> exact same (as far as
>>>> we can tell) software may fail occasionally, but then it will work
>>>> again.
>>>>
>>>> Here is an strace output.  I changed to the
>>>> "/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-2.scope/vrf/_vrf1"
>>>>
>>>>
>>>> directory as root user, and could view the files in that directory, so
>>>> I'm not sure why the strace shows error 5.
>>>>
>>>> Any idea what could be the problem and/or how to fix it or debug
>>>> further?
>>>>
>>>>
>>>> This command was run as root user.
>>>
>>> check 'ulimit -l'. BPF is used to set the VRF and it requires locked
>>> memory.
>>
>> It is set to '64'.  What is a good value to use?
>>
> 
> This is a pain point in using BPF for this. It's really use case
> dependent. 128kB, 256kB.
> 

Setting:  ulimit -l 1024

'fixed' the problem.

I'd rather waste a bit of memory and not have any of my users hit such an esoteric
bug, so I'll set it to at least 1024 going forward.

Would large numbers of vrf and/or network devices mean you need more locked memory?

And surely 'ip' could output a better error than just 'permission denied' for
this error case?  Or even something that would show up in dmesg to give a clue?

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com