* [PATCH 0/2] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Casey Leedom @ 2017-05-01 23:13 UTC (permalink / raw)
To: Bjorn Helgaas, leedom
Cc: Casey Leedom, Michael Werner, Ganesh Goudar, Arjun V,
David Miller, Asit K Mallick, Patrick J Cramer, Ashok Raj,
Suravee Suthikulpanit, Bob Shaw, h, Alexander Duyck,
Ding Tianhong, Mark Rutland, Amir Ancel, Gabriele Paoloni,
Catalin Marinas, Will Deacon, LinuxArm, David Laight
Some devices have problems with Transaction Layer Packets with the Relaxed
Ordering Attribute set. This patch set adds a new PCIe Device Flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
devices with Relaxed Ordering issues, and a use of this new flag by the
cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
Ports.
It's been years since I've submitted kernel.org patches, I appolgise for the
almost certain submission errors.
Casey Leedom (2):
PCI: Add new PCIe Fabric End Node flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING
net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +++++++++++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 ++--
drivers/pci/quirks.c | 38 +++++++++++++++++++++++++
include/linux/pci.h | 2 ++
5 files changed, 61 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/2] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Casey Leedom @ 2017-05-01 23:13 UTC (permalink / raw)
To: Bjorn Helgaas, leedom
Cc: Casey Leedom, Michael Werner, Ganesh Goudar, Arjun V,
David Miller, Asit K Mallick, Patrick J Cramer, Ashok Raj,
Suravee Suthikulpanit, Bob Shaw, h, Alexander Duyck,
Ding Tianhong, Mark Rutland, Amir Ancel, Gabriele Paoloni,
Catalin Marinas, Will Deacon, LinuxArm, David Laight
In-Reply-To: <cover.1493678834.git.leedom@chelsio.com>
cxgb4 Ethernet driver now queries Root Complex Port to determine if it can
send TLPs to it with the Relaxed Ordering Attribute set.
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 163543b..46d61b1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -512,6 +512,7 @@ enum { /* adapter flags */
USING_SOFT_PARAMS = (1 << 6),
MASTER_PF = (1 << 7),
FW_OFLD_CONN = (1 << 9),
+ ROOT_NO_RELAXED_ORDERING = (1 << 10),
};
enum {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index afb0967..510c020 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4636,6 +4636,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
#ifdef CONFIG_PCI_IOV
u32 v, port_vec;
#endif
+ struct pci_dev *root;
printk_once(KERN_INFO "%s - version %s\n", DRV_DESC, DRV_VERSION);
@@ -4734,6 +4735,22 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->msg_enable = DFLT_MSG_ENABLE;
memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map));
+ /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+ * Ingress Packet Data to Free List Buffers in order to allow for
+ * chipset performance optimizations between the Root Complex and
+ * Memory Controllers. (Messages to the associated Ingress Queue
+ * notifying new Packet Placement in the Free Lists Buffers will be
+ * send without the Relaxed Ordering Attribute thus guaranteing that
+ * all preceding PCIe Transaction Layer Packets will be processed
+ * first.) But some Root Complexes have various issues with Upstream
+ * Transaction Layer Packets with the Relaxed Ordering Attribute set.
+ * So we check our Root Complex to see if it's flaged with advice
+ * against using Relaxed Ordering.
+ */
+ root = pci_find_pcie_root_port(adapter->pdev);
+ if (root && (root->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING))
+ adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
spin_lock_init(&adapter->stats_lock);
spin_lock_init(&adapter->tid_release_lock);
spin_lock_init(&adapter->win0_lock);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index f05f0d4..ac229a3 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2571,6 +2571,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
struct fw_iq_cmd c;
struct sge *s = &adap->sge;
struct port_info *pi = netdev_priv(dev);
+ int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING);
/* Size needs to be multiple of 16, including status entry. */
iq->size = roundup(iq->size, 16);
@@ -2624,8 +2625,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc);
c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F |
- FW_IQ_CMD_FL0FETCHRO_F |
- FW_IQ_CMD_FL0DATARO_F |
+ FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+ FW_IQ_CMD_FL0DATARO_V(relaxed) |
FW_IQ_CMD_FL0PADEN_F);
if (cong >= 0)
c.iqns_to_fl0congen |=
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
From: Casey Leedom @ 2017-05-01 23:13 UTC (permalink / raw)
To: Bjorn Helgaas, leedom
Cc: Mark Rutland, Gabriele Paoloni, Asit K Mallick, Catalin Marinas,
Will Deacon, LinuxArm, Alexander Duyck, Ashok Raj, Ganesh Goudar,
David Miller, jeffrey.t.kirsher, Bob Shaw, Casey Leedom,
Patrick J Cramer, Arjun V, Ding Tianhong, Michael Werner,
linux-arm-kernel, Amir Ancel, netdev, David Laight,
Suravee Suthikulpanit, Robin Murphy, davem
In-Reply-To: <cover.1493678834.git.leedom@chelsio.com>
The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
Ordering Attribute should not be used on Transaction Layer Packets destined
for the PCIe End Node so flagged. Initially flagged this way are Intel
E5-26xx Root Complex Ports which suffer from a Flow Control Credit
Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which
don't obey PCIe 3.0 ordering rules which can lead to Data Corruption.
---
drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f754453..4ae78b3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3979,6 +3979,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
quirk_tw686x_class);
/*
+ * Some devices have problems with Transaction Layer Packets with the Relaxed
+ * Ordering Attribute set. Such devices should mark themselves and other
+ * Device Drivers should check before sending TLPs with RO set.
+ */
+static void quirk_relaxedordering_disable(struct pci_dev *dev)
+{
+ dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
+}
+
+/*
+ * Intel E5-26xx Root Complex has a Flow Control Credit issue which can
+ * cause performance problems with Upstream Transaction Layer Packets with
+ * Relaxed Ordering set.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f02, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f04, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f08, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+
+/*
+ * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex
+ * where Upstream Transaction Layer Packets with the Relaxed Ordering
+ * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering
+ * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules
+ * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0
+ * November 10, 2010). As a result, on this platform we can't use Relaxed
+ * Ordering for Upstream TLPs.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a00, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a01, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a02, PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+
+/*
* Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
* values for the Attribute as were supplied in the header of the
* corresponding Request, except as explicitly allowed when IDO is used."
diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb3da1a..6764f66 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -178,6 +178,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
/* Get VPD from function 0 VPD */
PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
+ /* Don't use Relaxed Ordering for TLPs directed at this device */
+ PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 9),
};
enum pci_irq_reroute_variant {
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] xdp: fix parameter kdoc for extack
From: Jakub Kicinski @ 2017-05-01 22:53 UTC (permalink / raw)
To: netdev; +Cc: kbuild-all, fengguang.wu, Jakub Kicinski
In-Reply-To: <201705020535.2FQBLyjE%fengguang.wu@intel.com>
Fix kdoc parameter spelling from extact to extack.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 35a06cebb282..0b2876e00834 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6854,7 +6854,7 @@ EXPORT_SYMBOL(dev_change_proto_down);
/**
* dev_change_xdp_fd - set or clear a bpf program for a device rx path
* @dev: device
- * @extact: netlink extended ack
+ * @extack: netlink extended ack
* @fd: new program fd or negative value to clear
* @flags: xdp-related flags
*
--
2.11.0
^ permalink raw reply related
* [PATCH net-next] bpf, samples: fix build warning in cookie_uid_helper_example
From: Daniel Borkmann @ 2017-05-01 22:47 UTC (permalink / raw)
To: davem; +Cc: alexei.starovoitov, netdev, Daniel Borkmann
Fix the following warnings triggered by 51570a5ab2b7 ("A Sample of
using socket cookie and uid for traffic monitoring"):
In file included from /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:54:0:
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c: In function 'prog_load':
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:119:27: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, uid)),
^
/home/foo/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro 'BPF_STX_MEM'
.off = OFF, \
^
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:121:27: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, packets), 1),
^
/home/foo/net-next/samples/bpf/libbpf.h:155:12: note: in definition of macro 'BPF_ST_MEM'
.off = OFF, \
^
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:129:27: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, bytes)),
^
/home/foo/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro 'BPF_STX_MEM'
.off = OFF, \
^
HOSTLD /home/foo/net-next/samples/bpf/per_socket_stats_example
Fixes: 51570a5ab2b7 ("A Sample of using socket cookie and uid for traffic monitoring")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
samples/bpf/cookie_uid_helper_example.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/samples/bpf/cookie_uid_helper_example.c b/samples/bpf/cookie_uid_helper_example.c
index 9ce5584..b08ab4e 100644
--- a/samples/bpf/cookie_uid_helper_example.c
+++ b/samples/bpf/cookie_uid_helper_example.c
@@ -116,9 +116,9 @@ static void prog_load(void)
* is set by directly place a IMM value 1 into the stack.
*/
BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_0,
- -32 + offsetof(struct stats, uid)),
+ -32 + (__s16)offsetof(struct stats, uid)),
BPF_ST_MEM(BPF_DW, BPF_REG_10,
- -32 + offsetof(struct stats, packets), 1),
+ -32 + (__s16)offsetof(struct stats, packets), 1),
/*
* __sk_buff is a special struct used for eBPF program to
* directly access some sk_buff field.
@@ -126,7 +126,7 @@ static void prog_load(void)
BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_6,
offsetof(struct __sk_buff, len)),
BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_1,
- -32 + offsetof(struct stats, bytes)),
+ -32 + (__s16)offsetof(struct stats, bytes)),
/*
* add new map entry using BPF_FUNC_map_update_elem, it takes
* 4 parameters (R1: map_fd, R2: &socket_cookie, R3: &stats,
--
1.9.3
^ permalink raw reply related
* [PATCH net] tcp: fix wraparound issue in tcp_lp
From: Eric Dumazet @ 2017-05-01 22:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Be careful when comparing tcp_time_stamp to some u32 quantity,
otherwise result can be surprising.
Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_lp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_lp.c b/net/ipv4/tcp_lp.c
index 046fd3910873306d74207615d6997e1c847ea361..d6fb6c067af4641f232b94e7c590c212648e8173 100644
--- a/net/ipv4/tcp_lp.c
+++ b/net/ipv4/tcp_lp.c
@@ -264,13 +264,15 @@ static void tcp_lp_pkts_acked(struct sock *sk, const struct ack_sample *sample)
{
struct tcp_sock *tp = tcp_sk(sk);
struct lp *lp = inet_csk_ca(sk);
+ u32 delta;
if (sample->rtt_us > 0)
tcp_lp_rtt_sample(sk, sample->rtt_us);
/* calc inference */
- if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
- lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
+ delta = tcp_time_stamp - tp->rx_opt.rcv_tsecr;
+ if ((s32)delta > 0)
+ lp->inference = 3 * delta;
/* test if within inference */
if (lp->last_drop && (tcp_time_stamp - lp->last_drop < lp->inference))
^ permalink raw reply related
* Re: [PATCH net-next iproute2] ip: increase number of MPLS labels
From: Eric W. Biederman @ 2017-05-01 21:57 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev, roopa
In-Reply-To: <70667d3a-5cbc-4900-3c41-bce508a057ac@cumulusnetworks.com>
David Ahern <dsa@cumulusnetworks.com> writes:
> On 5/1/17 3:03 PM, Eric W. Biederman wrote:
>> Basically the kernel maximum is how large we can make struct mpls_route
>> without while being < 4096 aka PAGE_SIZE. Which also happens to be
>> larger than the largest known consumer.
>
> 2 limits in the kernel:
> 1. max allocation for mpls_route of 4096
> 2. max number of labels of 30.
Ah yes. I remember now. That conversation was just long enough ago that
the details had slipped my mind.
> The latter was necessitated by the LWT path. I wanted a cap on it and
> for the cap to be consistent for both ingress and LSP. To that end I
> went with a maximum of 30 labels in the kernel: 4k max allocation = ~30
> labels per nexthop with ~30 nexthops. For both 30 is excessive, overkill
> number. (though someone did ask me recently why not 512 labels. seriously)
>
> I can't say it makes sense for iproute2 to support 30 labels.
> Argumentative that even 16 is too high, but some folks have argued for it.
>
>
>> Dave is there a practical reason that is motivating increasing the size
>> in iproute? Or is the desire to ensure that iproute can take full
>> advantage of the kernel?
>
> I suspect only routing daemons would inject a high label stack. It would
> be nice for iproute2 to 1. be able to print that route properly
> (currently does not if the label count exceeds what it can handle), 2.
> be able to reinject the route. Even with scripting creating a route
> using ip with a lot of labels is a PITA.
Yes. At this point I will agree with Stephen Hemminger. The sensible
change to iproute is to rework the code so that it supports an arbitrary
number of labels. At least up to iproutes fixed sized rtnetlink packet
buffers.
It is a bit more work but then iproute won't be something that needs
worrying about any more. It will just work with whatever size addresses
are thrown at it.
Eric
^ permalink raw reply
* [net-next:master 2181/2226] htmldocs: net/core/dev.c:6865: warning: No description found for parameter 'extack'
From: kbuild test robot @ 2017-05-01 21:58 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 3410 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 5b8481fa42ac58484d633b558579e302aead64c1
commit: ddf9f970764f4390aba767e77fddaaced4a6760d [2181/2226] xdp: propagate extended ack to XDP setup
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
include/net/sock.h:476: warning: No description found for parameter 'sk_tsq_flags'
include/net/sock.h:476: warning: No description found for parameter '__sk_flags_offset[0]'
include/net/sock.h:476: warning: No description found for parameter 'sk_uid'
>> net/core/dev.c:6865: warning: No description found for parameter 'extack'
>> net/core/dev.c:6865: warning: Excess function parameter 'extact' description in 'dev_change_xdp_fd'
drivers/net/phy/phy.c:259: warning: No description found for parameter 'features'
drivers/net/phy/phy.c:259: warning: Excess function parameter 'feature' description in 'phy_lookup_setting'
drivers/net/phy/phy.c:259: warning: No description found for parameter 'features'
drivers/net/phy/phy.c:259: warning: Excess function parameter 'feature' description in 'phy_lookup_setting'
vim +/extack +6865 net/core/dev.c
d746d707 Anuradha Karuppiah 2015-07-14 6849 return -ENODEV;
d746d707 Anuradha Karuppiah 2015-07-14 6850 return ops->ndo_change_proto_down(dev, proto_down);
d746d707 Anuradha Karuppiah 2015-07-14 6851 }
d746d707 Anuradha Karuppiah 2015-07-14 6852 EXPORT_SYMBOL(dev_change_proto_down);
d746d707 Anuradha Karuppiah 2015-07-14 6853
d746d707 Anuradha Karuppiah 2015-07-14 6854 /**
a7862b45 Brenden Blanco 2016-07-19 6855 * dev_change_xdp_fd - set or clear a bpf program for a device rx path
a7862b45 Brenden Blanco 2016-07-19 6856 * @dev: device
ddf9f970 Jakub Kicinski 2017-04-30 6857 * @extact: netlink extended ack
a7862b45 Brenden Blanco 2016-07-19 6858 * @fd: new program fd or negative value to clear
85de8576 Daniel Borkmann 2016-11-28 6859 * @flags: xdp-related flags
a7862b45 Brenden Blanco 2016-07-19 6860 *
a7862b45 Brenden Blanco 2016-07-19 6861 * Set or clear a bpf program for a device
a7862b45 Brenden Blanco 2016-07-19 6862 */
ddf9f970 Jakub Kicinski 2017-04-30 6863 int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
ddf9f970 Jakub Kicinski 2017-04-30 6864 int fd, u32 flags)
a7862b45 Brenden Blanco 2016-07-19 @6865 {
b5cdae32 David S. Miller 2017-04-18 6866 int (*xdp_op)(struct net_device *dev, struct netdev_xdp *xdp);
a7862b45 Brenden Blanco 2016-07-19 6867 const struct net_device_ops *ops = dev->netdev_ops;
a7862b45 Brenden Blanco 2016-07-19 6868 struct bpf_prog *prog = NULL;
85de8576 Daniel Borkmann 2016-11-28 6869 struct netdev_xdp xdp;
a7862b45 Brenden Blanco 2016-07-19 6870 int err;
a7862b45 Brenden Blanco 2016-07-19 6871
85de8576 Daniel Borkmann 2016-11-28 6872 ASSERT_RTNL();
85de8576 Daniel Borkmann 2016-11-28 6873
:::::: The code at line 6865 was first introduced by commit
:::::: a7862b45849fe2f8610a2bec89235580f55d337f net: add ndo to setup/query xdp prog in adapter rx
:::::: TO: Brenden Blanco <bblanco@plumgrid.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6576 bytes --]
^ permalink raw reply
* Re: [PATCH net-next iproute2] ip: increase number of MPLS labels
From: David Ahern @ 2017-05-01 21:22 UTC (permalink / raw)
To: Eric W. Biederman, Stephen Hemminger; +Cc: netdev, roopa
In-Reply-To: <8737convca.fsf@xmission.com>
On 5/1/17 3:03 PM, Eric W. Biederman wrote:
> Basically the kernel maximum is how large we can make struct mpls_route
> without while being < 4096 aka PAGE_SIZE. Which also happens to be
> larger than the largest known consumer.
2 limits in the kernel:
1. max allocation for mpls_route of 4096
2. max number of labels of 30.
The latter was necessitated by the LWT path. I wanted a cap on it and
for the cap to be consistent for both ingress and LSP. To that end I
went with a maximum of 30 labels in the kernel: 4k max allocation = ~30
labels per nexthop with ~30 nexthops. For both 30 is excessive, overkill
number. (though someone did ask me recently why not 512 labels. seriously)
I can't say it makes sense for iproute2 to support 30 labels.
Argumentative that even 16 is too high, but some folks have argued for it.
> Dave is there a practical reason that is motivating increasing the size
> in iproute? Or is the desire to ensure that iproute can take full
> advantage of the kernel?
I suspect only routing daemons would inject a high label stack. It would
be nice for iproute2 to 1. be able to print that route properly
(currently does not if the label count exceeds what it can handle), 2.
be able to reinject the route. Even with scripting creating a route
using ip with a lot of labels is a PITA.
^ permalink raw reply
* Re: [PATCH net-next iproute2] ip: increase number of MPLS labels
From: Eric W. Biederman @ 2017-05-01 21:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Ahern, netdev, roopa
In-Reply-To: <20170501091540.13f57676@xeon-e3>
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Sun, 30 Apr 2017 17:42:15 -0600
> David Ahern <dsa@cumulusnetworks.com> wrote:
>
>> On 4/30/17 12:04 AM, Stephen Hemminger wrote:
>> > On Sat, 29 Apr 2017 20:48:50 -0700
>> > David Ahern <dsa@cumulusnetworks.com> wrote:
>> >
>> >> Kernel now supports more than 2 labels. Increase ip to
>> >> handle up to 16 labels.
>> >>
>> >> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>> >> ---
>> >> include/utils.h | 8 ++++----
>> >> lib/utils.c | 2 +-
>> >> 2 files changed, 5 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/include/utils.h b/include/utils.h
>> >> index 8c12e1e2a60c..a69e176c260d 100644
>> >> --- a/include/utils.h
>> >> +++ b/include/utils.h
>> >> @@ -54,6 +54,9 @@ void incomplete_command(void) __attribute__((noreturn));
>> >> #define NEXT_ARG_FWD() do { argv++; argc--; } while(0)
>> >> #define PREV_ARG() do { argv--; argc++; } while(0)
>> >>
>> >> +/* Maximum number of labels the mpls helpers support */
>> >> +#define MPLS_MAX_LABELS 16
>> >> +
>> >
>> > Why is the kernel limit not in include/uapi/ header file?
>> >
>>
>> I believe Eric had reasons, but not sure why.
>
> I just don't want iproute2 utilities chasing kernel values.
> Would prefer either make utilities take any size, or inherit maximum
> from kernel headers.
Basically the kernel maximum is how large we can make struct mpls_route
without while being < 4096 aka PAGE_SIZE. Which also happens to be
larger than the largest known consumer.
Which basically makes the limit meaningless for userspace. MPLS does
not actually have a maximum (other than packet size) in the protocol.
So we need a number large enough that people don't care or something
completely arbitrary in iproute.
At 8 labels we are the same size as an ipv6 address which is where
the limitation of 8 came from in the code. It was easy and it allowed
for future growth.
Taking a quick look at the code iproure uses inet_prefix for an address
in any protocol family and it is used fairly widely in the code.
Further addresses are placed in what appear to be fixed sized
preallocated netlink packets. Hmmmmm....
So a completely arbitrary number of labels seems like over-enginnerring.
It looks like what is more interesting is using as a limit the remaining
space in the rtnetlink buffer. Perhaps a function that combines
the efforts of get_addr and addattr_l/rta_addattr_l is the way to go.
That would appear to make it easier to add new address families in the future.
Dave is there a practical reason that is motivating increasing the size
in iproute? Or is the desire to ensure that iproute can take full
advantage of the kernel?
Eric
^ permalink raw reply
* RE: net/smc and the RDMA core
From: Steve Wise @ 2017-05-01 21:04 UTC (permalink / raw)
To: 'Christoph Hellwig', 'Ursula Braun',
'David S. Miller'
Cc: netdev, linux-rdma
In-Reply-To: <20170501163311.GA22209@lst.de>
>
> Hi Ursual, hi netdev reviewers,
>
> how did the smc protocol manage to get merged without any review
> on linux-rdma at all? As the results it seems it's very substandard
> in terms of RDMA API usage, e.g. it neither uses the proper CQ API
> nor the RDMA R/W API, and other will probably find additional issues
> as well.
> --
And it only supports RoCE (and maybe IB).
^ permalink raw reply
* Re: [PATCH 1/1] IB/mlx5: Add port_xmit_wait to counter registers read
From: Doug Ledford @ 2017-05-01 20:56 UTC (permalink / raw)
To: Tim Wright, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
saeedm-VPRAkNaXOzVWk0Htik3J/w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170501163008.27043-1-tim-r/Uwd3QrhQcqdlJmJB21zg@public.gmane.org>
On Mon, 2017-05-01 at 17:30 +0100, Tim Wright wrote:
> Add port_xmit_wait to the error counters read by mlx5_ib_process_mad
> to
> ensure sysfs port counter provides correct value for PortXmitWait.
> Otherwise the sysfs port_xmit_wait file always contains zero.
>
> The previous MAD_IFC implementation populated this counter, but it
> was
> removed during the migration to PPCNT for error counters (32-bit
> only).
>
> Signed-off-by: Tim Wright <tim-r/Uwd3QrhQcqdlJmJB21zg@public.gmane.org>
Thanks, applied.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: more bpf samples build breakage...
From: David Miller @ 2017-05-01 20:45 UTC (permalink / raw)
To: daniel; +Cc: netdev
In-Reply-To: <59079CE2.6010305@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 01 May 2017 22:38:58 +0200
> BPF samples:
>
> [root@apoc bpf]# make > /dev/null
> In file included from
> /root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:54:0:
> /root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c: In
> function ‘prog_load’:
> /root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:119:5:
> warning: overflow in implicit constant conversion [-Woverflow]
> -32 + offsetof(struct stats, uid)),
> ^
> /root/cilium/net-next/samples/bpf/libbpf.h:135:12: note: in definition
> of macro ‘BPF_STX_MEM’
> .off = OFF, \
> ^
> /root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:121:5:
> warning: overflow in implicit constant conversion [-Woverflow]
> -32 + offsetof(struct stats, packets), 1),
> ^
> /root/cilium/net-next/samples/bpf/libbpf.h:155:12: note: in definition
> of macro ‘BPF_ST_MEM’
> .off = OFF, \
> ^
> /root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:129:5:
> warning: overflow in implicit constant conversion [-Woverflow]
> -32 + offsetof(struct stats, bytes)),
> ^
> /root/cilium/net-next/samples/bpf/libbpf.h:135:12: note: in definition
> of macro ‘BPF_STX_MEM’
> .off = OFF, \
> ^
> [root@apoc bpf]#
>
> Above warning is from 51570a5ab2b7 ("A Sample of using socket
> cookie and uid for traffic monitoring"). I can see to send a
> fix for it.
Please do, thanks.
^ permalink raw reply
* Re: more bpf samples build breakage...
From: Daniel Borkmann @ 2017-05-01 20:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170501.153005.983887567095122966.davem@davemloft.net>
On 05/01/2017 09:30 PM, David Miller wrote:
>
> Inlcuding bpf_util.h into test_pkt_access.c et al. broke the build even
> more so than it already is on sparc.
>
> The problem is we end up including all the stdio.h bits and eventually
> hit things like:
>
> In file included from /usr/include/stdio.h:933:
> /usr/include/bits/stdio-ldbl.h:28:20: error: cannot apply asm label to function after its first use
> __LDBL_REDIR_DECL (vfprintf)
> ~~~~~~~~~~~~~~~~~~~^~~~~~~~~
> /usr/include/sys/cdefs.h:373:26: note: expanded from macro '__LDBL_REDIR_DECL'
> extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
>
> So please let's put CLANG compiled helpers into header files
> specifically meant to be included by CLANG compiled BPF programs
> rather than the host build environment.
Argh, sorry for that and thanks for the quick fix. When I tested
this on x86_64, I didn't hit a compilation issue.
BPF selftests:
[root@apoc bpf]# make > /dev/null
Warning: tools/include/uapi/linux/bpf.h differs from kernel
[root@apoc bpf]# ./test_progs
test_pkt_access:PASS:ipv4 401 nsec
test_pkt_access:PASS:ipv6 271 nsec
test_xdp:PASS:ipv4 4617 nsec
test_xdp:PASS:ipv6 2979 nsec
test_l4lb:PASS:ipv4 921 nsec
test_l4lb:PASS:ipv6 717 nsec
Summary: 6 PASSED, 0 FAILED
[root@apoc bpf]#
BPF samples:
[root@apoc bpf]# make > /dev/null
In file included from /root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:54:0:
/root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c: In function ‘prog_load’:
/root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:119:5: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, uid)),
^
/root/cilium/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro ‘BPF_STX_MEM’
.off = OFF, \
^
/root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:121:5: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, packets), 1),
^
/root/cilium/net-next/samples/bpf/libbpf.h:155:12: note: in definition of macro ‘BPF_ST_MEM’
.off = OFF, \
^
/root/cilium/net-next/samples/bpf/cookie_uid_helper_example.c:129:5: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, bytes)),
^
/root/cilium/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro ‘BPF_STX_MEM’
.off = OFF, \
^
[root@apoc bpf]#
Above warning is from 51570a5ab2b7 ("A Sample of using socket
cookie and uid for traffic monitoring"). I can see to send a
fix for it.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2 net-next] rhashtable: compact struct rhashtable_params
From: David Miller @ 2017-05-01 20:22 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170501201801.17344-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 1 May 2017 22:18:01 +0200
> By using smaller datatypes this (rather large) struct shrinks considerably
> (80 -> 48 bytes on x86_64).
>
> As this is embedded in other structs, this also rerduces size of several
> others, e.g. cls_fl_head or nft_hash.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> changes since v1: rebase on top of net-next master
>
> David, if its too late, just mark this as deferred in patchwork
> and I'll resubmit when net-next reopens.
It's fine, I asked you to respin.
Applied, thanks Florian.
^ permalink raw reply
* [PATCH v2 net-next] rhashtable: compact struct rhashtable_params
From: Florian Westphal @ 2017-05-01 20:18 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
By using smaller datatypes this (rather large) struct shrinks considerably
(80 -> 48 bytes on x86_64).
As this is embedded in other structs, this also rerduces size of several
others, e.g. cls_fl_head or nft_hash.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
changes since v1: rebase on top of net-next master
David, if its too late, just mark this as deferred in patchwork
and I'll resubmit when net-next reopens.
include/linux/rhashtable.h | 18 +++++++++---------
lib/rhashtable.c | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 45f89369c4c8..7d56a7ea2b2e 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -127,23 +127,23 @@ struct rhashtable;
* @head_offset: Offset of rhash_head in struct to be hashed
* @max_size: Maximum size while expanding
* @min_size: Minimum size while shrinking
- * @nulls_base: Base value to generate nulls marker
- * @automatic_shrinking: Enable automatic shrinking of tables
* @locks_mul: Number of bucket locks to allocate per cpu (default: 128)
+ * @automatic_shrinking: Enable automatic shrinking of tables
+ * @nulls_base: Base value to generate nulls marker
* @hashfn: Hash function (default: jhash2 if !(key_len % 4), or jhash)
* @obj_hashfn: Function to hash object
* @obj_cmpfn: Function to compare key with object
*/
struct rhashtable_params {
- size_t nelem_hint;
- size_t key_len;
- size_t key_offset;
- size_t head_offset;
+ u16 nelem_hint;
+ u16 key_len;
+ u16 key_offset;
+ u16 head_offset;
unsigned int max_size;
- unsigned int min_size;
- u32 nulls_base;
+ u16 min_size;
bool automatic_shrinking;
- size_t locks_mul;
+ u8 locks_mul;
+ u32 nulls_base;
rht_hashfn_t hashfn;
rht_obj_hashfn_t obj_hashfn;
rht_obj_cmpfn_t obj_cmpfn;
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 3895486ef551..a930e436db5d 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -967,7 +967,7 @@ int rhashtable_init(struct rhashtable *ht,
ht->max_elems = ht->p.max_size * 2;
}
- ht->p.min_size = max(ht->p.min_size, HASH_MIN_SIZE);
+ ht->p.min_size = max_t(u16, ht->p.min_size, HASH_MIN_SIZE);
if (params->nelem_hint)
size = rounded_hashtable_size(&ht->p);
--
2.10.2
^ permalink raw reply related
* Re: more bpf samples build breakage...
From: David Miller @ 2017-05-01 19:44 UTC (permalink / raw)
To: daniel; +Cc: netdev
In-Reply-To: <20170501.153005.983887567095122966.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 01 May 2017 15:30:05 -0400 (EDT)
>
> Inlcuding bpf_util.h into test_pkt_access.c et al. broke the build even
> more so than it already is on sparc.
>
> The problem is we end up including all the stdio.h bits and eventually
> hit things like:
>
> In file included from /usr/include/stdio.h:933:
> /usr/include/bits/stdio-ldbl.h:28:20: error: cannot apply asm label to function after its first use
> __LDBL_REDIR_DECL (vfprintf)
> ~~~~~~~~~~~~~~~~~~~^~~~~~~~~
> /usr/include/sys/cdefs.h:373:26: note: expanded from macro '__LDBL_REDIR_DECL'
> extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
>
> So please let's put CLANG compiled helpers into header files
> specifically meant to be included by CLANG compiled BPF programs
> rather than the host build environment.
I'm pushing the following quick fix for this for now:
>From bc1bafbbe9b3558d7789ff151ef4f185b6ad21f3 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Mon, 1 May 2017 12:43:49 -0700
Subject: [PATCH] bpf: Move endianness BPF helpers out of bpf_util.h
We do not want to include things like stdio.h and friends into
eBPF program builds. bpf_util.h is for host compiled programs,
so eBPF C-code helpers don't really belong there.
Add a new bpf_endian.h as a quick fix for this for now.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
tools/testing/selftests/bpf/bpf_endian.h | 23 +++++++++++++++++++++++
tools/testing/selftests/bpf/bpf_util.h | 19 -------------------
tools/testing/selftests/bpf/test_l4lb.c | 2 +-
tools/testing/selftests/bpf/test_pkt_access.c | 2 +-
4 files changed, 25 insertions(+), 21 deletions(-)
create mode 100644 tools/testing/selftests/bpf/bpf_endian.h
diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/tools/testing/selftests/bpf/bpf_endian.h
new file mode 100644
index 0000000..19d0604
--- /dev/null
+++ b/tools/testing/selftests/bpf/bpf_endian.h
@@ -0,0 +1,23 @@
+#ifndef __BPF_ENDIAN__
+#define __BPF_ENDIAN__
+
+#include <asm/byteorder.h>
+
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+# define __bpf_ntohs(x) __builtin_bswap16(x)
+# define __bpf_htons(x) __builtin_bswap16(x)
+#elif __BYTE_ORDER == __BIG_ENDIAN
+# define __bpf_ntohs(x) (x)
+# define __bpf_htons(x) (x)
+#else
+# error "Fix your __BYTE_ORDER?!"
+#endif
+
+#define bpf_htons(x) \
+ (__builtin_constant_p(x) ? \
+ __constant_htons(x) : __bpf_htons(x))
+#define bpf_ntohs(x) \
+ (__builtin_constant_p(x) ? \
+ __constant_ntohs(x) : __bpf_ntohs(x))
+
+#endif
diff --git a/tools/testing/selftests/bpf/bpf_util.h b/tools/testing/selftests/bpf/bpf_util.h
index 369e7d7..20ecbaa 100644
--- a/tools/testing/selftests/bpf/bpf_util.h
+++ b/tools/testing/selftests/bpf/bpf_util.h
@@ -6,25 +6,6 @@
#include <string.h>
#include <errno.h>
-#include <asm/byteorder.h>
-
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-# define __bpf_ntohs(x) __builtin_bswap16(x)
-# define __bpf_htons(x) __builtin_bswap16(x)
-#elif __BYTE_ORDER == __BIG_ENDIAN
-# define __bpf_ntohs(x) (x)
-# define __bpf_htons(x) (x)
-#else
-# error "Fix your __BYTE_ORDER?!"
-#endif
-
-#define bpf_htons(x) \
- (__builtin_constant_p(x) ? \
- __constant_htons(x) : __bpf_htons(x))
-#define bpf_ntohs(x) \
- (__builtin_constant_p(x) ? \
- __constant_ntohs(x) : __bpf_ntohs(x))
-
static inline unsigned int bpf_num_possible_cpus(void)
{
static const char *fcpu = "/sys/devices/system/cpu/possible";
diff --git a/tools/testing/selftests/bpf/test_l4lb.c b/tools/testing/selftests/bpf/test_l4lb.c
index b68b212..1e10c95 100644
--- a/tools/testing/selftests/bpf/test_l4lb.c
+++ b/tools/testing/selftests/bpf/test_l4lb.c
@@ -19,7 +19,7 @@
#include <linux/udp.h>
#include "bpf_helpers.h"
#include "test_iptunnel_common.h"
-#include "bpf_util.h"
+#include "bpf_endian.h"
int _version SEC("version") = 1;
diff --git a/tools/testing/selftests/bpf/test_pkt_access.c b/tools/testing/selftests/bpf/test_pkt_access.c
index 7113005..39387bb 100644
--- a/tools/testing/selftests/bpf/test_pkt_access.c
+++ b/tools/testing/selftests/bpf/test_pkt_access.c
@@ -14,7 +14,7 @@
#include <linux/tcp.h>
#include <linux/pkt_cls.h>
#include "bpf_helpers.h"
-#include "bpf_util.h"
+#include "bpf_endian.h"
#define barrier() __asm__ __volatile__("": : :"memory")
int _version SEC("version") = 1;
--
2.1.2.532.g19b5d50
^ permalink raw reply related
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: carl h @ 2017-05-01 19:35 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, netdev
In-Reply-To: <20170501192957.GA18265@lunn.ch>
I was afraid you were going to say that.
Thanks anyways Andrew.
On Mon, May 1, 2017 at 3:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 01, 2017 at 02:26:52PM -0400, carl h wrote:
>> It appears that the switchdev driver model was introduced after 2.6.39
>> which is the
>> kernel version that I'm using unfortunately.
>
> We cannot help you much is you are using an ancient kernel. Please
> upgrade.
>
> Andrew
^ permalink raw reply
* Re: [PATCH] ipv6: Need to export ipv6_push_frag_opts for tunneling now.
From: Craig Gallek @ 2017-05-01 19:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170501.151109.1682060890683033268.davem@davemloft.net>
On Mon, May 1, 2017 at 3:11 PM, David Miller <davem@davemloft.net> wrote:
>
> Since that change also made the nfrag function not necessary
> for exports, remove it.
>
> Fixes: 89a23c8b528b ("ip6_tunnel: Fix missing tunnel encapsulation limit option")
> Signed-off-by: David S. Miller <davem@davemloft.net>
Woops, sorry I missed this. Thanks for the fix!
Acked-by: Craig Gallek <kraig@google.com>
^ permalink raw reply
* more bpf samples build breakage...
From: David Miller @ 2017-05-01 19:30 UTC (permalink / raw)
To: daniel; +Cc: netdev
Inlcuding bpf_util.h into test_pkt_access.c et al. broke the build even
more so than it already is on sparc.
The problem is we end up including all the stdio.h bits and eventually
hit things like:
In file included from /usr/include/stdio.h:933:
/usr/include/bits/stdio-ldbl.h:28:20: error: cannot apply asm label to function after its first use
__LDBL_REDIR_DECL (vfprintf)
~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/usr/include/sys/cdefs.h:373:26: note: expanded from macro '__LDBL_REDIR_DECL'
extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
So please let's put CLANG compiled helpers into header files
specifically meant to be included by CLANG compiled BPF programs
rather than the host build environment.
^ permalink raw reply
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: Andrew Lunn @ 2017-05-01 19:29 UTC (permalink / raw)
To: carl h; +Cc: David Miller, netdev
In-Reply-To: <CABM+yxnbLPjoq4E2Z3d2Jc5qUvN_TWUb6rQpjDWCTs=9j0ce3A@mail.gmail.com>
On Mon, May 01, 2017 at 02:26:52PM -0400, carl h wrote:
> It appears that the switchdev driver model was introduced after 2.6.39
> which is the
> kernel version that I'm using unfortunately.
We cannot help you much is you are using an ancient kernel. Please
upgrade.
Andrew
^ permalink raw reply
* Re: pull request: bluetooth-next 2017-04-30
From: Johan Hedberg @ 2017-05-01 19:21 UTC (permalink / raw)
To: David Miller; +Cc: linux-bluetooth, netdev
In-Reply-To: <20170501.145019.1619484787513762409.davem@davemloft.net>
On Mon, May 01, 2017, David Miller wrote:
> From: Johan Hedberg <johan.hedberg@gmail.com>
> Date: Mon, 1 May 2017 21:42:21 +0300
>
> > Hi Dave,
> >
> > On Sun, Apr 30, 2017, David Miller wrote:
> >> From: Johan Hedberg <johan.hedberg@gmail.com>
> >> Date: Sun, 30 Apr 2017 17:09:28 +0300
> >>
> >> > Here's one last batch of Bluetooth patches in the bluetooth-next tree
> >> > targeting the 4.12 kernel.
> >> >
> >> > - Remove custom ECDH implementation and use new KPP API instead
> >> > - Add protocol checks to hci_ldisc
> >> > - Add module license to HCI UART Nokia H4+ driver
> >> > - Minor fix for 32bit user space - 64 bit kernel combination
> >> >
> >> > Please let me know if there are any issues pulling. Thanks.
> >>
> >> Pulled, thanks Johan.
> >
> > Thanks, however I don't see the patches in net-next yet. I have seen
> > other patches go in there since your response though. Cause for concern?
>
> Shuld be there now.
Looks good now. Thanks.
Johan
^ permalink raw reply
* Re: Question about tcp_mark_lost_retrans
From: Joe Smith @ 2017-05-01 19:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170501.151042.1997320785999410909.davem@davemloft.net>
Thanks Dave. I was looking at linux-stable-v4.11-rc7. I will sync up.
On Mon, May 1, 2017 at 12:10 PM, David Miller <davem@davemloft.net> wrote:
> From: Joe Smith <codesoldier1@gmail.com>
> Date: Mon, 1 May 2017 12:01:33 -0700
>
>> static void tcp_mark_lost_retrans(struct sock *sk)
>
> This function no longer exists in the tree.
--
JS
^ permalink raw reply
* [PATCH] ipv6: Need to export ipv6_push_frag_opts for tunneling now.
From: David Miller @ 2017-05-01 19:11 UTC (permalink / raw)
To: cgallek; +Cc: netdev
Since that change also made the nfrag function not necessary
for exports, remove it.
Fixes: 89a23c8b528b ("ip6_tunnel: Fix missing tunnel encapsulation limit option")
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv6/exthdrs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index d32e211..b636f1da 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -946,13 +946,13 @@ void ipv6_push_nfrag_opts(struct sk_buff *skb, struct ipv6_txoptions *opt,
if (opt->hopopt)
ipv6_push_exthdr(skb, proto, NEXTHDR_HOP, opt->hopopt);
}
-EXPORT_SYMBOL(ipv6_push_nfrag_opts);
void ipv6_push_frag_opts(struct sk_buff *skb, struct ipv6_txoptions *opt, u8 *proto)
{
if (opt->dst1opt)
ipv6_push_exthdr(skb, proto, NEXTHDR_DEST, opt->dst1opt);
}
+EXPORT_SYMBOL(ipv6_push_frag_opts);
struct ipv6_txoptions *
ipv6_dup_options(struct sock *sk, struct ipv6_txoptions *opt)
--
2.4.11
^ permalink raw reply related
* Re: Question about tcp_mark_lost_retrans
From: David Miller @ 2017-05-01 19:10 UTC (permalink / raw)
To: codesoldier1; +Cc: netdev
In-Reply-To: <CABGNecwM2eDJpPLMQZZ3DCsGDO4ktsX-R43dvgTQkd1Etq+WjA@mail.gmail.com>
From: Joe Smith <codesoldier1@gmail.com>
Date: Mon, 1 May 2017 12:01:33 -0700
> static void tcp_mark_lost_retrans(struct sock *sk)
This function no longer exists in the tree.
^ 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