* Re: second wave of netlink extended ACK reporting
From: David Ahern @ 2017-04-16 14:50 UTC (permalink / raw)
To: Jamal Hadi Salim, Johannes Berg,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w, Jiri Pirko, Pravin Shelar,
dev-yBygre7rU0TnMu66kgdUjQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jiri Benc,
pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <280d0c61-4506-f721-1536-4afb2daabef8-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
On 4/16/17 8:48 AM, Jamal Hadi Salim wrote:
> Excellent. His patches seem to be in. Seems
> commit ce07183282975026716107d36fd3f5f93de76668
> is a good point?
yes. will send later today.
^ permalink raw reply
* Re: second wave of netlink extended ACK reporting
From: Jamal Hadi Salim @ 2017-04-16 14:48 UTC (permalink / raw)
To: David Ahern, Johannes Berg,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w, Jiri Pirko, Pravin Shelar,
dev-yBygre7rU0TnMu66kgdUjQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, pablo-Cap9r6Oaw4JrovVCs/uTlw,
Jiri Benc
In-Reply-To: <c75ab5ec-d33e-256d-1222-590dd22c5b08-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
On 17-04-16 10:45 AM, David Ahern wrote:
> On 4/16/17 8:40 AM, Jamal Hadi Salim wrote:
>>
>> Johannes or anybody else working on it?
>> i.e one which sends the extack to the bowels of callees
>> so we can return meaningful messages
>> example: rtnetlink::doit() or equivalent seems to be a candidate for
>> taking it as a param
>
> I have a patch for the first pass on rtnetlink doit path. plumbs the
> extack parameter and covers the nlmsg_parse case. I'll send it once
> Johannes' patches go in.
>
Excellent. His patches seem to be in. Seems
commit ce07183282975026716107d36fd3f5f93de76668
is a good point?
cheers,
jamal
^ permalink raw reply
* Re: second wave of netlink extended ACK reporting
From: David Ahern @ 2017-04-16 14:45 UTC (permalink / raw)
To: Jamal Hadi Salim, Johannes Berg,
nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w, Jiri Pirko, Pravin Shelar,
dev-yBygre7rU0TnMu66kgdUjQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, pablo-Cap9r6Oaw4JrovVCs/uTlw,
Jiri Benc
In-Reply-To: <826de765-dd18-f6a3-8e37-7b55398ad99b-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
On 4/16/17 8:40 AM, Jamal Hadi Salim wrote:
>
> Johannes or anybody else working on it?
> i.e one which sends the extack to the bowels of callees
> so we can return meaningful messages
> example: rtnetlink::doit() or equivalent seems to be a candidate for
> taking it as a param
I have a patch for the first pass on rtnetlink doit path. plumbs the
extack parameter and covers the nlmsg_parse case. I'll send it once
Johannes' patches go in.
^ permalink raw reply
* second wave of netlink extended ACK reporting
From: Jamal Hadi Salim @ 2017-04-16 14:40 UTC (permalink / raw)
To: Johannes Berg, nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w,
David Ahern, Jiri Pirko, Pravin Shelar,
dev-yBygre7rU0TnMu66kgdUjQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jiri Benc,
pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <1492111480.29526.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Johannes or anybody else working on it?
i.e one which sends the extack to the bowels of callees
so we can return meaningful messages
example: rtnetlink::doit() or equivalent seems to be a candidate for
taking it as a param
For things that call netlink_ack it may be easier if they create
the extack.
For dumps it makes it tricky since their lifetime is much
longer..
cheers,
jamal
^ permalink raw reply
* Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error
From: Jamal Hadi Salim @ 2017-04-16 14:30 UTC (permalink / raw)
To: Wolfgang Bumiller
Cc: Cong Wang, David S. Miller, Roman Mashak, netdev@vger.kernel.org
In-Reply-To: <1985738840.18.1492282135309@webmail.proxmox.com>
Wolfgang, can you _please_ stop cc-ing lkml? Everybody you need to deal
with is on netdev.
On 17-04-15 02:48 PM, Wolfgang Bumiller wrote:
>
>>
>>> So I'm not sure exactly how the module and tc_action counts are related
>>> (and I usually like to understand my own patches ;-) ).
>>
>>
Every time we add an action, refcnt goes up. Every time we bind an
action to a filter the refcnt + bindcnt goes up.
Reverse for everytime we delete a filter or action. The action does
not get destroyed because the filter was deleted.
Everytime the action gets its refcount bumped up (for either of the
two reasons described above), the module ref needs incrementing.
Everytime the action refcnt goes down the module ref needs to be
decremented.
Only when both refcnt and bind cnt go to at least zero do we really
delete/destroy.
>> Each action holds a refcnt to its module, each filter holds a refcnt to
>> its bound or referenced (unbound) action.
>>
>>
>>> Maybe I'm missing something obvious but I'm currently a bit confused as
>>> to whether the tcf_hash_release() call there is okay, or should have its
>>> return value checked or should depend on ->init()'s ACT_P_CREATED value
>>> as well?
>>>
>>
>> I think it's the same? If we have ACT_P_CREATED here, tcf_hash_release()
>> will return ACT_P_DELETED for sure because the newly created action has
>> refcnt==1?
>
> Makes sense on the one hand, but for ACT_P_DELETED both ref and bind
> count need to reach 0, so I'm still concerned that the different behaviors
> I mentioned above might be problematic if we use ACT_P_CREATED only.
> (It also means my patches still leak a count - which is probably still
> better than the previous underflow, but ultimately doesn't satisfy me.)
> Should I still resend it this way for the record with the Acked-bys?
> (Since given the fact that with unprivileged containers it's possible to
> trigger this access and potentially crash the kernel I strongly feel that
> some version of this should end up in the 4.11 release.)
>
I think that is an unrelated code path, current issue is on the
create/replace code path. We need to separate delete from get - we
just havent got around to it yet. Followup patches will make sense.
Agree, this change should go in quickly..
Actually - come to think of it: You should probably leave the module
put to the end instead of the beginning because it protects against
another entry unloading the module while we are still processing.
Just post the patch - we'll help reviewing it.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 1/1] net sched actions: add time filter for action dumping
From: Jamal Hadi Salim @ 2017-04-16 14:00 UTC (permalink / raw)
To: davem; +Cc: netdev, xiyou.wangcong, eric.dumazet, jiri
In-Reply-To: <1492350973-6846-1-git-send-email-jhs@emojatatu.com>
I should say this is dependent on the earlier patch I posted.
Made them separate because I think this one in particular
may generate some discussions.
cheers,
jamal
On 17-04-16 09:56 AM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> This adds support for filtering based on time since last used.
> When we are dumping a large number of actions it is useful to
> have the option of filtering based on when the action was last
> used to reduce the amount of data crossing to user space.
>
> With this patch the user space app sets the FILTER_ACCESS_TIME flag
> (in the pad1 flags area) and the "time of interest since now" in seconds
> when the action was last used (in the pad2 area). The kernel converts
> this to jiffies and does the filtering comparison matching entries that
> have seen activity since then and returns them to user space.
> Old kernels and old tc continue to work in legacy mode.
>
> Some example (we have 400 actions bound to 400 filters); at installation
> time using hacked tc which sets the time of interest to 120 seconds:
>
> prompt$ hackedtc actions ls action gact | grep index | wc -l
> 400
>
> go get some coffee and wait for > 120 seconds and try again:
>
> prompt$ hackedtc actions ls action gact | grep index | wc -l
> 0
>
> Lets see a filter bound to one of these actions:
> ..
> filter pref 10 u32
> filter pref 10 u32 fh 800: ht divisor 1
> filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 2 success 1)
> match 7f000002/ffffffff at 12 (success 1 )
> action order 1: gact action pass
> random type none pass val 0
> index 23 ref 2 bind 1 installed 1145 sec used 802 sec
> Action statistics:
> Sent 84 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> ....
>
> Now lets ping -c 1 127.0.0.2, then run the actions again:
>
> prompt$ hackedtc actions ls action gact | grep index | wc -l
> 1
>
> More details please:
>
> prompt$ hackedtc -s actions ls action gact
> total acts 1 flags 0x3
>
> action order 0: gact action pass
> random type none pass val 0
> index 23 ref 2 bind 1 installed 1270 sec used 30 sec
> Action statistics:
> Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> And the filter?
>
> filter pref 10 u32
> filter pref 10 u32 fh 800: ht divisor 1
> filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 4 success 2)
> match 7f000002/ffffffff at 12 (success 2 )
> action order 1: gact action pass
> random type none pass val 0
> index 23 ref 2 bind 1 installed 1324 sec used 84 sec
> Action statistics:
> Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> ---
> net/sched/act_api.c | 24 ++++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index 90cc774..4dd55f2 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -84,11 +84,13 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
> {
> int err = 0, index = -1, i = 0, s_i = 0, n_i = 0;
> unsigned short act_flags = cb->args[2];
> + unsigned long jiffy_filter = cb->args[3];
> +
> struct nlattr *nest;
>
> spin_lock_bh(&hinfo->lock);
>
> - s_i = cb->args[0];
> + s_i = cb->args[4];
>
> for (i = 0; i < (hinfo->hmask + 1); i++) {
> struct hlist_head *head;
> @@ -101,6 +103,12 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
> if (index < s_i)
> continue;
>
> + if (jiffy_filter &&
> + time_after(jiffy_filter,
> + (unsigned long)p->tcfa_tm.lastuse)) {
> + continue;
> + }
> +
> nest = nla_nest_start(skb, n_i);
> if (nest == NULL)
> goto nla_put_failure;
> @@ -118,6 +126,8 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
> }
> }
> done:
> + if (index > 0)
> + cb->args[4] = index + 1;
> spin_unlock_bh(&hinfo->lock);
> if (n_i) {
> cb->args[0] += n_i;
> @@ -1086,8 +1096,10 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
> struct tc_action_ops *a_o;
> int ret = 0;
> struct tcamsg *t = (struct tcamsg *) nlmsg_data(cb->nlh);
> - unsigned char act_flags = t->tca__pad1;
> struct nlattr *kind = find_dump_kind(cb->nlh);
> + unsigned char act_flags = t->tca__pad1;
> + unsigned short secs = t->tca__pad2;
> + unsigned long jiffy_wanted = 0;
>
> if (kind == NULL) {
> pr_info("tc_dump_action: action bad kind\n");
> @@ -1103,7 +1115,15 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
> if (!nlh)
> goto out_module_put;
>
> + if (act_flags & ACT_FILTER_TIME_ACCESS) {
> + const unsigned int m = secs * 1000L;
> + unsigned long jiffy_msecs = msecs_to_jiffies(m);
> +
> + jiffy_wanted = jiffies - jiffy_msecs;
> + }
> +
> cb->args[2] = act_flags;
> + cb->args[3] = jiffy_wanted;
>
> t = nlmsg_data(nlh);
> t->tca_family = AF_UNSPEC;
>
^ permalink raw reply
* [PATCH net-next 1/1] net sched actions: add time filter for action dumping
From: Jamal Hadi Salim @ 2017-04-16 13:56 UTC (permalink / raw)
To: davem; +Cc: netdev, xiyou.wangcong, eric.dumazet, jiri, Jamal Hadi Salim
From: Jamal Hadi Salim <jhs@mojatatu.com>
This adds support for filtering based on time since last used.
When we are dumping a large number of actions it is useful to
have the option of filtering based on when the action was last
used to reduce the amount of data crossing to user space.
With this patch the user space app sets the FILTER_ACCESS_TIME flag
(in the pad1 flags area) and the "time of interest since now" in seconds
when the action was last used (in the pad2 area). The kernel converts
this to jiffies and does the filtering comparison matching entries that
have seen activity since then and returns them to user space.
Old kernels and old tc continue to work in legacy mode.
Some example (we have 400 actions bound to 400 filters); at installation
time using hacked tc which sets the time of interest to 120 seconds:
prompt$ hackedtc actions ls action gact | grep index | wc -l
400
go get some coffee and wait for > 120 seconds and try again:
prompt$ hackedtc actions ls action gact | grep index | wc -l
0
Lets see a filter bound to one of these actions:
..
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 2 success 1)
match 7f000002/ffffffff at 12 (success 1 )
action order 1: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1145 sec used 802 sec
Action statistics:
Sent 84 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
....
Now lets ping -c 1 127.0.0.2, then run the actions again:
prompt$ hackedtc actions ls action gact | grep index | wc -l
1
More details please:
prompt$ hackedtc -s actions ls action gact
total acts 1 flags 0x3
action order 0: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1270 sec used 30 sec
Action statistics:
Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
And the filter?
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 4 success 2)
match 7f000002/ffffffff at 12 (success 2 )
action order 1: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1324 sec used 84 sec
Action statistics:
Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
net/sched/act_api.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 90cc774..4dd55f2 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -84,11 +84,13 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
{
int err = 0, index = -1, i = 0, s_i = 0, n_i = 0;
unsigned short act_flags = cb->args[2];
+ unsigned long jiffy_filter = cb->args[3];
+
struct nlattr *nest;
spin_lock_bh(&hinfo->lock);
- s_i = cb->args[0];
+ s_i = cb->args[4];
for (i = 0; i < (hinfo->hmask + 1); i++) {
struct hlist_head *head;
@@ -101,6 +103,12 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
if (index < s_i)
continue;
+ if (jiffy_filter &&
+ time_after(jiffy_filter,
+ (unsigned long)p->tcfa_tm.lastuse)) {
+ continue;
+ }
+
nest = nla_nest_start(skb, n_i);
if (nest == NULL)
goto nla_put_failure;
@@ -118,6 +126,8 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
}
}
done:
+ if (index > 0)
+ cb->args[4] = index + 1;
spin_unlock_bh(&hinfo->lock);
if (n_i) {
cb->args[0] += n_i;
@@ -1086,8 +1096,10 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
struct tc_action_ops *a_o;
int ret = 0;
struct tcamsg *t = (struct tcamsg *) nlmsg_data(cb->nlh);
- unsigned char act_flags = t->tca__pad1;
struct nlattr *kind = find_dump_kind(cb->nlh);
+ unsigned char act_flags = t->tca__pad1;
+ unsigned short secs = t->tca__pad2;
+ unsigned long jiffy_wanted = 0;
if (kind == NULL) {
pr_info("tc_dump_action: action bad kind\n");
@@ -1103,7 +1115,15 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
if (!nlh)
goto out_module_put;
+ if (act_flags & ACT_FILTER_TIME_ACCESS) {
+ const unsigned int m = secs * 1000L;
+ unsigned long jiffy_msecs = msecs_to_jiffies(m);
+
+ jiffy_wanted = jiffies - jiffy_msecs;
+ }
+
cb->args[2] = act_flags;
+ cb->args[3] = jiffy_wanted;
t = nlmsg_data(nlh);
t->tca_family = AF_UNSPEC;
--
1.9.1
^ permalink raw reply related
* Re: [RFC patch 1/1] large netlink dumps
From: Jamal Hadi Salim @ 2017-04-16 13:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Johannes Berg, Pablo Neira Ayuso, David Miller,
netdev@vger.kernel.org
In-Reply-To: <1492312137.10587.87.camel@edumazet-glaptop3.roam.corp.google.com>
On 17-04-15 11:08 PM, Eric Dumazet wrote:
> On Sat, 2017-04-15 at 13:07 -0400, Jamal Hadi Salim wrote:
>> Eric,
>>
>> How does attached look instead of the 32K?
>> I found it helps to let user space suggest something
>> larger.
>>
>> cheers,
>> jamal
>
> Looks dangerous to me, for various reasons.
>
> 1) Memory allocations might not like it
>
> Have you tried your change after user does a
> setsockopt( SO_RCVBUFFORCE, 256 Mbytes), and a
> recvmsg ( .. 64 Mbytes) ?
>
> Presumably, we could replace 32768 by (PAGE_SIZE <<
> PAGE_ALLOC_COSTLY_ORDER), but this will not matter on x86.
>
For my use case I dont need to go that high, but i can see
plausibility that someone else will. Is there a reasonable
large number other than 32K? 128K-512K would be way sufficient.
> 2) We might have paths in the kernel filling a potential big skb without
> yielding cpu or a spinlock or a mutex. -> latency source.
>
>
> What perf numbers do you have, using 1MB buffers instead of 32KB ?
>
> The syscall overhead seems tiny compared to the actual cost of filling
> the netlink message, accessing thousands of cache lines all over the
> places.
>
sycall is affecting me - but I have only compared with limited
traffic running at the same time as dumping. The more i can batch
the sooner i can stop polluting the cache.
The tests I have done are with a default socket buffer of 4M
and say recvmsg(... 128K). I dont need to go higher
that 256-512K to achieve my goals.
With default of 32K I can fit about 250-60 actions in one batch.
With 128K I can fit 4x that.
It takes about 1.5 minutes for one process to dump 1M actions
on my laptop (Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz) with
32K; 25% of that time with 128K. tc is single threaded, so i can
keep one cpu busy 100% while I dump which means latency fear
is lowered.
My eventual need: To dump all relevant stats every 5 seconds.
I will send the other patch I talked about which filters based
on time which helps in most cases but not always.
I am also now thinking of adding "a range index filter" and then
multi-threading several parrallel requests, one for each range of
indices.
cheers,
jamal
^ permalink raw reply
* [PATCH net-next 1/1] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-04-16 12:34 UTC (permalink / raw)
To: davem; +Cc: netdev, eric.dumazet, xiyou.wangcong, jiri, Jamal Hadi Salim
From: Jamal Hadi Salim <jhs@mojatatu.com>
When you dump hundreds of thousands of actions, getting only 32 per
dump batch even when the socket buffer and memory allocations allow
is inefficient.
With this change, the user will get as many as possibly fitting
within the given constraints.
We reuse the pad fields in tcamsg. pad1 is used as a flag space.
User explicitly requests for the large dump in order to maintain
backwards compatibility with user space by setting bit
ACT_LARGE_DUMP_ON; older user space which doesnt set this flag
doesnt get the large (than 32) batches - so continues to work
as before. Older kernels ignore this flag, so legacy behavior
is maintained.
The kernel uses pad2 to tell the user how many actions are put in
a single batch. As such user space app(like tc) knows how long
to iterate instead of hardcoded maximum of 32.
Some results dumping 1.5M actions, first unpatched tc which the
kernel doesnt help:
prompt$ time -p tc actions ls action gact | grep index | wc -l
1500000
real 1388.43
user 2.07
sys 1386.79
Now patched tc which sets the correct flags when requesting a dump:
prompt$ time -p updatedtc actions ls action gact | grep index | wc -l
1500000
real 178.13
user 2.02
sys 176.96
Improvement: Dump time from about 20 minutes to about 2 minutes.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
include/uapi/linux/rtnetlink.h | 7 +++++++
net/sched/act_api.c | 17 ++++++++++++++---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index cce0613..3434d98 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -678,6 +678,13 @@ struct tcamsg {
#define TA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct tcamsg))
#define TCA_ACT_TAB 1 /* attr type must be >=1 */
#define TCAA_MAX 1
+/* tcamsg flags stored in tca__pad
+ *
+ * ACT_LARGE_DUMP_ON user->kernel to request for larger than TCA_ACT_MAX_PRIO
+ * actions in a dump. All dump responses will contain the number of actions
+ * being dumped stored in tca__pad2 for user app's info
+ */
+#define ACT_LARGE_DUMP_ON (1 << 0)
/* New extended info filters for IFLA_EXT_MASK */
#define RTEXT_FILTER_VF (1 << 0)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 79d875c..90cc774 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -83,6 +83,7 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
struct netlink_callback *cb)
{
int err = 0, index = -1, i = 0, s_i = 0, n_i = 0;
+ unsigned short act_flags = cb->args[2];
struct nlattr *nest;
spin_lock_bh(&hinfo->lock);
@@ -111,14 +112,18 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
}
nla_nest_end(skb, nest);
n_i++;
- if (n_i >= TCA_ACT_MAX_PRIO)
+ if (!(act_flags & ACT_LARGE_DUMP_ON) &&
+ n_i >= TCA_ACT_MAX_PRIO)
goto done;
}
}
done:
spin_unlock_bh(&hinfo->lock);
- if (n_i)
+ if (n_i) {
cb->args[0] += n_i;
+ if (act_flags & ACT_LARGE_DUMP_ON)
+ cb->args[1] = n_i;
+ }
return n_i;
nla_put_failure:
@@ -1081,6 +1086,7 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
struct tc_action_ops *a_o;
int ret = 0;
struct tcamsg *t = (struct tcamsg *) nlmsg_data(cb->nlh);
+ unsigned char act_flags = t->tca__pad1;
struct nlattr *kind = find_dump_kind(cb->nlh);
if (kind == NULL) {
@@ -1096,9 +1102,12 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
cb->nlh->nlmsg_type, sizeof(*t), 0);
if (!nlh)
goto out_module_put;
+
+ cb->args[2] = act_flags;
+
t = nlmsg_data(nlh);
t->tca_family = AF_UNSPEC;
- t->tca__pad1 = 0;
+ t->tca__pad1 = act_flags;
t->tca__pad2 = 0;
nest = nla_nest_start(skb, TCA_ACT_TAB);
@@ -1112,6 +1121,8 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
if (ret > 0) {
nla_nest_end(skb, nest);
ret = skb->len;
+ t->tca__pad2 = cb->args[1];
+ cb->args[1] = 0;
} else
nlmsg_trim(skb, b);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH RFC ipsec-next 0/14] IPsec hardware offloding API
From: Steffen Klassert @ 2017-04-16 11:49 UTC (permalink / raw)
To: netdev; +Cc: Ilan Tayari
In-Reply-To: <1491978413-5700-1-git-send-email-steffen.klassert@secunet.com>
On Wed, Apr 12, 2017 at 08:26:39AM +0200, Steffen Klassert wrote:
> This patchset adds the basic infrastructure for IPsec hardware
> offloading, it creates a configuration API and adjusts the
> packet path.
This is now applied to ipsec-next.
^ permalink raw reply
* [PATCH 3.18 043/145] [PATCH 093/760] net: sctp, forbid negative length
From: Greg Kroah-Hartman @ 2017-04-16 10:48 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, Vlad Yasevich,
Neil Horman, David S. Miller, linux-sctp, netdev
In-Reply-To: <20170416080200.205458595@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit a4b8e71b05c27bae6bad3bdecddbc6b68a3ad8cf ]
Most of getsockopt handlers in net/sctp/socket.c check len against
sizeof some structure like:
if (len < sizeof(int))
return -EINVAL;
On the first look, the check seems to be correct. But since len is int
and sizeof returns size_t, int gets promoted to unsigned size_t too. So
the test returns false for negative lengths. Yes, (-1 < sizeof(long)) is
false.
Fix this in sctp by explicitly checking len < 0 before any getsockopt
handler is called.
Note that sctp_getsockopt_events already handled the negative case.
Since we added the < 0 check elsewhere, this one can be removed.
If not checked, this is the result:
UBSAN: Undefined behaviour in ../mm/page_alloc.c:2722:19
shift exponent 52 is too large for 32-bit type 'int'
CPU: 1 PID: 24535 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
0000000000000000 ffff88006d99f2a8 ffffffffb2f7bdea 0000000041b58ab3
ffffffffb4363c14 ffffffffb2f7bcde ffff88006d99f2d0 ffff88006d99f270
0000000000000000 0000000000000000 0000000000000034 ffffffffb5096422
Call Trace:
[<ffffffffb3051498>] ? __ubsan_handle_shift_out_of_bounds+0x29c/0x300
...
[<ffffffffb273f0e4>] ? kmalloc_order+0x24/0x90
[<ffffffffb27416a4>] ? kmalloc_order_trace+0x24/0x220
[<ffffffffb2819a30>] ? __kmalloc+0x330/0x540
[<ffffffffc18c25f4>] ? sctp_getsockopt_local_addrs+0x174/0xca0 [sctp]
[<ffffffffc18d2bcd>] ? sctp_getsockopt+0x10d/0x1b0 [sctp]
[<ffffffffb37c1219>] ? sock_common_getsockopt+0xb9/0x150
[<ffffffffb37be2f5>] ? SyS_getsockopt+0x1a5/0x270
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-sctp@vger.kernel.org
Cc: netdev@vger.kernel.org
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/socket.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4385,7 +4385,7 @@ static int sctp_getsockopt_disable_fragm
static int sctp_getsockopt_events(struct sock *sk, int len, char __user *optval,
int __user *optlen)
{
- if (len <= 0)
+ if (len == 0)
return -EINVAL;
if (len > sizeof(struct sctp_event_subscribe))
len = sizeof(struct sctp_event_subscribe);
@@ -5981,6 +5981,9 @@ static int sctp_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
+ if (len < 0)
+ return -EINVAL;
+
lock_sock(sk);
switch (optname) {
^ permalink raw reply
* [PATCH net-next 1/1] ipv6: sr: fix BUG due to headroom too small after SRH push
From: David Lebrun @ 2017-04-16 10:27 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
When a locally generated packet receives an SRH with two or more segments,
the remaining headroom is too small to push an ethernet header. This patch
ensures that the headroom is large enough after SRH push.
The BUG generated the following trace.
[ 192.950285] skbuff: skb_under_panic: text:ffffffff81809675 len:198 put:14 head:ffff88006f306400 data:ffff88006f3063fa tail:0xc0 end:0x2c0 dev:A-1
[ 192.952456] ------------[ cut here ]------------
[ 192.953218] kernel BUG at net/core/skbuff.c:105!
[ 192.953411] invalid opcode: 0000 [#1] PREEMPT SMP
[ 192.953411] Modules linked in:
[ 192.953411] CPU: 5 PID: 3433 Comm: ping6 Not tainted 4.11.0-rc3+ #237
[ 192.953411] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
[ 192.953411] task: ffff88007c2d42c0 task.stack: ffffc90000ef4000
[ 192.953411] RIP: 0010:skb_panic+0x61/0x70
[ 192.953411] RSP: 0018:ffffc90000ef7900 EFLAGS: 00010286
[ 192.953411] RAX: 0000000000000085 RBX: 00000000000086dd RCX: 0000000000000201
[ 192.953411] RDX: 0000000080000201 RSI: ffffffff81d104c5 RDI: 00000000ffffffff
[ 192.953411] RBP: ffffc90000ef7920 R08: 0000000000000001 R09: 0000000000000000
[ 192.953411] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 192.953411] R13: ffff88007c5a4000 R14: ffff88007b363d80 R15: 00000000000000b8
[ 192.953411] FS: 00007f94b558b700(0000) GS:ffff88007fd40000(0000) knlGS:0000000000000000
[ 192.953411] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 192.953411] CR2: 00007fff5ecd5080 CR3: 0000000074141000 CR4: 00000000001406e0
[ 192.953411] Call Trace:
[ 192.953411] skb_push+0x3b/0x40
[ 192.953411] eth_header+0x25/0xc0
[ 192.953411] neigh_resolve_output+0x168/0x230
[ 192.953411] ? ip6_finish_output2+0x242/0x8f0
[ 192.953411] ip6_finish_output2+0x242/0x8f0
[ 192.953411] ? ip6_finish_output2+0x76/0x8f0
[ 192.953411] ip6_finish_output+0xa8/0x1d0
[ 192.953411] ip6_output+0x64/0x2d0
[ 192.953411] ? ip6_output+0x73/0x2d0
[ 192.953411] ? ip6_dst_check+0xb5/0xc0
[ 192.953411] ? dst_cache_per_cpu_get.isra.2+0x40/0x80
[ 192.953411] seg6_output+0xb0/0x220
[ 192.953411] lwtunnel_output+0xcf/0x210
[ 192.953411] ? lwtunnel_output+0x59/0x210
[ 192.953411] ip6_local_out+0x38/0x70
[ 192.953411] ip6_send_skb+0x2a/0xb0
[ 192.953411] ip6_push_pending_frames+0x48/0x50
[ 192.953411] rawv6_sendmsg+0xa39/0xf10
[ 192.953411] ? __lock_acquire+0x489/0x890
[ 192.953411] ? __mutex_lock+0x1fc/0x970
[ 192.953411] ? __lock_acquire+0x489/0x890
[ 192.953411] ? __mutex_lock+0x1fc/0x970
[ 192.953411] ? tty_ioctl+0x283/0xec0
[ 192.953411] inet_sendmsg+0x45/0x1d0
[ 192.953411] ? _copy_from_user+0x54/0x80
[ 192.953411] sock_sendmsg+0x33/0x40
[ 192.953411] SYSC_sendto+0xef/0x170
[ 192.953411] ? entry_SYSCALL_64_fastpath+0x5/0xc2
[ 192.953411] ? trace_hardirqs_on_caller+0x12b/0x1b0
[ 192.953411] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 192.953411] SyS_sendto+0x9/0x10
[ 192.953411] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 192.953411] RIP: 0033:0x7f94b453db33
[ 192.953411] RSP: 002b:00007fff5ecd0578 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 192.953411] RAX: ffffffffffffffda RBX: 00007fff5ecd16e0 RCX: 00007f94b453db33
[ 192.953411] RDX: 0000000000000040 RSI: 000055a78352e9c0 RDI: 0000000000000003
[ 192.953411] RBP: 00007fff5ecd1690 R08: 000055a78352c940 R09: 000000000000001c
[ 192.953411] R10: 0000000000000000 R11: 0000000000000246 R12: 000055a783321e10
[ 192.953411] R13: 000055a7839890c0 R14: 0000000000000004 R15: 0000000000000000
[ 192.953411] Code: 00 00 48 89 44 24 10 8b 87 c4 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 90 58 d2 81 48 89 04 24 31 c0 e8 4f 70 9a ff <0f> 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 97 d8 00 00
[ 192.953411] RIP: skb_panic+0x61/0x70 RSP: ffffc90000ef7900
[ 193.000186] ---[ end trace bd0b89fabdf2f92c ]---
[ 193.000951] Kernel panic - not syncing: Fatal exception in interrupt
[ 193.001137] Kernel Offset: disabled
[ 193.001169] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 19d5a26f5ef8de5dcb78799feaf404d717b1aac3 ("ipv6: sr: expand skb head only if necessary")
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6_iptunnel.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 7436a4a..6a49549 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -265,6 +265,10 @@ static int seg6_input(struct sk_buff *skb)
skb_dst_set(skb, dst);
}
+ err = skb_cow_head(skb, LL_RESERVED_SPACE(dst->dev));
+ if (unlikely(err))
+ return err;
+
return dst_input(skb);
}
@@ -310,6 +314,10 @@ static int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
skb_dst_drop(skb);
skb_dst_set(skb, dst);
+ err = skb_cow_head(skb, LL_RESERVED_SPACE(dst->dev));
+ if (unlikely(err))
+ goto drop;
+
return dst_output(net, sk, skb);
drop:
kfree_skb(skb);
--
2.10.2
^ permalink raw reply related
* Re: 4.10.9 nok with realtek wlan, atom
From: rupert THURNER @ 2017-04-16 10:23 UTC (permalink / raw)
To: Larry Finger
Cc: Bjorn Helgaas, linux-pci, Chaoming Li, Kalle Valo, linux-wireless,
netdev, linux-kernel
In-Reply-To: <9e48930c-4822-5af4-2ebb-4d2dcd12d448@lwfinger.net>
On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger
<Larry.Finger@lwfinger.net> wrote:
> On 04/14/2017 03:26 PM, rupert THURNER wrote:
>>
>> On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <Larry.Finger@lwfinger.net>
>> wrote:
>>>
>>> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:
>>>>
>>>>
>>>> [+cc rtl8192ce folks in case they've seen this]
>>>>
>>>> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
>>>>>
>>>>>
>>>>> hi,
>>>>>
>>>>> not technical expert enough, i just wanted to give a short user
>>>>> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
>>>>> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
>>>>> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
>>>>> hotspot is possible then drops, or connecting to wlan fails
>>>>> alltogether.
>>>>
>>>>
>>>>
>>>> Thanks very much for your report, and sorry for the inconvenience.
>>>>
>>>> v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.
>>>>
>>>> But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
>>>> need to figure out why and make sure we fix the v4.9 stable series.
>>>>
>>>> I can't tell yet whether this is PCI-related or not. If it is,
>>>> 4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
>>>> appeared in v4.9.6, and there is a known issue with that. The issue
>>>> should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
>>>> as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
>>>> the first thing to do would be to test v4.9.9.
>>>>
>>>> If it's not fixed in v4.9.9, can you share the complete dmesg log
>>>> (output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
>>>> known working version) and v4.9.6 (first known broken version)? On
>>>> v4.9.6, collect the dmesg output after the failure occurs.
>>>>
>>>>> 24: PCI 300.0: 0282 WLAN controller
>>>>> [Created at pci.366]
>>>>> Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
>>>>> Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
>>>>> Revision: 0x01
>>>>> Driver: "rtl8192ce"
>>>>> Driver Modules: "rtl8192ce"
>>>>> Device File: wlp3s0
>>>>> Features: WLAN
>>>
>>>
>>>
>>> It would be helpful if someone were to bisect this issue. The only issue
>>> that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
>>> Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
>>> backported to 4.9.
>>>
>>> The above issue is one that could not be reproduced on my hardware, thus
>>> it
>>> took Jurij Smakov to find the fix. Without his bisection of the problem,
>>> who
>>> knows how long it would have taken to find my edit mistake.
>>
>>
>> larry, using the newest kernel 4.10.8 the network connection dropps
>> again irregular.
>>
>> # dmesg
>> [ 0.000000] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
>> version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
>> 2017
>> [ 11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
>> [ 11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
>> [ 11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
>> [ 11.978945] rtlwifi: rtlwifi: wireless switch is on
>>
>> # lspci -vv
>> Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi
>> Adapter
>> Kernel driver in use: rtl8192ce
>
>
> Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?
4.10.x used to work. 4.10.6 or 4.10.7 it started failing? i am not too
sure about it.
# ls -l /usr/lib/firmware/rtlwifi/rtl8192cfw.bin
-rw-r--r-- 1 root root 16192 Mar 10 12:15
/usr/lib/firmware/rtlwifi/rtl8192cfw.bin
rupert
^ permalink raw reply
* [PATCH] gso: Validate assumption of frag_list segementation
From: ilant @ 2017-04-16 8:00 UTC (permalink / raw)
To: netdev
Cc: Alexander Duyck, Eric Dumazet, Steffen Klassert, Boris Pismenny,
Ilya Lesokhin, Ilan Tayari
From: Ilan Tayari <ilant@mellanox.com>
Commit 07b26c9454a2 ("gso: Support partial splitting at the frag_list
pointer") assumes that all SKBs in a frag_list (except maybe the last
one) contain the same amount of GSO payload.
This assumption is not always correct, resulting in the following
warning message in the log:
skb_segment: too many frags
For example, mlx5 driver in Striding RQ mode creates some RX SKBs with
one frag, and some with 2 frags.
After GRO, the frag_list SKBs end up having different amounts of payload.
If this frag_list SKB is then forwarded, the aforementioned assumption
is violated.
Validate the assumption, and fall back to software GSO if it not true.
Fixes: 07b26c9454a2 ("gso: Support partial splitting at the frag_list pointer")
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
---
net/core/skbuff.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 5d9a11eafbf5..ad2af563756a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3082,22 +3082,32 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
if (sg && csum && (mss != GSO_BY_FRAGS)) {
if (!(features & NETIF_F_GSO_PARTIAL)) {
struct sk_buff *iter;
+ unsigned int frag_len;
if (!list_skb ||
!net_gso_ok(features, skb_shinfo(head_skb)->gso_type))
goto normal;
- /* Split the buffer at the frag_list pointer.
- * This is based on the assumption that all
- * buffers in the chain excluding the last
- * containing the same amount of data.
+ /* If we get here then all the required
+ * GSO features except frag_list are supported.
+ * Try to split the SKB to multiple GSO SKBs
+ * with no frag_list.
+ * Currently we can do that only when the buffers don't
+ * have a linear part and all the buffers except
+ * the last are of the same length.
*/
+ frag_len = list_skb->len;
skb_walk_frags(head_skb, iter) {
+ if (frag_len != iter->len && iter->next)
+ goto normal;
if (skb_headlen(iter) && !iter->head_frag)
goto normal;
len -= iter->len;
}
+
+ if (len != frag_len)
+ goto normal;
}
/* GSO partial only requires that we trim off any excess that
--
2.11.0
^ permalink raw reply related
* Re: [RFC patch 1/1] large netlink dumps
From: Eric Dumazet @ 2017-04-16 3:08 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Johannes Berg, Pablo Neira Ayuso, David Miller,
netdev@vger.kernel.org
In-Reply-To: <e17f52a6-b2ad-6b39-a655-2e8779a5d192@mojatatu.com>
On Sat, 2017-04-15 at 13:07 -0400, Jamal Hadi Salim wrote:
> Eric,
>
> How does attached look instead of the 32K?
> I found it helps to let user space suggest something
> larger.
>
> cheers,
> jamal
Looks dangerous to me, for various reasons.
1) Memory allocations might not like it
Have you tried your change after user does a
setsockopt( SO_RCVBUFFORCE, 256 Mbytes), and a
recvmsg ( .. 64 Mbytes) ?
Presumably, we could replace 32768 by (PAGE_SIZE <<
PAGE_ALLOC_COSTLY_ORDER), but this will not matter on x86.
2) We might have paths in the kernel filling a potential big skb without
yielding cpu or a spinlock or a mutex. -> latency source.
What perf numbers do you have, using 1MB buffers instead of 32KB ?
The syscall overhead seems tiny compared to the actual cost of filling
the netlink message, accessing thousands of cache lines all over the
places.
^ permalink raw reply
* Re: TPACKET_V3 timeout bug?
From: Guy Harris @ 2017-04-16 2:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Sowmini Varadhan, netdev, tcpdump-workers
In-Reply-To: <20170416021050.GA16418@lunn.ch>
On Apr 15, 2017, at 7:10 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> Do you think this is a kernel problem, libpcap problem, or an
> application problem?
An application problem. See my response on netdev; the timeout (which is provided by the kernel's capture mechanism, in most cases) is to make sure packets don't stay stuck in the kernel's packet buffer for an indefinite period of time, it's *not* to make sure a thread capturing packets doesn't stay blocked for an indefinite period of time. Whether the timer goes off even if no packets have arrived is platform-dependent; code capturing packets should neither depend on it doing so or on it not doing so.
^ permalink raw reply
* Re: TPACKET_V3 timeout bug?
From: Guy Harris @ 2017-04-16 2:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Sowmini Varadhan, netdev
In-Reply-To: <20170415234437.GA21836@lunn.ch>
On Apr 15, 2017, at 4:44 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> Yet i'm debugging an application which expects a timeout even when
> there are 0 packets.
Well, you've already found a bug - it expects a timeout where there are no packets.
To quote the pcap man page (this is the latest version, which calls it the "packet buffer timeout" rather than the "read timeout"):
packet buffer timeout
If, when capturing, packets are delivered as soon as they
arrive, the application capturing the packets will be woken up
for each packet as it arrives, and might have to make one or
more calls to the operating system to fetch each packet.
If, instead, packets are not delivered as soon as they arrive,
but are delivered after a short delay (called a "packet buffer
timeout"), more than one packet can be accumulated before the
packets are delivered, so that a single wakeup would be done for
multiple packets, and each set of calls made to the operating
system would supply multiple packets, rather than a single
packet. This reduces the per-packet CPU overhead if packets are
arriving at a high rate, increasing the number of packets per
second that can be captured.
The packet buffer timeout is required so that an application
won't wait for the operating system's capture buffer to fill up
before packets are delivered; if packets are arriving slowly,
that wait could take an arbitrarily long period of time.
Not all platforms support a packet buffer timeout; on platforms
that don't, the packet buffer timeout is ignored. A zero value
for the timeout, on platforms that support a packet buffer time-
out, will cause a read to wait forever to allow enough packets
to arrive, with no timeout.
NOTE: the packet buffer timeout cannot be used to cause calls
that read packets to return within a limited period of time,
because, on some platforms, the packet buffer timeout isn't sup-
ported, and, on other platforms, the timer doesn't start until
at least one packet arrives. This means that the packet buffer
timeout should NOT be used, for example, in an interactive
application to allow the packet capture loop to ``poll'' for
user input periodically, as there's no guarantee that a call
reading packets will return after the timeout expires even if no
packets have arrived.
The packet buffer timeout is set with pcap_set_timeout().
Note especially the next-to-last paragraph - which was put in there long before TPACKET_V3, to cover, for example, Solaris.
The purpose of the timeout is to make sure packets don't stay stuck in the kernel buffer for an indefinite period of time (if they're not arriving at a sufficient rate to fill up the buffer in a reasonably-short period of time); it's *not* to make sure the application doesn't remain blocked for an indefinite period of time.
^ permalink raw reply
* Re: ipv6 udp early demux breaks udp_l3mdev_accept=0
From: Subash Abhinov Kasiviswanathan @ 2017-04-16 2:23 UTC (permalink / raw)
To: dsa; +Cc: David Miller, netdev, rshearma
In-Reply-To: <20170415.094810.1393827754237126920.davem@davemloft.net>
>> It should be fixed for 4.12. Basically, __udp6_lib_demux_lookup needs
>> to
>> be more like __udp4_lib_demux_lookup
Hi David
Would it be possible for you to test this with udp_l3mdev_accept=0
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index b793ed1..0e307e5 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -46,6 +46,7 @@
#include <net/tcp_states.h>
#include <net/ip6_checksum.h>
#include <net/xfrm.h>
+#include <net/inet_hashtables.h>
#include <net/inet6_hashtables.h>
#include <net/busy_poll.h>
#include <net/sock_reuseport.h>
@@ -864,21 +865,25 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct
udp_table *udptable,
return 0;
}
+
static struct sock *__udp6_lib_demux_lookup(struct net *net,
__be16 loc_port, const struct in6_addr
*loc_addr,
__be16 rmt_port, const struct in6_addr
*rmt_addr,
int dif)
{
+ unsigned short hnum = ntohs(loc_port);
+ unsigned int hash2 = udp6_portaddr_hash(net, loc_addr, hnum);
+ unsigned int slot2 = hash2 & udp_table.mask;
+ struct udp_hslot *hslot2 = &udp_table.hash2[slot2];
+ const __portpair ports = INET_COMBINED_PORTS(rmt_port, hnum);
struct sock *sk;
- rcu_read_lock();
- sk = __udp6_lib_lookup(net, rmt_addr, rmt_port, loc_addr,
loc_port,
- dif, &udp_table, NULL);
- if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
- sk = NULL;
- rcu_read_unlock();
-
- return sk;
+ udp_portaddr_for_each_entry_rcu(sk, &hslot2->head) {
+ if (INET6_MATCH(sk, net, rmt_addr, loc_addr, ports,
dif))
+ return sk;
+ break;
+ }
+ return NULL;
}
static void udp_v6_early_demux(struct sk_buff *skb)
^ permalink raw reply related
* Re: TPACKET_V3 timeout bug?
From: Andrew Lunn @ 2017-04-16 2:10 UTC (permalink / raw)
To: Sowmini Varadhan, guy; +Cc: netdev, tcpdump-workers
In-Reply-To: <20170415224530.GA21010@oracle.com>
On Sat, Apr 15, 2017 at 06:45:36PM -0400, Sowmini Varadhan wrote:
> On (04/15/17 21:40), Andrew Lunn wrote:
> >
> > In my case, lan3 is up and idle, there are no packets flying around to
> > be captured. So i would expect pcap_next_ex() to exit once a second,
> > with a return value of 0. But it is not, it blocks and stays blocked.
> :
> > Looking at the libpcap source, the 1000ms timeout is being used as
> > part of the setsockopt(3, SOL_PACKET, PACKET_RX_RING, 0xbe9445c0, 28)
> > call, req.tp_retire_blk_tov is set to the timeoutval.
>
> right, aiui, the retire_blk_tov will only kick in if we have at
> least one frame in a block, but the block is not filled up yet,
> before the req.tp_retire_blk_tov (1s in your case) expires.
>
> If there are 0 frames pending, we should not be waking up the app,
> so everything seems to be behaving as it should?
Hi Guy
You wrote the TPACKET3 set_poll_timeout() handling. Please could you
have a look at the thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg163532.html
Do you think this is a kernel problem, libpcap problem, or an
application problem?
Thanks
Andrew
^ permalink raw reply
* [PATCH -next] rhashtable: remove insecure_elasticity
From: Florian Westphal @ 2017-04-16 0:55 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
commit 83e7e4ce9e93c3 ("mac80211: Use rhltable instead of rhashtable")
removed the last user that made use of 'insecure_elasticity' parameter,
i.e. the default of 16 is used everywhere.
Replace it with a constant.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/linux/rhashtable.h | 21 ++++++++++++++++-----
lib/rhashtable.c | 17 +----------------
2 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index e507290cd2c7..ae87dcdf52d2 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -49,6 +49,21 @@
/* Base bits plus 1 bit for nulls marker */
#define RHT_HASH_RESERVED_SPACE (RHT_BASE_BITS + 1)
+/* Maximum chain length before rehash
+ *
+ * The maximum (not average) chain length grows with the size of the hash
+ * table, at a rate of (log N)/(log log N).
+ *
+ * The value of 16 is selected so that even if the hash table grew to
+ * 2^32 you would not expect the maximum chain length to exceed it
+ * unless we are under attack (or extremely unlucky).
+ *
+ * As this limit is only to detect attacks, we don't need to set it to a
+ * lower value as you'd need the chain length to vastly exceed 16 to have
+ * any real effect on the system.
+ */
+#define RHT_ELASTICITY 16u
+
struct rhash_head {
struct rhash_head __rcu *next;
};
@@ -114,7 +129,6 @@ struct rhashtable;
* @max_size: Maximum size while expanding
* @min_size: Minimum size while shrinking
* @nulls_base: Base value to generate nulls marker
- * @insecure_elasticity: Set to true to disable chain length checks
* @automatic_shrinking: Enable automatic shrinking of tables
* @locks_mul: Number of bucket locks to allocate per cpu (default: 128)
* @hashfn: Hash function (default: jhash2 if !(key_len % 4), or jhash)
@@ -130,7 +144,6 @@ struct rhashtable_params {
unsigned int max_size;
unsigned int min_size;
u32 nulls_base;
- bool insecure_elasticity;
bool automatic_shrinking;
size_t locks_mul;
rht_hashfn_t hashfn;
@@ -143,7 +156,6 @@ struct rhashtable_params {
* @tbl: Bucket table
* @nelems: Number of elements in table
* @key_len: Key length for hashfn
- * @elasticity: Maximum chain length before rehash
* @p: Configuration parameters
* @rhlist: True if this is an rhltable
* @run_work: Deferred worker to expand/shrink asynchronously
@@ -154,7 +166,6 @@ struct rhashtable {
struct bucket_table __rcu *tbl;
atomic_t nelems;
unsigned int key_len;
- unsigned int elasticity;
struct rhashtable_params p;
bool rhlist;
struct work_struct run_work;
@@ -726,7 +737,7 @@ static inline void *__rhashtable_insert_fast(
return rhashtable_insert_slow(ht, key, obj);
}
- elasticity = ht->elasticity;
+ elasticity = RHT_ELASTICITY;
pprev = rht_bucket_insert(ht, tbl, hash);
data = ERR_PTR(-ENOMEM);
if (!pprev)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index f8635fd57442..d22a5ef109fb 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -535,7 +535,7 @@ static void *rhashtable_lookup_one(struct rhashtable *ht,
struct rhash_head *head;
int elasticity;
- elasticity = ht->elasticity;
+ elasticity = RHT_ELASTICITY;
pprev = rht_bucket_var(tbl, hash);
rht_for_each_continue(head, *pprev, tbl, hash) {
struct rhlist_head *list;
@@ -972,21 +972,6 @@ int rhashtable_init(struct rhashtable *ht,
if (params->nelem_hint)
size = rounded_hashtable_size(&ht->p);
- /* The maximum (not average) chain length grows with the
- * size of the hash table, at a rate of (log N)/(log log N).
- * The value of 16 is selected so that even if the hash
- * table grew to 2^32 you would not expect the maximum
- * chain length to exceed it unless we are under attack
- * (or extremely unlucky).
- *
- * As this limit is only to detect attacks, we don't need
- * to set it to a lower value as you'd need the chain
- * length to vastly exceed 16 to have any real effect
- * on the system.
- */
- if (!params->insecure_elasticity)
- ht->elasticity = 16;
-
if (params->locks_mul)
ht->p.locks_mul = roundup_pow_of_two(params->locks_mul);
else
--
2.10.2
^ permalink raw reply related
* Re: [PATCH RFC (resend) net-next 5/6] virtio-net: Add support for vlan acceleration vnet header extension.
From: Michael S. Tsirkin @ 2017-04-16 0:28 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, virtualization, virtio-dev, jasowang, maxime.coquelin,
Vladislav Yasevich
In-Reply-To: <1492274298-17362-6-git-send-email-vyasevic@redhat.com>
On Sat, Apr 15, 2017 at 12:38:17PM -0400, Vladislav Yasevich wrote:
> This extension allows us to pass vlan ID and vlan protocol data to the
> host hypervisor as part of the vnet header and lets us take advantage
> of HW accelerated vlan tagging in the host. It requires support in the
> host to negotiate the feature. When the extension is enabled, the
> virtio device will enabled HW accelerated vlan features.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Performance data will be required to justify this.
> ---
> drivers/net/virtio_net.c | 17 ++++++++++++++++-
> include/linux/virtio_net.h | 17 +++++++++++++++++
> include/uapi/linux/virtio_net.h | 7 +++++++
> 3 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 18eb0dd..696ef4a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -182,6 +182,7 @@ struct virtio_net_hdr_max {
> struct virtio_net_hdr_mrg_rxbuf hdr;
> struct virtio_net_ext_hdr ext_hdr;
> struct virtio_net_ext_ip6frag ip6f_ext;
> + struct virtio_net_ext_vlan vlan_ext;
> };
>
> static inline u8 padded_vnet_hdr(struct virtnet_info *vi)
> @@ -2276,6 +2277,11 @@ static void virtnet_init_extensions(struct virtio_device *vdev)
> vi->hdr_len += sizeof(u32);
> vi->ext_mask |= VIRTIO_NET_EXT_F_IP6FRAG;
> }
> +
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_VLAN_OFFLOAD)) {
> + vi->hdr_len += sizeof(struct virtio_net_ext_vlan);
> + vi->ext_mask |= VIRTIO_NET_EXT_F_VLAN;
> + }
> }
>
> #define MIN_MTU ETH_MIN_MTU
> @@ -2352,6 +2358,14 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
> dev->features |= NETIF_F_RXCSUM;
>
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_VLAN_OFFLOAD)) {
> + dev->features |= NETIF_F_HW_VLAN_CTAG_TX |
> + NETIF_F_HW_VLAN_CTAG_RX |
> + NETIF_F_HW_VLAN_STAG_TX |
> + NETIF_F_HW_VLAN_STAG_RX;
> + }
> +
> +
> dev->vlan_features = dev->features;
>
> /* MTU range: 68 - 65535 */
> @@ -2395,7 +2409,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
> vi->mergeable_rx_bufs = true;
>
> - if (virtio_has_feature(vdev, VIRTIO_NET_F_IP6_FRAGID))
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_IP6_FRAGID) ||
> + virtio_has_feature(vdev, VIRTIO_NET_F_VLAN_OFFLOAD))
> vi->hdr_ext = true;
>
> if (vi->hdr_ext)
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index 3b259dc..e790191 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -113,6 +113,14 @@ static inline int virtio_net_ext_to_skb(struct sk_buff *skb,
> ptr += sizeof(struct virtio_net_ext_ip6frag);
> }
>
> + if (ext->flags & VIRTIO_NET_EXT_F_VLAN) {
> + struct virtio_net_ext_vlan *vhdr =
> + (struct virtio_net_ext_vlan *)ptr;
> +
> + __vlan_hwaccel_put_tag(skb, vhdr->vlan_proto, vhdr->vlan_tci);
> + ptr += sizeof(struct virtio_net_ext_vlan);
> + }
> +
> return 0;
> }
>
> @@ -130,6 +138,15 @@ static inline int virtio_net_ext_from_skb(const struct sk_buff *skb,
> ext->flags |= VIRTIO_NET_EXT_F_IP6FRAG;
> }
>
> + if (ext_mask & VIRTIO_NET_EXT_F_VLAN && skb_vlan_tag_present(skb)) {
> + struct virtio_net_ext_vlan *vhdr =
> + (struct virtio_net_ext_vlan *)ptr;
> +
> + vlan_get_tag(skb, &vhdr->vlan_tci);
> + vhdr->vlan_proto = skb->vlan_proto;
> + ext->flags |= VIRTIO_NET_EXT_F_VLAN;
> + }
> +
> return 0;
> }
> #endif /* _LINUX_VIRTIO_NET_H */
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index eac8d94..6125de7 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -57,6 +57,7 @@
> * Steering */
> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> #define VIRTIO_NET_F_IP6_FRAGID 24 /* Host supports VLAN accleration */
> +#define VIRTIO_NET_F_VLAN_OFFLOAD 25 /* Host supports VLAN accleration */
>
> #ifndef VIRTIO_NET_NO_LEGACY
> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> @@ -111,6 +112,7 @@ struct virtio_net_hdr_v1 {
> */
> struct virtio_net_ext_hdr {
> #define VIRTIO_NET_EXT_F_IP6FRAG (1<<0)
> +#define VIRTIO_NET_EXT_F_VLAN (1<<1)
> __u32 flags;
> __u8 extensions[];
> };
> @@ -120,6 +122,11 @@ struct virtio_net_ext_ip6frag {
> __be32 frag_id;
> };
>
> +struct virtio_net_ext_vlan {
> + __be16 vlan_tci;
> + __be16 vlan_proto;
> +};
> +
> #ifndef VIRTIO_NET_NO_LEGACY
> /* This header comes first in the scatter-gather list.
> * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it must
> --
> 2.7.4
^ permalink raw reply
* Re: TPACKET_V3 timeout bug?
From: Andrew Lunn @ 2017-04-15 23:44 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: netdev
In-Reply-To: <20170415224530.GA21010@oracle.com>
On Sat, Apr 15, 2017 at 06:45:36PM -0400, Sowmini Varadhan wrote:
> On (04/15/17 21:40), Andrew Lunn wrote:
> >
> > In my case, lan3 is up and idle, there are no packets flying around to
> > be captured. So i would expect pcap_next_ex() to exit once a second,
> > with a return value of 0. But it is not, it blocks and stays blocked.
> :
> > Looking at the libpcap source, the 1000ms timeout is being used as
> > part of the setsockopt(3, SOL_PACKET, PACKET_RX_RING, 0xbe9445c0, 28)
> > call, req.tp_retire_blk_tov is set to the timeoutval.
>
> right, aiui, the retire_blk_tov will only kick in if we have at
> least one frame in a block, but the block is not filled up yet,
> before the req.tp_retire_blk_tov (1s in your case) expires.
>
> If there are 0 frames pending, we should not be waking up the app,
> so everything seems to be behaving as it should?
Hi Sowmini
Humm, i can see the logic of that, it puts an upper bound on the
latency for delivering a frame to user space, but does not wake user
space when there is nothing in the queue.
Yet i'm debugging an application which expects a timeout even when
there are 0 packets. The Ostinator drone. It is a multi thread
process, with a thread performing capture, and another thread doing
control stuff. When the control thread wants to stop the capturing, it
is setting a variable. The next time the capture thread comes out of
pcap_next_en() it checks the variable and close the capture and the
thread exists. But if there is no network traffic, it never
exists. This scheme has worked before, but suddenly stopped when i
upgraded something. What i cannot say is if that is libpcap, or a
kernel, since i upgraded both at the same time.
But it does seem like a regression somewhere.
Looking at libpcap, it does seem to expect a timeout to happen even
when there are 0 packets available. Has there been a kernel change
with respect to this behaviour?
Andrew
^ permalink raw reply
* Re: TPACKET_V3 timeout bug?
From: Sowmini Varadhan @ 2017-04-15 22:45 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20170415194042.GA5936@lunn.ch>
On (04/15/17 21:40), Andrew Lunn wrote:
>
> In my case, lan3 is up and idle, there are no packets flying around to
> be captured. So i would expect pcap_next_ex() to exit once a second,
> with a return value of 0. But it is not, it blocks and stays blocked.
:
> Looking at the libpcap source, the 1000ms timeout is being used as
> part of the setsockopt(3, SOL_PACKET, PACKET_RX_RING, 0xbe9445c0, 28)
> call, req.tp_retire_blk_tov is set to the timeoutval.
right, aiui, the retire_blk_tov will only kick in if we have at
least one frame in a block, but the block is not filled up yet,
before the req.tp_retire_blk_tov (1s in your case) expires.
If there are 0 frames pending, we should not be waking up the app,
so everything seems to be behaving as it should?
--Sowmini
^ permalink raw reply
* Re: 4.10.9 nok with realtek wlan, atom
From: Larry Finger @ 2017-04-15 20:40 UTC (permalink / raw)
To: rupert THURNER
Cc: Bjorn Helgaas, linux-pci, Chaoming Li, Kalle Valo, linux-wireless,
netdev, linux-kernel
In-Reply-To: <CAJs9aZ8HVPn_J9yPjvdBm-A_d3FiquPMGoy1xFsGopF8Xg_89Q@mail.gmail.com>
On 04/14/2017 03:26 PM, rupert THURNER wrote:
> On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:
>>>
>>> [+cc rtl8192ce folks in case they've seen this]
>>>
>>> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
>>>>
>>>> hi,
>>>>
>>>> not technical expert enough, i just wanted to give a short user
>>>> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
>>>> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
>>>> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
>>>> hotspot is possible then drops, or connecting to wlan fails
>>>> alltogether.
>>>
>>>
>>> Thanks very much for your report, and sorry for the inconvenience.
>>>
>>> v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.
>>>
>>> But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
>>> need to figure out why and make sure we fix the v4.9 stable series.
>>>
>>> I can't tell yet whether this is PCI-related or not. If it is,
>>> 4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
>>> appeared in v4.9.6, and there is a known issue with that. The issue
>>> should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
>>> as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
>>> the first thing to do would be to test v4.9.9.
>>>
>>> If it's not fixed in v4.9.9, can you share the complete dmesg log
>>> (output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
>>> known working version) and v4.9.6 (first known broken version)? On
>>> v4.9.6, collect the dmesg output after the failure occurs.
>>>
>>>> 24: PCI 300.0: 0282 WLAN controller
>>>> [Created at pci.366]
>>>> Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
>>>> Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
>>>> Revision: 0x01
>>>> Driver: "rtl8192ce"
>>>> Driver Modules: "rtl8192ce"
>>>> Device File: wlp3s0
>>>> Features: WLAN
>>
>>
>> It would be helpful if someone were to bisect this issue. The only issue
>> that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
>> Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
>> backported to 4.9.
>>
>> The above issue is one that could not be reproduced on my hardware, thus it
>> took Jurij Smakov to find the fix. Without his bisection of the problem, who
>> knows how long it would have taken to find my edit mistake.
>
> larry, using the newest kernel 4.10.8 the network connection dropps
> again irregular.
>
> # dmesg
> [ 0.000000] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
> version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
> 2017
> [ 11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
> [ 11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
> [ 11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [ 11.978945] rtlwifi: rtlwifi: wireless switch is on
>
> # lspci -vv
> Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter
> Kernel driver in use: rtl8192ce
Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?
Larry
^ permalink raw reply
* Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"
From: Mel Gorman @ 2017-04-15 19:57 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Andrew Morton, willy, peterz, pagupta, ttoukan.linux, tariqt,
netdev, saeedm, linux-kernel, linux-mm
In-Reply-To: <20170415212833.30ed3f2b@redhat.com>
On Sat, Apr 15, 2017 at 09:28:33PM +0200, Jesper Dangaard Brouer wrote:
> On Sat, 15 Apr 2017 15:53:50 +0100
> Mel Gorman <mgorman@techsingularity.net> wrote:
>
> > This reverts commit 374ad05ab64d696303cec5cc8ec3a65d457b7b1c. While the
> > patch worked great for userspace allocations, the fact that softirq loses
> > the per-cpu allocator caused problems. It needs to be redone taking into
> > account that a separate list is needed for hard/soft IRQs or alternatively
> > find a cheap way of detecting reentry due to an interrupt. Both are possible
> > but sufficiently tricky that it shouldn't be rushed. Jesper had one method
> > for allowing softirqs but reported that the cost was high enough that it
> > performed similarly to a plain revert. His figures for netperf TCP_STREAM
> > were as follows
> >
> > Baseline v4.10.0 : 60316 Mbit/s
> > Current 4.11.0-rc6: 47491 Mbit/s
> > This patch : 60662 Mbit/s
> (should instead state "Jesper's patch" or "His patch")
>
Yes, you are correct of course.
> Ran same test (8 parallel netperf TCP_STREAMs) with this patch applied:
>
> This patch 60106 Mbit/s (average of 7 iteration 60 sec runs)
>
> With these speeds I'm starting to hit the memory bandwidth of my machines.
> Thus, the 60 GBit/s measurement cannot be used to validate the
> performance impact of reverting this compared to my softirq patch, it
> only shows we fixed the regression. (I'm suspicious as I see a higher
> contention on the page allocator lock (4% vs 1.3%) with this patch and
> still same performance... but lets worry about that outside the rc-series).
>
Well, in itself that limitation highlights that evaluating this is
challenging and needs careful treatment. Otherwise two different
approaches can seem equivalent only because a hardware-related
bottleneck was at play.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
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