On Tue, Feb 21, 2017 at 02:00:13PM +0100, Jesper Dangaard Brouer wrote:
> On Tue, 21 Feb 2017 00:06:11 -0800
> Alexei Starovoitov wrote:
>
> > On Mon, Feb 20, 2017 at 05:25:58PM +0100, Jesper Dangaard Brouer wrote:
> > > On Mon, 20 Feb 2017 16:57:34 +0100
> > > Daniel Borkmann wrote:
> > >
>
On Tue, 21 Feb 2017 00:06:11 -0800
Alexei Starovoitov wrote:
> On Mon, Feb 20, 2017 at 05:25:58PM +0100, Jesper Dangaard Brouer wrote:
> > On Mon, 20 Feb 2017 16:57:34 +0100
> > Daniel Borkmann wrote:
> >
> > > On 02/20/2017 04:35 PM, Jesper Dangaard Brouer wrote:
> > > > It is confusing us
On Mon, Feb 20, 2017 at 05:25:58PM +0100, Jesper Dangaard Brouer wrote:
> On Mon, 20 Feb 2017 16:57:34 +0100
> Daniel Borkmann wrote:
>
> > On 02/20/2017 04:35 PM, Jesper Dangaard Brouer wrote:
> > > It is confusing users of samples/bpf that exceeding the resource
> > > limits for RLIMIT_MEMLOCK
On Mon, 20 Feb 2017 16:57:34 +0100
Daniel Borkmann wrote:
> On 02/20/2017 04:35 PM, Jesper Dangaard Brouer wrote:
> > It is confusing users of samples/bpf that exceeding the resource
> > limits for RLIMIT_MEMLOCK result in an "Operation not permitted"
> > message. This is due to bpf limits check
On 02/20/2017 04:35 PM, Jesper Dangaard Brouer wrote:
It is confusing users of samples/bpf that exceeding the resource
limits for RLIMIT_MEMLOCK result in an "Operation not permitted"
message. This is due to bpf limits check return -EPERM.
Instead return -ENOMEM, like most other users of this A
It is confusing users of samples/bpf that exceeding the resource
limits for RLIMIT_MEMLOCK result in an "Operation not permitted"
message. This is due to bpf limits check return -EPERM.
Instead return -ENOMEM, like most other users of this API.
Fixes: aaac3ba95e4c ("bpf: charge user for creation