| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch added the RM_ADDR option parsing logic:
We parsed the incoming options to find if the rm_addr option is received,
and called mptcp_pm_rm_addr_received to schedule PM work to a new status,
named MPTCP_PM_RM_ADDR_RECEIVED.
PM work got this status, and called mptcp_pm_nl_rm_addr_received to handle
it.
In mptcp_pm_nl_rm_addr_received, we closed the subflow matching the rm_id,
and updated PM counter.
Suggested-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Suggested-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Two minor conflicts:
1) net/ipv4/route.c, adding a new local variable while
moving another local variable and removing it's
initial assignment.
2) drivers/net/dsa/microchip/ksz9477.c, overlapping changes.
One pretty prints the port mode differently, whilst another
changes the driver to try and obtain the port mode from
the port node rather than the switch node.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
So that can be accessed easily from the subflow creation
helper. No functional change intended.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
mptcp_pm_nl_get_local_id may be called in interrupt context, so we need to
use GFP_ATOMIC flag to allocate memory to avoid sleeping in atomic context.
[ 280.209809] BUG: sleeping function called from invalid context at mm/slab.h:498
[ 280.209812] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1680, name: kworker/1:3
[ 280.209814] INFO: lockdep is turned off.
[ 280.209816] CPU: 1 PID: 1680 Comm: kworker/1:3 Tainted: G W 5.9.0-rc3-mptcp+ #146
[ 280.209818] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 280.209820] Workqueue: events mptcp_worker
[ 280.209822] Call Trace:
[ 280.209824] <IRQ>
[ 280.209826] dump_stack+0x77/0xa0
[ 280.209829] ___might_sleep.cold+0xa6/0xb6
[ 280.209832] kmem_cache_alloc_trace+0x1d1/0x290
[ 280.209835] mptcp_pm_nl_get_local_id+0x23c/0x410
[ 280.209840] subflow_init_req+0x1e9/0x2ea
[ 280.209843] ? inet_reqsk_alloc+0x1c/0x120
[ 280.209845] ? kmem_cache_alloc+0x264/0x290
[ 280.209849] tcp_conn_request+0x303/0xae0
[ 280.209854] ? printk+0x53/0x6a
[ 280.209857] ? tcp_rcv_state_process+0x28f/0x1374
[ 280.209859] tcp_rcv_state_process+0x28f/0x1374
[ 280.209864] ? tcp_v4_do_rcv+0xb3/0x1f0
[ 280.209866] tcp_v4_do_rcv+0xb3/0x1f0
[ 280.209869] tcp_v4_rcv+0xed6/0xfa0
[ 280.209873] ip_protocol_deliver_rcu+0x28/0x270
[ 280.209875] ip_local_deliver_finish+0x89/0x120
[ 280.209877] ip_local_deliver+0x180/0x220
[ 280.209881] ip_rcv+0x166/0x210
[ 280.209885] __netif_receive_skb_one_core+0x82/0x90
[ 280.209888] process_backlog+0xd6/0x230
[ 280.209891] net_rx_action+0x13a/0x410
[ 280.209895] __do_softirq+0xcf/0x468
[ 280.209899] asm_call_on_stack+0x12/0x20
[ 280.209901] </IRQ>
[ 280.209903] ? ip_finish_output2+0x240/0x9a0
[ 280.209906] do_softirq_own_stack+0x4d/0x60
[ 280.209908] do_softirq.part.0+0x2b/0x60
[ 280.209911] __local_bh_enable_ip+0x9a/0xa0
[ 280.209913] ip_finish_output2+0x264/0x9a0
[ 280.209916] ? rcu_read_lock_held+0x4d/0x60
[ 280.209920] ? ip_output+0x7a/0x250
[ 280.209922] ip_output+0x7a/0x250
[ 280.209925] ? __ip_finish_output+0x330/0x330
[ 280.209928] __ip_queue_xmit+0x1dc/0x5a0
[ 280.209931] __tcp_transmit_skb+0xa0f/0xc70
[ 280.209937] tcp_connect+0xb03/0xff0
[ 280.209939] ? lockdep_hardirqs_on_prepare+0xe7/0x190
[ 280.209942] ? ktime_get_with_offset+0x125/0x150
[ 280.209944] ? trace_hardirqs_on+0x1c/0xe0
[ 280.209948] tcp_v4_connect+0x449/0x550
[ 280.209953] __inet_stream_connect+0xbb/0x320
[ 280.209955] ? mark_held_locks+0x49/0x70
[ 280.209958] ? lockdep_hardirqs_on_prepare+0xe7/0x190
[ 280.209960] ? __local_bh_enable_ip+0x6b/0xa0
[ 280.209963] inet_stream_connect+0x32/0x50
[ 280.209966] __mptcp_subflow_connect+0x1fd/0x242
[ 280.209972] mptcp_pm_create_subflow_or_signal_addr+0x2db/0x600
[ 280.209975] mptcp_worker+0x543/0x7a0
[ 280.209980] process_one_work+0x26d/0x5b0
[ 280.209984] ? process_one_work+0x5b0/0x5b0
[ 280.209987] worker_thread+0x48/0x3d0
[ 280.209990] ? process_one_work+0x5b0/0x5b0
[ 280.209993] kthread+0x117/0x150
[ 280.209996] ? kthread_park+0x80/0x80
[ 280.209998] ret_from_fork+0x22/0x30
Fixes: 01cacb00b35cb ("mptcp: add netlink-based PM")
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch set the init remote_id to zero, otherwise it will be a random
number.
Then it added the missing subflow's remote_id setting code both in
__mptcp_subflow_connect and in subflow_ulp_clone.
Fixes: 01cacb00b35cb ("mptcp: add netlink-based PM")
Fixes: ec3edaa7ca6ce ("mptcp: Add handling of outgoing MP_JOIN requests")
Fixes: f296234c98a8f ("mptcp: Add handling of incoming MP_JOIN requests")
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In mptcp_pm_nl_get_local_id, skc_local is the same as msk_local, so it
always return 0. Thus every subflow's local_id is 0. It's incorrect.
This patch fixed this issue.
Also, we need to ignore the zero address here, like 0.0.0.0 in IPv4. When
we use the zero address as a local address, it means that we can use any
one of the local addresses. The zero address is not a new address, we don't
need to add it to PM, so this patch added a new function address_zero to
check whether an address is the zero address, if it is, we ignore this
address.
Fixes: 01cacb00b35cb ("mptcp: add netlink-based PM")
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Change places that open-code NLA_POLICY_EXACT_LEN() to
use the macro instead, giving us flexibility in how we
handle the details of the macro.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add the missing annotation in some setup-only
functions.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Normal there should be checked for nla_put_in6_addr like other
usage in net.
Detected by CoverityScan, CID# 1461639
Fixes: 01cacb00b35c ("mptcp: add netlink-based PM")
Signed-off-by: Bo YU <tsu.yubo@gmail.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some of the mptcp logs didn't print out the format string:
[ 185.651493] DSS
[ 185.651494] data_fin=0 dsn64=0 use_map=0 ack64=1 use_ack=1
[ 185.651494] data_ack=13792750332298763796
[ 185.651495] MPTCP: msk=00000000c4b81cfc ssk=000000009743af53 data_avail=0 skb=0000000063dc595d
[ 185.651495] MPTCP: msk=00000000c4b81cfc ssk=000000009743af53 status=0
[ 185.651495] MPTCP: msk ack_seq=9bbc894565aa2f9a subflow ack_seq=9bbc894565aa2f9a
[ 185.651496] MPTCP: msk=00000000c4b81cfc ssk=000000009743af53 data_avail=1 skb=0000000012e809e1
So this patch added these missing pr_fmt defines. Then we can get the same
format string "MPTCP" in all mptcp logs like this:
[ 142.795829] MPTCP: DSS
[ 142.795829] MPTCP: data_fin=0 dsn64=0 use_map=0 ack64=1 use_ack=1
[ 142.795829] MPTCP: data_ack=8089704603109242421
[ 142.795830] MPTCP: msk=00000000133a24e0 ssk=000000002e508c64 data_avail=0 skb=00000000d5f230df
[ 142.795830] MPTCP: msk=00000000133a24e0 ssk=000000002e508c64 status=0
[ 142.795831] MPTCP: msk ack_seq=66790290f1199d9b subflow ack_seq=66790290f1199d9b
[ 142.795831] MPTCP: msk=00000000133a24e0 ssk=000000002e508c64 data_avail=1 skb=00000000de5aca2e
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Expose a new netlink family to userspace to control the PM, setting:
- list of local addresses to be signalled.
- list of local addresses used to created subflows.
- maximum number of add_addr option to react
When the msk is fully established, the PM netlink attempts to
announce the 'signal' list via the ADD_ADDR option. Since we
currently lack the ADD_ADDR echo (and related event) only the
first addr is sent.
After exhausting the 'announce' list, the PM tries to create
subflow for each addr in 'local' list, waiting for each
connection to be completed before attempting the next one.
Idea is to add an additional PM hook for ADD_ADDR echo, to allow
the PM netlink announcing multiple addresses, in sequence.
Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
