* Re: [PATCH] Fix dumping vlan rules
From: Florian Westphal @ 2019-07-13 21:43 UTC (permalink / raw)
To: michael-dev; +Cc: netdev, netfilter-devel
In-Reply-To: <20190713210306.30815-1-michael-dev@fami-braun.de>
michael-dev@fami-braun.de <michael-dev@fami-braun.de> wrote:
> From: "M. Braun" <michael-dev@fami-braun.de>
>
> Given the following bridge rules:
> 1. ip protocol icmp accept
> 2. ether type vlan vlan type ip ip protocol icmp accept
>
> The are currently both dumped by "nft list ruleset" as
> 1. ip protocol icmp accept
> 2. ip protocol icmp accept
Yes, thats a bug, the dependency removal is incorrect.
> +++ b/src/payload.c
> @@ -506,6 +506,18 @@ static bool payload_may_dependency_kill(struct payload_dep_ctx *ctx,
> dep->left->payload.desc == &proto_ip6) &&
> expr->payload.base == PROTO_BASE_TRANSPORT_HDR)
> return false;
> + /* Do not kill
> + * ether type vlan and vlan type ip and ip protocol icmp
> + * into
> + * ip protocol icmp
> + * as this lacks ether type vlan.
> + * More generally speaking, do not kill protocol type
> + * for stacked protocols if we only have protcol type matches.
> + */
> + if (dep->left->etype == EXPR_PAYLOAD && dep->op == OP_EQ &&
> + expr->flags & EXPR_F_PROTOCOL &&
> + expr->payload.base == dep->left->payload.base)
> + return false;
Can you please add a test case for this problem to
tests/py/bridge/vlan.t so we catch this when messing with dependency
handling in the future?
Also, please submit v2 directly to netfilter-devel@.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Paul E. McKenney @ 2019-07-13 21:28 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713161316.GA39321@google.com>
On Sat, Jul 13, 2019 at 12:13:16PM -0400, Joel Fernandes wrote:
> On Sat, Jul 13, 2019 at 08:50:10AM -0700, Paul E. McKenney wrote:
> > On Sat, Jul 13, 2019 at 11:36:06AM -0400, Joel Fernandes wrote:
> > > On Sat, Jul 13, 2019 at 07:41:08AM -0700, Paul E. McKenney wrote:
> > > > On Sat, Jul 13, 2019 at 09:30:49AM -0400, Joel Fernandes wrote:
> > > > > On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> > > > > > On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > > > > > > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > > > > > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > > > > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > > > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > > > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > > > > > > and it results in a nice cleanup.
> > > > > > > > > > >
> > > > > > > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > > > > > >
> > > > > > > > > > Hi Oleg,
> > > > > > > > > > Slightly unrelated to the patch,
> > > > > > > > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > > > > > > > >
> > > > > > > > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > > > > > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > > > > > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > > > > > > > reflect latest changes?
> > > > > > > > > > Also could you help understand how is a writer not able to change
> > > > > > > > > > sem->state and count the per-cpu read counters at the same time as the
> > > > > > > > > > comment tries to say?
> > > > > > > > > >
> > > > > > > > > > /*
> > > > > > > > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > > > > > > > * cannot both change sem->state from readers_fast and start checking
> > > > > > > > > > * counters while we are here. So if we see !sem->state, we know that
> > > > > > > > > > * the writer won't be checking until we're past the preempt_enable()
> > > > > > > > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > > > > > > > * anything we did within this RCU-sched read-size critical section.
> > > > > > > > > > */
> > > > > > > > > >
> > > > > > > > > > Also,
> > > > > > > > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > > > > > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > > > > > > > series.
> > > > > > > > >
> > > > > > > > > Hello, Joel,
> > > > > > > > >
> > > > > > > > > Oleg has a set of patches updating this code that just hit mainline
> > > > > > > > > this week. These patches get rid of the code that previously handled
> > > > > > > > > RCU's multiple flavors. Or are you looking at current mainline and
> > > > > > > > > me just missing your point?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Hi Paul,
> > > > > > > > You are right on point. I have a bad habit of not rebasing my trees. In this
> > > > > > > > case the feature branch of mine in concern was based on v5.1. Needless to
> > > > > > > > say, I need to rebase my tree.
> > > > > > > >
> > > > > > > > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > > > > > > > rebase just fine.
> > > > > > > >
> > > > > > > > The 2 options I see are:
> > > > > > > > 1. Let us drop this patch for now and I resend it later.
> > > > > > > > 2. I resend all patches based on Linus's master branch.
> > > > > > >
> > > > > > > Below is the updated patch based on Linus master branch:
> > > > > > >
> > > > > > > ---8<-----------------------
> > > > > > >
> > > > > > > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > > > > > > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > > > > > > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > > > > > > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
> > > > > > >
> > > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > > and it results in a nice cleanup.
> > > > > > >
> > > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > > > ---
> > > > > > > include/linux/rcu_sync.h | 4 +---
> > > > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > > > > > > index 9b83865d24f9..0027d4c8087c 100644
> > > > > > > --- a/include/linux/rcu_sync.h
> > > > > > > +++ b/include/linux/rcu_sync.h
> > > > > > > @@ -31,9 +31,7 @@ struct rcu_sync {
> > > > > > > */
> > > > > > > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > > > > > > {
> > > > > > > - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > > > > > > - !rcu_read_lock_bh_held() &&
> > > > > > > - !rcu_read_lock_sched_held(),
> > > > > > > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> > > > > >
> > > > > > I believe that replacing rcu_read_lock_sched_held() with preemptible()
> > > > > > in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
> > > > > > If you have not already done so, could you please give it a try?
> > > > >
> > > > > Hi Paul,
> > > > > I don't think it will cause splats for !CONFIG_PREEMPT.
> > > > >
> > > > > Currently, rcu_read_lock_any_held() introduced in this patch returns true if
> > > > > !preemptible(). This means that:
> > > > >
> > > > > The following expression above:
> > > > > RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),...)
> > > > >
> > > > > Becomes:
> > > > > RCU_LOCKDEP_WARN(preemptible(), ...)
> > > > >
> > > > > For, CONFIG_PREEMPT=n kernels, this means:
> > > > > RCU_LOCKDEP_WARN(0, ...)
> > > > >
> > > > > Which would mean no splats. Or, did I miss the point?
> > > >
> > > > I suggest trying it out on a CONFIG_PREEMPT=n kernel.
> > >
> > > Sure, will do, sorry did not try it out yet because was busy with weekend
> > > chores but will do soon, thanks!
> >
> > I am not faulting you for taking the weekend off, actually. ;-)
>
> ;-)
>
> I tried doing RCU_LOCKDEP_WARN(preemptible(), ...) in this code path and I
> don't get any splats. I also disassembled the code and it seems to me
> RCU_LOCKDEP_WARN() becomes a NOOP which also the above reasoning confirms.
OK, very good. Could you do the same thing for the RCU_LOCKDEP_WARN()
in synchronize_rcu()? Why or why not?
(No need to work this on your Sunday.)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] Fix dumping vlan rules
From: Laura Garcia @ 2019-07-13 21:15 UTC (permalink / raw)
To: michael-dev; +Cc: netdev, Netfilter Development Mailing list
In-Reply-To: <20190713210306.30815-1-michael-dev@fami-braun.de>
CC'ing netfilter.
On Sat, Jul 13, 2019 at 11:10 PM <michael-dev@fami-braun.de> wrote:
>
> From: "M. Braun" <michael-dev@fami-braun.de>
>
> Given the following bridge rules:
> 1. ip protocol icmp accept
> 2. ether type vlan vlan type ip ip protocol icmp accept
>
> The are currently both dumped by "nft list ruleset" as
> 1. ip protocol icmp accept
> 2. ip protocol icmp accept
>
> Though, the netlink code actually is different
>
> bridge filter FORWARD 4
> [ payload load 2b @ link header + 12 => reg 1 ]
> [ cmp eq reg 1 0x00000008 ]
> [ payload load 1b @ network header + 9 => reg 1 ]
> [ cmp eq reg 1 0x00000001 ]
> [ immediate reg 0 accept ]
>
> bridge filter FORWARD 5 4
> [ payload load 2b @ link header + 12 => reg 1 ]
> [ cmp eq reg 1 0x00000081 ]
> [ payload load 2b @ link header + 16 => reg 1 ]
> [ cmp eq reg 1 0x00000008 ]
> [ payload load 1b @ network header + 9 => reg 1 ]
> [ cmp eq reg 1 0x00000001 ]
> [ immediate reg 0 accept ]
>
> Fix this by avoiding the removal of all vlan statements
> in the given example.
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
> ---
> src/payload.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/payload.c b/src/payload.c
> index 3bf1ecc..905422a 100644
> --- a/src/payload.c
> +++ b/src/payload.c
> @@ -506,6 +506,18 @@ static bool payload_may_dependency_kill(struct payload_dep_ctx *ctx,
> dep->left->payload.desc == &proto_ip6) &&
> expr->payload.base == PROTO_BASE_TRANSPORT_HDR)
> return false;
> + /* Do not kill
> + * ether type vlan and vlan type ip and ip protocol icmp
> + * into
> + * ip protocol icmp
> + * as this lacks ether type vlan.
> + * More generally speaking, do not kill protocol type
> + * for stacked protocols if we only have protcol type matches.
> + */
> + if (dep->left->etype == EXPR_PAYLOAD && dep->op == OP_EQ &&
> + expr->flags & EXPR_F_PROTOCOL &&
> + expr->payload.base == dep->left->payload.base)
> + return false;
> break;
> }
>
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH] Fix dumping vlan rules
From: michael-dev @ 2019-07-13 21:03 UTC (permalink / raw)
To: netdev; +Cc: michael-dev
From: "M. Braun" <michael-dev@fami-braun.de>
Given the following bridge rules:
1. ip protocol icmp accept
2. ether type vlan vlan type ip ip protocol icmp accept
The are currently both dumped by "nft list ruleset" as
1. ip protocol icmp accept
2. ip protocol icmp accept
Though, the netlink code actually is different
bridge filter FORWARD 4
[ payload load 2b @ link header + 12 => reg 1 ]
[ cmp eq reg 1 0x00000008 ]
[ payload load 1b @ network header + 9 => reg 1 ]
[ cmp eq reg 1 0x00000001 ]
[ immediate reg 0 accept ]
bridge filter FORWARD 5 4
[ payload load 2b @ link header + 12 => reg 1 ]
[ cmp eq reg 1 0x00000081 ]
[ payload load 2b @ link header + 16 => reg 1 ]
[ cmp eq reg 1 0x00000008 ]
[ payload load 1b @ network header + 9 => reg 1 ]
[ cmp eq reg 1 0x00000001 ]
[ immediate reg 0 accept ]
Fix this by avoiding the removal of all vlan statements
in the given example.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
---
src/payload.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/payload.c b/src/payload.c
index 3bf1ecc..905422a 100644
--- a/src/payload.c
+++ b/src/payload.c
@@ -506,6 +506,18 @@ static bool payload_may_dependency_kill(struct payload_dep_ctx *ctx,
dep->left->payload.desc == &proto_ip6) &&
expr->payload.base == PROTO_BASE_TRANSPORT_HDR)
return false;
+ /* Do not kill
+ * ether type vlan and vlan type ip and ip protocol icmp
+ * into
+ * ip protocol icmp
+ * as this lacks ether type vlan.
+ * More generally speaking, do not kill protocol type
+ * for stacked protocols if we only have protcol type matches.
+ */
+ if (dep->left->etype == EXPR_PAYLOAD && dep->op == OP_EQ &&
+ expr->flags & EXPR_F_PROTOCOL &&
+ expr->payload.base == dep->left->payload.base)
+ return false;
break;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Joel Fernandes @ 2019-07-13 16:13 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713155010.GF26519@linux.ibm.com>
On Sat, Jul 13, 2019 at 08:50:10AM -0700, Paul E. McKenney wrote:
> On Sat, Jul 13, 2019 at 11:36:06AM -0400, Joel Fernandes wrote:
> > On Sat, Jul 13, 2019 at 07:41:08AM -0700, Paul E. McKenney wrote:
> > > On Sat, Jul 13, 2019 at 09:30:49AM -0400, Joel Fernandes wrote:
> > > > On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> > > > > On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > > > > > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > > > > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > > > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > > > > > and it results in a nice cleanup.
> > > > > > > > > >
> > > > > > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > > > > >
> > > > > > > > > Hi Oleg,
> > > > > > > > > Slightly unrelated to the patch,
> > > > > > > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > > > > > > >
> > > > > > > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > > > > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > > > > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > > > > > > reflect latest changes?
> > > > > > > > > Also could you help understand how is a writer not able to change
> > > > > > > > > sem->state and count the per-cpu read counters at the same time as the
> > > > > > > > > comment tries to say?
> > > > > > > > >
> > > > > > > > > /*
> > > > > > > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > > > > > > * cannot both change sem->state from readers_fast and start checking
> > > > > > > > > * counters while we are here. So if we see !sem->state, we know that
> > > > > > > > > * the writer won't be checking until we're past the preempt_enable()
> > > > > > > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > > > > > > * anything we did within this RCU-sched read-size critical section.
> > > > > > > > > */
> > > > > > > > >
> > > > > > > > > Also,
> > > > > > > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > > > > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > > > > > > series.
> > > > > > > >
> > > > > > > > Hello, Joel,
> > > > > > > >
> > > > > > > > Oleg has a set of patches updating this code that just hit mainline
> > > > > > > > this week. These patches get rid of the code that previously handled
> > > > > > > > RCU's multiple flavors. Or are you looking at current mainline and
> > > > > > > > me just missing your point?
> > > > > > > >
> > > > > > >
> > > > > > > Hi Paul,
> > > > > > > You are right on point. I have a bad habit of not rebasing my trees. In this
> > > > > > > case the feature branch of mine in concern was based on v5.1. Needless to
> > > > > > > say, I need to rebase my tree.
> > > > > > >
> > > > > > > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > > > > > > rebase just fine.
> > > > > > >
> > > > > > > The 2 options I see are:
> > > > > > > 1. Let us drop this patch for now and I resend it later.
> > > > > > > 2. I resend all patches based on Linus's master branch.
> > > > > >
> > > > > > Below is the updated patch based on Linus master branch:
> > > > > >
> > > > > > ---8<-----------------------
> > > > > >
> > > > > > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > > > > > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > > > > > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > > > > > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
> > > > > >
> > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > and it results in a nice cleanup.
> > > > > >
> > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > > ---
> > > > > > include/linux/rcu_sync.h | 4 +---
> > > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > > > > > index 9b83865d24f9..0027d4c8087c 100644
> > > > > > --- a/include/linux/rcu_sync.h
> > > > > > +++ b/include/linux/rcu_sync.h
> > > > > > @@ -31,9 +31,7 @@ struct rcu_sync {
> > > > > > */
> > > > > > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > > > > > {
> > > > > > - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > > > > > - !rcu_read_lock_bh_held() &&
> > > > > > - !rcu_read_lock_sched_held(),
> > > > > > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> > > > >
> > > > > I believe that replacing rcu_read_lock_sched_held() with preemptible()
> > > > > in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
> > > > > If you have not already done so, could you please give it a try?
> > > >
> > > > Hi Paul,
> > > > I don't think it will cause splats for !CONFIG_PREEMPT.
> > > >
> > > > Currently, rcu_read_lock_any_held() introduced in this patch returns true if
> > > > !preemptible(). This means that:
> > > >
> > > > The following expression above:
> > > > RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),...)
> > > >
> > > > Becomes:
> > > > RCU_LOCKDEP_WARN(preemptible(), ...)
> > > >
> > > > For, CONFIG_PREEMPT=n kernels, this means:
> > > > RCU_LOCKDEP_WARN(0, ...)
> > > >
> > > > Which would mean no splats. Or, did I miss the point?
> > >
> > > I suggest trying it out on a CONFIG_PREEMPT=n kernel.
> >
> > Sure, will do, sorry did not try it out yet because was busy with weekend
> > chores but will do soon, thanks!
>
> I am not faulting you for taking the weekend off, actually. ;-)
;-)
I tried doing RCU_LOCKDEP_WARN(preemptible(), ...) in this code path and I
don't get any splats. I also disassembled the code and it seems to me
RCU_LOCKDEP_WARN() becomes a NOOP which also the above reasoning confirms.
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Paul E. McKenney @ 2019-07-13 15:50 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713153606.GD133650@google.com>
On Sat, Jul 13, 2019 at 11:36:06AM -0400, Joel Fernandes wrote:
> On Sat, Jul 13, 2019 at 07:41:08AM -0700, Paul E. McKenney wrote:
> > On Sat, Jul 13, 2019 at 09:30:49AM -0400, Joel Fernandes wrote:
> > > On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > > > > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > > > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > > > > and it results in a nice cleanup.
> > > > > > > > >
> > > > > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > > > >
> > > > > > > > Hi Oleg,
> > > > > > > > Slightly unrelated to the patch,
> > > > > > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > > > > > >
> > > > > > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > > > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > > > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > > > > > reflect latest changes?
> > > > > > > > Also could you help understand how is a writer not able to change
> > > > > > > > sem->state and count the per-cpu read counters at the same time as the
> > > > > > > > comment tries to say?
> > > > > > > >
> > > > > > > > /*
> > > > > > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > > > > > * cannot both change sem->state from readers_fast and start checking
> > > > > > > > * counters while we are here. So if we see !sem->state, we know that
> > > > > > > > * the writer won't be checking until we're past the preempt_enable()
> > > > > > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > > > > > * anything we did within this RCU-sched read-size critical section.
> > > > > > > > */
> > > > > > > >
> > > > > > > > Also,
> > > > > > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > > > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > > > > > series.
> > > > > > >
> > > > > > > Hello, Joel,
> > > > > > >
> > > > > > > Oleg has a set of patches updating this code that just hit mainline
> > > > > > > this week. These patches get rid of the code that previously handled
> > > > > > > RCU's multiple flavors. Or are you looking at current mainline and
> > > > > > > me just missing your point?
> > > > > > >
> > > > > >
> > > > > > Hi Paul,
> > > > > > You are right on point. I have a bad habit of not rebasing my trees. In this
> > > > > > case the feature branch of mine in concern was based on v5.1. Needless to
> > > > > > say, I need to rebase my tree.
> > > > > >
> > > > > > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > > > > > rebase just fine.
> > > > > >
> > > > > > The 2 options I see are:
> > > > > > 1. Let us drop this patch for now and I resend it later.
> > > > > > 2. I resend all patches based on Linus's master branch.
> > > > >
> > > > > Below is the updated patch based on Linus master branch:
> > > > >
> > > > > ---8<-----------------------
> > > > >
> > > > > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > > > > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > > > > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > > > > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
> > > > >
> > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > this series, this is no longer need. We can just use the generic helper
> > > > > and it results in a nice cleanup.
> > > > >
> > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > ---
> > > > > include/linux/rcu_sync.h | 4 +---
> > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > > > > index 9b83865d24f9..0027d4c8087c 100644
> > > > > --- a/include/linux/rcu_sync.h
> > > > > +++ b/include/linux/rcu_sync.h
> > > > > @@ -31,9 +31,7 @@ struct rcu_sync {
> > > > > */
> > > > > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > > > > {
> > > > > - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > > > > - !rcu_read_lock_bh_held() &&
> > > > > - !rcu_read_lock_sched_held(),
> > > > > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> > > >
> > > > I believe that replacing rcu_read_lock_sched_held() with preemptible()
> > > > in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
> > > > If you have not already done so, could you please give it a try?
> > >
> > > Hi Paul,
> > > I don't think it will cause splats for !CONFIG_PREEMPT.
> > >
> > > Currently, rcu_read_lock_any_held() introduced in this patch returns true if
> > > !preemptible(). This means that:
> > >
> > > The following expression above:
> > > RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),...)
> > >
> > > Becomes:
> > > RCU_LOCKDEP_WARN(preemptible(), ...)
> > >
> > > For, CONFIG_PREEMPT=n kernels, this means:
> > > RCU_LOCKDEP_WARN(0, ...)
> > >
> > > Which would mean no splats. Or, did I miss the point?
> >
> > I suggest trying it out on a CONFIG_PREEMPT=n kernel.
>
> Sure, will do, sorry did not try it out yet because was busy with weekend
> chores but will do soon, thanks!
I am not faulting you for taking the weekend off, actually. ;-)
Thanx, Paul
^ permalink raw reply
* [net-next 0/2] ipvs: speedup ipvs netns dismantle
From: Haishuang Yan @ 2019-07-13 15:19 UTC (permalink / raw)
To: David S. Miller, Pablo Neira Ayuso, Simon Horman
Cc: netdev, lvs-devel, linux-kernel, netfilter-devel, Haishuang Yan
Implement exit_batch() method to dismantle more ipvs netns
per round.
Haishuang Yan (2):
ipvs: batch __ip_vs_cleanup
ipvs: batch __ip_vs_dev_cleanup
include/net/ip_vs.h | 2 +-
net/netfilter/ipvs/ip_vs_core.c | 49 +++++++++++++++++++++++++----------------
net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++---
3 files changed, 41 insertions(+), 23 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [net-next 2/2] ipvs: batch __ip_vs_dev_cleanup
From: Haishuang Yan @ 2019-07-13 15:19 UTC (permalink / raw)
To: David S. Miller, Pablo Neira Ayuso, Simon Horman
Cc: netdev, lvs-devel, linux-kernel, netfilter-devel, Haishuang Yan
In-Reply-To: <1563031186-2101-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
It's better to batch __ip_vs_cleanup to speedup ipvs
devices dismantle.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/netfilter/ipvs/ip_vs_core.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index b4d79b7..58af24a 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -2434,14 +2434,20 @@ static int __net_init __ip_vs_dev_init(struct net *net)
return ret;
}
-static void __net_exit __ip_vs_dev_cleanup(struct net *net)
+static void __net_exit __ip_vs_dev_cleanup_batch(struct list_head *net_list)
{
- struct netns_ipvs *ipvs = net_ipvs(net);
+ struct netns_ipvs *ipvs;
+ struct net *net;
+ LIST_HEAD(list);
+
EnterFunction(2);
- nf_unregister_net_hooks(net, ip_vs_ops, ARRAY_SIZE(ip_vs_ops));
- ipvs->enable = 0; /* Disable packet reception */
- smp_wmb();
- ip_vs_sync_net_cleanup(ipvs);
+ list_for_each_entry(net, net_list, exit_list) {
+ ipvs = net_ipvs(net);
+ nf_unregister_net_hooks(net, ip_vs_ops, ARRAY_SIZE(ip_vs_ops));
+ ipvs->enable = 0; /* Disable packet reception */
+ smp_wmb();
+ ip_vs_sync_net_cleanup(ipvs);
+ }
LeaveFunction(2);
}
@@ -2454,7 +2460,7 @@ static void __net_exit __ip_vs_dev_cleanup(struct net *net)
static struct pernet_operations ipvs_core_dev_ops = {
.init = __ip_vs_dev_init,
- .exit = __ip_vs_dev_cleanup,
+ .exit_batch = __ip_vs_dev_cleanup_batch,
};
/*
--
1.8.3.1
^ permalink raw reply related
* [net-next 1/2] ipvs: batch __ip_vs_cleanup
From: Haishuang Yan @ 2019-07-13 15:19 UTC (permalink / raw)
To: David S. Miller, Pablo Neira Ayuso, Simon Horman
Cc: netdev, lvs-devel, linux-kernel, netfilter-devel, Haishuang Yan
In-Reply-To: <1563031186-2101-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
It's better to batch __ip_vs_cleanup to speedup ipvs
connections dismantle.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
include/net/ip_vs.h | 2 +-
net/netfilter/ipvs/ip_vs_core.c | 29 +++++++++++++++++------------
net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++++---
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 3759167..93e7a25 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1324,7 +1324,7 @@ static inline void ip_vs_control_del(struct ip_vs_conn *cp)
void ip_vs_control_net_cleanup(struct netns_ipvs *ipvs);
void ip_vs_estimator_net_cleanup(struct netns_ipvs *ipvs);
void ip_vs_sync_net_cleanup(struct netns_ipvs *ipvs);
-void ip_vs_service_net_cleanup(struct netns_ipvs *ipvs);
+void ip_vs_service_nets_cleanup(struct list_head *net_list);
/* IPVS application functions
* (from ip_vs_app.c)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 46f06f9..b4d79b7 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -2402,18 +2402,23 @@ static int __net_init __ip_vs_init(struct net *net)
return -ENOMEM;
}
-static void __net_exit __ip_vs_cleanup(struct net *net)
+static void __net_exit __ip_vs_cleanup_batch(struct list_head *net_list)
{
- struct netns_ipvs *ipvs = net_ipvs(net);
-
- ip_vs_service_net_cleanup(ipvs); /* ip_vs_flush() with locks */
- ip_vs_conn_net_cleanup(ipvs);
- ip_vs_app_net_cleanup(ipvs);
- ip_vs_protocol_net_cleanup(ipvs);
- ip_vs_control_net_cleanup(ipvs);
- ip_vs_estimator_net_cleanup(ipvs);
- IP_VS_DBG(2, "ipvs netns %d released\n", ipvs->gen);
- net->ipvs = NULL;
+ struct netns_ipvs *ipvs;
+ struct net *net;
+ LIST_HEAD(list);
+
+ ip_vs_service_nets_cleanup(net_list); /* ip_vs_flush() with locks */
+ list_for_each_entry(net, net_list, exit_list) {
+ ipvs = net_ipvs(net);
+ ip_vs_conn_net_cleanup(ipvs);
+ ip_vs_app_net_cleanup(ipvs);
+ ip_vs_protocol_net_cleanup(ipvs);
+ ip_vs_control_net_cleanup(ipvs);
+ ip_vs_estimator_net_cleanup(ipvs);
+ IP_VS_DBG(2, "ipvs netns %d released\n", ipvs->gen);
+ net->ipvs = NULL;
+ }
}
static int __net_init __ip_vs_dev_init(struct net *net)
@@ -2442,7 +2447,7 @@ static void __net_exit __ip_vs_dev_cleanup(struct net *net)
static struct pernet_operations ipvs_core_ops = {
.init = __ip_vs_init,
- .exit = __ip_vs_cleanup,
+ .exit_batch = __ip_vs_cleanup_batch,
.id = &ip_vs_net_id,
.size = sizeof(struct netns_ipvs),
};
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 07e0967..c8e652b 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1607,14 +1607,21 @@ static int ip_vs_flush(struct netns_ipvs *ipvs, bool cleanup)
/*
* Delete service by {netns} in the service table.
- * Called by __ip_vs_cleanup()
+ * Called by __ip_vs_batch_cleanup()
*/
-void ip_vs_service_net_cleanup(struct netns_ipvs *ipvs)
+void ip_vs_service_nets_cleanup(struct list_head *net_list)
{
+ struct netns_ipvs *ipvs;
+ struct net *net;
+ LIST_HEAD(list);
+
EnterFunction(2);
/* Check for "full" addressed entries */
mutex_lock(&__ip_vs_mutex);
- ip_vs_flush(ipvs, true);
+ list_for_each_entry(net, net_list, exit_list) {
+ ipvs = net_ipvs(net);
+ ip_vs_flush(ipvs, true);
+ }
mutex_unlock(&__ip_vs_mutex);
LeaveFunction(2);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Joel Fernandes @ 2019-07-13 15:36 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713144108.GD26519@linux.ibm.com>
On Sat, Jul 13, 2019 at 07:41:08AM -0700, Paul E. McKenney wrote:
> On Sat, Jul 13, 2019 at 09:30:49AM -0400, Joel Fernandes wrote:
> > On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > > > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > > > and it results in a nice cleanup.
> > > > > > > >
> > > > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > > >
> > > > > > > Hi Oleg,
> > > > > > > Slightly unrelated to the patch,
> > > > > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > > > > >
> > > > > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > > > > reflect latest changes?
> > > > > > > Also could you help understand how is a writer not able to change
> > > > > > > sem->state and count the per-cpu read counters at the same time as the
> > > > > > > comment tries to say?
> > > > > > >
> > > > > > > /*
> > > > > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > > > > * cannot both change sem->state from readers_fast and start checking
> > > > > > > * counters while we are here. So if we see !sem->state, we know that
> > > > > > > * the writer won't be checking until we're past the preempt_enable()
> > > > > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > > > > * anything we did within this RCU-sched read-size critical section.
> > > > > > > */
> > > > > > >
> > > > > > > Also,
> > > > > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > > > > series.
> > > > > >
> > > > > > Hello, Joel,
> > > > > >
> > > > > > Oleg has a set of patches updating this code that just hit mainline
> > > > > > this week. These patches get rid of the code that previously handled
> > > > > > RCU's multiple flavors. Or are you looking at current mainline and
> > > > > > me just missing your point?
> > > > > >
> > > > >
> > > > > Hi Paul,
> > > > > You are right on point. I have a bad habit of not rebasing my trees. In this
> > > > > case the feature branch of mine in concern was based on v5.1. Needless to
> > > > > say, I need to rebase my tree.
> > > > >
> > > > > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > > > > rebase just fine.
> > > > >
> > > > > The 2 options I see are:
> > > > > 1. Let us drop this patch for now and I resend it later.
> > > > > 2. I resend all patches based on Linus's master branch.
> > > >
> > > > Below is the updated patch based on Linus master branch:
> > > >
> > > > ---8<-----------------------
> > > >
> > > > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > > > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > > > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > > > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
> > > >
> > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > section. With RCU consolidating flavors and the generic helper added in
> > > > this series, this is no longer need. We can just use the generic helper
> > > > and it results in a nice cleanup.
> > > >
> > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > ---
> > > > include/linux/rcu_sync.h | 4 +---
> > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > > > index 9b83865d24f9..0027d4c8087c 100644
> > > > --- a/include/linux/rcu_sync.h
> > > > +++ b/include/linux/rcu_sync.h
> > > > @@ -31,9 +31,7 @@ struct rcu_sync {
> > > > */
> > > > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > > > {
> > > > - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > > > - !rcu_read_lock_bh_held() &&
> > > > - !rcu_read_lock_sched_held(),
> > > > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> > >
> > > I believe that replacing rcu_read_lock_sched_held() with preemptible()
> > > in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
> > > If you have not already done so, could you please give it a try?
> >
> > Hi Paul,
> > I don't think it will cause splats for !CONFIG_PREEMPT.
> >
> > Currently, rcu_read_lock_any_held() introduced in this patch returns true if
> > !preemptible(). This means that:
> >
> > The following expression above:
> > RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),...)
> >
> > Becomes:
> > RCU_LOCKDEP_WARN(preemptible(), ...)
> >
> > For, CONFIG_PREEMPT=n kernels, this means:
> > RCU_LOCKDEP_WARN(0, ...)
> >
> > Which would mean no splats. Or, did I miss the point?
>
> I suggest trying it out on a CONFIG_PREEMPT=n kernel.
Sure, will do, sorry did not try it out yet because was busy with weekend
chores but will do soon, thanks!
^ permalink raw reply
* Re: [PATCH] [net-next] cxgb4: reduce kernel stack usage in cudbg_collect_mem_region()
From: Arnd Bergmann @ 2019-07-13 15:35 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, vishal, rahul.lakkireddy, ganeshgr, Alexios Zavras,
arjun, surendra, Networking, Linux Kernel Mailing List,
clang-built-linux
In-Reply-To: <82ccdd83d2a18912bb8cf75585e751c0bd39a215.camel@perches.com>
On Sat, Jul 13, 2019 at 2:14 AM Joe Perches <joe@perches.com> wrote:
>
> On Fri, 2019-07-12 at 15:36 -0700, David Miller wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> > Date: Fri, 12 Jul 2019 11:06:33 +0200
> >
> > > The cudbg_collect_mem_region() and cudbg_read_fw_mem() both use several
> > > hundred kilobytes of kernel stack space.
>
> Several hundred 'kilo' bytes?
> I hope not.
Right, my mistake.
Arnd
^ permalink raw reply
* Re: [PATCH net] net: neigh: fix multiple neigh timer scheduling
From: Lorenzo Bianconi @ 2019-07-13 15:13 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, David Ahern, Marek Majkowski
In-Reply-To: <20190712.154225.26530675805696474.davem@davemloft.net>
>
> From: David Miller <davem@davemloft.net>
> Date: Fri, 12 Jul 2019 15:40:47 -0700 (PDT)
>
> > From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> > Date: Fri, 12 Jul 2019 19:22:51 +0200
> >
> >> Neigh timer can be scheduled multiple times from userspace adding
> >> multiple neigh entries and forcing the neigh timer scheduling passing
> >> NTF_USE in the netlink requests.
> >> This will result in a refcount leak and in the following dump stack:
> > ...
> >> Fix the issue unscheduling neigh_timer if selected entry is in 'IN_TIMER'
> >> receiving a netlink request with NTF_USE flag set
> >>
> >> Reported-by: Marek Majkowski <marek@cloudflare.com>
> >> Fixes: 0c5c2d308906 ("neigh: Allow for user space users of the neighbour table")
> >> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> >
> > Applied and queued up for -stable, thanks.
>
> Actually, reverted, you didn't test the build thoroughly as Infiniband
> fails:
>
> drivers/infiniband/core/addr.c: In function ‘dst_fetch_ha’:
> drivers/infiniband/core/addr.c:337:3: error: too few arguments to function ‘neigh_event_send’
> neigh_event_send(n, NULL);
> ^~~~~~~~~~~~~~~~
Hi Dave,
sorry for the issue. I will post a v2 fixing it
Regards,
Lorenzo
^ permalink raw reply
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Paul E. McKenney @ 2019-07-13 14:41 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713133049.GA133650@google.com>
On Sat, Jul 13, 2019 at 09:30:49AM -0400, Joel Fernandes wrote:
> On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > > and it results in a nice cleanup.
> > > > > > >
> > > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > > >
> > > > > > Hi Oleg,
> > > > > > Slightly unrelated to the patch,
> > > > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > > > >
> > > > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > > > reflect latest changes?
> > > > > > Also could you help understand how is a writer not able to change
> > > > > > sem->state and count the per-cpu read counters at the same time as the
> > > > > > comment tries to say?
> > > > > >
> > > > > > /*
> > > > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > > > * cannot both change sem->state from readers_fast and start checking
> > > > > > * counters while we are here. So if we see !sem->state, we know that
> > > > > > * the writer won't be checking until we're past the preempt_enable()
> > > > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > > > * anything we did within this RCU-sched read-size critical section.
> > > > > > */
> > > > > >
> > > > > > Also,
> > > > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > > > series.
> > > > >
> > > > > Hello, Joel,
> > > > >
> > > > > Oleg has a set of patches updating this code that just hit mainline
> > > > > this week. These patches get rid of the code that previously handled
> > > > > RCU's multiple flavors. Or are you looking at current mainline and
> > > > > me just missing your point?
> > > > >
> > > >
> > > > Hi Paul,
> > > > You are right on point. I have a bad habit of not rebasing my trees. In this
> > > > case the feature branch of mine in concern was based on v5.1. Needless to
> > > > say, I need to rebase my tree.
> > > >
> > > > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > > > rebase just fine.
> > > >
> > > > The 2 options I see are:
> > > > 1. Let us drop this patch for now and I resend it later.
> > > > 2. I resend all patches based on Linus's master branch.
> > >
> > > Below is the updated patch based on Linus master branch:
> > >
> > > ---8<-----------------------
> > >
> > > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
> > >
> > > The rcu/sync code was doing its own check whether we are in a reader
> > > section. With RCU consolidating flavors and the generic helper added in
> > > this series, this is no longer need. We can just use the generic helper
> > > and it results in a nice cleanup.
> > >
> > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > ---
> > > include/linux/rcu_sync.h | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > > index 9b83865d24f9..0027d4c8087c 100644
> > > --- a/include/linux/rcu_sync.h
> > > +++ b/include/linux/rcu_sync.h
> > > @@ -31,9 +31,7 @@ struct rcu_sync {
> > > */
> > > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > > {
> > > - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > > - !rcu_read_lock_bh_held() &&
> > > - !rcu_read_lock_sched_held(),
> > > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> >
> > I believe that replacing rcu_read_lock_sched_held() with preemptible()
> > in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
> > If you have not already done so, could you please give it a try?
>
> Hi Paul,
> I don't think it will cause splats for !CONFIG_PREEMPT.
>
> Currently, rcu_read_lock_any_held() introduced in this patch returns true if
> !preemptible(). This means that:
>
> The following expression above:
> RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),...)
>
> Becomes:
> RCU_LOCKDEP_WARN(preemptible(), ...)
>
> For, CONFIG_PREEMPT=n kernels, this means:
> RCU_LOCKDEP_WARN(0, ...)
>
> Which would mean no splats. Or, did I miss the point?
I suggest trying it out on a CONFIG_PREEMPT=n kernel.
Thanx, Paul
^ permalink raw reply
* [net-next] bonding: add documentation for peer_notif_delay
From: Vincent Bernat @ 2019-07-13 14:35 UTC (permalink / raw)
To: David Miller, j.vosburgh, vfalico, andy, netdev; +Cc: Vincent Bernat
Ability to tweak the interval between peer notifications has been
added in 07a4ddec3ce9 ("bonding: add an option to specify a delay
between peer notifications") but the documentation was not updated.
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
---
Documentation/networking/bonding.txt | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index d3e5dd26db12..e3abfbd32f71 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -706,9 +706,9 @@ num_unsol_na
unsolicited IPv6 Neighbor Advertisements) to be issued after a
failover event. As soon as the link is up on the new slave
(possibly immediately) a peer notification is sent on the
- bonding device and each VLAN sub-device. This is repeated at
- each link monitor interval (arp_interval or miimon, whichever
- is active) if the number is greater than 1.
+ bonding device and each VLAN sub-device. This is repeated at
+ the rate specified by peer_notif_delay if the number is
+ greater than 1.
The valid range is 0 - 255; the default value is 1. These options
affect only the active-backup mode. These options were added for
@@ -727,6 +727,16 @@ packets_per_slave
The valid range is 0 - 65535; the default value is 1. This option
has effect only in balance-rr mode.
+peer_notif_delay
+
+ Specify the delay, in milliseconds, between each peer
+ notification (gratuitous ARP and unsolicited IPv6 Neighbor
+ Advertisement) when they are issued after a failover event.
+ This delay should be a multiple of the link monitor interval
+ (arp_interval or miimon, whichever is active). The default
+ value is 0 which means to match the value of the link monitor
+ interval.
+
primary
A string (eth0, eth2, etc) specifying which slave is the
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Joel Fernandes @ 2019-07-13 13:30 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713082114.GA26519@linux.ibm.com>
On Sat, Jul 13, 2019 at 01:21:14AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> > On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > > this series, this is no longer need. We can just use the generic helper
> > > > > > and it results in a nice cleanup.
> > > > > >
> > > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > > >
> > > > > Hi Oleg,
> > > > > Slightly unrelated to the patch,
> > > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > > >
> > > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > > reflect latest changes?
> > > > > Also could you help understand how is a writer not able to change
> > > > > sem->state and count the per-cpu read counters at the same time as the
> > > > > comment tries to say?
> > > > >
> > > > > /*
> > > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > > * cannot both change sem->state from readers_fast and start checking
> > > > > * counters while we are here. So if we see !sem->state, we know that
> > > > > * the writer won't be checking until we're past the preempt_enable()
> > > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > > * anything we did within this RCU-sched read-size critical section.
> > > > > */
> > > > >
> > > > > Also,
> > > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > > series.
> > > >
> > > > Hello, Joel,
> > > >
> > > > Oleg has a set of patches updating this code that just hit mainline
> > > > this week. These patches get rid of the code that previously handled
> > > > RCU's multiple flavors. Or are you looking at current mainline and
> > > > me just missing your point?
> > > >
> > >
> > > Hi Paul,
> > > You are right on point. I have a bad habit of not rebasing my trees. In this
> > > case the feature branch of mine in concern was based on v5.1. Needless to
> > > say, I need to rebase my tree.
> > >
> > > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > > rebase just fine.
> > >
> > > The 2 options I see are:
> > > 1. Let us drop this patch for now and I resend it later.
> > > 2. I resend all patches based on Linus's master branch.
> >
> > Below is the updated patch based on Linus master branch:
> >
> > ---8<-----------------------
> >
> > >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> > From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > Date: Fri, 12 Jul 2019 12:13:27 -0400
> > Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
> >
> > The rcu/sync code was doing its own check whether we are in a reader
> > section. With RCU consolidating flavors and the generic helper added in
> > this series, this is no longer need. We can just use the generic helper
> > and it results in a nice cleanup.
> >
> > Cc: Oleg Nesterov <oleg@redhat.com>
> > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > ---
> > include/linux/rcu_sync.h | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > index 9b83865d24f9..0027d4c8087c 100644
> > --- a/include/linux/rcu_sync.h
> > +++ b/include/linux/rcu_sync.h
> > @@ -31,9 +31,7 @@ struct rcu_sync {
> > */
> > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > {
> > - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > - !rcu_read_lock_bh_held() &&
> > - !rcu_read_lock_sched_held(),
> > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
>
> I believe that replacing rcu_read_lock_sched_held() with preemptible()
> in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
> If you have not already done so, could you please give it a try?
Hi Paul,
I don't think it will cause splats for !CONFIG_PREEMPT.
Currently, rcu_read_lock_any_held() introduced in this patch returns true if
!preemptible(). This means that:
The following expression above:
RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),...)
Becomes:
RCU_LOCKDEP_WARN(preemptible(), ...)
For, CONFIG_PREEMPT=n kernels, this means:
RCU_LOCKDEP_WARN(0, ...)
Which would mean no splats. Or, did I miss the point?
thanks,
- Joel
^ permalink raw reply
* Re: [Patch net] net_sched: unset TCQ_F_CAN_BYPASS when adding filters
From: Eric Dumazet @ 2019-07-13 12:54 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Eric Dumazet
In-Reply-To: <20190712201749.28421-1-xiyou.wangcong@gmail.com>
On 7/12/19 10:17 PM, Cong Wang wrote:
> For qdisc's that support TC filters and set TCQ_F_CAN_BYPASS,
> notably fq_codel, it makes no sense to let packets bypass the TC
> filters we setup in any scenario, otherwise our packets steering
> policy could not be enforced.
>
> This can be easily reproduced with the following script:
>
> ip li add dev dummy0 type dummy
> ifconfig dummy0 up
> tc qd add dev dummy0 root fq_codel
> tc filter add dev dummy0 parent 8001: protocol arp basic action mirred egress redirect dev lo
> tc filter add dev dummy0 parent 8001: protocol ip basic action mirred egress redirect dev lo
> ping -I dummy0 192.168.112.1
>
> Without this patch, packets are sent directly to dummy0 without
> hitting any of the filters. With this patch, packets are redirected
> to loopback as expected.
>
> This fix is not perfect, it only unsets the flag but does not set it back
> because we have to save the information somewhere in the qdisc if we
> really want that.
>
> Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM")
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/sched/cls_api.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 638c1bc1ea1b..5c800b0c810b 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -2152,6 +2152,7 @@ static int tc_new_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
> tfilter_notify(net, skb, n, tp, block, q, parent, fh,
> RTM_NEWTFILTER, false, rtnl_held);
> tfilter_put(tp, fh);
> + q->flags &= ~TCQ_F_CAN_BYPASS;
> }
>
> errout:
>
Strange, because sfq and fq_codel are roughly the same for TCQ_F_CAN_BYPASS handling.
Why is fq_codel_bind() not effective ?
If not effective, sfq had the same issue, so the Fixes: tag needs to be refined,
maybe to commit 23624935e0c4 net_sched: TCQ_F_CAN_BYPASS generalization
^ permalink raw reply
* Re: [RFC PATCH net-next 3/6] net: dsa: Pass tc-taprio offload to drivers
From: Vladimir Oltean @ 2019-07-13 12:48 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Florian Fainelli, Vivien Didelot, Andrew Lunn, David S. Miller,
Vinicius Costa Gomes, vedang.patel, Richard Cochran, weifeng.voon,
jiri, m-karicheri2, Jose.Abreu, netdev
In-Reply-To: <20190708112307.GA7480@apalos>
Hi Ilias,
On Mon, 8 Jul 2019 at 14:23, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Vladimir,
>
> > tc-taprio is a qdisc based on the enhancements for scheduled traffic
> > specified in IEEE 802.1Qbv (later merged in 802.1Q). This qdisc has
> > a software implementation and an optional offload through which
> > compatible Ethernet ports may configure their egress 802.1Qbv
> > schedulers.
> >
> > Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> > ---
> > include/net/dsa.h | 3 +++
> > net/dsa/slave.c | 14 ++++++++++++++
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/include/net/dsa.h b/include/net/dsa.h
> > index 1e8650fa8acc..e7ee6ac8ce6b 100644
> > --- a/include/net/dsa.h
> > +++ b/include/net/dsa.h
> > @@ -152,6 +152,7 @@ struct dsa_mall_tc_entry {
> > };
> > };
> >
> > +struct tc_taprio_qopt_offload;
> >
> > struct dsa_port {
> > /* A CPU port is physically connected to a master device.
> > @@ -516,6 +517,8 @@ struct dsa_switch_ops {
> > bool ingress);
> > void (*port_mirror_del)(struct dsa_switch *ds, int port,
> > struct dsa_mall_mirror_tc_entry *mirror);
> > + int (*port_setup_taprio)(struct dsa_switch *ds, int port,
> > + struct tc_taprio_qopt_offload *qopt);
>
> Is there any way to make this more generic? 802.1Qbv are not the only hardware
> schedulers. CBS and ETF are examples that first come to mind. Maybe having
> something more generic than tc_taprio_qopt_offload as an option could host
> future schedulers?
>
Good point. I'll see what I can do to make DSA more qdisc-agnostic
when I gather enough feedback to mandate a v2.
> >
> > /*
> > * Cross-chip operations
> > diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> > index 99673f6b07f6..2bae33788708 100644
> > --- a/net/dsa/slave.c
> > +++ b/net/dsa/slave.c
> > @@ -965,12 +965,26 @@ static int dsa_slave_setup_tc_block(struct net_device *dev,
> > }
> > }
> >
> > +static int dsa_slave_setup_tc_taprio(struct net_device *dev,
> > + struct tc_taprio_qopt_offload *f)
> > +{
> > + struct dsa_port *dp = dsa_slave_to_port(dev);
> > + struct dsa_switch *ds = dp->ds;
> > +
> > + if (!ds->ops->port_setup_taprio)
> > + return -EOPNOTSUPP;
> > +
> > + return ds->ops->port_setup_taprio(ds, dp->index, f);
> > +}
> > +
> > static int dsa_slave_setup_tc(struct net_device *dev, enum tc_setup_type type,
> > void *type_data)
> > {
> > switch (type) {
> > case TC_SETUP_BLOCK:
> > return dsa_slave_setup_tc_block(dev, type_data);
> > + case TC_SETUP_QDISC_TAPRIO:
> > + return dsa_slave_setup_tc_taprio(dev, type_data);
> > default:
> > return -EOPNOTSUPP;
> > }
> > --
> > 2.17.1
> >
> Thanks
> /Ilias
Thanks,
-Vladimir
^ permalink raw reply
* [PATCH net] r8169: fix issue with confused RX unit after PHY power-down on RTL8411b
From: Heiner Kallweit @ 2019-07-13 11:55 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Ionut Radu
On RTL8411b the RX unit gets confused if the PHY is powered-down.
This was reported in [0] and confirmed by Realtek. Realtek provided
a sequence to fix the RX unit after PHY wakeup.
The issue itself seems to have been there longer, the Fixes tag
refers to where the fix applies properly.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1692075
Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support")
Tested-by: Ionut Radu <ionut.radu@gmail.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
This patch is for versions up to 5.2. On versions before 5.2 there
may be little fuzz when applying because rtl_ephy_init used to have
one parameter more.
---
drivers/net/ethernet/realtek/r8169.c | 137 +++++++++++++++++++++++++++
1 file changed, 137 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index d06a61f00..96637fcbe 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5157,6 +5157,143 @@ static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
/* disable aspm and clock request before access ephy */
rtl_hw_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8411_2);
+
+ /* The following Realtek-provided magic fixes an issue with the RX unit
+ * getting confused after the PHY having been powered-down.
+ */
+ r8168_mac_ocp_write(tp, 0xFC28, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC2A, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC2C, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC2E, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC30, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC32, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC34, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC36, 0x0000);
+ mdelay(3);
+ r8168_mac_ocp_write(tp, 0xFC26, 0x0000);
+
+ r8168_mac_ocp_write(tp, 0xF800, 0xE008);
+ r8168_mac_ocp_write(tp, 0xF802, 0xE00A);
+ r8168_mac_ocp_write(tp, 0xF804, 0xE00C);
+ r8168_mac_ocp_write(tp, 0xF806, 0xE00E);
+ r8168_mac_ocp_write(tp, 0xF808, 0xE027);
+ r8168_mac_ocp_write(tp, 0xF80A, 0xE04F);
+ r8168_mac_ocp_write(tp, 0xF80C, 0xE05E);
+ r8168_mac_ocp_write(tp, 0xF80E, 0xE065);
+ r8168_mac_ocp_write(tp, 0xF810, 0xC602);
+ r8168_mac_ocp_write(tp, 0xF812, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF814, 0x0000);
+ r8168_mac_ocp_write(tp, 0xF816, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF818, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF81A, 0x074C);
+ r8168_mac_ocp_write(tp, 0xF81C, 0xC302);
+ r8168_mac_ocp_write(tp, 0xF81E, 0xBB00);
+ r8168_mac_ocp_write(tp, 0xF820, 0x080A);
+ r8168_mac_ocp_write(tp, 0xF822, 0x6420);
+ r8168_mac_ocp_write(tp, 0xF824, 0x48C2);
+ r8168_mac_ocp_write(tp, 0xF826, 0x8C20);
+ r8168_mac_ocp_write(tp, 0xF828, 0xC516);
+ r8168_mac_ocp_write(tp, 0xF82A, 0x64A4);
+ r8168_mac_ocp_write(tp, 0xF82C, 0x49C0);
+ r8168_mac_ocp_write(tp, 0xF82E, 0xF009);
+ r8168_mac_ocp_write(tp, 0xF830, 0x74A2);
+ r8168_mac_ocp_write(tp, 0xF832, 0x8CA5);
+ r8168_mac_ocp_write(tp, 0xF834, 0x74A0);
+ r8168_mac_ocp_write(tp, 0xF836, 0xC50E);
+ r8168_mac_ocp_write(tp, 0xF838, 0x9CA2);
+ r8168_mac_ocp_write(tp, 0xF83A, 0x1C11);
+ r8168_mac_ocp_write(tp, 0xF83C, 0x9CA0);
+ r8168_mac_ocp_write(tp, 0xF83E, 0xE006);
+ r8168_mac_ocp_write(tp, 0xF840, 0x74F8);
+ r8168_mac_ocp_write(tp, 0xF842, 0x48C4);
+ r8168_mac_ocp_write(tp, 0xF844, 0x8CF8);
+ r8168_mac_ocp_write(tp, 0xF846, 0xC404);
+ r8168_mac_ocp_write(tp, 0xF848, 0xBC00);
+ r8168_mac_ocp_write(tp, 0xF84A, 0xC403);
+ r8168_mac_ocp_write(tp, 0xF84C, 0xBC00);
+ r8168_mac_ocp_write(tp, 0xF84E, 0x0BF2);
+ r8168_mac_ocp_write(tp, 0xF850, 0x0C0A);
+ r8168_mac_ocp_write(tp, 0xF852, 0xE434);
+ r8168_mac_ocp_write(tp, 0xF854, 0xD3C0);
+ r8168_mac_ocp_write(tp, 0xF856, 0x49D9);
+ r8168_mac_ocp_write(tp, 0xF858, 0xF01F);
+ r8168_mac_ocp_write(tp, 0xF85A, 0xC526);
+ r8168_mac_ocp_write(tp, 0xF85C, 0x64A5);
+ r8168_mac_ocp_write(tp, 0xF85E, 0x1400);
+ r8168_mac_ocp_write(tp, 0xF860, 0xF007);
+ r8168_mac_ocp_write(tp, 0xF862, 0x0C01);
+ r8168_mac_ocp_write(tp, 0xF864, 0x8CA5);
+ r8168_mac_ocp_write(tp, 0xF866, 0x1C15);
+ r8168_mac_ocp_write(tp, 0xF868, 0xC51B);
+ r8168_mac_ocp_write(tp, 0xF86A, 0x9CA0);
+ r8168_mac_ocp_write(tp, 0xF86C, 0xE013);
+ r8168_mac_ocp_write(tp, 0xF86E, 0xC519);
+ r8168_mac_ocp_write(tp, 0xF870, 0x74A0);
+ r8168_mac_ocp_write(tp, 0xF872, 0x48C4);
+ r8168_mac_ocp_write(tp, 0xF874, 0x8CA0);
+ r8168_mac_ocp_write(tp, 0xF876, 0xC516);
+ r8168_mac_ocp_write(tp, 0xF878, 0x74A4);
+ r8168_mac_ocp_write(tp, 0xF87A, 0x48C8);
+ r8168_mac_ocp_write(tp, 0xF87C, 0x48CA);
+ r8168_mac_ocp_write(tp, 0xF87E, 0x9CA4);
+ r8168_mac_ocp_write(tp, 0xF880, 0xC512);
+ r8168_mac_ocp_write(tp, 0xF882, 0x1B00);
+ r8168_mac_ocp_write(tp, 0xF884, 0x9BA0);
+ r8168_mac_ocp_write(tp, 0xF886, 0x1B1C);
+ r8168_mac_ocp_write(tp, 0xF888, 0x483F);
+ r8168_mac_ocp_write(tp, 0xF88A, 0x9BA2);
+ r8168_mac_ocp_write(tp, 0xF88C, 0x1B04);
+ r8168_mac_ocp_write(tp, 0xF88E, 0xC508);
+ r8168_mac_ocp_write(tp, 0xF890, 0x9BA0);
+ r8168_mac_ocp_write(tp, 0xF892, 0xC505);
+ r8168_mac_ocp_write(tp, 0xF894, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF896, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF898, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF89A, 0x0300);
+ r8168_mac_ocp_write(tp, 0xF89C, 0x051E);
+ r8168_mac_ocp_write(tp, 0xF89E, 0xE434);
+ r8168_mac_ocp_write(tp, 0xF8A0, 0xE018);
+ r8168_mac_ocp_write(tp, 0xF8A2, 0xE092);
+ r8168_mac_ocp_write(tp, 0xF8A4, 0xDE20);
+ r8168_mac_ocp_write(tp, 0xF8A6, 0xD3C0);
+ r8168_mac_ocp_write(tp, 0xF8A8, 0xC50F);
+ r8168_mac_ocp_write(tp, 0xF8AA, 0x76A4);
+ r8168_mac_ocp_write(tp, 0xF8AC, 0x49E3);
+ r8168_mac_ocp_write(tp, 0xF8AE, 0xF007);
+ r8168_mac_ocp_write(tp, 0xF8B0, 0x49C0);
+ r8168_mac_ocp_write(tp, 0xF8B2, 0xF103);
+ r8168_mac_ocp_write(tp, 0xF8B4, 0xC607);
+ r8168_mac_ocp_write(tp, 0xF8B6, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF8B8, 0xC606);
+ r8168_mac_ocp_write(tp, 0xF8BA, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF8BC, 0xC602);
+ r8168_mac_ocp_write(tp, 0xF8BE, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF8C0, 0x0C4C);
+ r8168_mac_ocp_write(tp, 0xF8C2, 0x0C28);
+ r8168_mac_ocp_write(tp, 0xF8C4, 0x0C2C);
+ r8168_mac_ocp_write(tp, 0xF8C6, 0xDC00);
+ r8168_mac_ocp_write(tp, 0xF8C8, 0xC707);
+ r8168_mac_ocp_write(tp, 0xF8CA, 0x1D00);
+ r8168_mac_ocp_write(tp, 0xF8CC, 0x8DE2);
+ r8168_mac_ocp_write(tp, 0xF8CE, 0x48C1);
+ r8168_mac_ocp_write(tp, 0xF8D0, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF8D2, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF8D4, 0x00AA);
+ r8168_mac_ocp_write(tp, 0xF8D6, 0xE0C0);
+ r8168_mac_ocp_write(tp, 0xF8D8, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF8DA, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF8DC, 0x0132);
+
+ r8168_mac_ocp_write(tp, 0xFC26, 0x8000);
+
+ r8168_mac_ocp_write(tp, 0xFC2A, 0x0743);
+ r8168_mac_ocp_write(tp, 0xFC2C, 0x0801);
+ r8168_mac_ocp_write(tp, 0xFC2E, 0x0BE9);
+ r8168_mac_ocp_write(tp, 0xFC30, 0x02FD);
+ r8168_mac_ocp_write(tp, 0xFC32, 0x0C25);
+ r8168_mac_ocp_write(tp, 0xFC34, 0x00A9);
+ r8168_mac_ocp_write(tp, 0xFC36, 0x012D);
+
rtl_hw_aspm_clkreq_enable(tp, true);
}
--
2.22.0
^ permalink raw reply related
* [PATCH net] r8169: fix issue with confused RX unit after PHY power-down on RTL8411b
From: Heiner Kallweit @ 2019-07-13 11:45 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Ionut Radu
On RTL8411b the RX unit gets confused if the PHY is powered-down.
This was reported in [0] and confirmed by Realtek. Realtek provided
a sequence to fix the RX unit after PHY wakeup.
The issue itself seems to have been there longer, the Fixes tag
refers to where the fix applies properly.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1692075
Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support")
Tested-by: Ionut Radu <ionut.radu@gmail.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
This patch doesn't apply on versions up to 5.2 due to the renaming
of r8169.c to r8169_main.c. I will provide a separate patch for these
versions.
---
drivers/net/ethernet/realtek/r8169_main.c | 137 ++++++++++++++++++++++
1 file changed, 137 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index efef5453b..0637c6752 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4667,6 +4667,143 @@ static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
/* disable aspm and clock request before access ephy */
rtl_hw_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8411_2);
+
+ /* The following Realtek-provided magic fixes an issue with the RX unit
+ * getting confused after the PHY having been powered-down.
+ */
+ r8168_mac_ocp_write(tp, 0xFC28, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC2A, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC2C, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC2E, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC30, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC32, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC34, 0x0000);
+ r8168_mac_ocp_write(tp, 0xFC36, 0x0000);
+ mdelay(3);
+ r8168_mac_ocp_write(tp, 0xFC26, 0x0000);
+
+ r8168_mac_ocp_write(tp, 0xF800, 0xE008);
+ r8168_mac_ocp_write(tp, 0xF802, 0xE00A);
+ r8168_mac_ocp_write(tp, 0xF804, 0xE00C);
+ r8168_mac_ocp_write(tp, 0xF806, 0xE00E);
+ r8168_mac_ocp_write(tp, 0xF808, 0xE027);
+ r8168_mac_ocp_write(tp, 0xF80A, 0xE04F);
+ r8168_mac_ocp_write(tp, 0xF80C, 0xE05E);
+ r8168_mac_ocp_write(tp, 0xF80E, 0xE065);
+ r8168_mac_ocp_write(tp, 0xF810, 0xC602);
+ r8168_mac_ocp_write(tp, 0xF812, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF814, 0x0000);
+ r8168_mac_ocp_write(tp, 0xF816, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF818, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF81A, 0x074C);
+ r8168_mac_ocp_write(tp, 0xF81C, 0xC302);
+ r8168_mac_ocp_write(tp, 0xF81E, 0xBB00);
+ r8168_mac_ocp_write(tp, 0xF820, 0x080A);
+ r8168_mac_ocp_write(tp, 0xF822, 0x6420);
+ r8168_mac_ocp_write(tp, 0xF824, 0x48C2);
+ r8168_mac_ocp_write(tp, 0xF826, 0x8C20);
+ r8168_mac_ocp_write(tp, 0xF828, 0xC516);
+ r8168_mac_ocp_write(tp, 0xF82A, 0x64A4);
+ r8168_mac_ocp_write(tp, 0xF82C, 0x49C0);
+ r8168_mac_ocp_write(tp, 0xF82E, 0xF009);
+ r8168_mac_ocp_write(tp, 0xF830, 0x74A2);
+ r8168_mac_ocp_write(tp, 0xF832, 0x8CA5);
+ r8168_mac_ocp_write(tp, 0xF834, 0x74A0);
+ r8168_mac_ocp_write(tp, 0xF836, 0xC50E);
+ r8168_mac_ocp_write(tp, 0xF838, 0x9CA2);
+ r8168_mac_ocp_write(tp, 0xF83A, 0x1C11);
+ r8168_mac_ocp_write(tp, 0xF83C, 0x9CA0);
+ r8168_mac_ocp_write(tp, 0xF83E, 0xE006);
+ r8168_mac_ocp_write(tp, 0xF840, 0x74F8);
+ r8168_mac_ocp_write(tp, 0xF842, 0x48C4);
+ r8168_mac_ocp_write(tp, 0xF844, 0x8CF8);
+ r8168_mac_ocp_write(tp, 0xF846, 0xC404);
+ r8168_mac_ocp_write(tp, 0xF848, 0xBC00);
+ r8168_mac_ocp_write(tp, 0xF84A, 0xC403);
+ r8168_mac_ocp_write(tp, 0xF84C, 0xBC00);
+ r8168_mac_ocp_write(tp, 0xF84E, 0x0BF2);
+ r8168_mac_ocp_write(tp, 0xF850, 0x0C0A);
+ r8168_mac_ocp_write(tp, 0xF852, 0xE434);
+ r8168_mac_ocp_write(tp, 0xF854, 0xD3C0);
+ r8168_mac_ocp_write(tp, 0xF856, 0x49D9);
+ r8168_mac_ocp_write(tp, 0xF858, 0xF01F);
+ r8168_mac_ocp_write(tp, 0xF85A, 0xC526);
+ r8168_mac_ocp_write(tp, 0xF85C, 0x64A5);
+ r8168_mac_ocp_write(tp, 0xF85E, 0x1400);
+ r8168_mac_ocp_write(tp, 0xF860, 0xF007);
+ r8168_mac_ocp_write(tp, 0xF862, 0x0C01);
+ r8168_mac_ocp_write(tp, 0xF864, 0x8CA5);
+ r8168_mac_ocp_write(tp, 0xF866, 0x1C15);
+ r8168_mac_ocp_write(tp, 0xF868, 0xC51B);
+ r8168_mac_ocp_write(tp, 0xF86A, 0x9CA0);
+ r8168_mac_ocp_write(tp, 0xF86C, 0xE013);
+ r8168_mac_ocp_write(tp, 0xF86E, 0xC519);
+ r8168_mac_ocp_write(tp, 0xF870, 0x74A0);
+ r8168_mac_ocp_write(tp, 0xF872, 0x48C4);
+ r8168_mac_ocp_write(tp, 0xF874, 0x8CA0);
+ r8168_mac_ocp_write(tp, 0xF876, 0xC516);
+ r8168_mac_ocp_write(tp, 0xF878, 0x74A4);
+ r8168_mac_ocp_write(tp, 0xF87A, 0x48C8);
+ r8168_mac_ocp_write(tp, 0xF87C, 0x48CA);
+ r8168_mac_ocp_write(tp, 0xF87E, 0x9CA4);
+ r8168_mac_ocp_write(tp, 0xF880, 0xC512);
+ r8168_mac_ocp_write(tp, 0xF882, 0x1B00);
+ r8168_mac_ocp_write(tp, 0xF884, 0x9BA0);
+ r8168_mac_ocp_write(tp, 0xF886, 0x1B1C);
+ r8168_mac_ocp_write(tp, 0xF888, 0x483F);
+ r8168_mac_ocp_write(tp, 0xF88A, 0x9BA2);
+ r8168_mac_ocp_write(tp, 0xF88C, 0x1B04);
+ r8168_mac_ocp_write(tp, 0xF88E, 0xC508);
+ r8168_mac_ocp_write(tp, 0xF890, 0x9BA0);
+ r8168_mac_ocp_write(tp, 0xF892, 0xC505);
+ r8168_mac_ocp_write(tp, 0xF894, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF896, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF898, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF89A, 0x0300);
+ r8168_mac_ocp_write(tp, 0xF89C, 0x051E);
+ r8168_mac_ocp_write(tp, 0xF89E, 0xE434);
+ r8168_mac_ocp_write(tp, 0xF8A0, 0xE018);
+ r8168_mac_ocp_write(tp, 0xF8A2, 0xE092);
+ r8168_mac_ocp_write(tp, 0xF8A4, 0xDE20);
+ r8168_mac_ocp_write(tp, 0xF8A6, 0xD3C0);
+ r8168_mac_ocp_write(tp, 0xF8A8, 0xC50F);
+ r8168_mac_ocp_write(tp, 0xF8AA, 0x76A4);
+ r8168_mac_ocp_write(tp, 0xF8AC, 0x49E3);
+ r8168_mac_ocp_write(tp, 0xF8AE, 0xF007);
+ r8168_mac_ocp_write(tp, 0xF8B0, 0x49C0);
+ r8168_mac_ocp_write(tp, 0xF8B2, 0xF103);
+ r8168_mac_ocp_write(tp, 0xF8B4, 0xC607);
+ r8168_mac_ocp_write(tp, 0xF8B6, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF8B8, 0xC606);
+ r8168_mac_ocp_write(tp, 0xF8BA, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF8BC, 0xC602);
+ r8168_mac_ocp_write(tp, 0xF8BE, 0xBE00);
+ r8168_mac_ocp_write(tp, 0xF8C0, 0x0C4C);
+ r8168_mac_ocp_write(tp, 0xF8C2, 0x0C28);
+ r8168_mac_ocp_write(tp, 0xF8C4, 0x0C2C);
+ r8168_mac_ocp_write(tp, 0xF8C6, 0xDC00);
+ r8168_mac_ocp_write(tp, 0xF8C8, 0xC707);
+ r8168_mac_ocp_write(tp, 0xF8CA, 0x1D00);
+ r8168_mac_ocp_write(tp, 0xF8CC, 0x8DE2);
+ r8168_mac_ocp_write(tp, 0xF8CE, 0x48C1);
+ r8168_mac_ocp_write(tp, 0xF8D0, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF8D2, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF8D4, 0x00AA);
+ r8168_mac_ocp_write(tp, 0xF8D6, 0xE0C0);
+ r8168_mac_ocp_write(tp, 0xF8D8, 0xC502);
+ r8168_mac_ocp_write(tp, 0xF8DA, 0xBD00);
+ r8168_mac_ocp_write(tp, 0xF8DC, 0x0132);
+
+ r8168_mac_ocp_write(tp, 0xFC26, 0x8000);
+
+ r8168_mac_ocp_write(tp, 0xFC2A, 0x0743);
+ r8168_mac_ocp_write(tp, 0xFC2C, 0x0801);
+ r8168_mac_ocp_write(tp, 0xFC2E, 0x0BE9);
+ r8168_mac_ocp_write(tp, 0xFC30, 0x02FD);
+ r8168_mac_ocp_write(tp, 0xFC32, 0x0C25);
+ r8168_mac_ocp_write(tp, 0xFC34, 0x00A9);
+ r8168_mac_ocp_write(tp, 0xFC36, 0x012D);
+
rtl_hw_aspm_clkreq_enable(tp, true);
}
--
2.22.0
^ permalink raw reply related
* [PATCH iproute2] tc: util: constrain percentage in 0-100 interval
From: Andrea Claudi @ 2019-07-13 9:44 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern
parse_percent() currently allows to specify negative percentages
or value above 100%. However this does not seems to make sense,
as the function is used for probabilities or bandiwidth rates.
Moreover, using negative values leads to erroneous results
(using Bernoulli loss model as example):
$ ip link add test type dummy
$ ip link set test up
$ tc qdisc add dev test root netem loss gemodel -10% limit 10
$ tc qdisc show dev test
qdisc netem 800c: root refcnt 2 limit 10 loss gemodel p 90% r 10% 1-h 100% 1-k 0%
Using values above 100% we have instead:
$ ip link add test type dummy
$ ip link set test up
$ tc qdisc add dev test root netem loss gemodel 140% limit 10
$ tc qdisc show dev test
qdisc netem 800f: root refcnt 2 limit 10 loss gemodel p 40% r 60% 1-h 100% 1-k 0%
This commit changes parse_percent() with a check to ensure
percentage values stay between 1.0 and 0.0.
parse_percent_rate() function, which already employs a similar
check, is adjusted accordingly.
With this check in place, we have:
$ ip link add test type dummy
$ ip link set test up
$ tc qdisc add dev test root netem loss gemodel -10% limit 10
Illegal "loss gemodel p"
Fixes: 927e3cfb52b58 ("tc: B.W limits can now be specified in %.")
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
---
tc/tc_util.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index 53d15e08e9734..b90d256c33a4a 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -198,7 +198,7 @@ int parse_percent(double *val, const char *str)
char *p;
*val = strtod(str, &p) / 100.;
- if (*val == HUGE_VALF || *val == HUGE_VALL)
+ if (*val > 1.0 || *val < 0.0)
return 1;
if (*p && strcmp(p, "%"))
return -1;
@@ -226,16 +226,16 @@ static int parse_percent_rate(char *rate, size_t len,
if (ret != 1)
goto malf;
- if (parse_percent(&perc, str_perc))
+ ret = parse_percent(&perc, str_perc);
+ if (ret == 1) {
+ fprintf(stderr, "Invalid rate specified; should be between [0,100]%% but is %s\n", str);
+ goto err;
+ } else if (ret == -1) {
goto malf;
+ }
free(str_perc);
- if (perc > 1.0 || perc < 0.0) {
- fprintf(stderr, "Invalid rate specified; should be between [0,100]%% but is %s\n", str);
- return -1;
- }
-
rate_bit = perc * dev_mbit * 1000 * 1000;
ret = snprintf(rate, len, "%lf", rate_bit);
@@ -247,8 +247,9 @@ static int parse_percent_rate(char *rate, size_t len,
return 0;
malf:
- free(str_perc);
fprintf(stderr, "Specified rate value could not be read or is malformed\n");
+err:
+ free(str_perc);
return -1;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Paul E. McKenney @ 2019-07-13 8:21 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Oleg Nesterov, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Jonathan Corbet, Josh Triplett, keescook,
kernel-hardening, kernel-team, Lai Jiangshan, Len Brown,
linux-acpi, linux-doc, linux-pci, linux-pm, Mathieu Desnoyers,
neilb, netdev, Pavel Machek, peterz, Rafael J. Wysocki,
Rasmus Villemoes, rcu, Steven Rostedt, Tejun Heo, Thomas Gleixner,
will, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190713031008.GA248225@google.com>
On Fri, Jul 12, 2019 at 11:10:08PM -0400, Joel Fernandes wrote:
> On Fri, Jul 12, 2019 at 11:01:50PM -0400, Joel Fernandes wrote:
> > On Fri, Jul 12, 2019 at 04:32:06PM -0700, Paul E. McKenney wrote:
> > > On Fri, Jul 12, 2019 at 05:35:59PM -0400, Joel Fernandes wrote:
> > > > On Fri, Jul 12, 2019 at 01:00:18PM -0400, Joel Fernandes (Google) wrote:
> > > > > The rcu/sync code was doing its own check whether we are in a reader
> > > > > section. With RCU consolidating flavors and the generic helper added in
> > > > > this series, this is no longer need. We can just use the generic helper
> > > > > and it results in a nice cleanup.
> > > > >
> > > > > Cc: Oleg Nesterov <oleg@redhat.com>
> > > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > >
> > > > Hi Oleg,
> > > > Slightly unrelated to the patch,
> > > > I tried hard to understand this comment below in percpu_down_read() but no dice.
> > > >
> > > > I do understand how rcu sync and percpu rwsem works, however the comment
> > > > below didn't make much sense to me. For one, there's no readers_fast anymore
> > > > so I did not follow what readers_fast means. Could the comment be updated to
> > > > reflect latest changes?
> > > > Also could you help understand how is a writer not able to change
> > > > sem->state and count the per-cpu read counters at the same time as the
> > > > comment tries to say?
> > > >
> > > > /*
> > > > * We are in an RCU-sched read-side critical section, so the writer
> > > > * cannot both change sem->state from readers_fast and start checking
> > > > * counters while we are here. So if we see !sem->state, we know that
> > > > * the writer won't be checking until we're past the preempt_enable()
> > > > * and that once the synchronize_rcu() is done, the writer will see
> > > > * anything we did within this RCU-sched read-size critical section.
> > > > */
> > > >
> > > > Also,
> > > > I guess we could get rid of all of the gp_ops struct stuff now that since all
> > > > the callbacks are the same now. I will post that as a follow-up patch to this
> > > > series.
> > >
> > > Hello, Joel,
> > >
> > > Oleg has a set of patches updating this code that just hit mainline
> > > this week. These patches get rid of the code that previously handled
> > > RCU's multiple flavors. Or are you looking at current mainline and
> > > me just missing your point?
> > >
> >
> > Hi Paul,
> > You are right on point. I have a bad habit of not rebasing my trees. In this
> > case the feature branch of mine in concern was based on v5.1. Needless to
> > say, I need to rebase my tree.
> >
> > Yes, this sync clean up patch does conflict when I rebase, but other patches
> > rebase just fine.
> >
> > The 2 options I see are:
> > 1. Let us drop this patch for now and I resend it later.
> > 2. I resend all patches based on Linus's master branch.
>
> Below is the updated patch based on Linus master branch:
>
> ---8<-----------------------
>
> >From 5f40c9a07fcf3d6dafc2189599d0ba9443097d0f Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> Date: Fri, 12 Jul 2019 12:13:27 -0400
> Subject: [PATCH v2.1 3/9] rcu/sync: Remove custom check for reader-section
>
> The rcu/sync code was doing its own check whether we are in a reader
> section. With RCU consolidating flavors and the generic helper added in
> this series, this is no longer need. We can just use the generic helper
> and it results in a nice cleanup.
>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> include/linux/rcu_sync.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> index 9b83865d24f9..0027d4c8087c 100644
> --- a/include/linux/rcu_sync.h
> +++ b/include/linux/rcu_sync.h
> @@ -31,9 +31,7 @@ struct rcu_sync {
> */
> static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> {
> - RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> - !rcu_read_lock_bh_held() &&
> - !rcu_read_lock_sched_held(),
> + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
I believe that replacing rcu_read_lock_sched_held() with preemptible()
in a CONFIG_PREEMPT=n kernel will give you false-positive splats here.
If you have not already done so, could you please give it a try?
Thanx, Paul
> "suspicious rcu_sync_is_idle() usage");
> return !READ_ONCE(rsp->gp_state); /* GP_IDLE */
> }
> --
> 2.22.0.510.g264f2c817a-goog
>
^ permalink raw reply
* Re: [PATCH net-next 00/11] Add drop monitor for offloaded data paths
From: Toke Høiland-Jørgensen @ 2019-07-13 8:07 UTC (permalink / raw)
To: Neil Horman
Cc: Ido Schimmel, David Miller, netdev, jiri, mlxsw, dsahern, roopa,
nikolay, andy, pablo, jakub.kicinski, pieter.jansenvanvuuren,
andrew, f.fainelli, vivien.didelot, idosch
In-Reply-To: <20190713004011.GA24036@localhost.localdomain>
>Neil Horman <nhorman@tuxdriver.com> writes:
> On Fri, Jul 12, 2019 at 02:33:29PM +0200, Toke Høiland-Jørgensen wrote:
>> Neil Horman <nhorman@tuxdriver.com> writes:
>>
>> > On Fri, Jul 12, 2019 at 11:27:55AM +0200, Toke Høiland-Jørgensen wrote:
>> >> Neil Horman <nhorman@tuxdriver.com> writes:
>> >>
>> >> > On Thu, Jul 11, 2019 at 03:39:09PM +0300, Ido Schimmel wrote:
>> >> >> On Sun, Jul 07, 2019 at 12:45:41PM -0700, David Miller wrote:
>> >> >> > From: Ido Schimmel <idosch@idosch.org>
>> >> >> > Date: Sun, 7 Jul 2019 10:58:17 +0300
>> >> >> >
>> >> >> > > Users have several ways to debug the kernel and understand why a packet
>> >> >> > > was dropped. For example, using "drop monitor" and "perf". Both
>> >> >> > > utilities trace kfree_skb(), which is the function called when a packet
>> >> >> > > is freed as part of a failure. The information provided by these tools
>> >> >> > > is invaluable when trying to understand the cause of a packet loss.
>> >> >> > >
>> >> >> > > In recent years, large portions of the kernel data path were offloaded
>> >> >> > > to capable devices. Today, it is possible to perform L2 and L3
>> >> >> > > forwarding in hardware, as well as tunneling (IP-in-IP and VXLAN).
>> >> >> > > Different TC classifiers and actions are also offloaded to capable
>> >> >> > > devices, at both ingress and egress.
>> >> >> > >
>> >> >> > > However, when the data path is offloaded it is not possible to achieve
>> >> >> > > the same level of introspection as tools such "perf" and "drop monitor"
>> >> >> > > become irrelevant.
>> >> >> > >
>> >> >> > > This patchset aims to solve this by allowing users to monitor packets
>> >> >> > > that the underlying device decided to drop along with relevant metadata
>> >> >> > > such as the drop reason and ingress port.
>> >> >> >
>> >> >> > We are now going to have 5 or so ways to capture packets passing through
>> >> >> > the system, this is nonsense.
>> >> >> >
>> >> >> > AF_PACKET, kfree_skb drop monitor, perf, XDP perf events, and now this
>> >> >> > devlink thing.
>> >> >> >
>> >> >> > This is insanity, too many ways to do the same thing and therefore the
>> >> >> > worst possible user experience.
>> >> >> >
>> >> >> > Pick _ONE_ method to trap packets and forward normal kfree_skb events,
>> >> >> > XDP perf events, and these taps there too.
>> >> >> >
>> >> >> > I mean really, think about it from the average user's perspective. To
>> >> >> > see all drops/pkts I have to attach a kfree_skb tracepoint, and not just
>> >> >> > listen on devlink but configure a special tap thing beforehand and then
>> >> >> > if someone is using XDP I gotta setup another perf event buffer capture
>> >> >> > thing too.
>> >> >>
>> >> >> Dave,
>> >> >>
>> >> >> Before I start working on v2, I would like to get your feedback on the
>> >> >> high level plan. Also adding Neil who is the maintainer of drop_monitor
>> >> >> (and counterpart DropWatch tool [1]).
>> >> >>
>> >> >> IIUC, the problem you point out is that users need to use different
>> >> >> tools to monitor packet drops based on where these drops occur
>> >> >> (SW/HW/XDP).
>> >> >>
>> >> >> Therefore, my plan is to extend the existing drop_monitor netlink
>> >> >> channel to also cover HW drops. I will add a new message type and a new
>> >> >> multicast group for HW drops and encode in the message what is currently
>> >> >> encoded in the devlink events.
>> >> >>
>> >> > A few things here:
>> >> > IIRC we don't announce individual hardware drops, drivers record them in
>> >> > internal structures, and they are retrieved on demand via ethtool calls, so you
>> >> > will either need to include some polling (probably not a very performant idea),
>> >> > or some sort of flagging mechanism to indicate that on the next message sent to
>> >> > user space you should go retrieve hw stats from a given interface. I certainly
>> >> > wouldn't mind seeing this happen, but its more work than just adding a new
>> >> > netlink message.
>> >> >
>> >> > Also, regarding XDP drops, we wont see them if the xdp program is offloaded to
>> >> > hardware (you'll need your hw drop gathering mechanism for that), but for xdp
>> >> > programs run on the cpu, dropwatch should alrady catch those. I.e. if the xdp
>> >> > program returns a DROP result for a packet being processed, the OS will call
>> >> > kfree_skb on its behalf, and dropwatch wil call that.
>> >>
>> >> There is no skb by the time an XDP program runs, so this is not true. As
>> >> I mentioned upthread, there's a tracepoint that will get called if an
>> >> error occurs (or the program returns XDP_ABORTED), but in most cases,
>> >> XDP_DROP just means that the packet silently disappears...
>> >>
>> > As I noted, thats only true for xdp programs that are offloaded to hardware, I
>> > was only speaking for XDP programs that run on the cpu. For the former case, we
>> > obviously need some other mechanism to detect drops, but for cpu executed xdp
>> > programs, the OS is responsible for freeing skbs associated with programs the
>> > return XDP_DROP.
>>
>> Ah, I think maybe you're thinking of generic XDP (also referred to as
>> skb mode)? That is a separate mode; an XDP program loaded in "native
> Yes, was I not clear about that?
No, not really. "Generic XDP" is not the same as "XDP"; the generic mode
is more of a debug mode (as far as I'm concerned at least). So in the
common case, it is absolutely not the case that the kernel will end up
calling kfree_skb after an XDP_DROP; so I got somewhat thrown off by
your insistence that it would... :)
-Toke
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-07-13 6:17 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix excessive stack usage in cxgb4, from Arnd Bergmann.
2) Missing skb queue lock init in tipc, from Chris Packham.
3) Fix some regressions in ipv6 flow label handling, from Eric Dumazet.
4) Elide flow dissection of local packets in FIB rules, from Petar
Penkov.
5) Fix TLS support build failure in mlx5, from Tariq Toukab.
Please pull, thanks a lot.
The following changes since commit a131c2bf165684315f606fdd88cf80be22ba32f3:
Merge tag 'acpi-5.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2019-07-11 11:17:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 25a09ce79639a8775244808c17282c491cff89cf:
ppp: mppe: Revert "ppp: mppe: Add softdep to arc4" (2019-07-12 22:58:49 -0700)
----------------------------------------------------------------
Arnd Bergmann (2):
davinci_cpdma: don't cast dma_addr_t to pointer
cxgb4: reduce kernel stack usage in cudbg_collect_mem_region()
Aya Levin (3):
net/mlx5e: Fix return value from timeout recover function
net/mlx5e: Fix error flow in tx reporter diagnose
net/mlx5e: IPoIB, Add error path in mlx5_rdma_setup_rn
Chris Packham (1):
tipc: ensure head->lock is initialised
Christian Lamparter (1):
net: dsa: qca8k: replace legacy gpio include
Cong Wang (1):
hsr: switch ->dellink() to ->ndo_uninit()
David S. Miller (4):
Merge branch 'mlx5-build-fixes'
Merge tag 'mlx5-fixes-2019-07-11' of git://git.kernel.org/.../saeed/linux
Merge branch 'net/rds-fixes' of git://git.kernel.org/.../ssantosh/linux
Merge branch 'nfp-flower-bugs'
Denis Efremov (1):
net: phy: make exported variables non-static
Eli Britstein (1):
net/mlx5e: Fix port tunnel GRE entropy control
Eric Biggers (1):
ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
Eric Dumazet (3):
ipv6: tcp: fix flowlabels reflection for RST packets
ipv6: fix potential crash in ip6_datagram_dst_update()
ipv6: fix static key imbalance in fl_create()
Gerd Rausch (3):
Revert "RDS: IB: split the mr registration and invalidation path"
rds: Accept peer connection reject messages due to incompatible version
rds: Return proper "tos" value to user-space
Jiangfeng Xiao (1):
net: hisilicon: Use devm_platform_ioremap_resource
Joe Perches (2):
net: ethernet: mediatek: Fix misuses of GENMASK macro
net: stmmac: Fix misuses of GENMASK macro
John Hurley (2):
nfp: flower: fix ethernet check on match fields
nfp: flower: ensure ip protocol is specified for L4 matches
Maor Gottlieb (1):
net/mlx5: E-Switch, Fix default encap mode
Nathan Chancellor (1):
net/mlx5e: Convert single case statement switch statements into if statements
Petar Penkov (1):
net: fib_rules: do not flow dissect local packets
Roman Mashak (1):
tc-tests: updated skbedit tests
Saeed Mahameed (3):
net/mlx5e: Rx, Fix checksum calculation for new hardware
net/mlx5e: Fix unused variable warning when CONFIG_MLX5_ESWITCH is off
net/mlx5: E-Switch, Reduce ingress acl modify metadata stack usage
Santosh Shilimkar (2):
rds: fix reordering with composite message notification
rds: avoid version downgrade to legitimate newer peer connections
Taehee Yoo (1):
net: openvswitch: do not update max_headroom if new headroom is equal to old headroom
Tariq Toukan (1):
net/mlx5e: Fix compilation error in TLS code
Vlad Buslov (2):
net: sched: Fix NULL-pointer dereference in tc_indr_block_ing_cmd()
net/mlx5e: Provide cb_list pointer when setting up tc block on rep
yangxingwu (1):
ipv6: Use ipv6_authlen for len
drivers/net/dsa/qca8k.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 19 ++++++---
drivers/net/ethernet/hisilicon/hip04_eth.c | 7 +---
drivers/net/ethernet/hisilicon/hisi_femac.c | 7 +---
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 7 +---
drivers/net/ethernet/hisilicon/hns_mdio.c | 4 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
drivers/net/ethernet/mediatek/mtk_sgmii.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/accel/tls.h | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c | 10 ++---
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c | 34 +++++-----------
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 8 ++--
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 5 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 7 +++-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 5 ---
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 9 ++++-
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 9 ++++-
drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c | 23 ++---------
drivers/net/ethernet/netronome/nfp/flower/offload.c | 28 +++++--------
drivers/net/ethernet/stmicro/stmmac/descs.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 4 +-
drivers/net/ethernet/ti/davinci_cpdma.c | 26 ++++++------
drivers/net/phy/phy_device.c | 6 +--
drivers/net/ppp/ppp_mppe.c | 1 -
include/linux/mlx5/mlx5_ifc.h | 3 +-
include/linux/phy.h | 3 ++
include/net/fib_rules.h | 4 +-
include/net/pkt_cls.h | 10 +++++
net/hsr/hsr_device.c | 18 ++++-----
net/hsr/hsr_device.h | 1 -
net/hsr/hsr_netlink.c | 7 ----
net/ipv6/ah6.c | 4 +-
net/ipv6/datagram.c | 2 +-
net/ipv6/exthdrs_core.c | 2 +-
net/ipv6/ip6_flowlabel.c | 9 +++--
net/ipv6/ip6_tunnel.c | 2 +-
net/ipv6/netfilter/ip6t_ah.c | 2 +-
net/ipv6/netfilter/ip6t_ipv6header.c | 2 +-
net/ipv6/netfilter/nf_conntrack_reasm.c | 2 +-
net/ipv6/netfilter/nf_log_ipv6.c | 2 +-
net/ipv6/tcp_ipv6.c | 7 +++-
net/openvswitch/datapath.c | 39 +++++++++++++-----
net/rds/connection.c | 1 +
net/rds/ib.h | 4 +-
net/rds/ib_cm.c | 9 +----
net/rds/ib_frmr.c | 11 +++--
net/rds/ib_send.c | 29 ++++++-------
net/rds/rdma.c | 10 -----
net/rds/rdma_transport.c | 11 +++--
net/rds/rds.h | 1 -
net/rds/send.c | 4 +-
net/sched/cls_api.c | 2 +-
net/tipc/name_distr.c | 2 +-
tools/testing/selftests/tc-testing/tc-tests/actions/skbedit.json | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++
55 files changed, 328 insertions(+), 222 deletions(-)
^ permalink raw reply
* Re: [PATCH net] ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
From: David Miller @ 2019-07-13 6:07 UTC (permalink / raw)
To: ebiggers; +Cc: netdev, linux-ppp, paulus, linux-crypto, tiwai, ard.biesheuvel
In-Reply-To: <20190712233931.17350-1-ebiggers@kernel.org>
From: Eric Biggers <ebiggers@kernel.org>
Date: Fri, 12 Jul 2019 16:39:31 -0700
> From: Eric Biggers <ebiggers@google.com>
>
> Commit 0e5a610b5ca5 ("ppp: mppe: switch to RC4 library interface"),
> which was merged through the crypto tree for v5.3, changed ppp_mppe.c to
> use the new arc4_crypt() library function rather than access RC4 through
> the dynamic crypto_skcipher API.
>
> Meanwhile commit aad1dcc4f011 ("ppp: mppe: Add softdep to arc4") was
> merged through the net tree and added a module soft-dependency on "arc4".
>
> The latter commit no longer makes sense because the code now uses the
> "libarc4" module rather than "arc4", and also due to the direct use of
> arc4_crypt(), no module soft-dependency is required.
>
> So revert the latter commit.
>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 13/19] ionic: Add initial ethtool support
From: Shannon Nelson @ 2019-07-13 5:32 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190709023050.GC5835@lunn.ch>
On 7/8/19 7:30 PM, Andrew Lunn wrote:
>> +static int ionic_nway_reset(struct net_device *netdev)
>> +{
>> + struct lif *lif = netdev_priv(netdev);
>> + int err = 0;
>> +
>> + if (netif_running(netdev))
>> + err = ionic_reset_queues(lif);
> What does ionic_reset_queues() do? It sounds nothing like restarting
> auto negotiation?
>
> Andrew
Basically, it's a rip-it-all-down-and-start-over way of restarting the
connection, and is also useful for fixing queues that are misbehaving.
It's a little old-fashioned, taken from the ixgbe example, but is
effective when there isn't an actual "restart auto-negotiation" command
in the firmware.
I'll try to make it a little more evident.
sln
^ 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