netdev - Re: [PATCH bpf-next v5 1/3] devmap/cpumap: Use flush list instead of bitmap

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]

Date:   Fri, 28 Jun 2019 00:14:31 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        netdev@...r.kernel.org
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        David Miller <davem@...emloft.net>,
        Jonathan Lemon <jonathan.lemon@...il.com>
Subject: Re: [PATCH bpf-next v5 1/3] devmap/cpumap: Use flush list instead of
 bitmap

On 06/23/2019 04:17 AM, Toke Høiland-Jørgensen wrote:
> From: Toke Høiland-Jørgensen <toke@...hat.com>
> 
> The socket map uses a linked list instead of a bitmap to keep track of
> which entries to flush. Do the same for devmap and cpumap, as this means we
> don't have to care about the map index when enqueueing things into the
> map (and so we can cache the map lookup).
> 
> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
[...]
> +static int bq_flush_to_queue(struct xdp_bulk_queue *bq, bool in_napi_ctx)
>  {
> +	struct bpf_cpu_map_entry *rcpu = bq->obj;
>  	unsigned int processed = 0, drops = 0;
>  	const int to_cpu = rcpu->cpu;
>  	struct ptr_ring *q;
> @@ -621,6 +630,9 @@ static int bq_flush_to_queue(struct bpf_cpu_map_entry *rcpu,
>  	bq->count = 0;
>  	spin_unlock(&q->producer_lock);
>  
> +	__list_del(bq->flush_node.prev, bq->flush_node.next);
> +	bq->flush_node.prev = NULL;

Given this and below is a bit non-standard way of using list API, maybe add
these as inline helpers to include/linux/list.h to make sure anyone changing
list API semantics doesn't overlook these in future?

>  	/* Feedback loop via tracepoints */
>  	trace_xdp_cpumap_enqueue(rcpu->map_id, processed, drops, to_cpu);
>  	return 0;
[...]
> +
> +	if (!bq->flush_node.prev)
> +		list_add(&bq->flush_node, flush_list);
> +
>  	return 0;
>  }
>