* [PATCH net-next] net: davinci_mdio: fix building error without CONFIG_OF
From: YueHaibing @ 2018-05-29 11:56 UTC (permalink / raw)
To: davem, grygorii.strashko, muvarov
Cc: netdev, linux-kernel, andrew, fugang.duan, linux-omap, YueHaibing
gcc report a build error when compiling without CONFIG_OF
drivers/net/ethernet/ti/davinci_mdio.c: In function ‘davinci_mdio_probe’:
drivers/net/ethernet/ti/davinci_mdio.c:380:9: error: implicit declaration of function ‘davinci_mdio_probe_dt’ [-Werror=implicit-function-declaration]
ret = davinci_mdio_probe_dt(&data->pdata, pdev);
^
Fixes: 9eae9c7d0875 ("drivers: net: davinci_mdio: enable pm runtime auto for ti cpsw-mdio")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 8ac7283..6e544d9 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -339,9 +339,7 @@ static int davinci_mdio_probe_dt(struct mdio_platform_data *data,
return 0;
}
-#endif
-#if IS_ENABLED(CONFIG_OF)
static const struct davinci_mdio_of_param of_cpsw_mdio_data = {
.autosuspend_delay_ms = 100,
};
@@ -352,6 +350,12 @@ static const struct of_device_id davinci_mdio_of_mtable[] = {
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_mdio_of_mtable);
+#else
+static int davinci_mdio_probe_dt(struct mdio_platform_data *data,
+ struct platform_device *pdev)
+{
+ return -EINVAL;
+}
#endif
static int davinci_mdio_probe(struct platform_device *pdev)
--
2.7.0
^ permalink raw reply related
* Re: INFO: rcu detected stall in is_bpf_text_address
From: Andrey Konovalov @ 2018-05-29 11:53 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Xin Long, Eric Dumazet, syzbot, ast, Daniel Borkmann, LKML,
network dev, syzkaller-bugs
In-Reply-To: <20180528182230.GE3787@localhost.localdomain>
On Mon, May 28, 2018 at 8:22 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> The reproducer has:
> r0 = socket$inet6(0xa, 0x1, 0x8010000000000084)
>
> Considering socket() prototype uses an int for the 3rd argument, how
> should I interpret this 64b value?
>
> 0x84 is IPPROTO_SCTP, but don't know about the 0x8010000000000000 in
> there.
Hi Marcelo,
It gets stripped to int the same way C does it, so the value would be 0x84.
Thanks!
^ permalink raw reply
* Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs
From: Neil Horman @ 2018-05-29 11:41 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Dmitry Vyukov, Michael Tuexen, Xin Long, network dev, linux-sctp,
David Miller, David Ahern, Eric Dumazet, syzkaller
In-Reply-To: <20180528194315.GB3788@localhost.localdomain>
On Mon, May 28, 2018 at 04:43:15PM -0300, Marcelo Ricardo Leitner wrote:
> On Sat, May 26, 2018 at 09:01:00PM -0400, Neil Horman wrote:
> > On Sat, May 26, 2018 at 05:50:39PM +0200, Dmitry Vyukov wrote:
> > > On Sat, May 26, 2018 at 5:42 PM, Michael Tuexen
> > > <michael.tuexen@lurchi.franken.de> wrote:
> > > >> On 25. May 2018, at 21:13, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >>
> > > >> On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
> > > >>> syzbot reported a rcu_sched self-detected stall on CPU which is caused
> > > >>> by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
> > > >>> value, hb_timer will get stuck there, as in its timer handler it starts
> > > >>> this timer again with this value, then goes to the timer handler again.
> > > >>>
> > > >>> This problem is there since very beginning, and thanks to Eric for the
> > > >>> reproducer shared from a syzbot mail.
> > > >>>
> > > >>> This patch fixes it by not allowing to set rto_min with a value below
> > > >>> 200 msecs, which is based on TCP's, by either setsockopt or sysctl.
> > > >>>
> > > >>> Reported-by: syzbot+3dcd59a1f907245f891f@syzkaller.appspotmail.com
> > > >>> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > > >>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > >>> ---
> > > >>> include/net/sctp/constants.h | 1 +
> > > >>> net/sctp/socket.c | 10 +++++++---
> > > >>> net/sctp/sysctl.c | 3 ++-
> > > >>> 3 files changed, 10 insertions(+), 4 deletions(-)
> > > >>>
> > > >>> diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
> > > >>> index 20ff237..2ee7a7b 100644
> > > >>> --- a/include/net/sctp/constants.h
> > > >>> +++ b/include/net/sctp/constants.h
> > > >>> @@ -277,6 +277,7 @@ enum { SCTP_MAX_GABS = 16 };
> > > >>> #define SCTP_RTO_INITIAL (3 * 1000)
> > > >>> #define SCTP_RTO_MIN (1 * 1000)
> > > >>> #define SCTP_RTO_MAX (60 * 1000)
> > > >>> +#define SCTP_RTO_HARD_MIN 200
> > > >>>
> > > >>> #define SCTP_RTO_ALPHA 3 /* 1/8 when converted to right shifts. */
> > > >>> #define SCTP_RTO_BETA 2 /* 1/4 when converted to right shifts. */
> > > >>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > >>> index ae7e7c6..6ef12c7 100644
> > > >>> --- a/net/sctp/socket.c
> > > >>> +++ b/net/sctp/socket.c
> > > >>> @@ -3029,7 +3029,8 @@ static int sctp_setsockopt_nodelay(struct sock *sk, char __user *optval,
> > > >>> * be changed.
> > > >>> *
> > > >>> */
> > > >>> -static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval, unsigned int optlen)
> > > >>> +static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval,
> > > >>> + unsigned int optlen)
> > > >>> {
> > > >>> struct sctp_rtoinfo rtoinfo;
> > > >>> struct sctp_association *asoc;
> > > >>> @@ -3056,10 +3057,13 @@ static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval, unsigne
> > > >>> else
> > > >>> rto_max = asoc ? asoc->rto_max : sp->rtoinfo.srto_max;
> > > >>>
> > > >>> - if (rto_min)
> > > >>> + if (rto_min) {
> > > >>> + if (rto_min < SCTP_RTO_HARD_MIN)
> > > >>> + return -EINVAL;
> > > >>> rto_min = asoc ? msecs_to_jiffies(rto_min) : rto_min;
> > > >>> - else
> > > >>> + } else {
> > > >>> rto_min = asoc ? asoc->rto_min : sp->rtoinfo.srto_min;
> > > >>> + }
> > > >>>
> > > >>> if (rto_min > rto_max)
> > > >>> return -EINVAL;
> > > >>> diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
> > > >>> index 33ca5b7..7ec854a 100644
> > > >>> --- a/net/sctp/sysctl.c
> > > >>> +++ b/net/sctp/sysctl.c
> > > >>> @@ -52,6 +52,7 @@ static int rto_alpha_min = 0;
> > > >>> static int rto_beta_min = 0;
> > > >>> static int rto_alpha_max = 1000;
> > > >>> static int rto_beta_max = 1000;
> > > >>> +static int rto_hard_min = SCTP_RTO_HARD_MIN;
> > > >>>
> > > >>> static unsigned long max_autoclose_min = 0;
> > > >>> static unsigned long max_autoclose_max =
> > > >>> @@ -116,7 +117,7 @@ static struct ctl_table sctp_net_table[] = {
> > > >>> .maxlen = sizeof(unsigned int),
> > > >>> .mode = 0644,
> > > >>> .proc_handler = proc_sctp_do_rto_min,
> > > >>> - .extra1 = &one,
> > > >>> + .extra1 = &rto_hard_min,
> > > >>> .extra2 = &init_net.sctp.rto_max
> > > >>> },
> > > >>> {
> > > >>> --
> > > >>> 2.1.0
> > > >>>
> > > >>> --
> > > >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> > > >>> the body of a message to majordomo@vger.kernel.org
> > > >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > >>>
> > > >> Patch looks fine, you probably want to note this hard minimum in man(7) sctp as
> > > >> well
> > > >>
> > > > I'm aware of some signalling networks which use RTO.min of smaller values than 200ms.
> > > > So could this be reduced?
> > >
> > > Hi Michael,
> > >
> > > What value do they use?
> > >
> > > Xin, Neil, is there more principled way of ensuring that a timer won't
> > > cause a hard CPU stall? There are slow machines and there are slow
> > > kernels (in particular syzbot kernel has tons of debug configs
> > > enabled). 200ms _should_ not cause problems because we did not see
> > > them with tcp. But it's hard to say what's the low limit as we are
> > > trying to put a hard upper bound on execution time of a complex
> > > section of code. Is there something like cond_resched for timers?
> > Unfortunately, Theres not really a way to do conditional rescheduling of timers,
> > additionally, we have a problem because the timer is reset as a side effect of
> > the SCTP state machine, and so the execution time between timer updates has a
> > signifcant amount of jitter (meaning its a pretty hard value to calibrate,
> > unless you just select a 'safe' large value for the floor).
> >
> > What we might could do (though this might impact the protocol function is change
> > the timer update side effects to simply set a flag, and consistently update the
> > timers on exit from sctp_do_sm, so they don't re-arm until all state machine
> > processing is complete. Anyone have any thoughts on that?
>
> I was reviewing all this again and I'm thinking that we are missing
> the real point. With the parameters that reproducer [1] has, setting
> those very low RTO parameters, it causes the timer to actually
> busyloop on the heartbeats, as Xin had explained.
>
> But thing is, it busy loops not just because RTO is too low, but
> because hbinterval was not accounted.
>
> /* What is the next timeout value for this transport? */
> unsigned long sctp_transport_timeout(struct sctp_transport *trans)
> {
> /* RTO + timer slack +/- 50% of RTO */
> unsigned long timeout = trans->rto >> 1; <-- [a]
>
> if (trans->state != SCTP_UNCONFIRMED &&
> trans->state != SCTP_PF) <--- [2]
> timeout += trans->hbinterval;
>
> return timeout;
> }
>
> The if() in [2] is to speed up path verification before using them, as
> per the commit changelog. Secondary paths added on processing the
> cookie are created with status SCTP_UNCONFIRMED, and HB timers are
> started in the sequence:
> sctp_sf_do_5_1D_ce
> -> sctp_process_init
> |> sctp_process_param
> | -> sctp_assoc_add_peer(asoc, &addr, gfp, SCTP_UNCONFIRMED)
> '> sctp_add_cmd_sf(commands, SCTP_CMD_HB_TIMERS_START, SCTP_NULL());
>
> which starts the timer using only the small RTO for secondary paths:
> static void sctp_cmd_hb_timers_start(struct sctp_cmd_seq *cmds,
> struct sctp_association *asoc)
> {
> struct sctp_transport *t;
>
> /* Start a heartbeat timer for each transport on the association.
> * hold a reference on the transport to make sure none of
> * the needed data structures go away.
> */
> list_for_each_entry(t, &asoc->peer.transport_addr_list, transports)
> sctp_transport_reset_hb_timer(t);
> }
>
> But if the system is too busy generating HBs, it likely won't process
> incoming HB ACKs, which would stop the loop as it would mark the
> transport as Active.
>
> I'm now thinking a better fix would be to have a specific way to
> kickstart these initial heartbeets, and then always use hbinterval on
> subsequent ones.
>
I like the idea, but I don't think we can just use the hbinterval to set the
timeout. That said, it seems like we should always be using the HB interval,
not just on unconfirmed or partially failed transports. From the RFC:
On an idle destination address that is allowed to heartbeat, it is
recommended that a HEARTBEAT chunk is sent once per RTO of that
destination address plus the protocol parameter 'HB.interval', with
jittering of +/- 50% of the RTO value, and exponential backoff of the
RTO if the previous HEARTBEAT is unanswered
It seems like we should be adding it to the timer expiration universally. By my
read, we've never done this quite right. And yes, I agree, if we account this
properly, we will avoid this issue.
Its also probably important to note here, that, like RTO.min currently, there is
no hard floor to the heartbeat interval, and the RFC is silent on what it should
be. So it would be possible to still find ourselves in this situation if we set
the interval to 0 from userspace. Is it worth considering a floor on the
minimum hb interval of the rto is to have no floor?
Neil
> This would not only fix the issue, but also improve the time we need
> to identify the transports as Active upon association start, which is
> currently RTO/2 (equals to 500ms by default).
>
> While working on this, I got myself wondering how HZ can affect the
> stack with such small RTO. If we have HZ=250, for example, we probably
> should be careful when doing calcs such as in mark [a] to not let it
> tend to 0. This should not be related to the reported issue as
> syzkaller was using HZ=1000.
>
> (I didn't do any tests, this is only based on code review so far)
>
> 1. https://syzkaller.appspot.com/x/repro.syz?x=1079cf8f800000
> 2. ad8fec1720e0 ("[SCTP]: Verify all the paths to a peer via heartbeat before using them.")
> b. https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
>
^ permalink raw reply
* [PATCH bpf-next] bpf: clean up eBPF helpers documentation
From: Quentin Monnet @ 2018-05-29 11:27 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, oss-drivers, quentin.monnet
These are minor edits for the eBPF helpers documentation in
include/uapi/linux/bpf.h.
The main fix consists in removing "BPF_FIB_LOOKUP_", because it ends
with a non-escaped underscore that gets interpreted by rst2man and
produces the following message in the resulting manual page:
DOCUTILS SYSTEM MESSAGES
System Message: ERROR/3 (/tmp/bpf-helpers.rst:, line 1514)
Unknown target name: "bpf_fib_lookup".
Other edits consist in:
- Improving formatting for flag values for "bpf_fib_lookup()" helper.
- Emphasising a parameter name in description of the return value for
"bpf_get_stack()" helper.
- Removing unnecessary blank lines between "Description" and "Return"
sections for the few helpers that would use it, for consistency.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
include/uapi/linux/bpf.h | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index cc68787f2d97..3f556b35ac8d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1010,7 +1010,6 @@ union bpf_attr {
* ::
*
* # sysctl kernel.perf_event_max_stack=<new value>
- *
* Return
* The positive or null stack id on success, or a negative error
* in case of failure.
@@ -1821,10 +1820,9 @@ union bpf_attr {
* ::
*
* # sysctl kernel.perf_event_max_stack=<new value>
- *
* Return
- * a non-negative value equal to or less than size on success, or
- * a negative error in case of failure.
+ * A non-negative value equal to or less than *size* on success,
+ * or a negative error in case of failure.
*
* int skb_load_bytes_relative(const struct sk_buff *skb, u32 offset, void *to, u32 len, u32 start_header)
* Description
@@ -1845,7 +1843,6 @@ union bpf_attr {
* in socket filters where *skb*\ **->data** does not always point
* to the start of the mac header and where "direct packet access"
* is not available.
- *
* Return
* 0 on success, or a negative error in case of failure.
*
@@ -1861,16 +1858,18 @@ union bpf_attr {
* rt_metric is set to metric from route.
*
* *plen* argument is the size of the passed in struct.
- * *flags* argument can be one or more BPF_FIB_LOOKUP_ flags:
+ * *flags* argument can be a combination of one or more of the
+ * following values:
*
- * **BPF_FIB_LOOKUP_DIRECT** means do a direct table lookup vs
- * full lookup using FIB rules
- * **BPF_FIB_LOOKUP_OUTPUT** means do lookup from an egress
- * perspective (default is ingress)
+ * **BPF_FIB_LOOKUP_DIRECT**
+ * Do a direct table lookup vs full lookup using FIB
+ * rules.
+ * **BPF_FIB_LOOKUP_OUTPUT**
+ * Perform lookup from an egress perspective (default is
+ * ingress).
*
* *ctx* is either **struct xdp_md** for XDP programs or
* **struct sk_buff** tc cls_act programs.
- *
* Return
* Egress device index on success, 0 if packet needs to continue
* up the stack for further processing or a negative error in case
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path
From: Yafang Shao @ 2018-05-29 11:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, Song Liu, David Miller, netdev, LKML
In-Reply-To: <68b62912-21d5-c238-7536-12928670a08a@gmail.com>
On Tue, May 29, 2018 at 12:53 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 05/28/2018 05:41 PM, Yafang Shao wrote:
>
>> OK.
>>
>> And what about introducing a new helper tcp_hdr_fast() ?
>>
>> /* use it when tcp header has not been pulled yet */
>> static inline struct tcphdr *tcp_hdr_fast(const struct sk_buff *skb)
>>
>> {
>>
>> return (const struct tcphdr *)skb->data;
>>
>> }
>>
>>
>> That could help us to use this optimized one instead of the original
>> one if possilbe.
>
>
> I would rather not add such macro...
>
> The call site needs to know what is going on, so having a macro like that would not help.
OK
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] net: bridge: Notify about bridge VLANs
From: Dan Carpenter @ 2018-05-29 11:02 UTC (permalink / raw)
To: Ido Schimmel
Cc: devel, andrew, f.fainelli, vivien.didelot, nikolay, netdev,
bridge, idosch, jiri, razvan.stefanescu, gregkh, Petr Machata,
davem
In-Reply-To: <20180529105853.GA13795@splinter.mtl.com>
On Tue, May 29, 2018 at 01:58:53PM +0300, Ido Schimmel wrote:
> On Tue, May 29, 2018 at 01:46:09PM +0300, Dan Carpenter wrote:
> > It occured to me that I should read the cover letter and here are the
> > answers I was looking for. But the cover letter isn't saved after the
> > commits are merged.
>
> DaveM adds the cover letter to the merge commit.
That's true but it doesn't help. When I want to find why line of code
is there I look up the commit message, not the merge commit.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] net: bridge: Notify about bridge VLANs
From: Ido Schimmel @ 2018-05-29 10:58 UTC (permalink / raw)
To: Dan Carpenter
Cc: Petr Machata, netdev, devel, bridge, f.fainelli, andrew, nikolay,
gregkh, vivien.didelot, idosch, jiri, razvan.stefanescu, davem
In-Reply-To: <20180529104609.jqbql6ts2rbb7k3l@mwanda>
On Tue, May 29, 2018 at 01:46:09PM +0300, Dan Carpenter wrote:
> It occured to me that I should read the cover letter and here are the
> answers I was looking for. But the cover letter isn't saved after the
> commits are merged.
DaveM adds the cover letter to the merge commit.
^ permalink raw reply
* Re: [PATCH net-next v3 6/7] net: bridge: Notify about bridge VLANs
From: Dan Carpenter @ 2018-05-29 10:55 UTC (permalink / raw)
To: Petr Machata
Cc: devel, andrew, f.fainelli, vivien.didelot, nikolay, netdev,
bridge, idosch, jiri, razvan.stefanescu, gregkh, davem
In-Reply-To: <645c0bde19cffebb0dc603872ef6ab45e9fbf0b6.1527519997.git.petrm@mellanox.com>
On Mon, May 28, 2018 at 05:11:04PM +0200, Petr Machata wrote:
> @@ -580,6 +591,9 @@ int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags, bool *changed)
> vg->num_vlans++;
> *changed = true;
> }
> + ret = br_switchdev_port_vlan_add(br->dev, vid, flags);
> + if (ret && ret != -EOPNOTSUPP)
> + return ret;
We should probably do some error handling instead of returning directly?
> if (__vlan_add_flags(vlan, flags))
> *changed = true;
>
regards,
dan caprenter
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] net: bridge: Notify about bridge VLANs
From: Dan Carpenter @ 2018-05-29 10:46 UTC (permalink / raw)
To: Petr Machata
Cc: devel, andrew, f.fainelli, vivien.didelot, nikolay, netdev,
bridge, idosch, jiri, razvan.stefanescu, gregkh, davem
In-Reply-To: <cover.1527519997.git.petrm@mellanox.com>
On Mon, May 28, 2018 at 05:10:22PM +0200, Petr Machata wrote:
> In commit 946a11e7408e ("mlxsw: spectrum_span: Allow bridge for gretap
> mirror"), mlxsw got support for offloading mirror-to-gretap such that
> the underlay packet path involves a bridge. In that case, the offload is
> also influenced by PVID setting of said bridge. However, changes to VLAN
> configuration of the bridge itself do not generate switchdev
> notifications, so there's no mechanism to prod mlxsw to update the
> offload when these settings change.
>
> In this patchset, the problem is resolved by distributing the switchdev
> notification SWITCHDEV_OBJ_ID_PORT_VLAN also for configuration changes
> on bridge VLANs. Since stacked devices distribute the notification to
> lower devices, such event eventually reaches the driver, which can
> determine whether it's a bridge or port VLAN by inspecting orig_dev.
>
> To keep things consistent, the newly-distributed notifications observe
> the same protocol as the existing ones: dual prepare/commit, with
> -EOPNOTSUPP indicating lack of support, even though there's currently
> nothing to prepare for and nothing to support. Correspondingly, all
> switchdev drivers have been updated to return -EOPNOTSUPP for bridge
> VLAN notifications.
>
> In patch #1, the code to send notifications for adding and deleting is
> factored out into two named functions.
>
> In patches #2-#5, respectively for mlxsw, rocker, DSA and DPAA2 ethsw,
> the new notifications (which are not enabled yet) are ignored to
> maintain the current behavior.
>
It occured to me that I should read the cover letter and here are the
answers I was looking for. But the cover letter isn't saved after the
commits are merged. This should really be in the commit messages itself
so that we can look it up in the git history.
> In patch #6, the notification is actually enabled.
>
> In patch #7, mlxsw is changed to update offloads of mirror-to-gre also
> for bridge-related notifications.
regards,
dan carpenter
^ permalink raw reply
* [PATCH net-next] net: qcom/emac: fix unused variable
From: YueHaibing @ 2018-05-29 10:43 UTC (permalink / raw)
To: davem, timur; +Cc: netdev, linux-kernel, YueHaibing
When CONFIG_ACPI isn't set, variable qdf2400_ops/qdf2432_ops isn't used.
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:284:25: warning: ‘qdf2400_ops’ defined but not used [-Wunused-variable]
static struct sgmii_ops qdf2400_ops = {
^~~~~~~~~~~
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:276:25: warning: ‘qdf2432_ops’ defined but not used [-Wunused-variable]
static struct sgmii_ops qdf2432_ops = {
^~~~~~~~~~~
Move the declaration and functions inside the CONFIG_ACPI ifdef
to fix the warning.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 562420b..15609cb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -108,6 +108,7 @@ static void emac_sgmii_link_init(struct emac_adapter *adpt)
writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
}
+#ifdef CONFIG_ACPI
static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits)
{
struct emac_sgmii *phy = &adpt->phy;
@@ -291,7 +292,6 @@ static struct sgmii_ops qdf2400_ops = {
static int emac_sgmii_acpi_match(struct device *dev, void *data)
{
-#ifdef CONFIG_ACPI
static const struct acpi_device_id match_table[] = {
{
.id = "QCOM8071",
@@ -327,10 +327,16 @@ static int emac_sgmii_acpi_match(struct device *dev, void *data)
return 1;
}
}
-#endif
return 0;
}
+#else
+static int emac_sgmii_acpi_match(struct device *dev, void *data)
+{
+ return 0;
+}
+
+#endif
static const struct of_device_id emac_sgmii_dt_match[] = {
{
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next v3 2/7] mlxsw: spectrum_switchdev: Ignore bridge VLAN events
From: Dan Carpenter @ 2018-05-29 10:43 UTC (permalink / raw)
To: Petr Machata
Cc: devel, andrew, f.fainelli, vivien.didelot, nikolay, netdev,
bridge, idosch, jiri, razvan.stefanescu, gregkh, davem
In-Reply-To: <67c3f567cd774cae8935873072c81e5ea62dc521.1527519997.git.petrm@mellanox.com>
On Mon, May 28, 2018 at 05:10:40PM +0200, Petr Machata wrote:
> Ignore VLAN events where the orig_dev is the bridge device itself.
>
I don't know this code, and I have not looked at it either... But this
changelog just says what you are doing and not why. Is this a bug fix?
What are the user visible effects of this patch? Perhaps it is
something which will be required in the future but has no effect now?
You know how the New York Times is written for people with at least a
10th grade education? I feel like maybe if I knew this code I would
know the answers to my question, but kernel commit descriptions should
generally be written to Dan Carpenter level of education. Which is
pretty darn ignorant... Can you please resend?
regards,
dan carpenter
^ permalink raw reply
* Re: Unable to create ip alias on bridge interface
From: Akshat Kakkar @ 2018-05-29 10:41 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev
In-Reply-To: <20180529102954.r7ayncpopip6dcpr@unicorn.suse.cz>
Thanks.
Thanks a lot for clarifying all this.
On Tue, May 29, 2018 at 3:59 PM, Michal Kubecek <mkubecek@suse.cz> wrote:
> On Tue, May 29, 2018 at 03:39:05PM +0530, Akshat Kakkar wrote:
>> For following commands,
>> ip addr add 10.10.10.1/24 brd + dev br0
>> ip addr add 10.10.10.2/24 brd + dev br0
>> ip addr add 20.20.20.1/24 brd + dev br0
>> ip addr add 20.20.20.2/24 brd + dev br0
>>
>> Both 10.10.10.1 and 20.20.20.1 becomes primary. Which one will be used
>> as source IP?
>>
>> Is it nextHop of route that will decide?
>
> Unless you have an unusual routing setup, yes. When unsure, you can use
> "ip route get ..." which should tell you which route and which source
> address will be used.
>
>> And what about communication in local subnet, say ping to 10.10.10.200
>> and 20.20.20.200? Will source for both will change according to
>> destination IP?
>
> This is the same. Under "normal" circumstances, 10.10.10.1 will be used
> for targets from 10.10.10.0/24 and 20.20.20.1 for targets from
> 20.20.20.0/24.
>
> Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next v3 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
From: Dan Carpenter @ 2018-05-29 10:35 UTC (permalink / raw)
To: Petr Machata
Cc: devel, andrew, f.fainelli, vivien.didelot, nikolay, netdev,
bridge, idosch, jiri, razvan.stefanescu, gregkh, davem
In-Reply-To: <85401f20b801fa1bae3025bf1df991a9d475fe85.1527519997.git.petrm@mellanox.com>
On Mon, May 28, 2018 at 05:10:28PM +0200, Petr Machata wrote:
> /* Try switchdev op first. In case it is not supported, fallback to
> * 8021q add.
> */
> - err = switchdev_port_obj_add(dev, &v.obj);
> + int err = br_switchdev_port_vlan_add(dev, vid, flags);
> if (err == -EOPNOTSUPP)
This will introduce a checkpatch warning if you re-run with the --file
option. (I haven't tested). It's sort of ugly to put function logic in
the declaration block. That's really just for initializing variables
like "int start = 0; struct foo *p = parent_of_bar();" Do it like this
instead:
int err;
err = br_switchdev_port_vlan_add(dev, vid, flags);
if (err == -EOPNOTSUPP)
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: hide the unused 'off' variable
From: Arnd Bergmann @ 2018-05-29 10:35 UTC (permalink / raw)
To: YueHaibing
Cc: David Miller, Alexei Starovoitov, Daniel Borkmann, Networking,
Linux Kernel Mailing List
In-Reply-To: <20180529024018.12740-1-yuehaibing@huawei.com>
On Tue, May 29, 2018 at 4:40 AM, YueHaibing <yuehaibing@huawei.com> wrote:
> The local variable is only used while CONFIG_IPV6 enabled
>
> net/core/filter.c: In function ‘sk_msg_convert_ctx_access’:
> net/core/filter.c:6489:6: warning: unused variable ‘off’ [-Wunused-variable]
> int off;
> ^
> This puts it into #ifdef.
>
> Fixes: 303def35f64e ("bpf: allow sk_msg programs to read sock fields")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
I was about to send the same patch and found you had already sent one.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: Unable to create ip alias on bridge interface
From: Michal Kubecek @ 2018-05-29 10:29 UTC (permalink / raw)
To: netdev; +Cc: Akshat Kakkar
In-Reply-To: <CAA5aLPiuP8ToWLtqKvP-+X6urdQ92wbwt76SHDLn+D1oXdoOfA@mail.gmail.com>
On Tue, May 29, 2018 at 03:39:05PM +0530, Akshat Kakkar wrote:
> For following commands,
> ip addr add 10.10.10.1/24 brd + dev br0
> ip addr add 10.10.10.2/24 brd + dev br0
> ip addr add 20.20.20.1/24 brd + dev br0
> ip addr add 20.20.20.2/24 brd + dev br0
>
> Both 10.10.10.1 and 20.20.20.1 becomes primary. Which one will be used
> as source IP?
>
> Is it nextHop of route that will decide?
Unless you have an unusual routing setup, yes. When unsure, you can use
"ip route get ..." which should tell you which route and which source
address will be used.
> And what about communication in local subnet, say ping to 10.10.10.200
> and 20.20.20.200? Will source for both will change according to
> destination IP?
This is the same. Under "normal" circumstances, 10.10.10.1 will be used
for targets from 10.10.10.0/24 and 20.20.20.1 for targets from
20.20.20.0/24.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH v3 11/11] net: sched: change action API to use array of pointers to actions
From: Vlad Buslov @ 2018-05-29 10:25 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: jiri, netdev, jhs, xiyou.wangcong, davem, ast, daniel, kliteyn
In-Reply-To: <20180528213147.GF3787@localhost.localdomain>
On Mon 28 May 2018 at 21:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> On Mon, May 28, 2018 at 12:17:29AM +0300, Vlad Buslov wrote:
> ...
>> -int tcf_action_destroy(struct list_head *actions, int bind)
>> +int tcf_action_destroy(struct tc_action *actions[], int bind)
>> {
>> const struct tc_action_ops *ops;
>> - struct tc_action *a, *tmp;
>> - int ret = 0;
>> + struct tc_action *a;
>> + int ret = 0, i;
>>
>> - list_for_each_entry_safe(a, tmp, actions, list) {
>> + for (i = 0; i < TCA_ACT_MAX_PRIO && actions[i]; i++) {
> ...
>> @@ -878,10 +881,9 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
>> if (TC_ACT_EXT_CMP(a->tcfa_action, TC_ACT_GOTO_CHAIN)) {
>> err = tcf_action_goto_chain_init(a, tp);
>> if (err) {
>> - LIST_HEAD(actions);
>> + struct tc_action *actions[TCA_ACT_MAX_PRIO] = { a };
>
> Somewhat nit.. Considering tcf_action_destroy will stop at the first
> NULL, you need only 2 slots here.
Yes, I guess NULLing whole array when only first pointer is used, is
redundant. I didn't want to be too clever in this patch and made all
actions array of same size, but I don't see anything potentially
dangerous in reducing this one.
>
>>
>> - list_add_tail(&a->list, &actions);
>> - tcf_action_destroy(&actions, bind);
>> + tcf_action_destroy(actions, bind);
>> NL_SET_ERR_MSG(extack, "Failed to init TC action chain");
>> return ERR_PTR(err);
>> }
Thank you for reviewing my code!
^ permalink raw reply
* Re: [PATCH net-next v2 3/7] rocker: rocker_main: Ignore bridge VLAN events
From: Ilias Apalodimas @ 2018-05-29 10:25 UTC (permalink / raw)
To: Petr Machata
Cc: devel, f.fainelli, andrew, nikolay, netdev, bridge, idosch, jiri,
razvan.stefanescu, gregkh, vivien.didelot, davem
In-Reply-To: <708f594ac6cef4a63a6f6a28759098c4d7922976.1527503302.git.petrm@mellanox.com>
Hi Petr,
On Mon, May 28, 2018 at 12:50:09PM +0200, Petr Machata wrote:
> Ignore VLAN events where the orig_dev is the bridge device itself.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> ---
> drivers/net/ethernet/rocker/rocker_main.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
> index e73e4fe..aeafdb9 100644
> --- a/drivers/net/ethernet/rocker/rocker_main.c
> +++ b/drivers/net/ethernet/rocker/rocker_main.c
> @@ -1632,6 +1632,9 @@ rocker_world_port_obj_vlan_add(struct rocker_port *rocker_port,
> {
> struct rocker_world_ops *wops = rocker_port->rocker->wops;
>
> + if (netif_is_bridge_master(vlan->obj.orig_dev))
> + return -EOPNOTSUPP;
> +
What will happen to the "bridge vlan add dev br0 vid X pvid untagged self" when
the lower level (the driver) returns -EOPNOTSUPP? Will it avoid adding a vlan on
the bridge ?
> if (!wops->port_obj_vlan_add)
> return -EOPNOTSUPP;
>
> @@ -1647,6 +1650,9 @@ rocker_world_port_obj_vlan_del(struct rocker_port *rocker_port,
> {
> struct rocker_world_ops *wops = rocker_port->rocker->wops;
>
> + if (netif_is_bridge_master(vlan->obj.orig_dev))
> + return -EOPNOTSUPP;
> +
> if (!wops->port_obj_vlan_del)
> return -EOPNOTSUPP;
> return wops->port_obj_vlan_del(rocker_port, vlan);
> --
> 2.4.11
>
^ permalink raw reply
* Re: [PATCH v3 00/11] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-29 10:20 UTC (permalink / raw)
To: Cong Wang
Cc: Jiri Pirko, Linux Kernel Network Developers, Jamal Hadi Salim,
David Miller, Alexei Starovoitov, Daniel Borkmann, kliteyn
In-Reply-To: <CAM_iQpVMcg3wb2MvChgTLuhEgH3zad5tJR2_FVWwuhkopABorw@mail.gmail.com>
On Tue 29 May 2018 at 04:26, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> Currently, all netlink protocol handlers for updating rules, actions and
>> qdiscs are protected with single global rtnl lock which removes any
>> possibility for parallelism. This patch set is a first step to remove
>> rtnl lock dependency from TC rules update path.
>>
>> Recently, new rtnl registration flag RTNL_FLAG_DOIT_UNLOCKED was added.
>> Handlers registered with this flag are called without RTNL taken. End
>> goal is to have rule update handlers(RTM_NEWTFILTER, RTM_DELTFILTER,
>> etc.) to be registered with UNLOCKED flag to allow parallel execution.
>> However, there is no intention to completely remove or split rtnl lock
>> itself. This patch set addresses specific problems in action API that
>> prevents it from being executed concurrently.
>
>
> Great, your goal is much clear now! So can I expect this patchset is to
> _completely_ get rid of RTNL lock from action update paths, correct?
No, this patch set is preparation only and deals with specific issues in
act API. I guess I should specify it in cover letter. There is one more
patch set that changes individual actions and...
>
> I ask because this is your first step, RTNL is still acquired on upper layer,
> that is, filter update paths.
... several more patch sets that update cls API, including filter update path.
>
>
>>
>> As a preparation for executing TC rules update handlers without rtnl
>> lock, action API code was audited to determine areas that assume
>> external synchronization with rtnl lock and must be changed to allow
>> safe concurrent access with following results:
>>
>> 1. Action idr is already protected with spinlock. However, some code
>> paths assume that idr state is not changes between several
>> consecutive tcf_idr_* function calls.
>> 2. tc_action reference and bind counters are implemented as plain
>> integers. They purpose was to allow single actions to be shared
>> between multiple filters, not to provide means for concurrent
>> modification.
>> 3. tc_action 'cookie' pointer field is not protected against
>> modification.
>> 4. Action API functions, that work with set of actions, use intrusive
>> linked list, which cannot be used concurrently without additional
>> synchronization.
>> 5. Action API functions don't take reference to actions while using
>> them, assuming external synchronization with rtnl lock.
>
>
> Fair enough, thanks for the details, but some high-level things are still
> missing:
>
> 1. What lock protects action updates with your patches? Since you remove
> RTNL from these paths, I assume no lock at all except the existing spinlock?
> Please state here in your cover letter.
Next patch set updates every action implementation. However, it is safe
to apply this patchset without next one because I didn't re-register any
handlers with UNLOCKED flag yet, so all rules/actions update paths are
still synchronized with RTNL.
>
>
> 2. Assume 1) is correct, how do you guarantee an action update is atomic?
> Let's say I have action foo:
>
> struct act_foo
> {
> int a;
> int b;
> };
>
> With RTNL:
>
> rtnl_lock();
> act_foo->a = a;
> if (a == X)
> act_foo->b = b;
> rtnl_unlock();
>
> Without any lock (as I assumed):
>
>
> act_foo->a = a;
> // fast path now reads new ->a but old ->b
> if (act_foo->a == X)
> // Other slow path may be changing ->a too
> act_foo->b = b;
>
> If my assumption is correct, please explain the above question in your
> cover letter, it is very important for understanding your 11 patches.
>
> If my assumption is wrong, please be specific on which lock protects
> which paths here.
Your observation, that this patch is not enough and individual actions
must be updates in order to be executed concurrently, is correct. This
issue is dealt with in next patch set. For most of actions that require
additional synchronization, I used tcf_spinlock or rcu + atomic
exchange.
>
>
> 3. How are actions like act_mirred and act_ipt updated w/o RTNL?
>
> act_mirred requires to hold a refcnt for target device:
>
> if (dev != NULL) {
> if (ret != ACT_P_CREATED)
> dev_put(rcu_dereference_protected(m->tcfm_dev, 1));
> dev_hold(dev);
> rcu_assign_pointer(m->tcfm_dev, dev);
> m->tcfm_mac_header_xmit = mac_header_xmit;
> }
>
> Without RTNL, how is dev_put()+dev_hold() be atomic in !CREATED case?
Again, next set.
>
> act_ipt calls xt_request_find_target() and xt_check_target(), I guess both
> assumes RTNL?
Do they? Internally, target list is protected with mutex.
Anyway, third patch in this series adds 'rtnl_held' argument to action
init function, that allows actions to take(or release) rtnl lock when
necessary. It is intended to be used specifically in this kind of
situations when some external API requires caller to have rtnl lock. I
guess I should also add this info to cover letter. I have omitted it
because that argument is not used in this patch set.
>
> Or you just leave these exceptions as they are but make the rest actions
> lockless? If so, please list all of them here and describe why are they
> special.
All actions will be updated in next set, without exceptions.
>
>
> Last, since your end goal is to remove RTNL from filter update paths,
> how does it work if a tc filter block shared among different qdiscs?
> Assume a tc filter block can be shared by different qdiscs on different
> devs.
Basically, what I do with blocks in patch set, that changes
qdisc->block->chain->proto->filter tree to remove rtnl lock dependency,
is:
- Change block reference counter type to refcount_t.
- Take reference to block when using it in slow path.
- Protect block idr in tcf_net with additional spinlock.
(Same approach that I employed in current patch set for actions and
action idr)
Anything specific that I'm missing? Could you describe potential issue
with shared blocks in more details?
>
>
> Thanks!
^ permalink raw reply
* Re: Unable to create ip alias on bridge interface
From: Akshat Kakkar @ 2018-05-29 10:09 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev
In-Reply-To: <CAA5aLPimhYWGLZY9g7x8UjHbY2_R8evkXpxaNZ8kAj1iKJztMQ@mail.gmail.com>
For following commands,
ip addr add 10.10.10.1/24 brd + dev br0
ip addr add 10.10.10.2/24 brd + dev br0
ip addr add 20.20.20.1/24 brd + dev br0
ip addr add 20.20.20.2/24 brd + dev br0
Both 10.10.10.1 and 20.20.20.1 becomes primary. Which one will be used
as source IP?
Is it nextHop of route that will decide?
And what about communication in local subnet, say ping to 10.10.10.200
and 20.20.20.200? Will source for both will change according to
destination IP?
On Mon, May 28, 2018 at 11:50 PM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
> Thanks for clarifying that first ip will be used as primary ip.
> I have 2 further queries on this.
> 1. How can this survive across reboots without having a custom script
> on boot up? Like some ifcfg file,etc.
> 2. is there a way to tell to make a given ip as primary, irrespective of order?
>
> On Mon, May 28, 2018 at 5:35 PM, Michal Kubecek <mkubecek@suse.cz> wrote:
>> On Mon, May 28, 2018 at 02:35:41PM +0530, Akshat Kakkar wrote:
>>> I am having a bridge named br0 having ports eno1 and eno2 as members.
>>> I have given IP to br0 as 10.10.10.1/24
>>>
>>> Now I want to create alias on br0 as br0:1 and give IP as
>>> 10.10.10.2/24, but I am unable to.
>>>
>>> I know, we can add multiple IPs to br0 using "ip addr" command, but I
>>> dont want to do it that way as I want all outgoing connections from
>>> br0 to take src ip as 10.10.10.1. I know by providing option of "src"
>>> in all routes, things can work but this looks more like a hack and
>>> less of a solution.
>>
>> I don't understand. There are no actual aliases since kernel 2.2 and an
>> attempt to add "br0:1 with address 10.10.10.2/24" using ifconfig should
>> result in the same configuration as
>>
>> ip addr add 10.10.10.2/24 brd + label br0:1 dev br0
>>
>> where the "label br0:1" part only adds a label which allows ifconfig to
>> see the new address.
>>
>> As both addresses share the same range, you don't even have to worry
>> about source address as primary address (10.10.10.1 - or first one added
>> in general) will be used unless specified otherwise.
>>
>> Michal Kubecek
^ permalink raw reply
* Re: [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Johannes Berg @ 2018-05-29 10:01 UTC (permalink / raw)
To: Dan Carpenter
Cc: Colin King, Kalle Valo, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20180529100049.up6wzjkzmd5a3v2q@mwanda>
On Tue, 2018-05-29 at 13:00 +0300, Dan Carpenter wrote:
> On Tue, May 29, 2018 at 11:17:08AM +0200, Johannes Berg wrote:
> > On Tue, 2018-05-29 at 10:14 +0100, Colin King wrote:
> > >
> > > @@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
> > > hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
> > > if (!hwsim_wq)
> > > return -ENOMEM;
> > > - rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > > + err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > > + if (err)
> > > + return err;
> >
> > That's missing a workqueue free, but I can fix that while applying if
> > you prefer.
> >
>
> And we don't free the hashtable on error either.
Heh. Ok, I guess I'll make a whole new commit to fix up all the things
here.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Dan Carpenter @ 2018-05-29 10:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Colin King, Kalle Valo, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <1527585428.6955.7.camel@sipsolutions.net>
On Tue, May 29, 2018 at 11:17:08AM +0200, Johannes Berg wrote:
> On Tue, 2018-05-29 at 10:14 +0100, Colin King wrote:
> >
> > @@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
> > hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
> > if (!hwsim_wq)
> > return -ENOMEM;
> > - rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > + err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > + if (err)
> > + return err;
>
> That's missing a workqueue free, but I can fix that while applying if
> you prefer.
>
And we don't free the hashtable on error either.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] bpfilter: fix building without CONFIG_INET
From: Arnd Bergmann @ 2018-05-29 9:55 UTC (permalink / raw)
To: David S. Miller, Arnd Bergmann, Alexei Starovoitov; +Cc: netdev, linux-kernel
bpfilter_process_sockopt is a callback that gets called from
ip_setsockopt() and ip_getsockopt(). However, when CONFIG_INET is
disabled, it never gets called at all, and assigning a function to the
callback pointer results in a link failure:
net/bpfilter/bpfilter_kern.o: In function `__stop_umh':
bpfilter_kern.c:(.text.unlikely+0x3): undefined reference to `bpfilter_process_sockopt'
net/bpfilter/bpfilter_kern.o: In function `load_umh':
bpfilter_kern.c:(.init.text+0x73): undefined reference to `bpfilter_process_sockopt'
Since there is no caller in this configuration, I assume we can
simply make the assignment conditional.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This happened on last week's linux-next tree. Since there hasn't
been an update since, it's possible that this is fixed in another
tree already.
---
net/bpfilter/bpfilter_kern.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c
index 7596314b61c7..b13d058f8c34 100644
--- a/net/bpfilter/bpfilter_kern.c
+++ b/net/bpfilter/bpfilter_kern.c
@@ -33,7 +33,8 @@ static void shutdown_umh(struct umh_info *info)
static void __stop_umh(void)
{
- if (bpfilter_process_sockopt) {
+ if (IS_ENABLED(CONFIG_INET) &&
+ bpfilter_process_sockopt) {
bpfilter_process_sockopt = NULL;
shutdown_umh(&info);
}
@@ -98,7 +99,9 @@ static int __init load_umh(void)
stop_umh();
return -EFAULT;
}
- bpfilter_process_sockopt = &__bpfilter_process_sockopt;
+ if (IS_ENABLED(CONFIG_INET))
+ bpfilter_process_sockopt = &__bpfilter_process_sockopt;
+
return 0;
}
--
2.9.0
^ permalink raw reply related
* Re: Unable to create ip alias on bridge interface
From: Michal Kubecek @ 2018-05-29 9:32 UTC (permalink / raw)
To: netdev; +Cc: Akshat Kakkar
In-Reply-To: <CAA5aLPimhYWGLZY9g7x8UjHbY2_R8evkXpxaNZ8kAj1iKJztMQ@mail.gmail.com>
On Mon, May 28, 2018 at 11:50:05PM +0530, Akshat Kakkar wrote:
> 1. How can this survive across reboots without having a custom script
> on boot up? Like some ifcfg file,etc.
Every reasonable distribution should provide a way to use more than one
address on an interface. But as there is no universal standard for
config files and their format, there is no universal standard for
listing multiple addresses either. You have to check the documentation
of your distribution.
> 2. is there a way to tell to make a given ip as primary, irrespective
> of order?
AFAIK there is no interface allowing to switch the primary address. It
only changes when you delete primary address and have promote_secondaries
enabled for the interface.
Also, don't forget that this primary/secondary distinction is only done
for addresses with the same range (which would create the same automatic
route), i.e. e.g. 10.0.1.42/24 and 10.0.1.43/24 but not if it's e.g.
10.0.1.42/24 and 10.0.2.42/24.
Michal Kubecek
^ permalink raw reply
* [PATCH net-next 1/1] qed*: Add link change count value to ethtool statistics display.
From: Sudarsana Reddy Kalluru @ 2018-05-29 9:31 UTC (permalink / raw)
To: davem; +Cc: netdev, ariel.elior
This patch adds driver changes for capturing the link change count in
ethtool statistics display.
Please consider applying this to "net-next".
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 12 ++++++++++--
drivers/net/ethernet/qlogic/qede/qede.h | 1 +
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 2 ++
drivers/net/ethernet/qlogic/qede/qede_main.c | 1 +
include/linux/qed/qed_if.h | 1 +
5 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 5e655c3..1e0254a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1852,6 +1852,11 @@ static void __qed_get_vport_port_stats(struct qed_hwfn *p_hwfn,
p_ah->tx_1519_to_max_byte_packets =
port_stats.eth.u1.ah1.t1519_to_max;
}
+
+ p_common->link_change_count = qed_rd(p_hwfn, p_ptt,
+ p_hwfn->mcp_info->port_addr +
+ offsetof(struct public_port,
+ link_change_count));
}
static void __qed_get_vport_stats(struct qed_hwfn *p_hwfn,
@@ -1959,11 +1964,14 @@ void qed_reset_vport_stats(struct qed_dev *cdev)
/* PORT statistics are not necessarily reset, so we need to
* read and create a baseline for future statistics.
+ * Link change stat is maintained by MFW, return its value as is.
*/
- if (!cdev->reset_stats)
+ if (!cdev->reset_stats) {
DP_INFO(cdev, "Reset stats not allocated\n");
- else
+ } else {
_qed_get_vport_stats(cdev, cdev->reset_stats);
+ cdev->reset_stats->common.link_change_count = 0;
+ }
}
static enum gft_profile_type
diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h
index 2d3f09e..df791e2 100644
--- a/drivers/net/ethernet/qlogic/qede/qede.h
+++ b/drivers/net/ethernet/qlogic/qede/qede.h
@@ -87,6 +87,7 @@ struct qede_stats_common {
u64 coalesced_aborts_num;
u64 non_coalesced_pkts;
u64 coalesced_bytes;
+ u64 link_change_count;
/* port */
u64 rx_64_byte_packets;
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 8c6fdad..f374e18 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -170,6 +170,8 @@
QEDE_STAT(coalesced_aborts_num),
QEDE_STAT(non_coalesced_pkts),
QEDE_STAT(coalesced_bytes),
+
+ QEDE_STAT(link_change_count),
};
#define QEDE_NUM_STATS ARRAY_SIZE(qede_stats_arr)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 9e70f71..cbfe892 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -398,6 +398,7 @@ void qede_fill_by_demand_stats(struct qede_dev *edev)
p_common->brb_truncates = stats.common.brb_truncates;
p_common->brb_discards = stats.common.brb_discards;
p_common->tx_mac_ctrl_frames = stats.common.tx_mac_ctrl_frames;
+ p_common->link_change_count = stats.common.link_change_count;
if (QEDE_IS_BB(edev)) {
struct qede_stats_bb *p_bb = &edev->stats.bb;
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 44af652..4444491 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -1179,6 +1179,7 @@ struct qed_eth_stats_common {
u64 tx_mac_mc_packets;
u64 tx_mac_bc_packets;
u64 tx_mac_ctrl_frames;
+ u64 link_change_count;
};
struct qed_eth_stats_bb {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] brcmfmac: stop watchdog before detach and free everything
From: Arend van Spriel @ 2018-05-29 9:25 UTC (permalink / raw)
To: Michael Trimarchi
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel
In-Reply-To: <1527493857-2220-1-git-send-email-michael@amarulasolutions.com>
On 5/28/2018 9:50 AM, Michael Trimarchi wrote:
> Watchdog need to be stopped in brcmf_sdio_remove to avoid
> i
> The system is going down NOW!
> [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
> Sent SIGTERM to all processes
[snip]
Please send a V2 with your configuration details to the commit message,
ie. using built-in driver, no firmware in place, etc.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++++++
> 1 file changed, 7 insertions(+)
^ 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