* [PATCH net] bpf: do not blindly change rlimit in reuseport net selftest
@ 2018-10-06 2:38 Eric Dumazet
2018-10-06 7:23 ` Daniel Borkmann
2018-10-08 8:34 ` Daniel Borkmann
0 siblings, 2 replies; 3+ messages in thread
From: Eric Dumazet @ 2018-10-06 2:38 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, John Sperbeck, Daniel Borkmann
If the current process has unlimited RLIMIT_MEMLOCK,
we should should leave it as is.
Fixes: 941ff6f11c02 ("bpf: fix rlimit in reuseport net selftest")
Signed-off-by: John Sperbeck <jsperbeck@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
---
tools/testing/selftests/net/reuseport_bpf.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/reuseport_bpf.c b/tools/testing/selftests/net/reuseport_bpf.c
index cad14cd0ea922f839d61ca8f78c8e73c9fdb89f5..b5277106df1fd156b5e7c0b30b55952c369b6bd1 100644
--- a/tools/testing/selftests/net/reuseport_bpf.c
+++ b/tools/testing/selftests/net/reuseport_bpf.c
@@ -437,14 +437,19 @@ void enable_fastopen(void)
}
}
-static struct rlimit rlim_old, rlim_new;
+static struct rlimit rlim_old;
static __attribute__((constructor)) void main_ctor(void)
{
getrlimit(RLIMIT_MEMLOCK, &rlim_old);
- rlim_new.rlim_cur = rlim_old.rlim_cur + (1UL << 20);
- rlim_new.rlim_max = rlim_old.rlim_max + (1UL << 20);
- setrlimit(RLIMIT_MEMLOCK, &rlim_new);
+
+ if (rlim_old.rlim_cur != RLIM_INFINITY) {
+ struct rlimit rlim_new;
+
+ rlim_new.rlim_cur = rlim_old.rlim_cur + (1UL << 20);
+ rlim_new.rlim_max = rlim_old.rlim_max + (1UL << 20);
+ setrlimit(RLIMIT_MEMLOCK, &rlim_new);
+ }
}
static __attribute__((destructor)) void main_dtor(void)
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH net] bpf: do not blindly change rlimit in reuseport net selftest
2018-10-06 2:38 [PATCH net] bpf: do not blindly change rlimit in reuseport net selftest Eric Dumazet
@ 2018-10-06 7:23 ` Daniel Borkmann
2018-10-08 8:34 ` Daniel Borkmann
1 sibling, 0 replies; 3+ messages in thread
From: Daniel Borkmann @ 2018-10-06 7:23 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, John Sperbeck
On 10/06/2018 04:38 AM, Eric Dumazet wrote:
> If the current process has unlimited RLIMIT_MEMLOCK,
> we should should leave it as is.
>
> Fixes: 941ff6f11c02 ("bpf: fix rlimit in reuseport net selftest")
> Signed-off-by: John Sperbeck <jsperbeck@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH net] bpf: do not blindly change rlimit in reuseport net selftest
2018-10-06 2:38 [PATCH net] bpf: do not blindly change rlimit in reuseport net selftest Eric Dumazet
2018-10-06 7:23 ` Daniel Borkmann
@ 2018-10-08 8:34 ` Daniel Borkmann
1 sibling, 0 replies; 3+ messages in thread
From: Daniel Borkmann @ 2018-10-08 8:34 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, John Sperbeck
On 10/06/2018 04:38 AM, Eric Dumazet wrote:
> If the current process has unlimited RLIMIT_MEMLOCK,
> we should should leave it as is.
>
> Fixes: 941ff6f11c02 ("bpf: fix rlimit in reuseport net selftest")
> Signed-off-by: John Sperbeck <jsperbeck@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
Applied to bpf, thanks Eric!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-08 15:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-06 2:38 [PATCH net] bpf: do not blindly change rlimit in reuseport net selftest Eric Dumazet
2018-10-06 7:23 ` Daniel Borkmann
2018-10-08 8:34 ` Daniel Borkmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.