mirror of
				https://github.com/torvalds/linux.git
				synced 2025-11-04 02:30:34 +02:00 
			
		
		
		
	net: trust the bitmap in __dev_alloc_name()
Prior to restructuring __dev_alloc_name() handled both printf and non-printf names. In a clever attempt at code reuse it always prints the name into a buffer and checks if it's a duplicate. Trust the bitmap, and return an error if its full. This shrinks the possible ID space by one from 32K to 32K - 1, as previously the max value would have been tried as a valid ID. It seems very unlikely that anyone would care as we heard no requests to increase the max beyond 32k. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20231023152346.3639749-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
		
							parent
							
								
									9a81046812
								
							
						
					
					
						commit
						7ad17b04dc
					
				
					 1 changed files with 4 additions and 11 deletions
				
			
		| 
						 | 
				
			
			@ -1119,18 +1119,11 @@ static int __dev_alloc_name(struct net *net, const char *name, char *res)
 | 
			
		|||
 | 
			
		||||
	i = find_first_zero_bit(inuse, max_netdevices);
 | 
			
		||||
	bitmap_free(inuse);
 | 
			
		||||
	if (i == max_netdevices)
 | 
			
		||||
		return -ENFILE;
 | 
			
		||||
 | 
			
		||||
	snprintf(buf, IFNAMSIZ, name, i);
 | 
			
		||||
	if (!netdev_name_in_use(net, buf)) {
 | 
			
		||||
		strscpy(res, buf, IFNAMSIZ);
 | 
			
		||||
		return i;
 | 
			
		||||
	}
 | 
			
		||||
 | 
			
		||||
	/* It is possible to run out of possible slots
 | 
			
		||||
	 * when the name is long and there isn't enough space left
 | 
			
		||||
	 * for the digits, or if all bits are used.
 | 
			
		||||
	 */
 | 
			
		||||
	return -ENFILE;
 | 
			
		||||
	snprintf(res, IFNAMSIZ, name, i);
 | 
			
		||||
	return i;
 | 
			
		||||
}
 | 
			
		||||
 | 
			
		||||
/* Returns negative errno or allocated unit id (see __dev_alloc_name()) */
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in a new issue