* Re: [RFC PATCH net-next 2/4] net: 8021q: vlan_core: allow use list of vlans for real device
From: Ivan Khoronzhuk @ 2018-10-19 14:02 UTC (permalink / raw)
To: Bjørn Mork
Cc: grygorii.strashko, davem, linux-omap, netdev, linux-kernel,
alexander.h.duyck
In-Reply-To: <878t2up4er.fsf@miraculix.mork.no>
On Fri, Oct 19, 2018 at 01:22:20PM +0200, Bjørn Mork wrote:
>Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> writes:
>
>> @@ -236,6 +239,13 @@ __vlan_find_dev_deep_rcu(struct net_device *real_dev,
>> return NULL;
>> }
>>
>> +static inline int
>> +vlan_for_each(struct net_device *dev,
>> + int (*action)(struct net_device *dev, int vid, void *arg),
>> + void *arg)
>> +{
>> +}
>> +
>
>
>This stub should return 0, shouldn't it?
yes, it has.
>
>
>Bjørn
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH] selftests/bpf: add missing executables to .gitignore
From: Anders Roxell @ 2018-10-19 14:24 UTC (permalink / raw)
To: ast, daniel, shuah; +Cc: netdev, linux-kernel, linux-kselftest, Anders Roxell
Fixes: 371e4fcc9d96 ("selftests/bpf: cgroup local storage-based network counters")
Fixes: 370920c47b26 ("selftests/bpf: Test libbpf_{prog,attach}_type_by_name")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
tools/testing/selftests/bpf/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/bpf/.gitignore b/tools/testing/selftests/bpf/.gitignore
index 8a60c9b9892d..1b799e30c06d 100644
--- a/tools/testing/selftests/bpf/.gitignore
+++ b/tools/testing/selftests/bpf/.gitignore
@@ -25,3 +25,5 @@ test_cgroup_storage
test_select_reuseport
test_flow_dissector
flow_dissector_load
+test_netcnt
+test_section_names
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 1/3] net: socionext: Stop PHY before resetting netsec
From: Masahisa Kojima @ 2018-10-19 6:24 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, Ilias Apalodimas, Jassi Brar, Ard Biesheuvel,
Yoshitoyo Osaki
In-Reply-To: <a9434d99-a757-c14f-faac-dfd46f6b1a53@gmail.com>
Hi,
Thank you very much for your comment.
I have not realized that reading MII_PHYSID1/ID2 are ignored
if the PHY is in power down, this patch has a side effect
in ACPI case.
My intention is that netsec_reset_hardware() should be called
in PHY power down state, but current place to add PHY power down
is not proper.
I will consider the right place to do.
On Fri, 19 Oct 2018 at 11:59, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 10/18/2018 6:08 PM, masahisa.kojima@linaro.org wrote:
> > From: Masahisa Kojima <masahisa.kojima@linaro.org>
> >
> > After resetting netsec IP, driver have to wait until
> > netsec mode turns to NRM mode.
> > But sometimes mode transition to NRM will not complete
> > if the PHY is in normal operation state.
> > To avoid this situation, stop PHY before resetting netsec.
> >
> > Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
> > Signed-off-by: Yoshitoyo Osaki <osaki.yoshitoyo@socionext.com>
> > ---
> > drivers/net/ethernet/socionext/netsec.c | 15 +++++++++++----
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> > index 4289ccb26e4e..273cc5fc07e0 100644
> > --- a/drivers/net/ethernet/socionext/netsec.c
> > +++ b/drivers/net/ethernet/socionext/netsec.c
> > @@ -1343,11 +1343,11 @@ static int netsec_netdev_stop(struct net_device *ndev)
> > netsec_uninit_pkt_dring(priv, NETSEC_RING_TX);
> > netsec_uninit_pkt_dring(priv, NETSEC_RING_RX);
> >
> > - ret = netsec_reset_hardware(priv, false);
> > -
> > phy_stop(ndev->phydev);
> > phy_disconnect(ndev->phydev);
> >
> > + ret = netsec_reset_hardware(priv, false);
> > +
> > pm_runtime_put_sync(priv->dev);
> >
> > return ret;
> > @@ -1415,7 +1415,7 @@ static const struct net_device_ops netsec_netdev_ops = {
> > };
> >
> > static int netsec_of_probe(struct platform_device *pdev,
> > - struct netsec_priv *priv)
> > + struct netsec_priv *priv, u32 *phy_addr)
> > {
> > priv->phy_np = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
> > if (!priv->phy_np) {
> > @@ -1423,6 +1423,8 @@ static int netsec_of_probe(struct platform_device *pdev,
> > return -EINVAL;
> > }
> >
> > + *phy_addr = of_mdio_parse_addr(&pdev->dev, priv->phy_np);
> > +
> > priv->clk = devm_clk_get(&pdev->dev, NULL); /* get by 'phy_ref_clk' */
> > if (IS_ERR(priv->clk)) {
> > dev_err(&pdev->dev, "phy_ref_clk not found\n");
> > @@ -1473,6 +1475,7 @@ static int netsec_register_mdio(struct netsec_priv *priv, u32 phy_addr)
> > {
> > struct mii_bus *bus;
> > int ret;
> > + u16 data;
> >
> > bus = devm_mdiobus_alloc(priv->dev);
> > if (!bus)
> > @@ -1486,6 +1489,10 @@ static int netsec_register_mdio(struct netsec_priv *priv, u32 phy_addr)
> > bus->parent = priv->dev;
> > priv->mii_bus = bus;
> >
> > + /* set phy power down */
> > + data = netsec_phy_read(bus, phy_addr, 0) | 0x800;
> > + netsec_phy_write(bus, phy_addr, 0, data);
>
> This is not explained in your commit message, and this is using open
> coded values instead of the symbolic names from include/uapi/linux/mii.h.
>
> Note that depending on the type of PHY you are interfaced with if the
> PHY is in power down, the only register it is allowed to accept writes
> for is MII_BMCR (per 802.3 clause 22 spec), any other read or write to a
> different register can be discarded by its MDIO snooping logic. Since
> probing the MDIO bus involves reading MII_PHYSID1/ID2, what is this
> trying to achieve?
>
> > +
> > if (dev_of_node(priv->dev)) {
> > struct device_node *mdio_node, *parent = dev_of_node(priv->dev);
> >
> > @@ -1623,7 +1630,7 @@ static int netsec_probe(struct platform_device *pdev)
> > }
> >
> > if (dev_of_node(&pdev->dev))
> > - ret = netsec_of_probe(pdev, priv);
> > + ret = netsec_of_probe(pdev, priv, &phy_addr);
> > else
> > ret = netsec_acpi_probe(pdev, priv, &phy_addr);
> > if (ret)
> >
>
> --
> Florian
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add dummy PHY register read in phy_write()
From: Masahisa Kojima @ 2018-10-19 6:44 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, Ilias Apalodimas, Jassi Brar, Ard Biesheuvel,
Yoshitoyo Osaki
In-Reply-To: <6b6328ad-a1a8-f3de-6618-40a703db178f@gmail.com>
On Fri, 19 Oct 2018 at 12:01, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 10/18/2018 6:08 PM, masahisa.kojima@linaro.org wrote:
> > From: Masahisa Kojima <masahisa.kojima@linaro.org>
> >
> > There is a compatibility issue between RTL8211E implemented
> > in Developerbox and netsec network controller IP(F_GMAC4).
> >
> > RTL8211E expects MDC clock must be kept toggling for several
> > clock cycle with MDIO high before entering the IDLE state.
> > To meet this requirement, netsec driver needs to issue dummy
> > read(e.g. read PHYID1(offset 0x2) register) right after write.
> >
> > Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
> > Signed-off-by: Yoshitoyo Osaki <osaki.yoshitoyo@socionext.com>
> > ---
> > drivers/net/ethernet/socionext/netsec.c | 18 ++++++++++++++++--
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> > index 273cc5fc07e0..e7faaf8be99e 100644
> > --- a/drivers/net/ethernet/socionext/netsec.c
> > +++ b/drivers/net/ethernet/socionext/netsec.c
> > @@ -431,9 +431,12 @@ static int netsec_mac_update_to_phy_state(struct netsec_priv *priv)
> > return 0;
> > }
> >
> > +static int netsec_phy_read(struct mii_bus *bus, int phy_addr, int reg_addr);
> > +
> > static int netsec_phy_write(struct mii_bus *bus,
> > int phy_addr, int reg, u16 val)
> > {
> > + int status;
> > struct netsec_priv *priv = bus->priv;
> >
> > if (netsec_mac_write(priv, GMAC_REG_GDR, val))
> > @@ -446,8 +449,19 @@ static int netsec_phy_write(struct mii_bus *bus,
> > GMAC_REG_SHIFT_CR_GAR)))
> > return -ETIMEDOUT;
> >
> > - return netsec_mac_wait_while_busy(priv, GMAC_REG_GAR,
> > - NETSEC_GMAC_GAR_REG_GB);
> > + status = netsec_mac_wait_while_busy(priv, GMAC_REG_GAR,
> > + NETSEC_GMAC_GAR_REG_GB);
> > +
> > + /* Developerbox implements RTL8211E PHY and there is
> > + * a compatibility problem with F_GMAC4.
> > + * RTL8211E expects MDC clock must be kept toggling for several
> > + * clock cycle with MDIO high before entering the IDLE state.
> > + * To meet this requirement, netsec driver needs to issue dummy
> > + * read(e.g. read PHYID1(offset 0x2) register) right after write.
> > + */
> > + netsec_phy_read(bus, phy_addr, 2);
>
> MII_PHYSID1 instead of 0x2 would be preferable. It is not clear to me
> from your commit message if this is a problem specific to your MDIO
> controller implementation and the RTL8211E PHY or if this is a general
> problem of the PHY irrespective of the MDIO controller it is interface
> with. If the latter, then we should seek a solution at a different layer
> such that other systems don't have that same problem.
>
> Thank you!
> --
> Florian
I will replace direct value with MACROs, also for other instances.
Our MDIO controller stops MDC clock right after the write access,
but RTL8211E PHY expects to keep several clock cycle.
So it is depending on our MDIO controller implementation.
^ permalink raw reply
* CRC errors between mvneta and macb
From: Richard Genoud @ 2018-10-19 15:15 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Antoine Tenart, Gregory CLEMENT, Yelena Krivosheev,
Maxime Chevallier, Nicolas Ferre, netdev, linux-kernel
Hi all,
I've been struggling with a strange behavior between a clearfog-pro
and an at91sam9g35-ek boards.
TL;DR: ethernet frames are received with a CRC error on the clearfog
ETH0, but seem perfectly all right. Add a switch between the 2
boards, and the ethernet frames are accepted.
I've got a clearfog pro and an at91sam9g35-ek, both with kernel
4.19-rc8.
An RJ45 cable is plugged between the clearfog (on the solo port (eth0))
and the g35-ek board (100Mb/s).
They are configured with autoneg and a fixed IP address.
I start the 2 board, and, with the clearfog I ping the g35-ek.
If it succeeds, it will until the g35-ek is rebooted.
If it fails, it also will until the g35-ek is rebooted.
Rebooting the cleafog doesn't change anything.
Resetting the g35-ek PHY (mii-diag -R) doesn't change anything either.
When the ping fails, it's actually because the mvneta returns a CRC
error:
mvneta f1070000.ethernet eth0: bad rx status 0cc10000 (crc error), size=66
And, if I plug the RJ45 cable between the clearfog's matrix and the
g35-ek, everything works well, always.
To ease the debugging, instead of a ping I used:
https://gist.github.com/austinmarton/1922600
from the g35-ek in order to have the same frame every time.
So, I check with the scope the ethernet CRC (on the g35-ek PHY TXD[0-1]
(DM9161A)).
And the CRC is all right.
I also manage to trigger this bug by simply doing:
rmmod macb ; insmod macb.ko on the g35-ek.
Then, frames are accepted, or not.
I checked all PHY/macb register values on the g35-ek, they are the same.
The only thing I could find is related to the TXCLK on the PHY.
When there's a CRC error, the TXCLK has its polarity inverted...
That's a clue !
But this TXCLK (25MHz) is not used on the g35-ek.
Only the REFCLK/XT2 (50MHz) is used to synchronise the PHY and the macb.
So I guess that the TXCLK has a role to play to generate TX+/TX-
And I also guess that when the signal is converted back on the clearfog,
the clock polarity is somehow responsible for the CRC errors.
I was heading to get my scope on the clearfog's PHY to see what it
received, but Marvell's documentation is not as freely available as
Atmel's ones, so I'm quite stuck at this point.
Any idea ?
NB: I also managed to trigger this with an at91sam9g20-ek (but not with
a sama5d2)
Regards,
Richard
^ permalink raw reply
* Re: [PATCH net] r8169: fix NAPI handling under high load
From: Jonathan Woithe @ 2018-10-19 7:29 UTC (permalink / raw)
To: Holger Hoffstätte
Cc: Heiner Kallweit, Francois Romieu, David Miller,
Realtek linux nic maintainers, netdev@vger.kernel.org
In-Reply-To: <19a2c03e-a3bd-2be5-5d80-7bc2c8912670@applied-asynchrony.com>
On Thu, Oct 18, 2018 at 01:52:33PM +0200, Holger Hoffstätte wrote:
> On 10/18/18 08:15, Jonathan Woithe wrote:
> > On Thu, Oct 18, 2018 at 08:03:32AM +0200, Heiner Kallweit wrote:
> > > Proposed fix is here:
> > > https://patchwork.ozlabs.org/patch/985014/
> > > Would be good if you could test it. Thanks!
> >
> > I should be able to do so tomorrow. Which kernel would you like me to apply
> > the patch to?
>
> Hi Jonathan,
>
> I'm already running it on 4.18.15, so either that or latest 4.19-rc would
> work as well.
It turns out I couldn't compile 4.18.15 conveniently for the test system due
to the age of the compiler. The compiler, like the rest of the
distribution, is ancient: the presence of the bug has prevented us updating
the system due to a need to support hardware in the field. The bug has
affected the operation of our systems in all kernels since (I think) 3.3.
I could compile 4.14 though - I had previously confirmed that the problem
was still seen with that kernel. I therefore applied the fix to 4.14 (which
was trivial) and started a test with that. The system has been running
without exhibiting the effects of the bug for over five hours. With an
unpatched 4.14, symptoms were typically seen within 30 minutes.
I will leave the system to operate over the weekend to be sure, but at this
stage it seems likely that the patch will resolve this long-standing
difficulty that we've experienced. I will report back on Monday.
Regards
jonathan
^ permalink raw reply
* Re: CRC errors between mvneta and macb
From: Willy Tarreau @ 2018-10-19 15:44 UTC (permalink / raw)
To: Richard Genoud
Cc: Thomas Petazzoni, Antoine Tenart, Gregory CLEMENT,
Yelena Krivosheev, Maxime Chevallier, Nicolas Ferre, netdev,
linux-kernel
In-Reply-To: <f6ccdfbd-7a67-ae14-5940-c7614cb143e9@sorico.fr>
On Fri, Oct 19, 2018 at 05:15:03PM +0200, Richard Genoud wrote:
> When there's a CRC error, the TXCLK has its polarity inverted...
> That's a clue !
>
> But this TXCLK (25MHz) is not used on the g35-ek.
> Only the REFCLK/XT2 (50MHz) is used to synchronise the PHY and the macb.
> So I guess that the TXCLK has a role to play to generate TX+/TX-
Well, just a stupid idea, maybe when this signal is inverted, the TX+/TX-
are desynchronized by half a clock and are not always properly interpreted
on the other side ?
Willy
^ permalink raw reply
* Re: KASAN: use-after-free Read in sk_psock_link_pop
From: Daniel Borkmann @ 2018-10-19 15:57 UTC (permalink / raw)
To: syzbot, davem, john.fastabend, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <000000000000a6391e057896e940@google.com>
On 10/19/2018 05:54 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 3a3295bfa6f4 Merge branch 'sctp-fix-sk_wmem_queued-and-use..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10a09791400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=133950703f7759f9
> dashboard link: https://syzkaller.appspot.com/bug?extid=1651eee005f9de26ec35
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+1651eee005f9de26ec35@syzkaller.appspotmail.com
>
> __nla_parse: 2 callbacks suppressed
> netlink: 20 bytes leftover after parsing attributes in process `syz-executor0'.
> ==================================================================
> BUG: KASAN: use-after-free in __lock_acquire+0x37c2/0x4ec0 kernel/locking/lockdep.c:3290
> Read of size 8 at addr ffff8801bcae2ff8 by task syz-executor3/30186
>
> CPU: 0 PID: 30186 Comm: syz-executor3 Not tainted 4.19.0-rc7+ #266
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> __lock_acquire+0x37c2/0x4ec0 kernel/locking/lockdep.c:3290
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
> _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
> spin_lock_bh include/linux/spinlock.h:334 [inline]
[...]
Looking into it ...
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] tools, perf: use smp_{rmb,mb} barriers instead of {rmb,mb}
From: Peter Zijlstra @ 2018-10-19 8:04 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, paulmck, will.deacon, acme, yhs, john.fastabend,
netdev
In-Reply-To: <20181018153307.ayvmq6du3gnsyvro@ast-mbp.dhcp.thefacebook.com>
On Thu, Oct 18, 2018 at 08:33:09AM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
> > #endif /* _TOOLS_LINUX_ASM_IA64_BARRIER_H */
> > diff --git a/tools/arch/powerpc/include/asm/barrier.h b/tools/arch/powerpc/include/asm/barrier.h
> > index a634da0..905a2c6 100644
> > --- a/tools/arch/powerpc/include/asm/barrier.h
> > +++ b/tools/arch/powerpc/include/asm/barrier.h
> > @@ -27,4 +27,20 @@
> > #define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> > #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> >
> > +#if defined(__powerpc64__)
> > +#define smp_lwsync() __asm__ __volatile__ ("lwsync" : : : "memory")
> > +
> > +#define smp_store_release(p, v) \
> > +do { \
> > + smp_lwsync(); \
> > + WRITE_ONCE(*p, v); \
> > +} while (0)
> > +
> > +#define smp_load_acquire(p) \
> > +({ \
> > + typeof(*p) ___p1 = READ_ONCE(*p); \
> > + smp_lwsync(); \
> > + ___p1; \
>
> I don't like this proliferation of asm.
> Why do we think that we can do better job than compiler?
> can we please use gcc builtins instead?
> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> __atomic_load_n(ptr, __ATOMIC_ACQUIRE);
> __atomic_store_n(ptr, val, __ATOMIC_RELEASE);
> are done specifically for this use case if I'm not mistaken.
> I think it pays to learn what compiler provides.
My problem with using the C11 stuff for this is that we're then limited
to compilers that actually support that. The kernel has a minimum of
gcc-4.6 (and thus perf does too I think) and gcc-4.6 does not have C11.
What Daniel writes is also true; the kernel and C11 memory models don't
align; but you're right in that for this purpose the C11 load-acquire
and store-release would indeed suffice.
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] samples: bpf: get ifindex from ifname
From: Matteo Croce @ 2018-10-19 8:42 UTC (permalink / raw)
To: ys114321; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <CAH3MdRUM+Dw3-Es45bjyGdyF8QO6Vb2-EPf9HStb2_1L5pOErA@mail.gmail.com>
On Fri, Oct 19, 2018 at 5:35 AM Y Song <ys114321@gmail.com> wrote:
>
> On Thu, Oct 18, 2018 at 1:48 PM Matteo Croce <mcroce@redhat.com> wrote:
> >
> > Find the ifindex via ioctl(SIOCGIFINDEX) instead of requiring the
> > numeric ifindex.
>
> Maybe use if_nametoindex which is simpler?
>
> >
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
> > ---
> > samples/bpf/xdp1_user.c | 26 ++++++++++++++++++++++++--
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/samples/bpf/xdp1_user.c b/samples/bpf/xdp1_user.c
> > index 4f3d824fc044..a1d0c5dcee9c 100644
> > --- a/samples/bpf/xdp1_user.c
> > +++ b/samples/bpf/xdp1_user.c
> > @@ -15,6 +15,9 @@
> > #include <unistd.h>
> > #include <libgen.h>
> > #include <sys/resource.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/socket.h>
> > +#include <linux/if.h>
> >
> > #include "bpf_util.h"
> > #include "bpf/bpf.h"
> > @@ -59,7 +62,7 @@ static void poll_stats(int map_fd, int interval)
> > static void usage(const char *prog)
> > {
> > fprintf(stderr,
> > - "usage: %s [OPTS] IFINDEX\n\n"
> > + "usage: %s [OPTS] IFACE\n\n"
> > "OPTS:\n"
> > " -S use skb-mode\n"
> > " -N enforce native mode\n",
> > @@ -74,9 +77,11 @@ int main(int argc, char **argv)
> > };
> > const char *optstr = "SN";
> > int prog_fd, map_fd, opt;
> > + struct ifreq ifr = { 0 };
> > struct bpf_object *obj;
> > struct bpf_map *map;
> > char filename[256];
> > + int sock;
> >
> > while ((opt = getopt(argc, argv, optstr)) != -1) {
> > switch (opt) {
> > @@ -102,7 +107,24 @@ int main(int argc, char **argv)
> > return 1;
> > }
> >
> > - ifindex = strtoul(argv[optind], NULL, 0);
> > + sock = socket(AF_UNIX, SOCK_DGRAM, 0);
> > + if (sock == -1) {
> > + perror("socket");
> > + return 1;
> > + }
> > +
> > + if (strlen(argv[optind]) >= IFNAMSIZ) {
> > + printf("invalid ifname '%s'\n", argv[optind]);
> > + return 1;
> > + }
> > +
> > + strcpy(ifr.ifr_name, argv[optind]);
> > + if (ioctl(sock, SIOCGIFINDEX, &ifr) < 0) {
> > + perror("SIOCGIFINDEX");
> > + return 1;
> > + }
> > + close(sock);
> > + ifindex = ifr.ifr_ifindex;
> >
> > snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
> > prog_load_attr.file = filename;
> > --
> > 2.19.1
> >
Right, even better. Will do a v2, thanks.
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [net-next PATCH] net: sched: cls_flower: Classify packets using port ranges
From: Jiri Pirko @ 2018-10-19 8:52 UTC (permalink / raw)
To: Nambiar, Amritha
Cc: netdev, davem, jakub.kicinski, sridhar.samudrala, jhs,
xiyou.wangcong
In-Reply-To: <28d1bd21-fd85-07e5-c6e6-18e7a0b19da4@intel.com>
Thu, Oct 18, 2018 at 08:24:44PM CEST, amritha.nambiar@intel.com wrote:
>On 10/18/2018 5:17 AM, Jiri Pirko wrote:
>> Fri, Oct 12, 2018 at 03:53:30PM CEST, amritha.nambiar@intel.com wrote:
>>> Added support in tc flower for filtering based on port ranges.
>>> This is a rework of the RFC patch at:
>>> https://patchwork.ozlabs.org/patch/969595/
>>>
>>> Example:
>>> 1. Match on a port range:
>>> -------------------------
>>> $ tc filter add dev enp4s0 protocol ip parent ffff:\
>>> prio 1 flower ip_proto tcp dst_port range 20-30 skip_hw\
>>> action drop
>>>
>>> $ tc -s filter show dev enp4s0 parent ffff:
>>> filter protocol ip pref 1 flower chain 0
>>> filter protocol ip pref 1 flower chain 0 handle 0x1
>>> eth_type ipv4
>>> ip_proto tcp
>>> dst_port_min 20
>>> dst_port_max 30
>>> skip_hw
>>> not_in_hw
>>> action order 1: gact action drop
>>> random type none pass val 0
>>> index 1 ref 1 bind 1 installed 181 sec used 5 sec
>>> Action statistics:
>>> Sent 460 bytes 10 pkt (dropped 10, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>>
>>> 2. Match on IP address and port range:
>>> --------------------------------------
>>> $ tc filter add dev enp4s0 protocol ip parent ffff:\
>>> prio 1 flower dst_ip 192.168.1.1 ip_proto tcp dst_port range 100-200\
>>> skip_hw action drop
>>>
>>> $ tc -s filter show dev enp4s0 parent ffff:
>>> filter protocol ip pref 1 flower chain 0 handle 0x2
>>> eth_type ipv4
>>> ip_proto tcp
>>> dst_ip 192.168.1.1
>>> dst_port_min 100
>>> dst_port_max 200
>>> skip_hw
>>> not_in_hw
>>> action order 1: gact action drop
>>> random type none pass val 0
>>> index 2 ref 1 bind 1 installed 28 sec used 6 sec
>>> Action statistics:
>>> Sent 460 bytes 10 pkt (dropped 10, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>>
>>> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
>>> ---
>>> include/uapi/linux/pkt_cls.h | 5 ++
>>> net/sched/cls_flower.c | 134 ++++++++++++++++++++++++++++++++++++++++--
>>> 2 files changed, 132 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>>> index 401d0c1..b569308 100644
>>> --- a/include/uapi/linux/pkt_cls.h
>>> +++ b/include/uapi/linux/pkt_cls.h
>>> @@ -405,6 +405,11 @@ enum {
>>> TCA_FLOWER_KEY_UDP_SRC, /* be16 */
>>> TCA_FLOWER_KEY_UDP_DST, /* be16 */
>>>
>>> + TCA_FLOWER_KEY_PORT_SRC_MIN, /* be16 */
>>> + TCA_FLOWER_KEY_PORT_SRC_MAX, /* be16 */
>>> + TCA_FLOWER_KEY_PORT_DST_MIN, /* be16 */
>>> + TCA_FLOWER_KEY_PORT_DST_MAX, /* be16 */
>>> +
>>> TCA_FLOWER_FLAGS,
>>> TCA_FLOWER_KEY_VLAN_ID, /* be16 */
>>> TCA_FLOWER_KEY_VLAN_PRIO, /* u8 */
>>> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>>> index 9aada2d..5f135f0 100644
>>> --- a/net/sched/cls_flower.c
>>> +++ b/net/sched/cls_flower.c
>>> @@ -55,6 +55,9 @@ struct fl_flow_key {
>>> struct flow_dissector_key_ip ip;
>>> struct flow_dissector_key_ip enc_ip;
>>> struct flow_dissector_key_enc_opts enc_opts;
>>> +
>>> + struct flow_dissector_key_ports tp_min;
>>> + struct flow_dissector_key_ports tp_max;
>>> } __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
>>>
>>> struct fl_flow_mask_range {
>>> @@ -103,6 +106,11 @@ struct cls_fl_filter {
>>> struct net_device *hw_dev;
>>> };
>>>
>>> +enum fl_endpoint {
>>> + FLOWER_ENDPOINT_DST,
>>> + FLOWER_ENDPOINT_SRC
>>> +};
>>> +
>>> static const struct rhashtable_params mask_ht_params = {
>>> .key_offset = offsetof(struct fl_flow_mask, key),
>>> .key_len = sizeof(struct fl_flow_key),
>>> @@ -179,11 +187,86 @@ static void fl_clear_masked_range(struct fl_flow_key *key,
>>> memset(fl_key_get_start(key, mask), 0, fl_mask_range(mask));
>>> }
>>>
>>> +static int fl_range_compare_params(struct cls_fl_filter *filter,
>>> + struct fl_flow_key *key,
>>> + struct fl_flow_key *mkey,
>>> + enum fl_endpoint endpoint)
>>> +{
>>> + __be16 min_mask, max_mask, min_val, max_val;
>>> +
>>> + if (endpoint == FLOWER_ENDPOINT_DST) {
>>> + min_mask = htons(filter->mask->key.tp_min.dst);
>>> + max_mask = htons(filter->mask->key.tp_max.dst);
>>> + min_val = htons(filter->key.tp_min.dst);
>>> + max_val = htons(filter->key.tp_max.dst);
>>> +
>>> + if (min_mask && max_mask) {
>>> + if (htons(key->tp.dst) < min_val ||
>>> + htons(key->tp.dst) > max_val)
>>> + return -1;
>>> +
>>> + /* skb does not have min and max values */
>>> + mkey->tp_min.dst = filter->mkey.tp_min.dst;
>>> + mkey->tp_max.dst = filter->mkey.tp_max.dst;
>>> + }
>>> + } else {
>>> + min_mask = htons(filter->mask->key.tp_min.src);
>>> + max_mask = htons(filter->mask->key.tp_max.src);
>>> + min_val = htons(filter->key.tp_min.src);
>>> + max_val = htons(filter->key.tp_max.src);
>>> +
>>> + if (min_mask && max_mask) {
>>> + if (htons(key->tp.src) < min_val ||
>>> + htons(key->tp.src) > max_val)
>>> + return -1;
>>> +
>>> + /* skb does not have min and max values */
>>> + mkey->tp_min.src = filter->mkey.tp_min.src;
>>> + mkey->tp_max.src = filter->mkey.tp_max.src;
>>> + }
>>
>> You basically have 2 functions in 1 here. Just have 2 functions:
>> fl_port_range_dst_cmp()
>> and
>> fl_port_range_src_cmp()
>>
>> And avoid the "endpoint enum.
>> Also, as you return -1 or 0, just make it bool.
>>
>
>Makes sense. Will do.
>
>>
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static struct cls_fl_filter *fl_lookup_range(struct fl_flow_mask *mask,
>>> + struct fl_flow_key *mkey,
>>> + struct fl_flow_key *key)
>>> +{
>>> + struct cls_fl_filter *filter, *f;
>>> + int ret;
>>> +
>>> + list_for_each_entry_rcu(filter, &mask->filters, list) {
>>> + ret = fl_range_compare_params(filter, key, mkey,
>>> + FLOWER_ENDPOINT_DST);
>>> + if (ret < 0)
>>> + continue;
>>> +
>>> + ret = fl_range_compare_params(filter, key, mkey,
>>> + FLOWER_ENDPOINT_SRC);
>>> + if (ret < 0)
>>> + continue;
>>> +
>>> + f = rhashtable_lookup_fast(&mask->ht,
>>> + fl_key_get_start(mkey, mask),
>>> + mask->filter_ht_params);
>>> + if (f)
>>> + return f;
>>> + }
>>> + return NULL;
>>> +}
>>> +
>>> static struct cls_fl_filter *fl_lookup(struct fl_flow_mask *mask,
>>> - struct fl_flow_key *mkey)
>>> + struct fl_flow_key *mkey,
>>> + struct fl_flow_key *key, bool is_skb)
>>> {
>>> - return rhashtable_lookup_fast(&mask->ht, fl_key_get_start(mkey, mask),
>>> - mask->filter_ht_params);
>>> + if ((!(mask->key.tp_min.dst && mask->key.tp_max.dst) &&
>>> + !(mask->key.tp_min.src && mask->key.tp_max.src)) || !is_skb) {
>>
>> Would be probably good to have a dedicated bit to check for and decide
>> if you do normal/range lookup. This is fast path.
>>
>
>Will fix in v2.
>
>>
>>> + return rhashtable_lookup_fast(&mask->ht,
>>
>> Remove double space ^^
>>
>
>Will fix in v2.
>
>>
>>> + fl_key_get_start(mkey, mask),
>>> + mask->filter_ht_params);
>>> + }
>>> + /* Classify based on range */
>>> + return fl_lookup_range(mask, mkey, key);
>>> }
>>>
>>> static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>>> @@ -207,8 +290,8 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>>> skb_flow_dissect(skb, &mask->dissector, &skb_key, 0);
>>>
>>> fl_set_masked_key(&skb_mkey, &skb_key, mask);
>>> + f = fl_lookup(mask, &skb_mkey, &skb_key, true);
>>>
>>> - f = fl_lookup(mask, &skb_mkey);
>>> if (f && !tc_skip_sw(f->flags)) {
>>> *res = f->res;
>>> return tcf_exts_exec(skb, &f->exts, res);
>>> @@ -909,6 +992,23 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
>>> sizeof(key->arp.tha));
>>> }
>>>
>>> + if (key->basic.ip_proto == IPPROTO_TCP ||
>>> + key->basic.ip_proto == IPPROTO_UDP ||
>>> + key->basic.ip_proto == IPPROTO_SCTP) {
>>> + fl_set_key_val(tb, &key->tp_min.dst,
>>> + TCA_FLOWER_KEY_PORT_DST_MIN, &mask->tp_min.dst,
>>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_min.dst));
>>> + fl_set_key_val(tb, &key->tp_max.dst,
>>> + TCA_FLOWER_KEY_PORT_DST_MAX, &mask->tp_max.dst,
>>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_max.dst));
>>> + fl_set_key_val(tb, &key->tp_min.src,
>>> + TCA_FLOWER_KEY_PORT_SRC_MIN, &mask->tp_min.src,
>>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_min.src));
>>> + fl_set_key_val(tb, &key->tp_max.src,
>>> + TCA_FLOWER_KEY_PORT_SRC_MAX, &mask->tp_max.src,
>>> + TCA_FLOWER_UNSPEC, sizeof(key->tp_max.src));
>>> + }
>>> +
>>> if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
>>> tb[TCA_FLOWER_KEY_ENC_IPV4_DST]) {
>>> key->enc_control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
>>> @@ -1026,8 +1126,7 @@ static void fl_init_dissector(struct flow_dissector *dissector,
>>> FLOW_DISSECTOR_KEY_IPV4_ADDRS, ipv4);
>>> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>>> FLOW_DISSECTOR_KEY_IPV6_ADDRS, ipv6);
>>> - FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>>> - FLOW_DISSECTOR_KEY_PORTS, tp);
>>> + FL_KEY_SET(keys, cnt, FLOW_DISSECTOR_KEY_PORTS, tp);
>>> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>>> FLOW_DISSECTOR_KEY_IP, ip);
>>> FL_KEY_SET_IF_MASKED(mask, keys, cnt,
>>> @@ -1227,7 +1326,7 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
>>> goto errout_idr;
>>>
>>> if (!tc_skip_sw(fnew->flags)) {
>>> - if (!fold && fl_lookup(fnew->mask, &fnew->mkey)) {
>>> + if (!fold && fl_lookup(fnew->mask, &fnew->mkey, NULL, false)) {
>>
>>
>> I don't undestand why do you need the "is_skb" arg here. Could you
>> please explain?
>>
>> Thanks!
>>
>
>The reason to keep the 'is_skb' arg is because, fl_lookup is called in
>two cases, one for skb classification and another for checking if a
>filter exists every-time a new filter is added. In case of skb
>classification, we need to go through the range-comparator to decide if
>the skb's port-value falls within the range-filter's min and max limits.
>In case of filter validation, the range-filter that we are trying to add
>will have min and max values, and we are validating it against other
>range-filters with min and max values. So, rhashtable lookup will
>suffice here and there is no need to go through the range-comparator in
>this case. In the above code, we are validating if a range-filter
>exists, so 'is_skb' is false.
Got it. In that case, please just have a helper:
static struct cls_fl_filter *__fl_lookup(struct fl_flow_mask *mask,
struct fl_flow_key *mkey)
{
return rhashtable_lookup_fast(&mask->ht, fl_key_get_start(mkey, mask),
mask->filter_ht_params);
}
Call this helper from both fl_lookup() and fl_change()
>
>>
>>> err = -EEXIST;
>>> goto errout_mask;
>>> }
>>> @@ -1800,6 +1899,27 @@ static int fl_dump_key(struct sk_buff *skb, struct net *net,
>>> sizeof(key->arp.tha))))
>>> goto nla_put_failure;
>>>
>>> + if ((key->basic.ip_proto == IPPROTO_TCP ||
>>> + key->basic.ip_proto == IPPROTO_UDP ||
>>> + key->basic.ip_proto == IPPROTO_SCTP) &&
>>> + (fl_dump_key_val(skb, &key->tp_min.dst,
>>> + TCA_FLOWER_KEY_PORT_DST_MIN,
>>> + &mask->tp_min.dst, TCA_FLOWER_UNSPEC,
>>> + sizeof(key->tp_min.dst)) ||
>>> + fl_dump_key_val(skb, &key->tp_max.dst,
>>> + TCA_FLOWER_KEY_PORT_DST_MAX,
>>> + &mask->tp_max.dst, TCA_FLOWER_UNSPEC,
>>> + sizeof(key->tp_max.dst)) ||
>>> + fl_dump_key_val(skb, &key->tp_min.src,
>>> + TCA_FLOWER_KEY_PORT_SRC_MIN,
>>> + &mask->tp_min.src, TCA_FLOWER_UNSPEC,
>>> + sizeof(key->tp_min.src)) ||
>>> + fl_dump_key_val(skb, &key->tp_max.src,
>>> + TCA_FLOWER_KEY_PORT_SRC_MAX,
>>> + &mask->tp_max.src, TCA_FLOWER_UNSPEC,
>>> + sizeof(key->tp_max.src))))
>>> + goto nla_put_failure;
>>> +
>>> if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
>>> (fl_dump_key_val(skb, &key->enc_ipv4.src,
>>> TCA_FLOWER_KEY_ENC_IPV4_SRC, &mask->enc_ipv4.src,
>>>
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ti: cpsw: don't flush mcast entries while switch promisc mode
From: Grygorii Strashko @ 2018-10-19 17:23 UTC (permalink / raw)
To: davem, linux-omap, netdev, linux-kernel
In-Reply-To: <20181019120408.GA3909@khorivan>
On 10/19/18 7:04 AM, Ivan Khoronzhuk wrote:
> On Thu, Oct 18, 2018 at 07:03:06PM -0500, Grygorii Strashko wrote:
>>
>>
>> On 10/18/18 1:00 PM, Ivan Khoronzhuk wrote:
>>> No need now to flush mcast entries in switch mode while toggling to
>>> promiscuous mode. It's not needed as vlan reg_mcast = ALL_PORTS
>>> and mcast/vlan ports = ALL_PORTS, the same happening for vlan
>>> unreg_mcast, it's set to ALL_PORT_MASK just after calling promisc
>>> mode routine by calling set allmulti. I suppose main reason to flush
>>> them is to use unreg_mcast to receive all to host port. Thus, now, all
>>> mcast packets are received anyway and no reason to flush mcast entries
>>> unsafely, as they were synced with __dev_mc_sync() previously and are
>>> not restored. Another way is to _dev_mc_unsync() them, but no need.
>>
>> User have possibility to add additional mcast entries or edit existing
>> in switch-mode, which is now done using custom tool. So, Host in promisc
>> mode will not receive packets for mcast address X if port mask for this
>> addr set to (ALL_PORTS - HOST_PORT). Am I missing smth?
>
> I didn't take into account the custom tool changing entries directly,
> but even in this case there is at least a couple of interesting
> questions:
>
> 1) Before the patch applied only several days ago -
> 5da1948969bc1991920987ce4361ea56046e5a98
> "ti: cpsw: fix lost of mcast packets while rx_mode update"
> It was impossible to do correctly anyway, as all mcast entries not
> in the mc list were flushed (after rx_mode cb), by:
> cpsw_ale_flush_multicast(cpsw->ale, ALE_ALL_PORTS, vid);
> and those in mc, rewritten by adding them back in corrected form.
> ... or this cb was not supposed to be called at all ...
It's not allowed to manipulate ALE table in dual_mac mode, so your
patches are safe in dual_mac mode. For switch-mode (unless we move
forward with switch dev) standard linux interfaces allows create
default mcast entries which then (if required) corrected using custom
tool now.
>
> 2) What is the reason to add mcast switch entires
> (ALL_PORTS - HOST_PORT) if its function is added anyway by
> unreq_mcast & (ALL_PORTS - HOST_PORT) ?
> So, doesn't matter it's added or not - it will work :-|.
because in switch mode not all traffic directed to the Host port -
only in promisc mode. Reason safety and performance - Host should not
receive traffic which is not designated for it.
promiscuous in switch mode:
- disables learning
- enables unicast flooding to Host port
- enables unregistered multi-cast flooding to the Host port
In other words, CPSW will continue forwarding packets between P1&P2, but
also will "duplicate" packets to Host port. This will work only for
vlans which have host port as member.
>
> 3) Even so, toggling promisc mode will clear all these changes anyway,
> even I will call _dev_mc_unsync() after flushing them.
there can be records which are not under control of Linux now.
>
> 4) If user can tune ALE table by hand, what stops him do it after moving
> to promisc mode, seems he knows what he's doing?
>
> 5) It could be possible only for not default vlan entries, but mcast
> vlan support is not supported yet. Who is gona restore those
> entries after promisc off?
>
> This behaviour is arguable, and flushing mcast entries can bring more
> issues then leaving. For me it doesn't matter, I can archive the same
> by adding after flush one line, it's even shorter:
> __dev_mc_unsync(priv->ndev, NULL);
Again, unless we move forward with switch dev you can't assume that
Linux stack has full control over ALE table. Sry, hence this patch is
not a fix and can introduce changes in current behavior and cause
regression reports - NACK.
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v3 0/2] phy: ocelot-serdes: fix out-of-bounds read
From: Gustavo A. R. Silva @ 2018-10-19 9:18 UTC (permalink / raw)
To: linux-kernel
Cc: Rob Herring, Mark Rutland, devicetree, Kishon Vijay Abraham I,
David S. Miller, Quentin Schulz, netdev, Gustavo A. R. Silva
This patchset aims to fix an out-of-bounds bug in
the phy-ocelot-serdes driver.
Currently, there is an out-of-bounds read on array ctrl->phys,
once variable i reaches the maximum array size of SERDES_MAX
in the for loop.
Quentin Schulz pointed out that SERDES_MAX is a valid value to
index ctrl->phys. So, I updated SERDES_MAX to be SERDES6G_MAX + 1
in include/dt-bindings/phy/phy-ocelot-serdes.h.
Then I changed the condition in the for loop from
i <= SERDES_MAX to i < SERDES_MAX in order to
complete the fix.
The reason I'm sending this fix as series is because
checkpatch reported an error when I first tried to
integrate the whole solution into a singe patch. So,
changes to dt-bindings should be sent as a separate
patch.
Thanks!
Changes in v3:
- Post the series to netdev, so Dave can take it.
Changes in v2:
- Send the whole series to Kishon Vijay Abraham I, so it
can be taken into the PHY tree.
- Add Quentin's Reviewed-by to commit log in both patches.
Gustavo A. R. Silva (2):
dt-bindings: phy: Update SERDES_MAX to be SERDES_MAX + 1
phy: ocelot-serdes: fix out-of-bounds read
drivers/phy/mscc/phy-ocelot-serdes.c | 4 ++--
include/dt-bindings/phy/phy-ocelot-serdes.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: netconsole warning in 4.19.0-rc7
From: David Miller @ 2018-10-19 17:45 UTC (permalink / raw)
To: davej; +Cc: mroos, xiyou.wangcong, linux-kernel, netdev
In-Reply-To: <20181019134704.ky2vqeij6m77qrpg@codemonkey.org.uk>
From: Dave Jones <davej@codemonkey.org.uk>
Date: Fri, 19 Oct 2018 09:47:04 -0400
> On Fri, Oct 19, 2018 at 12:51:38PM +0300, Meelis Roos wrote:
> > > > > I took another look at that error path. Turns out this is all we need I
> > > > > think..
> > > >
> > > > With this patch applied on top of 4.19-rc8, I stll get the warning:
> > > >
> > > > [ 13.722919] WARNING: CPU: 0 PID: 0 at kernel/softirq.c:168 __local_bh_enable_ip+0x2e/0x44
> > >
> > > It's going to be a couple days before I get chance to get back to this.
> > > Did the previous patch in this thread (without the _bh) fare any better?
> >
> > Tried it with rcu_read_unlock() instead, still the same.
>
> Ok, this is going to take more time than I have. DaveM, do you want
> to revert 6fe9487892b32cb1c8b8b0d552ed7222a527fe30, or do you want a
> patch doing the same ?
>
> That'll bring back the rcu warning, but fewer people were complaining
> about that than this new issue..
I'll revert.
Thanks Dave.
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] tools, perf: use smp_{rmb,mb} barriers instead of {rmb,mb}
From: Peter Zijlstra @ 2018-10-19 9:44 UTC (permalink / raw)
To: Daniel Borkmann
Cc: alexei.starovoitov, paulmck, will.deacon, acme, yhs,
john.fastabend, netdev
In-Reply-To: <df1da9c7-f9b4-a482-0bbc-a6455b57a476@iogearbox.net>
On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
> diff --git a/tools/include/linux/ring_buffer.h b/tools/include/linux/ring_buffer.h
> new file mode 100644
> index 0000000..48200e0
> --- /dev/null
> +++ b/tools/include/linux/ring_buffer.h
> @@ -0,0 +1,69 @@
> +#ifndef _TOOLS_LINUX_RING_BUFFER_H_
> +#define _TOOLS_LINUX_RING_BUFFER_H_
> +
> +#include <linux/compiler.h>
> +#include <asm/barrier.h>
> +
> +/*
> + * Below barriers pair as follows (kernel/events/ring_buffer.c):
> + *
> + * Since the mmap() consumer (userspace) can run on a different CPU:
> + *
> + * kernel user
> + *
> + * if (LOAD ->data_tail) { LOAD ->data_head
> + * (A) smp_rmb() (C)
> + * STORE $data LOAD $data
> + * smp_wmb() (B) smp_mb() (D)
> + * STORE ->data_head STORE ->data_tail
> + * }
> + *
> + * Where A pairs with D, and B pairs with C.
> + *
> + * In our case A is a control dependency that separates the load
> + * of the ->data_tail and the stores of $data. In case ->data_tail
> + * indicates there is no room in the buffer to store $data we do not.
> + *
> + * D needs to be a full barrier since it separates the data READ
> + * from the tail WRITE.
> + *
> + * For B a WMB is sufficient since it separates two WRITEs, and for
> + * C an RMB is sufficient since it separates two READs.
> + */
> +
> +/*
> + * Note, instead of B, C, D we could also use smp_store_release()
> + * in B and D as well as smp_load_acquire() in C. However, this
> + * optimization makes sense not for all architectures since it
> + * would resolve into READ_ONCE() + smp_mb() pair for smp_load_acquire()
> + * and smp_mb() + WRITE_ONCE() pair for smp_store_release(), thus
> + * for those smp_wmb() in B and smp_rmb() in C would still be less
> + * expensive. For the case of D this has either the same cost or
> + * is less expensive. For example, due to TSO (total store order),
> + * x86 can avoid the CPU barrier entirely.
> + */
> +
> +static inline u64 ring_buffer_read_head(struct perf_event_mmap_page *base)
> +{
> +/*
> + * Architectures where smp_load_acquire() does not fallback to
> + * READ_ONCE() + smp_mb() pair.
> + */
> +#if defined(__x86_64__) || defined(__aarch64__) || defined(__powerpc64__) || \
> + defined(__ia64__) || defined(__sparc__) && defined(__arch64__)
> + return smp_load_acquire(&base->data_head);
> +#else
> + u64 head = READ_ONCE(base->data_head);
> +
> + smp_rmb();
> + return head;
> +#endif
> +}
> +
> +static inline void ring_buffer_write_tail(struct perf_event_mmap_page *base,
> + u64 tail)
> +{
> + smp_store_release(&base->data_tail, tail);
> +}
> +
> +#endif /* _TOOLS_LINUX_RING_BUFFER_H_ */
(for the whole patch, but in particular the above)
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
^ permalink raw reply
* Improving accuracy of PHC readings
From: Miroslav Lichvar @ 2018-10-19 9:51 UTC (permalink / raw)
To: netdev; +Cc: Richard Cochran, Keller, Jacob E
I think there might be a way how we could significantly improve
accuracy of synchronization between the system clock and a PTP
hardware clock, at least with some network drivers.
Currently, the PTP_SYS_OFFSET ioctl reads the system clock, reads the
PHC using the gettime64 function of the driver, and reads the system
clock again. The ioctl can repeat this to provide multiple readings to
the user space.
phc2sys (or another program synchronizing the system clock to the PHC)
assumes the PHC timestamps were captured in the middle between the two
closest system clock timestamps.
The trouble is that gettime64 typically reads multiple (2-3) registers
and the timestamp is latched on the first one, so the assumption about
middle point is wrong. There is an asymmetry, even if the delays on
the PCIe bus are perfectly symmetric.
A solution to this would be a new driver function that wraps the
latching register read with readings of the system clock and return
three timestamps instead of one. For example:
ktime_get_real_ts64(&sys_ts1);
IXGBE_READ_REG(hw, IXGBE_SYSTIMR);
ktime_get_real_ts64(&sys_ts2);
phc_ts.tv_nsec = IXGBE_READ_REG(hw, IXGBE_SYSTIML);
phc_ts.tv_sec = IXGBE_READ_REG(hw, IXGBE_SYSTIMH);
The extra timestamp doesn't fit the API of the PTP_SYS_OFFSET ioctl,
so it would need to shift the timestamp it returns by the missing
intervals (assuming the frequency offset between the PHC and system
clock is small), or a new ioctl could be introduced that would return
all timestamps in an array looking like this:
[sys, phc, sys, sys, phc, sys, ...]
This should significantly improve the accuracy of the synchronization,
reduce the uncertainty in the readings to less than a half or third,
and also reduce the jitter as there are fewer register reads sensitive
to the PCIe delay.
What do you think?
--
Miroslav Lichvar
^ permalink raw reply
* [PATCH] mISDN: Fix type of switch control variable in ctrl_teimanager
From: Nathan Chancellor @ 2018-10-19 18:00 UTC (permalink / raw)
To: Karsten Keil, David S. Miller; +Cc: netdev, linux-kernel, Nathan Chancellor
Clang warns (trimmed for brevity):
drivers/isdn/mISDN/tei.c:1193:7: warning: overflow converting case value
to switch condition type (2147764552 to 18446744071562348872) [-Wswitch]
case IMHOLD_L1:
^
drivers/isdn/mISDN/tei.c:1187:7: warning: overflow converting case value
to switch condition type (2147764550 to 18446744071562348870) [-Wswitch]
case IMCLEAR_L2:
^
2 warnings generated.
The root cause is that the _IOC macro can generate really large numbers,
which don't find into type int. My research into how GCC and Clang are
handling this at a low level didn't prove fruitful and surveying the
kernel tree shows that aside from here and a few places in the scsi
subsystem, everything that uses _IOC is at least of type 'unsigned int'.
Make that change here because as nothing in this function cares about
the signedness of the variable and it removes ambiguity, which is never
good when dealing with compilers.
While we're here, remove the unnecessary local variable ret (just return
-EINVAL and 0 directly).
Link: https://github.com/ClangBuiltLinux/linux/issues/67
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/isdn/mISDN/tei.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/mISDN/tei.c b/drivers/isdn/mISDN/tei.c
index 12d9e5f4beb1..58635b5f296f 100644
--- a/drivers/isdn/mISDN/tei.c
+++ b/drivers/isdn/mISDN/tei.c
@@ -1180,8 +1180,7 @@ static int
ctrl_teimanager(struct manager *mgr, void *arg)
{
/* currently we only have one option */
- int *val = (int *)arg;
- int ret = 0;
+ unsigned int *val = (unsigned int *)arg;
switch (val[0]) {
case IMCLEAR_L2:
@@ -1197,9 +1196,9 @@ ctrl_teimanager(struct manager *mgr, void *arg)
test_and_clear_bit(OPTION_L1_HOLD, &mgr->options);
break;
default:
- ret = -EINVAL;
+ return -EINVAL;
}
- return ret;
+ return 0;
}
/* This function does create a L2 for fixed TEI in NT Mode */
--
2.19.1
^ permalink raw reply related
* Re: [PATCH] selftests/bpf: add missing executables to .gitignore
From: Y Song @ 2018-10-19 18:00 UTC (permalink / raw)
To: Anders Roxell
Cc: Alexei Starovoitov, Daniel Borkmann, Shuah Khan, netdev, LKML,
linux-kselftest
In-Reply-To: <20181019142436.2955-1-anders.roxell@linaro.org>
On Fri, Oct 19, 2018 at 7:25 AM Anders Roxell <anders.roxell@linaro.org> wrote:
>
> Fixes: 371e4fcc9d96 ("selftests/bpf: cgroup local storage-based network counters")
> Fixes: 370920c47b26 ("selftests/bpf: Test libbpf_{prog,attach}_type_by_name")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* [PATCH] bpf/test_run: Add braces to initialization in bpf_prog_test_run_skb
From: Nathan Chancellor @ 2018-10-19 18:26 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: netdev, linux-kernel, Nathan Chancellor
Clang warns:
net/bpf/test_run.c:120:20: error: suggest braces around initialization
of subobject [-Werror,-Wmissing-braces]
struct sock sk = {0};
^
{}
Add the braces to properly initialize all subobjects.
Fixes: 75079847e9d0 ("bpf: add tests for direct packet access from CGROUP_SKB")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
net/bpf/test_run.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index 8dccac305268..65e049c61a7a 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -117,7 +117,7 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
u32 retval, duration;
int hh_len = ETH_HLEN;
struct sk_buff *skb;
- struct sock sk = {0};
+ struct sock sk = { { {0} } };
void *data;
int ret;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH bpf-next 2/3] tools, perf: use smp_{rmb,mb} barriers instead of {rmb,mb}
From: Daniel Borkmann @ 2018-10-19 10:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: alexei.starovoitov, paulmck, will.deacon, acme, yhs,
john.fastabend, netdev
In-Reply-To: <20181019094417.GE3121@hirez.programming.kicks-ass.net>
On 10/19/2018 11:44 AM, Peter Zijlstra wrote:
> On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
>> diff --git a/tools/include/linux/ring_buffer.h b/tools/include/linux/ring_buffer.h
>> new file mode 100644
>> index 0000000..48200e0
>> --- /dev/null
>> +++ b/tools/include/linux/ring_buffer.h
>> @@ -0,0 +1,69 @@
>> +#ifndef _TOOLS_LINUX_RING_BUFFER_H_
>> +#define _TOOLS_LINUX_RING_BUFFER_H_
>> +
>> +#include <linux/compiler.h>
>> +#include <asm/barrier.h>
>> +
>> +/*
>> + * Below barriers pair as follows (kernel/events/ring_buffer.c):
>> + *
>> + * Since the mmap() consumer (userspace) can run on a different CPU:
>> + *
>> + * kernel user
>> + *
>> + * if (LOAD ->data_tail) { LOAD ->data_head
>> + * (A) smp_rmb() (C)
>> + * STORE $data LOAD $data
>> + * smp_wmb() (B) smp_mb() (D)
>> + * STORE ->data_head STORE ->data_tail
>> + * }
>> + *
>> + * Where A pairs with D, and B pairs with C.
>> + *
>> + * In our case A is a control dependency that separates the load
>> + * of the ->data_tail and the stores of $data. In case ->data_tail
>> + * indicates there is no room in the buffer to store $data we do not.
>> + *
>> + * D needs to be a full barrier since it separates the data READ
>> + * from the tail WRITE.
>> + *
>> + * For B a WMB is sufficient since it separates two WRITEs, and for
>> + * C an RMB is sufficient since it separates two READs.
>> + */
>> +
>> +/*
>> + * Note, instead of B, C, D we could also use smp_store_release()
>> + * in B and D as well as smp_load_acquire() in C. However, this
>> + * optimization makes sense not for all architectures since it
>> + * would resolve into READ_ONCE() + smp_mb() pair for smp_load_acquire()
>> + * and smp_mb() + WRITE_ONCE() pair for smp_store_release(), thus
>> + * for those smp_wmb() in B and smp_rmb() in C would still be less
>> + * expensive. For the case of D this has either the same cost or
>> + * is less expensive. For example, due to TSO (total store order),
>> + * x86 can avoid the CPU barrier entirely.
>> + */
>> +
>> +static inline u64 ring_buffer_read_head(struct perf_event_mmap_page *base)
>> +{
>> +/*
>> + * Architectures where smp_load_acquire() does not fallback to
>> + * READ_ONCE() + smp_mb() pair.
>> + */
>> +#if defined(__x86_64__) || defined(__aarch64__) || defined(__powerpc64__) || \
>> + defined(__ia64__) || defined(__sparc__) && defined(__arch64__)
>> + return smp_load_acquire(&base->data_head);
>> +#else
>> + u64 head = READ_ONCE(base->data_head);
>> +
>> + smp_rmb();
>> + return head;
>> +#endif
>> +}
>> +
>> +static inline void ring_buffer_write_tail(struct perf_event_mmap_page *base,
>> + u64 tail)
>> +{
>> + smp_store_release(&base->data_tail, tail);
>> +}
>> +
>> +#endif /* _TOOLS_LINUX_RING_BUFFER_H_ */
>
> (for the whole patch, but in particular the above)
>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Great, thanks a lot, Peter! Will flush out v2 in a bit.
^ permalink raw reply
* Re: [PATCH] bpf/test_run: Add braces to initialization in bpf_prog_test_run_skb
From: Eric Dumazet @ 2018-10-19 18:46 UTC (permalink / raw)
To: Nathan Chancellor, Alexei Starovoitov, Daniel Borkmann
Cc: netdev, linux-kernel
In-Reply-To: <20181019182649.24301-1-natechancellor@gmail.com>
On 10/19/2018 11:26 AM, Nathan Chancellor wrote:
> Clang warns:
>
> net/bpf/test_run.c:120:20: error: suggest braces around initialization
> of subobject [-Werror,-Wmissing-braces]
> struct sock sk = {0};
> ^
> {}
>
> Add the braces to properly initialize all subobjects.
>
> Fixes: 75079847e9d0 ("bpf: add tests for direct packet access from CGROUP_SKB")
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> net/bpf/test_run.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index 8dccac305268..65e049c61a7a 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -117,7 +117,7 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> u32 retval, duration;
> int hh_len = ETH_HLEN;
> struct sk_buff *skb;
> - struct sock sk = {0};
> + struct sock sk = { { {0} } };
> void *data;
> int ret;
>
>
Strange, I thought this patch was still under discussion.
Has an old version of it being merged somewhere ?
^ permalink raw reply
* Re: [PATCH] bpf/test_run: Add braces to initialization in bpf_prog_test_run_skb
From: Alexei Starovoitov @ 2018-10-19 18:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: natechancellor, Alexei Starovoitov, Daniel Borkmann,
Network Development, LKML
In-Reply-To: <3e2e5343-3ead-5b4d-758d-14f04183b39e@gmail.com>
On Fri, Oct 19, 2018 at 11:46 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 10/19/2018 11:26 AM, Nathan Chancellor wrote:
> > Clang warns:
> >
> > net/bpf/test_run.c:120:20: error: suggest braces around initialization
> > of subobject [-Werror,-Wmissing-braces]
> > struct sock sk = {0};
> > ^
> > {}
> >
> > Add the braces to properly initialize all subobjects.
> >
> > Fixes: 75079847e9d0 ("bpf: add tests for direct packet access from CGROUP_SKB")
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> > net/bpf/test_run.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> > index 8dccac305268..65e049c61a7a 100644
> > --- a/net/bpf/test_run.c
> > +++ b/net/bpf/test_run.c
> > @@ -117,7 +117,7 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> > u32 retval, duration;
> > int hh_len = ETH_HLEN;
> > struct sk_buff *skb;
> > - struct sock sk = {0};
> > + struct sock sk = { { {0} } };
> > void *data;
> > int ret;
> >
> >
>
> Strange, I thought this patch was still under discussion.
> Has an old version of it being merged somewhere ?
merged and reverted. This patch is not necessary.
^ permalink raw reply
* Re: [PATCH] bpf/test_run: Add braces to initialization in bpf_prog_test_run_skb
From: Nathan Chancellor @ 2018-10-19 19:03 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Eric Dumazet, Alexei Starovoitov, Daniel Borkmann,
Network Development, LKML
In-Reply-To: <CAADnVQKyaU=kPZN5+Bi=NJDGh6AMV0HKZoDg+tzLGQdq+L8xaQ@mail.gmail.com>
On Fri, Oct 19, 2018 at 11:47:34AM -0700, Alexei Starovoitov wrote:
> On Fri, Oct 19, 2018 at 11:46 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >
> >
> > On 10/19/2018 11:26 AM, Nathan Chancellor wrote:
> > > Clang warns:
> > >
> > > net/bpf/test_run.c:120:20: error: suggest braces around initialization
> > > of subobject [-Werror,-Wmissing-braces]
> > > struct sock sk = {0};
> > > ^
> > > {}
> > >
> > > Add the braces to properly initialize all subobjects.
> > >
> > > Fixes: 75079847e9d0 ("bpf: add tests for direct packet access from CGROUP_SKB")
> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > > ---
> > > net/bpf/test_run.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> > > index 8dccac305268..65e049c61a7a 100644
> > > --- a/net/bpf/test_run.c
> > > +++ b/net/bpf/test_run.c
> > > @@ -117,7 +117,7 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> > > u32 retval, duration;
> > > int hh_len = ETH_HLEN;
> > > struct sk_buff *skb;
> > > - struct sock sk = {0};
> > > + struct sock sk = { { {0} } };
> > > void *data;
> > > int ret;
> > >
> > >
> >
> > Strange, I thought this patch was still under discussion.
> > Has an old version of it being merged somewhere ?
Looks like it made its way into -next in the 20181019 version, which
is what I am working off of.
>
> merged and reverted. This patch is not necessary.
Thank you for the heads up and sorry for the noise!
Nathan
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] tools, perf: use smp_{rmb,mb} barriers instead of {rmb,mb}
From: Will Deacon @ 2018-10-19 11:02 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Peter Zijlstra, paulmck, acme, yhs,
john.fastabend, netdev
In-Reply-To: <20181019035340.ahjocmdj2o2zam4m@ast-mbp.dhcp.thefacebook.com>
On Thu, Oct 18, 2018 at 08:53:42PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 18, 2018 at 09:00:46PM +0200, Daniel Borkmann wrote:
> > On 10/18/2018 05:33 PM, Alexei Starovoitov wrote:
> > > On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
> > >> #endif /* _TOOLS_LINUX_ASM_IA64_BARRIER_H */
> > >> diff --git a/tools/arch/powerpc/include/asm/barrier.h b/tools/arch/powerpc/include/asm/barrier.h
> > >> index a634da0..905a2c6 100644
> > >> --- a/tools/arch/powerpc/include/asm/barrier.h
> > >> +++ b/tools/arch/powerpc/include/asm/barrier.h
> > >> @@ -27,4 +27,20 @@
> > >> #define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> > >> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> > >>
> > >> +#if defined(__powerpc64__)
> > >> +#define smp_lwsync() __asm__ __volatile__ ("lwsync" : : : "memory")
> > >> +
> > >> +#define smp_store_release(p, v) \
> > >> +do { \
> > >> + smp_lwsync(); \
> > >> + WRITE_ONCE(*p, v); \
> > >> +} while (0)
> > >> +
> > >> +#define smp_load_acquire(p) \
> > >> +({ \
> > >> + typeof(*p) ___p1 = READ_ONCE(*p); \
> > >> + smp_lwsync(); \
> > >> + ___p1; \
> > >
> > > I don't like this proliferation of asm.
> > > Why do we think that we can do better job than compiler?
> > > can we please use gcc builtins instead?
> > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> > > __atomic_load_n(ptr, __ATOMIC_ACQUIRE);
> > > __atomic_store_n(ptr, val, __ATOMIC_RELEASE);
> > > are done specifically for this use case if I'm not mistaken.
> > > I think it pays to learn what compiler provides.
> >
> > But are you sure the C11 memory model matches exact same model as kernel?
> > Seems like last time Will looked into it [0] it wasn't the case ...
>
> I'm only suggesting equivalence of __atomic_load_n(ptr, __ATOMIC_ACQUIRE)
> with kernel's smp_load_acquire().
> I've seen a bunch of user space ring buffer implementations implemented
> with __atomic_load_n() primitives.
> But let's ask experts who live in both worlds.
One thing to be wary of is if there is an implementation choice between
how to implement load-acquire and store-release for a given architecture.
In these situations, it's often important that concurrent software agrees
on the "mapping", so we'd need to be sure that (a) All userspace compilers
that we care about have compatible mappings and (b) These mappings are
compatible with the kernel code.
Will
^ permalink raw reply
* [PATCH net-next 0/7] Adds support of RAS Error Handling in HNS3 Driver
From: Salil Mehta @ 2018-10-19 19:15 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
This patch-set adds support related to RAS Error handling to the HNS3
Ethernet PF Driver. Set of errors occurred in the HNS3 hardware are
reported to the driver through the PCIe AER interface. The received
error information is then used to classify the received errors and
then decide the appropriate receovery action depending on the type
of error.
Shiju Jose (7):
net: hns3: Add PCIe AER callback error_detected
net: hns3: Add PCIe AER error recovery
net: hns3: Add support to enable and disable hw errors
net: hns3: Add enable and process common ecc errors
net: hns3: Add enable and process hw errors from IGU, EGU and NCSI
net: hns3: Add enable and process hw errors from PPP
net: hns3: Add enable and process hw errors of TM scheduler
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 3 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 50 +-
.../net/ethernet/hisilicon/hns3/hns3pf/Makefile | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 22 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 1088 ++++++++++++++++++++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 83 ++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 33 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +-
8 files changed, 1276 insertions(+), 8 deletions(-)
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
--
2.7.4
^ 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