* Re: Error when loading BPF_CGROUP_INET_EGRESS program with bpftool
From: Fejes Ferenc @ 2019-08-12 20:48 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAEf4BzZ27SnYkQ=psqxeWadLhnspojiJGQrGB0JRuPkP+GTiNQ@mail.gmail.com>
Thanks for the answer, I really appreciate it. I tried omitting
"cgroup/skb" to let libbpf guess the attach type, but I got the same
error. Really interesting, because I got the error
> libbpf: failed to load program 'cgroup_skb/egress'
wich is weird because it shows that libbpf guess the program type
correctly. So something definitely on my side - thank you for verifyng
that - I try to investigate it!
Ferenc
Andrii Nakryiko <andrii.nakryiko@gmail.com> ezt írta (időpont: 2019.
aug. 12., H, 20:27):
>
> On Mon, Aug 12, 2019 at 1:59 AM Fejes Ferenc <fejes@inf.elte.hu> wrote:
> >
> > Greetings!
> >
> > I found a strange error when I tried to load a BPF_CGROUP_INET_EGRESS
> > prog with bpftool. Loading the same program from C code with
> > bpf_prog_load_xattr works without problem.
> >
> > The error message I got:
> > bpftool prog loadall hbm_kern.o /sys/fs/bpf/hbm type cgroup/skb
>
> You need "cgroup_skb/egress" instead of "cgroup/skb" (or try just
> dropping it, bpftool will try to guess the type from program's section
> name, which would be correct in this case).
>
> > libbpf: load bpf program failed: Invalid argument
> > libbpf: -- BEGIN DUMP LOG ---
> > libbpf:
> > ; return ALLOW_PKT | REDUCE_CW;
> > 0: (b7) r0 = 3
> > 1: (95) exit
> > At program exit the register R0 has value (0x3; 0x0) should have been
> > in (0x0; 0x1)
> > processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0
> > peak_states 0 mark_read 0
> >
> > libbpf: -- END LOG --
> > libbpf: failed to load program 'cgroup_skb/egress'
> > libbpf: failed to load object 'hbm_kern.o'
> > Error: failed to load object file
> >
> >
> > My environment: 5.3-rc3 / net-next master (both producing the error).
> > Libbpf and bpftool installed from the kernel source (cleaned and
> > reinstalled when I tried a new kernel). I compiled the program with
> > Clang 8, on Ubuntu 19.10 server image, the source:
> >
> > #include <linux/bpf.h>
> > #include "bpf_helpers.h"
> >
> > #define DROP_PKT 0
> > #define ALLOW_PKT 1
> > #define REDUCE_CW 2
> >
> > SEC("cgroup_skb/egress")
> > int hbm(struct __sk_buff *skb)
> > {
> > return ALLOW_PKT | REDUCE_CW;
> > }
> > char _license[] SEC("license") = "GPL";
> >
> >
> > I also tried to trace down the bug with gdb. It seems like the
> > section_names array in libbpf.c filled with garbage, especially the
>
> I did the same, section_names appears to be correct, not sure what was
> going on in your case. The problem is that "cgroup/skb", which you
> provided on command line, overrides this section name and forces
> bpftool to guess program type as BPF_CGROUP_INET_INGRESS, which
> restricts return codes to just 0 or 1, while for
> BPF_CGROUP_INET_EGRESS i is [0, 3].
>
> > expected_attach_type fields (in my case, this contains
> > BPF_CGROUP_INET_INGRESS instead of BPF_CGROUP_INET_EGRESS).
> >
> > Thanks!
^ permalink raw reply
* Re: [PATCH] vhost: do not reference a file that does not exist
From: Enrico Granata @ 2019-08-12 20:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Enrico Granata, Linux Kernel Mailing List, mst, jasowang, kvm,
virtualization, netdev, trivial
In-Reply-To: <20190810081540.GA30426@infradead.org>
Fair enough, yeah.
I think what I found confusing was that the file had a precise
(directly actionable in a file browser, if you will) path. If it was
just listed as a filename, or a project name, it might have been more
obvious that one shouldn't expect to find it within the kernel tree
and just go look it up in your favorite search engine.
The right incantation to get your hands on that file is a web search,
not a local file navigation, and to my perception a full and seemingly
valid path pointed in the direction of doing the wrong thing.
It's not a huge deal, obviously, and it may be that I was the only one
confused by that. If so, feel free to disregard the patch.
Thanks,
- Enrico
Thanks,
- Enrico
On Sat, Aug 10, 2019 at 1:15 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Aug 07, 2019 at 05:52:55PM -0700, egranata@chromium.org wrote:
> > From: Enrico Granata <egranata@google.com>
> >
> > lguest was removed from the mainline kernel in late 2017.
> >
> > Signed-off-by: Enrico Granata <egranata@google.com>
>
> But this particular file even has an override in the script looking
> for dead references, which together with the content of the overal
> contents makes me thing the dangling reference is somewhat intentional.
^ permalink raw reply
* Re: [PATCH 0/7] Add definition for the number of standard PCI BARs
From: Denis Efremov @ 2019-08-12 21:00 UTC (permalink / raw)
To: Andrew Murray
Cc: Bjorn Helgaas, Sebastian Ott, Gerald Schaefer, H. Peter Anvin,
Giuseppe Cavallaro, Alexandre Torgue, Matt Porter,
Alexandre Bounine, Peter Jones, Bartlomiej Zolnierkiewicz,
Cornelia Huck, Alex Williamson, kvm, linux-fbdev, netdev, x86,
linux-s390, linux-pci, linux-kernel
In-Reply-To: <20190812090639.GX56241@e119886-lin.cambridge.arm.com>
On 12.08.2019 12:06, Andrew Murray wrote:
>
> Hi Denis,
Hi!
>
> You could also fix up a few cases where the number of BARs is hard coded in
> loops, e.g.
>
> drivers/pci/controller/pci-hyperv.c - look for uses of probed_bar in loops
> drivers/pci/pci.c - pci_release_selected_regions and __pci_request_selected_regions
> drivers/pci/quirks.c - quirk_alder_ioapic
>
Thanks for pointing me on that. I will take this into account in v2.
Denis
^ permalink raw reply
* Re: [PATCH v2] net: phy: at803x: stop switching phy delay config needlessly
From: David Miller @ 2019-08-12 21:02 UTC (permalink / raw)
To: git; +Cc: linux-kernel, andrew, f.fainelli, hkallweit1, netdev
In-Reply-To: <20190809112025.27482-1-git@andred.net>
From: André Draszik <git@andred.net>
Date: Fri, 9 Aug 2019 12:20:25 +0100
> This driver does a funny dance disabling and re-enabling
> RX and/or TX delays. In any of the RGMII-ID modes, it first
> disables the delays, just to re-enable them again right
> away. This looks like a needless exercise.
>
> Just enable the respective delays when in any of the
> relevant 'id' modes, and disable them otherwise.
>
> Also, remove comments which don't add anything that can't be
> seen by looking at the code.
>
> Signed-off-by: André Draszik <git@andred.net>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 04/12] net: stmmac: Add Split Header support and enable it in XGMAC cores
From: David Miller @ 2019-08-12 21:06 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <6279e35421e17256ac023227ec8cd5c8498d34d0.1565602974.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Mon, 12 Aug 2019 11:44:03 +0200
> - Add performance info (David)
Ummm...
Whilst cpu utilization is interesting, I might be mainly interested in
how this effects "networking" performance. I find it very surprising
that it isn't obvious that this is what I wanted.
Do you not do performance testing on the networking level when you
make fundamental changes to how packets are processed by the
hardware/driver?
^ permalink raw reply
* [PATCH net v2] ibmveth: Convert multicast list size for little-endian system
From: Thomas Falcon @ 2019-08-12 21:13 UTC (permalink / raw)
To: netdev; +Cc: liuhangbin, davem, joe, Thomas Falcon
The ibm,mac-address-filters property defines the maximum number of
addresses the hypervisor's multicast filter list can support. It is
encoded as a big-endian integer in the OF device tree, but the virtual
ethernet driver does not convert it for use by little-endian systems.
As a result, the driver is not behaving as it should on affected systems
when a large number of multicast addresses are assigned to the device.
Reported-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
v2: define filter size pointer as __be32 instead of unsigned int,
suggested by Joe Perches
---
drivers/net/ethernet/ibm/ibmveth.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index 77af9c2c0571..5641c00d34f2 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1643,7 +1643,7 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
struct net_device *netdev;
struct ibmveth_adapter *adapter;
unsigned char *mac_addr_p;
- unsigned int *mcastFilterSize_p;
+ __be32 *mcastFilterSize_p;
long ret;
unsigned long ret_attr;
@@ -1665,8 +1665,9 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
return -EINVAL;
}
- mcastFilterSize_p = (unsigned int *)vio_get_attribute(dev,
- VETH_MCAST_FILTER_SIZE, NULL);
+ mcastFilterSize_p = (__be32 *)vio_get_attribute(dev,
+ VETH_MCAST_FILTER_SIZE,
+ NULL);
if (!mcastFilterSize_p) {
dev_err(&dev->dev, "Can't find VETH_MCAST_FILTER_SIZE "
"attribute\n");
@@ -1683,7 +1684,7 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
adapter->vdev = dev;
adapter->netdev = netdev;
- adapter->mcastFilterSize = *mcastFilterSize_p;
+ adapter->mcastFilterSize = be32_to_cpu(*mcastFilterSize_p);
adapter->pool_config = 0;
ibmveth_init_link_settings(adapter);
--
2.16.4
^ permalink raw reply related
* Re: [PATCH v2] Documentation: virt: Fix broken reference to virt tree's index
From: Jonathan Corbet @ 2019-08-12 21:16 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, linux-kernel-mentees, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau,
Song Liu, Yonghong Song, open list:DOCUMENTATION, open list,
open list:RISC-V ARCHITECTURE,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools)
In-Reply-To: <20190809132349.GA15460@localhost>
On Fri, 9 Aug 2019 14:23:49 +0100
Sheriff Esseson <sheriffesseson@gmail.com> wrote:
> Fix broken reference to virt/index.rst.
>
> Fixes: 2f5947dfcaec ("Documentation: move Documentation/virtual to
> Documentation/virt")
>
> Signed-off-by: Sheriff Esseson <sheriffesseson@gmail.com>
Note that you should keep the "Fixes:" tag on a single line, and not put a
blank line between it and the other tags. I've fixed that up and applied
the patch, thanks.
jon
^ permalink raw reply
* [PATCH net-next 0/3] net: phy: let phy_speed_down/up support speeds >1Gbps
From: Heiner Kallweit @ 2019-08-12 21:18 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction and add needed helpers to phy-core.c
Heiner Kallweit (3):
net: phy: add __set_linkmode_max_speed
net: phy: add __phy_speed_down and phy_resolve_min_speed
net: phy: let phy_speed_down/up support speeds >1Gbps
drivers/net/phy/phy-core.c | 39 +++++++++++++++++++++++--
drivers/net/phy/phy.c | 60 ++++++++++----------------------------
include/linux/phy.h | 3 ++
3 files changed, 56 insertions(+), 46 deletions(-)
--
2.22.0
^ permalink raw reply
* Re: [PATCH v2 bpf-next] mm: mmap: increase sockets maximum memory size pgoff for 32bits
From: Andrew Morton @ 2019-08-12 21:19 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: bjorn.topel, linux-mm, xdp-newbies, netdev, bpf, linux-kernel,
ast, magnus.karlsson
In-Reply-To: <20190812124326.32146-1-ivan.khoronzhuk@linaro.org>
On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
> established already and are part of configuration interface.
>
> But for 32-bit systems, while AF_XDP socket configuration, the values
> are to large to pass maximum allowed file size verification.
> The offsets can be tuned ofc, but instead of changing existent
> interface - extend max allowed file size for sockets.
What are the implications of this? That all code in the kernel which
handles mapped sockets needs to be audited (and tested) for correctly
handling mappings larger than 4G on 32-bit machines? Has that been
done? Are we confident that we aren't introducing user-visible buggy
behaviour into unsuspecting legacy code?
Also... what are the user-visible runtime effects of this change?
Please send along a paragraph which explains this, for the changelog.
Does this patch fix some user-visible problem? If so, should be code
be backported into -stable kernels?
^ permalink raw reply
* [PATCH net] netfilter: ebtables: Fix argument order to ADD_COUNTER
From: Todd Seidelmann @ 2019-08-12 21:20 UTC (permalink / raw)
To: netdev
The ordering of arguments to the x_tables ADD_COUNTER macro
appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
and arp_tables.c).
This causes data corruption in the ebtables userspace tools
because they get incorrect packet & byte counts from the kernel.
---
net/bridge/netfilter/ebtables.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c
b/net/bridge/netfilter/ebtables.c
index c8177a8..4096d8a 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -221,7 +221,7 @@ unsigned int ebt_do_table(struct sk_buff *skb,
return NF_DROP;
}
- ADD_COUNTER(*(counter_base + i), 1, skb->len);
+ ADD_COUNTER(*(counter_base + i), skb->len, 1);
/* these should only watch: not modify, nor tell us
* what to do with the packet
@@ -959,8 +959,8 @@ static void get_counters(const struct ebt_counter
*oldcounters,
continue;
counter_base = COUNTER_BASE(oldcounters, nentries, cpu);
for (i = 0; i < nentries; i++)
- ADD_COUNTER(counters[i], counter_base[i].pcnt,
- counter_base[i].bcnt);
+ ADD_COUNTER(counters[i], counter_base[i].bcnt,
+ counter_base[i].pcnt);
}
}
@@ -1280,7 +1280,7 @@ static int do_update_counters(struct net *net,
const char *name,
/* we add to the counters of the first cpu */
for (i = 0; i < num_counters; i++)
- ADD_COUNTER(t->private->counters[i], tmp[i].pcnt, tmp[i].bcnt);
+ ADD_COUNTER(t->private->counters[i], tmp[i].bcnt, tmp[i].pcnt);
write_unlock_bh(&t->lock);
ret = 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/3] net: phy: add __set_linkmode_max_speed
From: Heiner Kallweit @ 2019-08-12 21:19 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0799ec1f-307c-25ab-0259-b8239e4e04ba@gmail.com>
We will need the functionality of __set_linkmode_max_speed also for
linkmode bitmaps other than phydev->supported. Therefore split it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-core.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 9ae3abb2d..de085f255 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -207,14 +207,15 @@ size_t phy_speeds(unsigned int *speeds, size_t size,
return count;
}
-static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
+static int __set_linkmode_max_speed(struct phy_device *phydev, u32 max_speed,
+ unsigned long *addr)
{
const struct phy_setting *p;
int i;
for (i = 0, p = settings; i < ARRAY_SIZE(settings); i++, p++) {
if (p->speed > max_speed)
- linkmode_clear_bit(p->bit, phydev->supported);
+ linkmode_clear_bit(p->bit, addr);
else
break;
}
@@ -222,6 +223,11 @@ static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
return 0;
}
+static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
+{
+ return __set_linkmode_max_speed(phydev, max_speed, phydev->supported);
+}
+
int phy_set_max_speed(struct phy_device *phydev, u32 max_speed)
{
int err;
--
2.22.0
^ permalink raw reply related
* [PATCH net-next 2/3] net: phy: add __phy_speed_down and phy_resolve_min_speed
From: Heiner Kallweit @ 2019-08-12 21:20 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0799ec1f-307c-25ab-0259-b8239e4e04ba@gmail.com>
__phy_speed_down provides most of the functionality for phy_speed_down.
It makes use of new helper phy_resolve_min_speed that is based on the
sorting of the settings[] array.
In certain cases it may be helpful to be able to exclude legacy half
duplex modes, therefore prepare phy_resolve_min_speed() for it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-core.c | 29 +++++++++++++++++++++++++++++
include/linux/phy.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index de085f255..d7331875e 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -316,6 +316,35 @@ void phy_resolve_aneg_linkmode(struct phy_device *phydev)
}
EXPORT_SYMBOL_GPL(phy_resolve_aneg_linkmode);
+static int phy_resolve_min_speed(struct phy_device *phydev, bool fdx_only)
+{
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(common);
+ int i = ARRAY_SIZE(settings);
+
+ linkmode_and(common, phydev->lp_advertising, phydev->advertising);
+
+ while (i--) {
+ if (test_bit(settings[i].bit, common)) {
+ if (fdx_only && settings[i].duplex != DUPLEX_FULL)
+ continue;
+ return settings[i].speed;
+ }
+ }
+
+ return SPEED_UNKNOWN;
+}
+
+int __phy_speed_down(struct phy_device *phydev)
+{
+ int min_common_speed = phy_resolve_min_speed(phydev, true);
+
+ if (min_common_speed == SPEED_UNKNOWN)
+ return -EINVAL;
+
+ return __set_linkmode_max_speed(phydev, min_common_speed,
+ phydev->advertising);
+}
+
static void mmd_phy_indirect(struct mii_bus *bus, int phy_addr, int devad,
u16 regnum)
{
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 781f4810c..4be6d3b47 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -665,6 +665,7 @@ size_t phy_speeds(unsigned int *speeds, size_t size,
unsigned long *mask);
void of_set_phy_supported(struct phy_device *phydev);
void of_set_phy_eee_broken(struct phy_device *phydev);
+int __phy_speed_down(struct phy_device *phydev);
/**
* phy_is_started - Convenience function to check whether PHY is started
--
2.22.0
^ permalink raw reply related
* [PATCH net-next 3/3] net: phy: let phy_speed_down/up support speeds >1Gbps
From: Heiner Kallweit @ 2019-08-12 21:20 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0799ec1f-307c-25ab-0259-b8239e4e04ba@gmail.com>
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction by using new helper __phy_speed_down. New member adv_old
in struct phy_device is used by phy_speed_up to restore the advertised
modes before calling phy_speed_down. Don't simply advertise what is
supported because a user may have intentionally removed modes from
advertisement.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy.c | 60 ++++++++++++-------------------------------
include/linux/phy.h | 2 ++
2 files changed, 18 insertions(+), 44 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index ef7aa738e..f8e68b3b4 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -608,38 +608,21 @@ static int phy_poll_aneg_done(struct phy_device *phydev)
*/
int phy_speed_down(struct phy_device *phydev, bool sync)
{
- __ETHTOOL_DECLARE_LINK_MODE_MASK(adv_old);
- __ETHTOOL_DECLARE_LINK_MODE_MASK(adv);
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(adv_tmp);
int ret;
if (phydev->autoneg != AUTONEG_ENABLE)
return 0;
- linkmode_copy(adv_old, phydev->advertising);
- linkmode_copy(adv, phydev->lp_advertising);
- linkmode_and(adv, adv, phydev->supported);
-
- if (linkmode_test_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT, adv) ||
- linkmode_test_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT, adv)) {
- linkmode_clear_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT,
- phydev->advertising);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
- phydev->advertising);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
- phydev->advertising);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
- phydev->advertising);
- } else if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT,
- adv) ||
- linkmode_test_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
- adv)) {
- linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
- phydev->advertising);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
- phydev->advertising);
- }
+ linkmode_copy(adv_tmp, phydev->advertising);
+
+ ret = __phy_speed_down(phydev);
+ if (ret)
+ return ret;
- if (linkmode_equal(phydev->advertising, adv_old))
+ linkmode_copy(phydev->adv_old, adv_tmp);
+
+ if (linkmode_equal(phydev->advertising, adv_tmp))
return 0;
ret = phy_config_aneg(phydev);
@@ -658,30 +641,19 @@ EXPORT_SYMBOL_GPL(phy_speed_down);
*/
int phy_speed_up(struct phy_device *phydev)
{
- __ETHTOOL_DECLARE_LINK_MODE_MASK(all_speeds) = { 0, };
- __ETHTOOL_DECLARE_LINK_MODE_MASK(not_speeds);
- __ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
- __ETHTOOL_DECLARE_LINK_MODE_MASK(adv_old);
- __ETHTOOL_DECLARE_LINK_MODE_MASK(speeds);
-
- linkmode_copy(adv_old, phydev->advertising);
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(adv_tmp);
if (phydev->autoneg != AUTONEG_ENABLE)
return 0;
- linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT, all_speeds);
- linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT, all_speeds);
- linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT, all_speeds);
- linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT, all_speeds);
- linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, all_speeds);
- linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, all_speeds);
+ if (linkmode_empty(phydev->adv_old))
+ return 0;
- linkmode_andnot(not_speeds, adv_old, all_speeds);
- linkmode_copy(supported, phydev->supported);
- linkmode_and(speeds, supported, all_speeds);
- linkmode_or(phydev->advertising, not_speeds, speeds);
+ linkmode_copy(adv_tmp, phydev->advertising);
+ linkmode_copy(phydev->advertising, phydev->adv_old);
+ linkmode_zero(phydev->adv_old);
- if (linkmode_equal(phydev->advertising, adv_old))
+ if (linkmode_equal(phydev->advertising, adv_tmp))
return 0;
return phy_config_aneg(phydev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 4be6d3b47..3c2be52b1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -403,6 +403,8 @@ struct phy_device {
__ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
__ETHTOOL_DECLARE_LINK_MODE_MASK(advertising);
__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising);
+ /* used with phy_speed_down */
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(adv_old);
/* Energy efficient ethernet modes which should be prohibited */
u32 eee_broken_modes;
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net] netfilter: ebtables: Fix argument order to ADD_COUNTER
From: Florian Westphal @ 2019-08-12 21:25 UTC (permalink / raw)
To: Todd Seidelmann; +Cc: netdev, netfilter-devel
In-Reply-To: <00a6c489-dc5b-d66f-f06d-b8785acb50e7@linode.com>
Todd Seidelmann <tseidelmann@linode.com> wrote:
> The ordering of arguments to the x_tables ADD_COUNTER macro
> appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
> and arp_tables.c).
>
> This causes data corruption in the ebtables userspace tools
> because they get incorrect packet & byte counts from the kernel.
Please send netfilter patches to netfilter-devel@vger.kernel.org .
Fixes: d72133e628803 ("netfilter: ebtables: use ADD_COUNTER macro")
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: phy: add __set_linkmode_max_speed
From: Andrew Lunn @ 2019-08-12 21:27 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <5067e168-7b49-7ba9-1f17-89d17509d423@gmail.com>
On Mon, Aug 12, 2019 at 11:19:31PM +0200, Heiner Kallweit wrote:
> We will need the functionality of __set_linkmode_max_speed also for
> linkmode bitmaps other than phydev->supported. Therefore split it.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy-core.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
> index 9ae3abb2d..de085f255 100644
> --- a/drivers/net/phy/phy-core.c
> +++ b/drivers/net/phy/phy-core.c
> @@ -207,14 +207,15 @@ size_t phy_speeds(unsigned int *speeds, size_t size,
> return count;
> }
>
> -static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
> +static int __set_linkmode_max_speed(struct phy_device *phydev, u32 max_speed,
> + unsigned long *addr)
> {
Hi Heiner
It looks like phydev is an unused parameter. Maybe it should be
removed?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: phy: add __set_linkmode_max_speed
From: Heiner Kallweit @ 2019-08-12 21:31 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190812212715.GB15047@lunn.ch>
On 12.08.2019 23:27, Andrew Lunn wrote:
> On Mon, Aug 12, 2019 at 11:19:31PM +0200, Heiner Kallweit wrote:
>> We will need the functionality of __set_linkmode_max_speed also for
>> linkmode bitmaps other than phydev->supported. Therefore split it.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy-core.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>> index 9ae3abb2d..de085f255 100644
>> --- a/drivers/net/phy/phy-core.c
>> +++ b/drivers/net/phy/phy-core.c
>> @@ -207,14 +207,15 @@ size_t phy_speeds(unsigned int *speeds, size_t size,
>> return count;
>> }
>>
>> -static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
>> +static int __set_linkmode_max_speed(struct phy_device *phydev, u32 max_speed,
>> + unsigned long *addr)
>> {
>
> Hi Heiner
>
> It looks like phydev is an unused parameter. Maybe it should be
> removed?
>
Right, it can be removed. Thanks!
> Andrew
>
Heiner
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: phy: add __phy_speed_down and phy_resolve_min_speed
From: Andrew Lunn @ 2019-08-12 21:32 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <e499c226-7141-d5be-990c-b46b7dd048f8@gmail.com>
> +int __phy_speed_down(struct phy_device *phydev)
> +{
> + int min_common_speed = phy_resolve_min_speed(phydev, true);
> +
> + if (min_common_speed == SPEED_UNKNOWN)
> + return -EINVAL;
> +
> + return __set_linkmode_max_speed(phydev, min_common_speed,
> + phydev->advertising);
> +}
> +
> static void mmd_phy_indirect(struct mii_bus *bus, int phy_addr, int devad,
> u16 regnum)
> {
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 781f4810c..4be6d3b47 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -665,6 +665,7 @@ size_t phy_speeds(unsigned int *speeds, size_t size,
> unsigned long *mask);
> void of_set_phy_supported(struct phy_device *phydev);
> void of_set_phy_eee_broken(struct phy_device *phydev);
> +int __phy_speed_down(struct phy_device *phydev);
It seems odd having a __ function exported. Can we find a better name
for it, and drop the __?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: phy: let phy_speed_down/up support speeds >1Gbps
From: Andrew Lunn @ 2019-08-12 21:40 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <e6f96369-aa6e-19f3-76af-5e9d6df03aab@gmail.com>
On Mon, Aug 12, 2019 at 11:20:51PM +0200, Heiner Kallweit wrote:
> So far phy_speed_down/up can be used up to 1Gbps only. Remove this
> restriction by using new helper __phy_speed_down. New member adv_old
> in struct phy_device is used by phy_speed_up to restore the advertised
> modes before calling phy_speed_down. Don't simply advertise what is
> supported because a user may have intentionally removed modes from
> advertisement.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Jakub Kicinski @ 2019-08-12 21:43 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, David Ahern, netdev, David Miller, Stephen Hemminger,
dcbw, Michal Kubecek, Andrew Lunn, parav, Saeed Mahameed, mlxsw
In-Reply-To: <CAJieiUhqAvqvxDZk517hWQP4Tx3Hk2PT7Yjq6NSGk+pB_87q8A@mail.gmail.com>
On Mon, 12 Aug 2019 08:13:39 -0700, Roopa Prabhu wrote:
> On Mon, Aug 12, 2019 at 1:31 AM Jiri Pirko <jiri@resnulli.us> wrote:
> > Mon, Aug 12, 2019 at 03:37:26AM CEST, dsahern@gmail.com wrote:
> > >On 8/11/19 7:34 PM, David Ahern wrote:
> > >> On 8/10/19 12:30 AM, Jiri Pirko wrote:
> > >>> Could you please write me an example message of add/remove?
> > >>
> > >> altnames are for existing netdevs, yes? existing netdevs have an id and
> > >> a name - 2 existing references for identifying the existing netdev for
> > >> which an altname will be added. Even using the altname as the main
> > >> 'handle' for a setlink change, I see no reason why the GETLINK api can
> > >> not take an the IFLA_ALT_IFNAME and return the full details of the
> > >> device if the altname is unique.
> > >>
> > >> So, what do the new RTM commands give you that you can not do with
> > >> RTM_*LINK?
> > >
> > >To put this another way, the ALT_NAME is an attribute of an object - a
> > >LINK. It is *not* a separate object which requires its own set of
> > >commands for manipulating.
> >
> > Okay, again, could you provide example of a message to add/remove
> > altname using existing setlink message? Thanks!
>
> Will the below work ?... just throwing an example for discussion:
>
> make the name list a nested list
> IFLA_ALT_NAMES
> IFLA_ALT_NAME_OP /* ADD or DEL used with setlink */
> IFLA_ALT_NAME
> IFLA_ALT_NAME_LIST
>
> With RTM_NEWLINK you can specify a list to set and unset
> With RTM_SETLINK you can specify an individual name with a add or del op
>
> notifications will always be RTM_NEWLINK with the full list.
>
> The nested attribute can be structured differently.
>
> Only thing is i am worried about increasing the size of link dump and
> notification msgs.
Is not adding commands better because it's easier to deal with the
RTM_NEWLINK notification? I must say it's unclear from the thread why
muxing the op through RTM_SETLINK is preferable. IMHO new op is
cleaner, do we have precedent for such IFLA_.*_OP-style attributes?
^ permalink raw reply
* [PATCH net-next v2 0/3] net: phy: let phy_speed_down/up support speeds >1Gbps
From: Heiner Kallweit @ 2019-08-12 21:47 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction and add needed helpers to phy-core.c
v2:
- remove unused parameter in patch 1
- rename __phy_speed_down to phy_speed_down_core in patch 2
Heiner Kallweit (3):
net: phy: add __set_linkmode_max_speed
net: phy: add phy_speed_down_core and phy_resolve_min_speed
net: phy: let phy_speed_down/up support speeds >1Gbps
drivers/net/phy/phy-core.c | 39 +++++++++++++++++++++++--
drivers/net/phy/phy.c | 60 ++++++++++----------------------------
include/linux/phy.h | 3 ++
3 files changed, 56 insertions(+), 46 deletions(-)
--
2.22.0
^ permalink raw reply
* [PATCH 01/16] s390/boot: fix section name escaping
From: Nick Desaulniers @ 2019-08-12 21:50 UTC (permalink / raw)
To: akpm
Cc: sedat.dilek, jpoimboe, yhs, miguel.ojeda.sandonis,
clang-built-linux, Nick Desaulniers, Heiko Carstens,
Vasily Gorbik, Christian Borntraeger, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Martin Schwidefsky,
Gerald Schaefer, Philipp Rudo, linux-s390, linux-kernel, netdev,
bpf
GCC unescapes escaped string section names while Clang does not. Because
__section uses the `#` stringification operator for the section name, it
doesn't need to be escaped.
This antipattern was found with:
$ grep -e __section\(\" -e __section__\(\" -r
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/s390/boot/startup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/boot/startup.c b/arch/s390/boot/startup.c
index 7b0d05414618..26493c4ff04b 100644
--- a/arch/s390/boot/startup.c
+++ b/arch/s390/boot/startup.c
@@ -46,7 +46,7 @@ struct diag_ops __bootdata_preserved(diag_dma_ops) = {
.diag0c = _diag0c_dma,
.diag308_reset = _diag308_reset_dma
};
-static struct diag210 _diag210_tmp_dma __section(".dma.data");
+static struct diag210 _diag210_tmp_dma __section(.dma.data);
struct diag210 *__bootdata_preserved(__diag210_tmp_dma) = &_diag210_tmp_dma;
void _swsusp_reset_dma(void);
unsigned long __bootdata_preserved(__swsusp_reset_dma) = __pa(_swsusp_reset_dma);
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* [PATCH 02/16] arc: prefer __section from compiler_attributes.h
From: Nick Desaulniers @ 2019-08-12 21:50 UTC (permalink / raw)
To: akpm
Cc: sedat.dilek, jpoimboe, yhs, miguel.ojeda.sandonis,
clang-built-linux, Nick Desaulniers, Vineet Gupta,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Enrico Weigelt, Kate Stewart, Thomas Gleixner, Greg Kroah-Hartman,
Allison Randal, linux-snps-arc, linux-kernel, netdev, bpf
In-Reply-To: <20190812215052.71840-1-ndesaulniers@google.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/arc/include/asm/linkage.h | 8 ++++----
arch/arc/include/asm/mach_desc.h | 3 +--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index a0eeb9f8f0a9..d9ee43c6b7db 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -62,15 +62,15 @@
#else /* !__ASSEMBLY__ */
#ifdef CONFIG_ARC_HAS_ICCM
-#define __arcfp_code __attribute__((__section__(".text.arcfp")))
+#define __arcfp_code __section(.text.arcfp)
#else
-#define __arcfp_code __attribute__((__section__(".text")))
+#define __arcfp_code __section(.text)
#endif
#ifdef CONFIG_ARC_HAS_DCCM
-#define __arcfp_data __attribute__((__section__(".data.arcfp")))
+#define __arcfp_data __section(.data.arcfp)
#else
-#define __arcfp_data __attribute__((__section__(".data")))
+#define __arcfp_data __section(.data)
#endif
#endif /* __ASSEMBLY__ */
diff --git a/arch/arc/include/asm/mach_desc.h b/arch/arc/include/asm/mach_desc.h
index 8ac0e2ac3e70..73746ed5b834 100644
--- a/arch/arc/include/asm/mach_desc.h
+++ b/arch/arc/include/asm/mach_desc.h
@@ -53,8 +53,7 @@ extern const struct machine_desc __arch_info_begin[], __arch_info_end[];
*/
#define MACHINE_START(_type, _name) \
static const struct machine_desc __mach_desc_##_type \
-__used \
-__attribute__((__section__(".arch.info.init"))) = { \
+__used __section(.arch.info.init) = { \
.name = _name,
#define MACHINE_END \
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* [PATCH 03/16] parisc: prefer __section from compiler_attributes.h
From: Nick Desaulniers @ 2019-08-12 21:50 UTC (permalink / raw)
To: akpm
Cc: sedat.dilek, jpoimboe, yhs, miguel.ojeda.sandonis,
clang-built-linux, Nick Desaulniers, James E.J. Bottomley,
Helge Deller, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, John David Anglin, linux-parisc,
linux-kernel, netdev, bpf
In-Reply-To: <20190812215052.71840-1-ndesaulniers@google.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/parisc/include/asm/cache.h | 2 +-
arch/parisc/include/asm/ldcw.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/parisc/include/asm/cache.h b/arch/parisc/include/asm/cache.h
index 73ca89a47f49..e5de3f897633 100644
--- a/arch/parisc/include/asm/cache.h
+++ b/arch/parisc/include/asm/cache.h
@@ -22,7 +22,7 @@
#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
-#define __read_mostly __attribute__((__section__(".data..read_mostly")))
+#define __read_mostly __section(.data..read_mostly)
void parisc_cache_init(void); /* initializes cache-flushing */
void disable_sr_hashing_asm(int); /* low level support for above */
diff --git a/arch/parisc/include/asm/ldcw.h b/arch/parisc/include/asm/ldcw.h
index 3eb4bfc1fb36..e080143e79a3 100644
--- a/arch/parisc/include/asm/ldcw.h
+++ b/arch/parisc/include/asm/ldcw.h
@@ -52,7 +52,7 @@
})
#ifdef CONFIG_SMP
-# define __lock_aligned __attribute__((__section__(".data..lock_aligned")))
+# define __lock_aligned __section(.data..lock_aligned)
#endif
#endif /* __PARISC_LDCW_H */
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* [PATCH 04/16] um: prefer __section from compiler_attributes.h
From: Nick Desaulniers @ 2019-08-12 21:50 UTC (permalink / raw)
To: akpm
Cc: sedat.dilek, jpoimboe, yhs, miguel.ojeda.sandonis,
clang-built-linux, Nick Desaulniers, Jeff Dike,
Richard Weinberger, Anton Ivanov, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, linux-um,
linux-kernel, netdev, bpf
In-Reply-To: <20190812215052.71840-1-ndesaulniers@google.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/um/kernel/um_arch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index a818ccef30ca..18e0287dd97e 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -52,9 +52,9 @@ struct cpuinfo_um boot_cpu_data = {
.ipi_pipe = { -1, -1 }
};
-union thread_union cpu0_irqstack
- __attribute__((__section__(".data..init_irqstack"))) =
- { .thread_info = INIT_THREAD_INFO(init_task) };
+union thread_union cpu0_irqstack __section(.data..init_irqstack) = {
+ .thread_info = INIT_THREAD_INFO(init_task)
+};
/* Changed in setup_arch, which is called in early boot */
static char host_info[(__NEW_UTS_LEN + 1) * 5];
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* [PATCH 05/16] sh: prefer __section from compiler_attributes.h
From: Nick Desaulniers @ 2019-08-12 21:50 UTC (permalink / raw)
To: akpm
Cc: sedat.dilek, jpoimboe, yhs, miguel.ojeda.sandonis,
clang-built-linux, Nick Desaulniers, Yoshinori Sato, Rich Felker,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
linux-sh, linux-kernel, netdev, bpf
In-Reply-To: <20190812215052.71840-1-ndesaulniers@google.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/sh/include/asm/cache.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/cache.h b/arch/sh/include/asm/cache.h
index 2408ac4873aa..07ddf31124a3 100644
--- a/arch/sh/include/asm/cache.h
+++ b/arch/sh/include/asm/cache.h
@@ -15,7 +15,7 @@
#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
-#define __read_mostly __attribute__((__section__(".data..read_mostly")))
+#define __read_mostly __section(.data..read_mostly)
#ifndef __ASSEMBLY__
struct cache_info {
--
2.23.0.rc1.153.gdeed80330f-goog
^ 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