* Re: [PATCH net-next v2 0/6] Add comphy support for Armada 38x
From: Kishon Vijay Abraham I @ 2019-02-08 9:22 UTC (permalink / raw)
To: Thomas Petazzoni, David Miller
Cc: linux, andrew, gregory.clement, jason, sebastian.hesselbarth,
devicetree, linux-arm-kernel, mark.rutland, netdev, robh+dt
In-Reply-To: <20190208085821.7556a18d@windsurf>
Hi,
On 08/02/19 1:28 PM, Thomas Petazzoni wrote:
> Hello David,
>
> On Thu, 07 Feb 2019 18:10:49 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
>> Date: Thu, 7 Feb 2019 16:18:25 +0000
>>
>>> This series adds support for the comphy for Armada 38x, which allows
>>> these SoCs to use 2500BASE-X mode with appropriate SFP modules.
>>>
>>> Tested on SolidRun Clearfog after updating for the 5.0 merge window
>>> changes.
>>
>> Series applied, thanks Russell.
>
> This series contained:
>
> - Device Tree bindings that had not been ACKed by the DT bindings
> maintainers, one of which should have been merged through the
> drivers/phy maintainer tree.
>
> - A brand new drivers/phy driver that had not been ACKed by the
> drivers/phy maintainer.
The PHY driver looks good to me. But I think it might still be better to take
it via PHY tree since there are other Marvell drivers that are getting merged
and will result in conflicts in Kconfig and Makefile.
Thanks
Kishon
^ permalink raw reply
* [PATCH net-next 2/2] bnxt_en: Remove wake_on_lan parameter support for devlink
From: Vasundhara Volam @ 2019-02-08 9:13 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, netdev
In-Reply-To: <1549617190-387130-1-git-send-email-vasundhara-v.volam@broadcom.com>
Retain the code to register devlink port parameters.
There will be followup patchset to add some port parameters.
Cc: Michael Chan <michael.chan@broadcom.com>
Cc: Michal Kubecek <mkubecek@suse.cz>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 19 +------------------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 -
2 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index a6abfa4..9d2b699 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -37,8 +37,6 @@ enum bnxt_dl_param_id {
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
{BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
BNXT_NVM_SHARED_CFG, 1},
-
- {DEVLINK_PARAM_GENERIC_ID_WOL, NVM_OFF_WOL, BNXT_NVM_PORT_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -72,8 +70,7 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
switch (bytesize) {
case 1:
- if (nvm_param.num_bits == 1 &&
- nvm_param.id != DEVLINK_PARAM_GENERIC_ID_WOL)
+ if (nvm_param.num_bits == 1)
buf = &val->vbool;
else
buf = &val->vu8;
@@ -167,17 +164,6 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
return 0;
}
-static int bnxt_dl_wol_validate(struct devlink *dl, u32 id,
- union devlink_param_value val,
- struct netlink_ext_ack *extack)
-{
- if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
- NL_SET_ERR_MSG_MOD(extack, "WOL type is not supported");
- return -EINVAL;
- }
- return 0;
-}
-
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -203,9 +189,6 @@ static int bnxt_dl_wol_validate(struct devlink *dl, u32 id,
};
static const struct devlink_param bnxt_dl_port_params[] = {
- DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
- bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
- bnxt_dl_wol_validate),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index da065ca..5b6b2c7 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -35,7 +35,6 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
#define NVM_OFF_MSIX_VEC_PER_PF_MAX 108
#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
-#define NVM_OFF_WOL 152
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/2] Revert "devlink: Add a generic wake_on_lan port parameter"
From: Vasundhara Volam @ 2019-02-08 9:13 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, netdev
In-Reply-To: <1549617190-387130-1-git-send-email-vasundhara-v.volam@broadcom.com>
This reverts commit b639583f9e36d044ac1b13090ae812266992cbac.
As per discussion with Jakub Kicinski and Michal Kubecek,
this will be better addressed by soon-too-come ethtool netlink
API with additional indication that given configuration request
is supposed to be persisted.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michal Kubecek <mkubecek@suse.cz>
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 8 --------
net/core/devlink.c | 5 -----
2 files changed, 13 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index c12ad6e..1dfdd81 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -369,17 +369,12 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY,
- DEVLINK_PARAM_GENERIC_ID_WOL,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
DEVLINK_PARAM_GENERIC_ID_MAX = __DEVLINK_PARAM_GENERIC_ID_MAX - 1,
};
-enum devlink_param_wol_types {
- DEVLINK_PARAM_WAKE_MAGIC = (1 << 0),
-};
-
#define DEVLINK_PARAM_GENERIC_INT_ERR_RESET_NAME "internal_error_reset"
#define DEVLINK_PARAM_GENERIC_INT_ERR_RESET_TYPE DEVLINK_PARAM_TYPE_BOOL
@@ -404,9 +399,6 @@ enum devlink_param_wol_types {
#define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME "fw_load_policy"
#define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE DEVLINK_PARAM_TYPE_U8
-#define DEVLINK_PARAM_GENERIC_WOL_NAME "wake_on_lan"
-#define DEVLINK_PARAM_GENERIC_WOL_TYPE DEVLINK_PARAM_TYPE_U8
-
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 7fbdba5..f064ad3 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2701,11 +2701,6 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME,
.type = DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE,
},
- {
- .id = DEVLINK_PARAM_GENERIC_ID_WOL,
- .name = DEVLINK_PARAM_GENERIC_WOL_NAME,
- .type = DEVLINK_PARAM_GENERIC_WOL_TYPE,
- },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/2] Revert wake_on_lan devlink parameter
From: Vasundhara Volam @ 2019-02-08 9:13 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, netdev
As per discussion with Jakub Kicinski and Michal Kubecek,
this will be better addressed by soon-too-come ethtool netlink
API with additional indication that given WoL configuration request
is supposed to be persisted.
Retain bnxt_en code for devlink port param table registration.
There will be follow up patches to add some devlink port params
for bnxt_en driver.
Vasundhara Volam (2):
Revert "devlink: Add a generic wake_on_lan port parameter"
bnxt_en: Remove wake_on_lan parameter support for devlink
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 19 +------------------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 -
include/net/devlink.h | 8 --------
net/core/devlink.c | 5 -----
4 files changed, 1 insertion(+), 32 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH bpf-next 1/6] bpf: Add a bpf_sock pointer to __sk_buff and a bpf_sk_fullsock helper
From: Daniel Borkmann @ 2019-02-08 8:56 UTC (permalink / raw)
To: Martin Lau
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Kernel Team,
Lawrence Brakmo
In-Reply-To: <20190208055601.wwqqi2bpwtfft4nz@kafai-mbp.dhcp.thefacebook.com>
On 02/08/2019 06:56 AM, Martin Lau wrote:
> On Thu, Feb 07, 2019 at 11:21:41PM +0100, Daniel Borkmann wrote:
>> On 02/07/2019 08:27 AM, Martin Lau wrote:
>> [...]
>>> Following up the discussion in the iovisor conf call.
>>>
>>> One of discussion was about:
>>> other than tw, can __sk_buff->sk always return a
>>> fullsock (PTR_TO_SOCKET_OR_NULL). In request_sock case,
>>> it is doable because it can trace back to the listener sock.
>>>
>>> However, that will go back to the sock_common accessing question.
>>> In particular, how to access the sock_common's fields of the
>>> request_sock itself? Those fields in the request_sock are different
>>> from its listener sock. e.g. the skc_daddr and skc_dport.
>>>
>>> Also, if the sock_common fields of tw is needed, it will become weird
>>> because likely a new "struct bpf_tw_sock" is needed which is OK
>>> but all sock_common fields need to be copied from bpf_sock
>>> to bpf_tw_sock.
>>>
>>> I think reading a sk from a ctx should return the
>>> most basic type PTR_TO_SOCK_COMMON_OR_NULL (unless the running
>>> ctx can guarantee that it always has a fullsock).
>>> Currently, it is __sk_buff->sk. Later, sock_ops->sk...etc.
>>> One single 'struct bpf_sock' and limit fullsock field access
>>> at verification time. The bpf_prog then moves down the chain
>>> based on what it needs. It could be fullsock, tcp_sock...etc.
>>>
>>> I think that will be the most flexible way to write bpf_prog
>>> while also avoid having duplicate fields in different
>>> bpf struct in uapi.
>>
>> Ok, thanks for following up and sorry for late reply, lets go with
>> sock_common then. What's the plan to moving forward with accessing
>> full sk in case of req sk? Separate helper or backed into the newly
>> added bpf_sk_fullsock() one? Presumably latter?
> I will add sk_to_full_sk() to bpf_sk_fullsock() and bpf_tcp_sock().
Ok, sounds good, thanks!
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE
From: Jiri Pirko @ 2019-02-08 8:39 UTC (permalink / raw)
To: Simon Horman
Cc: Eli Cohen, jhs, xiyou.wangcong, davem, netdev, linux-kernel,
jakub.kicinski, dirk.vandermerwe, francois.theron, quentin.monnet,
john.hurley, edwin.peer
In-Reply-To: <20190208080141.dlksz5dfkufj2sbm@netronome.com>
Fri, Feb 08, 2019 at 09:01:42AM CET, simon.horman@netronome.com wrote:
>On Thu, Feb 07, 2019 at 09:45:49AM +0200, Eli Cohen wrote:
>> Modify the kernel users of the TCA_ACT_* macros to use TCA_ID_*. For
>> example, use TCA_ID_GACT instead of TCA_ACT_GACT. This will align with
>> TCA_ID_POLICE and also differentiates these identifier, used in struct
>> tc_action_ops type field, from other macros starting with TCA_ACT_.
>>
>> To make things clearer, we name the enum defining the TCA_ID_*
>> identifiers and also change the "type" field of struct tc_action to
>> id.
>>
>> Signed-off-by: Eli Cohen <eli@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>
>...
>
>> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>> index 7ab55f97e7c4..51a0496f78ea 100644
>> --- a/include/uapi/linux/pkt_cls.h
>> +++ b/include/uapi/linux/pkt_cls.h
>> @@ -85,7 +85,7 @@ enum {
>> #define TCA_ACT_SAMPLE 26
>>
>> /* Action type identifiers*/
>> -enum {
>> +enum tca_id {
>> TCA_ID_UNSPEC = 0,
>> TCA_ID_POLICE = 1,
>> TCA_ID_GACT = TCA_ACT_GACT,
>
>This change updates the UAPI. It seems to me that it would not
>break existing users. But I would like to ask if this has been
>given due consideration.
Sure it has. I believe this is UAPI-safe change.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] Add comphy support for Armada 38x
From: Thomas Petazzoni @ 2019-02-08 7:58 UTC (permalink / raw)
To: David Miller
Cc: linux, andrew, gregory.clement, jason, kishon,
sebastian.hesselbarth, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt
In-Reply-To: <20190207.181049.1229639710283404215.davem@davemloft.net>
Hello David,
On Thu, 07 Feb 2019 18:10:49 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Date: Thu, 7 Feb 2019 16:18:25 +0000
>
> > This series adds support for the comphy for Armada 38x, which allows
> > these SoCs to use 2500BASE-X mode with appropriate SFP modules.
> >
> > Tested on SolidRun Clearfog after updating for the 5.0 merge window
> > changes.
>
> Series applied, thanks Russell.
This series contained:
- Device Tree bindings that had not been ACKed by the DT bindings
maintainers, one of which should have been merged through the
drivers/phy maintainer tree.
- A brand new drivers/phy driver that had not been ACKed by the
drivers/phy maintainer.
- Changes to platform Device Tree that should have been merged through
the platform tree.
Only patches 4/6 and 5/6 should go through the net-next tree, all the
other patches should have gone through other trees.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE
From: Simon Horman @ 2019-02-08 8:01 UTC (permalink / raw)
To: Eli Cohen
Cc: jhs, xiyou.wangcong, jiri, davem, netdev, linux-kernel,
jakub.kicinski, dirk.vandermerwe, francois.theron, quentin.monnet,
john.hurley, edwin.peer
In-Reply-To: <20190207074549.29861-3-eli@mellanox.com>
On Thu, Feb 07, 2019 at 09:45:49AM +0200, Eli Cohen wrote:
> Modify the kernel users of the TCA_ACT_* macros to use TCA_ID_*. For
> example, use TCA_ID_GACT instead of TCA_ACT_GACT. This will align with
> TCA_ID_POLICE and also differentiates these identifier, used in struct
> tc_action_ops type field, from other macros starting with TCA_ACT_.
>
> To make things clearer, we name the enum defining the TCA_ID_*
> identifiers and also change the "type" field of struct tc_action to
> id.
>
> Signed-off-by: Eli Cohen <eli@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
...
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index 7ab55f97e7c4..51a0496f78ea 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -85,7 +85,7 @@ enum {
> #define TCA_ACT_SAMPLE 26
>
> /* Action type identifiers*/
> -enum {
> +enum tca_id {
> TCA_ID_UNSPEC = 0,
> TCA_ID_POLICE = 1,
> TCA_ID_GACT = TCA_ACT_GACT,
This change updates the UAPI. It seems to me that it would not
break existing users. But I would like to ask if this has been
given due consideration.
...
^ permalink raw reply
* Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
From: Simon Horman @ 2019-02-08 7:59 UTC (permalink / raw)
To: David Miller; +Cc: gvrose8192, elibr, pshelar, dev, netdev
In-Reply-To: <20190204.120900.211287782199950541.davem@davemloft.net>
On Mon, Feb 04, 2019 at 12:09:00PM -0800, David Miller wrote:
> From: Gregory Rose <gvrose8192@gmail.com>
> Date: Mon, 4 Feb 2019 11:41:29 -0800
>
> >
> > On 2/3/2019 1:12 AM, Eli Britstein wrote:
> >> Declare ovs key structures using macros as a pre-step towards to
> >> enable retrieving fields information, as a work done in proposed
> >> commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
> >> ("odp-util: Do not rewrite fields with the same values as matched"),
> >> with no functional change.
> >>
> >> Signed-off-by: Eli Britstein <elibr@mellanox.com>
> >> Reviewed-by: Roi Dayan <roid@mellanox.com>
> >
> > Obscuring the structures with these macros is awful. I'm opposed but
> > I see it has already been
> > accepted upstream so I guess that's that.
>
> I am personally in no way obligated to apply this patch to my tree
> just because "upstream" did, and I absolutely have no plans to do so
> at this point.
>
> This patch is absolutely awful.
I hate to jump on a bandwagon, but this patch makes the code much
less readable.
^ permalink raw reply
* Re: [PATCH] net: stmmac: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
From: Maxime Ripard @ 2019-02-08 7:44 UTC (permalink / raw)
To: Yizhuo
Cc: csong, zhiyunq, Giuseppe Cavallaro, Alexandre Torgue,
Chen-Yu Tsai, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20190207174623.16712-1-yzhai003@ucr.edu>
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
On Thu, Feb 07, 2019 at 09:46:23AM -0800, Yizhuo wrote:
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/2] mlxsw: spectrum_router: Offload blackhole routes
From: Ido Schimmel @ 2019-02-08 7:34 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko,
Alexander Petrovskiy, mlxsw
In-Reply-To: <18da8b4d-5966-e851-46d6-e389e40b865e@gmail.com>
On Thu, Feb 07, 2019 at 04:40:11PM -0800, David Ahern wrote:
> On 2/6/19 11:42 AM, Ido Schimmel wrote:
> > Create a new FIB entry type for blackhole routes and set it in case the
> > type of the notified route is 'RTN_BLACKHOLE'.
> >
> > Program such routes with a discard action and mark them as offloaded
> > since the device is dropping the packets instead of the kernel.
> >
> > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > Acked-by: Jiri Pirko <jiri@mellanox.com>
> > ---
> > .../ethernet/mellanox/mlxsw/spectrum_router.c | 27 +++++++++++++++++--
> > 1 file changed, 25 insertions(+), 2 deletions(-)
> >
>
> One of the feature requests from the FRR team (and a feature I have
> implemented) is a blackhole nexthop. The idea is that prefixes are
> installed pointing to nexthop id N. That nexthop definition can be
> atomically updated to go between a device / gateway and a blackhole.
>
>
> [ prefix ] --> [ nhid 1 ] --> [ dev1 / gateway1 ]
>
>
> [ prefix ] --> [ nhid 1 ] --> [ blackhole ]
>
>
> [ prefix ] --> [ nhid 1 ] --> [ dev2 / gateway2 ]
>
> Do you see this working ok with mlxsw without having to update the
> prefix entries (which can be numerous) directly?
Yes. This patch configures the route itself to drop packets, but we can
instead configure it as a remote route and configure the adjacency entry
to drop packets.
If you later want to change X routes using this blackhole nexthop to a
different one, then create the new one and tell the hardware to do the
switch in a single operation. It will basically grep over all configured
routes and do:
s/blackhole_adjacency_index/new_adjacency_index/
s/black_ecmp_size/new_ecmp_size/
See RALEU in drivers/net/ethernet/mellanox/mlxsw/reg.h
I assume that user can't put blackhole and normal nexthops in the same
group?
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum_router: Use struct_size() in kzalloc()
From: Jiri Pirko @ 2019-02-08 7:06 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jiri Pirko, Ido Schimmel, David S. Miller, netdev, linux-kernel
In-Reply-To: <20190208034241.GA11858@embeddedor>
Fri, Feb 08, 2019 at 04:42:41AM CET, gustavo@embeddedor.com wrote:
>One of the more common cases of allocation size calculations is finding
>the size of a structure that has a zero-sized array at the end, along
>with memory for some number of elements for that array. For example:
>
>struct foo {
> int stuff;
> struct boo entry[];
>};
>
>size = sizeof(struct foo) + count * sizeof(struct boo);
>instance = kzalloc(size, GFP_KERNEL)
>
>Instead of leaving these open-coded and prone to type mistakes, we can
>now use the new struct_size() helper:
>
>instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
>Notice that, in this case, variable alloc_size is not necessary, hence
>it is removed.
>
>This code was detected with the help of Coccinelle.
>
>Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH net-next] net: phy: disregard "Clause 22 registers present" bit in get_phy_c45_devs_in_pkg
From: Heiner Kallweit @ 2019-02-08 7:12 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Bit 0 in register 1.5 doesn't represent a device but is a flag that
Clause 22 registers are present. Therefore disregard this bit when
populating the device list. If code needs this information it
should read register 1.5 directly instead of accessing the device
list. Because this bit doesn't represent a device I didn't add a
MDIO_MMD_C22PRESENT constant or similar.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 3 ++-
include/uapi/linux/mdio.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9369e1323..c2316a117 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -682,7 +682,8 @@ static int get_phy_c45_devs_in_pkg(struct mii_bus *bus, int addr, int dev_addr,
phy_reg = mdiobus_read(bus, addr, reg_addr);
if (phy_reg < 0)
return -EIO;
- *devices_in_package |= (phy_reg & 0xffff);
+ /* Bit 0 doesn't represent a device, it indicates c22 regs presence */
+ *devices_in_package |= (phy_reg & 0xfffe);
return 0;
}
diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h
index 2e6e309f0..0e012b168 100644
--- a/include/uapi/linux/mdio.h
+++ b/include/uapi/linux/mdio.h
@@ -115,6 +115,7 @@
/* Device present registers. */
#define MDIO_DEVS_PRESENT(devad) (1 << (devad))
+#define MDIO_DEVS_C22PRESENT MDIO_DEVS_PRESENT(0)
#define MDIO_DEVS_PMAPMD MDIO_DEVS_PRESENT(MDIO_MMD_PMAPMD)
#define MDIO_DEVS_WIS MDIO_DEVS_PRESENT(MDIO_MMD_WIS)
#define MDIO_DEVS_PCS MDIO_DEVS_PRESENT(MDIO_MMD_PCS)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 4/6] ethtool: support per-queue sub command --show-coalesce
From: Michal Kubecek @ 2019-02-08 7:10 UTC (permalink / raw)
To: netdev
Cc: Nunley, Nicholas D, Kirsher, Jeffrey T, linville@tuxdriver.com,
nhorman@redhat.com, sassmann@redhat.com
In-Reply-To: <146CDE3B8C383A4B88452B498CB0FBBBFD9C3FE9@ORSMSX157.amr.corp.intel.com>
On Thu, Feb 07, 2019 at 11:53:40PM +0000, Nunley, Nicholas D wrote:
> > > @@ -5390,7 +5438,19 @@ static int do_perqueue(struct cmd_context *ctx)
> > > if (i < 0)
> > > exit_bad_args();
> > >
> > > - /* no sub_command support yet */
> > > + if (strstr(args[i].opts, "--show-coalesce") != NULL) {
> >
> > Comparing args[i].func to do_gcoalesce might be easier.
>
> This is the one comment where I think it's better to leave the code as it is.
> To me is seems more confusing to match on a function pointer that we're never
> going to call. Unless there are more objections I'd rather keep it the way it
> is.
No problem. This is not a code where performance is crucial. In theory,
you could get into trouble if someone introduces another command
(allowing per queue settings) with name like "--show-coalesce-foo" but
that's not very likely, IMHO.
Michal Kubecek
^ permalink raw reply
* Re: Kernel 5.0-rc5 regression with NAT, bisected to: netfilter: nat: remove l4proto->manip_pkt
From: Florian Westphal @ 2019-02-08 7:07 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: Florian Westphal, Pablo Neira Ayuso, David S. Miller, netdev,
linux-kernel
In-Reply-To: <40b70892-daf5-28d7-28b5-869911faf2bb@eikelenboom.it>
Sander Eikelenboom <linux@eikelenboom.it> wrote:
> L.S.,
>
> While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression with NAT.
> (using an nftables firewall with NAT and connection tracking).
>
> Unfortunately it isn't too obvious since no errors are logged, but on clients it
> causes symptoms like firefox intermittently not being able to load pages with:
> Network Protocol Error
> An error occurred during a connection to www.example.com
> The page you are trying to view cannot be shown because an error in the network protocol was detected.
> Please contact the website owners to inform them of this problem.
>
> But it's only intermittently, so i can still visit some webpages with clients,
> could be that packet size and or fragments are at play ?
>
> So I tried testing with git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git with
> e8c32c32b48c2e889704d8ca0872f92eb027838e as last commit, to be sure to have the latest netdev has to offer,
> but to no avail.
>
> After that I tried to git bisect and ended up with:
>
> faec18dbb0405c7d4dda025054511dc3a6696918 is the first bad commit
> commit faec18dbb0405c7d4dda025054511dc3a6696918
> Author: Florian Westphal <fw@strlen.de>
> Date: Thu Dec 13 16:01:33 2018 +0100
>
> netfilter: nat: remove l4proto->manip_pkt
Thanks, this is immensely helpful.
I think I see the bug, we can't use target->dst.protonum in
nf_nat_l4proto_manip_pkt(), it will be TCP in case we're dealing
with a related icmp packet.
I will send a patch in a few hours when I get back.
^ permalink raw reply
* Re: [PATCH v2 3/6] ethtool: introduce new ioctl for per-queue settings
From: Michal Kubecek @ 2019-02-08 7:02 UTC (permalink / raw)
To: netdev
Cc: Nunley, Nicholas D, Kirsher, Jeffrey T, linville@tuxdriver.com,
nhorman@redhat.com, sassmann@redhat.com
In-Reply-To: <146CDE3B8C383A4B88452B498CB0FBBBFD9C3F87@ORSMSX157.amr.corp.intel.com>
On Thu, Feb 07, 2019 at 11:37:19PM +0000, Nunley, Nicholas D wrote:
> From: Michal Kubecek [mailto:mkubecek@suse.cz]
> > On Tue, Feb 05, 2019 at 04:01:03PM -0800, Jeff Kirsher wrote:
> > > Introduce a new ioctl for setting per-queue parameters.
> > > Users can apply commands to specific queues by setting SUB_COMMAND
> > and
> > > queue_mask with the following ethtool command:
> > >
> > > ethtool --set-perqueue-command DEVNAME [queue_mask %x]
> > SUB_COMMAND
> >
> > The "set" part is IMHO a bit confusing in combination with "show" type
> > subcommands.
>
> I'm not a fan of the "set" either. This patch set had already gone
> through some review before it was passed on to me, and the command
> naming wasn't a previous point of contention and I didn't want to
> disturb the parts that weren't "broken", but since you've brought it
> up I agree that this may not be the best name. I think
> "--perqueue-command" is more appropriate. Does this seem reasonable to
> you?
That sounds good, I would say either that or "--per-queue".
Michal Kubecek
^ permalink raw reply
* Re: [PATCH bpf-next 1/6] bpf: Add a bpf_sock pointer to __sk_buff and a bpf_sk_fullsock helper
From: Martin Lau @ 2019-02-08 5:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Kernel Team,
Lawrence Brakmo
In-Reply-To: <58d44fb9-a10b-d6dd-6313-60f7802e4519@iogearbox.net>
On Thu, Feb 07, 2019 at 11:21:41PM +0100, Daniel Borkmann wrote:
> On 02/07/2019 08:27 AM, Martin Lau wrote:
> [...]
> > Following up the discussion in the iovisor conf call.
> >
> > One of discussion was about:
> > other than tw, can __sk_buff->sk always return a
> > fullsock (PTR_TO_SOCKET_OR_NULL). In request_sock case,
> > it is doable because it can trace back to the listener sock.
> >
> > However, that will go back to the sock_common accessing question.
> > In particular, how to access the sock_common's fields of the
> > request_sock itself? Those fields in the request_sock are different
> > from its listener sock. e.g. the skc_daddr and skc_dport.
> >
> > Also, if the sock_common fields of tw is needed, it will become weird
> > because likely a new "struct bpf_tw_sock" is needed which is OK
> > but all sock_common fields need to be copied from bpf_sock
> > to bpf_tw_sock.
> >
> > I think reading a sk from a ctx should return the
> > most basic type PTR_TO_SOCK_COMMON_OR_NULL (unless the running
> > ctx can guarantee that it always has a fullsock).
> > Currently, it is __sk_buff->sk. Later, sock_ops->sk...etc.
> > One single 'struct bpf_sock' and limit fullsock field access
> > at verification time. The bpf_prog then moves down the chain
> > based on what it needs. It could be fullsock, tcp_sock...etc.
> >
> > I think that will be the most flexible way to write bpf_prog
> > while also avoid having duplicate fields in different
> > bpf struct in uapi.
>
> Ok, thanks for following up and sorry for late reply, lets go with
> sock_common then. What's the plan to moving forward with accessing
> full sk in case of req sk? Separate helper or backed into the newly
> added bpf_sk_fullsock() one? Presumably latter?
I will add sk_to_full_sk() to bpf_sk_fullsock() and bpf_tcp_sock().
Thanks,
Martin
^ permalink raw reply
* Clang warning in drivers/net/ethernet/intel/igc/igc_ethtool.c
From: Nathan Chancellor @ 2019-02-08 5:09 UTC (permalink / raw)
To: Sasha Neftin, Jeff Kirsher
Cc: Aaron Brown, intel-wired-lan, netdev, linux-kernel,
Nick Desaulniers
Hi all,
After commit 8c5ad0dae93c ("igc: Add ethtool support"), Clang warns:
drivers/net/ethernet/intel/igc/igc_ethtool.c:9:19: warning: variable 'igc_priv_flags_strings' is not needed and will not be emitted [-Wunneeded-internal-declaration]
static const char igc_priv_flags_strings[][ETH_GSTRING_LEN] = {
^
1 warning generated.
igc_priv_flags_strings is only used in an ARRAY_SIZE macro, which is a
compile time evaluation, so no reference to it is being emitted in the
final assembly. Is it actually needed and was forgotten to be used
somewhere or could it be eliminated so that Clang no longer warns?
Thanks,
Nathan
^ permalink raw reply
* [PATCH net-next] ethtool: Remove unnecessary null check in ethtool_rx_flow_rule_create
From: Nathan Chancellor @ 2019-02-08 4:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Pablo Neira Ayuso, Jiri Pirko,
Nick Desaulniers, Nathan Chancellor
net/core/ethtool.c:3023:19: warning: address of array
'ext_m_spec->h_dest' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (ext_m_spec->h_dest) {
~~ ~~~~~~~~~~~~^~~~~~
h_dest is an array, it can't be null so remove this check.
Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator")
Link: https://github.com/ClangBuiltLinux/linux/issues/353
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
net/core/ethtool.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 0fbf39239b29..d2c47cdf25da 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -3020,17 +3020,15 @@ ethtool_rx_flow_rule_create(const struct ethtool_rx_flow_spec_input *input)
const struct ethtool_flow_ext *ext_h_spec = &fs->h_ext;
const struct ethtool_flow_ext *ext_m_spec = &fs->m_ext;
- if (ext_m_spec->h_dest) {
- memcpy(match->key.eth_addrs.dst, ext_h_spec->h_dest,
- ETH_ALEN);
- memcpy(match->mask.eth_addrs.dst, ext_m_spec->h_dest,
- ETH_ALEN);
-
- match->dissector.used_keys |=
- BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS);
- match->dissector.offset[FLOW_DISSECTOR_KEY_ETH_ADDRS] =
- offsetof(struct ethtool_rx_flow_key, eth_addrs);
- }
+ memcpy(match->key.eth_addrs.dst, ext_h_spec->h_dest,
+ ETH_ALEN);
+ memcpy(match->mask.eth_addrs.dst, ext_m_spec->h_dest,
+ ETH_ALEN);
+
+ match->dissector.used_keys |=
+ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS);
+ match->dissector.offset[FLOW_DISSECTOR_KEY_ETH_ADDRS] =
+ offsetof(struct ethtool_rx_flow_key, eth_addrs);
}
act = &flow->rule->action.entries[0];
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] ixgbe: Use struct_size() helper
From: Gustavo A. R. Silva @ 2019-02-08 4:22 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
Notice that, in this case, variable size is not necessary, hence
it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
index 62e6499e4146..cc3196ae5aea 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -836,12 +836,10 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter *adapter,
struct ixgbe_ring *ring;
int node = NUMA_NO_NODE;
int cpu = -1;
- int ring_count, size;
+ int ring_count;
u8 tcs = adapter->hw_tcs;
ring_count = txr_count + rxr_count + xdp_count;
- size = sizeof(struct ixgbe_q_vector) +
- (sizeof(struct ixgbe_ring) * ring_count);
/* customize cpu for Flow Director mapping */
if ((tcs <= 1) && !(adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)) {
@@ -855,9 +853,11 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter *adapter,
}
/* allocate q_vector and rings */
- q_vector = kzalloc_node(size, GFP_KERNEL, node);
+ q_vector = kzalloc_node(struct_size(q_vector, ring, ring_count),
+ GFP_KERNEL, node);
if (!q_vector)
- q_vector = kzalloc(size, GFP_KERNEL);
+ q_vector = kzalloc(struct_size(q_vector, ring, ring_count),
+ GFP_KERNEL);
if (!q_vector)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] igc: Use struct_size() helper
From: Gustavo A. R. Silva @ 2019-02-08 4:19 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL)
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
Notice that, in this case, variable size is not necessary, hence
it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/intel/igc/igc_main.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 11c75433fe22..87a11879bf2d 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -2958,22 +2958,21 @@ static int igc_alloc_q_vector(struct igc_adapter *adapter,
{
struct igc_q_vector *q_vector;
struct igc_ring *ring;
- int ring_count, size;
+ int ring_count;
/* igc only supports 1 Tx and/or 1 Rx queue per vector */
if (txr_count > 1 || rxr_count > 1)
return -ENOMEM;
ring_count = txr_count + rxr_count;
- size = sizeof(struct igc_q_vector) +
- (sizeof(struct igc_ring) * ring_count);
/* allocate q_vector and rings */
q_vector = adapter->q_vector[v_idx];
if (!q_vector)
- q_vector = kzalloc(size, GFP_KERNEL);
+ q_vector = kzalloc(struct_size(q_vector, ring, ring_count),
+ GFP_KERNEL);
else
- memset(q_vector, 0, size);
+ memset(q_vector, 0, struct_size(q_vector, ring, ring_count));
if (!q_vector)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] igb: use struct_size() helper
From: Gustavo A. R. Silva @ 2019-02-08 4:15 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel, Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + count * sizeof(struct boo);
instance = alloc(size, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
size = struct_size(instance, entry, count);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 6d812e96572d..69b230c53fed 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1189,15 +1189,15 @@ static int igb_alloc_q_vector(struct igb_adapter *adapter,
{
struct igb_q_vector *q_vector;
struct igb_ring *ring;
- int ring_count, size;
+ int ring_count;
+ size_t size;
/* igb only supports 1 Tx and/or 1 Rx queue per vector */
if (txr_count > 1 || rxr_count > 1)
return -ENOMEM;
ring_count = txr_count + rxr_count;
- size = sizeof(struct igb_q_vector) +
- (sizeof(struct igb_ring) * ring_count);
+ size = struct_size(q_vector, ring, ring_count);
/* allocate q_vector and rings */
q_vector = adapter->q_vector[v_idx];
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Callum Sinclair @ 2019-02-08 4:11 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel; +Cc: Callum Sinclair
Created a way to clear the multicast forwarding cache on a socket
without having to either remove the entries manually using the delete
entry socket option or destroy and recreate the multicast socket.
Using the flags MRT_FLUSH_ENTRIES and MRT_FLUSH_VIFS, all multicast
entries can be cleared, all multicast interfaces can be closed or both
can be cleared using one sockopt call.
Callum Sinclair (1):
ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
include/uapi/linux/mroute.h | 7 +++-
include/uapi/linux/mroute6.h | 7 +++-
net/ipv4/ipmr.c | 69 ++++++++++++++++++++-------------
net/ipv6/ip6mr.c | 74 ++++++++++++++++++++++--------------
4 files changed, 100 insertions(+), 57 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Callum Sinclair @ 2019-02-08 4:11 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel; +Cc: Callum Sinclair
In-Reply-To: <20190208041103.31299-1-callum.sinclair@alliedtelesis.co.nz>
Currently the only way to clear the mfc cache was to delete the entries
one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which will clear the multicast forwarding
cache on the socket without destroying the socket. The new socket option
MRT_FLUSH_ENTRIES will clear all multicast entries on the sockets table
and the MRT_FLUSH_VIFS will delete all multicast vifs on the socket
table.
Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
---
include/uapi/linux/mroute.h | 7 +++-
include/uapi/linux/mroute6.h | 7 +++-
net/ipv4/ipmr.c | 69 ++++++++++++++++++++-------------
net/ipv6/ip6mr.c | 74 ++++++++++++++++++++++--------------
4 files changed, 100 insertions(+), 57 deletions(-)
diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index 5d37a9ccce63..673495ca3495 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -28,12 +28,17 @@
#define MRT_TABLE (MRT_BASE+9) /* Specify mroute table ID */
#define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT_MAX (MRT_BASE+11)
+#define MRT_FLUSH (MRT_BASE+12) /* Flush all multicast entries and vifs */
+#define MRT_MAX (MRT_BASE+12)
#define SIOCGETVIFCNT SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT_FLUSH optional flags */
+#define MRT_FLUSH_ENTRIES 1 /* For flushing all multicast entries */
+#define MRT_FLUSH_VIFS 2 /* For flushing all multicast vifs */
+
#define MAXVIFS 32
typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short vifi_t;
diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index 9999cc006390..1f7ac3f0bc20 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -31,12 +31,17 @@
#define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID */
#define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT6_MAX (MRT6_BASE+11)
+#define MRT6_FLUSH (MRT6_BASE+12) /* Flush all multicast entries and vifs */
+#define MRT6_MAX (MRT6_BASE+12)
#define SIOCGETMIFCNT_IN6 SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT6_FLUSH optional flags */
+#define MRT6_FLUSH_ENTRIES 1 /* For flushing all multicast entries */
+#define MRT6_FLUSH_VIFS 2 /* For flushing all multicast vifs */
+
#define MAXMIFS 32
typedef unsigned long mifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short mifi_t;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index e536970557dd..dc7a4ee1d7ca 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -110,7 +110,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
int cmd);
static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, bool all, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -415,7 +415,7 @@ static struct mr_table *ipmr_new_table(struct net *net, u32 id)
static void ipmr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, true, MRT_FLUSH_VIFS | MRT_FLUSH_ENTRIES);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1296,7 +1296,7 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
}
/* Close the multicast socket, and clear the vif tables etc */
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, bool all, int flags)
{
struct net *net = read_pnet(&mrt->net);
struct mr_mfc *c, *tmp;
@@ -1305,35 +1305,39 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
int i;
/* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- vif_delete(mrt, i, 0, &list);
+ if (flags & MRT_FLUSH_VIFS) {
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
+ continue;
+ vif_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
}
- unregister_netdevice_many(&list);
/* Wipe the cache */
- list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
- if (!all && (c->mfc_flags & MFC_STATIC))
- continue;
- rhltable_remove(&mrt->mfc_hash, &c->mnode, ipmr_rht_params);
- list_del_rcu(&c->list);
- cache = (struct mfc_cache *)c;
- call_ipmr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL, cache,
- mrt->id);
- mroute_netlink_event(mrt, cache, RTM_DELROUTE);
- mr_cache_put(c);
- }
-
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
- spin_lock_bh(&mfc_unres_lock);
- list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
- list_del(&c->list);
+ if (flags & MRT_FLUSH_ENTRIES) {
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
+ if (!all && (c->mfc_flags & MFC_STATIC))
+ continue;
+ rhltable_remove(&mrt->mfc_hash, &c->mnode, ipmr_rht_params);
+ list_del_rcu(&c->list);
cache = (struct mfc_cache *)c;
+ call_ipmr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL, cache,
+ mrt->id);
mroute_netlink_event(mrt, cache, RTM_DELROUTE);
- ipmr_destroy_unres(mrt, cache);
+ mr_cache_put(c);
+ }
+
+ if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ spin_lock_bh(&mfc_unres_lock);
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
+ list_del(&c->list);
+ cache = (struct mfc_cache *)c;
+ mroute_netlink_event(mrt, cache, RTM_DELROUTE);
+ ipmr_destroy_unres(mrt, cache);
+ }
+ spin_unlock_bh(&mfc_unres_lock);
}
- spin_unlock_bh(&mfc_unres_lock);
}
}
@@ -1354,7 +1358,7 @@ static void mrtsock_destruct(struct sock *sk)
NETCONFA_IFINDEX_ALL,
net->ipv4.devconf_all);
RCU_INIT_POINTER(mrt->mroute_sk, NULL);
- mroute_clean_tables(mrt, false);
+ mroute_clean_tables(mrt, false, MRT_FLUSH_VIFS | MRT_FLUSH_ENTRIES);
}
}
rtnl_unlock();
@@ -1479,6 +1483,17 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
sk == rtnl_dereference(mrt->mroute_sk),
parent);
break;
+ case MRT_FLUSH:
+ if (optlen != sizeof(val)) {
+ ret = -EINVAL;
+ break;
+ }
+ if (get_user(val, (int __user *)optval)) {
+ ret = -EFAULT;
+ break;
+ }
+ mroute_clean_tables(mrt, true, val);
+ break;
/* Control PIM assert. */
case MRT_ASSERT:
if (optlen != sizeof(val)) {
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index cc01aa3f2b5e..01f015fb33f0 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -97,7 +97,7 @@ static void mr6_netlink_event(struct mr_table *mrt, struct mfc6_cache *mfc,
static void mrt6msg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
static int ip6mr_rtm_dumproute(struct sk_buff *skb,
struct netlink_callback *cb);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, bool all, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IPV6_MROUTE_MULTIPLE_TABLES
@@ -393,7 +393,7 @@ static struct mr_table *ip6mr_new_table(struct net *net, u32 id)
static void ip6mr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, true, MRT6_FLUSH_VIFS | MRT6_FLUSH_ENTRIES);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1496,42 +1496,46 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
* Close the multicast socket, and clear the vif tables etc
*/
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, bool all, int flags)
{
struct mr_mfc *c, *tmp;
LIST_HEAD(list);
int i;
/* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- mif6_delete(mrt, i, 0, &list);
+ if (flags & MRT6_FLUSH_VIFS) {
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
+ continue;
+ mif6_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
}
- unregister_netdevice_many(&list);
/* Wipe the cache */
- list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
- if (!all && (c->mfc_flags & MFC_STATIC))
- continue;
- rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
- list_del_rcu(&c->list);
- call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
- FIB_EVENT_ENTRY_DEL,
- (struct mfc6_cache *)c, mrt->id);
- mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
- mr_cache_put(c);
- }
+ if (flags & MRT6_FLUSH_ENTRIES) {
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
+ if (!all && (c->mfc_flags & MFC_STATIC))
+ continue;
+ rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
+ list_del_rcu(&c->list);
+ call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
+ FIB_EVENT_ENTRY_DEL,
+ (struct mfc6_cache *)c, mrt->id);
+ mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
+ mr_cache_put(c);
+ }
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
- spin_lock_bh(&mfc_unres_lock);
- list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
- list_del(&c->list);
- mr6_netlink_event(mrt, (struct mfc6_cache *)c,
- RTM_DELROUTE);
- ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
+ if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ spin_lock_bh(&mfc_unres_lock);
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
+ list_del(&c->list);
+ mr6_netlink_event(mrt, (struct mfc6_cache *)c,
+ RTM_DELROUTE);
+ ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
+ }
+ spin_unlock_bh(&mfc_unres_lock);
}
- spin_unlock_bh(&mfc_unres_lock);
}
}
@@ -1587,7 +1591,7 @@ int ip6mr_sk_done(struct sock *sk)
NETCONFA_IFINDEX_ALL,
net->ipv6.devconf_all);
- mroute_clean_tables(mrt, false);
+ mroute_clean_tables(mrt, false, MRT6_FLUSH_VIFS | MRT6_FLUSH_ENTRIES);
err = 0;
break;
}
@@ -1703,6 +1707,20 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
rtnl_unlock();
return ret;
+ case MRT6_FLUSH:
+ {
+ int flags;
+
+ if (optlen != sizeof(flags))
+ return -EINVAL;
+ if (get_user(flags, (int __user *)optval))
+ return -EFAULT;
+ rtnl_lock();
+ mroute_clean_tables(mrt, true, flags);
+ rtnl_unlock();
+ return 0;
+ }
+
/*
* Control PIM assert (to activate pim will activate assert)
*/
--
2.20.1
^ permalink raw reply related
* [PATCH v1 net-next 4/4] net: dsa: microchip: remove unnecessary include headers
From: Tristram.Ha @ 2019-02-08 4:07 UTC (permalink / raw)
To: Sergio Paracuellos, Andrew Lunn, Florian Fainelli, Pavel Machek
Cc: Tristram Ha, UNGLinuxDriver, netdev
In-Reply-To: <1549598829-25970-1-git-send-email-Tristram.Ha@microchip.com>
From: Tristram Ha <Tristram.Ha@microchip.com>
Remove unnecessary header include lines.
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
---
drivers/net/dsa/microchip/ksz9477.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 8391b9e..7c51edd 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -5,15 +5,11 @@
* Copyright (C) 2017-2019 Microchip Technology Inc.
*/
-#include <linux/delay.h>
-#include <linux/export.h>
-#include <linux/gpio.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/iopoll.h>
#include <linux/platform_data/microchip-ksz.h>
#include <linux/phy.h>
-#include <linux/etherdevice.h>
#include <linux/if_bridge.h>
#include <net/dsa.h>
#include <net/switchdev.h>
--
1.9.1
^ 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