net: reserve ports for applications using fixed port numbers
in [Kernel]
|
Prev: power_supply: bq27x00: fix temperature conversion
Next: [PATCH 0/3][GIT PULL][v2.6.34] tracing: updates
From: Eric Dumazet on 16 Feb 2010 08:30 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 17 Feb 2010 11:40 Le jeudi 18 février 2010 à 00:13 +0800, Cong Wang a écrit : > 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. > Sure, but I was thinking retrieving the list of reserved port by a database query, using network :) Anyway, I just feel your argument is not applicable. Our kernel is capable of doing an intersection for us, we dont need to forbid user to mark a port as 'reserved' if this port is already blacklisted by another mechanism (for example, if this port is already in use) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bill Fink on 21 Feb 2010 01:30 On Sat, 20 Feb 2010, Octavian Purdila wrote: > On Saturday 20 February 2010 10:11:40 you wrote: > > Octavian Purdila wrote: > > > This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports which > > > allows users to reserve ports for third-party applications. > > > > > > The reserved ports will not be used by automatic port assignments > > > (e.g. when calling connect() or bind() with port number 0). Explicit > > > port allocation behavior is unchanged. > > > > > > Changes from the previous version: > > > - switch the /proc entry format to coma separated list of range ports > > > - treat -EFAULT just like any other error and acknowledge written values > > > - use isdigit() in proc_get_ulong > > > > > > Octavian Purdila (3): > > > sysctl: refactor integer handling proc code > > > sysctl: add proc_do_large_bitmap > > > net: reserve ports for applications using fixed port numbers > > > > Hi, > > > > This version looks fine for me, but I need to give them a test, and > > I will put feedbacks asap. Thanks for your work! > > > > Still two things: > > > > 1) bitops are always atomic on every arch, right? If yes, then ok. > > AFAIK, yes. > > > 2) I hope you could add some documentation to show the relations > > between ip_local_port_range and ip_local_reserved_ports. > > > > How does this sound: > > ip_local_reserved_ports - list of comma separated ranges > Specify the ports which are reserved for known third-party > applications. These ports will not be used by automatic port > assignments (e.g. when calling connect() or bind() with port > number 0). Explicit port allocation behavior is unchanged. > > The format used for both input and output is a comma separated > list of ranges (e.g. "1,2-4,10-10" for ports 1, 2, 3, 4 and > 10). Writing to the file will clear all previously reserved > ports and update the current list with the one given in the > input. > > Note that ip_local_port_range and ip_local_port_range settings Change second ip_local_port_range to ip_local_reserved_ports. -Bill > are independent and both are considered by the kernel when > determining which ports are available for automatic port > assignments. > > You can reserve ports which are not in the current > ip_local_port_range, e.g.: > > $ cat /proc/sys/net/ipv4/ip_local_port_range > 32000 61000 > $ cat /proc/sys/net/ipv4/ip_local_reserved_ports > 8080,9148 > > although this is redundant. However such a setting is useful > if later the port range is changed to a value that will > include the reserved ports. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 27 Feb 2010 06:40
Eric B., could you look over the first two patches (which touch the sysctl core) and give some review and ACK/NACK? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |