* [Patch net 0/2] net: hns3: bug fix & optimization for HNS3 driver
From: Huazhong Tan @ 2018-08-23 3:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
This patchset presents a bug fix found out when CONFIG_ARM64_64K_PAGES
enable and an optimization for HNS3 driver.
Huazhong Tan (2):
net: hns3: fix page_offset overflow when CONFIG_ARM64_64K_PAGES
net: hns3: modify variable type in hns3_nic_reuse_page
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply
* [Patch net 1/2] net: hns3: fix page_offset overflow when CONFIG_ARM64_64K_PAGES
From: Huazhong Tan @ 2018-08-23 3:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
In-Reply-To: <1534995436-25259-1-git-send-email-tanhuazhong@huawei.com>
When enable the config item "CONFIG_ARM64_64K_PAGES", the size of
PAGE_SIZE is 65536(64K). But the type of page_offset is u16, it will
overflow. So change it to u32, when "CONFIG_ARM64_64K_PAGES" enabled.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index a02a96a..cb450d7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -284,11 +284,11 @@ struct hns3_desc_cb {
/* priv data for the desc, e.g. skb when use with ip stack*/
void *priv;
- u16 page_offset;
- u16 reuse_flag;
-
+ u32 page_offset;
u32 length; /* length of the buffer */
+ u16 reuse_flag;
+
/* desc type, used by the ring user to mark the type of the priv data */
u16 type;
};
--
1.9.1
^ permalink raw reply related
* [Patch net 2/2] net: hns3: modify variable type in hns3_nic_reuse_page
From: Huazhong Tan @ 2018-08-23 3:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
In-Reply-To: <1534995436-25259-1-git-send-email-tanhuazhong@huawei.com>
'truesize' is supposed to be u32, not int, so fix it.
Signed-off-by: Huazhong tan <tanhuazhong@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 3554dca..955c4ab 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2019,7 +2019,8 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int i,
struct hns3_desc_cb *desc_cb)
{
struct hns3_desc *desc;
- int truesize, size;
+ u32 truesize;
+ int size;
int last_offset;
bool twobufs;
--
1.9.1
^ permalink raw reply related
* [PATCH] net/ipv6: init ip6 anycast rt->dst.input as ip6_input
From: Hangbin Liu @ 2018-08-23 3:31 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, David S. Miller, Hangbin Liu
Commit 6edb3c96a5f02 ("net/ipv6: Defer initialization of dst to data path")
forgot to handle anycast route and init anycast rt->dst.input to ip6_forward.
Fix it by setting anycast rt->dst.input back to ip6_input.
Fixes: 6edb3c96a5f02 ("net/ipv6: Defer initialization of dst to data path")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 7208c16..c4ea13e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -956,7 +956,7 @@ static void ip6_rt_init_dst(struct rt6_info *rt, struct fib6_info *ort)
rt->dst.error = 0;
rt->dst.output = ip6_output;
- if (ort->fib6_type == RTN_LOCAL) {
+ if (ort->fib6_type == RTN_LOCAL || ort->fib6_type == RTN_ANYCAST) {
rt->dst.input = ip6_input;
} else if (ipv6_addr_type(&ort->fib6_dst.addr) & IPV6_ADDR_MULTICAST) {
rt->dst.input = ip6_mc_input;
--
2.5.5
^ permalink raw reply related
* [Patch net 3/4] net: hns: fix skb->truesize underestimation
From: Huazhong Tan @ 2018-08-23 3:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
In-Reply-To: <1534993813-236850-1-git-send-email-tanhuazhong@huawei.com>
skb->truesize is not meant to be tracking amount of used bytes in a skb,
but amount of reserved/consumed bytes in memory.
For instance, if we use a single byte in last page fragment, we have to
account the full size of the fragment.
So skb_add_rx_frag needs to calculate the length of the entire buffer into
turesize.
Fixes: 9cbe9fd5214e ("net: hns: optimize XGE capability by reducing cpu usage")
Signed-off-by: Huazhong tan <tanhuazhong@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index c8c0b03..71bd3bf 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -531,7 +531,7 @@ static void hns_nic_reuse_page(struct sk_buff *skb, int i,
}
skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
- size - pull_len, truesize - pull_len);
+ size - pull_len, truesize);
/* avoid re-using remote pages,flag default unreuse */
if (unlikely(page_to_nid(desc_cb->priv) != numa_node_id()))
--
1.9.1
^ permalink raw reply related
* [Patch net 0/4] net: hns: bug fixes & optimization for HNS driver
From: Huazhong Tan @ 2018-08-23 3:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
This patchset presents some bug fixes found out when CONFIG_ARM64_64K_PAGES
enable and an optimization for HNS driver.
Huazhong Tan (4):
net: hns: fix length and page_offset overflow when
CONFIG_ARM64_64K_PAGES
net: hns: modify variable type in hns_nic_reuse_page
net: hns: fix skb->truesize underestimation
net: hns: use eth_get_headlen interface instead of hns_nic_get_headlen
drivers/net/ethernet/hisilicon/hns/hnae.h | 6 +-
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 108 +-------------------------
2 files changed, 7 insertions(+), 107 deletions(-)
--
1.9.1
^ permalink raw reply
* [Patch net 4/4] net: hns: use eth_get_headlen interface instead of hns_nic_get_headlen
From: Huazhong Tan @ 2018-08-23 3:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
In-Reply-To: <1534993813-236850-1-git-send-email-tanhuazhong@huawei.com>
Update hns to drop the hns_nic_get_headlen function in favour of
eth_get_headlen, and hence also removes now redundant hns_nic_get_headlen.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 103 +-------------------------
1 file changed, 1 insertion(+), 102 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 71bd3bf..02a0ba2 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -406,107 +406,6 @@ netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
return NETDEV_TX_BUSY;
}
-/**
- * hns_nic_get_headlen - determine size of header for RSC/LRO/GRO/FCOE
- * @data: pointer to the start of the headers
- * @max: total length of section to find headers in
- *
- * This function is meant to determine the length of headers that will
- * be recognized by hardware for LRO, GRO, and RSC offloads. The main
- * motivation of doing this is to only perform one pull for IPv4 TCP
- * packets so that we can do basic things like calculating the gso_size
- * based on the average data per packet.
- **/
-static unsigned int hns_nic_get_headlen(unsigned char *data, u32 flag,
- unsigned int max_size)
-{
- unsigned char *network;
- u8 hlen;
-
- /* this should never happen, but better safe than sorry */
- if (max_size < ETH_HLEN)
- return max_size;
-
- /* initialize network frame pointer */
- network = data;
-
- /* set first protocol and move network header forward */
- network += ETH_HLEN;
-
- /* handle any vlan tag if present */
- if (hnae_get_field(flag, HNS_RXD_VLAN_M, HNS_RXD_VLAN_S)
- == HNS_RX_FLAG_VLAN_PRESENT) {
- if ((typeof(max_size))(network - data) > (max_size - VLAN_HLEN))
- return max_size;
-
- network += VLAN_HLEN;
- }
-
- /* handle L3 protocols */
- if (hnae_get_field(flag, HNS_RXD_L3ID_M, HNS_RXD_L3ID_S)
- == HNS_RX_FLAG_L3ID_IPV4) {
- if ((typeof(max_size))(network - data) >
- (max_size - sizeof(struct iphdr)))
- return max_size;
-
- /* access ihl as a u8 to avoid unaligned access on ia64 */
- hlen = (network[0] & 0x0F) << 2;
-
- /* verify hlen meets minimum size requirements */
- if (hlen < sizeof(struct iphdr))
- return network - data;
-
- /* record next protocol if header is present */
- } else if (hnae_get_field(flag, HNS_RXD_L3ID_M, HNS_RXD_L3ID_S)
- == HNS_RX_FLAG_L3ID_IPV6) {
- if ((typeof(max_size))(network - data) >
- (max_size - sizeof(struct ipv6hdr)))
- return max_size;
-
- /* record next protocol */
- hlen = sizeof(struct ipv6hdr);
- } else {
- return network - data;
- }
-
- /* relocate pointer to start of L4 header */
- network += hlen;
-
- /* finally sort out TCP/UDP */
- if (hnae_get_field(flag, HNS_RXD_L4ID_M, HNS_RXD_L4ID_S)
- == HNS_RX_FLAG_L4ID_TCP) {
- if ((typeof(max_size))(network - data) >
- (max_size - sizeof(struct tcphdr)))
- return max_size;
-
- /* access doff as a u8 to avoid unaligned access on ia64 */
- hlen = (network[12] & 0xF0) >> 2;
-
- /* verify hlen meets minimum size requirements */
- if (hlen < sizeof(struct tcphdr))
- return network - data;
-
- network += hlen;
- } else if (hnae_get_field(flag, HNS_RXD_L4ID_M, HNS_RXD_L4ID_S)
- == HNS_RX_FLAG_L4ID_UDP) {
- if ((typeof(max_size))(network - data) >
- (max_size - sizeof(struct udphdr)))
- return max_size;
-
- network += sizeof(struct udphdr);
- }
-
- /* If everything has gone correctly network should be the
- * data section of the packet and will be the end of the header.
- * If not then it probably represents the end of the last recognized
- * header.
- */
- if ((typeof(max_size))(network - data) < max_size)
- return network - data;
- else
- return max_size;
-}
-
static void hns_nic_reuse_page(struct sk_buff *skb, int i,
struct hnae_ring *ring, int pull_len,
struct hnae_desc_cb *desc_cb)
@@ -696,7 +595,7 @@ static int hns_nic_poll_rx_skb(struct hns_nic_ring_data *ring_data,
} else {
ring->stats.seg_pkt_cnt++;
- pull_len = hns_nic_get_headlen(va, bnum_flag, HNS_RX_HEAD_SIZE);
+ pull_len = eth_get_headlen(va, HNS_RX_HEAD_SIZE);
memcpy(__skb_put(skb, pull_len), va,
ALIGN(pull_len, sizeof(long)));
--
1.9.1
^ permalink raw reply related
* [Patch net 2/4] net: hns: modify variable type in hns_nic_reuse_page
From: Huazhong Tan @ 2018-08-23 3:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
In-Reply-To: <1534993813-236850-1-git-send-email-tanhuazhong@huawei.com>
'truesize' is supposed to be u32, not int, so fix it.
Signed-off-by: Huazhong tan <tanhuazhong@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 9f2b552..c8c0b03 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -512,7 +512,8 @@ static void hns_nic_reuse_page(struct sk_buff *skb, int i,
struct hnae_desc_cb *desc_cb)
{
struct hnae_desc *desc;
- int truesize, size;
+ u32 truesize;
+ int size;
int last_offset;
bool twobufs;
--
1.9.1
^ permalink raw reply related
* [Patch net 1/4] net: hns: fix length and page_offset overflow when CONFIG_ARM64_64K_PAGES
From: Huazhong Tan @ 2018-08-23 3:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
tanhuazhong
In-Reply-To: <1534993813-236850-1-git-send-email-tanhuazhong@huawei.com>
When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE
is 65536(64K). But the type of length and page_offset are u16, they will
overflow. So change them to u32.
Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h b/drivers/net/ethernet/hisilicon/hns/hnae.h
index fa5b30f..cad52bd 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -220,10 +220,10 @@ struct hnae_desc_cb {
/* priv data for the desc, e.g. skb when use with ip stack*/
void *priv;
- u16 page_offset;
- u16 reuse_flag;
+ u32 page_offset;
+ u32 length; /* length of the buffer */
- u16 length; /* length of the buffer */
+ u16 reuse_flag;
/* desc type, used by the ring user to mark the type of the priv data */
u16 type;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ath9k: turn on btcoex_enable as default
From: Kai-Heng Feng @ 2018-08-23 1:33 UTC (permalink / raw)
To: Felix Fietkau
Cc: Kalle Valo, ath9k-devel, linux-wireless, netdev, linux-kernel
In-Reply-To: <6A0F65EF-A7C4-469F-8FAF-CBE314676237@canonical.com>
at 12:15, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
>
>
>> On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>
>> On 2018-02-10 14:56, Kai Heng Feng wrote:
>>>> On 9 Feb 2018, at 3:16 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>> Sure, but we have to make sure that we don't create regressions on
>>>> existing systems. For example, did you test this with any system which
>>>> don't support btcoex? (just asking, haven't tested this myself)
>>>
>>> No not really, but I will definitely test it.
>>> The only module I have that uses ath9k is Dell’s DW1707.
>>> How do I check if it support btcoex or not?
>> I just reviewed the code again, and I am sure that we cannot merge this
>> patch. Enabling the btcoex parameter makes the driver enable a whole
>> bunch of code starting timers, listening to some GPIOs, etc.
>>
>> On non-btcoex systems, some of those GPIOs might be floating or even
>> connected to different things, which could cause a lot of undefined
>> behavior.
>>
>> This is simply too big a risk, so there absolutely needs to be a
>> whitelist for systems that need this, otherwise it has to remain
>> disabled by default.
>
> So what information can we use to whitelist btcoex chips?
> Can we get btcoex support status at ath9k probing?
Sorry for bringing this up again.
Is DMI based match an acceptable approach for ath9k?
Kai-Heng
>
> Kai-Heng
>
>> - Felix
^ permalink raw reply
* Re: [PATCH net] net/ncsi: Fixup .dumpit message flags and ID check in Netlink handler
From: David Miller @ 2018-08-23 4:39 UTC (permalink / raw)
To: sam; +Cc: netdev, linux-kernel, openbmc
In-Reply-To: <20180822045744.9267-1-sam@mendozajonas.com>
From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Date: Wed, 22 Aug 2018 14:57:44 +1000
> The ncsi_pkg_info_all_nl() .dumpit handler is missing the NLM_F_MULTI
> flag, causing additional package information after the first to be lost.
> Also fixup a sanity check in ncsi_write_package_info() to reject out of
> range package IDs.
>
> Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 06/11] net: ethernet: renesas: use SPDX identifier for Renesas drivers
From: David Miller @ 2018-08-23 4:38 UTC (permalink / raw)
To: wsa+renesas
Cc: linux-renesas-soc, kuninori.morimoto.gx, sergei.shtylyov, netdev,
linux-kernel
In-Reply-To: <20180821220233.9202-7-wsa+renesas@sang-engineering.com>
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date: Wed, 22 Aug 2018 00:02:19 +0200
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Applied.
^ permalink raw reply
* [PATCHv3 iproute2 2/2] iproute: make clang happy
From: Mahesh Bandewar @ 2018-08-23 1:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
These are primarily fixes for "string is not string literal" warnings
/ errors (with -Werror -Wformat-nonliteral). This should be a no-op
change. I had to replace couple of print helper functions with the
code they call as it was becoming harder to eliminate these warnings,
however these helpers were used only at couple of places, so no
major change as such.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
include/json_writer.h | 3 +--
ip/iplink_can.c | 19 ++++++++++++-------
lib/color.c | 1 +
lib/json_print.c | 1 +
lib/json_writer.c | 15 +--------------
misc/ss.c | 3 ++-
tc/m_ematch.c | 1 +
tc/m_ematch.h | 1 +
8 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/include/json_writer.h b/include/json_writer.h
index 9ab88e1dbdd9..0c8831c1136d 100644
--- a/include/json_writer.h
+++ b/include/json_writer.h
@@ -29,6 +29,7 @@ void jsonw_pretty(json_writer_t *self, bool on);
void jsonw_name(json_writer_t *self, const char *name);
/* Add value */
+__attribute__((format(printf, 2, 3)))
void jsonw_printf(json_writer_t *self, const char *fmt, ...);
void jsonw_string(json_writer_t *self, const char *value);
void jsonw_bool(json_writer_t *self, bool value);
@@ -59,8 +60,6 @@ void jsonw_luint_field(json_writer_t *self, const char *prop,
unsigned long int num);
void jsonw_lluint_field(json_writer_t *self, const char *prop,
unsigned long long int num);
-void jsonw_float_field_fmt(json_writer_t *self, const char *prop,
- const char *fmt, double val);
/* Collections */
void jsonw_start_object(json_writer_t *self);
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index 587413da15c4..c0deeb1f1fcf 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -316,11 +316,14 @@ static void can_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
struct can_bittiming *bt = RTA_DATA(tb[IFLA_CAN_BITTIMING]);
if (is_json_context()) {
+ json_writer_t *jw;
+
open_json_object("bittiming");
print_int(PRINT_ANY, "bitrate", NULL, bt->bitrate);
- jsonw_float_field_fmt(get_json_writer(),
- "sample_point", "%.3f",
- (float) bt->sample_point / 1000.);
+ jw = get_json_writer();
+ jsonw_name(jw, "sample_point");
+ jsonw_printf(jw, "%.3f",
+ (float) bt->sample_point / 1000);
print_int(PRINT_ANY, "tq", NULL, bt->tq);
print_int(PRINT_ANY, "prop_seg", NULL, bt->prop_seg);
print_int(PRINT_ANY, "phase_seg1",
@@ -415,12 +418,14 @@ static void can_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
RTA_DATA(tb[IFLA_CAN_DATA_BITTIMING]);
if (is_json_context()) {
+ json_writer_t *jw;
+
open_json_object("data_bittiming");
print_int(PRINT_JSON, "bitrate", NULL, dbt->bitrate);
- jsonw_float_field_fmt(get_json_writer(),
- "sample_point",
- "%.3f",
- (float) dbt->sample_point / 1000.);
+ jw = get_json_writer();
+ jsonw_name(jw, "sample_point");
+ jsonw_printf(jw, "%.3f",
+ (float) dbt->sample_point / 1000.);
print_int(PRINT_JSON, "tq", NULL, dbt->tq);
print_int(PRINT_JSON, "prop_seg", NULL, dbt->prop_seg);
print_int(PRINT_JSON, "phase_seg1",
diff --git a/lib/color.c b/lib/color.c
index eaf69e74d673..e5406294dfc4 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -132,6 +132,7 @@ void set_color_palette(void)
is_dark_bg = 1;
}
+__attribute__((format(printf, 3, 4)))
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...)
{
int ret = 0;
diff --git a/lib/json_print.c b/lib/json_print.c
index 5dc41bfabfd4..77902824a738 100644
--- a/lib/json_print.c
+++ b/lib/json_print.c
@@ -100,6 +100,7 @@ void close_json_array(enum output_type type, const char *str)
* functions handling different types
*/
#define _PRINT_FUNC(type_name, type) \
+ __attribute__((format(printf, 4, 0))) \
void print_color_##type_name(enum output_type t, \
enum color_attr color, \
const char *key, \
diff --git a/lib/json_writer.c b/lib/json_writer.c
index aa9ce1c65e51..68890b34ee92 100644
--- a/lib/json_writer.c
+++ b/lib/json_writer.c
@@ -152,6 +152,7 @@ void jsonw_name(json_writer_t *self, const char *name)
putc(' ', self->out);
}
+__attribute__((format(printf, 2, 3)))
void jsonw_printf(json_writer_t *self, const char *fmt, ...)
{
va_list ap;
@@ -205,11 +206,6 @@ void jsonw_null(json_writer_t *self)
jsonw_printf(self, "null");
}
-void jsonw_float_fmt(json_writer_t *self, const char *fmt, double num)
-{
- jsonw_printf(self, fmt, num);
-}
-
void jsonw_float(json_writer_t *self, double num)
{
jsonw_printf(self, "%g", num);
@@ -274,15 +270,6 @@ void jsonw_float_field(json_writer_t *self, const char *prop, double val)
jsonw_float(self, val);
}
-void jsonw_float_field_fmt(json_writer_t *self,
- const char *prop,
- const char *fmt,
- double val)
-{
- jsonw_name(self, prop);
- jsonw_float_fmt(self, fmt, val);
-}
-
void jsonw_uint_field(json_writer_t *self, const char *prop, unsigned int num)
{
jsonw_name(self, prop);
diff --git a/misc/ss.c b/misc/ss.c
index 41e7762bb61f..93b1baf5dc40 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -976,6 +976,7 @@ static int buf_update(int len)
}
/* Append content to buffer as part of the current field */
+__attribute__((format(printf, 1, 2)))
static void out(const char *fmt, ...)
{
struct column *f = current_field;
@@ -1093,7 +1094,7 @@ static void print_header(void)
{
while (!field_is_last(current_field)) {
if (!current_field->disabled)
- out(current_field->header);
+ out("%s", current_field->header);
field_next();
}
}
diff --git a/tc/m_ematch.c b/tc/m_ematch.c
index ace4b3dd738b..a524b520b276 100644
--- a/tc/m_ematch.c
+++ b/tc/m_ematch.c
@@ -277,6 +277,7 @@ static int flatten_tree(struct ematch *head, struct ematch *tree)
return count;
}
+__attribute__((format(printf, 5, 6)))
int em_parse_error(int err, struct bstr *args, struct bstr *carg,
struct ematch_util *e, char *fmt, ...)
{
diff --git a/tc/m_ematch.h b/tc/m_ematch.h
index ff02d7ac9112..356f2eded7fc 100644
--- a/tc/m_ematch.h
+++ b/tc/m_ematch.h
@@ -102,6 +102,7 @@ static inline int parse_layer(const struct bstr *b)
return INT_MAX;
}
+__attribute__((format(printf, 5, 6)))
int em_parse_error(int err, struct bstr *args, struct bstr *carg,
struct ematch_util *, char *fmt, ...);
int print_ematch(FILE *, const struct rtattr *);
--
2.18.0.1017.ga543ac7ca45-goog
^ permalink raw reply related
* [PATCHv3 iproute2 1/2] ipmaddr: use preferred_family when given
From: Mahesh Bandewar @ 2018-08-23 1:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
When creating socket() AF_INET is used irrespective of the family
that is given at the command-line (with -4, -6, or -0). This change
will open the socket with the preferred family.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
ip/ipmaddr.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index a48499029e17..abf83784d0df 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -289,6 +289,7 @@ static int multiaddr_list(int argc, char **argv)
static int multiaddr_modify(int cmd, int argc, char **argv)
{
struct ifreq ifr = {};
+ int family;
int fd;
if (cmd == RTM_NEWADDR)
@@ -324,7 +325,17 @@ static int multiaddr_modify(int cmd, int argc, char **argv)
exit(-1);
}
- fd = socket(AF_INET, SOCK_DGRAM, 0);
+ switch (preferred_family) {
+ case AF_INET6:
+ case AF_PACKET:
+ case AF_INET:
+ family = preferred_family;
+ break;
+ default:
+ family = AF_INET;
+ }
+
+ fd = socket(family, SOCK_DGRAM, 0);
if (fd < 0) {
perror("Cannot create socket");
exit(1);
--
2.18.0.1017.ga543ac7ca45-goog
^ permalink raw reply related
* [PATCHv3 iproute2 0/2] clang + misc changes
From: Mahesh Bandewar @ 2018-08-23 1:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
The primary theme is to make clang compile the iproute2 package without
warnings. Along with this there are two other misc patches in the series.
First patch uses the preferred_family when operating with maddr feature.
Prior to this patch, it would always open an AF_INET socket irrespective
of the family that is preferred via command-line.
Second patch mostly adds format attributes to make the c-lang compiler
happy and not throw the warning messages.
Mahesh Bandewar (2):
ipmaddr: use preferred_family when given
iproute: make clang happy with iproute2 package
include/json_writer.h | 3 +--
ip/iplink_can.c | 19 ++++++++++++-------
ip/ipmaddr.c | 13 ++++++++++++-
lib/color.c | 1 +
lib/json_print.c | 1 +
lib/json_writer.c | 15 +--------------
misc/ss.c | 3 ++-
tc/m_ematch.c | 1 +
tc/m_ematch.h | 1 +
9 files changed, 32 insertions(+), 25 deletions(-)
--
2.18.0.1017.ga543ac7ca45-goog
^ permalink raw reply
* Re: [bpf-next RFC 0/3] Introduce eBPF flow dissector
From: Petar Penkov @ 2018-08-23 0:10 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Petar Penkov, Networking, David S . Miller,
Alexei Starovoitov, simon.horman, Willem de Bruijn
In-Reply-To: <219f3285-615f-8e95-fa67-de6bdab44c08@iogearbox.net>
On Wed, Aug 22, 2018 at 12:28 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> "On 08/22/2018 09:22 AM, Daniel Borkmann wrote:
>> On 08/22/2018 02:19 AM, Petar Penkov wrote:
>>> On Mon, Aug 20, 2018 at 1:52 PM, Alexei Starovoitov
>>> <alexei.starovoitov@gmail.com> wrote:
>>>> On Thu, Aug 16, 2018 at 09:44:20AM -0700, Petar Penkov wrote:
>>>>> From: Petar Penkov <ppenkov@google.com>
>> [...]
>>>>> 3/ The BPF program cannot use direct packet access everywhere because it
>>>>> uses an offset, initially supplied by the flow dissector. Because the
>>>>> initial value of this non-constant offset comes from outside of the
>>>>> program, the verifier does not know what its value is, and it cannot verify
>>>>> that it is within packet bounds. Therefore, direct packet access programs
>>>>> get rejected.
>>>>
>>>> this part doesn't seem to match the code.
>>>> direct packet access is allowed and usable even for fragmented skbs.
>>>> in such case only linear part of skb is in "direct access".
>>>
>>> I am not sure I understand. What I meant was that I use bpf_skb_load_bytes
>>> rather than direct packet access because the offset at which I read headers,
>>> nhoff, depends on an initial value that cannot be statically verified - namely
>>> what __skb_flow_dissect provides. Is there an alternative approach I should
>>> be taking here, and/or am I misunderstanding direct access?
>>
>> You can still use direct packet access with it, the only thing you would
>> need to make sure is that the initial offset is bounded (e.g. test if
>> larger than some const and then drop the packet, or '& <const>') so that
>> the verifier can make sure the alu op won't cause overflow, then you can
>> add this to pkt_data, and later on open an access range with the usual test
>> like pkt_data' + <const> > pkt_end.
>
> And for non-linear data, you could use the bpf_skb_pull_data() helper as
> we have in tc/BPF case 36bbef52c7eb ("bpf: direct packet write and access
> for helpers for clsact progs") to pull it into linear area and make it
> accessible for direct packet access.
>
>> Thanks,
>> Daniel
Thanks for the clarification! With direct packet access the flow
dissector in patch 2
is as fast as the in-kernel flow dissector when tested with the test in patch 3.
To bound the initial offset and use direct access I check if the
initial offset is larger
than 1500. This is sufficient for the verifier but I was wondering if there is a
better constant to use.
Thanks once again for your feedback,
Petar
^ permalink raw reply
* Re: ozlabs.org down?
From: Stephen Rothwell @ 2018-08-22 23:18 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andrew Donnellan, Jeff Kirsher, Jeremy Kerr, patchwork, netdev
In-Reply-To: <d5cc926d-7efe-d13e-c510-0383c86e5f46@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
Hi all,
On Wed, 22 Aug 2018 16:12:44 -0700 Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 08/22/2018 04:04 PM, Andrew Donnellan wrote:
> > On 23/08/18 02:12, Jeff Kirsher wrote:
> >> It appears the entire site is down, including patchworks. Is this
> >> expected? And for how long?
> >
> > + sfr
> >
> > It appears up for me right now.
> >
> > We've had a few dropouts over the last few weeks as a result of the upstream ISP having connectivity issues - it's possible that we've just hit that again.
> >
>
> I checked a few hours ago and it was down, but it's been up for over one hour
> now for me.
It hasn't actually been down for over 140 days, but our hosting company
has been having trouble with the router we are connected to and
replaced it a few days ago. I have no idea what happened this morning,
I will see if I can find out if these intermittent interruptions are
going to continue. :-(
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: ozlabs.org down?
From: Randy Dunlap @ 2018-08-22 23:12 UTC (permalink / raw)
To: Andrew Donnellan, Jeff Kirsher, Jeremy Kerr
Cc: patchwork, netdev, Stephen Rothwell
In-Reply-To: <66d14900-994d-a7ce-7054-d803089f0b84@au1.ibm.com>
On 08/22/2018 04:04 PM, Andrew Donnellan wrote:
> On 23/08/18 02:12, Jeff Kirsher wrote:
>> It appears the entire site is down, including patchworks. Is this
>> expected? And for how long?
>
> + sfr
>
> It appears up for me right now.
>
> We've had a few dropouts over the last few weeks as a result of the upstream ISP having connectivity issues - it's possible that we've just hit that again.
>
I checked a few hours ago and it was down, but it's been up for over one hour
now for me.
thanks.
--
~Randy
^ permalink raw reply
* Re: ozlabs.org down?
From: Andrew Donnellan @ 2018-08-22 23:04 UTC (permalink / raw)
To: Jeff Kirsher, Jeremy Kerr; +Cc: patchwork, netdev, Stephen Rothwell
In-Reply-To: <CAL3LdT6f7+dQbA_M_-L-XSwQ+XX5dG2ggT7U8dndH3dDTEg25A@mail.gmail.com>
On 23/08/18 02:12, Jeff Kirsher wrote:
> It appears the entire site is down, including patchworks. Is this
> expected? And for how long?
+ sfr
It appears up for me right now.
We've had a few dropouts over the last few weeks as a result of the
upstream ISP having connectivity issues - it's possible that we've just
hit that again.
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH next-queue 1/2] ixgbe: disallow ipsec tx offload when in sr-iov mode
From: Shannon Nelson @ 2018-08-22 22:59 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: steffen.klassert, netdev
There seems to be a problem in the x540's internal switch wherein if SR/IOV
mode is enabled and an offloaded IPsec packet is sent to a local VF,
the packet is silently dropped. This might never be a problem as it is
somewhat a corner case, but if someone happens to be using IPsec offload
from the PF to a VF that just happens to get migrated to the local box,
communication will mysteriously fail.
Not good.
A simple way to protect from this is to simply not allow any IPsec offloads
for outgoing packets when num_vfs != 0. This doesn't help any offloads that
were created before SR/IOV was enabled, but we'll get to that later.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 68395ab..24076b4 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -697,6 +697,9 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
} else {
struct tx_sa tsa;
+ if (adapter->num_vfs)
+ return -EOPNOTSUPP;
+
/* find the first unused index */
ret = ixgbe_ipsec_find_empty_idx(ipsec, false);
if (ret < 0) {
--
2.7.4
^ permalink raw reply related
* [PATCH next-queue 2/2] ixgbe: fix the return value for unsupported VF offload
From: Shannon Nelson @ 2018-08-22 22:59 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: steffen.klassert, netdev
In-Reply-To: <1534978781-25779-1-git-send-email-shannon.nelson@oracle.com>
When failing the request because we can't support that offload,
reporting EOPNOTSUPP makes much more sense than ENXIO.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 24076b4..7890f4a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -898,7 +898,7 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
* device, so block these requests for now.
*/
if (!(sam->flags & XFRM_OFFLOAD_INBOUND)) {
- err = -ENXIO;
+ err = -EOPNOTSUPP;
goto err_out;
}
--
2.7.4
^ permalink raw reply related
* Re: is "volatile" the cause of ifconfig flags not matching sysfs flags?
From: Stephen Hemminger @ 2018-08-22 22:53 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux kernel netdev mailing list
In-Reply-To: <alpine.LFD.2.21.1808221824460.5035@localhost.localdomain>
On Wed, 22 Aug 2018 18:32:36 -0400 (EDT)
"Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
> almost certainly another dumb question, but i was poking around the
> sysfs, particularly /sys/class/net/<ifname>/*, to familiarize myself
> with what i can glean (or set) re interfaces under /sys, and i noticed
> "flags", but what i get there doesn't match what i get by running
> ifconfig.
>
> specifically, if i list the flags for my wireless interface under
> /sys:
>
> $ cat flags
> 0x1003
> $
>
> but with ifconfig:
>
> $ ifconfig wlp2s0
> wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> ^^^^
>
> do those two "flags" values represent the same set of flags? and
> does the obvious difference have to do with some of those flags being
> "volatile" as dewscribed in include/uapi/linux/if.h? or am i just
> totally misreading this?
>
> rday
>
sysfs reports netdevice->if_flags where as ifconfig is getting hex
value from SIOCGIFFLAGS which does:
dev_get_flags(dev)
The value in sysfs is more intended for internal debugging, where all the
normal userspace API's return a more limited set of historical values.
^ permalink raw reply
* is "volatile" the cause of ifconfig flags not matching sysfs flags?
From: Robert P. J. Day @ 2018-08-22 22:32 UTC (permalink / raw)
To: Linux kernel netdev mailing list
almost certainly another dumb question, but i was poking around the
sysfs, particularly /sys/class/net/<ifname>/*, to familiarize myself
with what i can glean (or set) re interfaces under /sys, and i noticed
"flags", but what i get there doesn't match what i get by running
ifconfig.
specifically, if i list the flags for my wireless interface under
/sys:
$ cat flags
0x1003
$
but with ifconfig:
$ ifconfig wlp2s0
wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
^^^^
do those two "flags" values represent the same set of flags? and
does the obvious difference have to do with some of those flags being
"volatile" as dewscribed in include/uapi/linux/if.h? or am i just
totally misreading this?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [bpf PATCH 0/2] tls, sockmap, fixes for sk_wait_event
From: Daniel Borkmann @ 2018-08-22 21:52 UTC (permalink / raw)
To: John Fastabend, ast, davejwatson; +Cc: netdev, davem
In-Reply-To: <20180822153314.27968.72499.stgit@john-Precision-Tower-5810>
On 08/22/2018 05:37 PM, John Fastabend wrote:
> I have been testing ktls and sockmap lately and noticed that neither
> was handling sk_write_space events correctly. We need to ensure
> these events are pushed down to the lower layer in all cases to
> handle the case where the lower layer sendpage call has called
> sk_wait_event and needs to be woken up. Without this I see
> occosional stalls of sndtimeo length while we wait for the
> timeout value even though space is available.
>
> Two fixes below. Thanks.
>
> ---
>
> John Fastabend (2):
> tls: possible hang when do_tcp_sendpages hits sndbuf is full case
> bpf: sockmap: write_space events need to be passed to TCP handler
>
>
> kernel/bpf/sockmap.c | 3 +++
> net/tls/tls_main.c | 9 +++++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
Applied to bpf, thanks John!
^ permalink raw reply
* [PATCH bpf] bpf: use per htab salt for bucket hash
From: Daniel Borkmann @ 2018-08-22 21:49 UTC (permalink / raw)
To: alexei.starovoitov; +Cc: netdev, Daniel Borkmann
All BPF hash and LRU maps currently have a known and global seed
we feed into jhash() which is 0. This is suboptimal, thus fix it
by generating a random seed upon hashtab setup time which we can
later on feed into jhash() on lookup, update and deletions.
Fixes: 0f8e4bd8a1fc8 ("bpf: add hashtable type of eBPF maps")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/hashtab.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 04b8eda..03cc59e 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -15,6 +15,7 @@
#include <linux/jhash.h>
#include <linux/filter.h>
#include <linux/rculist_nulls.h>
+#include <linux/random.h>
#include <uapi/linux/btf.h>
#include "percpu_freelist.h"
#include "bpf_lru_list.h"
@@ -41,6 +42,7 @@ struct bpf_htab {
atomic_t count; /* number of elements in this hashtable */
u32 n_buckets; /* number of hash buckets */
u32 elem_size; /* size of each element in bytes */
+ u32 hashrnd;
};
/* each htab element is struct htab_elem + key + value */
@@ -371,6 +373,7 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
if (!htab->buckets)
goto free_htab;
+ htab->hashrnd = get_random_int();
for (i = 0; i < htab->n_buckets; i++) {
INIT_HLIST_NULLS_HEAD(&htab->buckets[i].head, i);
raw_spin_lock_init(&htab->buckets[i].lock);
@@ -402,9 +405,9 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
return ERR_PTR(err);
}
-static inline u32 htab_map_hash(const void *key, u32 key_len)
+static inline u32 htab_map_hash(const void *key, u32 key_len, u32 hashrnd)
{
- return jhash(key, key_len, 0);
+ return jhash(key, key_len, hashrnd);
}
static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32 hash)
@@ -470,7 +473,7 @@ static void *__htab_map_lookup_elem(struct bpf_map *map, void *key)
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
head = select_bucket(htab, hash);
@@ -597,7 +600,7 @@ static int htab_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
if (!key)
goto find_first_elem;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
head = select_bucket(htab, hash);
@@ -824,7 +827,7 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value,
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
b = __select_bucket(htab, hash);
head = &b->head;
@@ -880,7 +883,7 @@ static int htab_lru_map_update_elem(struct bpf_map *map, void *key, void *value,
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
b = __select_bucket(htab, hash);
head = &b->head;
@@ -945,7 +948,7 @@ static int __htab_percpu_map_update_elem(struct bpf_map *map, void *key,
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
b = __select_bucket(htab, hash);
head = &b->head;
@@ -998,7 +1001,7 @@ static int __htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
b = __select_bucket(htab, hash);
head = &b->head;
@@ -1071,7 +1074,7 @@ static int htab_map_delete_elem(struct bpf_map *map, void *key)
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
b = __select_bucket(htab, hash);
head = &b->head;
@@ -1103,7 +1106,7 @@ static int htab_lru_map_delete_elem(struct bpf_map *map, void *key)
key_size = map->key_size;
- hash = htab_map_hash(key, key_size);
+ hash = htab_map_hash(key, key_size, htab->hashrnd);
b = __select_bucket(htab, hash);
head = &b->head;
--
2.9.5
^ 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