- 19 Mar, 2015 20 commits
-
-
David S. Miller authored
Erik Hugne says: ==================== tipc: small bugfix an support for datagram connect() Most notable in this series is patch#3 that allows programs to associate a tipc address with a connectionless (RDM/DGRAM) socket. v2: Fix indent issue in patch#3 ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Erik Hugne authored
Following the example of ip4_datagram_connect, we store the address in the socket structure for dgram/rdm sockets and use that as the default destination for subsequent send() calls. It is allowed to connect to any address types, and the behaviour of send() will be the same as a normal sendto() with this address provided. Binding to an AF_UNSPEC address clears the association. Signed-off-by:
Erik Hugne <erik.hugne@ericsson.com> Reviewed-by:
Ying Xue <ying.xue@windriver.com> Reviewed-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Erik Hugne authored
Since commit 1186adf7 ("tipc: simplify message forwarding and rejection in socket layer") -EHOSTUNREACH is propagated back to the sending process if we fail to deliver the message to another socket local to the node. This is wrong, host unreachable should only be reported when the destination port/name does not exist in the cluster, and that check is always done before sending the message. Also, this introduces inconsistent sendmsg() behavior for local/remote destinations. Errors occurring on the receiving side should not trickle up to the sender. If message delivery fails TIPC should either discard the packet or reject it back to the sender based on the destination droppable option. Signed-off-by:
-
Erik Hugne authored
tipc_node_remove_conn may be called twice if shutdown() is called on a socket that have messages in the receive queue. Calling this function twice does no harm, but is unnecessary and we remove the redundant call. Signed-off-by:
-
Wu Fengguang authored
Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Jörg Thalheim authored
Signed-off-by:
Jörg Thalheim <joerg@higgsboson.tk> Signed-off-by:
-
David S. Miller authored
When a networking device is taken down that has a non-trivial number of VLAN devices configured under it, we eat a full synchronize_net() for every such VLAN device. This is because of the call chain: NETDEV_DOWN notifier --> vlan_device_event() --> dev_change_flags() --> __dev_change_flags() --> __dev_close() --> __dev_close_many() --> dev_deactivate_many() --> synchronize_net() This is kind of rediculous because we already have infrastructure for batching doing operation X to a list of net devices so that we only incur one sync. So make use of that by exporting dev_close_many() and adjusting it's interfaace so that the caller can fully manage the batch list. Use this in vlan_device_event() and all the overhead goes away. Reported-by:
Salam Noureddine <noureddine@arista.com> Signed-off-by:
-
Eric Dumazet authored
On a large hash table, we can easily spend seconds to walk over all entries. Add a cond_resched() to yield cpu if necessary. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David Ahern authored
Implement the phys_port_name operation. Port names are pulled from the rocker hardware model in qemu and default to the qemu name + port id. e.g., sw1p1: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether 52:54:00:12:35:01 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 where 'sw1' comes from the qemu command line -device rocker,name=sw1, and 'p1' is port 1. Patch is adapted from Scott's phys_port_id patch. Signed-off-by:David Ahern <dsahern@gmail.com> Acked-by:
Scott Feldman <sfeldma@gmail.com> Acked-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
David Ahern authored
Similar to port id allow netdevices to specify port names and export the name via sysfs. Drivers can implement the netdevice operation to assist udev in having sane default names for the devices using the rule: $ cat /etc/udev/rules.d/80-net-setup-link.rules SUBSYSTEM=="net", ACTION=="add", ATTR{phys_port_name}!="", NAME="$attr{phys_port_name}" Use of phys_name versus phys_id was suggested-by Jiri Pirko. Signed-off-by: -
Marcelo Ricardo Leitner authored
Currently, if a multicast join operation fail, the vxlan interface will be UP but not functional, without even a log message informing the user. Now that we can grab socket lock after already having rntl, we don't need to defer socket creation and multicast operations. By not deferring we can do proper error reporting to the user through ip exit code. This patch thus removes all deferred work that vxlan had and put it back inline. Now the socket will only be created, bound and join multicast group when one bring the interface up, and will undo all that as soon as one put the interface down. As vxlan_sock_hold() is not used after this patch, it was removed too. Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Marcelo Ricardo Leitner authored
in favor of their inner __ ones, which doesn't grab rtnl. As these functions need to operate on a locked socket, we can't be grabbing rtnl by then. It's too late and doing so causes reversed locking. So this patch: - move rtnl handling to callers instead while already fixing some reversed locking situations, like on vxlan and ipvs code. - renames __ ones to not have the __ mark: __ip_mc_{join,leave}_group -> ip_mc_{join,leave}_group __ipv6_sock_mc_{join,drop} -> ipv6_sock_mc_{join,drop} Signed-off-by:Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Marcelo Ricardo Leitner authored
There are some setsockopt operations in ipv4 and ipv6 that are grabbing rtnl after having grabbed the socket lock. Yet this makes it impossible to do operations that have to lock the socket when already within a rtnl protected scope, like ndo dev_open and dev_stop. We normally take coarse grained locks first but setsockopt inverted that. So this patch invert the lock logic for these operations and makes setsockopt grab rtnl if it will be needed prior to grabbing socket lock. Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== inet: tcp listener refactoring, part 13 inet_hash functions are in a bad state : Too much IPv6/IPv4 copy/pasting. Lets refactor a bit. Idea is that we do not want to have an equivalent of inet_csk(sk)->icsk_af_ops for request socks in order to be able to use the right variant. In this patch series, I started to let IPv6/IPv4 converge to common helpers. Idea is to use ipv6_addr_set_v4mapped() even for AF_INET sockets, so that we can test if (sk->sk_family == AF_INET6 && !ipv6_addr_v4mapped(&sk->sk_v6_daddr)) to tell if we deal with an IPv6 socket, or IPv4 one, at least in slow paths. Ideally, we could save 8 bytes per struct sock_common, if we alias skc_daddr & skc_rcv_saddr to skc_v6_daddr[3]/skc_v6_rcv_saddr[3]. ==================== Signed-off-by: -
Eric Dumazet authored
In order to be able to use sk_ehashfn() for request socks, we need to initialize their IPv6/IPv4 addresses. Signed-off-by:
-
Eric Dumazet authored
We now always call __inet_hash_nolisten(), no need to pass it as an argument. Signed-off-by:
-
Eric Dumazet authored
We can now use inet_hash() and __inet_hash() instead of private functions. Signed-off-by:
-
Eric Dumazet authored
Intent is to converge IPv4 & IPv6 inet_hash functions to factorize code. IPv4 sockets initialize sk_rcv_saddr and sk_v6_daddr in this patch, thanks to new sk_daddr_set() and sk_rcv_saddr_set() helpers. __inet6_hash can now use sk_ehashfn() instead of a private inet6_sk_ehashfn() and will simply use __inet_hash() in a following patch. Signed-off-by:
-
Eric Dumazet authored
Goal is to unify IPv4/IPv6 inet_hash handling, and use common helpers for all kind of sockets (full sockets, timewait and request sockets) inet_sk_ehashfn() becomes sk_ehashfn() but still only copes with IPv4 Signed-off-by:
-
Eric Dumazet authored
const qualifiers ease code review by making clear which objects are not written in a function. Signed-off-by:
-
- 18 Mar, 2015 20 commits
-
-
David S. Miller authored
Or Gerlitz says: ==================== Add max rate TXQ attribute Add the ability to set a max-rate limitation for TX queues. The attribute name is maxrate and the units are Mbs, to make it similar to the existing max-rate limitation knobs (ETS and SRIOV ndo calls). changes from V2: - added Documentation (thanks Florian and Tom) - rebased to latest net-next to comply with the swdev ndo removal - addressed more feedback from Dave on the comments style changes from V1: - addressed feedback from Dave changes from V0: - addressed feedback from Sergei John Fastabend (1): net: Add max rate tx queue attribute ==================== Signed-off-by: -
Or Gerlitz authored
Add ndo_set_tx_maxrate support. To support per tx queue maxrate limit, we use the update-qp firmware command to do run-time rate setting for the qp that serves this tx ring. Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Ido Shamay <idos@mellanox.com> Signed-off-by:
-
Or Gerlitz authored
Add the low-level device commands and definitions used for QP max-rate limiting. This is done through the following elements: - read rate-limit device caps in QUERY_DEV_CAP: number of different rates and the min/max rates in Kbs/Mbs/Gbs units - enhance the QP context struct to contain rate limit units and value - allow to do run time rate-limit setting to QPs through the update-qp firmware command - QP rate-limiting is disallowed for VFs Signed-off-by: -
John Fastabend authored
This adds a tx_maxrate attribute to the tx queue sysfs entry allowing for max-rate limiting. Along with DCB-ETS and BQL this provides another knob to tune queue performance. The limit units are Mbps. By default it is disabled. To disable the rate limitation after it has been set for a queue, it should be set to zero. Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Signed-off-by:
-
David S. Miller authored
Herbert Xu says: ==================== rhashtable: Kill redundant shift parameter I was trying to squeeze bucket_table->rehash in by downsizing bucket_table->size, only to find that my spot had been taken over by bucket_table->shift. These patches kill shift and makes me feel better :) v2 corrects the typo in the test_rhashtable changelog and also notes the min_shift parameter in the tipc patch changelog. ==================== Acked-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Herbert Xu authored
Now that nobody uses max_shift and min_shift, we can safely remove them. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
This patch converts test_rhashtable to use rhashtable max_size instead of the obsolete max_shift. Signed-off-by:
-
Herbert Xu authored
This patch converts tipc to use rhashtable max/min_size instead of the obsolete max/min_shift. Signed-off-by:
-
Herbert Xu authored
This patch converts netlink to use rhashtable max_size instead of the obsolete max_shift. Signed-off-by:
-
Herbert Xu authored
This patch adds the parameters max_size and min_size which are meant to replace max_shift and min_shift. Signed-off-by:
-
Herbert Xu authored
Keeping both size and shift is silly. We only need one. Signed-off-by:
-
David S. Miller authored
Keyur Chudgar says: ==================== drivers: net: xgene: Add second SGMII based 1G interface This patch adds support for second SGMII based 1G interface. ==================== Signed-off-by:
Keyur Chudgar <kchudgar@apm.com> Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
-
Keyur Chudgar authored
- Added resource initialization based on port-id field - Enabled second SGMII 1G interface Signed-off-by:
-
Keyur Chudgar authored
- Added new SGMII node for port 1 - Added port-id field Signed-off-by:
-
Keyur Chudgar authored
Signed-off-by:
-
David S. Miller authored
Ying Xue says: ==================== tipc: fix netns refcnt leak The series aims to eliminate the issue of netns refcount leak. But during fixing it, another two additional problems are found. So all of known issues associated with the netns refcnt leak are resolved at the same time in the patchset. ==================== Signed-off-by: -
Ying Xue authored
The TIPC topology server is a per namespace service associated with the tipc name {1, 1}. When a namespace is deleted, that name must be withdrawn before we call sk_release_kernel because the kernel socket release is done in init_net and trying to withdraw a TIPC name published in another namespace will fail with an error as: [ 170.093264] Unable to remove local publication [ 170.093264] (type=1, lower=1, ref=2184244004, key=2184244005) We fix this by breaking the association between the topology server name and socket before calling sk_release_kernel. Signed-off-by: -
Ying Xue authored
[ 28.531768] ============================================= [ 28.532322] [ INFO: possible recursive locking detected ] [ 28.532322] 3.19.0+ #194 Not tainted [ 28.532322] --------------------------------------------- [ 28.532322] insmod/583 is trying to acquire lock: [ 28.532322] (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000d219>] tipc_nametbl_remove_publ+0x49/0x2e0 [tipc] [ 28.532322] [ 28.532322] but task is already holding lock: [ 28.532322] (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000e0dc>] tipc_nametbl_stop+0xfc/0x1f0 [tipc] [ 28.532322] [ 28.532322] other info that might help us debug this: [ 28.532322] Possible unsafe locking scenario: [ 28.532322] [ 28.532322] CPU0 [ 28.532322] ---- [ 28.532322] lock(&(&nseq->lock)->rlock); [ 28.532322] lock(&(&nseq->lock)->rlock); [ 28.532322] [ 28.532322] *** DEADLOCK *** [ 28.532322] [ 28.532322] May be due to missing lock nesting notation [ 28.532322] [ 28.532322] 3 locks held by insmod/583: [ 28.532322] #0: (net_mutex){+.+.+.}, at: [<ffffffff8163e30f>] register_pernet_subsys+0x1f/0x50 [ 28.532322] #1: (&(&tn->nametbl_lock)->rlock){+.....}, at: [<ffffffffa000e091>] tipc_nametbl_stop+0xb1/0x1f0 [tipc] [ 28.532322] #2: (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000e0dc>] tipc_nametbl_stop+0xfc/0x1f0 [tipc] [ 28.532322] [ 28.532322] stack backtrace: [ 28.532322] CPU: 1 PID: 583 Comm: insmod Not tainted 3.19.0+ #194 [ 28.532322] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 28.532322] ffffffff82394460 ffff8800144cb928 ffffffff81792f3e 0000000000000007 [ 28.532322] ffffffff82394460 ffff8800144cba28 ffffffff810a8080 ffff8800144cb998 [ 28.532322] ffffffff810a4df3 ffff880013e9cb10 ffffffff82b0d330 ffff880013e9cb38 [ 28.532322] Call Trace: [ 28.532322] [<ffffffff81792f3e>] dump_stack+0x4c/0x65 [ 28.532322] [<ffffffff810a8080>] __lock_acquire+0x740/0x1ca0 [ 28.532322] [<ffffffff810a4df3>] ? __bfs+0x23/0x270 [ 28.532322] [<ffffffff810a7506>] ? check_irq_usage+0x96/0xe0 [ 28.532322] [<ffffffff810a8a73>] ? __lock_acquire+0x1133/0x1ca0 [ 28.532322] [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc] [ 28.532322] [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140 [ 28.532322] [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc] [ 28.532322] [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50 [ 28.532322] [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc] [ 28.532322] [<ffffffffa000d219>] tipc_nametbl_remove_publ+0x49/0x2e0 [tipc] [ 28.532322] [<ffffffffa000e11e>] tipc_nametbl_stop+0x13e/0x1f0 [tipc] [ 28.532322] [<ffffffffa000dfe5>] ? tipc_nametbl_stop+0x5/0x1f0 [tipc] [ 28.532322] [<ffffffffa0004bab>] tipc_init_net+0x13b/0x150 [tipc] [ 28.532322] [<ffffffffa0004a75>] ? tipc_init_net+0x5/0x150 [tipc] [ 28.532322] [<ffffffff8163dece>] ops_init+0x4e/0x150 [ 28.532322] [<ffffffff810aa66d>] ? trace_hardirqs_on+0xd/0x10 [ 28.532322] [<ffffffff8163e1d3>] register_pernet_operations+0xf3/0x190 [ 28.532322] [<ffffffff8163e31e>] register_pernet_subsys+0x2e/0x50 [ 28.532322] [<ffffffffa002406a>] tipc_init+0x6a/0x1000 [tipc] [ 28.532322] [<ffffffffa0024000>] ? 0xffffffffa0024000 [ 28.532322] [<ffffffff810002d9>] do_one_initcall+0x89/0x1c0 [ 28.532322] [<ffffffff811b7cb0>] ? kmem_cache_alloc_trace+0x50/0x1b0 [ 28.532322] [<ffffffff810e725b>] ? do_init_module+0x2b/0x200 [ 28.532322] [<ffffffff810e7294>] do_init_module+0x64/0x200 [ 28.532322] [<ffffffff810e9353>] load_module+0x12f3/0x18e0 [ 28.532322] [<ffffffff810e5890>] ? show_initstate+0x50/0x50 [ 28.532322] [<ffffffff810e9a19>] SyS_init_module+0xd9/0x110 [ 28.532322] [<ffffffff8179f3b3>] sysenter_dispatch+0x7/0x1f Before tipc_purge_publications() calls tipc_nametbl_remove_publ() to remove a publication with a name sequence, the name sequence's lock is held. However, when tipc_nametbl_remove_publ() calling tipc_nameseq_remove_publ() to remove the publication, it first tries to query name sequence instance with the publication, and then holds the lock of the found name sequence. But as the lock may be already taken in tipc_purge_publications(), deadlock happens like above scenario demonstrated. As tipc_nameseq_remove_publ() doesn't grab name sequence's lock, the deadlock can be avoided if it's directly invoked by tipc_purge_publications(). Fixes: 97ede29e ("tipc: convert name table read-write lock to RCU") Signed-off-by: -
Ying Xue authored
When the TIPC module is loaded, we launch a topology server in kernel space, which in its turn is creating TIPC sockets for communication with topology server users. Because both the socket's creator and provider reside in the same module, it is necessary that the TIPC module's reference count remains zero after the server is started and the socket created; otherwise it becomes impossible to perform "rmmod" even on an idle module. Currently, we achieve this by defining a separate "tipc_proto_kern" protocol struct, that is used only for kernel space socket allocations. This structure has the "owner" field set to NULL, which restricts the module reference count from being be bumped when sk_alloc() for local sockets is called. Furthermore, we have defined three kernel-specific functions, tipc_sock_create_local(), tipc_sock_release_local() and tipc_sock_accept_local(), to avoid the module counter being modified when module local sockets are created or deleted. This has worked well until we introduced name space support. However, after name space support was introduced, we have observed that a reference count leak occurs, because the netns counter is not decremented in tipc_sock_delete_local(). This commit remedies this problem. But instead of just modifying tipc_sock_delete_local(), we eliminate the whole parallel socket handling infrastructure, and start using the regular sk_create_kern(), kernel_accept() and sk_release_kernel() calls. Since those functions manipulate the module counter, we must now compensate for that by explicitly decrementing the counter after module local sockets are created, and increment it just before calling sk_release_kernel(). Fixes: a62fbcce ("tipc: make subscriber server support net namespace") Signed-off-by:
Jon Maloy <jon.maloy@ericson.com> Reviewed-by:
Cong Wang <cwang@twopensource.com> Tested-by:
-
David S. Miller authored
Eric Dumazet says: ==================== inet: tcp listener refactoring, part 12 By adding a pointer back to listener, we are preparing synack rtx handling to no longer be governed by listener keepalive timer, as this is the most problematic source of contention on listener spinlock. Note that TCP FastOpen had such pointer anyway, so we make it generic. ==================== Signed-off-by:
-
