* 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 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 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 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 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/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: [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: 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
* [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
* [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 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 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 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 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
* 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
* 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: [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: 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: [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: [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-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-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
* [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][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
* Re: [GIT] Networking
From: Kalle Valo @ 2017-08-30 17:31 UTC (permalink / raw)
To: David Miller; +Cc: pavel, xiyou.wangcong, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20170830.101143.2305098064824357647.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Wed, 30 Aug 2017 17:45:31 +0300
>
>> Pavel Machek <pavel@ucw.cz> writes:
>>
>>> Could we get this one in?
>>>
>>> wl1251 misses a spin_lock_init().
>>>
>>> https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html
>>>
>>> It seems pretty trivial, yet getting the backtraces is not nice.
>>
>> It's in wireless-drivers-next and will be in 4.14-rc1:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=6e9aae179f290f1a44fce7ef8e9a8e2dd68ed1e4
>
> Is the bug only present in net-next?
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.
And Pavel can also submit it to the stable release, it should apply
without problems as wl1251 doesn't have had that many patches during the
last few years (if ever).
--
Kalle Valo
^ 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