Messages in this thread | | | Date | Thu, 18 Feb 2010 00:13:14 +0800 | From | Cong Wang <> | Subject | Re: [net-next PATCH v4 3/3] net: reserve ports for applications using fixed port numbers |
| |
Eric Dumazet wrote: > Le mardi 16 février 2010 à 21:06 +0800, Cong Wang a écrit : >> 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. >> >> 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 disagree with you. This is perfectly OK. > > A port not being flagged in ip_local_reserved_ports doesnt mean it can > be used for allocation. > > If you want to really block ports from being used at boot, you could for > example : > > # temporarly reduce the ip_local_port_range > echo "61000 61001" >/proc/sys/net/ipv4/ip_local_port_range > # Build our bitmap (could be slow, if a remote database is read) > for port in $LIST_RESERVED_PORT > do > echo $port >/proc/sys/net/ipv4/ip_local_reserved_ports > done > echo "10000 61000" >/proc/sys/net/ipv4/ip_local_port_range > >
I don't think so, if you want to avoid race condition, you just need to write the reserved ports before any networking application starts, IOW, as early as possible during boot.
Thanks.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |