- 16 Apr, 2008 23 commits
-
-
Pavel Emelyanov authored
The hashes of tunnels will be per-net too, so prepare all the functions that uses them for this change by adding an argument. Use init_net temporarily in places, where the net does not exist explicitly yet. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Create on in ipip_init_net(), use it all over the code (the proper place to get the net from already exists) and destroy in ipip_net_exit(). Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
When van device is moved to another namespace proc files, related to this device, should also change one. Use the netdev REGISTER and UNREGISTER event handlers for this. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Pavel Emelyanov authored
This one is similar to what I've done for TUN - set the proper net after device allocation and clean VLANs on net exit (use the rtnl_kill_links helper finally). Plus, drop explicit init_net usage and net != &init_net checks. Signed-off-by:
-
Pavel Emelyanov authored
This includes moving one on the struct vlan_net and s/vlan_name_type/vn->name_type/ over the code. Signed-off-by:
-
Pavel Emelyanov authored
It is created in a proper net, so make is show info, related to this particular net. Signed-off-by:
-
Pavel Emelyanov authored
The proc_vlan_dir and proc_vlan_conf migrate on the struct vlan_net and their creation uses the struct net. The devices' entries use the corresponding device's net. Signed-off-by:
-
Pavel Emelyanov authored
All proc files will be created in each net, so prepare them for this change now, not to mess it with real creation patch. The net != &init_net checks in them are for git-bisect sanity, but I will drop them soon. Signed-off-by:
-
Pavel Emelyanov authored
Unlike TUN, it is empty from the very beginning, and will be eventually populated later. Signed-off-by:
-
Pavel Emelyanov authored
Currently vlan group is searched using one key - the ifindex. We'll have to lookup the vlan_group by two keys - ifindex and net. Turning the vlan_group lookup key to struct net_device pointer will make this process easier. Besides, this will eliminate one more place in the networking, that assumes that indexes are unique in the kernel. Signed-off-by:
-
Pavel Emelyanov authored
This one is responsible for calling ->dellink on each net device found in net to help with vlan net_exit hook in the nearest future. Signed-off-by:
-
Pavel Emelyanov authored
Each potential list_del (happening from inside a ->dellink call) is followed by goto restart, so there's no need in _safe iteration. Signed-off-by:
-
Pavel Emelyanov authored
This is basically means that a net is set for a new device, but actually also involves two more steps: 1. mark the tun device as "local", i.e. do not allow for it to move across namespaces. This is done so, since tun device is most often associated to some file (and thus to some process) and moving the device alone is not valid while keeping the file and the process outside. The need in ability to move a detached persistent device is to be investigated later. 2. get the tun device's net when tun becomes attached and put one when it becomes detached. This is needed to handle the case when a task owning the tun dies, but a files lives for some more time - in this case we must not allow for net to be freed, since its exit hook will spoil that file's private data by unregistering the tun from under tun_chr_close. Signed-off-by:
-
Pavel Emelyanov authored
Remove the static tun_dev_list and replace its occurrences in driver with per-net one. It is used in two places - in tun_set_iff and tun_cleanup. In the first case it's legal to use current net_ns. In the cleanup call - move the loop, that unregisters all devices in net exit hook. Signed-off-by:
-
Pavel Emelyanov authored
This is the first step in making tuntap devices work in net namespaces. The structure mentioned is pointed by generic net pointer with tun_net_id id, and tun driver fills one on its load. It will contain only the tun devices list. So declare this structure and introduce net init and exit hooks. Signed-off-by:
-
Ilpo Järvinen authored
Needed can only be more strict than what was checked by the earlier common case check for non-tail skbs, thus cwnd_len <= needed will never match in that case anyway. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Mandeep Singh Baines authored
Currently, it is not possible to read/write to an eeprom larger than 128k in size because the buffer used for temporarily storing the eeprom contents is allocated using kmalloc. kmalloc can only allocate a maximum of 128k depending on architecture. Modified ethtool_get/set_eeprom to only allocate a page of memory and then copy the eeprom a page at a time. Updated original patch as per suggestions from Joe Perches. Signed-off-by:
Mandeep Singh Baines <msb@google.com> Signed-off-by:
-
Oliver Hartkopp authored
Make use of hrtimers to support high resolution capabilities, when provided by the system clocksource. The conversion to hrtimers additionally discovered and solved an unlikely race condition that has been reproduced under (unrealistic) massive receive load, which can only be produced on vcan software devices. [ Fix printf format warnings on 64-bit -DaveM ] Signed-off-by:
Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by:
-
Allan Stephens authored
This patch ensures that TIPC properly handles incoming messages that have incorrect or unexpected formats. Most significantly, it now ensures that each sl_buff has at least as much data as the message header indicates it should, and that the entire message header is stored contiguously; this prevents TIPC from accidentally accessing memory that is not part of the sk_buff. Signed-off-by:
Allan Stephens <allan.stephens@windriver.com> Signed-off-by:
-
Allan Stephens authored
This patch allows TIPC to process incoming messages that are stored in a fragmented sk_buff, by forcing the linearization of any such messages it receives. Note: This is an interim solution to allow TIPC to operate with Ethernet devices that generate non-linear buffers (such as the gianfar driver), until such time as the rest of TIPC is enhanced to handle sk_buffs with multiple data areas. Signed-off-by:
-
Allan Stephens authored
This patch causes TIPC to allocate fast clonable sk_buffs, rather than standard ones. This speeds up the cloning operation done by the link code each time a message is sent off-node. Signed-off-by:
-
Allan Stephens authored
This patch eliminates a null pointer check when discarding a TIPC message buffer, since kfree_skb() already handles this situation. Acknowledgements to Florian Westphal (fw@strlen.de> for suggesting this enhancement. Signed-off-by:
-
- 15 Apr, 2008 12 commits
-
-
Pavel Emelyanov authored
Add the elastic array of void * pointer to the struct net. The access rules are simple: 1. register the ops with register_pernet_gen_device to get the id of your private pointer 2. call net_assign_generic() to put the private data on the struct net (most preferably this should be done in the ->init callback of the ops registered) 3. do not store any private reference on the net_generic array; 4. do not change this pointer while the net is alive; 5. use the net_generic() to get the pointer. When adding a new pointer, I copy the old array, replace it with a new one and schedule the old for kfree after an RCU grace period. Since the net_generic explores the net->gen array inside rcu read section and once set the net->gen->ptr[x] pointer never changes, this grants us a safe access to generic pointers. Quoting Paul: "... RCU is protecting -only- the net_generic structure that net_generic() is traversing, and the [pointer] returned by net_generic() is protected by a reference counter in the upper-level struct net." Signed-off-by:Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Pavel Emelyanov authored
To make some per-net generic pointers, we need some way to address them, i.e. - IDs. This is simple IDA-based IDs generator for pernet subsystems. Addressing questions about potential checkpoint/restart problems: these IDs are "lite-offsets" within the net structure and are by no means supposed to be exported to the userspace. Since it will be used in the nearest future by devices only (tun, vlan, tunnels, bridge, etc), I make it resemble the functionality of register_pernet_device(). The new ids is stored in the *id pointer _before_ calling the init callback to make this id available in this callback. Signed-off-by:
-
Adrian Bunk authored
This patch remove the usage of a nonexisting kconfig variable. Reported-by:
Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Adrian Bunk authored
Even kernel 2.2.26 (sic) already contains the #undef CONFIG_IRLAN_SEND_GRATUITOUS_ARP with the comment "but for some reason the machine crashes if you use DHCP". Either someone finally looks into this or it's simply time to remove this dead code. Reported-by:
-
Adrian Bunk authored
Robert P. J. Day spotted that my removal of the Sangoma drivers missed a few bits. Signed-off-by:
-
Allan Stephens authored
This patch modifies TIPC's socket code to follow the same approach used by other protocols. This change eliminates the need for a mutex in the TIPC-specific portion of the socket protocol data structure -- in its place, the standard Linux socket backlog queue and associated locking routines are utilized. These changes fix a long-standing receive queue bug on SMP systems, and also enable individual read and write threads to utilize a socket without unnecessarily interfering with each other. Signed-off-by:
-
Allan Stephens authored
This patch fixes TIPC's connect routine to conform to Linux kernel style norms of indentation, line length, etc. Signed-off-by:
-
Allan Stephens authored
This patch causes TIPC to return an error indication if the non- blocking form of connect() is requested (which TIPC does not yet support). Signed-off-by:
-
Allan Stephens authored
This patch fixes a bug that allowed TIPC to queue 1 more message than allowed by the socket receive queue threshold limits. The patch also improves the threshold code's logic and naming to help prevent this sort of error from recurring in the future. Signed-off-by:
-
Allan Stephens authored
This patch ensures that padding bytes appearing at the end of an incoming TIPC message are not returned as valid stream data. Signed-off-by:
-
Allan Stephens authored
This patch allows a stream socket to receive data from multiple TIPC messages in its receive queue, without requiring the use of the MSG_WAITALL flag. Acknowledgements to Florian Westphal <fw-tipc@strlen.de> for identifying this issue and suggesting how to correct it. Signed-off-by:
-
Allan Stephens authored
This patch optimizes the receive path for SOCK_DGRAM and SOCK_RDM messages by skipping over code that handles connection-based flow control. Signed-off-by:
-
- 14 Apr, 2008 5 commits
-
-
Denis V. Lunev authored
When CONFIG_SECURITY_NETWORK_XFRM is undefined the following warnings appears: net/xfrm/xfrm_user.c: In function 'xfrm_add_pol_expire': net/xfrm/xfrm_user.c:1576: warning: 'ctx' may be used uninitialized in this function net/xfrm/xfrm_user.c: In function 'xfrm_get_policy': net/xfrm/xfrm_user.c:1340: warning: 'ctx' may be used uninitialized in this function (security_xfrm_policy_alloc is noop for the case). It seems that they are result of the commit 03e1ad7b ("LSM: Make the Labeled IPsec hooks more stack friendly") Signed-off-by:
Denis V. Lunev <den@openvz.org> Signed-off-by:
-
YOSHIFUJI Hideaki authored
Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
YOSHIFUJI Hideaki authored
And use %u to format port. Signed-off-by:
-
-
Pavel Emelyanov authored
I was asked about "why don't we perform a sk_net filtering in bind_conflict calls, like we do in other sock lookup places" for a couple of times. Can we please add a comment about why we do not need one? Signed-off-by:
-
