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  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:	Tue, 16 Feb 2010 16:25:22 +0200
From:	Octavian Purdila <>
To:	Cong Wang <>
Cc:	David Miller <>,
	Linux Kernel Network Developers <>,
	Linux Kernel Developers <>,
	Neil Horman <>,
	Eric Dumazet <>
Subject: Re: [net-next PATCH v4 3/3] net: reserve ports for applications using fixed port numbers

On Tuesday 16 February 2010 15:06:26 you wrote:
> Octavian Purdila wrote:
> > On Tuesday 16 February 2010 11:37:04 you wrote:
> >>>  	BUILD_BUG_ON(sizeof(struct inet_skb_parm) > sizeof(dummy_skb->cb));
> >>>
> >>> +	sysctl_local_reserved_ports = kzalloc(65536 / 8, GFP_KERNEL);
> >>> +	if (!sysctl_local_reserved_ports)
> >>> +		goto out;
> >>> +
> >>
> >> I think we should also consider the ports in ip_local_port_range,
> >> since we can only reserve the ports in that range.
> >
> > That is subject to changes at runtime, which means we will have to
> > readjust the bitmap at runtime which introduces the need for additional
> > synchronization operations which I would rather avoid.
> Why? As long as the bitmap is global, this will not be hard.

For the more important point see bellow, but with regard to reallocation, this 
means we need to at least use rcu_read_lock() in the fast path to avoid races 
between freeing the old bitmap and doing a read in progress. 

Granted, that is a light operation, but would it makes things so much more 
complicated just so that we save one memory page (assuming the range is the 
default [32000 64000] one).

> Consider that if one user writes a port number which is beyond
> the ip_local_port_range into ip_local_reserved_ports, we should
> not accept this, because it doesn't make any sense. But with your
> patch, we do.

I think it should be allowed. I see ip_local_reserved_ports and ip_local_range 
as independent settings that can be change at any time.

That way I can flag port 8080 even if the current range is [32000, 64000] and 
then later I can expand the range to [1024, 64000] without loosing the 8080 
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists