* [PATCH][v2] netfilter: use kvzalloc to allocate memory for hashtable
From: Li RongQing @ 2018-07-25 5:34 UTC (permalink / raw)
To: netdev, pablo, kadlec, fw, netfilter-devel, coreteam, edumazet
nf_ct_alloc_hashtable is used to allocate memory for conntrack,
NAT bysrc and expectation hashtable. Assuming 64k bucket size,
which means 7th order page allocation, __get_free_pages, called
by nf_ct_alloc_hashtable, will trigger the direct memory reclaim
and stall for a long time, when system has lots of memory stress
so replace combination of __get_free_pages and vzalloc with
kvzalloc, which provides a fallback if no high order memory
is available, and do not retry to reclaim memory, reduce stall
and remove nf_ct_free_hashtable, since it is just a kvfree
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Wang Li <wangli39@baidu.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
include/net/netfilter/nf_conntrack.h | 2 --
net/netfilter/nf_conntrack_core.c | 23 +++++------------------
net/netfilter/nf_conntrack_expect.c | 2 +-
net/netfilter/nf_conntrack_helper.c | 4 ++--
net/netfilter/nf_nat_core.c | 4 ++--
5 files changed, 10 insertions(+), 25 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index a2b0ed025908..7e012312cd61 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -176,8 +176,6 @@ void nf_ct_netns_put(struct net *net, u8 nfproto);
*/
void *nf_ct_alloc_hashtable(unsigned int *sizep, int nulls);
-void nf_ct_free_hashtable(void *hash, unsigned int size);
-
int nf_conntrack_hash_check_insert(struct nf_conn *ct);
bool nf_ct_delete(struct nf_conn *ct, u32 pid, int report);
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 8a113ca1eea2..191140c469d5 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -2022,16 +2022,6 @@ static int kill_all(struct nf_conn *i, void *data)
return net_eq(nf_ct_net(i), data);
}
-void nf_ct_free_hashtable(void *hash, unsigned int size)
-{
- if (is_vmalloc_addr(hash))
- vfree(hash);
- else
- free_pages((unsigned long)hash,
- get_order(sizeof(struct hlist_head) * size));
-}
-EXPORT_SYMBOL_GPL(nf_ct_free_hashtable);
-
void nf_conntrack_cleanup_start(void)
{
conntrack_gc_work.exiting = true;
@@ -2042,7 +2032,7 @@ void nf_conntrack_cleanup_end(void)
{
RCU_INIT_POINTER(nf_ct_hook, NULL);
cancel_delayed_work_sync(&conntrack_gc_work.dwork);
- nf_ct_free_hashtable(nf_conntrack_hash, nf_conntrack_htable_size);
+ kvfree(nf_conntrack_hash);
nf_conntrack_proto_fini();
nf_conntrack_seqadj_fini();
@@ -2120,10 +2110,7 @@ void *nf_ct_alloc_hashtable(unsigned int *sizep, int nulls)
return NULL;
sz = nr_slots * sizeof(struct hlist_nulls_head);
- hash = (void *)__get_free_pages(GFP_KERNEL | __GFP_NOWARN | __GFP_ZERO,
- get_order(sz));
- if (!hash)
- hash = vzalloc(sz);
+ hash = kvzalloc(sz, GFP_KERNEL);
if (hash && nulls)
for (i = 0; i < nr_slots; i++)
@@ -2150,7 +2137,7 @@ int nf_conntrack_hash_resize(unsigned int hashsize)
old_size = nf_conntrack_htable_size;
if (old_size == hashsize) {
- nf_ct_free_hashtable(hash, hashsize);
+ kvfree(hash);
return 0;
}
@@ -2186,7 +2173,7 @@ int nf_conntrack_hash_resize(unsigned int hashsize)
local_bh_enable();
synchronize_net();
- nf_ct_free_hashtable(old_hash, old_size);
+ kvfree(old_hash);
return 0;
}
@@ -2350,7 +2337,7 @@ int nf_conntrack_init_start(void)
err_expect:
kmem_cache_destroy(nf_conntrack_cachep);
err_cachep:
- nf_ct_free_hashtable(nf_conntrack_hash, nf_conntrack_htable_size);
+ kvfree(nf_conntrack_hash);
return ret;
}
diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c
index 3f586ba23d92..27b84231db10 100644
--- a/net/netfilter/nf_conntrack_expect.c
+++ b/net/netfilter/nf_conntrack_expect.c
@@ -712,5 +712,5 @@ void nf_conntrack_expect_fini(void)
{
rcu_barrier(); /* Wait for call_rcu() before destroy */
kmem_cache_destroy(nf_ct_expect_cachep);
- nf_ct_free_hashtable(nf_ct_expect_hash, nf_ct_expect_hsize);
+ kvfree(nf_ct_expect_hash);
}
diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
index d557a425289d..e24b762ffa1d 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -562,12 +562,12 @@ int nf_conntrack_helper_init(void)
return 0;
out_extend:
- nf_ct_free_hashtable(nf_ct_helper_hash, nf_ct_helper_hsize);
+ kvfree(nf_ct_helper_hash);
return ret;
}
void nf_conntrack_helper_fini(void)
{
nf_ct_extend_unregister(&helper_extend);
- nf_ct_free_hashtable(nf_ct_helper_hash, nf_ct_helper_hsize);
+ kvfree(nf_ct_helper_hash);
}
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 6366f0c0b8c1..e2b196054dfc 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -1056,7 +1056,7 @@ static int __init nf_nat_init(void)
ret = nf_ct_extend_register(&nat_extend);
if (ret < 0) {
- nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
+ kvfree(nf_nat_bysource);
pr_err("Unable to register extension\n");
return ret;
}
@@ -1094,7 +1094,7 @@ static void __exit nf_nat_cleanup(void)
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
synchronize_net();
- nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
+ kvfree(nf_nat_bysource);
unregister_pernet_subsys(&nat_net_ops);
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH] drivers: net: wlcore: remove duplicate \n for some warnings
From: Kalle Valo @ 2018-07-25 6:40 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Arnd Bergmann, Reizer, Eyal, Kees Cook, linux-wireless, netdev,
linux-kernel, letux-kernel, kernel
In-Reply-To: <af660348ade58fd33396d2dca432536d2ac85cf7.1532498079.git.hns@goldelico.com>
"H. Nikolaus Schaller" <hns@goldelico.com> writes:
> wl1271_warning() already appends a \n to the format,
> so adding one to the warning string gives empty lines in the log.
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
"drivers: net:" in the title is unnecessary, but I can remove that.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2 bpf-next] tools/bpftool: ignore build products
From: Taeung Song @ 2018-07-25 6:36 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: netdev, linux-kernel
For untracked things of tools/bpf, add this.
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
---
tools/bpf/.gitignore | 5 +++++
tools/bpf/bpftool/.gitignore | 2 ++
2 files changed, 7 insertions(+)
create mode 100644 tools/bpf/.gitignore
diff --git a/tools/bpf/.gitignore b/tools/bpf/.gitignore
new file mode 100644
index 000000000000..dfe2bd5a4b95
--- /dev/null
+++ b/tools/bpf/.gitignore
@@ -0,0 +1,5 @@
+FEATURE-DUMP.bpf
+bpf_asm
+bpf_dbg
+bpf_exp.yacc.*
+bpf_jit_disasm
diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
index d7e678c2d396..67167e44b726 100644
--- a/tools/bpf/bpftool/.gitignore
+++ b/tools/bpf/bpftool/.gitignore
@@ -1,3 +1,5 @@
*.d
bpftool
+bpftool*.8
+bpf-helpers.*
FEATURE-DUMP.bpftool
--
2.17.1
^ permalink raw reply related
* 答复: 答复: [PATCH] netfilter: avoid stalls in nf_ct_alloc_hashtable
From: Li,Rongqing @ 2018-07-25 5:23 UTC (permalink / raw)
To: Eric Dumazet, Florian Westphal
Cc: netdev@vger.kernel.org, pablo@netfilter.org,
kadlec@blackhole.kfki.hu
In-Reply-To: <7825838c-cd8e-7f8e-b8b1-3ce4b68f9c38@gmail.com>
>
> On 07/24/2018 02:50 AM, Li,Rongqing wrote:
>
> > Thanks, Your patch fixes my issue;
> >
> > My patch may be able to reduce stall when modprobe nf module in
> memory
> > stress, Do you think this patch has any value?
>
> Only if you make it use kvzalloc()/kvfree()
>
> Thanks.
I will send v2, free to give your signature.
Thanks,
-RongQing
^ permalink raw reply
* Re: selftests/bpf test_sockmap failure
From: Yonghong Song @ 2018-07-25 5:09 UTC (permalink / raw)
To: Prashant Bhole, John Fastabend, netdev; +Cc: Martin Lau
In-Reply-To: <ff63e289-91db-3dd7-3370-941f8ddb987c@lab.ntt.co.jp>
On 7/24/18 5:49 PM, Prashant Bhole wrote:
>
>
> On 7/25/2018 8:02 AM, Yonghong Song wrote:
>>
>>
>> On 7/24/18 3:40 PM, John Fastabend wrote:
>>> On 07/24/2018 08:45 AM, Yonghong Song wrote:
>>>> In one of our production machines, tools/testing/selftests/bpf
>>>> test_sockmap failed randomly like below:
>>>>
>>>> ...
>>>> [TEST 78]: (512, 1, 1, sendmsg, pass,apply 1,): rx thread exited with
>>>> err 1. FAILED
>>>> ...
>>>>
>>>> ...
>>>> [TEST 80]: (2, 1024, 256, sendmsg, pass,apply 1,): rx thread exited
>>>> with
>>>> err 1. FAILED
>>>> ...
>>>>
>>>> ...
>>>> [TEST 83]: (100, 1, 5, sendpage, pass,apply 1,): rx thread exited with
>>>> err 1. FAILED
>>>> ...
>>>>
>>>> ...
>>>> [TEST 79]: (512, 1, 1, sendpage, pass,apply 1,): rx thread exited with
>>>> err 1. FAILED
>>>> ...
>>>>
>>>> The command line is just `test_sockmap`. The machine has 80 cpus, 256G
>>>> memory. The kernel is based on 4.16 but backported with latest bpf-next
>>>> bpf changes.
>>>>
>>>> The failed test number (78, 79, 80, or 83) is random. But they all
>>>> share
>>>> similar characteristics:
>>>> . the option rate is greater than one, i.e., more than one
>>>> sendmsg/sendpage in the sender forked process.
>>>> . The txmsg_apply is not 0
>>>>
>>>> I debugged a little bit. It happens in msg_loop() function below
>>>> "unexpected timeout" path.
>>>>
>>>> ...
>>>> slct = select(max_fd + 1, &w, NULL, NULL,
>>>> &timeout);
>>>> if (slct == -1) {
>>>> perror("select()");
>>>> clock_gettime(CLOCK_MONOTONIC,
>>>> &s->end);
>>>> goto out_errno;
>>>> } else if (!slct) {
>>>> if (opt->verbose)
>>>> fprintf(stderr, "unexpected
>>>> timeout\n");
>>>> errno = -EIO;
>>>> clock_gettime(CLOCK_MONOTONIC,
>>>> &s->end);
>>>> goto out_errno;
>>>> }
>>>> ...
>>>>
>>>> It appears that when the error happens, the receive process does not
>>>> receive all bytes sent from the send process and eventually times out.
>>>>
>>>> Has anybody seen this issue as well?
>>>> John, any comments on this failure?
>>>
>>> Can you run the test with verbose enabled so we can determine if the tx
>>> side is even sending the message? Sample patch below. This will allow
>>> us to see the tx bytes and rx bytes, although it will be a bit noisy.
>>>
>>> I notice that the test program is not smart enough to (re)send bytes if
>>> the sendmsg call doesn't consume all bytes. This is a valid error if
>>> we get a enomem or other normal error on the tx side. With apply this
>>> is more likely because every byte (in apply = 1 case) is being sent
>>> through BPF prog.
>>
>> The following are some of logs for the failed tests:
>>
>> ...
>> [TEST 78]: (512, 1, 1, sendmsg, pass,apply 1,): connected sockets: c1
>> <-> p1, c2 <-> p2
>> cgroups binding: c1(24) <-> s1(22) - - - c2(25) <-> s2(23)
>> tx_sendmsg: TX: 512B 0.000000B/s 0.000000 GB/s RX: 0B 0.000000B/s
>> 0.000000GB/s
>> unexpected timeout
>> msg_loop_rx: iov_count 1 iov_buf 1 cnt 512 err -5
>> rx_sendmsg: TX: 0B 0.000000B/s 0.000000GB/s RX: 147B 147.000000B/s
>> 0.000000GB/s
>> rx thread exited with err 1. FAILED
>> ...
>>
>> [TEST 82]: (100, 1, 5, sendmsg, pass,apply 1,): connected sockets: c1
>> <-> p1, c2 <-> p2
>> cgroups binding: c1(24) <-> s1(22) - - - c2(25) <-> s2(23)
>> tx_sendmsg: TX: 500B 0.000000B/s 0.000000 GB/s RX: 0B 0.000000B/s
>> 0.000000GB/s
>> unexpected timeout
>> msg_loop_rx: iov_count 1 iov_buf 5 cnt 100 err -5
>> rx_sendmsg: TX: 0B 0.000000B/s 0.000000GB/s RX: 366B 366.000000B/s
>> 0.000000GB/s
>> rx thread exited with err 1. FAILED
>>
>> [TEST 402]: (512, 1, 1, sendmsg, pass,apply 1,): connected sockets: c1
>> <-> p1, c2 <-> p2
>> cgroups binding: c1(42) <-> s1(40) - - - c2(43) <-> s2(41)
>> tx_sendmsg: TX: 512B 0.000000B/s 0.000000 GB/s RX: 0B 0.000000B/s
>> 0.000000GB/s
>> unexpected timeout
>> msg_loop_rx: iov_count 1 iov_buf 1 cnt 512 err -5
>> rx_sendmsg: TX: 0B 0.000000B/s 0.000000GB/s RX: 147B 147.000000B/s
>> 0.000000GB/s
>> rx thread exited with err 1. FAILED
>>
>> [TEST 80]: (2, 1024, 256, sendmsg, pass,apply 1,): connected sockets:
>> c1 <-> p1, c2 <-> p2
>> cgroups binding: c1(24) <-> s1(22) - - - c2(25) <-> s2(23)
>> tx_sendmsg: TX: 524288B 0.000000B/s 0.000000 GB/s RX: 0B 0.000000B/s
>> 0.000000GB/s
>> unexpected timeout
>> msg_loop_rx: iov_count 1024 iov_buf 256 cnt 2 err -5
>> rx_sendmsg: TX: 0B 0.000000B/s 0.000000GB/s RX: 458805B
>> 458805.000000B/s 0.000459GB/s
>> rx thread exited with err 1. FAILED
>>
>>
>>>
>>> If this is not the case I can do some more digging but I've not seen
>>> this before.
>>
>> I cannot reproduce it in my FC27 VM (with latest bpf-next) either.
>> The bug only shows up on our production service which is a lot busier
>> and has more cpus/memorys and some sysctl configurations are different
>> from my VM setup.
>
> In the past I have noticed that on busy machines sometimes data is
> delayed so much that select() timeout is triggered. Although it isn't a
> solution but you can try to increase the timeout value to check if that
> is the case.
Thanks for the tip. My test machine is busier, but most jobs are waiting
for the work and the actual cpu utilization is not that high.
The default recv timeout is 1 second. I increased it to 10 seconds, and
the failure still exists.
^ permalink raw reply
* Re: [PATCH v3 bpf 0/3] Introduce BPF_ANNOTATE_KV_PAIR
From: Daniel Borkmann @ 2018-07-25 5:04 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <20180724154022.3863907-1-kafai@fb.com>
On 07/24/2018 05:40 PM, Martin KaFai Lau wrote:
> The series allows the BPF loader to figure out
> the btf_key_id and btf_value_id from a map's name
> by using BPF_ANNOTATE_KV_PAIR. It also removes
> the old 'typedef' way which requires two separate
> typedefs (one for the key and one for the value).
>
> By doing this, iproute2 and libbpf have one
> consistent way to figure out the btf_key_type_id and
> btf_value_type_id for a map.
>
> The first two patches are some prep/cleanup works.
> The last patch introduces BPF_ANNOTATE_KV_PAIR.
>
> v3:
> - Replace some more *int*_t and u* usages with the
> equivalent __[su]* in btf.c
> v2:
> - Fix the incorrect '&&' check on container_type
> in bpf_map_find_btf_info().
> - Expose the existing static btf_type_by_id() instead of
> creating a new one.
>
> Martin KaFai Lau (3):
> bpf: btf: Sync uapi btf.h to tools
> bpf: Replace [u]int32_t and [u]int64_t in libbpf
> bpf: Introduce BPF_ANNOTATE_KV_PAIR
>
> tools/include/uapi/linux/btf.h | 2 +-
> tools/lib/bpf/btf.c | 39 +++++----
> tools/lib/bpf/btf.h | 10 ++-
> tools/lib/bpf/libbpf.c | 85 +++++++++++---------
> tools/lib/bpf/libbpf.h | 4 +-
> tools/testing/selftests/bpf/bpf_helpers.h | 9 +++
> tools/testing/selftests/bpf/test_btf_haskv.c | 7 +-
> 7 files changed, 83 insertions(+), 73 deletions(-)
>
Applied to bpf, thanks Martin!
^ permalink raw reply
* [PATCH] drivers: net: wlcore: remove duplicate \n for some warnings
From: H. Nikolaus Schaller @ 2018-07-25 5:55 UTC (permalink / raw)
To: Kalle Valo, Arnd Bergmann, Reizer, Eyal, Kees Cook,
H. Nikolaus Schaller
Cc: linux-wireless, netdev, linux-kernel, letux-kernel, kernel
wl1271_warning() already appends a \n to the format,
so adding one to the warning string gives empty lines in the log.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/net/wireless/ti/wlcore/main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3a51ab116e79..ab34d41487d3 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6065,16 +6065,16 @@ static int wl1271_register_hw(struct wl1271 *wl)
}
if (oui_addr == 0xdeadbe && nic_addr == 0xef0000) {
- wl1271_warning("Detected unconfigured mac address in nvs, derive from fuse instead.\n");
+ wl1271_warning("Detected unconfigured mac address in nvs, derive from fuse instead.");
if (!strcmp(pdev_data->family->name, "wl18xx")) {
- wl1271_warning("This default nvs file can be removed from the file system\n");
+ wl1271_warning("This default nvs file can be removed from the file system");
} else {
- wl1271_warning("Your device performance is not optimized.\n");
- wl1271_warning("Please use the calibrator tool to configure your device.\n");
+ wl1271_warning("Your device performance is not optimized.");
+ wl1271_warning("Please use the calibrator tool to configure your device.");
}
if (wl->fuse_oui_addr == 0 && wl->fuse_nic_addr == 0) {
- wl1271_warning("Fuse mac address is zero. using random mac\n");
+ wl1271_warning("Fuse mac address is zero. using random mac");
/* Use TI oui and a random nic */
oui_addr = WLCORE_TI_OUI_ADDRESS;
nic_addr = get_random_int();
--
2.12.2
^ permalink raw reply related
* Re: [PATCH v2] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest()
From: Julian Anastasov @ 2018-07-25 5:53 UTC (permalink / raw)
To: Tan Hu
Cc: wensong, horms, pablo, kadlec, fw, davem, netdev, lvs-devel,
netfilter-devel, coreteam, linux-kernel, zhong.weidong,
jiang.biao2
In-Reply-To: <1532486980-17844-1-git-send-email-tan.hu@zte.com.cn>
Hello,
On Wed, 25 Jul 2018, Tan Hu wrote:
> We came across infinite loop in ipvs when using ipvs in docker
> env.
>
> When ipvs receives new packets and cannot find an ipvs connection,
> it will create a new connection, then if the dest is unavailable
> (i.e. IP_VS_DEST_F_AVAILABLE), the packet will be dropped sliently.
>
> But if the dropped packet is the first packet of this connection,
> the connection control timer never has a chance to start and the
> ipvs connection cannot be released. This will lead to memory leak, or
> infinite loop in cleanup_net() when net namespace is released like
> this:
>
> ip_vs_conn_net_cleanup at ffffffffa0a9f31a [ip_vs]
> __ip_vs_cleanup at ffffffffa0a9f60a [ip_vs]
> ops_exit_list at ffffffff81567a49
> cleanup_net at ffffffff81568b40
> process_one_work at ffffffff810a851b
> worker_thread at ffffffff810a9356
> kthread at ffffffff810b0b6f
> ret_from_fork at ffffffff81697a18
>
> race condition:
> CPU1 CPU2
> ip_vs_in()
> ip_vs_conn_new()
> ip_vs_del_dest()
> __ip_vs_unlink_dest()
> ~IP_VS_DEST_F_AVAILABLE
> cp->dest && !IP_VS_DEST_F_AVAILABLE
> __ip_vs_conn_put
> ...
> cleanup_net ---> infinite looping
>
> Fix this by checking whether the timer already started.
>
> Signed-off-by: Tan Hu <tan.hu@zte.com.cn>
> Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
> ---
> v2: fix use-after-free in CONN_ONE_PACKET case suggested by Julian Anastasov
>
> net/netfilter/ipvs/ip_vs_core.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index 0679dd1..a17104f 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1972,13 +1972,20 @@ static int ip_vs_in_icmp_v6(struct netns_ipvs *ipvs, struct sk_buff *skb,
> if (cp->dest && !(cp->dest->flags & IP_VS_DEST_F_AVAILABLE)) {
> /* the destination server is not available */
>
> - if (sysctl_expire_nodest_conn(ipvs)) {
> + __u32 flags = cp->flags;
Ops, now scripts/checkpatch.pl --strict /tmp/file.patch
is complaining about extra trailing space in above line.
You can also remove the empty line above the new code...
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v2] bpf: Add Python 3 support to selftests scripts for bpf
From: Daniel Borkmann @ 2018-07-25 5:53 UTC (permalink / raw)
To: Jeremy Cline, Alexei Starovoitov, Shuah Khan
Cc: Lawrence Brakmo, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20180724195334.13965-1-jcline@redhat.com>
On 07/24/2018 09:53 PM, Jeremy Cline wrote:
> Adjust tcp_client.py and tcp_server.py to work with Python 3 by using
> the print function, marking string literals as bytes, and using the
> newer exception syntax. This should be functionally equivalent and
> supports Python 3+.
>
> Signed-off-by: Jeremy Cline <jcline@redhat.com>
Applied to bpf-next, thanks Jeremy!
^ permalink raw reply
* Re: [PATCH bpf-next] samples/bpf: xdpsock: order memory on AArch64
From: Daniel Borkmann @ 2018-07-25 5:52 UTC (permalink / raw)
To: Brian Brooks, ast, bjorn.topel, magnus.karlsson; +Cc: netdev, linux-kernel
In-Reply-To: <20180724133337.20175-1-brian.brooks@linaro.org>
On 07/24/2018 03:33 PM, Brian Brooks wrote:
> Signed-off-by: Brian Brooks <brian.brooks@linaro.org>
Please respin with proper commit message instead of empty one.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: Daniel Borkmann @ 2018-07-25 5:45 UTC (permalink / raw)
To: YueHaibing, ast, quentin.monnet, jakub.kicinski,
bhole_prashant_q7, osk
Cc: linux-kernel, netdev, davem
In-Reply-To: <20180724025524.22012-1-yuehaibing@huawei.com>
On 07/24/2018 04:55 AM, YueHaibing wrote:
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied to bpf-next, thanks Yue!
^ permalink raw reply
* Re: [PATCH] perf build: Build error in libbpf with EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
From: Daniel Borkmann @ 2018-07-25 5:35 UTC (permalink / raw)
To: Thomas Richter, ast, netdev, linux-kernel
Cc: heiko.carstens, brueckner, schwidefsky, wangnan0
In-Reply-To: <20180724151011.36495-1-tmricht@linux.ibm.com>
On 07/24/2018 05:10 PM, Thomas Richter wrote:
> commit a5b8bd47dcc57 ("bpf tools: Collect eBPF programs from their own sections")
>
> cause a compiler error when building the perf tool in the linux-next tree.
> I compile it using a FEDORA 28 installation, my gcc compiler version:
> gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
>
> The file that causes the error is tools/lib/bpf/libbpf.c
>
> Here is the error message:
>
> [root@p23lp27] # make V=1 EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
> [...]
> make -f /home6/tmricht/linux-next/tools/build/Makefile.build
> dir=./util/scripting-engines obj=libperf
> libbpf.c: In function ‘bpf_object__elf_collect’:
> libbpf.c:811:15: error: ignoring return value of ‘strerror_r’,
> declared with attribute warn_unused_result [-Werror=unused-result]
> strerror_r(-err, errmsg, sizeof(errmsg));
> ^
> cc1: all warnings being treated as errors
> mv: cannot stat './.libbpf.o.tmp': No such file or directory
> /home6/tmricht/linux-next/tools/build/Makefile.build:96: recipe for target 'libbpf.o' failed
>
> Fix this by using strerror_r return value in pr_warning statement.
> Also fixes a possible initialization issue.
>
> Cc: Wang Nan <wangnan0@huawei.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
> ---
> tools/lib/bpf/libbpf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 955f8eafbf41..c70785ea903c 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -808,9 +808,9 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
> if (err) {
> char errmsg[STRERR_BUFSIZE];
>
> - strerror_r(-err, errmsg, sizeof(errmsg));
> pr_warning("failed to alloc program %s (%s): %s",
> - name, obj->path, errmsg);
> + name, obj->path,
> + strerror_r(-err, errmsg, sizeof(errmsg)));
This doesn't build for me. Doing this here won't work since it uses
strerror_r() variant that returns an int (which is posix variant and
not gnu specific one that would return char *):
# make
BUILD: Doing 'make -j4' parallel build
HOSTCC fixdep.o
HOSTLD fixdep-in.o
LINK fixdep
Warning: Kernel ABI header at 'tools/arch/powerpc/include/uapi/asm/unistd.h' differs from latest version at 'arch/powerpc/include/uapi/asm/unistd.h'
Warning: Kernel ABI header at 'tools/arch/x86/lib/memcpy_64.S' differs from latest version at 'arch/x86/lib/memcpy_64.S'
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ OFF ]
... libaudit: [ on ]
... libbfd: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ OFF ]
... libpython: [ OFF ]
... libslang: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
Makefile.config:443: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:610: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
Makefile.config:637: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:669: No 'python-config' tool was found: disables Python support - please install python-devel/python-dev
Makefile.config:812: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
Makefile.config:849: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
GEN common-cmds.h
CC fd/array.o
CC event-parse.o
PERF_VERSION = 4.18.rc5.g56801c
CC fs/fs.o
LD fd/libapi-in.o
CC fs/tracing_path.o
CC event-plugin.o
LD fs/libapi-in.o
CC cpu.o
CC debug.o
CC trace-seq.o
CC str_error_r.o
LD libapi-in.o
CC exec-cmd.o
AR libapi.a
CC parse-filter.o
CC parse-utils.o
CC help.o
CC pager.o
Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'
CC kbuffer-parse.o
CC libbpf.o
LD libtraceevent-in.o
LINK libtraceevent.a
libbpf.c: In function ‘bpf_object__elf_collect’:
libbpf.c:81:10: error: format ‘%s’ expects argument of type ‘char *’, but argument 4 has type ‘int’ [-Werror=format=]
(func)("libbpf: " fmt, ##__VA_ARGS__); \
^
libbpf.c:84:30: note: in expansion of macro ‘__pr’
#define pr_warning(fmt, ...) __pr(__pr_warning, fmt, ##__VA_ARGS__)
^~~~
libbpf.c:858:5: note: in expansion of macro ‘pr_warning’
pr_warning("failed to alloc program %s (%s): %s",
^~~~~~~~~~
CC parse-options.o
HOSTCC pmu-events/json.o
CC run-command.o
HOSTCC pmu-events/jsmn.o
cc1: all warnings being treated as errors
> }
> } else if (sh.sh_type == SHT_REL) {
> void *reloc = obj->efile.reloc;
> @@ -2334,7 +2334,7 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
> __u64 data_tail = header->data_tail;
> __u64 data_head = header->data_head;
> void *base, *begin, *end;
> - int ret;
> + int ret = 0;
>
> asm volatile("" ::: "memory"); /* in real code it should be smp_rmb() */
> if (data_head == data_tail)
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled
From: Toshiaki Makita @ 2018-07-25 4:22 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180724121015.5d9edbf3@cakuba.netronome.com>
On 2018/07/25 4:10, Jakub Kicinski wrote:
> On Tue, 24 Jul 2018 18:39:09 +0900, Toshiaki Makita wrote:
>> On 2018/07/24 10:56, Toshiaki Makita wrote:
>>> On 2018/07/24 9:27, Jakub Kicinski wrote:
>>>> On Mon, 23 Jul 2018 00:13:03 +0900, Toshiaki Makita wrote:
>>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>
>>>>> All oversized packets including GSO packets are dropped if XDP is
>>>>> enabled on receiver side, so don't send such packets from peer.
>>>>>
>>>>> Drop TSO and SCTP fragmentation features so that veth devices themselves
>>>>> segment packets with XDP enabled. Also cap MTU accordingly.
>>>>>
>>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>
>>>> Is there any precedence for fixing up features and MTU like this? Most
>>>> drivers just refuse to install the program if settings are incompatible.
>>>
>>> I don't know any precedence. I can refuse the program on installing it
>>> when features and MTU are not appropriate. Is it preferred?
>>> Note that with current implementation wanted_features are not touched so
>>> features will be restored when the XDP program is removed. MTU will not
>>> be restored though, as I do not remember the original MTU.
>>
>> I just recalled that virtio_net used to refused XDP when guest offload
>> features are incompatible but now it dynamically fixup them on
>> installing an XDP program.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f93522ffab2d46a36b57adf324a54e674fc9536
>
> That's slightly different AFAIU, because the virtio features weren't
> really controllable at runtime at all. I'm not dead set on leaving the
> features be, but I just want to make sure we think this through
> properly before we commit to any magic behaviour for ever...
To me it does not look so different. What the above virtio commit is
doing is almost disabling LRO so we could add a feature to toggle LRO
instead but it chose to automatically disable it. And this veth commit
is also almost equivalent to disabling LRO.
IMHO we should do this feature adjustment. It just avoids packet drops
and has no downside. It forces software segmentation on the peer veth.
Features will be restored when XDP is removed so there would be no
surprising for users. It seems there is no benefit to not doing this.
> Taking a quick glance at the MTU side, it seems that today if someone
> decides to set MTU on one side of a veth pair the packets will simply
> get dropped. So the MTU coupling for XDP doesn't seem in line with
> existing behaviour of veth, not only other XDP drivers.
It looks weird to allow such inconsistent MTU settings. But anyway
changing MTU can have negative effect on users, such as causing
fragmentation or EMSGSIZE error on UDP sendmsg() or not restoring MTU. I
think I should not adjust MTU but just cap max_mtu.
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion.
From: NeilBrown @ 2018-07-25 4:53 UTC (permalink / raw)
To: paulmck; +Cc: Herbert Xu, Thomas Graf, netdev, linux-kernel
In-Reply-To: <20180724225825.GE12945@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6443 bytes --]
On Tue, Jul 24 2018, Paul E. McKenney wrote:
> On Tue, Jul 24, 2018 at 07:52:03AM +1000, NeilBrown wrote:
>> On Mon, Jul 23 2018, Paul E. McKenney wrote:
>>
>> > On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
>> >> On Sun, Jul 22 2018, Paul E. McKenney wrote:
>> >> >
>> >> > One issue is that the ->func pointer can legitimately be NULL while on
>> >> > RCU's callback lists. This happens when someone invokes kfree_rcu()
>> >> > with the rcu_head structure at the beginning of the enclosing structure.
>> >> > I could add an offset to avoid this, or perhaps the kmalloc() folks
>> >> > could be persuaded Rao Shoaib's patch moving kfree_rcu() handling to
>> >> > the slab allocators, so that RCU only ever sees function pointers in
>> >> > the ->func field.
>> >> >
>> >> > Either way, this should be hidden behind an API to allow adjustments
>> >> > to be made if needed. Maybe something like is_after_call_rcu()?
>> >> > This would (for example) allow debug-object checks to be used to catch
>> >> > check-after-free bugs.
>> >> >
>> >> > Would something of that sort work for you?
>> >>
>> >> Yes, if you could provide an is_after_call_rcu() API, that would
>> >> perfectly suit my use-case.
>> >
>> > After beating my head against the object-debug code a bit, I have to ask
>> > if it would be OK for you if the is_after_call_rcu() API also takes the
>> > function that was passed to RCU.
>>
>> Sure. It feels a bit clumsy, but I can see it could be easier to make
>> robust.
>> So yes: I'm fine with pass the same function and rcu_head to both
>> call_rcu() and is_after_call_rcu(). Actually, when I say it like that,
>> it seems less clumsy :-)
>
> How about like this? (It needs refinements, like lockdep, but should
> get the gist.)
>
Looks good ... except ... naming is hard.
is_after_call_rcu_init() asserts where in the lifecycle we are,
is_after_call_rcu() tests where in the lifecycle we are.
The names are similar but the purpose is quite different.
Maybe s/is_after_call_rcu_init/call_rcu_init/ ??
Thanks,
NeilBrown
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 5aa0ebf4799b8bddbbd0124db1c008526e99fc7c
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Tue Jul 24 15:28:09 2018 -0700
>
> rcu: Provide functions for determining if call_rcu() has been invoked
>
> This commit adds is_after_call_rcu() and is_after_call_rcu_init()
> functions to help RCU users detect when another CPU has passed
> the specified rcu_head structure and function to call_rcu().
> The is_after_call_rcu_init() should be invoked before making the
> structure visible to RCU readers, and then the is_after_call_rcu() may
> be invoked from within an RCU read-side critical section on an rcu_head
> structure that was obtained during a traversal of the data structure
> in question. The is_after_call_rcu() function will return true if the
> rcu_head structure has already been passed (with the specified function)
> to call_rcu(), otherwise it will return false.
>
> If is_after_call_rcu_init() has not been invoked on the rcu_head
> structure or if the rcu_head (AKA callback) has already been invoked,
> then is_after_call_rcu() will do WARN_ON_ONCE().
>
> Reported-by: NeilBrown <neilb@suse.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index e4f821165d0b..82e5a91539b5 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -857,6 +857,45 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
> #endif /* #else #ifdef CONFIG_ARCH_WEAK_RELEASE_ACQUIRE */
>
>
> +/* Has the specified rcu_head structure been handed to call_rcu()? */
> +
> +/*
> + * is_after_call_rcu_init - Initialize rcu_head for is_after_call_rcu()
> + * @rhp: The rcu_head structure to initialize.
> + *
> + * If you intend to invoke is_after_call_rcu() to test whether a given
> + * rcu_head structure has already been passed to call_rcu(), then you must
> + * also invoke this is_after_call_rcu_init() function on it just after
> + * allocating that structure. Calls to this function must not race with
> + * calls to call_rcu(), is_after_call_rcu(), or callback invocation.
> + */
> +static inline void is_after_call_rcu_init(struct rcu_head *rhp)
> +{
> + rhp->func = (rcu_callback_t)~0L;
> +}
> +
> +/*
> + * is_after_call_rcu - Has this rcu_head been passed to call_rcu()?
> + * @rhp: The rcu_head structure to test.
> + * @func: The function passed to call_rcu() along with @rhp.
> + *
> + * Returns @true if the @rhp has been passed to call_rcu() with @func, and
> + * @false otherwise. Emits a warning in any other case, including the
> + * case where @rhp has already been invoked after a grace period.
> + * Calls to this function must not race with callback invocation. One
> + * way to avoid such races is to enclose the call to is_after_call_rcu()
> + * in an RCU read-side critical section that includes a read-side fetch
> + * of the pointer to the structure containing @rhp.
> + */
> +static inline bool is_after_call_rcu(struct rcu_head *rhp, rcu_callback_t f)
> +{
> + if (READ_ONCE(rhp->func) == f)
> + return true;
> + WARN_ON_ONCE(READ_ONCE(rhp->func) != (rcu_callback_t)~0L);
> + return false;
> +}
> +
> +
> /* Transitional pre-consolidation compatibility definitions. */
>
> static inline void synchronize_rcu_bh(void)
> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index 5dec94509a7e..4c56c1d98fb3 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -224,6 +224,7 @@ void kfree(const void *);
> */
> static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
> {
> + rcu_callback_t f;
> unsigned long offset = (unsigned long)head->func;
>
> rcu_lock_acquire(&rcu_callback_map);
> @@ -234,7 +235,9 @@ static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
> return true;
> } else {
> RCU_TRACE(trace_rcu_invoke_callback(rn, head);)
> - head->func(head);
> + f = head->func;
> + WRITE_ONCE(head->func, (rcu_callback_t)0L);
> + f(head);
> rcu_lock_release(&rcu_callback_map);
> return false;
> }
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH] RDS: RDMA: Fix the NULL-ptr deref in rds_ib_get_mr
From: Avinash Repaka @ 2018-07-25 3:31 UTC (permalink / raw)
To: Santosh Shilimkar, David S. Miller, netdev, linux-rdma, rds-devel,
linux-kernel
Cc: avinash.repaka
Registration of a memory region(MR) through FRMR/fastreg(unlike FMR)
needs a connection/qp. With a proxy qp, this dependency on connection
will be removed, but that needs more infrastructure patches, which is a
work in progress.
As an intermediate fix, the get_mr returns EOPNOTSUPP when connection
details are not populated. The MR registration through sendmsg() will
continue to work even with fast registration, since connection in this
case is formed upfront.
This patch fixes the following crash:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 4244 Comm: syzkaller468044 Not tainted 4.16.0-rc6+ #361
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544
RSP: 0018:ffff8801b059f890 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801b07e1300 RCX: ffffffff8562d96e
RDX: 000000000000000d RSI: 0000000000000001 RDI: 0000000000000068
RBP: ffff8801b059f8b8 R08: ffffed0036274244 R09: ffff8801b13a1200
R10: 0000000000000004 R11: ffffed0036274243 R12: ffff8801b13a1200
R13: 0000000000000001 R14: ffff8801ca09fa9c R15: 0000000000000000
FS: 00007f4d050af700(0000) GS:ffff8801db300000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4d050aee78 CR3: 00000001b0d9b006 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__rds_rdma_map+0x710/0x1050 net/rds/rdma.c:271
rds_get_mr_for_dest+0x1d4/0x2c0 net/rds/rdma.c:357
rds_setsockopt+0x6cc/0x980 net/rds/af_rds.c:347
SYSC_setsockopt net/socket.c:1849 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1828
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4456d9
RSP: 002b:00007f4d050aedb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 00000000004456d9
RDX: 0000000000000007 RSI: 0000000000000114 RDI: 0000000000000004
RBP: 00000000006dac38 R08: 00000000000000a0 R09: 0000000000000000
R10: 0000000020000380 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffbfb36d6f R14: 00007f4d050af9c0 R15: 0000000000000005
Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 cc 01 00 00 4c 8b bb 80 04 00 00
48
b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f
85 9c 01 00 00 4d 8b 7f 68 48 b8 00 00 00 00 00
RIP: rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544 RSP:
ffff8801b059f890
---[ end trace 7e1cea13b85473b0 ]---
Reported-by: syzbot+b51c77ef956678a65834@syzkaller.appspotmail.com
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: Avinash Repaka <avinash.repaka@oracle.com>
---
net/rds/ib_frmr.c | 5 +++++
net/rds/ib_mr.h | 3 ++-
net/rds/ib_rdma.c | 21 +++++++++++++--------
net/rds/rdma.c | 13 ++++++++-----
net/rds/rds.h | 5 ++++-
net/rds/send.c | 12 +++++++-----
6 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/net/rds/ib_frmr.c b/net/rds/ib_frmr.c
index 48332a6..d152e48 100644
--- a/net/rds/ib_frmr.c
+++ b/net/rds/ib_frmr.c
@@ -344,6 +344,11 @@ struct rds_ib_mr *rds_ib_reg_frmr(struct rds_ib_device *rds_ibdev,
struct rds_ib_frmr *frmr;
int ret;
+ if (!ic) {
+ /* TODO: Add FRWR support for RDS_GET_MR using proxy qp*/
+ return ERR_PTR(-EOPNOTSUPP);
+ }
+
do {
if (ibmr)
rds_ib_free_frmr(ibmr, true);
diff --git a/net/rds/ib_mr.h b/net/rds/ib_mr.h
index 0ea4ab0..655f01d 100644
--- a/net/rds/ib_mr.h
+++ b/net/rds/ib_mr.h
@@ -115,7 +115,8 @@ void rds_ib_get_mr_info(struct rds_ib_device *rds_ibdev,
struct rds_info_rdma_connection *iinfo);
void rds_ib_destroy_mr_pool(struct rds_ib_mr_pool *);
void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
- struct rds_sock *rs, u32 *key_ret);
+ struct rds_sock *rs, u32 *key_ret,
+ struct rds_connection *conn);
void rds_ib_sync_mr(void *trans_private, int dir);
void rds_ib_free_mr(void *trans_private, int invalidate);
void rds_ib_flush_mrs(void);
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index e678699..2e49a40 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -537,11 +537,12 @@ void rds_ib_flush_mrs(void)
}
void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
- struct rds_sock *rs, u32 *key_ret)
+ struct rds_sock *rs, u32 *key_ret,
+ struct rds_connection *conn)
{
struct rds_ib_device *rds_ibdev;
struct rds_ib_mr *ibmr = NULL;
- struct rds_ib_connection *ic = rs->rs_conn->c_transport_data;
+ struct rds_ib_connection *ic = NULL;
int ret;
rds_ibdev = rds_ib_get_device(rs->rs_bound_addr);
@@ -550,6 +551,9 @@ void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
goto out;
}
+ if (conn)
+ ic = conn->c_transport_data;
+
if (!rds_ibdev->mr_8k_pool || !rds_ibdev->mr_1m_pool) {
ret = -ENODEV;
goto out;
@@ -559,17 +563,18 @@ void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
ibmr = rds_ib_reg_frmr(rds_ibdev, ic, sg, nents, key_ret);
else
ibmr = rds_ib_reg_fmr(rds_ibdev, sg, nents, key_ret);
- if (ibmr)
- rds_ibdev = NULL;
-
- out:
- if (!ibmr)
+ if (IS_ERR(ibmr)) {
+ ret = PTR_ERR(ibmr);
pr_warn("RDS/IB: rds_ib_get_mr failed (errno=%d)\n", ret);
+ } else {
+ return ibmr;
+ }
+ out:
if (rds_ibdev)
rds_ib_dev_put(rds_ibdev);
- return ibmr;
+ return ERR_PTR(ret);
}
void rds_ib_destroy_mr_pool(struct rds_ib_mr_pool *pool)
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 634cfcb..80920e4 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -170,7 +170,8 @@ static int rds_pin_pages(unsigned long user_addr, unsigned int nr_pages,
}
static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args,
- u64 *cookie_ret, struct rds_mr **mr_ret)
+ u64 *cookie_ret, struct rds_mr **mr_ret,
+ struct rds_conn_path *cp)
{
struct rds_mr *mr = NULL, *found;
unsigned int nr_pages;
@@ -269,7 +270,8 @@ static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args,
* Note that dma_map() implies that pending writes are
* flushed to RAM, so no dma_sync is needed here. */
trans_private = rs->rs_transport->get_mr(sg, nents, rs,
- &mr->r_key);
+ &mr->r_key,
+ cp ? cp->cp_conn : NULL);
if (IS_ERR(trans_private)) {
for (i = 0 ; i < nents; i++)
@@ -330,7 +332,7 @@ int rds_get_mr(struct rds_sock *rs, char __user *optval, int optlen)
sizeof(struct rds_get_mr_args)))
return -EFAULT;
- return __rds_rdma_map(rs, &args, NULL, NULL);
+ return __rds_rdma_map(rs, &args, NULL, NULL, NULL);
}
int rds_get_mr_for_dest(struct rds_sock *rs, char __user *optval, int optlen)
@@ -354,7 +356,7 @@ int rds_get_mr_for_dest(struct rds_sock *rs, char __user *optval, int optlen)
new_args.cookie_addr = args.cookie_addr;
new_args.flags = args.flags;
- return __rds_rdma_map(rs, &new_args, NULL, NULL);
+ return __rds_rdma_map(rs, &new_args, NULL, NULL, NULL);
}
/*
@@ -782,7 +784,8 @@ int rds_cmsg_rdma_map(struct rds_sock *rs, struct rds_message *rm,
rm->m_rdma_cookie != 0)
return -EINVAL;
- return __rds_rdma_map(rs, CMSG_DATA(cmsg), &rm->m_rdma_cookie, &rm->rdma.op_rdma_mr);
+ return __rds_rdma_map(rs, CMSG_DATA(cmsg), &rm->m_rdma_cookie,
+ &rm->rdma.op_rdma_mr, rm->m_conn_path);
}
/*
diff --git a/net/rds/rds.h b/net/rds/rds.h
index f2272fb..60b3b78 100644
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -464,6 +464,8 @@ struct rds_message {
struct scatterlist *op_sg;
} data;
};
+
+ struct rds_conn_path *m_conn_path;
};
/*
@@ -544,7 +546,8 @@ struct rds_transport {
unsigned int avail);
void (*exit)(void);
void *(*get_mr)(struct scatterlist *sg, unsigned long nr_sg,
- struct rds_sock *rs, u32 *key_ret);
+ struct rds_sock *rs, u32 *key_ret,
+ struct rds_connection *conn);
void (*sync_mr)(void *trans_private, int direction);
void (*free_mr)(void *trans_private, int invalidate);
void (*flush_mrs)(void);
diff --git a/net/rds/send.c b/net/rds/send.c
index 94c7f74..59f17a2 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -1169,6 +1169,13 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len)
rs->rs_conn = conn;
}
+ if (conn->c_trans->t_mp_capable)
+ cpath = &conn->c_path[rds_send_mprds_hash(rs, conn)];
+ else
+ cpath = &conn->c_path[0];
+
+ rm->m_conn_path = cpath;
+
/* Parse any control messages the user may have included. */
ret = rds_cmsg_send(rs, rm, msg, &allocated_mr);
if (ret) {
@@ -1192,11 +1199,6 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len)
goto out;
}
- if (conn->c_trans->t_mp_capable)
- cpath = &conn->c_path[rds_send_mprds_hash(rs, conn)];
- else
- cpath = &conn->c_path[0];
-
if (rds_destroy_pending(conn)) {
ret = -EAGAIN;
goto out;
--
2.4.11
^ permalink raw reply related
* Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8
From: Michael Ellerman @ 2018-07-25 4:20 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Morton
Cc: Joe Perches, Arnd Bergmann, Samuel Ortiz, David S. Miller,
Rob Herring, Jonathan Cameron, linux-wireless, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-crypto, linuxppc-dev,
linux-iio, linux-pm, lvs-devel, netfilter-devel, coreteam
In-Reply-To: <20180724111600.4158975-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
...
> drivers/crypto/vmx/ghashp8-ppc.pl | 12 +-
...
> diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl b/drivers/crypto/vmx/ghashp8-ppc.pl
> index f746af271460..38b06503ede0 100644
> --- a/drivers/crypto/vmx/ghashp8-ppc.pl
> +++ b/drivers/crypto/vmx/ghashp8-ppc.pl
> @@ -129,9 +129,9 @@ $code=<<___;
> le?vperm $IN,$IN,$IN,$lemask
> vxor $zero,$zero,$zero
>
> - vpmsumd $Xl,$IN,$Hl # H.loXi.lo
> - vpmsumd $Xm,$IN,$H # H.hiXi.lo+H.loXi.hi
> - vpmsumd $Xh,$IN,$Hh # H.hiXi.hi
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> + vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>
> vpmsumd $t2,$Xl,$xC2 # 1st phase
>
> @@ -187,11 +187,11 @@ $code=<<___;
> .align 5
> Loop:
> subic $len,$len,16
> - vpmsumd $Xl,$IN,$Hl # H.loXi.lo
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> subfe. r0,r0,r0 # borrow?-1:0
> - vpmsumd $Xm,$IN,$H # H.hiXi.lo+H.loXi.hi
> + vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
> and r0,r0,$len
> - vpmsumd $Xh,$IN,$Hh # H.hiXi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
> add $inp,$inp,r0
>
> vpmsumd $t2,$Xl,$xC2 # 1st phase
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* Re: [PATCH] 9p: validate PDU length
From: Dominique Martinet @ 2018-07-25 4:11 UTC (permalink / raw)
To: Tomas Bortoli; +Cc: davem, v9fs-developer, netdev, linux-kernel, syzkaller
In-Reply-To: <20180723154404.2406-1-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Mon, Jul 23, 2018:
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 18c5271910dc..92240ccf476b 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -524,6 +525,12 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
> int ecode;
>
> err = p9_parse_header(req->rc, NULL, &type, NULL, 0);
> + if (req->rc->size >= c->msize) {
I was looking at this again, I think it's more appropriate to use
req->rc->capacity at this point like you did in the first version of the
patch.
I had suggested msize in the common p9_parse_header function because
that'd let us accept zc requests where the size in the pdu could be
bigger than capacity, but this isn't the case in p9_check_errors.
If you're ok with this I'll edit your commit directly, this is less work
for me than having to check a new patch.
Thanks,
--
Dominique
^ permalink raw reply
* [PATCH net-next 2/2] docs: net: Convert netdev-FAQ to restructured text
From: Tobin C. Harding @ 2018-07-25 2:50 UTC (permalink / raw)
To: David S. Miller, Jonathan Corbet
Cc: Tobin C. Harding, linux-doc, netdev, linux-kernel
In-Reply-To: <20180725025005.14332-1-me@tobin.cc>
Preferred kernel docs format is now restructured text. Convert
netdev-FAQ.txt to restructured text.
- Add SPDX license identifier.
- Change file heading 'Information you need to know about netdev' to
'netdev FAQ' to better suit displayed index (in HTML).
- Change question/answer layout to suit rst. Copy format in
Documentation/bpf/bpf_devel_QA.rst
- Fix indentation of code snippets
- If multiple consecutive URLs appear put them in a list (to maintain
whitespace).
- Use uniform spelling of 'bug fix' throughout document (not bugfix or
bug-fix).
- Add double back ticks to 'net' and 'net-next' when referring to the
trees.
- Use rst references for Documentation/ links.
- Add rst label 'netdev-FAQ' for referencing by other docs files.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/index.rst | 1 +
Documentation/networking/netdev-FAQ.rst | 259 ++++++++++++++++++++++++
Documentation/networking/netdev-FAQ.txt | 244 ----------------------
3 files changed, 260 insertions(+), 244 deletions(-)
create mode 100644 Documentation/networking/netdev-FAQ.rst
delete mode 100644 Documentation/networking/netdev-FAQ.txt
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index f0ae9b65dfba..884a26145f20 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -6,6 +6,7 @@ Contents:
.. toctree::
:maxdepth: 2
+ netdev-FAQ
af_xdp
batman-adv
can
diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst
new file mode 100644
index 000000000000..d388843d4d54
--- /dev/null
+++ b/Documentation/networking/netdev-FAQ.rst
@@ -0,0 +1,259 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _netdev-FAQ:
+
+==========
+netdev FAQ
+==========
+
+Q: What is netdev?
+------------------
+A: It is a mailing list for all network-related Linux stuff. This
+includes anything found under net/ (i.e. core code like IPv6) and
+drivers/net (i.e. hardware specific drivers) in the Linux source tree.
+
+Note that some subsystems (e.g. wireless drivers) which have a high
+volume of traffic have their own specific mailing lists.
+
+The netdev list is managed (like many other Linux mailing lists) through
+VGER (http://vger.kernel.org/) and archives can be found below:
+
+- http://marc.info/?l=linux-netdev
+- http://www.spinics.net/lists/netdev/
+
+Aside from subsystems like that mentioned above, all network-related
+Linux development (i.e. RFC, review, comments, etc.) takes place on
+netdev.
+
+Q: How do the changes posted to netdev make their way into Linux?
+-----------------------------------------------------------------
+A: There are always two trees (git repositories) in play. Both are
+driven by David Miller, the main network maintainer. There is the
+``net`` tree, and the ``net-next`` tree. As you can probably guess from
+the names, the ``net`` tree is for fixes to existing code already in the
+mainline tree from Linus, and ``net-next`` is where the new code goes
+for the future release. You can find the trees here:
+
+- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
+- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
+
+Q: How often do changes from these trees make it to the mainline Linus tree?
+----------------------------------------------------------------------------
+A: To understand this, you need to know a bit of background information on
+the cadence of Linux development. Each new release starts off with a
+two week "merge window" where the main maintainers feed their new stuff
+to Linus for merging into the mainline tree. After the two weeks, the
+merge window is closed, and it is called/tagged ``-rc1``. No new
+features get mainlined after this -- only fixes to the rc1 content are
+expected. After roughly a week of collecting fixes to the rc1 content,
+rc2 is released. This repeats on a roughly weekly basis until rc7
+(typically; sometimes rc6 if things are quiet, or rc8 if things are in a
+state of churn), and a week after the last vX.Y-rcN was done, the
+official vX.Y is released.
+
+Relating that to netdev: At the beginning of the 2-week merge window,
+the ``net-next`` tree will be closed - no new changes/features. The
+accumulated new content of the past ~10 weeks will be passed onto
+mainline/Linus via a pull request for vX.Y -- at the same time, the
+``net`` tree will start accumulating fixes for this pulled content
+relating to vX.Y
+
+An announcement indicating when ``net-next`` has been closed is usually
+sent to netdev, but knowing the above, you can predict that in advance.
+
+IMPORTANT: Do not send new ``net-next`` content to netdev during the
+period during which ``net-next`` tree is closed.
+
+Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
+tree for ``net-next`` reopens to collect content for the next (vX.Y+1)
+release.
+
+If you aren't subscribed to netdev and/or are simply unsure if
+``net-next`` has re-opened yet, simply check the ``net-next`` git
+repository link above for any new networking-related commits. You may
+also check the following website for the current status:
+
+ http://vger.kernel.org/~davem/net-next.html
+
+The ``net`` tree continues to collect fixes for the vX.Y content, and is
+fed back to Linus at regular (~weekly) intervals. Meaning that the
+focus for ``net`` is on stabilization and bug fixes.
+
+Finally, the vX.Y gets released, and the whole cycle starts over.
+
+Q: So where are we now in this cycle?
+
+Load the mainline (Linus) page here:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
+and note the top of the "tags" section. If it is rc1, it is early in
+the dev cycle. If it was tagged rc7 a week ago, then a release is
+probably imminent.
+
+Q: How do I indicate which tree (net vs. net-next) my patch should be in?
+-------------------------------------------------------------------------
+A: Firstly, think whether you have a bug fix or new "next-like" content.
+Then once decided, assuming that you use git, use the prefix flag, i.e.
+::
+
+ git format-patch --subject-prefix='PATCH net-next' start..finish
+
+Use ``net`` instead of ``net-next`` (always lower case) in the above for
+bug-fix ``net`` content. If you don't use git, then note the only magic
+in the above is just the subject text of the outgoing e-mail, and you
+can manually change it yourself with whatever MUA you are comfortable
+with.
+
+Q: I sent a patch and I'm wondering what happened to it?
+--------------------------------------------------------
+Q: How can I tell whether it got merged?
+A: Start by looking at the main patchworks queue for netdev:
+
+ http://patchwork.ozlabs.org/project/netdev/list/
+
+The "State" field will tell you exactly where things are at with your
+patch.
+
+Q: The above only says "Under Review". How can I find out more?
+----------------------------------------------------------------
+A: Generally speaking, the patches get triaged quickly (in less than
+48h). So be patient. Asking the maintainer for status updates on your
+patch is a good way to ensure your patch is ignored or pushed to the
+bottom of the priority list.
+
+Q: I submitted multiple versions of the patch series
+----------------------------------------------------
+Q: should I directly update patchwork for the previous versions of these
+patch series?
+A: No, please don't interfere with the patch status on patchwork, leave
+it to the maintainer to figure out what is the most recent and current
+version that should be applied. If there is any doubt, the maintainer
+will reply and ask what should be done.
+
+Q: How can I tell what patches are queued up for backporting to the various stable releases?
+--------------------------------------------------------------------------------------------
+A: Normally Greg Kroah-Hartman collects stable commits himself, but for
+networking, Dave collects up patches he deems critical for the
+networking subsystem, and then hands them off to Greg.
+
+There is a patchworks queue that you can see here:
+
+ http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
+
+It contains the patches which Dave has selected, but not yet handed off
+to Greg. If Greg already has the patch, then it will be here:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+
+A quick way to find whether the patch is in this stable-queue is to
+simply clone the repo, and then git grep the mainline commit ID, e.g.
+::
+
+ stable-queue$ git grep -l 284041ef21fdf2e
+ releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
+ releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
+ releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
+ stable/stable-queue$
+
+Q: I see a network patch and I think it should be backported to stable.
+-----------------------------------------------------------------------
+Q: Should I request it via stable@vger.kernel.org like the references in
+the kernel's Documentation/process/stable-kernel-rules.rst file say?
+A: No, not for networking. Check the stable queues as per above first
+to see if it is already queued. If not, then send a mail to netdev,
+listing the upstream commit ID and why you think it should be a stable
+candidate.
+
+Before you jump to go do the above, do note that the normal stable rules
+in :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+still apply. So you need to explicitly indicate why it is a critical
+fix and exactly what users are impacted. In addition, you need to
+convince yourself that you *really* think it has been overlooked,
+vs. having been considered and rejected.
+
+Generally speaking, the longer it has had a chance to "soak" in
+mainline, the better the odds that it is an OK candidate for stable. So
+scrambling to request a commit be added the day after it appears should
+be avoided.
+
+Q: I have created a network patch and I think it should be backported to stable.
+--------------------------------------------------------------------------------
+Q: Should I add a Cc: stable@vger.kernel.org like the references in the
+kernel's Documentation/ directory say?
+A: No. See above answer. In short, if you think it really belongs in
+stable, then ensure you write a decent commit log that describes who
+gets impacted by the bug fix and how it manifests itself, and when the
+bug was introduced. If you do that properly, then the commit will get
+handled appropriately and most likely get put in the patchworks stable
+queue if it really warrants it.
+
+If you think there is some valid information relating to it being in
+stable that does *not* belong in the commit log, then use the three dash
+marker line as described in
+:ref:`Documentation/process/submitting-patches.rst <the_canonical_patch_format>`
+to temporarily embed that information into the patch that you send.
+
+Q: Are all networking bug fixes backported to all stable releases?
+------------------------------------------------------------------
+A: Due to capacity, Dave could only take care of the backports for the
+last two stable releases. For earlier stable releases, each stable
+branch maintainer is supposed to take care of them. If you find any
+patch is missing from an earlier stable branch, please notify
+stable@vger.kernel.org with either a commit ID or a formal patch
+backported, and CC Dave and other relevant networking developers.
+
+Q: Is the comment style convention different for the networking content?
+------------------------------------------------------------------------
+A: Yes, in a largely trivial way. Instead of this::
+
+ /*
+ * foobar blah blah blah
+ * another line of text
+ */
+
+it is requested that you make it look like this::
+
+ /* foobar blah blah blah
+ * another line of text
+ */
+
+Q: I am working in existing code that has the former comment style and not the latter.
+--------------------------------------------------------------------------------------
+Q: Should I submit new code in the former style or the latter?
+A: Make it the latter style, so that eventually all code in the domain
+of netdev is of this format.
+
+Q: I found a bug that might have possible security implications or similar.
+---------------------------------------------------------------------------
+Q: Should I mail the main netdev maintainer off-list?**
+A: No. The current netdev maintainer has consistently requested that
+people use the mailing lists and not reach out directly. If you aren't
+OK with that, then perhaps consider mailing security@kernel.org or
+reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
+as possible alternative mechanisms.
+
+Q: What level of testing is expected before I submit my change?
+---------------------------------------------------------------
+A: If your changes are against ``net-next``, the expectation is that you
+have tested by layering your changes on top of ``net-next``. Ideally
+you will have done run-time testing specific to your change, but at a
+minimum, your changes should survive an ``allyesconfig`` and an
+``allmodconfig`` build without new warnings or failures.
+
+Q: Any other tips to help ensure my net/net-next patch gets OK'd?
+-----------------------------------------------------------------
+A: Attention to detail. Re-read your own work as if you were the
+reviewer. You can start with using ``checkpatch.pl``, perhaps even with
+the ``--strict`` flag. But do not be mindlessly robotic in doing so.
+If your change is a bug fix, make sure your commit log indicates the
+end-user visible symptom, the underlying reason as to why it happens,
+and then if necessary, explain why the fix proposed is the best way to
+get things done. Don't mangle whitespace, and as is common, don't
+mis-indent function arguments that span multiple lines. If it is your
+first patch, mail it to yourself so you can test apply it to an
+unpatched tree to confirm infrastructure didn't mangle it.
+
+Finally, go back and read
+:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+to be sure you are not repeating some common mistake documented there.
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt
deleted file mode 100644
index fa951b820b25..000000000000
--- a/Documentation/networking/netdev-FAQ.txt
+++ /dev/null
@@ -1,244 +0,0 @@
-
-Information you need to know about netdev
------------------------------------------
-
-Q: What is netdev?
-
-A: It is a mailing list for all network-related Linux stuff. This includes
- anything found under net/ (i.e. core code like IPv6) and drivers/net
- (i.e. hardware specific drivers) in the Linux source tree.
-
- Note that some subsystems (e.g. wireless drivers) which have a high volume
- of traffic have their own specific mailing lists.
-
- The netdev list is managed (like many other Linux mailing lists) through
- VGER ( http://vger.kernel.org/ ) and archives can be found below:
-
- http://marc.info/?l=linux-netdev
- http://www.spinics.net/lists/netdev/
-
- Aside from subsystems like that mentioned above, all network-related Linux
- development (i.e. RFC, review, comments, etc.) takes place on netdev.
-
-Q: How do the changes posted to netdev make their way into Linux?
-
-A: There are always two trees (git repositories) in play. Both are driven
- by David Miller, the main network maintainer. There is the "net" tree,
- and the "net-next" tree. As you can probably guess from the names, the
- net tree is for fixes to existing code already in the mainline tree from
- Linus, and net-next is where the new code goes for the future release.
- You can find the trees here:
-
- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
-
-Q: How often do changes from these trees make it to the mainline Linus tree?
-
-A: To understand this, you need to know a bit of background information
- on the cadence of Linux development. Each new release starts off with
- a two week "merge window" where the main maintainers feed their new
- stuff to Linus for merging into the mainline tree. After the two weeks,
- the merge window is closed, and it is called/tagged "-rc1". No new
- features get mainlined after this -- only fixes to the rc1 content
- are expected. After roughly a week of collecting fixes to the rc1
- content, rc2 is released. This repeats on a roughly weekly basis
- until rc7 (typically; sometimes rc6 if things are quiet, or rc8 if
- things are in a state of churn), and a week after the last vX.Y-rcN
- was done, the official "vX.Y" is released.
-
- Relating that to netdev: At the beginning of the 2-week merge window,
- the net-next tree will be closed - no new changes/features. The
- accumulated new content of the past ~10 weeks will be passed onto
- mainline/Linus via a pull request for vX.Y -- at the same time,
- the "net" tree will start accumulating fixes for this pulled content
- relating to vX.Y
-
- An announcement indicating when net-next has been closed is usually
- sent to netdev, but knowing the above, you can predict that in advance.
-
- IMPORTANT: Do not send new net-next content to netdev during the
- period during which net-next tree is closed.
-
- Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
- tree for net-next reopens to collect content for the next (vX.Y+1) release.
-
- If you aren't subscribed to netdev and/or are simply unsure if net-next
- has re-opened yet, simply check the net-next git repository link above for
- any new networking-related commits. You may also check the following
- website for the current status:
-
- http://vger.kernel.org/~davem/net-next.html
-
- The "net" tree continues to collect fixes for the vX.Y content, and
- is fed back to Linus at regular (~weekly) intervals. Meaning that the
- focus for "net" is on stabilization and bugfixes.
-
- Finally, the vX.Y gets released, and the whole cycle starts over.
-
-Q: So where are we now in this cycle?
-
-A: Load the mainline (Linus) page here:
-
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
-
- and note the top of the "tags" section. If it is rc1, it is early
- in the dev cycle. If it was tagged rc7 a week ago, then a release
- is probably imminent.
-
-Q: How do I indicate which tree (net vs. net-next) my patch should be in?
-
-A: Firstly, think whether you have a bug fix or new "next-like" content.
- Then once decided, assuming that you use git, use the prefix flag, i.e.
-
- git format-patch --subject-prefix='PATCH net-next' start..finish
-
- Use "net" instead of "net-next" (always lower case) in the above for
- bug-fix net content. If you don't use git, then note the only magic in
- the above is just the subject text of the outgoing e-mail, and you can
- manually change it yourself with whatever MUA you are comfortable with.
-
-Q: I sent a patch and I'm wondering what happened to it. How can I tell
- whether it got merged?
-
-A: Start by looking at the main patchworks queue for netdev:
-
- http://patchwork.ozlabs.org/project/netdev/list/
-
- The "State" field will tell you exactly where things are at with
- your patch.
-
-Q: The above only says "Under Review". How can I find out more?
-
-A: Generally speaking, the patches get triaged quickly (in less than 48h).
- So be patient. Asking the maintainer for status updates on your
- patch is a good way to ensure your patch is ignored or pushed to
- the bottom of the priority list.
-
-Q: I submitted multiple versions of the patch series, should I directly update
- patchwork for the previous versions of these patch series?
-
-A: No, please don't interfere with the patch status on patchwork, leave it to
- the maintainer to figure out what is the most recent and current version that
- should be applied. If there is any doubt, the maintainer will reply and ask
- what should be done.
-
-Q: How can I tell what patches are queued up for backporting to the
- various stable releases?
-
-A: Normally Greg Kroah-Hartman collects stable commits himself, but
- for networking, Dave collects up patches he deems critical for the
- networking subsystem, and then hands them off to Greg.
-
- There is a patchworks queue that you can see here:
- http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
-
- It contains the patches which Dave has selected, but not yet handed
- off to Greg. If Greg already has the patch, then it will be here:
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
-
- A quick way to find whether the patch is in this stable-queue is
- to simply clone the repo, and then git grep the mainline commit ID, e.g.
-
- stable-queue$ git grep -l 284041ef21fdf2e
- releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
- releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
- releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
- stable/stable-queue$
-
-Q: I see a network patch and I think it should be backported to stable.
- Should I request it via "stable@vger.kernel.org" like the references in
- the kernel's Documentation/process/stable-kernel-rules.rst file say?
-
-A: No, not for networking. Check the stable queues as per above 1st to see
- if it is already queued. If not, then send a mail to netdev, listing
- the upstream commit ID and why you think it should be a stable candidate.
-
- Before you jump to go do the above, do note that the normal stable rules
- in Documentation/process/stable-kernel-rules.rst still apply. So you need to
- explicitly indicate why it is a critical fix and exactly what users are
- impacted. In addition, you need to convince yourself that you _really_
- think it has been overlooked, vs. having been considered and rejected.
-
- Generally speaking, the longer it has had a chance to "soak" in mainline,
- the better the odds that it is an OK candidate for stable. So scrambling
- to request a commit be added the day after it appears should be avoided.
-
-Q: I have created a network patch and I think it should be backported to
- stable. Should I add a "Cc: stable@vger.kernel.org" like the references
- in the kernel's Documentation/ directory say?
-
-A: No. See above answer. In short, if you think it really belongs in
- stable, then ensure you write a decent commit log that describes who
- gets impacted by the bugfix and how it manifests itself, and when the
- bug was introduced. If you do that properly, then the commit will
- get handled appropriately and most likely get put in the patchworks
- stable queue if it really warrants it.
-
- If you think there is some valid information relating to it being in
- stable that does _not_ belong in the commit log, then use the three
- dash marker line as described in Documentation/process/submitting-patches.rst to
- temporarily embed that information into the patch that you send.
-
-Q: Are all networking bug fixes backported to all stable releases?
-
-A: Due to capacity, Dave could only take care of the backports for the last
- 2 stable releases. For earlier stable releases, each stable branch maintainer
- is supposed to take care of them. If you find any patch is missing from an
- earlier stable branch, please notify stable@vger.kernel.org with either a
- commit ID or a formal patch backported, and CC Dave and other relevant
- networking developers.
-
-Q: Someone said that the comment style and coding convention is different
- for the networking content. Is this true?
-
-A: Yes, in a largely trivial way. Instead of this:
-
- /*
- * foobar blah blah blah
- * another line of text
- */
-
- it is requested that you make it look like this:
-
- /* foobar blah blah blah
- * another line of text
- */
-
-Q: I am working in existing code that has the former comment style and not the
- latter. Should I submit new code in the former style or the latter?
-
-A: Make it the latter style, so that eventually all code in the domain of
- netdev is of this format.
-
-Q: I found a bug that might have possible security implications or similar.
- Should I mail the main netdev maintainer off-list?
-
-A: No. The current netdev maintainer has consistently requested that people
- use the mailing lists and not reach out directly. If you aren't OK with
- that, then perhaps consider mailing "security@kernel.org" or reading about
- http://oss-security.openwall.org/wiki/mailing-lists/distros
- as possible alternative mechanisms.
-
-Q: What level of testing is expected before I submit my change?
-
-A: If your changes are against net-next, the expectation is that you
- have tested by layering your changes on top of net-next. Ideally you
- will have done run-time testing specific to your change, but at a
- minimum, your changes should survive an "allyesconfig" and an
- "allmodconfig" build without new warnings or failures.
-
-Q: Any other tips to help ensure my net/net-next patch gets OK'd?
-
-A: Attention to detail. Re-read your own work as if you were the
- reviewer. You can start with using checkpatch.pl, perhaps even
- with the "--strict" flag. But do not be mindlessly robotic in
- doing so. If your change is a bug-fix, make sure your commit log
- indicates the end-user visible symptom, the underlying reason as
- to why it happens, and then if necessary, explain why the fix proposed
- is the best way to get things done. Don't mangle whitespace, and as
- is common, don't mis-indent function arguments that span multiple lines.
- If it is your first patch, mail it to yourself so you can test apply
- it to an unpatched tree to confirm infrastructure didn't mangle it.
-
- Finally, go back and read Documentation/process/submitting-patches.rst to be
- sure you are not repeating some common mistake documented there.
--
2.17.1
^ permalink raw reply related
* Re: general protection fault in rds_ib_get_mr
From: santosh.shilimkar @ 2018-07-25 3:58 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: Eric Biggers, linux-rdma, rds-devel, syzbot, davem, linux-kernel,
netdev, syzkaller-bugs
In-Reply-To: <20180706081113.kwrwcat5l6o7ozar@linux-x5ow.site>
On 7/6/18 1:11 AM, Johannes Thumshirn wrote:
> On Thu, Jul 05, 2018 at 09:09:44AM -0700, Santosh Shilimkar wrote:
>> OK. we will look into it if an interim fix can be made....
>
> Thanks a lot.
>
Intermediate fix is posted here [1]
Regards,
Santosh
[1] https://patchwork.ozlabs.org/patch/949010/
^ permalink raw reply
* [PATCH net-next] net/sched: cls_flower: Use correct inline function for assignment of vlan tpid
From: Jianbo Liu @ 2018-07-25 2:31 UTC (permalink / raw)
To: netdev, davem; +Cc: Jianbo Liu, Jamal Hadi Salim, Cong Wang, Jiri Pirko
This fixes the following sparse warning:
net/sched/cls_flower.c:1356:36: warning: incorrect type in argument 3 (different base types)
net/sched/cls_flower.c:1356:36: expected unsigned short [unsigned] [usertype] value
net/sched/cls_flower.c:1356:36: got restricted __be16 [usertype] vlan_tpid
Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
---
net/sched/cls_flower.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index c53fdd4..1d8559d 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -1340,8 +1340,8 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
TCA_FLOWER_KEY_CVLAN_PRIO,
&key->cvlan, &mask->cvlan) ||
(mask->cvlan.vlan_tpid &&
- nla_put_u16(skb, TCA_FLOWER_KEY_VLAN_ETH_TYPE,
- key->cvlan.vlan_tpid)))
+ nla_put_be16(skb, TCA_FLOWER_KEY_VLAN_ETH_TYPE,
+ key->cvlan.vlan_tpid)))
goto nla_put_failure;
if (mask->basic.n_proto) {
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next 0/2] docs: net: Convert netdev-FAQ to RST
From: Tobin C. Harding @ 2018-07-25 3:28 UTC (permalink / raw)
To: David S. Miller, Jonathan Corbet; +Cc: linux-doc, netdev, linux-kernel
In-Reply-To: <20180725025005.14332-1-me@tobin.cc>
On Wed, Jul 25, 2018 at 12:50:03PM +1000, Tobin C. Harding wrote:
Please drop this. I've forgotten to deal with the links from
Documentation/*.rst to Documentation/networking/netdev-FAQ.txt
Since I've already botched it can I ask for guidance here. The problem
is updating the links means making changes that will cause merge
conflicts if they go through net-dev tree (since most references are in
Documentation/*.rst). But we can't go through docs tree either since
that could lead to merge conflicts later as well.
My idea was to leave netdev-FAQ.txt in place but with all content
removed except
'This file has moved to netdev-FAQ.rst. This file will be removed once
netdev RST conversion is complete'
And then do the same for each file conversion under
Documentation/networking/. Once all the files are converted a single
patch set updating all references into Documentation/networking/*.rst
could be posted to the docs tree.
One other idea was to leave a symlink netdev-FAQ.txt -> netdev-FAQ.rst
but I don't know how that would play with the build system (docs or
otherwise).
thanks,
Tobin.
^ permalink raw reply
* Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives
From: Neal Cardwell @ 2018-07-25 1:57 UTC (permalink / raw)
To: Lawrence Brakmo
Cc: Yuchung Cheng, Daniel Borkmann, Netdev, Kernel Team, ast,
Eric Dumazet
In-Reply-To: <36385AF4-4EE4-4237-84B8-1978B091E28B@fb.com>
On Tue, Jul 24, 2018 at 1:42 PM Lawrence Brakmo <brakmo@fb.com> wrote:
>
> Note that without this fix the 99% latencies when doing 10KB RPCs
> in a congested network using DCTCP are 40ms vs. 190us with the patch.
> Also note that these 40ms high tail latencies started after commit
> 3759824da87b30ce7a35b4873b62b0ba38905ef5 in Jul 2015,
> which triggered the bugs/features we are fixing/adding. I agree it is a
> debatable whether it is a bug fix or a feature improvement and I am
> fine either way.
Good point. The fact that this greatly mitigates a regression in DCTCP
performance resulting from 3759824da87b30ce7a35b4873b62b0ba38905ef5
("tcp: PRR uses CRB mode by default and SS mode conditionally") IMHO
seems to be a good argument for putting this patch ("tcp: ack
immediately when a cwr packet arrives") in the "net" branch and stable
releases.
thanks,
neal
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Do not call msg_data_left() twice
From: Vakul Garg @ 2018-07-25 1:54 UTC (permalink / raw)
To: Al Viro
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davejwatson@fb.com, davem@davemloft.net
In-Reply-To: <20180725014920.GJ30522@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
From: Al Viro
Sent: Wednesday, 25 July, 7:19 AM
Subject: Re: [PATCH net-next] net/tls: Do not call msg_data_left() twice
To: Vakul Garg
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com, davejwatson@fb.com, davem@davemloft.net
On Tue, Jul 24, 2018 at 04:41:18PM +0530, Vakul Garg wrote: > In function tls_sw_sendmsg(), msg_data_left() needs to be called only > once. The second invocation of msg_data_left() for assigning variable > try_to_copy can be removed and merged with the first one. You do realize that msg_data_left(msg) is simply msg->msg_iter.count? So I'm not at all sure that your change will be an overall win...
Agreed, msg_data_left is inexpensive. It's just that is pointless to call it again.
[-- Attachment #2: Type: text/html, Size: 1991 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Do not call msg_data_left() twice
From: Al Viro @ 2018-07-25 1:49 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davejwatson, davem
In-Reply-To: <20180724111118.15415-1-vakul.garg@nxp.com>
On Tue, Jul 24, 2018 at 04:41:18PM +0530, Vakul Garg wrote:
> In function tls_sw_sendmsg(), msg_data_left() needs to be called only
> once. The second invocation of msg_data_left() for assigning variable
> try_to_copy can be removed and merged with the first one.
You do realize that msg_data_left(msg) is simply msg->msg_iter.count?
So I'm not at all sure that your change will be an overall win...
^ permalink raw reply
* [PATCH net-next 1/2] docs: Add rest label the_canonical_path_format
From: Tobin C. Harding @ 2018-07-25 2:50 UTC (permalink / raw)
To: David S. Miller, Jonathan Corbet
Cc: Tobin C. Harding, linux-doc, netdev, linux-kernel
In-Reply-To: <20180725025005.14332-1-me@tobin.cc>
In preparation to convert Documentation/network/netdev-FAQ.rst to
restructured text format we would like to be able to reference 'the
canonical patch format' section.
Add rest label: 'the_canonical_path_format'.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/process/submitting-patches.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 908bb55be407..c0917107b90a 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -611,6 +611,7 @@ which stable kernel versions should receive your fix. This is the preferred
method for indicating a bug fixed by the patch. See :ref:`describe_changes`
for more details.
+.. _the_canonical_patch_format:
14) The canonical patch format
------------------------------
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox