mirror of
				https://github.com/torvalds/linux.git
				synced 2025-11-04 10:40:15 +02:00 
			
		
		
		
	libbpf: fix up few libbpf.map problems
Seems like we missed to add 2 APIs to libbpf.map and another API was misspelled. Fix it in libbpf.map. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20220627211527.2245459-16-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
This commit is contained in:
		
							parent
							
								
									bd054102a8
								
							
						
					
					
						commit
						ab9a5a05dc
					
				
					 2 changed files with 4 additions and 3 deletions
				
			
		| 
						 | 
				
			
			@ -326,10 +326,11 @@ LIBBPF_0.7.0 {
 | 
			
		|||
		bpf_xdp_detach;
 | 
			
		||||
		bpf_xdp_query;
 | 
			
		||||
		bpf_xdp_query_id;
 | 
			
		||||
		btf_ext__raw_data;
 | 
			
		||||
		libbpf_probe_bpf_helper;
 | 
			
		||||
		libbpf_probe_bpf_map_type;
 | 
			
		||||
		libbpf_probe_bpf_prog_type;
 | 
			
		||||
		libbpf_set_memlock_rlim_max;
 | 
			
		||||
		libbpf_set_memlock_rlim;
 | 
			
		||||
} LIBBPF_0.6.0;
 | 
			
		||||
 | 
			
		||||
LIBBPF_0.8.0 {
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -76,8 +76,8 @@ enum libbpf_strict_mode {
 | 
			
		|||
	 * first BPF program or map creation operation. This is done only if
 | 
			
		||||
	 * kernel is too old to support memcg-based memory accounting for BPF
 | 
			
		||||
	 * subsystem. By default, RLIMIT_MEMLOCK limit is set to RLIM_INFINITY,
 | 
			
		||||
	 * but it can be overriden with libbpf_set_memlock_rlim_max() API.
 | 
			
		||||
	 * Note that libbpf_set_memlock_rlim_max() needs to be called before
 | 
			
		||||
	 * but it can be overriden with libbpf_set_memlock_rlim() API.
 | 
			
		||||
	 * Note that libbpf_set_memlock_rlim() needs to be called before
 | 
			
		||||
	 * the very first bpf_prog_load(), bpf_map_create() or bpf_object__load()
 | 
			
		||||
	 * operation.
 | 
			
		||||
	 */
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in a new issue