* Re: [PATCH net-next 2/2] tuntap: XDP transmission
From: kbuild test robot @ 2018-01-01 8:27 UTC (permalink / raw)
To: Jason Wang
Cc: kbuild-all, netdev, linux-kernel, mst, jbrouer, Jason Wang,
Jesper Dangaard Brouer
In-Reply-To: <1514541604-12728-3-git-send-email-jasowang@redhat.com>
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-Wang/XDP-transmission-for-tuntap/20180101-105946
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
vim +1274 drivers/net/tun.c
1270
1271 static void tun_xdp_flush(struct net_device *dev)
1272 {
1273 struct tun_struct *tun = netdev_priv(dev);
> 1274 struct tun_file *tfile = tun->tfiles[0];
1275
1276 /* Notify and wake up reader process */
1277 if (tfile->flags & TUN_FASYNC)
1278 kill_fasync(&tfile->fasync, SIGIO, POLL_IN);
1279 tfile->socket.sk->sk_data_ready(tfile->socket.sk);
1280 }
1281
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [net-next: PATCH v2 4/5] net: mvpp2: use device_*/fwnode_* APIs instead of of_*
From: Marcin Wojtas @ 2018-01-01 10:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-kernel, linux-arm-kernel, netdev, linux-acpi,
Graeme Gregory, David S. Miller, Russell King - ARM Linux,
Rafael J. Wysocki, Florian Fainelli, Antoine Ténart,
Thomas Petazzoni, Gregory Clément, Ezequiel Garcia, nadavh,
Neta Zur Hershkovits, Ard Biesheuvel, Grzegorz Jaszczyk,
Tomasz Nowicki
In-Reply-To: <20171231191836.GA20455@lunn.ch>
Hi Andrew,
2017-12-31 20:18 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> On Sun, Dec 31, 2017 at 12:58:39PM +0100, Marcin Wojtas wrote:
> Hi Marcin
>
>> Because there is no equivalent for for_each_available_child_of_node(),
>> use device_for_each_child_node() and check the port availability
>> inside the mvpp2_port_probe() routine.
>
> Could device_each_available_child_node() be added? I guess this will
> not be the last driver converted in this way, and having that macro
> will help with future ports.
>
Sure, I can add it in the next round.
Thanks,
Marcin
^ permalink raw reply
* Re: [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver
From: Marcin Wojtas @ 2018-01-01 10:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-kernel, linux-arm-kernel, netdev, linux-acpi,
Graeme Gregory, David S. Miller, Russell King - ARM Linux,
Rafael J. Wysocki, Florian Fainelli, Antoine Ténart,
Thomas Petazzoni, Gregory Clément, Ezequiel Garcia, nadavh,
Neta Zur Hershkovits, Ard Biesheuvel, Grzegorz Jaszczyk,
Tomasz Nowicki
In-Reply-To: <20171231192354.GB20455@lunn.ch>
HI Andrew,
2017-12-31 20:23 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> * Modify way of obtaining interrupts - with ACPI they are resources
>> bound to struct platform_device and it's not possible to obtain
>> them directly from the child node. Hence a formula is used, depending
>> on the port_id and number of possible CPUs.
>
> Hi Marcin
>
> I know nothing about ACPI. Is this limitation with respect to
> interrupts fundamental to ACPI, or just that nobody has implemented
> flexible interrupt support yet?
I think it's a limitation, however it would be great, if some real
ACPI expert was able to give an opinion here. I'd really prefer to
declare IRQ's in the child nodes, but it seems not possible.
>
>> * Until proper MDIO bus and PHY handling with ACPI is established in the
>> kernel, use only link interrupts feature in the driver.
>
> I think interrupts might be interesting with PHY devices, since they
> are child nodes of the MDIO device....
>
Apart from the phylink's SFP support that may require in-band
management, it's an alternative to the normal PHY handling. Once MDIO
bus + PHYs are supported for ACPI, phylib support will be used instead
of the IRQs, so there should be no problem here.
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Marcin Wojtas @ 2018-01-01 10:18 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stefan Chulski, Thomas Petazzoni, Andrew Lunn, Florian Fainelli,
Yan Markman, Jason Cooper, netdev, Antoine Tenart, linux-kernel,
kishon, nadavh, Miquèl Raynal, Gregory Clément,
David S. Miller, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20171230173157.GC10595@n2100.armlinux.org.uk>
Hi Russell,
2017-12-30 18:31 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> Hi Marcin,
>
> On Sat, Dec 30, 2017 at 05:34:23PM +0100, Marcin Wojtas wrote:
>> Yes, I already split the series and will send first one right away. I
>> will be followed by MDIO bus / PHY handling proposal, including the
>> bits related to phylink. I'm looking forward to your opinion on that
>> once sent.
>
> I'm looking forward to the patches. :)
>
>> This my understanding of how the PP2 HW works in terms of signalling
>> the link interrupt:
>>
>> The full in-band management, similar to mvneta is supported only in
>> the SGMII mode (1G, not sure how it looks like in 2.5G mode). Such
>> handling is not yet implemented in the mvpp2.c
>>
>> 10G:
>> The XGMII MAC (XLG) is capable of generating link status change
>> interrupt upon information provided from the reconciliation layer (RS)
>> of the interface.
>>
>> 2.5G/1G SGMII:
>> Apart from the in-band management, the MAC is also capable of
>> generating IRQ during link-status change.
>>
>> 1G RGMII:
>> I was a bit surprised, but checked on my own - the link change IRQ can
>> be generated here as well.
>>
>> In addition to above the clause 22 PHYs can be automatically polled
>> via SMI bus and provide complete information about link status, speed,
>> etc., reflecting it directly in GMAC status registers. However, this
>> feature had to be disabled, in order not to conflict with SW PHY
>> management of the phylib.
>>
>> Stefan, is above correct?
>
> This sounds very much like mvneta's 'managed = "in-band"' mode.
Indeed. RGMII MAC behaves same way, although it shouldn't be named as
'in-band' to be on par with the specifications. Anyway - this one is
rather a stub for being able to work with ACPI, so once the MDIO bus
works there, this will be out of any concerns.
>
> Having done some research earlier this month on the "2.5G SGMII" I have
> a number of comments about this:
>
> 1. Beware of "SGMII" being used as a generic term for single lane serdes
> based ethernet. Marvell seem to use this for 802.3z BASE-X in their
> code, but it is not. SGMII is a modification of 802.3z BASE-X by
> Cisco. This leads to some confusion!
>
> 2. For Cisco SGMII running at 2.5G, PHYs such as those from Xilinx do not
> support the speed bits, because the speed is defined to be 2.5G. IOW,
> they do not support 250Mbps or 25Mbps speeds by data replication as is
> done with 100Mbps and 10Mbps over 1G SGMII.
>
> 3. There is also 1000BASE-X upclocked to 2.5G speeds, which mvneta and
> mvpp2 both support by appropriate configuration of the comphy. I've
> already tested this with 4.3Mbps Fiberchannel SFPs between clearfog
> and mcbin - but needing devmem2 to reconfigure the clearfog comphy.
As for 3. I tested 2.5G link on Clearfog (FreeBSD) and Armada 8040
(UEFI), so yes - the comphy is a crucial component here.
>
>> > If my guessing is correct, I have to wonder why mvpp2 invented a
>> > different way to represent this from mvneta? This makes it much more
>> > difficult to convert mvpp2 to phylink, and it also makes it difficult
>> > to add SFP support ignoring the phylink issue (since there is no phy
>> > handle there either.)
>>
>> Doesn't SFP require the fwnode handle to the sfp node? This is what I
>> understand at least from the phylink_register_sfp.
>
> Yes, internally within phylink. What I'm concerned about is the
> following disparity between mvneta and mvpp2 - I'll try to explain it
> more clearly with DT examples:
>
> 1.1. mvneta phy
> ð {
> phy = <&phy>;
> phy-mode = "whatever";
> };
> 1.2. mvneta fixed-link
> ð {
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> 1.3. mvneta in-band
> ð {
> phy-mode = "sgmii";
> managed = "in-band-status";
> };
> 2.1. mvpp2 phy
> ð {
> phy = <&phy>;
> phy-mode = "whatever";
> };
> 2.2. mvpp2 fixed-link
> ð {
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> 2.3. mvpp2 in-band (guess)
> ð {
> phy-mode = "sgmii";
> };
>
> In both cases, the representation for phy and fixed-link mode are the
> same, but the in-band are different. In mvneta in-band, the generic
> "managed" property must be specified as specified by
> Documentation/devicetree/bindings/net/ethernet.txt. However, for mvpp2,
> this mode is currently selected by omission of both a "phy" property and
> a "fixed-link" sub-node/property - and that goes against the description
> of the "managed" property in the ethernet.txt binding doc.
>
> Phylink won't recognise the mvpp2's style of "in-band" because phylink,
> being a piece of generic code, is written to follow the generic binding
> documentation, rather than accomodating driver's individual quirks.
>
> So, if what I think is correct (basically what I've said above) there is
> a problem converting mvpp2 to use phylink - any existing DT files that
> use the "2.3 mvpp2 in-band" method instantly break, and I think that's
> what Antoine referred to when I picked out that the previous patches
> avoided using phylink when there was no "phy" node present.
>
> However, I haven't spotted anything using the 2.3 method, but it's not
> that easy to find the lack of a property amongst the maze of .dts*
> files - trying to track down which use mvpp2 and which do not specify
> a phy or fixed-link node can't be done by grep alone due to the
> includes etc. I think the only possible way would be to build all DT
> files, then reverse them back to dts and search those for the mvpp2
> compatible strings, and then manually check each one.
>
Thanks for detailed explanation. I agree with you - for the link IRQ,
the 'managed' property should be used. IMO this change should be a
part of mvpp2 -> phylink conversion patchset.
Best regards,
Marcin
>> Anyway, once the phylink is introduced in mvpp2.c, its presence will
>> simply be detected by port->phylink pointer. In such case the link IRQ
>> will no be used. In longer perspective, link IRQ should be used only
>> by ACPI and once MDIO bus is supported in generic way in this world,
>> it could remain as the 'last resort' option.
>
> It's not though - there are SFP modules that are SGMII and we have no
> access to the PHY onboard, so the only way we know what they're doing
> is from the inband status sent as part of the SGMII in-band
> configuration. So, even when using phylink, we need the in-band
> stuff to work, and so we need those link IRQs.
>
> There's also additional complexities around Cisco SGMII and "extended"
> SGMII concerning the flow control settings - in Cisco SGMII, there
> are no bits in the 16-bit control word for communicating the flow
> control to the MAC. In extended SGMII (which appears in some Marvell
> devices) you can configure flow control to appear in the 16-bit
> control word, and in some cases, also EEE. When implemented correctly
> by the MAC, phylink supports the "Cisco" method when it knows that
> in-band AN is being used along with a PHY - it knows to read the
> settings from the MAC but combine the flow control with what has been
> read from the PHY. If this is not done, we're likely to end up with
> the link partner believing that FC is supported (eg, because the PHY
> has defaulted to advertising FC) but the local MAC having FC disabled.
>
> Note that there's another quirk as far as SGMII goes - some PHYs will
> not pass data until their "negotiation" (iow, passing and acknowledgement
> of the SGMII control word by the MAC) has completed. Disabling SGMII
> "AN" on the MAC causes some SGMII PHYs to apparently be in "link up"
> state but with no traffic flow possible in either direction. This is
> a particularly important point if using phylib - the temptation is to
> use phylib to pass the results of AN to the MAC for SGMII and disable
> AN on the MAC, but this is, in fact, wrong for the reason set out in
> this paragraph.
>
> There are bits present that allow AN bypass if it doesn't complete in
> a certain time, but that's an entirely separate issue - especially
> when there's SGMII PHYs that we have no access to!
>
> Sorting out these nuances over the life of phylink so far has been
> "interesting".
>
There's ton of quirks here and there, thanks for the efforts, which
help to sort them out.
Marcin
^ permalink raw reply
* [PATCH net] tipc: fix missing rtnl lock protection during setting link properties
From: Ying Xue @ 2018-01-01 10:24 UTC (permalink / raw)
To: netdev; +Cc: tipc-discussion, syzkaller-bugs, davem
Currently when user changes link properties, TIPC first checks if
user's command message contains media name or bearer name through
tipc_media_find() or tipc_bearer_find() which is protected by rtnl
lock. But when tipc_nl_compat_link_set() conducts the checking with
the two functions, it doesn't hold rtnl lock at all, as a result,
the following complaints were reported:
audit: type=1400 audit(1514679888.244:9): avc: denied { write } for
pid=3194 comm="syzkaller021477" path="socket:[11143]" dev="sockfs"
ino=11143 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tclass=netlink_generic_socket permissive=1
=============================
WARNING: suspicious RCU usage
4.15.0-rc5+ #152 Not tainted
-----------------------------
net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syzkaller021477/3194:
#0: (cb_lock){++++}, at: [<00000000d20133ea>] genl_rcv+0x19/0x40
net/netlink/genetlink.c:634
#1: (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_lock
net/netlink/genetlink.c:33 [inline]
#1: (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_rcv_msg+0x115/0x140
net/netlink/genetlink.c:622
stack backtrace:
CPU: 1 PID: 3194 Comm: syzkaller021477 Not tainted 4.15.0-rc5+ #152
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
__tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
tipc_nl_compat_doit+0x15b/0x660 net/tipc/netlink_compat.c:335
tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
tipc_nl_compat_recv+0x112f/0x18f0 net/tipc/netlink_compat.c:1201
genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
sock_sendmsg_nosec net/socket.c:636 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:646
sock_write_iter+0x31a/0x5d0 net/socket.c:915
call_write_iter include/linux/fs.h:1772 [inline]
new_sync_write fs/read_write.c:469 [inline]
__vfs_write+0x684/0x970 fs/read_write.c:482
vfs_write+0x189/0x510 fs/read_write.c:544
SYSC_write fs/read_write.c:589 [inline]
SyS_write+0xef/0x220 fs/read_write.c:581
do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reported-by: syzbot <syzbot+6345fd433db009b29413@syzkaller.appspotmail.com>
---
net/tipc/netlink_compat.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
index e48f0b2..0fb12a4 100644
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -720,17 +720,21 @@ static int tipc_nl_compat_link_set(struct tipc_nl_compat_cmd_doit *cmd,
lc = (struct tipc_link_config *)TLV_DATA(msg->req);
+ rtnl_lock();
media = tipc_media_find(lc->name);
if (media) {
cmd->doit = &tipc_nl_media_set;
+ rtnl_unlock();
return tipc_nl_compat_media_set(skb, msg);
}
bearer = tipc_bearer_find(msg->net, lc->name);
if (bearer) {
cmd->doit = &tipc_nl_bearer_set;
+ rtnl_unlock();
return tipc_nl_compat_bearer_set(skb, msg);
}
+ rtnl_unlock();
return __tipc_nl_compat_link_set(skb, msg);
}
--
2.7.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* RE: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Stefan Chulski @ 2018-01-01 10:35 UTC (permalink / raw)
To: Marcin Wojtas, Russell King - ARM Linux
Cc: Thomas Petazzoni, Andrew Lunn, Florian Fainelli, Yan Markman,
Jason Cooper, netdev, Antoine Tenart,
linux-kernel@vger.kernel.org, kishon@ti.com, Nadav Haklai,
Miquèl Raynal, Gregory Clément, David S. Miller,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <CAPv3WKfn0=51CVtC8V5nWeiM+UV0BhqwFNewwRWUV3wy-9MtUg@mail.gmail.com>
> -----Original Message-----
> From: Marcin Wojtas [mailto:mw@semihalf.com]
> Sent: Monday, January 01, 2018 12:18 PM
> To: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Stefan Chulski <stefanc@marvell.com>; Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>; Andrew Lunn <andrew@lunn.ch>;
> Florian Fainelli <f.fainelli@gmail.com>; Yan Markman
> <ymarkman@marvell.com>; Jason Cooper <jason@lakedaemon.net>; netdev
> <netdev@vger.kernel.org>; Antoine Tenart <antoine.tenart@free-
> electrons.com>; linux-kernel@vger.kernel.org; kishon@ti.com; Nadav Haklai
> <nadavh@marvell.com>; Miquèl Raynal <miquel.raynal@free-electrons.com>;
> Gregory Clément <gregory.clement@free-electrons.com>; David S. Miller
> <davem@davemloft.net>; linux-arm-kernel@lists.infradead.org; Sebastian
> Hesselbarth <sebastian.hesselbarth@gmail.com>
> Subject: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the
> fourth network interface
>
> External Email
>
> ----------------------------------------------------------------------
> Hi Russell,
>
> 2017-12-30 18:31 GMT+01:00 Russell King - ARM Linux
> <linux@armlinux.org.uk>:
> > Hi Marcin,
> >
> > On Sat, Dec 30, 2017 at 05:34:23PM +0100, Marcin Wojtas wrote:
> >> Yes, I already split the series and will send first one right away. I
> >> will be followed by MDIO bus / PHY handling proposal, including the
> >> bits related to phylink. I'm looking forward to your opinion on that
> >> once sent.
> >
> > I'm looking forward to the patches. :)
> >
> >> This my understanding of how the PP2 HW works in terms of signalling
> >> the link interrupt:
> >>
> >> The full in-band management, similar to mvneta is supported only in
> >> the SGMII mode (1G, not sure how it looks like in 2.5G mode). Such
> >> handling is not yet implemented in the mvpp2.c
> >>
> >> 10G:
> >> The XGMII MAC (XLG) is capable of generating link status change
> >> interrupt upon information provided from the reconciliation layer
> >> (RS) of the interface.
> >>
> >> 2.5G/1G SGMII:
> >> Apart from the in-band management, the MAC is also capable of
> >> generating IRQ during link-status change.
> >>
> >> 1G RGMII:
> >> I was a bit surprised, but checked on my own - the link change IRQ
> >> can be generated here as well.
> >>
> >> In addition to above the clause 22 PHYs can be automatically polled
> >> via SMI bus and provide complete information about link status,
> >> speed, etc., reflecting it directly in GMAC status registers.
> >> However, this feature had to be disabled, in order not to conflict
> >> with SW PHY management of the phylib.
> >>
> >> Stefan, is above correct?
> >
> > This sounds very much like mvneta's 'managed = "in-band"' mode.
>
> Indeed. RGMII MAC behaves same way, although it shouldn't be named as 'in-
> band' to be on par with the specifications. Anyway - this one is rather a stub for
> being able to work with ACPI, so once the MDIO bus works there, this will be
> out of any concerns.
Hi Marcin,
This is correct.
"in-band" supported only for SGMII mode.
IRQ link interrupt depend on "in-band"' auto negation only if "in-band"' enabled.
But IRQ link interrupt could be triggered with "in-band", "out-band" or with specific fixed speed/duplex/flow_contol.
Best Regards.
^ permalink raw reply
* RE: [PATCH] qed: Use zeroing memory allocator than allocator/memset
From: Tayar, Tomer @ 2018-01-01 12:07 UTC (permalink / raw)
To: Himanshu Jha, Elior, Ariel
Cc: Dept-Eng Everest Linux L2, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, mcgrof@kernel.org
In-Reply-To: <1514648224-6820-1-git-send-email-himanshujha199640@gmail.com>
From: Himanshu Jha [mailto:himanshujha199640@gmail.com]
Sent: Saturday, December 30, 2017 5:37 PM
> Use dma_zalloc_coherent and vzalloc for allocating zeroed
> memory and remove unnecessary memset function.
>
> Done using Coccinelle.
> Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
> 0-day tested with no failures.
>
> Suggested-by: Luis R. Rodriguez <mcgrof@kernel.org>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Thanks
Acked-by: Tomer Tayar <Tomer.Tayar@cavium.com>
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: Arkadi Sharshevsky @ 2018-01-01 12:23 UTC (permalink / raw)
To: David Ahern, Yuval Mintz, Roopa Prabhu, Jiri Pirko
Cc: netdev@vger.kernel.org, David Miller, mlxsw, Andrew Lunn,
Vivien Didelot, Florian Fainelli, Michael Chan,
ganeshgr@chelsio.com, Saeed Mahameed, Matan Barak,
Leon Romanovsky, Ido Schimmel, jakub.kicinski@netronome.com,
ast@kernel.org, Daniel Borkmann, Simon Horman,
pieter.jansenvanvuuren@netronome.com, "john.hurley@netronome
In-Reply-To: <46bb1c77-9a0c-6a4b-2ea9-8cacfbe7eef6@cumulusnetworks.com>
On 12/31/2017 05:46 PM, David Ahern wrote:
> On 12/31/17 3:52 AM, Arkadi Sharshevsky wrote:
>>> [1] This is allowed by the current patch set and perhaps it should not be:
>>>
>>> $ ip ro ls vrf vrf1101
>>> unreachable default metric 8192
>>> 11.2.51.0/24 dev swp1s0.51 proto kernel scope link src 11.2.51.1 offload
>>> 11.3.51.0/24 dev swp1s1.51 proto kernel scope link src 11.3.51.1 offload
>>> 11.4.51.0/24 dev swp1s2.51 proto kernel scope link src 11.4.51.1 offload
>>> 11.5.51.0/24 dev swp1s3.51 proto kernel scope link src 11.5.51.1 offload
>>> 11.6.51.0/24 dev swp3s0.51 proto kernel scope link src 11.6.51.1 offload
>>> 11.7.51.0/24 dev swp3s1.51 proto kernel scope link src 11.7.51.1 offload
>>> 11.8.51.0/24 dev swp3s2.51 proto kernel scope link src 11.8.51.1 offload
>>> 11.9.51.0/24 dev swp3s3.51 proto kernel scope link src 11.9.51.1 offload
>>>
>>> $ devlink resource set pci/0000:03:00.0 path /kvd/linear size 0
>>
>> This line actually did nothing, because size zero is not acceptable
>> see patch 6. This is pure userpsace problem that error is not shown.
>
> Then perhaps you have a kernel side bug. After the reload I get this:
>
> $ devlink resource show pci/0000:03:00.0
> pci/0000:03:00.0:
> name kvd size 245760 size_valid true
> resources:
> name linear size 0 occ 0
> name hash_double size 60416
> name hash_single size 87040
>
Actually no bug here, the linear can be zero. This implies no nexthop
routes. The adj table uses it as you can see.
>
>>
>> You can verify it by dumping the resources and see that there is no
>> pending change (only size and not size_new).
>>
>>> $ devlink reload pci/0000:03:00.0
>>> $ ip ro ls vrf vrf1101
>>> unreachable default metric 8192
>>>
>>
>> So you just performed full reload of the driver which includes
>> unregistration of all the netdevs and full init. KVD update requires
>> full teardown of the driver.
>
> you are right, I forgot to do a networking reload. Because of the above
> (0 was actually taken) all kinds of errors are spewed on 'ifreload -av'
> and there is no change to the ro ls:
>
> $ ip ro ls vrf vrf1101
> unreachable default metric 8192
>
>>
>> The system will not get back to the same state after reloading,
>> It's should be done on init. But it doesn't have to be like this
>> this, each driver provides his own reload devlink op implementation
>> so in our case full blown reset is required.
>>
>>
>>> [2] Same exact result for setting hash_double to 0:
>>> $ ip ro ls vrf vrf1101
>>> unreachable default metric 8192
>>> 11.2.51.0/24 dev swp1s0.51 proto kernel scope link src 11.2.51.1 offload
>>> 11.3.51.0/24 dev swp1s1.51 proto kernel scope link src 11.3.51.1 offload
>>> 11.4.51.0/24 dev swp1s2.51 proto kernel scope link src 11.4.51.1 offload
>>> 11.5.51.0/24 dev swp1s3.51 proto kernel scope link src 11.5.51.1 offload
>>> 11.6.51.0/24 dev swp3s0.51 proto kernel scope link src 11.6.51.1 offload
>>> 11.7.51.0/24 dev swp3s1.51 proto kernel scope link src 11.7.51.1 offload
>>> 11.8.51.0/24 dev swp3s2.51 proto kernel scope link src 11.8.51.1 offload
>>> 11.9.51.0/24 dev swp3s3.51 proto kernel scope link src 11.9.51.1 offload
>>>
>>> $ devlink resource set pci/0000:03:00.0 path /kvd/hash_double size 0
>
> On this command you are correct, 0 is not taken:
> $ devlink resource set pci/0000:03:00.0 path /kvd/hash_double size 0
> $ devlink resource show pci/0000:03:00.0
> pci/0000:03:00.0:
> name kvd size 245760 size_valid true
> resources:
> name linear size 0 occ 0
> name hash_double size 60416
> name hash_single size 87040
>
> but the 'set' command did not fail with a proper extack based error
> message, so consider this another a bug report.
>
Yeah, this is a bug, but a userspace one. I actually sniffed the nl
messages with nlmon and saw the extended ack packet with the required
string.
^ permalink raw reply
* [PATCH RESEND] bpf: fix bad include in libbpf when srctree is set
From: Alexander Alemayhu @ 2018-01-01 12:36 UTC (permalink / raw)
To: netdev; +Cc: alexei.starovoitov, daniel, Alexander Alemayhu
The relative path can be wrong and prevents the build.
Makefile:57: ../../scripts/Makefile.include: No such file or directory
make: *** No rule to make target '../../scripts/Makefile.include'. Stop.
Signed-off-by: Alexander Alemayhu <alexander@alemayhu.com>
---
tools/lib/bpf/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 4555304dc18e..0068829a56db 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -54,7 +54,7 @@ man_dir_SQ = '$(subst ','\'',$(man_dir))'
export man_dir man_dir_SQ INSTALL
export DESTDIR DESTDIR_SQ
-include ../../scripts/Makefile.include
+include $(srctree)/tools/scripts/Makefile.include
# copy a bit from Linux kbuild
--
2.13.6
^ permalink raw reply related
* Re: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2018-01-01 13:25 UTC (permalink / raw)
To: Stefan Chulski
Cc: Thomas Petazzoni, Andrew Lunn, Florian Fainelli, Yan Markman,
Jason Cooper, netdev, Antoine Tenart,
linux-kernel@vger.kernel.org, kishon@ti.com, Nadav Haklai,
Miquèl Raynal, Gregory Clément, Marcin Wojtas,
David S. Miller, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <616c2f3b0fe64184bc26d2de43442540@IL-EXCH01.marvell.com>
On Mon, Jan 01, 2018 at 10:35:25AM +0000, Stefan Chulski wrote:
>
> > -----Original Message-----
> > Hi Russell,
> >
> > Indeed. RGMII MAC behaves same way, although it shouldn't be named as 'in-
> > band' to be on par with the specifications. Anyway - this one is rather a stub for
> > being able to work with ACPI, so once the MDIO bus works there, this will be
> > out of any concerns.
>
> Hi Marcin,
>
> This is correct.
> "in-band" supported only for SGMII mode.
> IRQ link interrupt depend on "in-band"' auto negation only if "in-band"' enabled.
> But IRQ link interrupt could be triggered with "in-band", "out-band" or with specific fixed speed/duplex/flow_contol.
Hi Stefan,
How does this work in RGMII mode - is this handled by the PP2 polling
the PHY to get the speed, duplex and flow control settings?
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: Arkadi Sharshevsky @ 2018-01-01 14:58 UTC (permalink / raw)
To: Jiri Pirko, netdev, dsa, roopa
Cc: davem, mlxsw, andrew, vivien.didelot, f.fainelli, michael.chan,
ganeshgr, saeedm, matanb, leonro, idosch, jakub.kicinski, ast,
daniel, simon.horman, pieter.jansenvanvuuren, john.hurley,
alexander.h.duyck, linville, gospo, steven.lin1, yuvalm, ogerlitz
In-Reply-To: <20171226112359.5313-1-jiri@resnulli.us>
On 12/26/2017 01:23 PM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Many of the ASIC's internal resources are limited and are shared between
> several hardware procedures. For example, unified hash-based memory can
> be used for many lookup purposes, like FDB and LPM. In many cases the user
> can provide a partitioning scheme for such a resource in order to perform
> fine tuning for his application. In such cases performing driver reload is
> needed for the changes to take place, thus this patchset also adds support
> for hot reload.
>
> Such an abstraction can be coupled with devlink's dpipe interface, which
> models the ASIC's pipeline as a graph of match/action tables. By modeling
> the hardware resource object, and by coupling it to several dpipe tables,
> further visibility can be achieved in order to debug ASIC-wide issues.
>
> The proposed interface will provide the user the ability to understand the
> limitations of the hardware, and receive notification regarding its occupancy.
> Furthermore, monitoring the resource occupancy can be done in real-time and
> can be useful in many cases.
> ---
> Userspace part prototype can be found at https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farkadis%2Fiproute2%2F&data=02%7C01%7Carkadis%40mellanox.com%7C1ae3d8b4854a454e21e008d54c5329e3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636498842440762657&sdata=7MC2BFQFxjnmHqy2sOOL9VEa4ZGq6e5Z2n2WvuNgyFk%3D&reserved=0
> at resource_dev branch.
>
> v1->v2
> - Add resource size attribute.
> - Fix split bug.
>
Just to summarize the current fixes required:
1. ERIF dpipe table size is reporting wrong size. More precisely the
ERIF table does not take rifs, so it should not be linked to the rif
bank resource (is not part of this patchset, future extension).
2. Extended ACK user-space bug.
3. ABI documentation- Not sure we agreed upon it, Jiri?
If I missed something please respond. Nothing of the fixes mentioned
above is relevant for this patchset actually.
Couple of key-points:
1. Constrains\trade off about setting the sizes - this can be obtained
trivially from the resource tree nested structure.
2. Dpipe provides the mapping of hardware processes to resources.
3. Units - each resource specifies his units, if dpipe table's size is
X and its related to some resource its size is normalized to that
resources basic unit.
IMO this is the most hardware exact interaction, and this is the way it
should be exported from the kernel, if something is not presented in
'user' convenient way some utilities can be implemented in userspace
to easily do it. Furthermore, some examples will be provided for the
whole kvd tree partition for different cases (IPv6 heavy etc..).
Advanced user will be able to tweak it as they like.
Regarding the 'switchdev' layer I think that kernel's software tables
like nexthops/neigh/routes should be mapped to dpipe tables and not
to resources directly:
kernel_fdb--> dpipe_fdb -->/kvd/hash_single.
> Arkadi Sharshevsky (10):
> devlink: Add per devlink instance lock
> devlink: Add support for resource abstraction
> devlink: Add support for reload
> devlink: Add relation between dpipe and resource
> mlxsw: pci: Add support for performing bus reset
> mlxsw: spectrum: Register KVD resources with devlink
> mlxsw: spectrum_dpipe: Connect dpipe tables to resources
> mlxsw: spectrum: Add support for getting kvdl occupancy
> mlxsw: pci: Add support for getting resource through devlink
> mlxsw: core: Add support for reload
>
> drivers/net/ethernet/mellanox/mlxsw/core.c | 85 ++-
> drivers/net/ethernet/mellanox/mlxsw/core.h | 16 +-
> drivers/net/ethernet/mellanox/mlxsw/i2c.c | 5 +-
> drivers/net/ethernet/mellanox/mlxsw/pci.c | 98 ++--
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 205 ++++++++
> drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 13 +
> .../net/ethernet/mellanox/mlxsw/spectrum_dpipe.c | 72 ++-
> .../net/ethernet/mellanox/mlxsw/spectrum_kvdl.c | 26 +
> include/net/devlink.h | 97 ++++
> include/uapi/linux/devlink.h | 21 +
> net/core/devlink.c | 573 ++++++++++++++++++---
> 11 files changed, 1079 insertions(+), 132 deletions(-)
>
^ permalink raw reply
* [PATCH] bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()
From: SF Markus Elfring @ 2018-01-01 16:07 UTC (permalink / raw)
To: netdev, Andy Gospodarek, Jay Vosburgh, Veaceslav Falico
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 17:00:04 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/bonding/bond_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c669554d70bb..a96e0c9cc4bf 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3910,7 +3910,6 @@ int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave)
GFP_KERNEL);
if (!new_arr) {
ret = -ENOMEM;
- pr_err("Failed to build slave-array.\n");
goto out;
}
if (BOND_MODE(bond) == BOND_MODE_8023AD) {
--
2.15.1
^ permalink raw reply related
* [PATCH] bcm63xx_enet: Delete two error messages for a failed memory allocation in bcm_enetsw_open()
From: SF Markus Elfring @ 2018-01-01 16:40 UTC (permalink / raw)
To: bcm-kernel-feedback-list, netdev, linux-arm-kernel, Allen Pais,
Arnd Bergmann, David S. Miller, Florian Fainelli, Himanshu Jha,
Johannes Berg, Jonas Gorski, Kees Cook, Sergei Shtylyov,
Yuval Shaia
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 17:30:04 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index d9346e2ac720..52a42e3058cf 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -2166,7 +2166,6 @@ static int bcm_enetsw_open(struct net_device *dev)
priv->tx_skb = kzalloc(sizeof(struct sk_buff *) * priv->tx_ring_size,
GFP_KERNEL);
if (!priv->tx_skb) {
- dev_err(kdev, "cannot allocate rx skb queue\n");
ret = -ENOMEM;
goto out_free_tx_ring;
}
@@ -2180,7 +2179,6 @@ static int bcm_enetsw_open(struct net_device *dev)
priv->rx_skb = kzalloc(sizeof(struct sk_buff *) * priv->rx_ring_size,
GFP_KERNEL);
if (!priv->rx_skb) {
- dev_err(kdev, "cannot allocate rx skb queue\n");
ret = -ENOMEM;
goto out_free_tx_skb;
}
--
2.15.1
^ permalink raw reply related
* [PATCH] net: systemport: Delete an error message for a failed memory allocation in two functions
From: SF Markus Elfring @ 2018-01-01 16:54 UTC (permalink / raw)
To: netdev, Florian Fainelli; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 17:50:02 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 9d7a834c5f62..34e6ddde89e1 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1396,7 +1396,6 @@ static int bcm_sysport_init_tx_ring(struct bcm_sysport_priv *priv,
if (!ring->cbs) {
dma_free_coherent(kdev, sizeof(struct dma_desc),
ring->desc_cpu, ring->desc_dma);
- netif_err(priv, hw, priv->netdev, "CB allocation failed\n");
return -ENOMEM;
}
@@ -1576,10 +1575,8 @@ static int bcm_sysport_init_rx_ring(struct bcm_sysport_priv *priv)
priv->rx_read_ptr = 0;
priv->rx_cbs = kcalloc(priv->num_rx_bds, sizeof(struct bcm_sysport_cb),
GFP_KERNEL);
- if (!priv->rx_cbs) {
- netif_err(priv, hw, priv->netdev, "CB allocation failed\n");
+ if (!priv->rx_cbs)
return -ENOMEM;
- }
for (i = 0; i < priv->num_rx_bds; i++) {
cb = priv->rx_cbs + i;
--
2.15.1
^ permalink raw reply related
* [PATCH] LiquidIO: Delete two error messages for a failed memory allocation in octeon_setup_interrupt()
From: SF Markus Elfring @ 2018-01-01 17:18 UTC (permalink / raw)
To: netdev, Derek Chickles, Felix Manlunas, Raghu Vatsavayi,
Satanand Burla
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 18:14:49 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/cavium/liquidio/lio_core.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c b/drivers/net/ethernet/cavium/liquidio/lio_core.c
index 32ae63b6f20e..012829de76b7 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
@@ -915,10 +915,8 @@ int octeon_setup_interrupt(struct octeon_device *oct, u32 num_ioqs)
/* allocate storage for the names assigned to each irq */
oct->irq_name_storage =
kcalloc(num_interrupts, INTRNAMSIZ, GFP_KERNEL);
- if (!oct->irq_name_storage) {
- dev_err(&oct->pci_dev->dev, "Irq name storage alloc failed...\n");
+ if (!oct->irq_name_storage)
return -ENOMEM;
- }
queue_irq_names = oct->irq_name_storage;
@@ -930,7 +928,6 @@ int octeon_setup_interrupt(struct octeon_device *oct, u32 num_ioqs)
sizeof(struct msix_entry),
GFP_KERNEL);
if (!oct->msix_entries) {
- dev_err(&oct->pci_dev->dev, "Memory Alloc failed...\n");
kfree(oct->irq_name_storage);
oct->irq_name_storage = NULL;
return -ENOMEM;
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] benet: Adjustments for two function implementations
From: SF Markus Elfring @ 2018-01-01 17:52 UTC (permalink / raw)
To: netdev, Ajit Khaparde, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 18:50:05 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation in be_alloc_work()
Delete an unnecessary return statement in be_work_add_vxlan_port()
drivers/net/ethernet/emulex/benet/be_main.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] benet: Delete an error message for a failed memory allocation in be_alloc_work()
From: SF Markus Elfring @ 2018-01-01 17:53 UTC (permalink / raw)
To: netdev, Ajit Khaparde, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna
Cc: LKML, kernel-janitors
In-Reply-To: <86e577a3-77a4-2e74-dd2d-4d63e90ffb72@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 18:38:06 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/emulex/benet/be_main.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index c6e859a27ee6..475d94762306 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4930,11 +4930,8 @@ static struct be_cmd_work *be_alloc_work(struct be_adapter *adapter,
struct be_cmd_work *work;
work = kzalloc(sizeof(*work), GFP_ATOMIC);
- if (!work) {
- dev_err(&adapter->pdev->dev,
- "be_work memory allocation failed\n");
+ if (!work)
return NULL;
- }
INIT_WORK(&work->work, func);
work->adapter = adapter;
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] benet: Delete an unnecessary return statement in be_work_add_vxlan_port()
From: SF Markus Elfring @ 2018-01-01 17:54 UTC (permalink / raw)
To: netdev, Ajit Khaparde, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna
Cc: LKML, kernel-janitors
In-Reply-To: <86e577a3-77a4-2e74-dd2d-4d63e90ffb72@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 18:45:17 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: void function return statements are not generally useful
Thus remove such a statement in the affected function.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/emulex/benet/be_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 475d94762306..38cc8f875846 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -5001,7 +5001,6 @@ static void be_work_add_vxlan_port(struct work_struct *work)
be_disable_vxlan_offloads(adapter);
done:
kfree(cmd_work);
- return;
}
static void be_work_del_vxlan_port(struct work_struct *work)
--
2.15.1
^ permalink raw reply related
* [PATCH] net: hns: Delete an error message for a failed memory allocation in hns_rcb_common_get_cfg()
From: SF Markus Elfring @ 2018-01-01 18:19 UTC (permalink / raw)
To: netdev, David S. Miller, lipeng, Matthias Brugger, Salil Mehta,
Timmy Li, Yisen Zhuang
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 19:11:46 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 6f3570cfb501..cd74f0598dde 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -767,10 +767,9 @@ int hns_rcb_common_get_cfg(struct dsaf_device *dsaf_dev,
rcb_common =
devm_kzalloc(dsaf_dev->dev, sizeof(*rcb_common) +
ring_num * sizeof(struct ring_pair_cb), GFP_KERNEL);
- if (!rcb_common) {
- dev_err(dsaf_dev->dev, "rcb common devm_kzalloc fail!\n");
+ if (!rcb_common)
return -ENOMEM;
- }
+
rcb_common->comm_index = comm_index;
rcb_common->ring_num = ring_num;
rcb_common->dsaf_dev = dsaf_dev;
--
2.15.1
^ permalink raw reply related
* [PATCH v4] uapi libc compat: add fallback for unsupported libcs
From: Hauke Mehrtens @ 2018-01-01 18:33 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, linux-api, musl, felix.janda, f.fainelli,
carlos, ldv
From: Felix Janda <felix.janda@posteo.de>
libc-compat.h aims to prevent symbol collisions between uapi and libc
headers for each supported libc. This requires continuous coordination
between them.
The goal of this commit is to improve the situation for libcs (such as
musl) which are not yet supported and/or do not wish to be explicitly
supported, while not affecting supported libcs. More precisely, with
this commit, unsupported libcs can request the suppression of any
specific uapi definition by defining the correspondings _UAPI_DEF_*
macro as 0. This can fix symbol collisions for them, as long as the
libc headers are included before the uapi headers. Inclusion in the
other order is outside the scope of this commit.
All infrastructure in order to enable this fallback for unsupported
libcs is already in place, except that libc-compat.h unconditionally
defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
any previous definitions are ignored. In order to fix this, this commit
merely makes these definitions conditional.
This commit together with the musl libc commit
http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
fixes for example the following compiler errors when <linux/in6.h> is
included after musl's <netinet/in.h>:
./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
The comments referencing glibc are still correct, but this file is not
only used for glibc any more.
Signed-off-by: Felix Janda <felix.janda@posteo.de>
Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de>
---
v4: Extend patch description with comment about glibc comments
v3: Fix typos, add a comment to the file and use #ifndef.
v2: The only change to the previous version is the commit title and
message.
This was send to linux-api@vger.kernel.org before and it was suggested
that this patch should go through the networking tree to Linus because
most of these definitions are networking related.
include/uapi/linux/libc-compat.h | 55 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 282875cf8056..8254c937c9f4 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -168,46 +168,99 @@
/* If we did not see any headers from any supported C libraries,
* or we are being included in the kernel, then define everything
- * that we need. */
+ * that we need. Check for previous __UAPI_* definitions to give
+ * unsupported C libraries a way to opt out of any kernel definition. */
#else /* !defined(__GLIBC__) */
/* Definitions for if.h */
+#ifndef __UAPI_DEF_IF_IFCONF
#define __UAPI_DEF_IF_IFCONF 1
+#endif
+#ifndef __UAPI_DEF_IF_IFMAP
#define __UAPI_DEF_IF_IFMAP 1
+#endif
+#ifndef __UAPI_DEF_IF_IFNAMSIZ
#define __UAPI_DEF_IF_IFNAMSIZ 1
+#endif
+#ifndef __UAPI_DEF_IF_IFREQ
#define __UAPI_DEF_IF_IFREQ 1
+#endif
/* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
#define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
+#endif
/* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
+#endif
/* Definitions for in.h */
+#ifndef __UAPI_DEF_IN_ADDR
#define __UAPI_DEF_IN_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN_IPPROTO
#define __UAPI_DEF_IN_IPPROTO 1
+#endif
+#ifndef __UAPI_DEF_IN_PKTINFO
#define __UAPI_DEF_IN_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP_MREQ
#define __UAPI_DEF_IP_MREQ 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN
#define __UAPI_DEF_SOCKADDR_IN 1
+#endif
+#ifndef __UAPI_DEF_IN_CLASS
#define __UAPI_DEF_IN_CLASS 1
+#endif
/* Definitions for in6.h */
+#ifndef __UAPI_DEF_IN6_ADDR
#define __UAPI_DEF_IN6_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN6_ADDR_ALT
#define __UAPI_DEF_IN6_ADDR_ALT 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN6
#define __UAPI_DEF_SOCKADDR_IN6 1
+#endif
+#ifndef __UAPI_DEF_IPV6_MREQ
#define __UAPI_DEF_IPV6_MREQ 1
+#endif
+#ifndef __UAPI_DEF_IPPROTO_V6
#define __UAPI_DEF_IPPROTO_V6 1
+#endif
+#ifndef __UAPI_DEF_IPV6_OPTIONS
#define __UAPI_DEF_IPV6_OPTIONS 1
+#endif
+#ifndef __UAPI_DEF_IN6_PKTINFO
#define __UAPI_DEF_IN6_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP6_MTUINFO
#define __UAPI_DEF_IP6_MTUINFO 1
+#endif
/* Definitions for ipx.h */
+#ifndef __UAPI_DEF_SOCKADDR_IPX
#define __UAPI_DEF_SOCKADDR_IPX 1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEFINITION
#define __UAPI_DEF_IPX_ROUTE_DEFINITION 1
+#endif
+#ifndef __UAPI_DEF_IPX_INTERFACE_DEFINITION
#define __UAPI_DEF_IPX_INTERFACE_DEFINITION 1
+#endif
+#ifndef __UAPI_DEF_IPX_CONFIG_DATA
#define __UAPI_DEF_IPX_CONFIG_DATA 1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEF
#define __UAPI_DEF_IPX_ROUTE_DEF 1
+#endif
/* Definitions for xattr.h */
+#ifndef __UAPI_DEF_XATTR
#define __UAPI_DEF_XATTR 1
+#endif
#endif /* __GLIBC__ */
--
2.11.0
^ permalink raw reply related
* [PATCH] ehea: Delete an error message for a failed memory allocation in two functions
From: SF Markus Elfring @ 2018-01-01 19:17 UTC (permalink / raw)
To: netdev, Douglas Miller; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 20:14:25 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 4878b7169e0f..b234bb9b9586 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -1512,7 +1512,6 @@ static int ehea_init_port_res(struct ehea_port *port, struct ehea_port_res *pr,
init_attr = kzalloc(sizeof(*init_attr), GFP_KERNEL);
if (!init_attr) {
ret = -ENOMEM;
- pr_err("no mem for ehea_qp_init_attr\n");
goto out_free;
}
@@ -3409,7 +3408,6 @@ static int ehea_probe_adapter(struct platform_device *dev)
adapter = devm_kzalloc(&dev->dev, sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
ret = -ENOMEM;
- dev_err(&dev->dev, "no mem for ehea_adapter\n");
goto out;
}
--
2.15.1
^ permalink raw reply related
* [PATCH] i40e: Delete an error message for a failed memory allocation in i40e_init_interrupt_scheme()
From: SF Markus Elfring @ 2018-01-01 19:43 UTC (permalink / raw)
To: netdev, intel-wired-lan, Jeff Kirsher; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 20:38:14 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 4a964d6e4a9e..fd9ac22ee65a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -10445,10 +10445,9 @@ static int i40e_init_interrupt_scheme(struct i40e_pf *pf)
/* set up vector assignment tracking */
size = sizeof(struct i40e_lump_tracking) + (sizeof(u16) * vectors);
pf->irq_pile = kzalloc(size, GFP_KERNEL);
- if (!pf->irq_pile) {
- dev_err(&pf->pdev->dev, "error allocating irq_pile memory\n");
+ if (!pf->irq_pile)
return -ENOMEM;
- }
+
pf->irq_pile->num_entries = vectors;
pf->irq_pile->search_hint = 0;
--
2.15.1
^ permalink raw reply related
* [PATCH] igb: Delete an error message for a failed memory allocation in igb_enable_sriov()
From: SF Markus Elfring @ 2018-01-01 19:56 UTC (permalink / raw)
To: netdev, intel-wired-lan, Jeff Kirsher; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 20:53:10 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index e94d3c256667..1621aaa3eb28 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3200,8 +3200,6 @@ static int igb_enable_sriov(struct pci_dev *pdev, int num_vfs)
/* if allocation failed then we do not support SR-IOV */
if (!adapter->vf_data) {
adapter->vfs_allocated_count = 0;
- dev_err(&pdev->dev,
- "Unable to allocate memory for VF Data Storage\n");
err = -ENOMEM;
goto out;
}
--
2.15.1
^ permalink raw reply related
* [PATCH] ethernet/mediatek: Delete an error message for a failed memory allocation in mtk_add_mac()
From: SF Markus Elfring @ 2018-01-01 20:15 UTC (permalink / raw)
To: linux-mediatek, linux-arm-kernel, netdev, Felix Fietkau,
John Crispin, Matthias Brugger, Nelson Chang, Sean Wang
Cc: kernel-janitors, LKML
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 1 Jan 2018 21:06:50 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 54adfd967858..52d489c1ceae 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2427,7 +2427,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
sizeof(*mac->hw_stats),
GFP_KERNEL);
if (!mac->hw_stats) {
- dev_err(eth->dev, "failed to allocate counter memory\n");
err = -ENOMEM;
goto free_netdev;
}
--
2.15.1
^ permalink raw reply related
* [PATCH] ethernet: mlx4: Delete an error message for a failed memory allocation in five functions
From: SF Markus Elfring @ 2018-01-01 20:46 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Tariq Toukan
Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA
From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Date: Mon, 1 Jan 2018 21:42:27 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx4/en_cq.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/main.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/reset.c | 1 -
5 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_cq.c b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
index 1e487acb4667..cf5e0d002b3f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
@@ -55,10 +55,8 @@ int mlx4_en_create_cq(struct mlx4_en_priv *priv,
cq = kzalloc_node(sizeof(*cq), GFP_KERNEL, node);
if (!cq) {
cq = kzalloc(sizeof(*cq), GFP_KERNEL);
- if (!cq) {
- en_err(priv, "Failed to allocate CQ structure\n");
+ if (!cq)
return -ENOMEM;
- }
}
cq->size = entries;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 85e28efcda33..103abe1ad0cb 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -272,10 +272,8 @@ int mlx4_en_create_rx_ring(struct mlx4_en_priv *priv,
ring = kzalloc_node(sizeof(*ring), GFP_KERNEL, node);
if (!ring) {
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
- if (!ring) {
- en_err(priv, "Failed to allocate RX ring structure\n");
+ if (!ring)
return -ENOMEM;
- }
}
ring->prod = 0;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 6b6853773848..a21d6ffaa244 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -58,10 +58,8 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
ring = kzalloc_node(sizeof(*ring), GFP_KERNEL, node);
if (!ring) {
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
- if (!ring) {
- en_err(priv, "Failed allocating TX ring\n");
+ if (!ring)
return -ENOMEM;
- }
}
ring->size = size;
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 4d84cab77105..c793c5b0b0cf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -3177,10 +3177,8 @@ static u64 mlx4_enable_sriov(struct mlx4_dev *dev, struct pci_dev *pdev,
}
dev->dev_vfs = kzalloc(total_vfs * sizeof(*dev->dev_vfs), GFP_KERNEL);
- if (NULL == dev->dev_vfs) {
- mlx4_err(dev, "Failed to allocate memory for VFs\n");
+ if (!dev->dev_vfs)
goto disable_sriov;
- }
if (!(dev->flags & MLX4_FLAG_SRIOV)) {
if (total_vfs > fw_enabled_sriov_vfs) {
diff --git a/drivers/net/ethernet/mellanox/mlx4/reset.c b/drivers/net/ethernet/mellanox/mlx4/reset.c
index 0076d88587ca..74d77e56cc35 100644
--- a/drivers/net/ethernet/mellanox/mlx4/reset.c
+++ b/drivers/net/ethernet/mellanox/mlx4/reset.c
@@ -72,7 +72,6 @@ int mlx4_reset(struct mlx4_dev *dev)
hca_header = kmalloc(256, GFP_KERNEL);
if (!hca_header) {
err = -ENOMEM;
- mlx4_err(dev, "Couldn't allocate memory to save HCA PCI header, aborting\n");
goto out;
}
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox