* Re: [PATCH][net-next][V3] bpf: test_maps: fix typos, "conenct" and "listeen"
From: John Fastabend @ 2017-08-30 17:31 UTC (permalink / raw)
To: Colin King, Alexei Starovoitov, Daniel Borkmann, Shuah Khan,
netdev, linux-kselftest, linux-kernel
In-Reply-To: <20170830171525.5688-1-colin.king@canonical.com>
On 08/30/2017 10:15 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to typos in printf error messages:
> "conenct" -> "connect"
> "listeen" -> "listen"
>
> thanks to Daniel Borkmann for spotting one of these mistakes
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Thanks. Even though its a spelling typo best to add fixes tag
I think.
Fixes: 6f6d33f3b3d0 ("bpf: selftests add sockmap tests")
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* [PATCH net-next] xen-netfront: be more drop monitor friendly
From: Eric Dumazet @ 2017-08-30 17:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
xennet_start_xmit() might copy skb with inappropriate layout
into a fresh one.
Old skb is freed, and at this point it is not a drop, but
a consume. New skb will then be either consumed or dropped.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 7b61adb6270c..523387e71a80 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -611,7 +611,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
nskb = skb_copy(skb, GFP_ATOMIC);
if (!nskb)
goto drop;
- dev_kfree_skb_any(skb);
+ dev_consume_skb_any(skb);
skb = nskb;
page = virt_to_page(skb->data);
offset = offset_in_page(skb->data);
^ permalink raw reply related
* Re: [patch net-next 0/8] mlxsw: Add IPv6 host dpipe table
From: David Ahern @ 2017-08-30 17:33 UTC (permalink / raw)
To: Andrew Lunn, Jiri Pirko; +Cc: netdev, davem, arkadis, idosch, mlxsw
In-Reply-To: <20170830172609.GD22289@lunn.ch>
On 8/30/17 11:26 AM, Andrew Lunn wrote:
> On Wed, Aug 30, 2017 at 02:02:58PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Arkadi says:
>>
>> This patchset adds IPv6 host dpipe table support. This will provide the
>> ability to observe the hardware offloaded IPv6 neighbors.
>
> Hi Jiri, Arkadi
>
> Could you give us an example of the output seen in user space.
>
> Thanks
> Andrew
>
Posting iproute2 patches with the set would be helpful as well.
^ permalink raw reply
* Re: [patch net-next 3/8] mlxsw: spectrum_dpipe: Add IPv6 host table initial support
From: David Ahern @ 2017-08-30 17:36 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, arkadis, idosch, mlxsw
In-Reply-To: <20170830120306.6128-4-jiri@resnulli.us>
On 8/30/17 6:03 AM, Jiri Pirko wrote:
> @@ -328,9 +329,21 @@ static int mlxsw_sp_dpipe_table_host_matches_dump(struct sk_buff *skb, int type)
> if (err)
> return err;
>
> - match.type = DEVLINK_DPIPE_MATCH_TYPE_FIELD_EXACT;
> - match.header = &devlink_dpipe_header_ipv4;
> - match.field_id = DEVLINK_DPIPE_FIELD_IPV4_DST_IP;
> + switch (type) {
> + case AF_INET:
> + match.type = DEVLINK_DPIPE_MATCH_TYPE_FIELD_EXACT;
> + match.header = &devlink_dpipe_header_ipv4;
> + match.field_id = DEVLINK_DPIPE_FIELD_IPV4_DST_IP;
> + break;
> + case AF_INET6:
> + match.type = DEVLINK_DPIPE_MATCH_TYPE_FIELD_EXACT;
> + match.header = &devlink_dpipe_header_ipv6;
> + match.field_id = DEVLINK_DPIPE_FIELD_IPV6_DST_IP;
> + break;
> + default:
> + WARN_ON(1);
Why a warn for dump request of an unsupported family?
> + return -EINVAL;
> + }
>
> return devlink_dpipe_match_put(skb, &match);
> }
> @@ -342,7 +355,7 @@ mlxsw_sp_dpipe_table_host4_matches_dump(void *priv, struct sk_buff *skb)
^ permalink raw reply
* Re: [PATCH net 6/9] sch_fq_codel: avoid double free on init failure
From: Cong Wang @ 2017-08-30 17:36 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Linux Kernel Network Developers, Eric Dumazet, Jamal Hadi Salim,
Jiri Pirko, Roopa Prabhu
In-Reply-To: <1504086545-7777-7-git-send-email-nikolay@cumulusnetworks.com>
On Wed, Aug 30, 2017 at 2:49 AM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> It is very unlikely to happen but the backlogs memory allocation
> could fail and will free q->flows, but then ->destroy() will free
> q->flows too. For correctness remove the first free and let ->destroy
> clean up.
>
> Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> net/sched/sch_fq_codel.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
> index 337f2d6d81e4..2c0c05f2cc34 100644
> --- a/net/sched/sch_fq_codel.c
> +++ b/net/sched/sch_fq_codel.c
> @@ -491,10 +491,8 @@ static int fq_codel_init(struct Qdisc *sch, struct nlattr *opt)
> if (!q->flows)
> return -ENOMEM;
> q->backlogs = kvzalloc(q->flows_cnt * sizeof(u32), GFP_KERNEL);
> - if (!q->backlogs) {
> - kvfree(q->flows);
> + if (!q->backlogs)
> return -ENOMEM;
> - }
This is fine. Or we can NULL it after kvfree().
I have no preference here. The only difference here is if we still
expect ->init() to cleanup its own failure.
^ permalink raw reply
* Re: [PATCH net 9/9] sch_tbf: fix two null pointer dereferences on init failure
From: Cong Wang @ 2017-08-30 17:37 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Linux Kernel Network Developers, Eric Dumazet, Jamal Hadi Salim,
Jiri Pirko, Roopa Prabhu
In-Reply-To: <1504086545-7777-10-git-send-email-nikolay@cumulusnetworks.com>
On Wed, Aug 30, 2017 at 2:49 AM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> Reproduce:
> $ sysctl net.core.default_qdisc=tbf
> $ ip l set ethX up
I once upon a time had a patch to disallow those qdisc's
to be default. Probably I should resend it.
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commit in the net-next tree
From: Stephen Rothwell @ 2017-08-30 17:38 UTC (permalink / raw)
To: David Ahern
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <32dc9201-c7a2-2cf0-e8a1-1c735b8784ee@gmail.com>
Hi David,
On Wed, 30 Aug 2017 10:53:48 -0600 David Ahern <dsahern@gmail.com> wrote:
>
> On 8/30/17 10:51 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commit
> >
> > 1b70d792cf67 ("ipv6: Use rt6i_idev index for echo replies to a local address")
> >
> > is missing a Signed-off-by from its author.
>
> Eric pointed this out last night. The commit message copied output from
> a command that contained '---' so git ignored the remainder of the message.
Rats!
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN
From: Eric W. Biederman @ 2017-08-30 17:41 UTC (permalink / raw)
To: Prakash Sangappa; +Cc: David Miller, linux-kernel, netdev, drepper
In-Reply-To: <d23ec1ae-e2f0-659c-ce67-9b1b1e9ad8a5@oracle.com>
Prakash Sangappa <prakash.sangappa@oracle.com> writes:
> On 8/29/17 5:10 PM, ebiederm@xmission.com wrote:
>
> "prakash.sangappa" <prakash.sangappa@oracle.com> writes:
>
> On 08/29/2017 04:02 PM, David Miller wrote:
>
> From: Prakash Sangappa <prakash.sangappa@oracle.com>
> Date: Mon, 28 Aug 2017 17:12:20 -0700
>
> Currently passing tid(gettid(2)) of a thread in struct ucred in
> SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise
> it fails with EPERM error. Some applications deal with thread id
> of a thread(tid) and so it would help to allow tid in SCM_CREDENTIALS
> message. Basically, either tgid(pid of the process) or the tid of
> the thread should be allowed without the need for CAP_SYS_ADMIN capability.
>
> SCM_CREDENTIALS will be used to determine the global id of a process or
> a thread running inside a pid namespace.
>
> This patch adds necessary check to accept tid in SCM_CREDENTIALS
> struct ucred.
>
> Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
>
> I'm pretty sure that by the descriptions in previous changes to this
> function, what you are proposing is basically a minor form of PID
> spoofing which we only want someone with CAP_SYS_ADMIN over the
> PID namespace to be able to do.
>
> The fix is to allow passing tid of the calling thread itself not of any
> other thread or process. Curious why would this be considered
> as pid spoofing?
>
> This change would enable a thread in a multi threaded process, running
> inside a pid namespace to be identified by the recipient of the
> message easily.
>
> I think a more practical problem is that change, changes what is being
> passed in the SCM_CREDENTIALS from a pid of a process to a tid of a
> thread. That could be confusing and that confusion could be exploited.
>
> It will be upto the application to decide what to pass, either pid of the
> process or tid of the thread and the co-operating process receiving the
> message would know what to expect. It does not change or make it
> mandatory to pass tid.
>
>
> It is definitely confusing because in some instances a value can be both
> a tgid and a tid.
>
>
> I definitely think this needs to be talked about in terms of changing
> what is passed in that field and what the consequences could be.
>
> Agreed that If the receiving process expects a pid and the process sending
> the message sends tid, it can cause confusion, but why would that occur?
> Shouldn't the sending process know what is the receiving process expecting?
>
>
> I suspect you are ok. As nothing allows passing a tid today. But I
> don't see any analysis on why passing a tid instead of a tgid will not
> confuse the receiving application, and in such confusion introduce a
> security hole.
>
> It would seem that there has to be an understanding between the two
> processes what is being passed(pid or tid) when communicating with
> each other.
Which is the issue. SCM_CREDENTIALS is fundamentally about dealing with
processes that are in a less than completely trusting relationship.
> With regards to security, the question basically is what is the consequence
> of passing the wrong id. As I understand it, Interpreting the id to be pid
> or tid, the effective uid and gid will be the same. It would be a problem
> only if the incorrect interpretation of the id would refer a different process.
> But that cannot happen as the the global tid(gettid() of a thread is
> unique.
There is also the issue that the receiving process could look, not see
the pid in proc and assume the sending process is dead. That I suspect
is the larger danger.
> As long as the thread is alive, that id cannot reference another process / thread.
> Unless the thread were to exit and the id gets recycled and got used for another
> thread or process. This would be no different from a process exiting and its
> pid getting recycled which is the case now.
Largely I agree.
If all you want are pid translations I suspect the are far easier ways
thant updating the SCM_CREDENTIALS code.
Eric
^ permalink raw reply
* Re: [patch net-next 6/8] mlxsw: spectrum_dpipe: Add support for IPv6 host table dump
From: David Ahern @ 2017-08-30 17:42 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, arkadis, idosch, mlxsw
In-Reply-To: <20170830120306.6128-7-jiri@resnulli.us>
On 8/30/17 6:03 AM, Jiri Pirko wrote:
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
> index 5924e97..75da2ef 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
> @@ -386,8 +386,19 @@ mlxsw_sp_dpipe_table_host_match_action_prepare(struct devlink_dpipe_match *match
>
> match = &matches[MLXSW_SP_DPIPE_TABLE_HOST_MATCH_DIP];
> match->type = DEVLINK_DPIPE_MATCH_TYPE_FIELD_EXACT;
> - match->header = &devlink_dpipe_header_ipv4;
> - match->field_id = DEVLINK_DPIPE_FIELD_IPV4_DST_IP;
> + switch (type) {
> + case AF_INET:
> + match->header = &devlink_dpipe_header_ipv4;
> + match->field_id = DEVLINK_DPIPE_FIELD_IPV4_DST_IP;
> + break;
> + case AF_INET6:
> + match->header = &devlink_dpipe_header_ipv6;
> + match->field_id = DEVLINK_DPIPE_FIELD_IPV6_DST_IP;
> + break;
> + default:
> + WARN_ON(1);
Here as well.
> + return;
> + }
>
> action->type = DEVLINK_DPIPE_ACTION_TYPE_FIELD_MODIFY;
> action->header = &devlink_dpipe_header_ethernet;
> @@ -424,7 +435,18 @@ mlxsw_sp_dpipe_table_host_entry_prepare(struct devlink_dpipe_entry *entry,
> match_value = &match_values[MLXSW_SP_DPIPE_TABLE_HOST_MATCH_DIP];
>
> match_value->match = match;
> - match_value->value_size = sizeof(u32);
> + switch (type) {
> + case AF_INET:
> + match_value->value_size = sizeof(u32);
> + break;
> + case AF_INET6:
> + match_value->value_size = sizeof(struct in6_addr);
> + break;
> + default:
> + WARN_ON(1);
And here. WARN_ON is overkill
> + return -EINVAL;
> + }
> +
> match_value->value = kmalloc(match_value->value_size, GFP_KERNEL);
> if (!match_value->value)
> return -ENOMEM;
^ permalink raw reply
* Re: [patch net-next 7/8] mlxsw: spectrum_router: Add support for setting counters on IPv6 neighbors
From: David Ahern @ 2017-08-30 17:43 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, arkadis, idosch, mlxsw
In-Reply-To: <20170830120306.6128-8-jiri@resnulli.us>
On 8/30/17 6:03 AM, Jiri Pirko wrote:
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> index db57c0c..0cf6810 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> @@ -1008,21 +1008,33 @@ mlxsw_sp_neigh_entry_remove(struct mlxsw_sp *mlxsw_sp,
> }
>
> static bool
> -mlxsw_sp_neigh4_counter_should_alloc(struct mlxsw_sp *mlxsw_sp)
> +mlxsw_sp_neigh_counter_should_alloc(struct mlxsw_sp *mlxsw_sp,
> + struct mlxsw_sp_neigh_entry *neigh_entry)
> {
> struct devlink *devlink;
> + const char *table_name;
> +
> + switch (mlxsw_sp_neigh_entry_type(neigh_entry)) {
> + case AF_INET:
> + table_name = MLXSW_SP_DPIPE_TABLE_NAME_HOST4;
> + break;
> + case AF_INET6:
> + table_name = MLXSW_SP_DPIPE_TABLE_NAME_HOST6;
> + break;
> + default:
> + WARN_ON(1);
Another unnecessary WARN_ON
> + return false;
> + }
>
> devlink = priv_to_devlink(mlxsw_sp->core);
> - return devlink_dpipe_table_counter_enabled(devlink,
> - MLXSW_SP_DPIPE_TABLE_NAME_HOST4);
> + return devlink_dpipe_table_counter_enabled(devlink, table_name);
> }
>
^ permalink raw reply
* [PATCH 0/5] net: mdio-mux: Misc fix
From: Corentin Labbe @ 2017-08-30 17:46 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Corentin Labbe
Hello
This patch series fix minor problems found when working on the
dwmac-sun8i syscon mdio-mux.
Regards
Corentin Labbe (5):
net: mdio-mux: Fix NULL Comparison style
net: mdio-mux: Remove unnecessary 'out of memory' message
net: mdio-mux: printing driver version is useless
net: mdio-mux-mmioreg: Can handle 8/16/32 bits registers
net: mdio-mux: fix unbalanced put_device
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/mdio-mux.c | 15 ++++-----------
2 files changed, 5 insertions(+), 12 deletions(-)
--
2.13.5
^ permalink raw reply
* [PATCH 1/5] net: mdio-mux: Fix NULL Comparison style
From: Corentin Labbe @ 2017-08-30 17:46 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170830174651.30325-1-clabbe.montjoie@gmail.com>
This patch fix checkpatch warning about NULL Comparison style.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/phy/mdio-mux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index 942ceaf3fd3f..b18ad7082b88 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -120,7 +120,7 @@ int mdio_mux_init(struct device *dev,
}
pb = devm_kzalloc(dev, sizeof(*pb), GFP_KERNEL);
- if (pb == NULL) {
+ if (!pb) {
ret_val = -ENOMEM;
goto err_pb_kz;
}
@@ -144,7 +144,7 @@ int mdio_mux_init(struct device *dev,
}
cb = devm_kzalloc(dev, sizeof(*cb), GFP_KERNEL);
- if (cb == NULL) {
+ if (!cb) {
dev_err(dev,
"Error: Failed to allocate memory for child %pOF\n",
child_bus_node);
--
2.13.5
^ permalink raw reply related
* [PATCH 2/5] net: mdio-mux: Remove unnecessary 'out of memory' message
From: Corentin Labbe @ 2017-08-30 17:46 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170830174651.30325-1-clabbe.montjoie@gmail.com>
This patch fix checkpatch warning about unnecessary 'out of memory'
message.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/phy/mdio-mux.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index b18ad7082b88..5e08e89465c5 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -145,9 +145,6 @@ int mdio_mux_init(struct device *dev,
cb = devm_kzalloc(dev, sizeof(*cb), GFP_KERNEL);
if (!cb) {
- dev_err(dev,
- "Error: Failed to allocate memory for child %pOF\n",
- child_bus_node);
ret_val = -ENOMEM;
continue;
}
@@ -156,9 +153,6 @@ int mdio_mux_init(struct device *dev,
cb->mii_bus = mdiobus_alloc();
if (!cb->mii_bus) {
- dev_err(dev,
- "Error: Failed to allocate MDIO bus for child %pOF\n",
- child_bus_node);
ret_val = -ENOMEM;
devm_kfree(dev, cb);
continue;
--
2.13.5
^ permalink raw reply related
* [PATCH 4/5] net: mdio-mux-mmioreg: Can handle 8/16/32 bits registers
From: Corentin Labbe @ 2017-08-30 17:46 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170830174651.30325-1-clabbe.montjoie@gmail.com>
This patch fix an old information that mdio-mux-mmioreg can only handle
8bit registers.
This is not true anymore.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/phy/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5afe6fdcc968..a9d16a3af514 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -85,7 +85,7 @@ config MDIO_BUS_MUX_MMIOREG
parent bus. Child bus selection is under the control of one of
the FPGA's registers.
- Currently, only 8-bit registers are supported.
+ Currently, only 8/16/32 bits registers are supported.
config MDIO_CAVIUM
tristate
--
2.13.5
^ permalink raw reply related
* [PATCH 3/5] net: mdio-mux: printing driver version is useless
From: Corentin Labbe @ 2017-08-30 17:46 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170830174651.30325-1-clabbe.montjoie@gmail.com>
Remove the driver version information because this information
is not useful in an upstream kernel driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/phy/mdio-mux.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index 5e08e89465c5..9a889a529b9c 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -179,7 +179,6 @@ int mdio_mux_init(struct device *dev,
}
if (pb->children) {
*mux_handle = pb;
- dev_info(dev, "Version " DRV_VERSION "\n");
return 0;
}
--
2.13.5
^ permalink raw reply related
* [PATCH 5/5] net: mdio-mux: fix unbalanced put_device
From: Corentin Labbe @ 2017-08-30 17:46 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170830174651.30325-1-clabbe.montjoie@gmail.com>
mdio_mux_uninit() call put_device (unconditionally) because of
of_mdio_find_bus() in mdio_mux_init.
But of_mdio_find_bus is only called if mux_bus is empty.
If mux_bus is set, mdio_mux_uninit will print a "refcount_t: underflow"
trace.
This patch add a get_device in the other branch of "if (mux_bus)".
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/phy/mdio-mux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index 9a889a529b9c..0b7d3d30ae97 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -117,6 +117,7 @@ int mdio_mux_init(struct device *dev,
} else {
parent_bus_node = NULL;
parent_bus = mux_bus;
+ get_device(&parent_bus->dev);
}
pb = devm_kzalloc(dev, sizeof(*pb), GFP_KERNEL);
@@ -186,8 +187,7 @@ int mdio_mux_init(struct device *dev,
devm_kfree(dev, pb);
err_pb_kz:
/* balance the reference of_mdio_find_bus() took */
- if (!mux_bus)
- put_device(&parent_bus->dev);
+ put_device(&parent_bus->dev);
err_parent_bus:
of_node_put(parent_bus_node);
return ret_val;
--
2.13.5
^ permalink raw reply related
* Re: linux-next: Signed-off-by missing for commit in the net-next tree
From: David Miller @ 2017-08-30 17:52 UTC (permalink / raw)
To: dsahern; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <32dc9201-c7a2-2cf0-e8a1-1c735b8784ee@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 30 Aug 2017 10:53:48 -0600
> On 8/30/17 10:51 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Commit
>>
>> 1b70d792cf67 ("ipv6: Use rt6i_idev index for echo replies to a local address")
>>
>> is missing a Signed-off-by from its author.
>>
>
> Eric pointed this out last night. The commit message copied output from
> a command that contained '---' so git ignored the remainder of the message.
Yes, it unfortunately got clipped off by GIT due to how the
commit message was written. :(
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2017-08-30 17:54 UTC (permalink / raw)
To: kvalo; +Cc: pavel, xiyou.wangcong, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <87val5rmh8.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Wed, 30 Aug 2017 20:31:31 +0300
> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug
> has been there for 7 years so waiting for a few more weeks should not
> hurt.
As a maintainer you have a right to handle bug fixing in that way, but
certainly that is not how I would handle this.
It's easy to validate this fix, it's extremely unlikely to cause
a regression, and fixes a problem someone actually was able to
trigger.
Deferring to -next only has the side effect of making people wait
longer for the fix.
^ permalink raw reply
* Re: [PATCH net-next 0/2] tcp: re-add header prediction
From: David Miller @ 2017-08-30 18:20 UTC (permalink / raw)
To: fw; +Cc: netdev, edumazet
In-Reply-To: <20170830172458.18544-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 30 Aug 2017 19:24:56 +0200
> Eric reported a performance regression caused by header prediction
> removal.
>
> We now call tcp_ack() much more frequently, for some workloads
> this brings in enough cache line misses to become noticeable.
>
> We could possibly still kill HP provided we find a different
> way to suppress unneeded tcp_ack, but given we're late in
> the cycle it seems preferable to revert.
Indeed, reverting at this point in the game is the best thing
to do right now.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: Add SRIOV VGT+ support
From: Saeed Mahameed @ 2017-08-30 18:30 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List,
Eugenia Emantayev, Mohamad Haj Yahia, Hannes Frederic Sowa
In-Reply-To: <20170829164330.GA22607@bistromath.localdomain>
On Tue, Aug 29, 2017 at 7:43 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> 2017-08-29, 13:13:09 +0300, Saeed Mahameed wrote:
>> On Mon, Aug 28, 2017 at 6:52 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
>> > 2017-08-27, 14:06:15 +0300, Saeed Mahameed wrote:
>> > [...]
>> >> +#define VF_VLAN_BITMAP DIV_ROUND_UP(VF_VLAN_N_VID, sizeof(__u64) * BITS_PER_BYTE)
>> >> +struct ifla_vf_vlan_trunk {
>> >> + __u32 vf;
>> >> + __u64 allowed_vlans_8021q_bm[VF_VLAN_BITMAP];
>> >> + __u64 allowed_vlans_8021ad_bm[VF_VLAN_BITMAP];
>> >> +};
>> >
>> > This is huge (1032B). And you put one of these in the netlink message
>> > for each VF. This means that with 51 VF (at least in my environment,
>> > where each VF takes 1296B), you're going to overflow the u16 size of a
>> > single attribute (IFLA_VFINFO_LIST), and you cannot dump the device
>> > anymore. I'm afraid this is going to break existing setups.
>> >
>>
>> Yes ! We will fix this,
>> we are considering to report only a boolean in VFINFO which indecates
>> if VGT+ is enable or not
>> and provide a new attribute per VF to report only the vlan list of specific VF.
>
> I don't see what this is going to look like. Maybe you can describe
> more precisely what you want to add to the netlink message? (otherwise
> I'll wait for the patches)
>
We are still looking for the best way from user experience perspective.
Currently we think we will only allow to query VF vlan list on one VF
at a time, with vlan list special ip route command.
Still under definition, we will let you know once ready.
> If you add large attributes for each VF, this is still going to break.
>
>
> Thanks.
>
> --
> Sabrina
^ permalink raw reply
* Re: [PATCH net-next 0/4] SRIOV VF VGT+ and violation counters support
From: Saeed Mahameed @ 2017-08-30 18:33 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: David S. Miller, Linux Netdev List, Eugenia Emantayev
In-Reply-To: <20170827110618.20599-1-saeedm@mellanox.com>
On Sun, Aug 27, 2017 at 2:06 PM, Saeed Mahameed <saeedm@mellanox.com> wrote:
> Hi Dave
>
> This series provides two security SRIOV related features (VGT+ and VF violation counters).
>
> VGT+ is a security feature that gives the administrator the ability of controlling
> the allowed VGT vlan IDs list that can be transmitted/received from/to the VF.
> The allowed VGT vlan IDs list is called "trunk".
>
Dave, I would like to drop this series for now since we need to respin
and find a better API to query vlan lists. it seems that it will take
some time for our developer to complete this. So i would like to
submit something else in the meanwhile.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH net-next 0/4] SRIOV VF VGT+ and violation counters support
From: David Miller @ 2017-08-30 18:39 UTC (permalink / raw)
To: saeedm; +Cc: saeedm, netdev, eugenia
In-Reply-To: <CALzJLG9FDh9XJKOGBxqxLqrJf3FSFxX8dZRLALxJRA7G-NQBBA@mail.gmail.com>
From: Saeed Mahameed <saeedm@dev.mellanox.co.il>
Date: Wed, 30 Aug 2017 21:33:18 +0300
> On Sun, Aug 27, 2017 at 2:06 PM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>> Hi Dave
>>
>> This series provides two security SRIOV related features (VGT+ and VF violation counters).
>>
>> VGT+ is a security feature that gives the administrator the ability of controlling
>> the allowed VGT vlan IDs list that can be transmitted/received from/to the VF.
>> The allowed VGT vlan IDs list is called "trunk".
>>
>
> Dave, I would like to drop this series for now since we need to respin
> and find a better API to query vlan lists. it seems that it will take
> some time for our developer to complete this. So i would like to
> submit something else in the meanwhile.
If you look in patchwork I marked these patches as "Changes requested" so there
is nothing you need to worry about.
^ permalink raw reply
* Re: [PATCH 3/5] net: mdio-mux: printing driver version is useless
From: Andrew Lunn @ 2017-08-30 18:46 UTC (permalink / raw)
To: Corentin Labbe; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <20170830174651.30325-4-clabbe.montjoie@gmail.com>
On Wed, Aug 30, 2017 at 07:46:49PM +0200, Corentin Labbe wrote:
> Remove the driver version information because this information
> is not useful in an upstream kernel driver.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Hi Corentin
You may as well remove DRV_VERSION from this file, not just here.
Andrew
^ permalink raw reply
* Re: [PATCH][net-next][V3] bpf: test_maps: fix typos, "conenct" and "listeen"
From: Daniel Borkmann @ 2017-08-30 18:47 UTC (permalink / raw)
To: Colin King, Alexei Starovoitov, Shuah Khan, netdev,
linux-kselftest, linux-kernel
In-Reply-To: <20170830171525.5688-1-colin.king@canonical.com>
On 08/30/2017 07:15 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to typos in printf error messages:
> "conenct" -> "connect"
> "listeen" -> "listen"
>
> thanks to Daniel Borkmann for spotting one of these mistakes
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH 1/5] net: mdio-mux: Fix NULL Comparison style
From: Andrew Lunn @ 2017-08-30 18:47 UTC (permalink / raw)
To: Corentin Labbe; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <20170830174651.30325-2-clabbe.montjoie@gmail.com>
On Wed, Aug 30, 2017 at 07:46:47PM +0200, Corentin Labbe wrote:
> This patch fix checkpatch warning about NULL Comparison style.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ 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