* 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
* Re: [PATCH v3 net-next 13/19] ionic: Add initial ethtool support
From: Shannon Nelson @ 2019-07-13 5:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190709021426.GA5835@lunn.ch>
On 7/8/19 7:14 PM, Andrew Lunn wrote:
>> +static int ionic_set_pauseparam(struct net_device *netdev,
>> + struct ethtool_pauseparam *pause)
>> +{
>> + struct lif *lif = netdev_priv(netdev);
>> + struct ionic *ionic = lif->ionic;
>> + struct ionic_dev *idev = &lif->ionic->idev;
>> +
>> + u32 requested_pause;
>> + u32 cur_autoneg;
>> + int err;
>> +
>> + cur_autoneg = idev->port_info->config.an_enable ? AUTONEG_ENABLE :
>> + AUTONEG_DISABLE;
>> + if (pause->autoneg != cur_autoneg) {
>> + netdev_info(netdev, "Please use 'ethtool -s ...' to change autoneg\n");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + /* change both at the same time */
>> + requested_pause = PORT_PAUSE_TYPE_LINK;
>> + if (pause->rx_pause)
>> + requested_pause |= IONIC_PAUSE_F_RX;
>> + if (pause->tx_pause)
>> + requested_pause |= IONIC_PAUSE_F_TX;
>> +
>> + if (requested_pause == idev->port_info->config.pause_type)
>> + return 0;
>> +
>> + idev->port_info->config.pause_type = requested_pause;
>> +
>> + mutex_lock(&ionic->dev_cmd_lock);
>> + ionic_dev_cmd_port_pause(idev, requested_pause);
>> + err = ionic_dev_cmd_wait(ionic, devcmd_timeout);
>> + mutex_unlock(&ionic->dev_cmd_lock);
>> + if (err)
>> + return err;
> Hi Shannon
>
> I've no idea what the firmware black box is doing, but this looks
> wrong.
>
> pause->autoneg is about if the results of auto-neg should be used or
> not. If false, just configure the MAC with the pause settings and you
> are done. If the interface is being forced, so autoneg in general is
> disabled, just configure the MAC and you are done.
>
> If pause->autoneg is true and the interface is using auto-neg as a
> whole, you pass the pause values to the PHY for it to advertise and
> trigger an auto-neg. Once autoneg has completed, and the resolved
> settings are available, the MAC is configured with the resolved
> values.
>
> Looking at this code, i don't see any difference between configuring
> the MAC or configuring the PHY. I would expect pause->autoneg to be
> part of requested_pause somehow, so the firmware knows what is should
> do.
>
> Andrew
In this device there's actually very little the driver can do to
directly configure the mac or phy besides passing through to the
firmware what the user has requested - that happens here for the pause
values, and in ionic_set_link_ksettings() for autoneg. The firmware is
managing the port based on these requests with the help of internally
configured rules defined in a customer setting.
sln
^ permalink raw reply
* Re: [PATCH v3 bpf 1/3] bpf: fix BTF verifier size resolution logic
From: Martin Lau @ 2019-07-13 4:54 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov,
daniel@iogearbox.net, Yonghong Song, andrii.nakryiko@gmail.com,
Kernel Team
In-Reply-To: <20190712172557.4039121-2-andriin@fb.com>
On Fri, Jul 12, 2019 at 10:25:55AM -0700, Andrii Nakryiko wrote:
> BTF verifier has a size resolution bug which in some circumstances leads to
> invalid size resolution for, e.g., TYPEDEF modifier. This happens if we have
> [1] PTR -> [2] TYPEDEF -> [3] ARRAY, in which case due to being in pointer
> context ARRAY size won't be resolved (because for pointer it doesn't matter, so
> it's a sink in pointer context), but it will be permanently remembered as zero
> for TYPEDEF and TYPEDEF will be marked as RESOLVED. Eventually ARRAY size will
> be resolved correctly, but TYPEDEF resolved_size won't be updated anymore.
> This, subsequently, will lead to erroneous map creation failure, if that
> TYPEDEF is specified as either key or value, as key_size/value_size won't
> correspond to resolved size of TYPEDEF (kernel will believe it's zero).
Thanks for the fix.
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Joel Fernandes @ 2019-07-13 3:10 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: <20190713030150.GA246587@google.com>
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(),
"suspicious rcu_sync_is_idle() usage");
return !READ_ONCE(rsp->gp_state); /* GP_IDLE */
}
--
2.22.0.510.g264f2c817a-goog
^ permalink raw reply related
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Joel Fernandes @ 2019-07-13 3:01 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: <20190712233206.GZ26519@linux.ibm.com>
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.
thanks,
- Joel
^ permalink raw reply
* [PATCH 2/2] net-next: ag71xx: Rearrange ag711xx struct to remove holes
From: Rosen Penev @ 2019-07-13 2:09 UTC (permalink / raw)
To: netdev
In-Reply-To: <20190713020921.18202-1-rosenp@gmail.com>
Removed ____cacheline_aligned attribute to ring structs. This actually
causes holes in the ag71xx struc as well as lower performance.
Rearranged struct members to fall within respective cachelines. The RX
ring struct now does not share a cacheline with the TX ring. The NAPI
atruct now takes up its own cachelines and does not share.
According to pahole -C ag71xx -c 32
Before:
struct ag71xx {
/* size: 384, cachelines: 12, members: 22 */
/* sum members: 375, holes: 2, sum holes: 9 */
After:
struct ag71xx {
/* size: 376, cachelines: 12, members: 22 */
/* last cacheline: 24 bytes */
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/ethernet/atheros/ag71xx.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c
index 8f450a03a885..f19711984d34 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -295,16 +295,15 @@ struct ag71xx {
/* Critical data related to the per-packet data path are clustered
* early in this structure to help improve the D-cache footprint.
*/
- struct ag71xx_ring rx_ring ____cacheline_aligned;
- struct ag71xx_ring tx_ring ____cacheline_aligned;
-
+ struct ag71xx_ring rx_ring;
u16 rx_buf_size;
- u8 rx_buf_offset;
+ u16 rx_buf_offset;
+ u32 msg_enable;
+ struct ag71xx_ring tx_ring;
struct net_device *ndev;
struct platform_device *pdev;
struct napi_struct napi;
- u32 msg_enable;
const struct ag71xx_dcfg *dcfg;
/* From this point onwards we're not looking at per-packet fields. */
@@ -313,20 +312,17 @@ struct ag71xx {
struct ag71xx_desc *stop_desc;
dma_addr_t stop_desc_dma;
- int phy_if_mode;
-
- struct delayed_work restart_work;
- struct timer_list oom_timer;
-
- struct reset_control *mac_reset;
-
u32 fifodata[3];
int mac_idx;
+ int phy_if_mode;
- struct reset_control *mdio_reset;
struct mii_bus *mii_bus;
struct clk *clk_mdio;
struct clk *clk_eth;
+ struct reset_control *mdio_reset;
+ struct delayed_work restart_work;
+ struct timer_list oom_timer;
+ struct reset_control *mac_reset;
};
static int ag71xx_desc_empty(struct ag71xx_desc *desc)
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] net-next: ag71xx: Add missing header
From: Rosen Penev @ 2019-07-13 2:09 UTC (permalink / raw)
To: netdev
ag71xx uses devm_ioremap_nocache. This fixes usage of an implicit function
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/ethernet/atheros/ag71xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c
index 72a57c6cd254..8f450a03a885 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -35,6 +35,7 @@
#include <linux/regmap.h>
#include <linux/reset.h>
#include <linux/clk.h>
+#include <linux/io.h>
/* For our NAPI weight bigger does *NOT* mean better - it means more
* D-cache misses and lots more wasted cycles than we'll ever
--
2.17.1
^ permalink raw reply related
* LPC 2019 Networking Track CFP (reminder)
From: David Miller @ 2019-07-13 0:52 UTC (permalink / raw)
To: netdev, daniel; +Cc: linux-wireless, netfilter-devel, bpf, linux-kernel, lwn
This is a call for proposals for the 3 day networking track at the
Linux Plumbers Conference in Lisbon, which will be happening on
September 9th-11th, 2019.
We are seeking talks of 40 minutes in length (including Q & A),
optionally accompanied by papers of 2 to 10 pages in length. The
papers, while not required, are very strongly encouraged by the
committee. The submitters intention to provide a paper will be taken
into consideration as a criteria when deciding which proposals to
accept.
Any kind of advanced networking-related topic will be considered.
Please submit your proposals on the LPC website at:
https://www.linuxplumbersconf.org/event/4/abstracts/#submit-abstract
And be sure to select "Networking Summit Track" in the Track pulldown
menu.
Proposals must be submitted by August 2nd, and submitters will be
notified of acceptance by August 9th.
Final slides and papers (as PDF) are due on September 2nd.
Looking forward to seeing you all in Lisbon in September!
^ permalink raw reply
* Re: [PATCH] be2net: fix adapter->big_page_size miscaculation
From: David Miller @ 2019-07-13 0:50 UTC (permalink / raw)
To: cai
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
arnd, dhowells, hpa, netdev, linux-arch, linux-kernel
In-Reply-To: <EFD25845-097A-46B1-9C1A-02458883E4DA@lca.pw>
From: Qian Cai <cai@lca.pw>
Date: Fri, 12 Jul 2019 20:27:09 -0400
> Actually, GCC would consider it a const with -O2 optimized level because it found that it was never modified and it does not understand it is a module parameter. Considering the following code.
>
> # cat const.c
> #include <stdio.h>
>
> static int a = 1;
>
> int main(void)
> {
> if (__builtin_constant_p(a))
> printf("a is a const.\n");
>
> return 0;
> }
>
> # gcc -O2 const.c -o const
That's not a complete test case, and with a proper test case that
shows the externalization of the address of &a done by the module
parameter macros, gcc should not make this optimization or we should
define the module parameter macros in a way that makes this properly
clear to the compiler.
It makes no sense to hack around this locally in drivers and other
modules.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 00/11] Add drop monitor for offloaded data paths
From: Neil Horman @ 2019-07-13 0:40 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
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: <871ryvv3dy.fsf@toke.dk>
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?
Neil
> mode" (or "driver mode") runs on the CPU, but before the skb is created;
> this is the common case for XDP, and there is no skb and thus no drop
> notification in this mode.
>
> There is *also* an offload mode for XDP programs, but that is only
> supported by netronome cards thus far, so not as commonly used...
>
> -Toke
>
^ permalink raw reply
* Re: [GIT PULL] 9p updates for 5.3
From: pr-tracker-bot @ 2019-07-13 0:40 UTC (permalink / raw)
To: Dominique Martinet; +Cc: Linus Torvalds, v9fs-developer, linux-kernel, netdev
In-Reply-To: <20190712080446.GA19400@nautica>
The pull request you sent on Fri, 12 Jul 2019 10:04:46 +0200:
> git://github.com/martinetd/linux tags/9p-for-5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/23bbbf5c1fb3ddf104c2ddbda4cc24ebe53a3453
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH] be2net: fix adapter->big_page_size miscaculation
From: Qian Cai @ 2019-07-13 0:27 UTC (permalink / raw)
To: David Miller
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
arnd, dhowells, hpa, netdev, linux-arch, linux-kernel
In-Reply-To: <20190712.154606.493382088615011132.davem@davemloft.net>
> On Jul 12, 2019, at 6:46 PM, David Miller <davem@davemloft.net> wrote:
>
> From: Qian Cai <cai@lca.pw>
> Date: Fri, 12 Jul 2019 15:23:21 -0400
>
>> The commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
>> problem for the be2net driver as "rx_frag_size" could be a module
>> parameter that can be changed while loading the module.
>
> Why is this a problem?
Well, for example, if rx_frag_size was set to 8096 when loading the module, the kernel has already used the default value 2048 during compilation time.
>
>> That commit checks __builtin_constant_p() first in get_order() which
>> cause "adapter->big_page_size" to be assigned a value based on the
>> the default "rx_frag_size" value at the compilation time. It also
>> generate a compilation warning,
>
> rx_frag_size is not a constant, therefore the __builtin_constant_p()
> test should not pass.
>
> This explanation doesn't seem valid.
Actually, GCC would consider it a const with -O2 optimized level because it found that it was never modified and it does not understand it is a module parameter. Considering the following code.
# cat const.c
#include <stdio.h>
static int a = 1;
int main(void)
{
if (__builtin_constant_p(a))
printf("a is a const.\n");
return 0;
}
# gcc -O2 const.c -o const
# ./const
a is a const.
^ permalink raw reply
* Re: [PATCH] [net-next] cxgb4: reduce kernel stack usage in cudbg_collect_mem_region()
From: Joe Perches @ 2019-07-13 0:14 UTC (permalink / raw)
To: David Miller, arnd
Cc: vishal, rahul.lakkireddy, ganeshgr, alexios.zavras, arjun,
surendra, netdev, linux-kernel, clang-built-linux
In-Reply-To: <20190712.153632.1007215196498198399.davem@davemloft.net>
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.
^ permalink raw reply
* [PATCH net] ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
From: Eric Biggers @ 2019-07-12 23:39 UTC (permalink / raw)
To: netdev, linux-ppp, David S . Miller, Paul Mackerras
Cc: linux-crypto, Takashi Iwai, Ard Biesheuvel
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>
---
drivers/net/ppp/ppp_mppe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index bd3c80b0bc77d..de3b57d09d0cb 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -64,7 +64,6 @@ MODULE_AUTHOR("Frank Cusack <fcusack@fcusack.com>");
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
-MODULE_SOFTDEP("pre: arc4");
MODULE_VERSION("1.0.2");
#define SHA1_PAD_SIZE 40
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
From: Paul E. McKenney @ 2019-07-12 23:32 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: <20190712213559.GA175138@google.com>
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?
Thanx, Paul
> thanks!
>
> - Joel
>
>
> > ---
> > Please note: Only build and boot tested this particular patch so far.
> >
> > include/linux/rcu_sync.h | 5 ++---
> > kernel/rcu/sync.c | 22 ----------------------
> > 2 files changed, 2 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> > index 6fc53a1345b3..c954f1efc919 100644
> > --- a/include/linux/rcu_sync.h
> > +++ b/include/linux/rcu_sync.h
> > @@ -39,9 +39,8 @@ extern void rcu_sync_lockdep_assert(struct rcu_sync *);
> > */
> > static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> > {
> > -#ifdef CONFIG_PROVE_RCU
> > - rcu_sync_lockdep_assert(rsp);
> > -#endif
> > + RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> > + "suspicious rcu_sync_is_idle() usage");
> > return !rsp->gp_state; /* GP_IDLE */
> > }
> >
> > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> > index a8304d90573f..535e02601f56 100644
> > --- a/kernel/rcu/sync.c
> > +++ b/kernel/rcu/sync.c
> > @@ -10,37 +10,25 @@
> > #include <linux/rcu_sync.h>
> > #include <linux/sched.h>
> >
> > -#ifdef CONFIG_PROVE_RCU
> > -#define __INIT_HELD(func) .held = func,
> > -#else
> > -#define __INIT_HELD(func)
> > -#endif
> > -
> > static const struct {
> > void (*sync)(void);
> > void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> > void (*wait)(void);
> > -#ifdef CONFIG_PROVE_RCU
> > - int (*held)(void);
> > -#endif
> > } gp_ops[] = {
> > [RCU_SYNC] = {
> > .sync = synchronize_rcu,
> > .call = call_rcu,
> > .wait = rcu_barrier,
> > - __INIT_HELD(rcu_read_lock_held)
> > },
> > [RCU_SCHED_SYNC] = {
> > .sync = synchronize_rcu,
> > .call = call_rcu,
> > .wait = rcu_barrier,
> > - __INIT_HELD(rcu_read_lock_sched_held)
> > },
> > [RCU_BH_SYNC] = {
> > .sync = synchronize_rcu,
> > .call = call_rcu,
> > .wait = rcu_barrier,
> > - __INIT_HELD(rcu_read_lock_bh_held)
> > },
> > };
> >
> > @@ -49,16 +37,6 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY };
> >
> > #define rss_lock gp_wait.lock
> >
> > -#ifdef CONFIG_PROVE_RCU
> > -void rcu_sync_lockdep_assert(struct rcu_sync *rsp)
> > -{
> > - RCU_LOCKDEP_WARN(!gp_ops[rsp->gp_type].held(),
> > - "suspicious rcu_sync_is_idle() usage");
> > -}
> > -
> > -EXPORT_SYMBOL_GPL(rcu_sync_lockdep_assert);
> > -#endif
> > -
> > /**
> > * rcu_sync_init() - Initialize an rcu_sync structure
> > * @rsp: Pointer to rcu_sync structure to be initialized
> > --
> > 2.22.0.510.g264f2c817a-goog
> >
>
^ permalink raw reply
* Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
From: Paul E. McKenney @ 2019-07-12 23:27 UTC (permalink / raw)
To: Joel Fernandes
Cc: Peter Zijlstra, linux-kernel, Alexey Kuznetsov, Bjorn Helgaas,
Borislav Petkov, c0d1n61at3, David S. Miller, edumazet,
Greg Kroah-Hartman, Hideaki YOSHIFUJI, H. Peter Anvin,
Ingo Molnar, Josh Triplett, keescook, kernel-hardening,
Lai Jiangshan, Len Brown, linux-acpi, linux-pci, linux-pm,
Mathieu Desnoyers, neilb, netdev, oleg, Pavel Machek,
Rafael J. Wysocki, Rasmus Villemoes, rcu, Steven Rostedt,
Tejun Heo, Thomas Gleixner, will,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20190712194040.GA150253@google.com>
On Fri, Jul 12, 2019 at 03:40:40PM -0400, Joel Fernandes wrote:
> On Fri, Jul 12, 2019 at 10:46:30AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 12, 2019 at 01:06:31PM -0400, Joel Fernandes wrote:
> > > On Fri, Jul 12, 2019 at 09:45:31AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Jul 12, 2019 at 11:10:51AM -0400, Joel Fernandes wrote:
> > > > > On Fri, Jul 12, 2019 at 01:11:25PM +0200, Peter Zijlstra wrote:
> > > > > > On Thu, Jul 11, 2019 at 07:43:56PM -0400, Joel Fernandes (Google) wrote:
> > > > > > > +int rcu_read_lock_any_held(void)
> > > > > > > +{
> > > > > > > + int lockdep_opinion = 0;
> > > > > > > +
> > > > > > > + if (!debug_lockdep_rcu_enabled())
> > > > > > > + return 1;
> > > > > > > + if (!rcu_is_watching())
> > > > > > > + return 0;
> > > > > > > + if (!rcu_lockdep_current_cpu_online())
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + /* Preemptible RCU flavor */
> > > > > > > + if (lock_is_held(&rcu_lock_map))
> > > > > >
> > > > > > you forgot debug_locks here.
> > > > >
> > > > > Actually, it turns out debug_locks checking is not even needed. If
> > > > > debug_locks == 0, then debug_lockdep_rcu_enabled() returns 0 and we would not
> > > > > get to this point.
> > > > >
> > > > > > > + return 1;
> > > > > > > +
> > > > > > > + /* BH flavor */
> > > > > > > + if (in_softirq() || irqs_disabled())
> > > > > >
> > > > > > I'm not sure I'd put irqs_disabled() under BH, also this entire
> > > > > > condition is superfluous, see below.
> > > > > >
> > > > > > > + return 1;
> > > > > > > +
> > > > > > > + /* Sched flavor */
> > > > > > > + if (debug_locks)
> > > > > > > + lockdep_opinion = lock_is_held(&rcu_sched_lock_map);
> > > > > > > + return lockdep_opinion || !preemptible();
> > > > > >
> > > > > > that !preemptible() turns into:
> > > > > >
> > > > > > !(preempt_count()==0 && !irqs_disabled())
> > > > > >
> > > > > > which is:
> > > > > >
> > > > > > preempt_count() != 0 || irqs_disabled()
> > > > > >
> > > > > > and already includes irqs_disabled() and in_softirq().
> > > > > >
> > > > > > > +}
> > > > > >
> > > > > > So maybe something lke:
> > > > > >
> > > > > > if (debug_locks && (lock_is_held(&rcu_lock_map) ||
> > > > > > lock_is_held(&rcu_sched_lock_map)))
> > > > > > return true;
> > > > >
> > > > > Agreed, I will do it this way (without the debug_locks) like:
> > > > >
> > > > > ---8<-----------------------
> > > > >
> > > > > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> > > > > index ba861d1716d3..339aebc330db 100644
> > > > > --- a/kernel/rcu/update.c
> > > > > +++ b/kernel/rcu/update.c
> > > > > @@ -296,27 +296,15 @@ EXPORT_SYMBOL_GPL(rcu_read_lock_bh_held);
> > > > >
> > > > > int rcu_read_lock_any_held(void)
> > > > > {
> > > > > - int lockdep_opinion = 0;
> > > > > -
> > > > > if (!debug_lockdep_rcu_enabled())
> > > > > return 1;
> > > > > if (!rcu_is_watching())
> > > > > return 0;
> > > > > if (!rcu_lockdep_current_cpu_online())
> > > > > return 0;
> > > > > -
> > > > > - /* Preemptible RCU flavor */
> > > > > - if (lock_is_held(&rcu_lock_map))
> > > > > - return 1;
> > > > > -
> > > > > - /* BH flavor */
> > > > > - if (in_softirq() || irqs_disabled())
> > > > > - return 1;
> > > > > -
> > > > > - /* Sched flavor */
> > > > > - if (debug_locks)
> > > > > - lockdep_opinion = lock_is_held(&rcu_sched_lock_map);
> > > > > - return lockdep_opinion || !preemptible();
> > > > > + if (lock_is_held(&rcu_lock_map) || lock_is_held(&rcu_sched_lock_map))
> > > >
> > > > OK, I will bite... Why not also lock_is_held(&rcu_bh_lock_map)?
> > >
> > > Hmm, I was borrowing the strategy from rcu_read_lock_bh_held() which does not
> > > check for a lock held in this map.
> > >
> > > Honestly, even lock_is_held(&rcu_sched_lock_map) seems unnecessary per-se
> > > since !preemptible() will catch that? rcu_read_lock_sched() disables
> > > preemption already, so lockdep's opinion of the matter seems redundant there.
> >
> > Good point! At least as long as the lockdep splats list RCU-bh among
> > the locks held, which they did last I checked.
> >
> > Of course, you could make the same argument for getting rid of
> > rcu_sched_lock_map. Does it make sense to have the one without
> > the other?
>
> It probably makes it inconsistent in the least. I will add the check for
> the rcu_bh_lock_map in a separate patch, if that's Ok with you - since I also
> want to update the rcu_read_lock_bh_held() logic in the same patch.
>
> That rcu_read_lock_bh_held() could also just return !preemptible as Peter
> suggested for the bh case.
Although that seems reasonable, please check the call sites.
> > > Sorry I already sent out patches again before seeing your comment but I can
> > > rework and resend them based on any other suggestions.
> >
> > Not a problem!
>
> Thanks. Depending on whether there is any other feedback, I will work on the
> bh_ stuff as a separate patch on top of this series, or work it into the next
> series revision if I'm reposting. Hopefully that sounds Ok to you.
Agreed -- let's separate concerns. And promote bisectability.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH net-next] net: openvswitch: do not update max_headroom if new headroom is equal to old headroom
From: Gregory Rose @ 2019-07-12 23:11 UTC (permalink / raw)
To: David Miller, ap420073; +Cc: pshelar, netdev, dev
In-Reply-To: <20190712.151846.1093841226730573129.davem@davemloft.net>
On 7/12/2019 3:18 PM, David Miller wrote:
> From: Taehee Yoo <ap420073@gmail.com>
> Date: Sat, 6 Jul 2019 01:08:09 +0900
>
>> When a vport is deleted, the maximum headroom size would be changed.
>> If the vport which has the largest headroom is deleted,
>> the new max_headroom would be set.
>> But, if the new headroom size is equal to the old headroom size,
>> updating routine is unnecessary.
>>
>> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> I don't think Taehee should be punished because it took several days
> to get someone to look at and review and/or test this patch and
> meanwhile the net-next tree closed down.
>
> I ask for maintainer review as both a courtesy and a way to lessen
> my workload. But if that means patches rot for days in patchwork
> I'm just going to apply them after my own review.
>
> So I'm applying this now.
>
My apologies Dave. I did test and review the patch, perhaps you didn't
see it. In any case, you're right, Taehee was owed a more timely review
and I missed it.
Thanks for applying the patch.
- Greg
^ permalink raw reply
* Re: [PATCH] be2net: fix adapter->big_page_size miscaculation
From: David Miller @ 2019-07-12 22:46 UTC (permalink / raw)
To: cai
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
arnd, dhowells, hpa, netdev, linux-arch, linux-kernel
In-Reply-To: <1562959401-19815-1-git-send-email-cai@lca.pw>
From: Qian Cai <cai@lca.pw>
Date: Fri, 12 Jul 2019 15:23:21 -0400
> The commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
> problem for the be2net driver as "rx_frag_size" could be a module
> parameter that can be changed while loading the module.
Why is this a problem?
> That commit checks __builtin_constant_p() first in get_order() which
> cause "adapter->big_page_size" to be assigned a value based on the
> the default "rx_frag_size" value at the compilation time. It also
> generate a compilation warning,
rx_frag_size is not a constant, therefore the __builtin_constant_p()
test should not pass.
This explanation doesn't seem valid.
^ permalink raw reply
* Re: [PATCH net] net: neigh: fix multiple neigh timer scheduling
From: David Miller @ 2019-07-12 22:42 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: netdev, dsahern, marek
In-Reply-To: <20190712.154047.1787144778692165503.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);
^~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH net] net: neigh: fix multiple neigh timer scheduling
From: David Miller @ 2019-07-12 22:40 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: netdev, dsahern, marek
In-Reply-To: <7b254317bcb84a33cdbe8eed96e510324d6eb97c.1562951883.git.lorenzo.bianconi@redhat.com>
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.
^ permalink raw reply
* Re: [PATCH] net: dsa: qca8k: replace legacy gpio include
From: David Miller @ 2019-07-12 22:38 UTC (permalink / raw)
To: chunkeey; +Cc: netdev, f.fainelli, vivien.didelot, andrew, lkp
In-Reply-To: <20190712153336.5018-1-chunkeey@gmail.com>
From: Christian Lamparter <chunkeey@gmail.com>
Date: Fri, 12 Jul 2019 17:33:36 +0200
> This patch replaces the legacy bulk gpio.h include
> with the proper gpio/consumer.h variant. This was
> caught by the kbuild test robot that was running
> into an error because of this.
>
> For more information why linux/gpio.h is bad can be found in:
> commit 56a46b6144e7 ("gpio: Clarify that <linux/gpio.h> is legacy")
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Link: https://www.spinics.net/lists/netdev/msg584447.html
> Fixes: a653f2f538f9 ("net: dsa: qca8k: introduce reset via gpio feature")
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: hisilicon: Use devm_platform_ioremap_resource
From: David Miller @ 2019-07-12 22:37 UTC (permalink / raw)
To: xiaojiangfeng
Cc: yisen.zhuang, salil.mehta, netdev, linux-kernel, sergei.shtylyov,
leeyou.li, nixiaoming
In-Reply-To: <1562937384-121710-1-git-send-email-xiaojiangfeng@huawei.com>
From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date: Fri, 12 Jul 2019 21:16:24 +0800
> Use devm_platform_ioremap_resource instead of
> devm_ioremap_resource. Make the code simpler.
>
> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] [net-next] cxgb4: reduce kernel stack usage in cudbg_collect_mem_region()
From: David Miller @ 2019-07-12 22:36 UTC (permalink / raw)
To: arnd
Cc: vishal, rahul.lakkireddy, ganeshgr, alexios.zavras, arjun,
surendra, netdev, linux-kernel, clang-built-linux
In-Reply-To: <20190712090700.317887-1-arnd@arndb.de>
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. One gets inlined into the other,
> which causes the stack usage to be combined beyond the warning limit
> when building with clang:
>
> drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c:1057:12: error: stack frame size of 1244 bytes in function 'cudbg_collect_mem_region' [-Werror,-Wframe-larger-than=]
>
> Restructuring cudbg_collect_mem_region() lets clang do the same
> optimization that gcc does and reuse the stack slots as it can
> see that the large variables are never used together.
>
> A better fix might be to avoid using cudbg_meminfo on the stack
> altogether, but that requires a larger rewrite.
>
> Fixes: a1c69520f785 ("cxgb4: collect MC memory dump")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH v2] tipc: ensure head->lock is initialised
From: David Miller @ 2019-07-12 22:34 UTC (permalink / raw)
To: chris.packham
Cc: jon.maloy, eric.dumazet, ying.xue, linux-kernel, netdev,
tipc-discussion
In-Reply-To: <20190711224115.21499-1-chris.packham@alliedtelesis.co.nz>
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date: Fri, 12 Jul 2019 10:41:15 +1200
> tipc_named_node_up() creates a skb list. It passes the list to
> tipc_node_xmit() which has some code paths that can call
> skb_queue_purge() which relies on the list->lock being initialised.
>
> The spin_lock is only needed if the messages end up on the receive path
> but when the list is created in tipc_named_node_up() we don't
> necessarily know if it is going to end up there.
>
> Once all the skb list users are updated in tipc it will then be possible
> to update them to use the unlocked variants of the skb list functions
> and initialise the lock when we know the message will follow the receive
> path.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-tests: updated skbedit tests
From: David Miller @ 2019-07-12 22:33 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1562862540-16509-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Thu, 11 Jul 2019 12:29:00 -0400
> - Added mask upper bound test case
> - Added mask validation test case
> - Added mask replacement case
>
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
New tests I'll allow still now, applied, thanks.
^ 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