* Re: [PATCH net-next 0/7] net: dsa: mv88e6xxx: prepare Wait Bit operation
From: David Miller @ 2019-08-12 4:27 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, f.fainelli, andrew
In-Reply-To: <20190809224759.5743-1-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Fri, 9 Aug 2019 18:47:52 -0400
> The Remote Management Interface has its own implementation of a Wait
> Bit operation, which requires a bit number and a value to wait for.
>
> In order to prepare the introduction of this implementation, rework the
> code waiting for bits and masks in mv88e6xxx to match this signature.
>
> This has the benefit to unify the implementation of wait routines while
> removing obsolete wait and update functions and also reducing the code.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] r8169: inline rtl8169_free_rx_databuff
From: David Miller @ 2019-08-12 4:26 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <e0902cae-4557-dcda-9c96-ad19b3c05993@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 9 Aug 2019 22:59:07 +0200
> rtl8169_free_rx_databuff is used in only one place, so let's inline it.
> We can improve the loop because rtl8169_init_ring zero's RX_databuff
> before calling rtl8169_rx_fill, and rtl8169_rx_fill fills
> Rx_databuff starting from index 0.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: phy: realtek: add support for integrated 2.5Gbps PHY in RTL8125
From: David Miller @ 2019-08-12 4:24 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <755b2bc9-22cb-f529-4188-0f4b6e48efbd@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 9 Aug 2019 20:41:58 +0200
> This series adds support for the integrated 2.5Gbps PHY in RTL8125.
> First three patches add necessary functionality to phylib.
>
> Changes in v2:
> - added patch 1
> - changed patch 4 to use a fake PHY ID that is injected by the
> network driver. This allows to use a dedicated PHY driver.
Series applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH][net-next] rxrpc: fix uninitialized return value in variable err
From: David Miller @ 2019-08-12 4:22 UTC (permalink / raw)
To: colin.king; +Cc: dhowells, linux-afs, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190809170259.29859-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 9 Aug 2019 18:02:59 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> An earlier commit removed the setting of err to -ENOMEM so currently
> the skb_shinfo(skb)->nr_frags > 16 check returns with an uninitialized
> bogus return code. Fix this by setting err to -ENOMEM to restore
> the original behaviour.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: b214b2d8f277 ("rxrpc: Don't use skb_cow_data() in rxkad")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
David, I assume you will pick this up.
^ permalink raw reply
* Re: [patch net-next] netdevsim: register couple of devlink params
From: David Miller @ 2019-08-12 4:20 UTC (permalink / raw)
To: jiri; +Cc: netdev, jakub.kicinski, mlxsw
In-Reply-To: <20190809110512.31779-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 9 Aug 2019 13:05:12 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Register couple of devlink params, one generic, one driver-specific.
> Make the values available over debugfs.
>
> Example:
> $ echo "111" > /sys/bus/netdevsim/new_device
> $ devlink dev param
> netdevsim/netdevsim111:
> name max_macs type generic
> values:
> cmode driverinit value 32
> name test1 type driver-specific
> values:
> cmode driverinit value true
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/max_macs
> 32
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/test1
> Y
> $ devlink dev param set netdevsim/netdevsim111 name max_macs cmode driverinit value 16
> $ devlink dev param set netdevsim/netdevsim111 name test1 cmode driverinit value false
> $ devlink dev reload netdevsim/netdevsim111
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/max_macs
> 16
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/test1
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* RE: [PATCH net-next v3 2/2] qed: Add driver API for flashing the config attributes.
From: Sudarsana Reddy Kalluru @ 2019-08-12 4:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Michal Kalderon, Ariel Elior
In-Reply-To: <DM5PR18MB2215C258FCC2276F0319D81EC4DA0@DM5PR18MB2215.namprd18.prod.outlook.com>
> -----Original Message-----
> From: Ariel Elior <aelior@marvell.com>
> Sent: Monday, August 5, 2019 8:00 PM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>; David Miller
> <davem@davemloft.net>
> Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>
> Subject: RE: [PATCH net-next v3 2/2] qed: Add driver API for flashing the
> config attributes.
>
> > From: Sudarsana Reddy Kalluru
> > Sent: Tuesday, July 30, 2019 6:36 AM
> > To: David Miller <davem@davemloft.net>
> >
> > > -----Original Message-----
> > > From: David Miller <davem@davemloft.net>
> > > Sent: Monday, July 29, 2019 11:34 PM
> > > To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > > Cc: netdev@vger.kernel.org; Michal Kalderon
> <mkalderon@marvell.com>;
> > > Ariel Elior <aelior@marvell.com>
> > > Subject: Re: [PATCH net-next v3 2/2] qed: Add driver API for
> > > flashing the config attributes.
> > >
> > > From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > > Date: Sat, 27 Jul 2019 18:55:49 -0700
> > >
> > > > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev
> > > > *cdev,
> > > const char *name)
> > > > rc = qed_nvm_flash_image_access(cdev, &data,
> > > > &check_resp);
> > > > break;
> > > > + case QED_NVM_FLASH_CMD_NVM_CFG_ID:
> > > > + rc = qed_nvm_flash_cfg_write(cdev, &data);
> > > > + break;
> >
> > > > default:
> > > > DP_ERR(cdev, "Unknown command %08x\n",
> > > cmd_type);
> > >
> > > I don't see how any existing portable interface can cause this new
> > > code to actually be used.
> > >
> > > You have to explain this to me.
> > The API qed_nvm_flash() is used to flash the user provided data (e.g.,
> > Management FW) to the required partitions of the adapter.
> > - Format of the input file would be - file signature info, followed
> > by one or more data sets.
> > - Each data set is represented with the header followed by its contents.
> > Header captures info such as command name (e.g., FILE_START), data
> > size etc., which specifies how to handle the data.
> > The API qed_nvm_flash() validates the user provided input file, parses
> > the data sets and handles each accordingly. Here one of the data sets
> > (preferably the last one) could be nvm-attributes page (with cmd-id =
> > QED_NVM_FLASH_CMD_NVM_CHANGE).
>
> This is basically an expansion of our existing ethtool -f implementation.
> The management FW has exposed an additional method of configuring some
> of the nvram options, and this makes use of that. The new code will come
> into use when newer FW files which contain configuration directives
> employing this API will be provided to ethtool -f.
>
> thanks,
> Ariel
Dave,
The series appears as "changes requested" in patchwork. Please let us know if any modifications need to be incorporated on this series?
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: David Miller @ 2019-08-12 4:13 UTC (permalink / raw)
To: jasowang; +Cc: mst, kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <360a3b91-1ac5-84c0-d34b-a4243fa748c4@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 12 Aug 2019 10:44:51 +0800
> On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
>> At this point how about we revert
>> 7f466032dc9e5a61217f22ea34b2df932786bbfc
>> for this release, and then re-apply a corrected version
>> for the next one?
>
> If possible, consider we've actually disabled the feature. How about
> just queued those patches for next release?
I'm tossing this series while you and Michael decide how to move forward.
^ permalink raw reply
* Re: [PATCHv2 net 0/2] Add netdev_level_ratelimited to avoid netdev msg flush
From: David Miller @ 2019-08-12 4:08 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, joe, tlfalcon
In-Reply-To: <20190809002941.15341-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Fri, 9 Aug 2019 08:29:39 +0800
> ibmveth 30000003 env3: h_multicast_ctrl rc=4 when adding an entry to the filter table
You need to root cause and fix the reason this message appears so much.
Once I let you rate limit the message you will have zero incentive to
fix the real problem and fix it.
^ permalink raw reply
* Re: [PATCH net] netdevsim: Restore per-network namespace accounting for fib entries
From: David Miller @ 2019-08-12 4:02 UTC (permalink / raw)
To: dsahern; +Cc: netdev, jiri, dsahern
In-Reply-To: <20190806191517.8713-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Tue, 6 Aug 2019 12:15:17 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Prior to the commit in the fixes tag, the resource controller in netdevsim
> tracked fib entries and rules per network namespace. Restore that behavior.
>
> Fixes: 5fc494225c1e ("netdevsim: create devlink instance per netdevsim instance")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks for bringing this to our attention and fixing it David.
Jiri, I disagree you on every single possible level.
If you didn't like how netdevsim worked in this area the opportunity to do
something about it was way back when it went in.
No matter how completely busted or disagreeable an interface is, once we have
committed it to a release (and in particular people are knowingly using and
depending upon it) you cannot break it.
It doesn't matter how much you disagree with something, you cannot break it
when it's out there and actively in use.
Do you have any idea how much stuff I'd like to break because I think the
design turned out to be completely wrong? But I can't.
^ permalink raw reply
* Re: [PATCH] nfc: st-nci: Fix an incorrect skb_buff size in 'st_nci_i2c_read()'
From: David Miller @ 2019-08-12 3:57 UTC (permalink / raw)
To: christophe.jaillet
Cc: tglx, gregkh, colin.king, allison, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20190806141640.13197-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Tue, 6 Aug 2019 16:16:40 +0200
> In 'st_nci_i2c_read()', we allocate a sk_buff with a size of
> ST_NCI_I2C_MIN_SIZE + len.
>
> However, later on, we first 'skb_reserve()' ST_NCI_I2C_MIN_SIZE bytes, then
> we 'skb_put()' ST_NCI_I2C_MIN_SIZE bytes.
> Finally, if 'len' is not 0, we 'skb_put()' 'len' bytes.
>
> So we use ST_NCI_I2C_MIN_SIZE*2 + len bytes.
>
> This is incorrect and should already panic. I guess that it does not occur
> because of extra memory allocated because of some rounding.
>
> Fix it and allocate enough room for the 'skb_reserve()' and the 'skb_put()'
> calls.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This patch is LIKELY INCORRECT. So think twice to what is the correct
> solution before applying it.
> Maybe the skb_reserve should be axed or some other sizes are incorrect.
> There seems to be an issue, that's all I can say.
The skb_reserve() should be removed, and the second memcpy() should remove
the " + ST_NCI_I2C_MIN_SIZE".
This SKB just get sent down to ndlc_recv() so the content returned from I2C
should places at skb->data to be processed.
Pretty clear this code was never tested.
^ permalink raw reply
* Re: [PATCH net] ipv4/route: do not check saddr dev if iif is LOOPBACK_IFINDEX
From: David Miller @ 2019-08-12 3:49 UTC (permalink / raw)
To: dsahern; +Cc: liuhangbin, netdev, sbrivio, mleitner
In-Reply-To: <209d2ebf-aeb1-de08-2343-f478d51b92fa@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 1 Aug 2019 22:16:00 -0600
> On 8/1/19 10:13 PM, Hangbin Liu wrote:
>> On Thu, Aug 01, 2019 at 01:51:25PM -0600, David Ahern wrote:
>>> On 8/1/19 2:29 AM, Hangbin Liu wrote:
>>>> Jianlin reported a bug that for IPv4, ip route get from src_addr would fail
>>>> if src_addr is not an address on local system.
>>>>
>>>> \# ip route get 1.1.1.1 from 2.2.2.2
>>>> RTNETLINK answers: Invalid argument
>>>
>>> so this is a forwarding lookup in which case iif should be set. Based on
>>
>> with out setting iif in userspace, the kernel set iif to lo by default.
>
> right, it presumes locally generated traffic.
>>
>>> the above 'route get' inet_rtm_getroute is doing a lookup as if it is
>>> locally generated traffic.
>>
>> yeah... but what about the IPv6 part. That cause a different behavior in
>> userspace.
>
> just one of many, many annoying differences between v4 and v6. We could
> try to catalog it.
I think we just have to accept this difference because this change would
change behavior for all route lookups, not just those done by ip route get.
^ permalink raw reply
* [PATCH] net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
From: Nathan Chancellor @ 2019-08-12 3:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, clang-built-linux, Nathan Chancellor
clang warns:
drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
^ ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
^~
&
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
~^~~~~~~~~~~~~~~
1 warning generated.
Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.
Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: https://github.com/ClangBuiltLinux/linux/issues/608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c
index 8479a440527b..12466a72cefc 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -1504,7 +1504,7 @@ tc35815_rx(struct net_device *dev, int limit)
pci_unmap_single(lp->pci_dev,
lp->rx_skbs[cur_bd].skb_dma,
RX_BUF_SIZE, PCI_DMA_FROMDEVICE);
- if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
+ if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN != 0)
memmove(skb->data, skb->data - NET_IP_ALIGN,
pkt_len);
data = skb_put(skb, pkt_len);
--
2.23.0.rc2
^ permalink raw reply related
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: Jason Wang @ 2019-08-12 2:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <20190810134948-mutt-send-email-mst@kernel.org>
On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
>> Hi all:
>>
>> This series try to fix several issues introduced by meta data
>> accelreation series. Please review.
>>
>> Changes from V4:
>> - switch to use spinlock synchronize MMU notifier with accessors
>>
>> Changes from V3:
>> - remove the unnecessary patch
>>
>> Changes from V2:
>> - use seqlck helper to synchronize MMU notifier with vhost worker
>>
>> Changes from V1:
>> - try not use RCU to syncrhonize MMU notifier with vhost worker
>> - set dirty pages after no readers
>> - return -EAGAIN only when we find the range is overlapped with
>> metadata
>>
>> Jason Wang (9):
>> vhost: don't set uaddr for invalid address
>> vhost: validate MMU notifier registration
>> vhost: fix vhost map leak
>> vhost: reset invalidate_count in vhost_set_vring_num_addr()
>> vhost: mark dirty pages during map uninit
>> vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
>> vhost: do not use RCU to synchronize MMU notifier with worker
>> vhost: correctly set dirty pages in MMU notifiers callback
>> vhost: do not return -EAGAIN for non blocking invalidation too early
>>
>> drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
>> drivers/vhost/vhost.h | 6 +-
>> 2 files changed, 122 insertions(+), 86 deletions(-)
> This generally looks more solid.
>
> But this amounts to a significant overhaul of the code.
>
> At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
> for this release, and then re-apply a corrected version
> for the next one?
If possible, consider we've actually disabled the feature. How about
just queued those patches for next release?
Thanks
>
>> --
>> 2.18.1
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-08-12 2:21 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Huy Nguyen,
Vlad Buslov, Saeed Mahameed
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
between commit:
93b3586e070b ("net/mlx5: Support inner header match criteria for non decap flow action")
from the net tree and commit:
226f2ca3075a ("net/mlx5e: Change flow flags type to unsigned long")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index deeb65da99f3,5be3da621499..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1839,18 -2057,15 +2061,20 @@@ static int parse_cls_flower(struct mlx5
struct mlx5_core_dev *dev = priv->mdev;
struct mlx5_eswitch *esw = dev->priv.eswitch;
struct mlx5e_rep_priv *rpriv = priv->ppriv;
- u8 match_level, tunnel_match_level = MLX5_MATCH_NONE;
struct mlx5_eswitch_rep *rep;
+ bool is_eswitch_flow;
int err;
- err = __parse_cls_flower(priv, spec, f, filter_dev, &match_level, &tunnel_match_level);
+ inner_match_level = MLX5_MATCH_NONE;
+ outer_match_level = MLX5_MATCH_NONE;
+
+ err = __parse_cls_flower(priv, spec, f, filter_dev, &inner_match_level,
+ &outer_match_level);
+ non_tunnel_match_level = (inner_match_level == MLX5_MATCH_NONE) ?
+ outer_match_level : inner_match_level;
- if (!err && (flow->flags & MLX5E_TC_FLOW_ESWITCH)) {
+ is_eswitch_flow = mlx5e_is_eswitch_flow(flow);
+ if (!err && is_eswitch_flow) {
rep = rpriv->rep;
if (rep->vport != MLX5_VPORT_UPLINK &&
(esw->offloads.inline_mode != MLX5_INLINE_MODE_NONE &&
@@@ -1864,11 -2079,11 +2088,11 @@@
}
}
- if (flow->flags & MLX5E_TC_FLOW_ESWITCH) {
+ if (is_eswitch_flow) {
- flow->esw_attr->match_level = match_level;
- flow->esw_attr->tunnel_match_level = tunnel_match_level;
+ flow->esw_attr->inner_match_level = inner_match_level;
+ flow->esw_attr->outer_match_level = outer_match_level;
} else {
- flow->nic_attr->match_level = match_level;
+ flow->nic_attr->match_level = non_tunnel_match_level;
}
return err;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: David Ahern @ 2019-08-12 1:37 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roopa Prabhu, netdev, David Miller, Jakub Kicinski,
Stephen Hemminger, dcbw, Michal Kubecek, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <b0a9ec0d-c00b-7aaf-46d4-c74d18498698@gmail.com>
On 8/11/19 7:34 PM, David Ahern wrote:
> On 8/10/19 12:30 AM, Jiri Pirko wrote:
>> Could you please write me an example message of add/remove?
>
> altnames are for existing netdevs, yes? existing netdevs have an id and
> a name - 2 existing references for identifying the existing netdev for
> which an altname will be added. Even using the altname as the main
> 'handle' for a setlink change, I see no reason why the GETLINK api can
> not take an the IFLA_ALT_IFNAME and return the full details of the
> device if the altname is unique.
>
> So, what do the new RTM commands give you that you can not do with
> RTM_*LINK?
>
To put this another way, the ALT_NAME is an attribute of an object - a
LINK. It is *not* a separate object which requires its own set of
commands for manipulating.
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: David Ahern @ 2019-08-12 1:34 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roopa Prabhu, netdev, David Miller, Jakub Kicinski,
Stephen Hemminger, dcbw, Michal Kubecek, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <20190810063047.GC2344@nanopsycho.orion>
On 8/10/19 12:30 AM, Jiri Pirko wrote:
> Could you please write me an example message of add/remove?
altnames are for existing netdevs, yes? existing netdevs have an id and
a name - 2 existing references for identifying the existing netdev for
which an altname will be added. Even using the altname as the main
'handle' for a setlink change, I see no reason why the GETLINK api can
not take an the IFLA_ALT_IFNAME and return the full details of the
device if the altname is unique.
So, what do the new RTM commands give you that you can not do with
RTM_*LINK?
^ permalink raw reply
* Re: [v4,2/4] tools: bpftool: add net detach command to detach XDP on interface
From: Y Song @ 2019-08-12 0:29 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <20190809133248.19788-3-danieltimlee@gmail.com>
On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee <danieltimlee@gmail.com> wrote:
>
> By this commit, using `bpftool net detach`, the attached XDP prog can
> be detached. Detaching the BPF prog will be done through libbpf
> 'bpf_set_link_xdp_fd' with the progfd set to -1.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> tools/bpf/bpftool/net.c | 42 ++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
> index 74cc346c36cd..ef1e576c6dba 100644
> --- a/tools/bpf/bpftool/net.c
> +++ b/tools/bpf/bpftool/net.c
> @@ -343,6 +343,43 @@ static int do_attach(int argc, char **argv)
> return 0;
> }
>
> +static int do_detach(int argc, char **argv)
> +{
> + enum net_attach_type attach_type;
> + int progfd, ifindex, err = 0;
> +
> + /* parse detach args */
> + if (!REQ_ARGS(3))
> + return -EINVAL;
> +
> + attach_type = parse_attach_type(*argv);
> + if (attach_type == net_attach_type_size) {
> + p_err("invalid net attach/detach type: %s", *argv);
> + return -EINVAL;
> + }
> + NEXT_ARG();
> +
> + ifindex = net_parse_dev(&argc, &argv);
> + if (ifindex < 1)
> + return -EINVAL;
> +
> + /* detach xdp prog */
> + progfd = -1;
> + if (is_prefix("xdp", attach_type_strings[attach_type]))
> + err = do_attach_detach_xdp(progfd, attach_type, ifindex, NULL);
> +
> + if (err < 0) {
> + p_err("interface %s detach failed: %s",
> + attach_type_strings[attach_type], strerror(errno));
> + return err;
> + }
Similar to previous patch, here we should use "strerror(-err)".
With this fixed, you can add my ack:
Acked-by: Yonghong Song <yhs@fb.com>
> +
> + if (json_output)
> + jsonw_null(json_wtr);
> +
> + return 0;
> +}
> +
[...]
^ permalink raw reply
* Re: [v4,1/4] tools: bpftool: add net attach command to attach XDP on interface
From: Y Song @ 2019-08-12 0:26 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <20190809133248.19788-2-danieltimlee@gmail.com>
On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee <danieltimlee@gmail.com> wrote:
>
> By this commit, using `bpftool net attach`, user can attach XDP prog on
> interface. New type of enum 'net_attach_type' has been made, as stated at
> cover-letter, the meaning of 'attach' is, prog will be attached on interface.
>
> With 'overwrite' option at argument, attached XDP program could be replaced.
> Added new helper 'net_parse_dev' to parse the network device at argument.
>
> BPF prog will be attached through libbpf 'bpf_set_link_xdp_fd'.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> tools/bpf/bpftool/net.c | 136 +++++++++++++++++++++++++++++++++++++---
> 1 file changed, 129 insertions(+), 7 deletions(-)
>
> diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
> index 67e99c56bc88..74cc346c36cd 100644
> --- a/tools/bpf/bpftool/net.c
> +++ b/tools/bpf/bpftool/net.c
> @@ -55,6 +55,35 @@ struct bpf_attach_info {
> __u32 flow_dissector_id;
> };
>
> +enum net_attach_type {
> + NET_ATTACH_TYPE_XDP,
> + NET_ATTACH_TYPE_XDP_GENERIC,
> + NET_ATTACH_TYPE_XDP_DRIVER,
> + NET_ATTACH_TYPE_XDP_OFFLOAD,
> +};
> +
> +static const char * const attach_type_strings[] = {
> + [NET_ATTACH_TYPE_XDP] = "xdp",
> + [NET_ATTACH_TYPE_XDP_GENERIC] = "xdpgeneric",
> + [NET_ATTACH_TYPE_XDP_DRIVER] = "xdpdrv",
> + [NET_ATTACH_TYPE_XDP_OFFLOAD] = "xdpoffload",
> +};
> +
> +const size_t net_attach_type_size = ARRAY_SIZE(attach_type_strings);
> +
> +static enum net_attach_type parse_attach_type(const char *str)
> +{
> + enum net_attach_type type;
> +
> + for (type = 0; type < net_attach_type_size; type++) {
> + if (attach_type_strings[type] &&
> + is_prefix(str, attach_type_strings[type]))
> + return type;
> + }
> +
> + return net_attach_type_size;
> +}
> +
> static int dump_link_nlmsg(void *cookie, void *msg, struct nlattr **tb)
> {
> struct bpf_netdev_t *netinfo = cookie;
> @@ -223,6 +252,97 @@ static int query_flow_dissector(struct bpf_attach_info *attach_info)
> return 0;
> }
>
> +static int net_parse_dev(int *argc, char ***argv)
> +{
> + int ifindex;
> +
> + if (is_prefix(**argv, "dev")) {
> + NEXT_ARGP();
> +
> + ifindex = if_nametoindex(**argv);
> + if (!ifindex)
> + p_err("invalid devname %s", **argv);
> +
> + NEXT_ARGP();
> + } else {
> + p_err("expected 'dev', got: '%s'?", **argv);
> + return -1;
> + }
> +
> + return ifindex;
> +}
> +
> +static int do_attach_detach_xdp(int progfd, enum net_attach_type attach_type,
> + int ifindex, bool overwrite)
> +{
> + __u32 flags = 0;
> +
> + if (!overwrite)
> + flags = XDP_FLAGS_UPDATE_IF_NOEXIST;
> + if (attach_type == NET_ATTACH_TYPE_XDP_GENERIC)
> + flags |= XDP_FLAGS_SKB_MODE;
> + if (attach_type == NET_ATTACH_TYPE_XDP_DRIVER)
> + flags |= XDP_FLAGS_DRV_MODE;
> + if (attach_type == NET_ATTACH_TYPE_XDP_OFFLOAD)
> + flags |= XDP_FLAGS_HW_MODE;
> +
> + return bpf_set_link_xdp_fd(ifindex, progfd, flags);
> +}
> +
> +static int do_attach(int argc, char **argv)
> +{
> + enum net_attach_type attach_type;
> + int progfd, ifindex, err = 0;
> + bool overwrite = false;
> +
> + /* parse attach args */
> + if (!REQ_ARGS(5))
> + return -EINVAL;
> +
> + attach_type = parse_attach_type(*argv);
> + if (attach_type == net_attach_type_size) {
> + p_err("invalid net attach/detach type: %s", *argv);
> + return -EINVAL;
> + }
> + NEXT_ARG();
> +
> + progfd = prog_parse_fd(&argc, &argv);
> + if (progfd < 0)
> + return -EINVAL;
> +
> + ifindex = net_parse_dev(&argc, &argv);
> + if (ifindex < 1) {
> + close(progfd);
> + return -EINVAL;
> + }
> +
> + if (argc) {
> + if (is_prefix(*argv, "overwrite")) {
> + overwrite = true;
> + } else {
> + p_err("expected 'overwrite', got: '%s'?", *argv);
> + close(progfd);
> + return -EINVAL;
> + }
> + }
> +
> + /* attach xdp prog */
> + if (is_prefix("xdp", attach_type_strings[attach_type]))
> + err = do_attach_detach_xdp(progfd, attach_type, ifindex,
> + overwrite);
> +
> + if (err < 0) {
> + p_err("interface %s attach failed: %s",
> + attach_type_strings[attach_type], strerror(errno));
> + return err;
> + }
I tried the below example,
-bash-4.4$ sudo ./bpftool net attach x pinned /sys/fs/bpf/xdp_example
dev v1
-bash-4.4$ sudo ./bpftool net attach x pinned /sys/fs/bpf/xdp_example dev v1
Kernel error message: XDP program already attached
Error: interface xdp attach failed: Success
-bash-4.4$
It printed out "Success" as errno here is 0.
The errno is encoded in variable err. Function bpf_set_link_xdp_fd()
uses netlink interface to do setting. The syscall may be find (errno = 0)
but the netlink msg may contain error code, which is returned with err.
So the above strerror(errno) should be strerror(-err).
libbpf API libbpf_strerror_r() accepts positive or negative err code which
you could use as well here.
With this issue fixed. You can add:
Acked-by: Yonghong Song <yhs@fb.com>
> +
> + if (json_output)
> + jsonw_null(json_wtr);
> +
> + return 0;
> +}
> +
[...]
^ permalink raw reply
* linux-next: manual merge of the afs tree with the net tree
From: Stephen Rothwell @ 2019-08-12 0:17 UTC (permalink / raw)
To: David Howells, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
Hi all,
Today's linux-next merge of the afs tree got conflicts in:
net/rxrpc/input.c
between commits:
730c5fd42c1e ("rxrpc: Fix local endpoint refcounting")
e8c3af6bb33a ("rxrpc: Don't bother generating maxSkew in the ACK packet")
from the net tree and commits:
5c2833938bf5 ("rxrpc: Fix local endpoint refcounting")
49bbdebb23f2 ("rxrpc: Don't bother generating maxSkew in the ACK packet")
from the afs tree.
I fixed it up (I just used the latter versions) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v2 4/4] selftests/bpf: add sockopt clone/inheritance test
From: Yonghong Song @ 2019-08-11 23:54 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Martin Lau
In-Reply-To: <20190809161038.186678-5-sdf@google.com>
On 8/9/19 9:10 AM, Stanislav Fomichev wrote:
> Add a test that calls setsockopt on the listener socket which triggers
> BPF program. This BPF program writes to the sk storage and sets
> clone flag. Make sure that sk storage is cloned for a newly
> accepted connection.
>
> We have two cloned maps in the tests to make sure we hit both cases
> in bpf_sk_storage_clone: first element (sk_storage_alloc) and
> non-first element(s) (selem_link_map).
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/4] bpf: support cloning sk storage on accept()
From: Yonghong Song @ 2019-08-11 23:54 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Martin Lau
In-Reply-To: <20190809161038.186678-3-sdf@google.com>
On 8/9/19 9:10 AM, Stanislav Fomichev wrote:
> Add new helper bpf_sk_storage_clone which optionally clones sk storage
> and call it from sk_clone_lock.
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/4] bpf: export bpf_map_inc_not_zero
From: Yonghong Song @ 2019-08-11 23:53 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Martin Lau
In-Reply-To: <20190809161038.186678-2-sdf@google.com>
On 8/9/19 9:10 AM, Stanislav Fomichev wrote:
> Rename existing bpf_map_inc_not_zero to __bpf_map_inc_not_zero to
> indicate that it's caller's responsibility to do proper locking.
> Create and export bpf_map_inc_not_zero wrapper that properly
> locks map_idr_lock. Will be used in the next commit to
> hold a map while cloning a socket.
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Michal Kubecek @ 2019-08-11 22:10 UTC (permalink / raw)
To: netdev
Cc: Roopa Prabhu, Jiri Pirko, David Miller, Jakub Kicinski,
Stephen Hemminger, David Ahern, dcbw, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <CAJieiUi3n2kKGBVogHBJOd1q+fUjm8ik+xKvDTOxodnZjmH2WQ@mail.gmail.com>
On Sat, Aug 10, 2019 at 12:39:31PM -0700, Roopa Prabhu wrote:
> On Sat, Aug 10, 2019 at 8:50 AM Michal Kubecek <mkubecek@suse.cz> wrote:
> >
> > On Sat, Aug 10, 2019 at 06:46:57AM -0700, Roopa Prabhu wrote:
> > > On Fri, Aug 9, 2019 at 8:46 AM Michal Kubecek <mkubecek@suse.cz> wrote:
> > > >
> > > > On Fri, Aug 09, 2019 at 08:40:25AM -0700, Roopa Prabhu wrote:
> > > > > to that point, I am also not sure why we have a new API For multiple
> > > > > names. I mean why support more than two names (existing old name and
> > > > > a new name to remove the length limitation) ?
> > > >
> > > > One use case is to allow "predictable names" from udev/systemd to work
> > > > the way do for e.g. block devices, see
> > > >
> > > > http://lkml.kernel.org/r/20190628162716.GF29149@unicorn.suse.cz
> > > >
> > >
> > > thanks for the link. don't know the details about alternate block
> > > device names. Does user-space generate multiple and assign them to a
> > > kernel object as proposed in this series ?. is there a limit to number
> > > of names ?. my understanding of 'predictable names' was still a single
> > > name but predictable structure to the name.
> >
> > It is a single name but IMHO mostly because we can only have one name.
> > For block devices, udev uses symlinks to create multiple aliases based
> > on different naming schemes, e.g.
> >
> > mike@lion:~> find -L /dev/disk/ -samefile /dev/sda2 -exec ls -l {} +
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68A_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-0ATA_WDC_WD30EFRX-68A_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-1ATA_WDC_WD30EFRX-68AX9N0_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-350014ee6589cfea0-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/wwn-0x50014ee6589cfea0-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-partlabel/root2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-partuuid/71affb47-a93b-40fd-8986-d2e227e1b39d -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-path/pci-0000:00:11.0-ata-1-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-path/pci-0000:00:11.0-scsi-0:0:0:0-part2 -> ../../sda2
> >
> > Few years ago, udev even dropped support for renaming block and
> > character devices (NAME="...") so that it now keeps kernel name and only
> > creates symlinks to it. Recent versions only allow NAME="..." for
> > network devices.
>
> ok thanks for the details. This looks like names that are structured
> on hardware info which could fall into devlinks scope and they point
> to a single name.
> We should think about keeping them under devlink (by-id, by-mac etc).
> It already can recognize network interfaces by id.
Not all of them are hardware based, there are also links based on
filesystem label or UUID. But my point is rather that udev creates
multiple links so that any of them can be used in any place where
a block device is to be identified.
As network devices can have only one name, udev drops kernel provided
name completely and replaces it with name following one naming scheme.
Thus we have to know which naming scheme is going to be used and make
sure it does not change. With multiple alternative names, we could also
have all udev provided names at once (and also the original one from
kernel).
Michal
^ permalink raw reply
* Re: pull-request: bpf 2019-08-11
From: David Miller @ 2019-08-11 21:49 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev, bpf
In-Reply-To: <20190811195834.3430-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 11 Aug 2019 21:58:34 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) x64 JIT code generation fix for backward-jumps to 1st insn, from Alexei.
>
> 2) Fix buggy multi-closing of BTF file descriptor in libbpf, from Andrii.
>
> 3) Fix libbpf_num_possible_cpus() to make it thread safe, from Takshak.
>
> 4) Fix bpftool to dump an error if pinning fails, from Jakub.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-11 21:33 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Mashak
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
Hi all,
In commit
e1fea322fc6d ("net sched: update skbedit action for batched events operations")
Fixes tag
Fixes: ca9b0e27e ("pkt_action: add new action skbedit")
has these problem(s):
- SHA1 should be at least 12 digits long
This Can be fixed for the future by setting core.abbrev to 12 (or
more) or (for git v2.11 or later) just making sure it is not set
(or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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