On 1 May 2020, at 21:16, Andrii Nakryiko wrote:
> On Fri, May 1, 2020 at 2:56 AM Eelco Chaudron wrote:
>>
>> Let me know, and I sent out a v2.
>
> Yes, that's the split I had in mind, but I'd move
> bpf_object__probe_loading() call directly into bpf_object__load() to
> be the first thing to c
On Fri, May 1, 2020 at 2:56 AM Eelco Chaudron wrote:
>
>
>
> On 30 Apr 2020, at 20:12, Andrii Nakryiko wrote:
>
> > On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron
> > wrote:
> >>
> >> When the probe code was failing for any reason ENOTSUP was returned,
> >> even
> >> if this was due to no having
On 30 Apr 2020, at 20:12, Andrii Nakryiko wrote:
On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron
wrote:
When the probe code was failing for any reason ENOTSUP was returned,
even
if this was due to no having enough lock space. This patch fixes this
by
returning EPERM to the user applicatio
On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron wrote:
>
> When the probe code was failing for any reason ENOTSUP was returned, even
> if this was due to no having enough lock space. This patch fixes this by
> returning EPERM to the user application, so it can respond and increase
> the RLIMIT_MEML
Eelco Chaudron writes:
> When the probe code was failing for any reason ENOTSUP was returned, even
> if this was due to no having enough lock space. This patch fixes this by
> returning EPERM to the user application, so it can respond and increase
> the RLIMIT_MEMLOCK size.
>
> Signed-off-by: Eel
When the probe code was failing for any reason ENOTSUP was returned, even
if this was due to no having enough lock space. This patch fixes this by
returning EPERM to the user application, so it can respond and increase
the RLIMIT_MEMLOCK size.
Signed-off-by: Eelco Chaudron
---
tools/lib/bpf/libb
