Begin forwarded message:
Date: Sat, 15 Sep 2018 08:43:09 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 201137] New: using traffic control with sfq cause kernel crash
https://bugzilla.kernel.org/show_bug.cgi?id=201137
Bug ID: 201137
From: Stephen Hemminger
Convert to use JSON
Signed-off-by: Stephen Hemminger
---
tc/q_sfq.c | 65 --
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 6a1d853b7c93..a813c055b92e 100644
--- a/tc/q_sf
From: Stephen Hemminger
Convert to use JSON
Signed-off-by: Stephen Hemminger
---
tc/q_sfq.c | 65 --
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 6a1d853b7c93..cc8ce0dddf7e 100644
--- a/tc/q_sf
From: gfree.w...@vip.163.com
Date: Sat, 26 Aug 2017 22:58:58 +0800
> From: Gao Feng
>
> The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
> is released) made a big change of tc for performance. But there are
> some points which are not changed in SFQ en
From: Gao Feng
The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
is released) made a big change of tc for performance. But there are
some points which are not changed in SFQ enqueue operation.
1. Fail to find the SFQ hash slot;
2. When the queue is full;
Now use qdisc
On Fri, 2017-08-25 at 15:43 +0800, gfree.w...@vip.163.com wrote:
> From: Gao Feng
>
> The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
> is released) made a big change of tc for performance. But there are
> some points which are not changed in SFQ en
From: Gao Feng
The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
is released) made a big change of tc for performance. But there are
some points which are not changed in SFQ enqueue operation.
1. Fail to find the SFQ hash slot;
2. When the queue is full;
Now use qdisc
From: Konstantin Khlebnikov
Date: Tue, 15 Aug 2017 16:37:04 +0300
> When sfq_enqueue() drops head packet or packet from another queue it
> have to update backlog at upper qdiscs too.
>
> Signed-off-by: Konstantin Khlebnikov
> Fixes: 2f5fb43f ("net_sched: update hierarchical backlog too")
A
On Tue, 2017-08-15 at 17:33 +0300, Konstantin Khlebnikov wrote:
> Nope. I'm not sure. But we have something similar in our 4.4 kernel
> for a while.
>
> Also fq_codel and pfifo_head_drop do something similar tho this.
>
> Probably this might crash without "[PATCH 1/2] net_sched: call
> qlen_noti
On 15.08.2017 17:09, Eric Dumazet wrote:
On Tue, 2017-08-15 at 16:37 +0300, Konstantin Khlebnikov wrote:
When sfq_enqueue() drops head packet or packet from another queue it
have to update backlog at upper qdiscs too.
Signed-off-by: Konstantin Khlebnikov
Fixes: 2f5fb43f ("net_sched: update
On Tue, 2017-08-15 at 16:37 +0300, Konstantin Khlebnikov wrote:
> When sfq_enqueue() drops head packet or packet from another queue it
> have to update backlog at upper qdiscs too.
>
> Signed-off-by: Konstantin Khlebnikov
> Fixes: 2f5fb43f ("net_sched: update hierarchical backlog too")
> ---
When sfq_enqueue() drops head packet or packet from another queue it
have to update backlog at upper qdiscs too.
Signed-off-by: Konstantin Khlebnikov
Fixes: 2f5fb43f ("net_sched: update hierarchical backlog too")
---
net/sched/sch_sfq.c |5 -
1 file changed, 4 insertions(+), 1 deleti
From: Cong Wang
Date: Tue, 14 Jul 2015 11:21:57 -0700
> Fixes: 25331d6ce42b ("net: sched: implement qstat helper routines")
> Cc: John Fastabend
> Signed-off-by: Cong Wang
> Signed-off-by: Cong Wang
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
Fixes: 25331d6ce42b ("net: sched: implement qstat helper routines")
Cc: John Fastabend
Signed-off-by: Cong Wang
Signed-off-by: Cong Wang
---
net/sched/sch_sfq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 7d14926..52f75a5 1
velopers hang out, 'netdev' is.
And you have to post patches for review, not URL's point to
the patches. It has to be int he email, in an applyable form
so people can review the thing properly.
Since SFQ is not exactly simple and I needed something like this
myself, I followed Pa
Patrick McHardy wrote:
> You're missing protocol, handle etc. Try something like this:
>
> tc filter add dev eth0 protocol ip pref 1 parent 1: handle 1 \
>
> flow hash keys dst divisor 1024
Thanks, the kernel accepts that. I guess I understand tc filter usage
less than I thought I did.
Corey Hickey wrote:
Patrick McHardy wrote:
These patches add support for external classifiers to SFQ and add a
new "flow" classifier, which can do hashing based on user-specified
keys or deterministic mapping of keys to classes. Additionally there
is a patch to make the SFQ queues v
Patrick McHardy wrote:
> These patches add support for external classifiers to SFQ and add a
> new "flow" classifier, which can do hashing based on user-specified
> keys or deterministic mapping of keys to classes. Additionally there
> is a patch to make the SFQ queues
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 18:58:02 +0100 (MET)
> These patches add support for external classifiers to SFQ and add a
> new "flow" classifier, which can do hashing based on user-specified
> keys or deterministic mapping of keys to cl
[IPROUTE]: Add support for SFQ xstats
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 196870f762ee393438c42115425f4af69e5b5186
tree 5650c1f93cc58886f8f97a0e55e374c157b96e2e
parent 54bb35c69cec6c730a4ac95530a1d2ca6670f73b
author Patrick McHardy <[EMAIL PROTECTED]> Thu,
These patches add support for external classifiers to SFQ and add a
new "flow" classifier, which can do hashing based on user-specified
keys or deterministic mapping of keys to classes. Additionally there
is a patch to make the SFQ queues visisble as classes to verify that
the hash is in
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 18 Jan 2008 14:48:37 -0800
> Add whitespace around operators, and add a few blank lines
> to improve readability.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe
From: "Paul E. McKenney" <[EMAIL PROTECTED]>
Date: Fri, 18 Jan 2008 20:18:20 -0800
> On Fri, Jan 18, 2008 at 02:47:30PM -0800, Stephen Hemminger wrote:
> > SFQ doesn't need true random numbers, it is only using them to salt
> > a hash. Therefore it is bett
is that the sfq_perturbation
> > > timer might be on one CPU, and all the operations using the corresponding
> > > SFQ on another. This could in theory allow a nearly omniscient attacker
> > > to exploit an SFQ imbalance while preventing perturbation of the hash
> >
On Fri, 04 Jan 2008 11:21:15 -0800
Jeff Gustafson <[EMAIL PROTECTED]> wrote:
> Hi all,
> I have a question about the status of the spiffy updates to SFQ. I
> *really* like the ESFQ idea. I appears to be exactly what I'm looking
> for. From what I can tell from th
r used for re-keying can be deferred, it doesn't
> > > need to be deterministic.
> >
> > The only concern that I can come up with is that the sfq_perturbation
> > timer might be on one CPU, and all the operations using the corresponding
> > SFQ on another.
> The only concern that I can come up with is that the sfq_perturbation
> timer might be on one CPU, and all the operations using the corresponding
> SFQ on another. This could in theory allow a nearly omniscient attacker
> to exploit an SFQ imbalance while preventing perturbation of t
s using the corresponding
SFQ on another. This could in theory allow a nearly omniscient attacker
to exploit an SFQ imbalance while preventing perturbation of the hash
function.
This does not seem to be a valid concern at this point, since there are
very few uses of init_timer_deferrable(). And i
On Fri, Jan 18, 2008 at 02:47:30PM -0800, Stephen Hemminger wrote:
> SFQ doesn't need true random numbers, it is only using them to salt
> a hash. Therefore it is better to use net_random() and avoid any possible
> problems with depleting the entropy pool.
The random-number alg
SFQ doesn't need true random numbers, it is only using them to salt
a hash. Therefore it is better to use net_random() and avoid any possible
problems with depleting the entropy pool.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/sched/sch_sfq.c 2008-
The perturbation timer used for re-keying can be deferred, it doesn't
need to be deterministic.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/sched/sch_sfq.c 2008-01-17 08:29:24.0 -0800
+++ b/net/sched/sch_sfq.c 2008-01-17 09:00:58.0 -0800
@@ -426,7 +
Add whitespace around operators, and add a few blank lines
to improve readability.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/sched/sch_sfq.c 2008-01-17 08:33:04.0 -0800
+++ b/net/sched/sch_sfq.c 2008-01-17 08:43:51.0 -0800
@@ -122,7 +122,7 @@ stat
Hi all,
I have a question about the status of the spiffy updates to SFQ. I
*really* like the ESFQ idea. I appears to be exactly what I'm looking
for. From what I can tell from this mailing list, SFQ is getting some
or all of the ESFQ features. Although the ESFQ web site gives det
s for my patches so far and yet another one would be much appreciated.
>
> Thanks,
> Corey
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majord
Corey Hickey wrote:
> Patchset try 2 addresses the review by Michael Buesch.
> Patchset try 3 addresses the review by Patrick McHardy.
> Patchset try 4 has a few cosmetic improvements.
> Patchset try 5 addresses further review by Patrick McHardy.
>
> This set of patches is substantially the same a
in compile time.
- */
-
/* RED section */
enum
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 05385cf..19e76ba 100644
--- a/tc/q_sfq.c
+++ b/tc/q_sfq.c
@@ -25,7 +25,7 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... sfq [ limit NUMBER ] [ perturb SECS ] [
quantum BYTE
These patches follow the ESFQ-->SFQ kernel patches. See the kernel
patch summary for general information.
Thanks,
Corey
include/linux/pkt_sched.h | 23 ++-
tc/q_sfq.c| 42 +-
2 files changed, 51 insertions(+),
changes made according to Patrick's recommendations.
Iproute2 patches will follow shortly.
The following is the original patch text.
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying t
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 19:55:22 +0400
> Hello!
>
> Remove artificial limitation for sfq queue limit.
>
> This is followup to Patrick's patch. A little optimization to enqueue
> routine allows to remove artificial limitati
Patrick McHardy wrote:
Corey Hickey wrote:
Patchset try 2 addresses the review by Michael Buesch.
Patchset try 3 addresses the review by Patrick McHardy.
Patchset try 4 has a few cosmetic improvements.
Nobody reviewed my last set of patches, and I wasn't pushy about asking.
Since it's been a wh
Corey Hickey wrote:
> Patchset try 2 addresses the review by Michael Buesch.
> Patchset try 3 addresses the review by Patrick McHardy.
> Patchset try 4 has a few cosmetic improvements.
>
> Nobody reviewed my last set of patches, and I wasn't pushy about asking.
> Since it's been a while, I ported
Corey Hickey wrote:
These patches follow the ESFQ-->SFQ kernel patches. See the kernel
patch summary for general information.
Dang, I forgot to set the subject; these are the iproute2 patches.
-Corey
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
These patches follow the ESFQ-->SFQ kernel patches. See the kernel
patch summary for general information.
Thanks,
Corey
include/linux/pkt_sched.h | 23 ++-
tc/q_sfq.c| 43 ++-
2 files changed, 52 inserti
ssible
- * to change these parameters in compile time.
- */
-
/* RED section */
enum
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 05385cf..7754db7 100644
--- a/tc/q_sfq.c
+++ b/tc/q_sfq.c
@@ -25,7 +25,7 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... sfq [ l
ext.
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying to get ESFQ included as a separate qdisc.
http://mailman.ds9a.nl/pipermail/lartc/2007q2/021056.html
My patches here implement "
Hello!
Remove artificial limitation for sfq queue limit.
This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.
Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even swee
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 19 Sep 2007 15:08:22 +0200
> Alexey Kuznetsov wrote:
> > Hello!
> >
> >>CCed Alexey just to be safe, but I think the patch should be fine.
> >
> >
> > Yes. But what'a about limit == 1? tc prohibits this case, but it is still
> > not nice to h
Alexey Kuznetsov wrote:
> Hello!
>
>>CCed Alexey just to be safe, but I think the patch should be fine.
>
>
> Yes. But what'a about limit == 1? tc prohibits this case, but it is still
> not nice to have the bug in kernel. Plus, code remains creepy, the check
>
> + if (++sch->q.qlen < q->lim
Hello!
> OK the off-by-one prevents an out-of-bounds array access,
Yes, this is not off-by-one (off-by-two, to be more exact :-)).
Maximal queue length is really limited by SFQ_DEPTH-2, because:
1. SFQ keeps list of queue lengths in array of length SFQ_DEPTH.
This means length of queue m
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 21:15:28 +0200
> OK the off-by-one prevents an out-of-bounds array access, which
> would cause a crash itself. Despite what I said above, sfq does
> try to handle dequeues while empty, but forgets to update q->ta
way and the empty qdisc is
> dequeued, which is not handled by SFQ.
>
> I see three possibilities to fix this (in my preferred order):
>
> 1) figure out why the off-by-one is there, if not needed remove
> 2) don't dequeue qdiscs even once if empty
> 3) check for NULL in sfq_
again.
dev_queue_xmit() calls qdisc_run() anyway and the empty qdisc is
dequeued, which is not handled by SFQ.
I see three possibilities to fix this (in my preferred order):
1) figure out why the off-by-one is there, if not needed remove
2) don't dequeue qdiscs even once if empty
3) check for NU
Chuck Ebbert wrote:
> Limit of 1 is forbidden, crashes with 2, works with 3:
>
>>From disassembling sch_sfq.ko it seems that it is on line 360 of sch_sfq.c:
> sch->qstats.backlog -= skb->len;
> where "skb" is an invalid pointer:
Is it a NULL pointer or something random?
-
To unsubscribe from
Limit of 1 is forbidden, crashes with 2, works with 3:
https://bugzilla.redhat.com/show_bug.cgi?id=219895
=
If the defect is produced at a console (as in ctrl-alt-f<0-6>) a kernel stack
trace can be seen the moment "ping" is invoked. Since the stack trace is not
written to the /var/log
These patches follow the ESFQ-->SFQ kernel patches. See the kernel
patch summary for general information.
Thanks,
Corey
include/linux/pkt_sched.h | 23 ++-
tc/q_sfq.c| 43 ++-
2 files changed, 52 inserti
.
- */
-
/* RED section */
enum
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 05385cf..7754db7 100644
--- a/tc/q_sfq.c
+++ b/tc/q_sfq.c
@@ -25,7 +25,7 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... sfq [ limit NUMBER ] [ perturb SECS ] [
quantum BYTES ]\n");
+
shortly.
The following is the original patch text.
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying to get ESFQ included as a separate qdisc.
http://mailman.ds9a.nl/pipermail/lartc/2007q2/021
> very much.
> >
>
> In the spirit of SFQ it is probably ok to do that;
> i.e iirc, the idea for justification behind sfq was to provide a
> "computationaly feasible/reasonable" way to provide fair queueing with a
> gazillion queues.
> Classification was co
.
- */
-
/* RED section */
enum
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 05385cf..7754db7 100644
--- a/tc/q_sfq.c
+++ b/tc/q_sfq.c
@@ -25,7 +25,7 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... sfq [ limit NUMBER ] [ perturb SECS ] [
quantum BYTES ]\n");
+
Hello,
Patchset try 2 addresses the review by Michael Buesch.
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying to get ESFQ included as a separate qdisc.
http://mailman.ds9a.nl/pipermail/
From: Corey Hickey <[EMAIL PROTECTED]>
Date: Sun, 29 Jul 2007 00:17:15 -0700
> Corey Hickey wrote:
> > Hello,
> >
> > This set of patches adds some of ESFQ's modifications to the original
> > SFQ. Thus far, I have received support for this approach r
Corey Hickey wrote:
Hello,
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying to get ESFQ included as a separate qdisc.
Crud; I wasn't expecting git-send-email to thread the message
.
- */
-
/* RED section */
enum
diff --git a/tc/q_sfq.c b/tc/q_sfq.c
index 05385cf..7754db7 100644
--- a/tc/q_sfq.c
+++ b/tc/q_sfq.c
@@ -25,7 +25,7 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... sfq [ limit NUMBER ] [ perturb SECS ] [
quantum BYTES ]\n");
+
Hello,
This set of patches adds some of ESFQ's modifications to the original
SFQ. Thus far, I have received support for this approach rather than for
trying to get ESFQ included as a separate qdisc.
http://mailman.ds9a.nl/pipermail/lartc/2007q2/021056.html
My patches here implement &quo
On Wed, 2007-30-05 at 18:55 +0200, Patrick McHardy wrote:
> I could do that, but I'm perfectly happy with the qdisc part of SFQ.
> Without the classifier SFQ is of course simply a FQ qdisc, all it
> cares about is serving queues equally.
Sure. You are writting the code - your
Patrick McHardy wrote:
My classifier uses jhash,
Ahh that's OK - I thought it still used the old sfq hash, which collided
alot with a low number of consecutive addresses.
Andy.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [
jamal wrote:
> On Wed, 2007-30-05 at 18:23 +0200, Patrick McHardy wrote:
>
>>My classifier seperates them entirely. The only thing it keeps
>>in SFQ is the old classifier for compatibility, besides that its
>>exactly what you say. It should be easily possible to remove
be useful.
> What
> remains for SFQ to do is serve the queues evenly.
And it does (yes, I looked at the patch;->).
> My classifier seperates them entirely. The only thing it keeps
> in SFQ is the old classifier for compatibility, besides that its
> exactly what you say. It s
>>Not sure exactly why I would need a new qdisc to do that :)
>>
>
>
> The caveat/difference with current SFQ is you have allowed the user to
> define which queue is selected.
I think exposing SFQ's queues as classes is a good thing, it allows
you to do whatever cl
gt; classification to the classifiers.
>
> I created a new classifier to leave classification to the classifiers ..
> Not sure exactly why I would need a new qdisc to do that :)
>
The caveat/difference with current SFQ is you have allowed the user to
define which queue is selected. It is
Andy Furniss wrote:
> Patrick McHardy wrote:
>
>> It currently does not support perturbation, I didn't want to move this
>> into
>> the classifier, so I need to think about a way to handle it within SFQ.
>>
>
> Cool, but isn't this going to show th
jamal wrote:
> On Wed, 2007-30-05 at 11:40 +0200, Patrick McHardy wrote:
>
>>One good thing about ESFQ is the more flexible flow classification, but
>>I don't like the concept of having a set of selectable hash functions
>>very much.
>>
>
>
> In th
On Wed, 2007-30-05 at 11:40 +0200, Patrick McHardy wrote:
> One good thing about ESFQ is the more flexible flow classification, but
> I don't like the concept of having a set of selectable hash functions
> very much.
>
In the spirit of SFQ it is probably ok to do that;
i.e ii
Patrick McHardy wrote:
One good thing about ESFQ is the more flexible flow classification, but
I don't like the concept of having a set of selectable hash functions
very much.
These patches change SFQ to allow attaching external classifiers and add
a new "flow" classifier
One good thing about ESFQ is the more flexible flow classification, but
I don't like the concept of having a set of selectable hash functions
very much.
These patches change SFQ to allow attaching external classifiers and add
a new "flow" classifier that allows to classify fl
On Tue, 2006-31-01 at 01:16 +0100, Patrick McHardy wrote:
> David S. Miller wrote:
> > From: dean gaudet <[EMAIL PROTECTED]>
> > Date: Sat, 17 Dec 2005 18:22:40 -0800 (PST)
> >
> >
> >>let me know what you think... i'd like to get something like this patch
> >>included upstream so i can eliminate
ash
functions. In fact there are more useful features in ESFQ and someone
should look into merging them into SFQ. I've put it on my TODO list in
case nobody else cares :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: dean gaudet <[EMAIL PROTECTED]>
Date: Sat, 17 Dec 2005 18:22:40 -0800 (PST)
> let me know what you think... i'd like to get something like this patch
> included upstream so i can eliminate a patch from several of my kernels.
The RTA length check is a little hackish. Maybe use a new
attribu
hi,
i've always found it unfortunate that sfq includes the destination port in
the hash because so-called "download accelerators" which issue a bunch of
simultaneous http range-requests with non-overlapping ranges end up
getting an unfair share of the bandwidth. so i've
79 matches
Mail list logo
