* Re: [PATCH net-next] rxrpc: Add /proc/net/rxrpc/peers to display peer list
From: David Miller @ 2018-10-16 5:53 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <153959946389.27408.16748794272430961849.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Mon, 15 Oct 2018 11:31:03 +0100
> Add /proc/net/rxrpc/peers to display the list of peers currently active.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH iproute2] macsec: fix off-by-one when parsing attributes
From: Sabrina Dubroca @ 2018-10-15 22:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Ahern
In-Reply-To: <20181015093658.7c590e29@xeon-e3>
2018-10-15, 09:36:58 -0700, Stephen Hemminger wrote:
> On Fri, 12 Oct 2018 17:34:12 +0200
> Sabrina Dubroca <sd@queasysnail.net> wrote:
>
> > I seem to have had a massive brainfart with uses of
> > parse_rtattr_nested(). The rtattr* array must have MAX+1 elements, and
> > the call to parse_rtattr_nested must have MAX as its bound. Let's fix
> > those.
> >
> > Fixes: b26fc590ce62 ("ip: add MACsec support")
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
>
> Applied,
> How did it ever work??
I'm guessing it wrote over some other stack variables before their
first use. It worked without issue until the JSON patch.
Thanks,
--
Sabrina
^ permalink raw reply
* Re: [Potential Spoof] Re: [PATCH net-next v4] net/ncsi: Add NCSI Broadcom OEM command
From: Samuel Mendoza-Jonas @ 2018-10-16 5:46 UTC (permalink / raw)
To: Vijay Khemka, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: openbmc@lists.ozlabs.org, linux-aspeed@lists.ozlabs.org
In-Reply-To: <E82A7C2E-6DBF-437D-B571-5376F0122176@fb.com>
On Mon, 2018-10-15 at 17:38 +0000, Vijay Khemka wrote:
>
> On 10/15/18, 10:27 AM, "Linux-aspeed on behalf of Vijay Khemka" <linux-aspeed-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of vijaykhemka@fb.com> wrote:
>
>
>
> On 10/14/18, 8:51 PM, "Samuel Mendoza-Jonas" <sam@mendozajonas.com> wrote:
>
> On Mon, 2018-10-15 at 13:08 +1100, Samuel Mendoza-Jonas wrote:
> > On Fri, 2018-10-12 at 11:20 -0700, Vijay Khemka wrote:
> > > This patch adds OEM Broadcom commands and response handling. It also
> > > defines OEM Get MAC Address handler to get and configure the device.
> > >
> > > ncsi_oem_gma_handler_bcm: This handler send NCSI broadcom command for
> > > getting mac address.
> > > ncsi_rsp_handler_oem_bcm: This handles response received for all
> > > broadcom OEM commands.
> > > ncsi_rsp_handler_oem_bcm_gma: This handles get mac address response and
> > > set it to device.
> > >
> > > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > > ---
> > > v4: updated as per comment from Sam, I was just wondering if I can remove
> > > NCSI_OEM_CMD_GET_MAC config option and let this code be valid always and
> > > it will configure mac address if there is get mac address handler for given
> > > manufacture id.
> >
> > Hi Vijay,
> >
> > We can look at handling this a different way, but I don't think we want
> > to unconditionally set the system's MAC address based on the OEM GMA
> > command. If the user wants to set a custom MAC address, or in the case of
> > OpenBMC for example who have their MAC address saved in flash, this will
> > override that value with whatever the Network Controller has saved. In
> > particular as it is set up it will override any MAC address every time a
> > channel is configured, such as during a failover event.
> >
> > We *could* always send the GMA command if it is available and move the
> > decision whether to use the resulting address or not into the response
> > handler. That would simplify the ncsi_configure_channel() logic a bit.
> > Another idea may be to have a Netlink command to tell NCSI to ignore the
> > GMA result; then we could drop the config option and the system can
> > safely change the address if desired.
> >
> > Any thoughts? I'll also ping some of the OpenBMC people and see what
> > their expectations are.
>
> After a bit of a think and an ask around, to quote a colleague:
> > I think we'd want it handled (overall) like any other net device; the MAC
> > address in the device's ROM provides a default, and is overridden by anything
> > specified by userspace
>
> Which describes what I was thinking pretty well.
> So if we can have it such that the NCSI driver only sets the MAC address
> _once_, and then after then does not update it again, we should be able to call
> the OEM GMA command without hiding it behind a config option. So the first time
> a channel was configured we store and set the MAC address given, but then on
> later configure events we don't continue to update it. What do you think?
>
> Cheers,
> Sam
>
> I agree with you setting it only once. I gave a thought about config option and realize that
> we should allow user to configure it. If user wants to set mac address through device tree
> and not through ROM then we must not override mac set by device tree. So my proposal is
> setting of mac address in response should be hidden under config option. Getting mac address
> can still go without config option. Your thought?
>
> or simply guard following block under config and no other function declaration guard required.
> And set static variable flag in function " ncsi_oem_handler" for calling this only once.
>
> #if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC)
> nca.type = NCSI_PKT_CMD_OEM;
> nca.package = np->id;
> nca.channel = nc->id;
> ndp->pending_req_num = 1;
> ret = ncsi_oem_handler(&nca, nc->version.mf_id);
> #endif /* CONFIG_NCSI_OEM_CMD_GET_MAC */
>
Hi Vijay,
Either way is likely fine; although you might need to take care you don't
get an unused function warning depending on how you guard
ncsi_oem_handler(). Also a flag in the ncsi_dev_priv struct could be
easier to keep track of than having a static variable in the handler
function.
Sam
^ permalink raw reply
* Re: [PATCH] qed: fix spelling mistake "Ireelevant" -> "Irrelevant"
From: David Miller @ 2018-10-16 5:40 UTC (permalink / raw)
To: colin.king
Cc: Ariel.Elior, everest-linux-l2, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20181013154825.6285-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 13 Oct 2018 16:48:25 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in DP_INFO message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH bpf-next 01/13] bpf: btf: Break up btf_type_is_void()
From: Daniel Borkmann @ 2018-10-15 21:50 UTC (permalink / raw)
To: Yonghong Song, ast, kafai, netdev; +Cc: kernel-team
In-Reply-To: <20181012185424.2378502-2-yhs@fb.com>
On 10/12/2018 08:54 PM, Yonghong Song wrote:
> This patch breaks up btf_type_is_void() into
> btf_type_is_void() and btf_type_is_fwd().
>
> It also adds btf_type_nosize() to better describe it is
> testing a type has nosize info.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
Yonghong, your SoB is missing here.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] octeontx2-af: remove unused cgx_fwi_link_change
From: David Miller @ 2018-10-16 5:32 UTC (permalink / raw)
To: arnd
Cc: sgoutham, lcherian, gakula, jerinj, yuehaibing, nmani, netdev,
linux-kernel
In-Reply-To: <20181012195232.4024123-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 12 Oct 2018 21:52:22 +0200
> The newly added driver causes a warning about a function that is
> not used anywhere:
>
> drivers/net/ethernet/marvell/octeontx2/af/cgx.c:320:12: error: 'cgx_fwi_link_change' defined but not used [-Werror=unused-function]
>
> Remove it for now, until a user gets added. If we want to use this
> function from another module, we also need a declaration in a header
> file, which is currently missing, so it would have to change anyway.
>
> Fixes: 1463f382f58d ("octeontx2-af: Add support for CGX link management")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ti: cpsw: use for mcast entries only host port
From: David Miller @ 2018-10-16 5:22 UTC (permalink / raw)
To: ivan.khoronzhuk; +Cc: grygorii.strashko, linux-omap, netdev, linux-kernel
In-Reply-To: <20181012160629.7245-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Fri, 12 Oct 2018 19:06:29 +0300
> In dual-emac mode the cpsw driver sends directed packets, that means
> that packets go to the directed port, but an ALE lookup is performed
> to determine untagged egress only. It means that on tx side no need
> to add port bit for ALE mcast entry mask, and basically ALE entry
> for port identification is needed only on rx side.
>
> So, add only host port in dual_emac mode as used directed
> transmission, and no need in one more port. For single port boards
> and switch mode all ports used, as usual, so no changes for them.
> Also it simplifies farther changes.
>
> In other words, mcast entries for dual-emac should behave exactly
> like unicast. It also can help avoid leaking packets between ports
> with same vlan on h/w level if ports could became members of same vid.
>
> So now, for instance, if mcast address 33:33:00:00:00:01 is added then
> entries in ALE table:
>
> vid = 1, addr = 33:33:00:00:00:01, port_mask = 0x1
> vid = 2, addr = 33:33:00:00:00:01, port_mask = 0x1
>
> Instead of:
> vid = 1, addr = 33:33:00:00:00:01, port_mask = 0x3
> vid = 2, addr = 33:33:00:00:00:01, port_mask = 0x5
>
> With the same considerations, set only host port for unregistered
> mcast for dual-emac mode in case of IFF_ALLMULTI is set, exactly like
> it's done in cpsw_ale_set_allmulti().
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] net: ethernet: ti: cpsw fix mcast packet lost
From: David Miller @ 2018-10-16 5:21 UTC (permalink / raw)
To: ivan.khoronzhuk; +Cc: grygorii.strashko, linux-omap, netdev, linux-kernel
In-Reply-To: <20181012152815.31320-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Fri, 12 Oct 2018 18:28:13 +0300
> The patchset omits redundant refresh of mcast address table and
> prevents mcast packet lost.
>
> Based on net-next/master
> tested on am572x evm
Series applied.
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix incorrect conditional on IPV6
From: David Miller @ 2018-10-16 5:20 UTC (permalink / raw)
To: dhowells; +Cc: netdev, kbuild-all, arnd, linux-afs, linux-kernel
In-Reply-To: <153935871685.8157.12127765977392104630.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Fri, 12 Oct 2018 16:38:36 +0100
> The udpv6_encap_enable() function is part of the ipv6 code, and if that is
> configured as a loadable module and rxrpc is built in then a build failure
> will occur because the conditional check is wrong:
>
> net/rxrpc/local_object.o: In function `rxrpc_lookup_local':
> local_object.c:(.text+0x2688): undefined reference to `udpv6_encap_enable'
>
> Use the correct config symbol (CONFIG_AF_RXRPC_IPV6) in the conditional
> check rather than CONFIG_IPV6 as that will do the right thing.
>
> Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
> Reported-by: kbuild-all@01.org
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: David Howells <dhowells@redhat.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix waring in af_unix
From: David Miller @ 2018-10-16 5:16 UTC (permalink / raw)
To: kyeongdon.kim
Cc: ktkhai, viro, garsilva, jbaron, dvlasenk, xiyou.wangcong, netdev,
linux-kernel
In-Reply-To: <1539340454-67970-1-git-send-email-kyeongdon.kim@lge.com>
From: Kyeongdon Kim <kyeongdon.kim@lge.com>
Date: Fri, 12 Oct 2018 19:34:14 +0900
> This fixes the "'hash' may be used uninitialized in this function"
>
> net/unix/af_unix.c:1041:20: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized]
> addr->hash = hash ^ sk->sk_type;
> ^
>
> Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com>
Please put the initialization at the start of unix_mkname() as a similar
situation exists elsewhere in this file, and the compiler will eventually
warn there too.
^ permalink raw reply
* Re: [PATCH net] net: bcmgenet: Poll internal PHY for GENETv5
From: David Miller @ 2018-10-16 5:11 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, opendmb, linux-kernel
In-Reply-To: <20181011220633.24450-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 11 Oct 2018 15:06:33 -0700
> On GENETv5, there is a hardware issue which prevents the GENET hardware
> from generating a link UP interrupt when the link is operating at
> 10Mbits/sec. Since we do not have any way to configure the link
> detection logic, fallback to polling in that case.
>
> Fixes: 421380856d9c ("net: bcmgenet: add support for the GENETv5 hardware")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix an uninitialised variable
From: David Miller @ 2018-10-16 5:09 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <153929355195.15518.16495330917691027211.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 11 Oct 2018 22:32:31 +0100
> Fix an uninitialised variable introduced by the last patch. This can cause
> a crash when a new call comes in to a local service, such as when an AFS
> fileserver calls back to the local cache manager.
>
> Fixes: c1e15b4944c9 ("rxrpc: Fix the packet reception routine")
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ethtool: fix a missing-check bug
From: David Miller @ 2018-10-16 4:39 UTC (permalink / raw)
To: wang6495
Cc: kjlu, f.fainelli, keescook, ilyal, ecree, ynorov, alan.brady,
eugenia, stephen, netdev, linux-kernel
In-Reply-To: <1539090940-5323-1-git-send-email-wang6495@umn.edu>
From: Wenwen Wang <wang6495@umn.edu>
Date: Tue, 9 Oct 2018 08:15:38 -0500
> In ethtool_get_rxnfc(), the eth command 'cmd' is compared against
> 'ETHTOOL_GRXFH' to see whether it is necessary to adjust the variable
> 'info_size'. Then the whole structure of 'info' is copied from the
> user-space buffer 'useraddr' with 'info_size' bytes. In the following
> execution, 'info' may be copied again from the buffer 'useraddr' depending
> on the 'cmd' and the 'info.flow_type'. However, after these two copies,
> there is no check between 'cmd' and 'info.cmd'. In fact, 'cmd' is also
> copied from the buffer 'useraddr' in dev_ethtool(), which is the caller
> function of ethtool_get_rxnfc(). Given that 'useraddr' is in the user
> space, a malicious user can race to change the eth command in the buffer
> between these copies. By doing so, the attacker can supply inconsistent
> data and cause undefined behavior because in the following execution 'info'
> will be passed to ops->get_rxnfc().
>
> This patch adds a necessary check on 'info.cmd' and 'cmd' to confirm that
> they are still same after the two copies in ethtool_get_rxnfc(). Otherwise,
> an error code EINVAL will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Applied.
^ permalink raw reply
* Re: [PATCH net] r8169: Enable MSI-X on RTL8106e
From: David Miller @ 2018-10-16 4:32 UTC (permalink / raw)
To: jian-hong
Cc: hkallweit1, nic_swsd, netdev, linux-kernel, kai.heng.feng, linux
In-Reply-To: <CAPpJ_ecr-tMNcpe=--MYyK3OWJiYEAoX7AnDBN63XO1OGZ4v_w@mail.gmail.com>
From: Jian-Hong Pan <jian-hong@endlessm.com>
Date: Mon, 15 Oct 2018 16:51:12 +0800
> 2018-10-02 13:57 GMT+08:00 Jian-Hong Pan <jian-hong@endlessm.com>:
>> David Miller <davem@davemloft.net> 於 2018年10月2日 週二 下午1:51寫道：
>>>
>>> From: Jian-Hong Pan <jian-hong@endlessm.com>
>>> Date: Thu, 27 Sep 2018 12:09:48 +0800
>>>
>>> > However, there is a commit which resolves the drivers getting nothing in
>>> > PCI BAR=4 after system resumes. It is 04cb3ae895d7 "PCI: Reprogram
>>> > bridge prefetch registers on resume" by Daniel Drake.
>>>
>>> I don't see this upstream yet.
>>
>> It is in linux-next repository:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=04cb3ae895d7efdc60f0fe17182b200a3da20f09
>
> The commit is also back ported into Linux kernel 4.19-rc7 now.
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=083874549fdfefa629dfa752785e20427dde1511
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next 0/2] IPv6 sk-lookup fixes
From: Daniel Borkmann @ 2018-10-15 20:39 UTC (permalink / raw)
To: Joe Stringer, ast; +Cc: netdev
In-Reply-To: <20181015172746.6475-1-joe@wand.net.nz>
On 10/15/2018 07:27 PM, Joe Stringer wrote:
> This series includes a couple of fixups for the IPv6 socket lookup
> helper, to make the API more consistent (always supply all arguments in
> network byte-order) and to allow its use when IPv6 is compiled as a
> module.
>
> Joe Stringer (2):
> bpf: Allow sk_lookup with IPv6 module
> bpf: Fix IPv6 dport byte-order in bpf_sk_lookup
>
> include/net/addrconf.h | 5 +++++
> net/core/filter.c | 15 +++++++++------
> net/ipv6/af_inet6.c | 1 +
> 3 files changed, 15 insertions(+), 6 deletions(-)
>
LGTM, thanks for following up on this. Series:
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 11/18] vxlan: Add netif_is_vxlan()
From: Stephen Hemminger @ 2018-10-15 20:33 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Ido Schimmel, Ido Schimmel, netdev
In-Reply-To: <20181015133041.6118aab1@cakuba.netronome.com>
On Mon, 15 Oct 2018 13:30:41 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Mon, 15 Oct 2018 23:27:41 +0300, Ido Schimmel wrote:
> > On Mon, Oct 15, 2018 at 01:16:42PM -0700, Stephen Hemminger wrote:
> > > On Mon, 15 Oct 2018 22:57:48 +0300
> > > Ido Schimmel <idosch@mellanox.com> wrote:
> > >
> > > > On Mon, Oct 15, 2018 at 11:57:56AM -0700, Jakub Kicinski wrote:
> > > > > On Sat, 13 Oct 2018 17:18:38 +0000, Ido Schimmel wrote:
> > > > > > Add the ability to determine whether a netdev is a VxLAN netdev by
> > > > > > calling the above mentioned function that checks the netdev's private
> > > > > > flags.
> > > > > >
> > > > > > This will allow modules to identify netdev events involving a VxLAN
> > > > > > netdev and act accordingly. For example, drivers capable of VxLAN
> > > > > > offload will need to configure the underlying device when a VxLAN netdev
> > > > > > is being enslaved to an offloaded bridge.
> > > > > >
> > > > > > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > > > > > Reviewed-by: Petr Machata <petrm@mellanox.com>
> > > > >
> > > > > Is this preferable over
> > > > >
> > > > > !strcmp(netdev->rtnl_link_ops->kind, "vxlan")
> > > > >
> > > > > which is what TC offloads do?
> > > >
> > > > Using a flag seemed like the more standard way.
> > > >
> > > > That being said, we considered using net_device_ops instead, given we
> > > > are about to run out of available private flags, so I don't mind
> > > > adopting a technique already employed by another driver.
> > > >
> > > > P.S. Had to Cc netdev again. I think your client somehow messed the Cc
> > > > list? I see Cc list in your reply, but with back slashes at the end of
> > > > two email addresses.
> > >
> > > Agree that using a global resource bit in flags is probably overkill.
> > > If you can use kind that would be good example for other drivers as well.
> >
> > OK, will change.
> >
> > Jakub, any objections if I implement netif_is_vxlan() using 'kind' and
> > convert nfp to use the helper? Having all these helpers in the same
> > location will increase the chances of others reusing them.
>
> Sounds very good :)
We could even do this for bridge, and other devices that are using private flags.
^ permalink raw reply
* Re: [PATCH net-next 11/18] vxlan: Add netif_is_vxlan()
From: Jakub Kicinski @ 2018-10-15 20:30 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Stephen Hemminger, Ido Schimmel, netdev
In-Reply-To: <20181015202741.GA27066@splinter>
On Mon, 15 Oct 2018 23:27:41 +0300, Ido Schimmel wrote:
> On Mon, Oct 15, 2018 at 01:16:42PM -0700, Stephen Hemminger wrote:
> > On Mon, 15 Oct 2018 22:57:48 +0300
> > Ido Schimmel <idosch@mellanox.com> wrote:
> >
> > > On Mon, Oct 15, 2018 at 11:57:56AM -0700, Jakub Kicinski wrote:
> > > > On Sat, 13 Oct 2018 17:18:38 +0000, Ido Schimmel wrote:
> > > > > Add the ability to determine whether a netdev is a VxLAN netdev by
> > > > > calling the above mentioned function that checks the netdev's private
> > > > > flags.
> > > > >
> > > > > This will allow modules to identify netdev events involving a VxLAN
> > > > > netdev and act accordingly. For example, drivers capable of VxLAN
> > > > > offload will need to configure the underlying device when a VxLAN netdev
> > > > > is being enslaved to an offloaded bridge.
> > > > >
> > > > > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > > > > Reviewed-by: Petr Machata <petrm@mellanox.com>
> > > >
> > > > Is this preferable over
> > > >
> > > > !strcmp(netdev->rtnl_link_ops->kind, "vxlan")
> > > >
> > > > which is what TC offloads do?
> > >
> > > Using a flag seemed like the more standard way.
> > >
> > > That being said, we considered using net_device_ops instead, given we
> > > are about to run out of available private flags, so I don't mind
> > > adopting a technique already employed by another driver.
> > >
> > > P.S. Had to Cc netdev again. I think your client somehow messed the Cc
> > > list? I see Cc list in your reply, but with back slashes at the end of
> > > two email addresses.
> >
> > Agree that using a global resource bit in flags is probably overkill.
> > If you can use kind that would be good example for other drivers as well.
>
> OK, will change.
>
> Jakub, any objections if I implement netif_is_vxlan() using 'kind' and
> convert nfp to use the helper? Having all these helpers in the same
> location will increase the chances of others reusing them.
Sounds very good :)
^ permalink raw reply
* Re: [PATCH net-next 11/18] vxlan: Add netif_is_vxlan()
From: Ido Schimmel @ 2018-10-15 20:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ido Schimmel, Jakub Kicinski, netdev
In-Reply-To: <20181015131642.4bd6e564@xeon-e3>
On Mon, Oct 15, 2018 at 01:16:42PM -0700, Stephen Hemminger wrote:
> On Mon, 15 Oct 2018 22:57:48 +0300
> Ido Schimmel <idosch@mellanox.com> wrote:
>
> > On Mon, Oct 15, 2018 at 11:57:56AM -0700, Jakub Kicinski wrote:
> > > On Sat, 13 Oct 2018 17:18:38 +0000, Ido Schimmel wrote:
> > > > Add the ability to determine whether a netdev is a VxLAN netdev by
> > > > calling the above mentioned function that checks the netdev's private
> > > > flags.
> > > >
> > > > This will allow modules to identify netdev events involving a VxLAN
> > > > netdev and act accordingly. For example, drivers capable of VxLAN
> > > > offload will need to configure the underlying device when a VxLAN netdev
> > > > is being enslaved to an offloaded bridge.
> > > >
> > > > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > > > Reviewed-by: Petr Machata <petrm@mellanox.com>
> > >
> > > Is this preferable over
> > >
> > > !strcmp(netdev->rtnl_link_ops->kind, "vxlan")
> > >
> > > which is what TC offloads do?
> >
> > Using a flag seemed like the more standard way.
> >
> > That being said, we considered using net_device_ops instead, given we
> > are about to run out of available private flags, so I don't mind
> > adopting a technique already employed by another driver.
> >
> > P.S. Had to Cc netdev again. I think your client somehow messed the Cc
> > list? I see Cc list in your reply, but with back slashes at the end of
> > two email addresses.
>
> Agree that using a global resource bit in flags is probably overkill.
> If you can use kind that would be good example for other drivers as well.
OK, will change.
Jakub, any objections if I implement netif_is_vxlan() using 'kind' and
convert nfp to use the helper? Having all these helpers in the same
location will increase the chances of others reusing them.
^ permalink raw reply
* [iproute PATCH] ip-addrlabel: Fix printing of label value
From: Phil Sutter @ 2018-10-15 20:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Passing the return value of RTA_DATA() to rta_getattr_u32() is wrong
since that function will call RTA_DATA() by itself already.
Fixes: a7ad1c8a6845d ("ipaddrlabel: add json support")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/ipaddrlabel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/ipaddrlabel.c b/ip/ipaddrlabel.c
index 2f79c56dcead2..8abe5722bafd1 100644
--- a/ip/ipaddrlabel.c
+++ b/ip/ipaddrlabel.c
@@ -95,7 +95,7 @@ int print_addrlabel(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg
}
if (tb[IFAL_LABEL] && RTA_PAYLOAD(tb[IFAL_LABEL]) == sizeof(uint32_t)) {
- uint32_t label = rta_getattr_u32(RTA_DATA(tb[IFAL_LABEL]));
+ uint32_t label = rta_getattr_u32(tb[IFAL_LABEL]);
print_uint(PRINT_ANY,
"label", "label %u ", label);
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net-next 11/18] vxlan: Add netif_is_vxlan()
From: Stephen Hemminger @ 2018-10-15 20:16 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Jakub Kicinski, netdev
In-Reply-To: <20181015195748.GA25940@splinter>
On Mon, 15 Oct 2018 22:57:48 +0300
Ido Schimmel <idosch@mellanox.com> wrote:
> On Mon, Oct 15, 2018 at 11:57:56AM -0700, Jakub Kicinski wrote:
> > On Sat, 13 Oct 2018 17:18:38 +0000, Ido Schimmel wrote:
> > > Add the ability to determine whether a netdev is a VxLAN netdev by
> > > calling the above mentioned function that checks the netdev's private
> > > flags.
> > >
> > > This will allow modules to identify netdev events involving a VxLAN
> > > netdev and act accordingly. For example, drivers capable of VxLAN
> > > offload will need to configure the underlying device when a VxLAN netdev
> > > is being enslaved to an offloaded bridge.
> > >
> > > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > > Reviewed-by: Petr Machata <petrm@mellanox.com>
> >
> > Is this preferable over
> >
> > !strcmp(netdev->rtnl_link_ops->kind, "vxlan")
> >
> > which is what TC offloads do?
>
> Using a flag seemed like the more standard way.
>
> That being said, we considered using net_device_ops instead, given we
> are about to run out of available private flags, so I don't mind
> adopting a technique already employed by another driver.
>
> P.S. Had to Cc netdev again. I think your client somehow messed the Cc
> list? I see Cc list in your reply, but with back slashes at the end of
> two email addresses.
Agree that using a global resource bit in flags is probably overkill.
If you can use kind that would be good example for other drivers as well.
^ permalink raw reply
* Re: [PATCH bpf-next] tools: bpftool: add map create command
From: Alexei Starovoitov @ 2018-10-15 19:58 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: daniel, netdev, oss-drivers
In-Reply-To: <20181015094908.2993a27b@cakuba.netronome.com>
On Mon, Oct 15, 2018 at 09:49:08AM -0700, Jakub Kicinski wrote:
> On Fri, 12 Oct 2018 23:16:59 -0700, Alexei Starovoitov wrote:
> > On Fri, Oct 12, 2018 at 11:06:14AM -0700, Jakub Kicinski wrote:
> > > Add a way of creating maps from user space. The command takes
> > > as parameters most of the attributes of the map creation system
> > > call command. After map is created its pinned to bpffs. This makes
> > > it possible to easily and dynamically (without rebuilding programs)
> > > test various corner cases related to map creation.
> > >
> > > Map type names are taken from bpftool's array used for printing.
> > > In general these days we try to make use of libbpf type names, but
> > > there are no map type names in libbpf as of today.
> > >
> > > As with most features I add the motivation is testing (offloads) :)
> > >
> > > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > > Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
> > ...
> > > fprintf(stderr,
> > > "Usage: %s %s { show | list } [MAP]\n"
> > > + " %s %s create FILE type TYPE key KEY_SIZE value VALUE_SIZE \\\n"
> > > + " entries MAX_ENTRIES [name NAME] [flags FLAGS] \\\n"
> > > + " [dev NAME]\n"
> >
> > I suspect as soon as bpftool has an ability to create standalone maps
> > some folks will start relying on such interface.
>
> That'd be cool, do you see any real life use cases where its useful
> outside of corner case testing?
In our XDP use case we have an odd protocol for different apps to share
common prog_array that is pinned in bpffs.
If cmdline creation of it via bpftool was available that would have been
an option to consider. Not saying that it would have been a better option.
Just another option.
>
> > Therefore I'd like to request to make 'name' argument to be mandatory.
>
> Will do in v2!
thx!
> > I think in the future we will require BTF to be mandatory too.
> > We need to move towards more transparent and debuggable infra.
> > Do you think requiring json description of key/value would be managable to implement?
> > Then bpftool could convert it to BTF and the map full be fully defined.
> > I certainly understand that bpf prog can disregard the key/value layout today,
> > but we will make verifier to enforce that in the future too.
>
> I was hoping that we can leave BTF support as a future extension, and
> then once we have the option for the verifier to enforce BTF (a sysctl?)
> the bpftool map create without a BTF will get rejected as one would
> expect.
right. something like sysctl in the future.
> IOW it's fine not to make BTF required at bpftool level and
> leave it to system configuration.
>
> I'd love to implement the BTF support right away, but I'm not sure I
> can afford that right now time-wise. The whole map create command is
> pretty trivial, but for BTF we don't even have a way of dumping it
> AFAICT. We can pretty print values, but what is the format in which to
> express the BTF itself? We could do JSON, do we use an external
> library? Should we have a separate BTF command for that?
I prefer standard C type description for both input and output :)
Anyway that wasn't a request for you to do it now. More of the feature
request for somebody to put on todo list :)
^ permalink raw reply
* Re: [PATCH net-next 11/18] vxlan: Add netif_is_vxlan()
From: Ido Schimmel @ 2018-10-15 19:57 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20181015115756.13b6c0da@cakuba.netronome.com>
On Mon, Oct 15, 2018 at 11:57:56AM -0700, Jakub Kicinski wrote:
> On Sat, 13 Oct 2018 17:18:38 +0000, Ido Schimmel wrote:
> > Add the ability to determine whether a netdev is a VxLAN netdev by
> > calling the above mentioned function that checks the netdev's private
> > flags.
> >
> > This will allow modules to identify netdev events involving a VxLAN
> > netdev and act accordingly. For example, drivers capable of VxLAN
> > offload will need to configure the underlying device when a VxLAN netdev
> > is being enslaved to an offloaded bridge.
> >
> > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > Reviewed-by: Petr Machata <petrm@mellanox.com>
>
> Is this preferable over
>
> !strcmp(netdev->rtnl_link_ops->kind, "vxlan")
>
> which is what TC offloads do?
Using a flag seemed like the more standard way.
That being said, we considered using net_device_ops instead, given we
are about to run out of available private flags, so I don't mind
adopting a technique already employed by another driver.
P.S. Had to Cc netdev again. I think your client somehow messed the Cc
list? I see Cc list in your reply, but with back slashes at the end of
two email addresses.
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/8] sockmap integration for ktls
From: Alexei Starovoitov @ 2018-10-15 19:27 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: john.fastabend, davejwatson, netdev
In-Reply-To: <20181013004603.3747-1-daniel@iogearbox.net>
On Sat, Oct 13, 2018 at 02:45:55AM +0200, Daniel Borkmann wrote:
> This work adds a generic sk_msg layer and converts both sockmap
> and later ktls over to make use of it as a common data structure
> for application data (similarly as sk_buff for network packets).
> With that in place the sk_msg framework spans accross ULP layer
> in the kernel and allows for introspection or filtering of L7
> data with the help of BPF programs operating on a common input
> context.
>
> In a second step, we enable the latter for ktls which was previously
> not possible, meaning, ktls and sk_msg verdict programs were
> mutually exclusive in the ULP layer which created challenges for
> the orchestrator when trying to apply TCP based policy, for
> example. Leveraging the prior consolidation we can finally overcome
> this limitation.
>
> Note, there's no change in behavior when ktls is not used in
> combination with BPF, and also no change in behavior for stand
> alone sockmap. The kselftest suites for ktls, sockmap and ktls
> with sockmap combined also runs through successfully. For further
> details please see individual patches.
>
> Thanks!
>
> v1 -> v2:
> - Removed leftover comment spotted by Alexei
> - Improved commit messages, rebase
Applied, Thanks
^ permalink raw reply
* [PATCH net-next] net: phy: merge phy_start_aneg and phy_start_aneg_priv
From: Heiner Kallweit @ 2018-10-15 19:25 UTC (permalink / raw)
To: David Miller, Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org
After commit 9f2959b6b52d ("net: phy: improve handling delayed work")
the sync parameter isn't needed any longer in phy_start_aneg_priv().
This allows to merge phy_start_aneg() and phy_start_aneg_priv().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy.c | 21 +++------------------
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d03bdbbd1..1d73ac330 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -482,16 +482,15 @@ static int phy_config_aneg(struct phy_device *phydev)
}
/**
- * phy_start_aneg_priv - start auto-negotiation for this PHY device
+ * phy_start_aneg - start auto-negotiation for this PHY device
* @phydev: the phy_device struct
- * @sync: indicate whether we should wait for the workqueue cancelation
*
* Description: Sanitizes the settings (if we're not autonegotiating
* them), and then calls the driver's config_aneg function.
* If the PHYCONTROL Layer is operating, we change the state to
* reflect the beginning of Auto-negotiation or forcing.
*/
-static int phy_start_aneg_priv(struct phy_device *phydev, bool sync)
+int phy_start_aneg(struct phy_device *phydev)
{
bool trigger = 0;
int err;
@@ -541,20 +540,6 @@ static int phy_start_aneg_priv(struct phy_device *phydev, bool sync)
return err;
}
-
-/**
- * phy_start_aneg - start auto-negotiation for this PHY device
- * @phydev: the phy_device struct
- *
- * Description: Sanitizes the settings (if we're not autonegotiating
- * them), and then calls the driver's config_aneg function.
- * If the PHYCONTROL Layer is operating, we change the state to
- * reflect the beginning of Auto-negotiation or forcing.
- */
-int phy_start_aneg(struct phy_device *phydev)
-{
- return phy_start_aneg_priv(phydev, true);
-}
EXPORT_SYMBOL(phy_start_aneg);
static int phy_poll_aneg_done(struct phy_device *phydev)
@@ -1085,7 +1070,7 @@ void phy_state_machine(struct work_struct *work)
mutex_unlock(&phydev->lock);
if (needs_aneg)
- err = phy_start_aneg_priv(phydev, false);
+ err = phy_start_aneg(phydev);
else if (do_suspend)
phy_suspend(phydev);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net] net/sched: properly init chain in case of multiple control actions
From: Cong Wang @ 2018-10-15 18:31 UTC (permalink / raw)
To: Davide Caratti
Cc: Jiri Pirko, Jamal Hadi Salim, David Miller,
Linux Kernel Network Developers
In-Reply-To: <dbb93ac2c87c14d412a18f35701890dcc87d0cdb.camel@redhat.com>
On Sat, Oct 13, 2018 at 8:23 AM Davide Caratti <dcaratti@redhat.com> wrote:
>
> On Fri, 2018-10-12 at 13:57 -0700, Cong Wang wrote:
> > Why not just validate the fallback action in each action init()?
> > For example, checking tcfg_paction in tcf_gact_init().
> >
> > I don't see the need of making it generic.
>
> hello Cong, once again thanks for looking at this.
>
> what you say is doable, and I evaluated doing it before proposing this
> patch.
>
> But I felt unconfortable, because I needed to pass struct tcf_proto *tp in
> tcf_gact_init() to initialize a->goto_chain with the chain_idx encoded in
> the fallback action. So, I would have changed all the init() functions in
> all TC actions, just to fix two of them.
>
> A (legal?) trick is to let tcf_action store the fallback action when it
> contains a 'goto chain' command, I just posted a proposal for gact. If you
> think it's ok, I will test and post the same for act_police.
Do we really need to support TC_ACT_GOTO_CHAIN for
gact->tcfg_paction etc.? I mean, is it useful in practice or is it just for
completeness?
IF we don't need to support it, we can just make it invalid without needing
to initialize it in ->init() at all.
If we do, however, we really need to move it into each ->init(), because
we have to lock each action if we are modifying an existing one. With
your patch, tcf_action_goto_chain_init() is still called without the per-action
lock.
What's more, if we support two different actions in gact, that is, tcfg_paction
and tcf_action, how could you still only have one a->goto_chain pointer?
There should be two pointers for each of them. :)
Thanks.
^ 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