* [PATCH net v2 7/7] smsc95xx: Check for Wake-on-LAN modes
From: Florian Fainelli @ 2018-09-28 23:18 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Woojung Huh,
Microchip Linux Driver Support, Steve Glendinning, Kees Cook,
Alexander Kurz, Hayes Wang, Kai-Heng Feng, Grant Grundler,
zhong jiang, Sebastian Andrzej Siewior, Ran Wang, Eric Dumazet,
open list:USB NETWORKING DRIVERS, open list
In-Reply-To: <20180928231856.3587-1-f.fainelli@gmail.com>
The driver does not check for Wake-on-LAN modes specified by an user,
but will conditionally set the device as wake-up enabled or not based on
that, which could be a very confusing user experience.
Fixes: e0e474a83c18 ("smsc95xx: add wol magic packet support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/usb/smsc95xx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 06b4d290784d..262e7a3c23cb 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -774,6 +774,9 @@ static int smsc95xx_ethtool_set_wol(struct net_device *net,
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
int ret;
+ if (wolinfo->wolopts & ~SUPPORTED_WAKE)
+ return -EINVAL;
+
pdata->wolopts = wolinfo->wolopts & SUPPORTED_WAKE;
ret = device_set_wakeup_enable(&dev->udev->dev, pdata->wolopts);
--
2.17.1
^ permalink raw reply related
* Re: bond: take rcu lock in bond_poll_controller
From: Cong Wang @ 2018-09-28 16:55 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Network Developers
In-Reply-To: <20180928161631.3pab3m2k6zvoemnz@codemonkey.org.uk>
On Fri, Sep 28, 2018 at 9:18 AM Dave Jones <davej@codemonkey.org.uk> wrote:
>
> Callers of bond_for_each_slave_rcu are expected to hold the rcu lock,
> otherwise a trace like below is shown
So why not take rcu read lock in netpoll_send_skb_on_dev() where
RCU is also assumed?
As I said, I can't explain why you didn't trigger the RCU warning in
netpoll_send_skb_on_dev()...
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ipneigh: support setting of NTF_ROUTER on neigh entries
From: David Ahern @ 2018-09-28 16:57 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev
In-Reply-To: <1537910139-21859-1-git-send-email-roopa@cumulusnetworks.com>
On 9/25/18 3:15 PM, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> ip/ipneigh.c | 2 ++
> 1 file changed, 2 insertions(+)
>
applied to iproute2-next.
And then I noticed you did not update the help or the man page. Please
send a follow up.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix an extack message in tcf_block_find()
From: Cong Wang @ 2018-09-28 17:03 UTC (permalink / raw)
To: Vlad Buslov; +Cc: Linux Kernel Network Developers, Jiri Pirko, Jamal Hadi Salim
In-Reply-To: <vbf1s9dyhub.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Fri, Sep 28, 2018 at 4:36 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
> On Thu 27 Sep 2018 at 20:42, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > It is clearly a copy-n-paste.
> >
> > Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> > ---
> > net/sched/cls_api.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> > index 3de47e99b788..8dd7f8af6d54 100644
> > --- a/net/sched/cls_api.c
> > +++ b/net/sched/cls_api.c
> > @@ -655,7 +655,7 @@ static struct tcf_block *tcf_block_find(struct net *net, struct Qdisc **q,
> >
> > *q = qdisc_refcount_inc_nz(*q);
> > if (!*q) {
> > - NL_SET_ERR_MSG(extack, "Parent Qdisc doesn't exists");
> > + NL_SET_ERR_MSG(extack, "Can't increase Qdisc refcount");
> > err = -EINVAL;
> > goto errout_rcu;
> > }
>
> Is there a benefit in exposing this info to user?
Depends on what user you mean here. For kernel developers, yes,
this is useful. For others, no.
> For all intents and purposes Qdisc is gone at that point.
I don't want to be a language lawyer, but there is a difference between
"it doesn't exist" and "it exists but being removed". The errno EINVAL
betrays what you said too, it must be ENOENT to mach "Qdisc is gone".
I don't want to waste my time on this any more. Let's just drop it.
I really don't care, do you?
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix an extack message in tcf_block_find()
From: Cong Wang @ 2018-09-28 17:04 UTC (permalink / raw)
To: Linux Kernel Network Developers; +Cc: Jiri Pirko, Jamal Hadi Salim, Vlad Buslov
In-Reply-To: <20180927204219.17846-1-xiyou.wangcong@gmail.com>
On Thu, Sep 27, 2018 at 1:42 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> It is clearly a copy-n-paste.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
I regret again for wasting my time, so:
NAcked-by: Cong Wang <xiyou.wangcong@gmail.com>
I really don't care, do you?
^ permalink raw reply
* [PATCH iproute2] lib/libnetlink: fix response seq check
From: vlad @ 2018-09-28 17:13 UTC (permalink / raw)
To: stephen; +Cc: chrism, netdev, maheshb, Vlad Dumitrescu
From: Vlad Dumitrescu <vladum@google.com>
Taking a one-iovec example, with rtnl->seq at 42. iovlen == 1, seq
becomes 43 on line 604, and a message is sent with nlmsg_seq == 43. If
a response with nlmsg_seq of 42 is received, the condition being fixed
in this patch would incorrectly accept it.
Fixes: 72a2ff3916e5 ("lib/libnetlink: Add a new function rtnl_talk_iov")
Signed-off-by: Vlad Dumitrescu <vladum@google.com>
---
lib/libnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index f18dceac..4d2416bf 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -647,7 +647,7 @@ static int __rtnl_talk_iov(struct rtnl_handle *rtnl, struct iovec *iov,
if (nladdr.nl_pid != 0 ||
h->nlmsg_pid != rtnl->local.nl_pid ||
- h->nlmsg_seq > seq || h->nlmsg_seq < seq - iovlen) {
+ h->nlmsg_seq > seq || h->nlmsg_seq < seq - iovlen + 1) {
/* Don't forget to skip that message. */
status -= NLMSG_ALIGN(len);
h = (struct nlmsghdr *)((char *)h + NLMSG_ALIGN(len));
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* Re: [PATCH net-next] qed: Remove set but not used variable 'p_archipelago'
From: David Miller @ 2018-09-28 17:15 UTC (permalink / raw)
To: yuehaibing; +Cc: Ariel.Elior, everest-linux-l2, netdev, kernel-janitors
In-Reply-To: <1538030706-138186-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 27 Sep 2018 06:45:06 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/qlogic/qed/qed_ooo.c: In function 'qed_ooo_delete_isles':
> drivers/net/ethernet/qlogic/qed/qed_ooo.c:354:30: warning:
> variable 'p_archipelago' set but not used [-Wunused-but-set-variable]
>
> drivers/net/ethernet/qlogic/qed/qed_ooo.c: In function 'qed_ooo_join_isles':
> drivers/net/ethernet/qlogic/qed/qed_ooo.c:463:30: warning:
> variable 'p_archipelago' set but not used [-Wunused-but-set-variable]
>
> Since commit 1eec2437d14c ("qed: Make OOO archipelagos into an array"),
> 'p_archipelago' is no longer in use.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* rcu_read_lock() in tcf_block_find()
From: Cong Wang @ 2018-09-28 17:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Linux Kernel Network Developers, Jiri Pirko, Jamal Hadi Salim,
Vlad Buslov
In-Reply-To: <4817f6db-bd55-2885-ac16-6fc7d6879b7e@gmail.com>
(Changing $subject as the discussion is going to a completely different topic)
On Thu, Sep 27, 2018 at 3:19 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/27/2018 02:36 PM, Cong Wang wrote:
>
> > I don't understand what you mean by changing ip command, you must
> > mean tc command, but still, I have no idea about how restarting failed
> > syscall could be related to my patch and why we need to restart anything
> > here. If the refcnt goes to 0, it will never come back, retrying won't help
> > anything.
> >
>
> Yep, tc command it is.
>
> I was not especially commenting your patch (replacing an english message by another does
> not seem very big deal), but the fact that the code right there seems to be prepared
> for parallel changes.
>
> But using RCU lookups in control path will lead to occasional failures
> that most user space tools would not expect.
>
I already discussed this with Vlad in the beginning of his RTNL
removal patches, we both agreed some lock is still needed, it is not
completely lockless. Take a look at tc action code now, two spinlocks
are still needed even after we will remove the RTNL there.
> Lets assume two tasks are launching "tc qdisc replace dev eth0 root XXX" in whatever order/parallelism.
>
> Both should succeed, after/before major RTNL->other_locking_mechanism
Yes, it is never going to be completely lockless.
>
> Control paths are usually using a mutex or a spinlock so that they never hit a 0-refcount at all.
For dev->qdisc, sure, we should already hold a refcnt, it can't be gone.
For qdisc_lookup_rcu(), it could be that refcnt goes to 0 before we
remove it from hashtable, right? call_rcu() is only called after
refcnt==0, so rcu read lock can't help here.
Thanks.
^ permalink raw reply
* Re: bond: take rcu lock in bond_poll_controller
From: Dave Jones @ 2018-09-28 17:25 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUVMszSA4ZyiJJgJAu053DZ3RbU91kBewrMMiWd7E19Lg@mail.gmail.com>
On Fri, Sep 28, 2018 at 09:55:52AM -0700, Cong Wang wrote:
> On Fri, Sep 28, 2018 at 9:18 AM Dave Jones <davej@codemonkey.org.uk> wrote:
> >
> > Callers of bond_for_each_slave_rcu are expected to hold the rcu lock,
> > otherwise a trace like below is shown
>
> So why not take rcu read lock in netpoll_send_skb_on_dev() where
> RCU is also assumed?
that does seem to solve the backtrace spew I saw too, so if that's
preferable I can respin the patch.
> As I said, I can't explain why you didn't trigger the RCU warning in
> netpoll_send_skb_on_dev()...
netpoll_send_skb_on_dev takes the rcu lock itself.
Dave
^ permalink raw reply
* Re: [PATCH v3 0/5] netlink: nested policy validation
From: David Miller @ 2018-09-28 17:25 UTC (permalink / raw)
To: johannes; +Cc: netdev, dsahern
In-Reply-To: <1538036562.14416.23.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 27 Sep 2018 10:22:42 +0200
> On Wed, 2018-09-26 at 10:21 -0700, David Miller wrote:
>> From: Johannes Berg <johannes@sipsolutions.net>
>> Date: Wed, 26 Sep 2018 11:15:29 +0200
>>
>> > This adds nested policy validation, which lets you specify the
>> > nested attribute type, e.g. NLA_NESTED with sub-policy, or the
>> > new NLA_NESTED_ARRAY with sub-sub-policy.
>> >
>> >
>> > Changes in v2:
>> > * move setting the bad attr pointer/message into validate_nla()
>> > * remove the recursion patch since that's no longer needed
>> > * simply skip the generic bad attr pointer/message setting in
>> > case of nested nla_validate() failing since that could fail
>> > only due to validate_nla() failing inside, which already sets
>> > the extack information
>> >
>> > Changes in v3:
>> > * fix NLA_REJECT to have an error message if none is in policy
>>
>> Looks great Johannes, series applied.
>
> Sorry to nag, but I see patches that you replied to later than this in
> the tree, but not this.
>
> Or did you see something wrong with this later and dropped it?
Ugh, the perils of working on multiple machines :-/
This should be fixed now and your netlink changes pushed out to net-next.
Sorry about that.
^ permalink raw reply
* [PATCH net-next] tcp/fq: move back to CLOCK_MONOTONIC
From: Eric Dumazet @ 2018-09-28 17:28 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Leonard Crestez
In the recent TCP/EDT patch series, I switched TCP and sch_fq
clocks from MONOTONIC to TAI, in order to meet the choice done
earlier for sch_etf packet scheduler.
But sure enough, this broke some setups were the TAI clock
jumps forward (by almost 50 year...), as reported
by Leonard Crestez.
If we want to converge later, we'll probably need to add
an skb field to differentiate the clock bases, or a socket option.
In the meantime, an UDP application will need to use CLOCK_MONOTONIC
base for its SCM_TXTIME timestamps if using fq packet scheduler.
Fixes: 72b0094f9182 ("tcp: switch tcp_clock_ns() to CLOCK_TAI base")
Fixes: 142537e41923 ("net_sched: sch_fq: switch to CLOCK_TAI")
Fixes: fd2bca2aa789 ("tcp: switch internal pacing timer to CLOCK_TAI")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Leonard Crestez <leonard.crestez@nxp.com>
---
include/net/tcp.h | 2 +-
net/ipv4/tcp_timer.c | 2 +-
net/sched/sch_fq.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index ff15d8e0d525715b17671e64f6abdead9df0a8f3..0d2929223c703c0aaabef0d485aabf7dc707aae1 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -732,7 +732,7 @@ void tcp_send_window_probe(struct sock *sk);
static inline u64 tcp_clock_ns(void)
{
- return ktime_get_tai_ns();
+ return ktime_get_ns();
}
static inline u64 tcp_clock_us(void)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 4f661e178da8465203266ff4dfa3e8743e60ff82..61023d50cd604d5e19464a32c33b65d29c75c81e 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -758,7 +758,7 @@ void tcp_init_xmit_timers(struct sock *sk)
{
inet_csk_init_xmit_timers(sk, &tcp_write_timer, &tcp_delack_timer,
&tcp_keepalive_timer);
- hrtimer_init(&tcp_sk(sk)->pacing_timer, CLOCK_TAI,
+ hrtimer_init(&tcp_sk(sk)->pacing_timer, CLOCK_MONOTONIC,
HRTIMER_MODE_ABS_PINNED_SOFT);
tcp_sk(sk)->pacing_timer.function = tcp_pace_kick;
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 628a2cdcfc6f2fa69d9402f06881949d2e1423d9..338222a6c664b1825aaada4355e2fc0a01db9c73 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -412,7 +412,7 @@ static void fq_check_throttled(struct fq_sched_data *q, u64 now)
static struct sk_buff *fq_dequeue(struct Qdisc *sch)
{
struct fq_sched_data *q = qdisc_priv(sch);
- u64 now = ktime_get_tai_ns();
+ u64 now = ktime_get_ns();
struct fq_flow_head *head;
struct sk_buff *skb;
struct fq_flow *f;
@@ -776,7 +776,7 @@ static int fq_init(struct Qdisc *sch, struct nlattr *opt,
q->fq_trees_log = ilog2(1024);
q->orphan_mask = 1024 - 1;
q->low_rate_threshold = 550000 / 8;
- qdisc_watchdog_init_clockid(&q->watchdog, sch, CLOCK_TAI);
+ qdisc_watchdog_init_clockid(&q->watchdog, sch, CLOCK_MONOTONIC);
if (opt)
err = fq_change(sch, opt, extack);
@@ -831,7 +831,7 @@ static int fq_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
st.flows_plimit = q->stat_flows_plimit;
st.pkts_too_long = q->stat_pkts_too_long;
st.allocation_errors = q->stat_allocation_errors;
- st.time_next_delayed_flow = q->time_next_delayed_flow - ktime_get_tai_ns();
+ st.time_next_delayed_flow = q->time_next_delayed_flow - ktime_get_ns();
st.flows = q->flows;
st.inactive_flows = q->inactive_flows;
st.throttled_flows = q->throttled_flows;
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: change bridge maintainers
From: David Miller @ 2018-09-28 17:28 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20180927084701.3468-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 27 Sep 2018 10:47:01 +0200
> I haven't been doing reviews only but not active development on bridge
> code for several years. Roopa and Nikolay have been doing most of
> the new features and have agreed to take over as new co-maintainers.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Thanks for all of the years of watching over the bridge code Stephen.
Applied.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: support combinations of FEC modes
From: Edward Cree @ 2018-09-28 17:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ariel Almog, linville, Linux Netdev List, ganeshgr,
jakub.kicinski, dustin, dirk.vandermerwe, shayag, ariela
In-Reply-To: <20180928164553.GB22858@lunn.ch>
On 28/09/18 17:45, Andrew Lunn wrote:
> Now is a good time to change the API, since we are moving to a netlink
> socket. Which is why these questions were asked in the first place...
OK, well, I've posted sfc's semantics and view-from-the-hardware*; now
patiently waiting for other NIC vendors to chime in so we can try to
converge on something consistent.
Then again, since they've been CCed since the original patch three weeks
ago, we might be waiting a while :-(
Regarding Ariel Almog's suggested semantics, it seems like they have the
'auto' bit just encoding 'more than one non-auto bit', which is
redundant (i.e. off|rs is always off|rs|auto, whereas rs is never
rs|auto). I don't see how that would be useful.
-Ed
* One complication I left out: we actually have _three_ pairs of sup/req
bits, because we separate 'BaseR for 10G/40G/100G' from 'BaseR for
25G/50G'. I don't know the details of why our HW does this (or why
100G isn't lumped in with the other 25ers) but I think it has to do
with Horrific Ethernet Spec Arcana Man Was Not Meant To Know™.
^ permalink raw reply
* Re: bond: take rcu lock in bond_poll_controller
From: Cong Wang @ 2018-09-28 17:31 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Network Developers
In-Reply-To: <20180928172556.arqk7ntmnz6lhb6d@codemonkey.org.uk>
On Fri, Sep 28, 2018 at 10:25 AM Dave Jones <davej@codemonkey.org.uk> wrote:
>
> On Fri, Sep 28, 2018 at 09:55:52AM -0700, Cong Wang wrote:
> > On Fri, Sep 28, 2018 at 9:18 AM Dave Jones <davej@codemonkey.org.uk> wrote:
> > >
> > > Callers of bond_for_each_slave_rcu are expected to hold the rcu lock,
> > > otherwise a trace like below is shown
> >
> > So why not take rcu read lock in netpoll_send_skb_on_dev() where
> > RCU is also assumed?
>
> that does seem to solve the backtrace spew I saw too, so if that's
> preferable I can respin the patch.
>From my observations, netpoll_send_skb_on_dev() does not take
RCU read lock _and_ it relies on rcu read lock because it calls
rcu_dereference_bh().
If my observation is correct, you should catch a RCU warning like
this but within netpoll_send_skb_on_dev().
>
> > As I said, I can't explain why you didn't trigger the RCU warning in
> > netpoll_send_skb_on_dev()...
>
> netpoll_send_skb_on_dev takes the rcu lock itself.
Could you please point me where exactly is the rcu lock here?
I am too stupid to see it. :)
^ permalink raw reply
* Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops
From: Pravin Shelar @ 2018-09-28 17:12 UTC (permalink / raw)
To: Yifeng Sun; +Cc: Linux Kernel Network Developers
In-Reply-To: <1537987214-6414-1-git-send-email-pkusunyifeng@gmail.com>
On Wed, Sep 26, 2018 at 11:40 AM Yifeng Sun <pkusunyifeng@gmail.com> wrote:
>
> This patch fixes the bug that all datapath and vport ops are returning
> wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
>
> Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
I am surprised this was not found earlier.
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] Update maintainers for bnx2/bnx2x/qlge/qlcnic drivers.
From: David Miller @ 2018-09-28 17:32 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Ameen.Rahman
In-Reply-To: <20180927045703.6700-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed, 26 Sep 2018 21:57:03 -0700
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Ameen Rahman <Ameen.Rahman@cavium.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net 1/1] qed: Fix shmem structure inconsistency between driver and the mfw.
From: David Miller @ 2018-09-28 17:40 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20180927111210.14203-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Thu, 27 Sep 2018 04:12:10 -0700
> The structure shared between driver and the management FW (mfw) differ in
> sizes. This would lead to issues when driver try to access the structure
> members which are not-aligned with the mfw copy e.g., data_ptr usage in the
> case of mfw_tlv request.
> Align the driver structure with mfw copy, add reserved field(s) to driver
> structure for the members not used by the driver.
>
> Fixes: dd006921d ("qed: Add MFW interfaces for TLV request support.)
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Applied and queued up for -stable.
In the future please use 12 digits of SHA1_ID for Fixes tags. I fixed
it up for you this time.
Thanks.
^ permalink raw reply
* Re: pull-request: mac80211 2018-09-27
From: David Miller @ 2018-09-28 17:42 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20180927111851.8058-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 27 Sep 2018 13:18:50 +0200
> Here's another - unfortunately pretty large - set of fixes
> for the current cycle. The changes are pretty simple or even
> trivial though.
>
> Please pull and let me know if there's any problem.
Pulled.
If they are all legit fixes, how can I object, right? :)
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: explicitly zero is_sticky in fdb_create
From: David Miller @ 2018-09-28 17:43 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, stephen, bridge
In-Reply-To: <20180927120510.7314-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 27 Sep 2018 15:05:10 +0300
> We need to explicitly zero is_sticky when creating a new fdb, otherwise
> we might get a stale value for a new entry.
>
> Fixes: 435f2e7cc0b7 ("net: bridge: add support for sticky fdb entries")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, thanks Nikolay.
^ permalink raw reply
* Re: [PATCH net-next] selftests: forwarding: test for bridge sticky flag
From: David Miller @ 2018-09-28 17:45 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa
In-Reply-To: <20180927133513.14175-2-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 27 Sep 2018 16:35:13 +0300
> This test adds an fdb entry with the sticky flag and sends traffic from
> a different port with the same mac as a source address expecting the entry
> to not change ports if the flag is operating correctly.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 03/11] net: fib_multipath_hash() - use new style struct initializer instead of memset
From: David Ahern @ 2018-09-28 17:47 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller; +Cc: netdev
In-Reply-To: <20180927230017.15398-3-zenczykowski@gmail.com>
On 9/27/18 5:00 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
> net/ipv4/route.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 048919713f4e..17953a52fbd0 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1821,12 +1821,11 @@ static void ip_multipath_l3_keys(const struct sk_buff *skb,
> int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
> const struct sk_buff *skb, struct flow_keys *flkeys)
> {
> - struct flow_keys hash_keys;
> + struct flow_keys hash_keys = {};
> u32 mhash;
>
> switch (net->ipv4.sysctl_fib_multipath_hash_policy) {
> case 0:
> - memset(&hash_keys, 0, sizeof(hash_keys));
> hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
> if (skb) {
> ip_multipath_l3_keys(skb, &hash_keys);
> @@ -1845,8 +1844,6 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
> if (skb->l4_hash)
> return skb_get_hash_raw(skb) >> 1;
>
> - memset(&hash_keys, 0, sizeof(hash_keys));
> -
> if (!flkeys) {
> skb_flow_dissect_flow_keys(skb, &keys, flag);
> flkeys = &keys;
> @@ -1859,7 +1856,6 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
> hash_keys.ports.dst = flkeys->ports.dst;
> hash_keys.basic.ip_proto = flkeys->basic.ip_proto;
> } else {
> - memset(&hash_keys, 0, sizeof(hash_keys));
> hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
> hash_keys.addrs.v4addrs.src = fl4->saddr;
> hash_keys.addrs.v4addrs.dst = fl4->daddr;
>
NACK on this one.
This is the hot path and the memset was done right before use for least
overhead.
^ permalink raw reply
* Re: [PATCH 04/11] net: ip6_multipath_l3_keys() - use new style struct initializer instead of memset
From: David Ahern @ 2018-09-28 17:48 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller; +Cc: netdev
In-Reply-To: <20180927230017.15398-4-zenczykowski@gmail.com>
On 9/27/18 5:00 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
> net/ipv6/route.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index d28f83e01593..9cb024451fc5 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1981,12 +1981,11 @@ static void ip6_multipath_l3_keys(const struct sk_buff *skb,
> u32 rt6_multipath_hash(const struct net *net, const struct flowi6 *fl6,
> const struct sk_buff *skb, struct flow_keys *flkeys)
> {
> - struct flow_keys hash_keys;
> + struct flow_keys hash_keys = {};
> u32 mhash;
>
> switch (ip6_multipath_hash_policy(net)) {
> case 0:
> - memset(&hash_keys, 0, sizeof(hash_keys));
> hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
> if (skb) {
> ip6_multipath_l3_keys(skb, &hash_keys, flkeys);
> @@ -2006,8 +2005,6 @@ u32 rt6_multipath_hash(const struct net *net, const struct flowi6 *fl6,
> if (skb->l4_hash)
> return skb_get_hash_raw(skb) >> 1;
>
> - memset(&hash_keys, 0, sizeof(hash_keys));
> -
> if (!flkeys) {
> skb_flow_dissect_flow_keys(skb, &keys, flag);
> flkeys = &keys;
> @@ -2019,7 +2016,6 @@ u32 rt6_multipath_hash(const struct net *net, const struct flowi6 *fl6,
> hash_keys.ports.dst = flkeys->ports.dst;
> hash_keys.basic.ip_proto = flkeys->basic.ip_proto;
> } else {
> - memset(&hash_keys, 0, sizeof(hash_keys));
> hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
> hash_keys.addrs.v6addrs.src = fl6->saddr;
> hash_keys.addrs.v6addrs.dst = fl6->daddr;
>
ditto for this one.
^ permalink raw reply
* [PATCH] openvswitch: load NAT helper
From: Flavio Leitner @ 2018-09-28 17:51 UTC (permalink / raw)
To: netfilter-devel, netdev, dev; +Cc: Pravin B Shelar, Flavio Leitner
Load the respective NAT helper module if the flow uses it.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
net/openvswitch/conntrack.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 86a75105af1a..7e9a5283e236 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1312,6 +1312,10 @@ static int ovs_ct_add_helper(struct ovs_conntrack_info *info, const char *name,
rcu_assign_pointer(help->helper, helper);
info->helper = helper;
+
+ if (info->nat)
+ request_module("ip_nat_%s", name);
+
return 0;
}
--
2.14.4
^ permalink raw reply related
* Re: [PATCH iproute2 net-next] bridge: fdb: add support for sticky flag
From: David Ahern @ 2018-09-28 17:54 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev; +Cc: roopa
In-Reply-To: <20180927133513.14175-1-nikolay@cumulusnetworks.com>
On 9/27/18 7:35 AM, Nikolay Aleksandrov wrote:
> Add support for the new sticky flag that can be set on fdbs and update the
> man page.
>
> CC: David Ahern <dsahern@gmail.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> bridge/fdb.c | 9 +++++++--
> man/man8/bridge.8 | 6 +++++-
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* [PATCH] Revert "openvswitch: Fix template leak in error cases."
From: Flavio Leitner @ 2018-09-28 17:55 UTC (permalink / raw)
To: netfilter-devel, netdev, dev
Cc: Pravin B Shelar, Joe Stringer, Flavio Leitner
This reverts commit 90c7afc96cbbd77f44094b5b651261968e97de67.
When the commit was merged, the code used nf_ct_put() to free
the entry, but later on commit 76644232e612 ("openvswitch: Free
tmpl with tmpl_free.") replaced that with nf_ct_tmpl_free which
is a more appropriate. Now the original problem is removed.
Then 44d6e2f27328 ("net: Replace NF_CT_ASSERT() with WARN_ON().")
replaced a debug assert with a WARN_ON() which is trigged now.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
net/openvswitch/conntrack.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 86a75105af1a..0aeb34c6389d 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1624,10 +1624,6 @@ int ovs_ct_copy_action(struct net *net, const struct nlattr *attr,
OVS_NLERR(log, "Failed to allocate conntrack template");
return -ENOMEM;
}
-
- __set_bit(IPS_CONFIRMED_BIT, &ct_info.ct->status);
- nf_conntrack_get(&ct_info.ct->ct_general);
-
if (helper) {
err = ovs_ct_add_helper(&ct_info, helper, key, log);
if (err)
@@ -1639,6 +1635,8 @@ int ovs_ct_copy_action(struct net *net, const struct nlattr *attr,
if (err)
goto err_free_ct;
+ __set_bit(IPS_CONFIRMED_BIT, &ct_info.ct->status);
+ nf_conntrack_get(&ct_info.ct->ct_general);
return 0;
err_free_ct:
__ovs_ct_free_action(&ct_info);
--
2.14.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox