On Tue, Sep 1, 2020 at 8:45 AM Willy Tarreau wrote:
>
> +/*
> + * Generate some initially weak seeding values to allow
> + * the prandom_u32() engine to be started.
> + */
> +static int __init prandom_init_early(void)
> +{
> + int i;
> + unsigned long v0, v1, v2, v3;
> +
> +
On Wed, Oct 18, 2017 at 10:38 AM, Jesper Dangaard Brouer
wrote:
>
> On Wed, 18 Oct 2017 09:45:59 +0200 Yann Ylavic wrote:
>
>> On Mon, Oct 16, 2017 at 12:19 PM, Jesper Dangaard Brouer
>> wrote:
>> > +
>> > + /* Notice returns -EPERM on if map
On Mon, Oct 16, 2017 at 12:19 PM, Jesper Dangaard Brouer
wrote:
> +
> + /* Notice returns -EPERM on if map size is larger than memlock limit
> */
> + ret = bpf_map_precharge_memlock(cmap->map.pages);
> + if (ret) {
> + err = ret;
> + goto free_cmap;
>
On Fri, Mar 25, 2016 at 9:53 AM, Willy Tarreau wrote:
>
> On Thu, Mar 24, 2016 at 11:49:41PM -0700, Eric Dumazet wrote:
>> Everything is possible, but do not complain because BPF went in the
>> kernel before your changes.
>
> Don't get me wrong, I'm not complaining, I'm more asking for help to
> tr
On Fri, Mar 25, 2016 at 12:54 AM, Tom Herbert wrote:
> On Thu, Mar 24, 2016 at 4:40 PM, Yann Ylavic wrote:
>>
>> From this POV, draining the (ending) listeners is already non obvious
>> but might be reasonable, (e)BPF sounds really overkill.
>>
> Just the opposit
On Thu, Mar 24, 2016 at 11:49 PM, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 23:40 +0100, Yann Ylavic wrote:
>
>> FWIW, I find:
>>
>> const struct bpf_insn prog[] = {
>> /* BPF_MOV64_REG(BPF_REG_6, BPF_REG_1) */
>> { BPF_ALU64 | BPF_MOV
On Thu, Mar 24, 2016 at 6:55 PM, Daniel Borkmann wrote:
> On 03/24/2016 06:26 PM, Tom Herbert wrote:
>>
>> On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet wrote:
>>>
>>> Really, when BPF can be the solution, we wont allow adding new stuff in
>>> the kernel in the old way.
>>
>> I completely agree wi
