* Re: [RFC v4 3/5] virtio_ring: add packed ring support
From: Jason Wang @ 2018-05-17 12:01 UTC (permalink / raw)
To: Tiwei Bie; +Cc: mst, virtualization, linux-kernel, netdev, wexu, jfreimann
In-Reply-To: <20180516143332.GA1957@debian>
On 2018年05月16日 22:33, Tiwei Bie wrote:
> On Wed, May 16, 2018 at 10:05:44PM +0800, Jason Wang wrote:
>> On 2018年05月16日 21:45, Tiwei Bie wrote:
>>> On Wed, May 16, 2018 at 08:51:43PM +0800, Jason Wang wrote:
>>>> On 2018年05月16日 20:39, Tiwei Bie wrote:
>>>>> On Wed, May 16, 2018 at 07:50:16PM +0800, Jason Wang wrote:
>>>>>> On 2018年05月16日 16:37, Tiwei Bie wrote:
> [...]
>>>>>>> +static void detach_buf_packed(struct vring_virtqueue *vq, unsigned int head,
>>>>>>> + unsigned int id, void **ctx)
>>>>>>> +{
>>>>>>> + struct vring_packed_desc *desc;
>>>>>>> + unsigned int i, j;
>>>>>>> +
>>>>>>> + /* Clear data ptr. */
>>>>>>> + vq->desc_state[id].data = NULL;
>>>>>>> +
>>>>>>> + i = head;
>>>>>>> +
>>>>>>> + for (j = 0; j < vq->desc_state[id].num; j++) {
>>>>>>> + desc = &vq->vring_packed.desc[i];
>>>>>>> + vring_unmap_one_packed(vq, desc);
>>>>>> As mentioned in previous discussion, this probably won't work for the case
>>>>>> of out of order completion since it depends on the information in the
>>>>>> descriptor ring. We probably need to extend ctx to record such information.
>>>>> Above code doesn't depend on the information in the descriptor
>>>>> ring. The vq->desc_state[] is the extended ctx.
>>>>>
>>>>> Best regards,
>>>>> Tiwei Bie
>>>> Yes, but desc is a pointer to descriptor ring I think so
>>>> vring_unmap_one_packed() still depends on the content of descriptor ring?
>>>>
>>> I got your point now. I think it makes sense to reserve
>>> the bits of the addr field. Driver shouldn't try to get
>>> addrs from the descriptors when cleanup the descriptors
>>> no matter whether we support out-of-order or not.
>> Maybe I was wrong, but I remember spec mentioned something like this.
> You're right. Spec mentioned this. I was just repeating
> the spec to emphasize that it does make sense. :)
>
>>> But combining it with the out-of-order support, it will
>>> mean that the driver still needs to maintain a desc/ctx
>>> list that is very similar to the desc ring in the split
>>> ring. I'm not quite sure whether it's something we want.
>>> If it is true, I'll do it. So do you think we also want
>>> to maintain such a desc/ctx list for packed ring?
>> To make it work for OOO backends I think we need something like this
>> (hardware NIC drivers are usually have something like this).
> Which hardware NIC drivers have this?
It's quite common I think, e.g driver track e.g dma addr and page frag
somewhere. e.g the ring->rx_info in mlx4 driver.
Thanks
>
>> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is
>> much more simpler to be started with.
> +1
>
> Best regards,
> Tiwei Bie
^ permalink raw reply
* Re: [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter
From: Eric Dumazet @ 2018-05-17 11:56 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Eric Dumazet, netdev; +Cc: cake
In-Reply-To: <87in7my196.fsf@toke.dk>
On 05/17/2018 04:23 AM, Toke Høiland-Jørgensen wrote:
>
> We don't do full parsing of SACKs, no; we were trying to keep things
> simple... We do detect the presence of SACK options, though, and the
> presence of SACK options on an ACK will make previous ACKs be considered
> redundant.
>
But they are not redundant in some cases, particularly when reorders happen in the network.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Allocate buffers from local node
From: Timur Tabi @ 2018-05-17 11:36 UTC (permalink / raw)
To: Hemanth Puranik, netdev, linux-kernel
In-Reply-To: <1526545680-21650-1-git-send-email-hpuranik@codeaurora.org>
On 5/17/18 3:28 AM, Hemanth Puranik wrote:
> Currently we use non-NUMA aware allocation for TPD and RRD buffers,
> this patch modifies to use NUMA friendly allocation.
>
> Signed-off-by: Hemanth Puranik<hpuranik@codeaurora.org>
Acked-by: Timur Tabi <timur@codeaurora.org>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] wcn36xx: Add support for Factory Test Mode (FTM)
From: Ramon Fried @ 2018-05-17 11:32 UTC (permalink / raw)
To: kvalo
Cc: linux-kernel, wcn36xx, linux-wireless, netdev, Eyal Ilsar,
Ramon Fried
From: Eyal Ilsar <eilsar@codeaurora.org>
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar <eilsar@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fried@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h | 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c | 74 +++++++++
drivers/net/wireless/ath/wcn36xx/smd.h | 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 151 ++++++++++++++++++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++++++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29 ++++
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +
9 files changed, 327 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include <linux/soc/qcom/smem_state.h>
#include <linux/soc/qcom/wcnss_ctrl.h>
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add = wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..8eaf192f8bdb 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header *hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do { \
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, &msg_body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do { \
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
{
struct wcn36xx_fw_msg_status_rsp *rsp;
@@ -741,6 +755,64 @@ int wcn36xx_smd_switch_channel(struct wcn36xx *wcn,
return ret;
}
+static int wcn36xx_smd_process_ptt_msg_rsp(void *buf, size_t len,
+ void **p_ptt_rsp_msg)
+{
+ struct wcn36xx_hal_process_ptt_msg_rsp_msg *rsp;
+ int ret = 0;
+
+ ret = wcn36xx_smd_rsp_status_check(buf, len);
+ if (ret)
+ return ret;
+
+ rsp = (struct wcn36xx_hal_process_ptt_msg_rsp_msg *)buf;
+
+ wcn36xx_dbg(WCN36XX_DBG_HAL, "process ptt msg responded with length %d\n",
+ rsp->header.len);
+ wcn36xx_dbg_dump(WCN36XX_DBG_HAL_DUMP, "HAL_PTT_MSG_RSP:", rsp->ptt_msg,
+ rsp->header.len - sizeof(rsp->ptt_msg_resp_status));
+
+ if (rsp->header.len > 0) {
+ *p_ptt_rsp_msg = kmalloc(rsp->header.len, GFP_ATOMIC);
+ memcpy(*p_ptt_rsp_msg, rsp->ptt_msg, rsp->header.len);
+ }
+ return ret;
+}
+
+int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
+ struct ieee80211_vif *vif, void *ptt_msg, size_t len,
+ void **ptt_rsp_msg)
+{
+ struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
+ int ret = 0;
+
+ mutex_lock(&wcn->hal_mutex);
+ p_msg_body = kmalloc(
+ sizeof(struct wcn36xx_hal_process_ptt_msg_req_msg) + len,
+ GFP_ATOMIC);
+ INIT_HAL_PTT_MSG(p_msg_body, len);
+
+ memcpy(&p_msg_body->ptt_msg, ptt_msg, len);
+
+ PREPARE_HAL_PTT_MSG_BUF(wcn->hal_buf, p_msg_body);
+
+ ret = wcn36xx_smd_send_and_wait(wcn, p_msg_body->header.len);
+ if (ret) {
+ wcn36xx_err("Sending hal_process_ptt_msg failed\n");
+ goto out;
+ }
+ ret = wcn36xx_smd_process_ptt_msg_rsp(wcn->hal_buf, wcn->hal_rsp_len,
+ ptt_rsp_msg);
+ if (ret) {
+ wcn36xx_err("process_ptt_msg response failed err=%d\n", ret);
+ goto out;
+ }
+out:
+ kfree(p_msg_body);
+ mutex_unlock(&wcn->hal_mutex);
+ return ret;
+}
+
static int wcn36xx_smd_update_scan_params_rsp(void *buf, size_t len)
{
struct wcn36xx_hal_update_scan_params_resp *rsp;
@@ -2367,6 +2439,7 @@ int wcn36xx_smd_rsp_process(struct rpmsg_device *rpdev,
case WCN36XX_HAL_JOIN_RSP:
case WCN36XX_HAL_UPDATE_SCAN_PARAM_RSP:
case WCN36XX_HAL_CH_SWITCH_RSP:
+ case WCN36XX_HAL_PROCESS_PTT_RSP:
case WCN36XX_HAL_FEATURE_CAPS_EXCHANGE_RSP:
case WCN36XX_HAL_8023_MULTICAST_LIST_RSP:
case WCN36XX_HAL_START_SCAN_OFFLOAD_RSP:
@@ -2407,6 +2480,7 @@ int wcn36xx_smd_rsp_process(struct rpmsg_device *rpdev,
return 0;
}
+
static void wcn36xx_ind_smd_work(struct work_struct *work)
{
struct wcn36xx *wcn =
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h b/drivers/net/wireless/ath/wcn36xx/smd.h
index 8076edf40ac8..6d83cc99dc25 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -86,6 +86,10 @@ int wcn36xx_smd_send_beacon(struct wcn36xx *wcn, struct ieee80211_vif *vif,
u16 p2p_off);
int wcn36xx_smd_switch_channel(struct wcn36xx *wcn,
struct ieee80211_vif *vif, int ch);
+int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
+ struct ieee80211_vif *vif,
+ void *ptt_msg, size_t len,
+ void **ptt_rsp_msg);
int wcn36xx_smd_update_proberesp_tmpl(struct wcn36xx *wcn,
struct ieee80211_vif *vif,
struct sk_buff *skb);
diff --git a/drivers/net/wireless/ath/wcn36xx/testmode.c b/drivers/net/wireless/ath/wcn36xx/testmode.c
new file mode 100644
index 000000000000..07d66b6bb4e8
--- /dev/null
+++ b/drivers/net/wireless/ath/wcn36xx/testmode.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <net/netlink.h>
+#include <linux/firmware.h>
+#include <net/cfg80211.h>
+#include "wcn36xx.h"
+
+#include "testmode.h"
+#include "testmode_i.h"
+#include "hal.h"
+#include "smd.h"
+
+static const struct nla_policy wcn36xx_tm_policy[WCN36XX_TM_ATTR_MAX + 1] = {
+ [WCN36XX_TM_ATTR_CMD] = { .type = NLA_U16 },
+ [WCN36XX_TM_ATTR_DATA] = { .type = NLA_BINARY,
+ .len = WCN36XX_TM_DATA_MAX_LEN },
+};
+
+struct build_release_number {
+ u16 drv_major;
+ u16 drv_minor;
+ u16 drv_patch;
+ u16 drv_build;
+ u16 ptt_max;
+ u16 ptt_min;
+ u16 fw_ver;
+} __packed;
+
+static int wcn36xx_tm_cmd_ptt(struct wcn36xx *wcn, struct ieee80211_vif *vif,
+ struct nlattr *tb[])
+{
+ int ret = 0, buf_len;
+ void *buf;
+ struct ftm_rsp_msg *msg, *rsp = NULL;
+ struct sk_buff *skb;
+
+ if (!tb[WCN36XX_TM_ATTR_DATA]) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ buf = nla_data(tb[WCN36XX_TM_ATTR_DATA]);
+ buf_len = nla_len(tb[WCN36XX_TM_ATTR_DATA]);
+ msg = (struct ftm_rsp_msg *)buf;
+
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "testmode cmd wmi msg_id 0x%04X msg_len %d buf %pK buf_len %d\n",
+ msg->msg_id, msg->msg_body_length,
+ buf, buf_len);
+
+ wcn36xx_dbg_dump(WCN36XX_DBG_TESTMODE_DUMP, "REQ ", buf, buf_len);
+
+ if (msg->msg_id == MSG_GET_BUILD_RELEASE_NUMBER) {
+ struct build_release_number *body =
+ (struct build_release_number *)
+ msg->msg_response;
+
+ body->drv_major = wcn->fw_major;
+ body->drv_minor = wcn->fw_minor;
+ body->drv_patch = wcn->fw_version;
+ body->drv_build = wcn->fw_revision;
+ body->ptt_max = 10;
+ body->ptt_min = 0;
+
+ rsp = msg;
+ rsp->resp_status = 0;
+ } else {
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "PPT Request >> HAL size %d\n",
+ msg->msg_body_length);
+
+ msg->resp_status = wcn36xx_smd_process_ptt_msg(wcn, vif, msg,
+ msg->msg_body_length, (void *)(&rsp));
+
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "Response status = %d\n",
+ msg->resp_status);
+ if (rsp)
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "PPT Response << HAL size %d\n",
+ rsp->msg_body_length);
+ }
+
+ if (!rsp) {
+ rsp = msg;
+ wcn36xx_warn("No response! Echoing request with response status %d\n",
+ rsp->resp_status);
+ }
+ wcn36xx_dbg_dump(WCN36XX_DBG_TESTMODE_DUMP, "RSP ",
+ rsp, rsp->msg_body_length);
+
+ skb = cfg80211_testmode_alloc_reply_skb(wcn->hw->wiphy,
+ nla_total_size(msg->msg_body_length));
+ if (!skb) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = nla_put(skb, WCN36XX_TM_ATTR_DATA, rsp->msg_body_length, rsp);
+ if (ret) {
+ kfree_skb(skb);
+ goto out;
+ }
+
+ ret = cfg80211_testmode_reply(skb);
+
+out:
+ if (rsp != msg)
+ kfree(rsp);
+
+ return ret;
+}
+
+int wcn36xx_tm_cmd(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ void *data, int len)
+{
+ struct wcn36xx *wcn = hw->priv;
+ struct nlattr *tb[WCN36XX_TM_ATTR_MAX + 1];
+ int ret = 0;
+ unsigned short attr;
+
+ wcn36xx_dbg_dump(WCN36XX_DBG_TESTMODE_DUMP, "Data:", data, len);
+ ret = nla_parse(tb, WCN36XX_TM_ATTR_MAX, data, len,
+ wcn36xx_tm_policy, NULL);
+ if (ret)
+ return ret;
+
+ if (!tb[WCN36XX_TM_ATTR_CMD])
+ return -EINVAL;
+
+ attr = nla_get_u16(tb[WCN36XX_TM_ATTR_CMD]);
+
+ if (attr != WCN36XX_TM_CMD_PTT)
+ return -EOPNOTSUPP;
+
+ return wcn36xx_tm_cmd_ptt(wcn, vif, tb);
+}
diff --git a/drivers/net/wireless/ath/wcn36xx/testmode.h b/drivers/net/wireless/ath/wcn36xx/testmode.h
new file mode 100644
index 000000000000..aba014896dfd
--- /dev/null
+++ b/drivers/net/wireless/ath/wcn36xx/testmode.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "wcn36xx.h"
+
+struct ftm_rsp_msg {
+ u16 msg_id;
+ u16 msg_body_length;
+ u32 resp_status;
+ u8 msg_response[0];
+} __packed;
+
+/* The request buffer of FTM which contains a byte of command and the request */
+struct ftm_payload {
+ u16 ftm_cmd_type;
+ struct ftm_rsp_msg ftm_cmd_msg;
+} __packed;
+
+#define MSG_GET_BUILD_RELEASE_NUMBER 0x32A2
+
+#ifdef CONFIG_NL80211_TESTMODE
+int wcn36xx_tm_cmd(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ void *data, int len);
+
+#else
+static inline int wcn36xx_tm_cmd(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ void *data, int len)
+{
+ return 0;
+}
+
+#endif
diff --git a/drivers/net/wireless/ath/wcn36xx/testmode_i.h b/drivers/net/wireless/ath/wcn36xx/testmode_i.h
new file mode 100644
index 000000000000..8a1477ffd5a0
--- /dev/null
+++ b/drivers/net/wireless/ath/wcn36xx/testmode_i.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#define WCN36XX_TM_DATA_MAX_LEN 5000
+
+enum wcn36xx_tm_attr {
+ __WCN36XX_TM_ATTR_INVALID = 0,
+ WCN36XX_TM_ATTR_CMD = 1,
+ WCN36XX_TM_ATTR_DATA = 2,
+
+ /* keep last */
+ __WCN36XX_TM_ATTR_AFTER_LAST,
+ WCN36XX_TM_ATTR_MAX = __WCN36XX_TM_ATTR_AFTER_LAST - 1,
+};
+
+#define WCN36XX_TM_CMD_PTT 3
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 5854adf43f3a..547e9a9eb28f 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -56,6 +56,8 @@ enum wcn36xx_debug_mask {
WCN36XX_DBG_BEACON_DUMP = 0x00001000,
WCN36XX_DBG_PMC = 0x00002000,
WCN36XX_DBG_PMC_DUMP = 0x00004000,
+ WCN36XX_DBG_TESTMODE = 0x00008000,
+ WCN36XX_DBG_TESTMODE_DUMP = 0x00010000,
WCN36XX_DBG_ANY = 0xffffffff,
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter
From: Toke Høiland-Jørgensen @ 2018-05-17 11:23 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake
In-Reply-To: <a002ff7b-2606-afcd-1769-b216f4db428c@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote:
>> The ACK filter is an optional feature of CAKE which is designed to improve
>> performance on links with very asymmetrical rate limits. On such links
>> (which are unfortunately quite prevalent, especially for DSL and cable
>> subscribers), the downstream throughput can be limited by the number of
>> ACKs capable of being transmitted in the *upstream* direction.
>>
>
> ...
>
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>> ---
>> net/sched/sch_cake.c | 260 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 258 insertions(+), 2 deletions(-)
>>
>>
>
> I have decided to implement ACK compression in TCP stack itself.
Awesome! Will look forward to seeing that!
> First step is to take care of SACK, which are the main source of the
> bloat, since we send one SACK for every incoming out-of-order packet.
>
> These SACK are not only causing pain on the network, they also cause
> the sender to send one MSS at a time (TSO auto defer is not engaged in
> this case), thus starting to fill its RTX queue with pathological skbs
> (1-MSS each), increasing processing time.
>
> I see that your ACK filter does not take care of this common case :)
We don't do full parsing of SACKs, no; we were trying to keep things
simple... We do detect the presence of SACK options, though, and the
presence of SACK options on an ACK will make previous ACKs be considered
redundant.
> Doing the filtering in TCP has the immense advantage of knowing the
> RTT and thus be able to use heuristics causing less damage.
Quite so. I'll be quite happy if the CAKE ACK filter can be delegated to
something only relevant for the poor sods stuck on proprietary operating
systems :)
Are you satisfied that the current version of the filter doesn't mangle
the skbs or crash the kernel?
-Toke
^ permalink raw reply
* Re: [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter
From: Eric Dumazet @ 2018-05-17 11:04 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, netdev; +Cc: cake
In-Reply-To: <152650254614.25701.1377066681230937234.stgit@alrua-kau>
On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote:
> The ACK filter is an optional feature of CAKE which is designed to improve
> performance on links with very asymmetrical rate limits. On such links
> (which are unfortunately quite prevalent, especially for DSL and cable
> subscribers), the downstream throughput can be limited by the number of
> ACKs capable of being transmitted in the *upstream* direction.
>
...
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
> ---
> net/sched/sch_cake.c | 260 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 258 insertions(+), 2 deletions(-)
>
>
I have decided to implement ACK compression in TCP stack itself.
First step is to take care of SACK, which are the main source of the bloat,
since we send one SACK for every incoming out-of-order packet.
These SACK are not only causing pain on the network, they also cause
the sender to send one MSS at a time (TSO auto defer is not engaged in this case),
thus starting to fill its RTX queue with pathological skbs (1-MSS each), increasing
processing time.
I see that your ACK filter does not take care of this common case :)
Doing the filtering in TCP has the immense advantage of knowing the RTT and thus be able
to use heuristics causing less damage.
^ permalink raw reply
* [PATCH net 1/1] net/smc: initialize tx_work before llc initial handshake
From: Ursula Braun @ 2018-05-17 10:54 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
From: Karsten Graul <kgraul@linux.ibm.com>
When the llc handshake fails in an early state, the general cleanup
routines may try to cancel an uninitialized worker. Avoid this by
initializing the worker before the llc initial handshake starts.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 544bab42f925..e96f324dc69f 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -494,6 +494,7 @@ static int smc_connect_rdma(struct smc_sock *smc)
rc = smc_clc_send_confirm(smc);
if (rc)
goto out_err_unlock;
+ smc_tx_init(smc);
if (local_contact == SMC_FIRST_CONTACT) {
/* QP confirmation over RoCE fabric */
@@ -505,9 +506,7 @@ static int smc_connect_rdma(struct smc_sock *smc)
if (reason_code > 0)
goto decline_rdma_unlock;
}
-
mutex_unlock(&smc_create_lgr_pending);
- smc_tx_init(smc);
out_connected:
smc_copy_sock_settings_to_clc(smc);
@@ -885,6 +884,7 @@ static void smc_listen_work(struct work_struct *work)
reason_code = SMC_CLC_DECL_INTERR;
goto decline_rdma_unlock;
}
+ smc_tx_init(new_smc);
if (local_contact == SMC_FIRST_CONTACT) {
rc = smc_ib_ready_link(link);
@@ -900,8 +900,6 @@ static void smc_listen_work(struct work_struct *work)
if (reason_code > 0)
goto decline_rdma_unlock;
}
-
- smc_tx_init(new_smc);
mutex_unlock(&smc_create_lgr_pending);
out_connected:
--
2.16.3
^ permalink raw reply related
* [PATCH net-next] net/smc: init conn.tx_work & conn.send_lock sooner
From: Eric Dumazet @ 2018-05-17 10:54 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Ursula Braun, linux-s390
syzkaller found that following program crashes the host :
{
int fd = socket(AF_SMC, SOCK_STREAM, 0);
int val = 1;
listen(fd, 0);
shutdown(fd, SHUT_RDWR);
setsockopt(fd, 6, TCP_NODELAY, &val, 4);
}
Simply initialize conn.tx_work & conn.send_lock at socket creation,
rather than deeper in the stack.
ODEBUG: assert_init not available (active state 0) object type: timer_list hint: (null)
WARNING: CPU: 1 PID: 13988 at lib/debugobjects.c:329 debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 13988 Comm: syz-executor0 Not tainted 4.17.0-rc4+ #46
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:326
RSP: 0018:ffff880197a37880 EFLAGS: 00010086
RAX: 0000000000000061 RBX: 0000000000000005 RCX: ffffc90001ed0000
RDX: 0000000000004aaf RSI: ffffffff8160f6f1 RDI: 0000000000000001
RBP: ffff880197a378c0 R08: ffff8801aa7a0080 R09: ffffed003b5e3eb2
R10: ffffed003b5e3eb2 R11: ffff8801daf1f597 R12: 0000000000000001
R13: ffffffff88d96980 R14: ffffffff87fa19a0 R15: ffffffff81666ec0
debug_object_assert_init+0x309/0x500 lib/debugobjects.c:692
debug_timer_assert_init kernel/time/timer.c:724 [inline]
debug_assert_init kernel/time/timer.c:776 [inline]
del_timer+0x74/0x140 kernel/time/timer.c:1198
try_to_grab_pending+0x439/0x9a0 kernel/workqueue.c:1223
mod_delayed_work_on+0x91/0x250 kernel/workqueue.c:1592
mod_delayed_work include/linux/workqueue.h:541 [inline]
smc_setsockopt+0x387/0x6d0 net/smc/af_smc.c:1367
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 01d2f7e2cdd3 ("net/smc: sockopts TCP_NODELAY and TCP_CORK")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ursula Braun <ubraun@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/smc/af_smc.c | 2 ++
net/smc/smc_tx.c | 4 +---
net/smc/smc_tx.h | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index d15762b057c0d8d4167feca9a4c41f0408604c37..6ad4f6c771c3fa63d3ae714dbe65879910963a21 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -193,8 +193,10 @@ static struct sock *smc_sock_alloc(struct net *net, struct socket *sock,
sk->sk_protocol = protocol;
smc = smc_sk(sk);
INIT_WORK(&smc->tcp_listen_work, smc_tcp_listen_work);
+ INIT_DELAYED_WORK(&smc->conn.tx_work, smc_tx_work);
INIT_LIST_HEAD(&smc->accept_q);
spin_lock_init(&smc->accept_q_lock);
+ spin_lock_init(&smc->conn.send_lock);
sk->sk_prot->hash(sk);
sk_refcnt_debug_inc(sk);
diff --git a/net/smc/smc_tx.c b/net/smc/smc_tx.c
index 58dfe0bd9d6075b5d3db97c659999b364b97da73..08a7de98bb031b5d2256e3238236108749e7ae39 100644
--- a/net/smc/smc_tx.c
+++ b/net/smc/smc_tx.c
@@ -450,7 +450,7 @@ int smc_tx_sndbuf_nonempty(struct smc_connection *conn)
/* Wakeup sndbuf consumers from process context
* since there is more data to transmit
*/
-static void smc_tx_work(struct work_struct *work)
+void smc_tx_work(struct work_struct *work)
{
struct smc_connection *conn = container_of(to_delayed_work(work),
struct smc_connection,
@@ -512,6 +512,4 @@ void smc_tx_consumer_update(struct smc_connection *conn)
void smc_tx_init(struct smc_sock *smc)
{
smc->sk.sk_write_space = smc_tx_write_space;
- INIT_DELAYED_WORK(&smc->conn.tx_work, smc_tx_work);
- spin_lock_init(&smc->conn.send_lock);
}
diff --git a/net/smc/smc_tx.h b/net/smc/smc_tx.h
index 78255964fa4dc1c69f96548e035e74a167999a62..8f64b12bf03c1b52c599b1239784a404efe65dae 100644
--- a/net/smc/smc_tx.h
+++ b/net/smc/smc_tx.h
@@ -27,6 +27,7 @@ static inline int smc_tx_prepared_sends(struct smc_connection *conn)
return smc_curs_diff(conn->sndbuf_size, &sent, &prep);
}
+void smc_tx_work(struct work_struct *work);
void smc_tx_init(struct smc_sock *smc);
int smc_tx_sendmsg(struct smc_sock *smc, struct msghdr *msg, size_t len);
int smc_tx_sndbuf_nonempty(struct smc_connection *conn);
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Jan Engelhardt @ 2018-05-17 10:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Eric Dumazet, Greg Hackmann, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Michal Kubecek, netfilter-devel, coreteam,
netdev
In-Reply-To: <20180517100908.GA3150@kroah.com>
On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
>> > --- a/net/netfilter/x_tables.c
>> > +++ b/net/netfilter/x_tables.c
>> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
>> > * than shoot all processes down before realizing there is nothing
>> > * more to reclaim.
>> > */
>> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
>> > + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
>> > if (!info)
>> > return NULL;
>>
>> I am curious, what particular path does not later overwrite the whole zone ?
>
>In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
>can be larger than the size of the structure itself.
>
>Then the data is copied to userspace in copy_entries_to_user() for ipv4
>and v6, and that's where the "bad data"
If the kernel incorrectly copies more bytes than it should, isn't that
a sign that may be going going past the end of the info buffer?
(And thus, zeroing won't truly fix the issue)
And if the kernel copies too few (because it just does not have more
data than userspace is requesting), what remains in the user buffer
is the garbage that originally was there.
^ permalink raw reply
* Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Greg Kroah-Hartman @ 2018-05-17 10:09 UTC (permalink / raw)
To: Eric Dumazet, Greg Hackmann
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Michal Kubecek, netfilter-devel, coreteam, netdev
In-Reply-To: <a8fadcf4-c2dd-7465-9b41-189eb97a3dd2@gmail.com>
On Thu, May 17, 2018 at 02:55:42AM -0700, Eric Dumazet wrote:
>
>
> On 05/17/2018 02:34 AM, Greg Kroah-Hartman wrote:
> > When allocating a xt_table_info structure, we should be clearing out the
> > full amount of memory that was allocated, not just the "header" of the
> > structure. Otherwise odd values could be passed to userspace, which is
> > not a good thing.
> >
> > Cc: stable <stable@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > v2: use kvzalloc instead of kvmalloc/memset pair, as suggested by Michal Kubecek
> >
> > net/netfilter/x_tables.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index cb7cb300c3bc..cd22bb9b66f3 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> > * than shoot all processes down before realizing there is nothing
> > * more to reclaim.
> > */
> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > if (!info)
> > return NULL;
> >
> > - memset(info, 0, sizeof(*info));
> > info->size = size;
> > return info;
> > }
> >
>
> I am curious, what particular path does not later overwrite the whole zone ?
The path back was long, adding Greg Hackman who helped to debug this to
the To: to confirm that I got this correct...
In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
can be larger than the size of the structure itself.
Then the data is copied to userspace in copy_entries_to_user() for ipv4
and v6, and that's where the "bad data" was noticed (a researcher was
using a kernel patch to determine what the data was)
Greg, that's the correct path here, right?
> Do not get me wrong, this is not fast path, but these blobs can be huge.
Yeah, I bet, but for "normal" cases the size should be small and all
should be fine.
thanks,
greg k-h
^ permalink raw reply
* [patch net-next] nfp: flower: fix error path during representor creation
From: Jiri Pirko @ 2018-05-17 10:06 UTC (permalink / raw)
To: netdev
Cc: davem, jakub.kicinski, simon.horman, dirk.vandermerwe,
john.hurley, pieter.jansenvanvuuren, oss-drivers
From: Jiri Pirko <jiri@mellanox.com>
Don't store repr pointer to reprs array until the representor is
successfully created. This avoids message about "representor
destruction" even when it was never created. Also it cleans-up the flow.
Also, check return value after port alloc.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/netronome/nfp/flower/main.c | 13 +++++++++++--
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 9 +++++++--
drivers/net/ethernet/netronome/nfp/nfp_net_repr.h | 1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c
index 84e3b9f5abb1..4e67c0cbf9f0 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -247,12 +247,16 @@ nfp_flower_spawn_vnic_reprs(struct nfp_app *app,
err = -ENOMEM;
goto err_reprs_clean;
}
- RCU_INIT_POINTER(reprs->reprs[i], repr);
/* For now we only support 1 PF */
WARN_ON(repr_type == NFP_REPR_TYPE_PF && i);
port = nfp_port_alloc(app, port_type, repr);
+ if (IS_ERR(port)) {
+ err = PTR_ERR(port);
+ nfp_repr_free(repr);
+ goto err_reprs_clean;
+ }
if (repr_type == NFP_REPR_TYPE_PF) {
port->pf_id = i;
port->vnic = priv->nn->dp.ctrl_bar;
@@ -271,9 +275,11 @@ nfp_flower_spawn_vnic_reprs(struct nfp_app *app,
port_id, port, priv->nn->dp.netdev);
if (err) {
nfp_port_free(port);
+ nfp_repr_free(repr);
goto err_reprs_clean;
}
+ RCU_INIT_POINTER(reprs->reprs[i], repr);
nfp_info(app->cpp, "%s%d Representor(%s) created\n",
repr_type == NFP_REPR_TYPE_PF ? "PF" : "VF", i,
repr->name);
@@ -344,16 +350,17 @@ nfp_flower_spawn_phy_reprs(struct nfp_app *app, struct nfp_flower_priv *priv)
err = -ENOMEM;
goto err_reprs_clean;
}
- RCU_INIT_POINTER(reprs->reprs[phys_port], repr);
port = nfp_port_alloc(app, NFP_PORT_PHYS_PORT, repr);
if (IS_ERR(port)) {
err = PTR_ERR(port);
+ nfp_repr_free(repr);
goto err_reprs_clean;
}
err = nfp_port_init_phy_port(app->pf, app, port, i);
if (err) {
nfp_port_free(port);
+ nfp_repr_free(repr);
goto err_reprs_clean;
}
@@ -365,6 +372,7 @@ nfp_flower_spawn_phy_reprs(struct nfp_app *app, struct nfp_flower_priv *priv)
cmsg_port_id, port, priv->nn->dp.netdev);
if (err) {
nfp_port_free(port);
+ nfp_repr_free(repr);
goto err_reprs_clean;
}
@@ -373,6 +381,7 @@ nfp_flower_spawn_phy_reprs(struct nfp_app *app, struct nfp_flower_priv *priv)
eth_tbl->ports[i].base,
phys_port);
+ RCU_INIT_POINTER(reprs->reprs[phys_port], repr);
nfp_info(app->cpp, "Phys Port %d Representor(%s) created\n",
phys_port, repr->name);
}
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
index 0cd077addb26..6e79da91e475 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
@@ -348,12 +348,17 @@ int nfp_repr_init(struct nfp_app *app, struct net_device *netdev,
return err;
}
-static void nfp_repr_free(struct nfp_repr *repr)
+static void __nfp_repr_free(struct nfp_repr *repr)
{
free_percpu(repr->stats);
free_netdev(repr->netdev);
}
+void nfp_repr_free(struct net_device *netdev)
+{
+ __nfp_repr_free(netdev_priv(netdev));
+}
+
struct net_device *nfp_repr_alloc(struct nfp_app *app)
{
struct net_device *netdev;
@@ -385,7 +390,7 @@ static void nfp_repr_clean_and_free(struct nfp_repr *repr)
nfp_info(repr->app->cpp, "Destroying Representor(%s)\n",
repr->netdev->name);
nfp_repr_clean(repr);
- nfp_repr_free(repr);
+ __nfp_repr_free(repr);
}
void nfp_reprs_clean_and_free(struct nfp_app *app, struct nfp_reprs *reprs)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.h b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.h
index a621e8ff528e..cd756a15445f 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.h
@@ -123,6 +123,7 @@ void nfp_repr_inc_rx_stats(struct net_device *netdev, unsigned int len);
int nfp_repr_init(struct nfp_app *app, struct net_device *netdev,
u32 cmsg_port_id, struct nfp_port *port,
struct net_device *pf_netdev);
+void nfp_repr_free(struct net_device *netdev);
struct net_device *nfp_repr_alloc(struct nfp_app *app);
void nfp_reprs_clean_and_free(struct nfp_app *app, struct nfp_reprs *reprs);
void nfp_reprs_clean_and_free_by_type(struct nfp_app *app,
--
2.14.3
^ permalink raw reply related
* [patch net-next] nfp: flower: set sysfs link to device for representors
From: Jiri Pirko @ 2018-05-17 10:05 UTC (permalink / raw)
To: netdev
Cc: davem, jakub.kicinski, simon.horman, dirk.vandermerwe,
john.hurley, pieter.jansenvanvuuren, oss-drivers
From: Jiri Pirko <jiri@mellanox.com>
Do this so the sysfs has "device" link correctly set.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/netronome/nfp/flower/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c
index 4e67c0cbf9f0..976ed112387d 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -267,6 +267,7 @@ nfp_flower_spawn_vnic_reprs(struct nfp_app *app,
app->pf->vf_cfg_mem + i * NFP_NET_CFG_BAR_SZ;
}
+ SET_NETDEV_DEV(repr, &priv->nn->pdev->dev);
eth_hw_addr_random(repr);
port_id = nfp_flower_cmsg_pcie_port(nfp_pcie, vnic_type,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next] net: stmmac: Populate missing callbacks in HWIF initialization
From: Jose Abreu @ 2018-05-17 9:57 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Corentin Labbe, David S. Miller, Joao Pinto,
Giuseppe Cavallaro, Alexandre Torgue
Some HW specific setusp, like sun8i, do not populate all the necessary
callbacks, which is what HWIF helpers were expecting.
Fix this by always trying to get the generic helpers and populate them
if they were not previously populated by HW specific setup.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Fixes: 5f0456b43140 ("net: stmmac: Implement logic to automatically
select HW Interface")
Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
Hi Corentin,
Please check if this patch makes sun8i work again.
Thanks and Best Regards,
Jose Miguel Abreu
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 38 ++++++++++++++++-----------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 9acc8d2..bf87571 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -163,13 +163,16 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
bool needs_gmac = priv->plat->has_gmac;
const struct stmmac_hwif_entry *entry;
struct mac_device_info *mac;
+ bool needs_setup = true;
int i, ret;
u32 id;
if (needs_gmac) {
id = stmmac_get_id(priv, GMAC_VERSION);
- } else {
+ } else if (needs_gmac4) {
id = stmmac_get_id(priv, GMAC4_VERSION);
+ } else {
+ id = 0;
}
/* Save ID for later use */
@@ -177,13 +180,12 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
/* Check for HW specific setup first */
if (priv->plat->setup) {
- priv->hw = priv->plat->setup(priv);
- if (!priv->hw)
- return -ENOMEM;
- return 0;
+ mac = priv->plat->setup(priv);
+ needs_setup = false;
+ } else {
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
}
- mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
if (!mac)
return -ENOMEM;
@@ -195,22 +197,26 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
continue;
if (needs_gmac4 ^ entry->gmac4)
continue;
- if (id < entry->min_id)
+ /* Use synopsys_id var because some setups can override this */
+ if (priv->synopsys_id < entry->min_id)
continue;
- mac->desc = entry->desc;
- mac->dma = entry->dma;
- mac->mac = entry->mac;
- mac->ptp = entry->hwtimestamp;
- mac->mode = entry->mode;
- mac->tc = entry->tc;
+ /* Only use generic HW helpers if needed */
+ mac->desc = mac->desc ? : entry->desc;
+ mac->dma = mac->dma ? : entry->dma;
+ mac->mac = mac->mac ? : entry->mac;
+ mac->ptp = mac->ptp ? : entry->hwtimestamp;
+ mac->mode = mac->mode ? : entry->mode;
+ mac->tc = mac->tc ? : entry->tc;
priv->hw = mac;
/* Entry found */
- ret = entry->setup(priv);
- if (ret)
- return ret;
+ if (needs_setup) {
+ ret = entry->setup(priv);
+ if (ret)
+ return ret;
+ }
/* Run quirks, if needed */
if (entry->quirks) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Eric Dumazet @ 2018-05-17 9:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal
Cc: Michal Kubecek, netfilter-devel, coreteam, netdev
In-Reply-To: <20180517093410.GB17597@kroah.com>
On 05/17/2018 02:34 AM, Greg Kroah-Hartman wrote:
> When allocating a xt_table_info structure, we should be clearing out the
> full amount of memory that was allocated, not just the "header" of the
> structure. Otherwise odd values could be passed to userspace, which is
> not a good thing.
>
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> v2: use kvzalloc instead of kvmalloc/memset pair, as suggested by Michal Kubecek
>
> net/netfilter/x_tables.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index cb7cb300c3bc..cd22bb9b66f3 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> * than shoot all processes down before realizing there is nothing
> * more to reclaim.
> */
> - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> if (!info)
> return NULL;
>
> - memset(info, 0, sizeof(*info));
> info->size = size;
> return info;
> }
>
I am curious, what particular path does not later overwrite the whole zone ?
Do not get me wrong, this is not fast path, but these blobs can be huge.
^ permalink raw reply
* [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Greg Kroah-Hartman @ 2018-05-17 9:34 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: Michal Kubecek, netfilter-devel, coreteam, netdev
In-Reply-To: <20180517085951.2wxvcg5herkjaxda@unicorn.suse.cz>
When allocating a xt_table_info structure, we should be clearing out the
full amount of memory that was allocated, not just the "header" of the
structure. Otherwise odd values could be passed to userspace, which is
not a good thing.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2: use kvzalloc instead of kvmalloc/memset pair, as suggested by Michal Kubecek
net/netfilter/x_tables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index cb7cb300c3bc..cd22bb9b66f3 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
* than shoot all processes down before realizing there is nothing
* more to reclaim.
*/
- info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
+ info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
if (!info)
return NULL;
- memset(info, 0, sizeof(*info));
info->size = size;
return info;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] netfilter: properly initialize xt_table_info structure
From: Greg Kroah-Hartman @ 2018-05-17 9:29 UTC (permalink / raw)
To: Michal Kubecek
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
netfilter-devel, coreteam, netdev
In-Reply-To: <20180517085951.2wxvcg5herkjaxda@unicorn.suse.cz>
On Thu, May 17, 2018 at 10:59:51AM +0200, Michal Kubecek wrote:
> On Thu, May 17, 2018 at 10:44:42AM +0200, Greg Kroah-Hartman wrote:
> > When allocating a xt_table_info structure, we should be clearing out the
> > full amount of memory that was allocated, not just the "header" of the
> > structure. Otherwise odd values could be passed to userspace, which is
> > not a good thing.
> >
> > Cc: stable <stable@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > net/netfilter/x_tables.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index cb7cb300c3bc..a300e8252bb6 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -1187,7 +1187,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> > if (!info)
> > return NULL;
> >
> > - memset(info, 0, sizeof(*info));
> > + memset(info, 0, sz);
> > info->size = size;
> > return info;
> > }
> > --
> > 2.17.0
> >
>
> Or we can replace kvmalloc() by kvzalloc() and remove the memset().
That works for me too, either is sufficient to solve the problem.
Let me go respin this, less lines of code is always better :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v3 00/10] net: mvpp2: phylink conversion
From: Antoine Tenart @ 2018-05-17 9:26 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: andrew, mw, ymarkman, jason, Antoine Tenart, netdev,
gregory.clement, linux-kernel, kishon, nadavh, thomas.petazzoni,
miquel.raynal, stefanc, maxime.chevallier, davem,
linux-arm-kernel, sebastian.hesselbarth
In-Reply-To: <20180517091856.GA17671@n2100.armlinux.org.uk>
Hi Russell,
On Thu, May 17, 2018 at 10:18:56AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 17, 2018 at 10:29:29AM +0200, Antoine Tenart wrote:
> > Since v2:
> > - Removed the SFP description from the DB boards, as their SFP cages
> > are wired properly. We now use fixed-link.
>
> I think you mean "improperly" here.
Right :)
Thanks,
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: xdp and fragments with virtio
From: Jason Wang @ 2018-05-17 9:24 UTC (permalink / raw)
To: David Ahern, netdev@vger.kernel.org
In-Reply-To: <ff050e6b-cd64-d2cc-e8fa-03a07b7cf247@gmail.com>
On 2018年05月17日 10:55, David Ahern wrote:
> On 5/16/18 1:24 AM, Jason Wang wrote:
>>
>> On 2018年05月16日 11:51, David Ahern wrote:
>>> Hi Jason:
>>>
>>> I am trying to test MTU changes to the BPF fib_lookup helper and seeing
>>> something odd. Hoping you can help.
>>>
>>> I have a VM with multiple virtio based NICs and tap backends. I install
>>> the xdp program on eth1 and eth2 to do forwarding. In the host I send a
>>> large packet to eth1:
>>>
>>> $ ping -s 1500 9.9.9.9
>>>
>>>
>>> The tap device in the host sees 2 packets:
>>>
>>> $ sudo tcpdump -nv -i vm02-eth1
>>> 20:44:33.943160 IP (tos 0x0, ttl 64, id 58746, offset 0, flags [+],
>>> proto ICMP (1), length 1500)
>>> 10.100.1.254 > 9.9.9.9: ICMP echo request, id 17917, seq 1,
>>> length 1480
>>> 20:44:33.943172 IP (tos 0x0, ttl 64, id 58746, offset 1480, flags
>>> [none], proto ICMP (1), length 48)
>>> 10.100.1.254 > 9.9.9.9: ip-proto-1
>>>
>>>
>>> In the VM, the XDP program only sees the first packet, not the fragment.
>>> I added a printk to the program (see diff below):
>>>
>>> $ cat trace_pipe
>>> <idle>-0 [003] ..s2 254.436467: 0: packet length 1514
>>>
>>>
>>> Anything come to mind in the virtio xdp implementation that affects
>>> fragment packets? I see this with both IPv4 and v6.
>> Not yet. But we do turn of tap gso when virtio has XDP set, but it
>> shouldn't matter this case.
>>
>> Will try to see what's wrong.
>>
> I added this to the command line for the NICs and it works:
>
> "mrg_rxbuf=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off"
>
> XDP program sees the full size packet and the fragment.
>
> Fun fact: only adding mrg_rxbuf=off so that mergeable_rx_bufs is false
> but big_packets is true generates a panic when it receives large packets.
It looks like we wrongly drop packets after linearizing the packets
during XDP_REDIRECT.
Please try the patch (but I do spot some other issues, will post a series):
Thanks
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f34794a..59702f9 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -800,7 +800,7 @@ static struct sk_buff *receive_mergeable(struct
net_device *dev,
}
*xdp_xmit = true;
if (unlikely(xdp_page != page))
- goto err_xdp;
+ put_page(page);
rcu_read_unlock();
goto xdp_xmit;
default:
^ permalink raw reply related
* Re: [PATCH net-next v3 00/10] net: mvpp2: phylink conversion
From: Russell King - ARM Linux @ 2018-05-17 9:18 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180517082939.14598-1-antoine.tenart@bootlin.com>
On Thu, May 17, 2018 at 10:29:29AM +0200, Antoine Tenart wrote:
> Since v2:
> - Removed the SFP description from the DB boards, as their SFP cages
> are wired properly. We now use fixed-link.
I think you mean "improperly" here.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 3/3] sh_eth: add R8A77980 support
From: Simon Horman @ 2018-05-17 8:56 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, devicetree, David S. Miller, Rob Herring, Mark Rutland,
linux-renesas-soc
In-Reply-To: <d3fe7c8e-3356-4f3a-d550-bc813f3f72cd@cogentembedded.com>
On Wed, May 16, 2018 at 11:00:29PM +0300, Sergei Shtylyov wrote:
> Finally, add support for the DT probing of the R-Car V3H (AKA R8A77980) --
> it's the only R-Car gen3 SoC having the GEther controller -- others have
> only EtherAVB...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH] netfilter: properly initialize xt_table_info structure
From: Michal Kubecek @ 2018-05-17 8:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
netfilter-devel, coreteam, netdev
In-Reply-To: <20180517084442.GA23981@kroah.com>
On Thu, May 17, 2018 at 10:44:42AM +0200, Greg Kroah-Hartman wrote:
> When allocating a xt_table_info structure, we should be clearing out the
> full amount of memory that was allocated, not just the "header" of the
> structure. Otherwise odd values could be passed to userspace, which is
> not a good thing.
>
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> net/netfilter/x_tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index cb7cb300c3bc..a300e8252bb6 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -1187,7 +1187,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> if (!info)
> return NULL;
>
> - memset(info, 0, sizeof(*info));
> + memset(info, 0, sz);
> info->size = size;
> return info;
> }
> --
> 2.17.0
>
Or we can replace kvmalloc() by kvzalloc() and remove the memset().
Michal Kubecek
^ permalink raw reply
* Re: net: ieee802154: 6lowpan: fix frag reassembly
From: Greg KH @ 2018-05-17 8:59 UTC (permalink / raw)
To: Stefan Schmidt
Cc: stable, Alexander Aring, David S. Miller,
linux-wpan@vger.kernel.org, Network Development
In-Reply-To: <142208d4-6ca6-5923-327c-8d1cb069ceb8@osg.samsung.com>
On Mon, May 14, 2018 at 05:22:18PM +0200, Stefan Schmidt wrote:
> Hello.
>
>
> Please apply f18fa5de5ba7f1d6650951502bb96a6e4715a948
>
> (net: ieee802154: 6lowpan: fix frag reassembly) to the 4.16.x stable tree.
>
>
> Earlier trees are not needed as the problem was introduced in 4.16.
Really? Commit f18fa5de5ba7 ("net: ieee802154: 6lowpan: fix frag
reassembly") says it fixes commit 648700f76b03 ("inet: frags: use
rhashtables for reassembly units") which did not show up until 4.17-rc1:
$ git describe --contains 648700f76b03
v4.17-rc1~148^2~20^2~11
Also, it did not get backported to 4.16.y, so I don't see how it is
needed in 4.16-stable.
To verify this, I tried applying the patch, and it totally fails to
apply to the 4.16.y tree.
So are you _sure_ you want/need this in 4.16? If so, can you provide a
working backport that you have verified works?
thanks,
greg k-h
^ permalink raw reply
* Re: [BUG] net: stmmac: dwmac-sun8i broken in linux-next
From: Jose Abreu @ 2018-05-17 8:56 UTC (permalink / raw)
To: Corentin Labbe, Jose.Abreu, davem, alexandre.torgue,
peppe.cavallaro
Cc: netdev, linux-kernel, linux-sunxi
In-Reply-To: <20180516183208.GA17778@Red>
Hi Corentin,
On 16-05-2018 19:32, Corentin Labbe wrote:
> Hello
>
> The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX errors as shown by ifconfig:
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.1.204 netmask 255.255.255.0 broadcast 192.168.1.255
> ether 96:75:ff:0d:f6:d8 txqueuelen 1000 (Ethernet)
> RX packets 0 bytes 0 (0.0 B)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 0 bytes 4956 (4.8 KiB)
> TX errors 118 dropped 0 overruns 0 carrier 0 collisions 0
>
> Reverting the following commit made the driver working:
> 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser")
> 5f0456b43140af9413397cc11d03d18b9f2fc2fc ("net: stmmac: Implement logic to automatically select HW Interface")
>
> Note that reverting only 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f lead to crash:
> [ 31.385110] Backtrace:
> [ 31.387576] [<c0510cd4>] (stmmac_open) from [<c062cf48>] (__dev_open+0xe4/0x180)
> [ 31.394972] r10:ed447d04 r9:edc5d010 r8:ef02002c r7:c08670a4 r6:00000000 r5:c0c08488
> [ 31.402793] r4:ef020000
> [ 31.405335] [<c062ce64>] (__dev_open) from [<c062d374>] (__dev_change_flags+0x190/0x1e8)
> [ 31.413421] r8:00001002 r7:c0c08488 r6:00001003 r5:00000001 r4:ef020000
> [ 31.420122] [<c062d1e4>] (__dev_change_flags) from [<c062d3ec>] (dev_change_flags+0x20/0x50)
> [ 31.428555] r9:edc5d010 r8:ed447c18 r7:ef020134 r6:00000000 r5:00001002 r4:ef020000
> [ 31.436300] [<c062d3cc>] (dev_change_flags) from [<c0646ef0>] (do_setlink+0x28c/0xbdc)
> [ 31.444213] r9:edc5d010 r8:ed447c18 r7:00000000 r6:c0c08488 r5:ed447b50 r4:ef020000
> [ 31.451955] [<c0646c64>] (do_setlink) from [<c0648064>] (rtnl_newlink+0x54c/0x7a8)
> [ 31.459522] r10:ed447d04 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:00000000
> [ 31.467343] r4:ef020000
> [ 31.469885] [<c0647b18>] (rtnl_newlink) from [<c06449f8>] (rtnetlink_rcv_msg+0x38c/0x544)
> [ 31.478058] r10:ed447d04 r9:00000000 r8:ee242840 r7:00000000 r6:edc5d000 r5:c0c08488
> [ 31.485879] r4:00000000
> [ 31.488422] [<c064466c>] (rtnetlink_rcv_msg) from [<c066e458>] (netlink_rcv_skb+0xc0/0x118)
> [ 31.496768] r10:c0c08488 r9:00000000 r8:00000020 r7:edc5d000 r6:c064466c r5:c0c08488
> [ 31.504589] r4:ee242840
> [ 31.507129] [<c066e398>] (netlink_rcv_skb) from [<c0644668>] (rtnetlink_rcv+0x18/0x1c)
> [ 31.515042] r8:ed447d60 r7:ee242840 r6:00000020 r5:ee37d800 r4:ee5fac00
> [ 31.521742] [<c0644650>] (rtnetlink_rcv) from [<c066db98>] (netlink_unicast+0x190/0x1fc)
> [ 31.529829] [<c066da08>] (netlink_unicast) from [<c066e098>] (netlink_sendmsg+0x3cc/0x410)
> [ 31.538089] r10:00000000 r9:00000020 r8:014000c0 r7:ee242840 r6:ee37d800 r5:c0c08488
> [ 31.545910] r4:ed447f44
> [ 31.548452] [<c066dccc>] (netlink_sendmsg) from [<c0604460>] (sock_sendmsg+0x1c/0x2c)
> [ 31.556279] r10:00000000 r9:ed447edc r8:00000000 r7:eefce640 r6:00000000 r5:c0c08488
> [ 31.564100] r4:ed447f44
> [ 31.566640] [<c0604444>] (sock_sendmsg) from [<c0604d9c>] (___sys_sendmsg+0x250/0x264)
> [ 31.574555] [<c0604b4c>] (___sys_sendmsg) from [<c0605e98>] (__sys_sendmsg+0x58/0x94)
> [ 31.582382] r10:00000000 r9:ed446000 r8:c01011c4 r7:eefce640 r6:00000000 r5:bec25150
> [ 31.590203] r4:c0c08488
> [ 31.592743] [<c0605e40>] (__sys_sendmsg) from [<c0605ee8>] (sys_sendmsg+0x14/0x18)
> [ 31.600307] r7:00000128 r6:bec2d17c r5:bec25144 r4:00093ee0
> [ 31.605969] [<c0605ed4>] (sys_sendmsg) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
> [ 31.613704] Exception stack(0xed447fa8 to 0xed447ff0)
> [ 31.618756] 7fa0: 00093ee0 bec25144 00000003 bec25150 00000000 85ce0000
> [ 31.626929] 7fc0: 00093ee0 bec25144 bec2d17c 00000128 000942a8 5afc783a 00094000 bec25150
> [ 31.635099] 7fe0: 00000000 bec250f0 0000012c b6e10b5c
> [ 31.640152] Code: e59a261c e59a013c e50b306c e592300c (e593300c)
> [ 31.646632] ---[ end trace 407964b7deb937bf ]---
>
> For the moment, I stil didnt find the issue.
> What to we do now ? do you want that I send revert patchs ?
No need for revert. I checked the patch and dwmac-sun8i
implementation and I think I found the problem. I will send you a
patch to test.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Regards
^ permalink raw reply
* Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation
From: Jiri Pirko @ 2018-05-17 8:47 UTC (permalink / raw)
To: Andy Gospodarek
Cc: David Ahern, netdev, davem, idosch, jakub.kicinski, mlxsw, andrew,
vivien.didelot, f.fainelli, michael.chan, ganeshgr, saeedm,
simon.horman, pieter.jansenvanvuuren, john.hurley,
dirk.vandermerwe, alexander.h.duyck, ogerlitz, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, sathya.perla,
vasundhara-v.volam, tariqt, eranbe, jeffrey.t.kirsher
In-Reply-To: <20180322192546.GA55631@C02RW35GFVH8.dhcp.broadcom.net>
Thu, Mar 22, 2018 at 08:25:46PM CET, andrew.gospodarek@broadcom.com wrote:
>On Thu, Mar 22, 2018 at 01:10:38PM -0600, David Ahern wrote:
>> On 3/22/18 11:49 AM, Jiri Pirko wrote:
>> > Thu, Mar 22, 2018 at 04:34:07PM CET, dsahern@gmail.com wrote:
>> >> On 3/22/18 4:55 AM, Jiri Pirko wrote:
>> >>> From: Jiri Pirko <jiri@mellanox.com>
>> >>>
>> >>> This patchset resolves 2 issues we have right now:
>> >>> 1) There are many netdevices / ports in the system, for port, pf, vf
>> >>> represenatation but the user has no way to see which is which
>> >>> 2) The ndo_get_phys_port_name is implemented in each driver separatelly,
>> >>> which may lead to inconsistent names between drivers.
>> >>
>> >> Similar to ndo_get_phys_port_{name,id}, devlink requires drivers to opt
>> >> in with an implementation right, so you can't really force a solution to
>> >> the consistent naming.
>> >
>> > Yeah, drivers would still have free choice to implemen the ndo
>> > themselves. But most of them, like all sriov switch drivers should use
>> > the devlink helper to have consistent naming. In other words, devlink
>> > helper should be the standard way, in weird cases (like rocker), driver
>> > implements it himself.
>>
>> That's an assumption that somehow the devlink API will be better
>> supported than ndo_get_phys_port_{name,id}. Don't get me wrong -- an API
>> to show the kind of device is needed, but I do not think this enforces
>> any kind of consistency in naming.
>>
>> >
>> >
>> >>
>> >>>
>> >>> This patchset introduces port flavours which should address the first
>> >>> problem. I'm testing this with Netronome nfp hardware. When the user
>> >>> has 2 physical ports, 1 pf, and 4 vfs, he should see something like this:
>> >>> # devlink port
>> >>> pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical number 0
>> >>> pci/0000:05:00.0/268435456: type eth netdev eth0 flavour physical number 0
>> >>> pci/0000:05:00.0/268435460: type eth netdev enp5s0np1 flavour physical number 1
>> >>> pci/0000:05:00.0/536875008: type eth netdev eth2 flavour pf_rep number 536875008
>> >>> pci/0000:05:00.0/536870912: type eth netdev eth1 flavour vf_rep number 0
>> >>> pci/0000:05:00.0/536870976: type eth netdev eth3 flavour vf_rep number 1
>> >>> pci/0000:05:00.0/536871040: type eth netdev eth4 flavour vf_rep number 2
>> >>> pci/0000:05:00.0/536871104: type eth netdev eth5 flavour vf_rep number 3
>> >>
>> >> How about 'kind' instead of flavo{u}r?
>> >
>> > Yeah, kind is often used in kernel already with different meaning
>> > git grep kind net/core
>> > I wanted to avoid confusions
>>
>> Roopa's amendment works as well; I just think flavor / flavour is the
>> wrong word. Make me thinks of food ... ice cream vs netdevices.
>
>Naming it a 'subtype' could also work. It's a bit longer than 'kind'
>(no longer than 'flavour') and accurately describes the characteristic
>of this port. It also avoids the namespace collision of 'kind' that
>Jiri points out.
>
>It also fits with the names used in the PCI world with vendor:device and
>subsystem vendor:subsystem device naming used there for further
>granularity.
Problem with "subtype" is that it indicates some relation with type.
We have type:
enum devlink_port_type {
DEVLINK_PORT_TYPE_NOTSET,
DEVLINK_PORT_TYPE_AUTO,
DEVLINK_PORT_TYPE_ETH,
DEVLINK_PORT_TYPE_IB,
};
Does not feel correct to have subtypes VF/PF/VFREP/etc, which really has
no relation to ETH/IB
What about "role"? Also does not sound good to me, as the "role"
indicates that the port can "act" like something.
For me the "flavour/flavor" is still a favourite. Tells how the port tastes
like, in a semi-fun way :)
Also, there is a precedence to this in particle physics:
https://en.wikipedia.org/wiki/Color%E2%80%93flavor_locking
I guess they also had troubles to find the right name :)
>
^ permalink raw reply
* [PATCH] netfilter: properly initialize xt_table_info structure
From: Greg Kroah-Hartman @ 2018-05-17 8:44 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: netfilter-devel, coreteam, netdev
When allocating a xt_table_info structure, we should be clearing out the
full amount of memory that was allocated, not just the "header" of the
structure. Otherwise odd values could be passed to userspace, which is
not a good thing.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/x_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index cb7cb300c3bc..a300e8252bb6 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1187,7 +1187,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
if (!info)
return NULL;
- memset(info, 0, sizeof(*info));
+ memset(info, 0, sz);
info->size = size;
return info;
}
--
2.17.0
^ 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