* [PATCH bpf-next v5 4/6] tools/include/uapi: Add devmap_hash BPF map type
From: Toke Høiland-Jørgensen @ 2019-07-26 16:06 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156415721066.13581.737309854787645225.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
This adds the devmap_hash BPF map type to the uapi headers in tools/.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
tools/include/uapi/linux/bpf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 4e455018da65..ee35cdbcc003 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -134,6 +134,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_QUEUE,
BPF_MAP_TYPE_STACK,
BPF_MAP_TYPE_SK_STORAGE,
+ BPF_MAP_TYPE_DEVMAP_HASH,
};
/* Note that tracing related programs such as
^ permalink raw reply related
* [PATCH bpf-next v5 1/6] include/bpf.h: Remove map_insert_ctx() stubs
From: Toke Høiland-Jørgensen @ 2019-07-26 16:06 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
In-Reply-To: <156415721066.13581.737309854787645225.stgit@alrua-x1>
From: Toke Høiland-Jørgensen <toke@redhat.com>
When we changed the device and CPU maps to use linked lists instead of
bitmaps, we also removed the need for the map_insert_ctx() helpers to keep
track of the bitmaps inside each map. However, it seems I forgot to remove
the function definitions stubs, so remove those here.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
include/linux/bpf.h | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 18f4cc2c6acd..bfdb54dd2ad1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -713,7 +713,6 @@ struct xdp_buff;
struct sk_buff;
struct bpf_dtab_netdev *__dev_map_lookup_elem(struct bpf_map *map, u32 key);
-void __dev_map_insert_ctx(struct bpf_map *map, u32 index);
void __dev_map_flush(struct bpf_map *map);
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
struct net_device *dev_rx);
@@ -721,7 +720,6 @@ int dev_map_generic_redirect(struct bpf_dtab_netdev *dst, struct sk_buff *skb,
struct bpf_prog *xdp_prog);
struct bpf_cpu_map_entry *__cpu_map_lookup_elem(struct bpf_map *map, u32 key);
-void __cpu_map_insert_ctx(struct bpf_map *map, u32 index);
void __cpu_map_flush(struct bpf_map *map);
int cpu_map_enqueue(struct bpf_cpu_map_entry *rcpu, struct xdp_buff *xdp,
struct net_device *dev_rx);
@@ -801,10 +799,6 @@ static inline struct net_device *__dev_map_lookup_elem(struct bpf_map *map,
return NULL;
}
-static inline void __dev_map_insert_ctx(struct bpf_map *map, u32 index)
-{
-}
-
static inline void __dev_map_flush(struct bpf_map *map)
{
}
@@ -834,10 +828,6 @@ struct bpf_cpu_map_entry *__cpu_map_lookup_elem(struct bpf_map *map, u32 key)
return NULL;
}
-static inline void __cpu_map_insert_ctx(struct bpf_map *map, u32 index)
-{
-}
-
static inline void __cpu_map_flush(struct bpf_map *map)
{
}
^ permalink raw reply related
* [PATCH bpf-next v5 0/6] xdp: Add devmap_hash map type
From: Toke Høiland-Jørgensen @ 2019-07-26 16:06 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, netdev, David Miller, Jesper Dangaard Brouer,
Jakub Kicinski, Björn Töpel, Yonghong Song
This series adds a new map type, devmap_hash, that works like the existing
devmap type, but using a hash-based indexing scheme. This is useful for the use
case where a devmap is indexed by ifindex (for instance for use with the routing
table lookup helper). For this use case, the regular devmap needs to be sized
after the maximum ifindex number, not the number of devices in it. A hash-based
indexing scheme makes it possible to size the map after the number of devices it
should contain instead.
This was previously part of my patch series that also turned the regular
bpf_redirect() helper into a map-based one; for this series I just pulled out
the patches that introduced the new map type.
Changelog:
v5:
- Dynamically set the number of hash buckets by rounding up max_entries to the
nearest power of two (mirroring the regular hashmap), as suggested by Jesper.
v4:
- Remove check_memlock parameter that was left over from an earlier patch
series.
- Reorder struct members to avoid holes.
v3:
- Rework the split into different patches
- Use spin_lock_irqsave()
- Also add documentation and bash completion definitions for bpftool
v2:
- Split commit adding the new map type so uapi and tools changes are separate.
Changes to these patches since the previous series:
- Rebase on top of the other devmap changes (makes this one simpler!)
- Don't enforce key==val, but allow arbitrary indexes.
- Rename the type to devmap_hash to reflect the fact that it's just a hashmap now.
---
Toke Høiland-Jørgensen (6):
include/bpf.h: Remove map_insert_ctx() stubs
xdp: Refactor devmap allocation code for reuse
xdp: Add devmap_hash map type for looking up devices by hashed index
tools/include/uapi: Add devmap_hash BPF map type
tools/libbpf_probes: Add new devmap_hash type
tools: Add definitions for devmap_hash map type
include/linux/bpf.h | 11 -
include/linux/bpf_types.h | 1
include/trace/events/xdp.h | 3
include/uapi/linux/bpf.h | 1
kernel/bpf/devmap.c | 332 +++++++++++++++++++----
kernel/bpf/verifier.c | 2
net/core/filter.c | 9 -
tools/bpf/bpftool/Documentation/bpftool-map.rst | 2
tools/bpf/bpftool/bash-completion/bpftool | 4
tools/bpf/bpftool/map.c | 3
tools/include/uapi/linux/bpf.h | 1
tools/lib/bpf/libbpf_probes.c | 1
tools/testing/selftests/bpf/test_maps.c | 16 +
13 files changed, 321 insertions(+), 65 deletions(-)
^ permalink raw reply
* [HOWTO?] packet: tx-only socket / binding to "nothing"?
From: David Lamparter @ 2019-07-26 15:45 UTC (permalink / raw)
To: netdev
Hi netdev,
quick question: is there a recommended setup to get a send-only packet
socket? I've been reading net/packet/af_packet.c up and down and don't
see an explicit way, so I ended up binding to ("lo", ETH_P_LOOP)
instead. (Nothing special about ETH_P_LOOP, I just grabbed a random
value that looked like it might never happen.)
Cheers,
-David
^ permalink raw reply
* [PATCH net-next v2 2/2] qed: Add driver API for flashing the config attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-26 15:52 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190726155215.25151-1-skalluru@marvell.com>
The patch adds driver interface for reading the NVM config request and
update the attributes on nvm config flash partition.
This API can be used by ethtool flash update command (i.e., ethtool -f) to
update config attributes in the NVM flash parition.
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 65 ++++++++++++++++++++++++++++++
include/linux/qed/qed_if.h | 1 +
2 files changed, 66 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..54f00d2 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -67,6 +67,8 @@
#define QED_ROCE_QPS (8192)
#define QED_ROCE_DPIS (8)
#define QED_RDMA_SRQS QED_ROCE_QPS
+#define QED_NVM_CFG_SET_FLAGS 0xE
+#define QED_NVM_CFG_SET_PF_FLAGS 0x1E
static char version[] =
"QLogic FastLinQ 4xxxx Core Module qed " DRV_MODULE_VERSION "\n";
@@ -2227,6 +2229,66 @@ static int qed_nvm_flash_image_validate(struct qed_dev *cdev,
return 0;
}
+/* Binary file format -
+ * /----------------------------------------------------------------------\
+ * 0B | 0x5 [command index] |
+ * 4B | Entity ID | Reserved | Number of config attributes |
+ * 8B | Config ID | Length | Value |
+ * | |
+ * \----------------------------------------------------------------------/
+ * There can be several Cfg_id-Length-Value sets as specified by 'Number of...'.
+ * Entity ID - A non zero entity value for which the config need to be updated.
+ */
+static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
+{
+ struct qed_hwfn *hwfn = QED_LEADING_HWFN(cdev);
+ u8 entity_id, len, buf[32];
+ struct qed_ptt *ptt;
+ u16 cfg_id, count;
+ int rc = 0, i;
+ u32 flags;
+
+ ptt = qed_ptt_acquire(hwfn);
+ if (!ptt)
+ return -EAGAIN;
+
+ /* NVM CFG ID attribute header */
+ *data += 4;
+ entity_id = **data;
+ *data += 2;
+ count = *((u16 *)*data);
+ *data += 2;
+
+ DP_VERBOSE(cdev, NETIF_MSG_DRV,
+ "Read config ids: entity id %02x num _attrs = %0d\n",
+ entity_id, count);
+ /* NVM CFG ID attributes */
+ for (i = 0; i < count; i++) {
+ cfg_id = *((u16 *)*data);
+ *data += 2;
+ len = **data;
+ (*data)++;
+ memcpy(buf, *data, len);
+ *data += len;
+
+ flags = entity_id ? QED_NVM_CFG_SET_PF_FLAGS :
+ QED_NVM_CFG_SET_FLAGS;
+
+ DP_VERBOSE(cdev, NETIF_MSG_DRV,
+ "cfg_id = %d len = %d\n", cfg_id, len);
+ rc = qed_mcp_nvm_set_cfg(hwfn, ptt, cfg_id, entity_id, flags,
+ buf, len);
+ if (rc) {
+ DP_ERR(cdev, "Error %d configuring %d\n", rc, cfg_id);
+ break;
+ }
+ }
+
+ qed_ptt_release(hwfn, ptt);
+
+ return rc;
+}
+
static int qed_nvm_flash(struct qed_dev *cdev, const char *name)
{
const struct firmware *image;
@@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev, const char *name)
rc = qed_nvm_flash_image_access(cdev, &data,
&check_resp);
break;
+ case QED_NVM_FLASH_CMD_NVM_CFG_ID:
+ rc = qed_nvm_flash_cfg_write(cdev, &data);
+ break;
default:
DP_ERR(cdev, "Unknown command %08x\n", cmd_type);
rc = -EINVAL;
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index eef02e6..23805ea 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -804,6 +804,7 @@ enum qed_nvm_flash_cmd {
QED_NVM_FLASH_CMD_FILE_DATA = 0x2,
QED_NVM_FLASH_CMD_FILE_START = 0x3,
QED_NVM_FLASH_CMD_NVM_CHANGE = 0x4,
+ QED_NVM_FLASH_CMD_NVM_CFG_ID = 0x5,
QED_NVM_FLASH_CMD_NVM_MAX,
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] qed: Add API for configuring NVM attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-26 15:52 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190726155215.25151-1-skalluru@marvell.com>
The patch adds API for configuring the NVM config attributes using
Management FW (MFW) interfaces.
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 17 +++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 35 +++++++++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 20 ++++++++++++++++++
3 files changed, 72 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index e054f6c..557a12e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -12580,6 +12580,8 @@ struct public_drv_mb {
#define DRV_MSG_CODE_BW_UPDATE_ACK 0x32000000
#define DRV_MSG_CODE_NIG_DRAIN 0x30000000
#define DRV_MSG_CODE_S_TAG_UPDATE_ACK 0x3b000000
+#define DRV_MSG_CODE_GET_NVM_CFG_OPTION 0x003e0000
+#define DRV_MSG_CODE_SET_NVM_CFG_OPTION 0x003f0000
#define DRV_MSG_CODE_INITIATE_PF_FLR 0x02010000
#define DRV_MSG_CODE_VF_DISABLED_DONE 0xc0000000
#define DRV_MSG_CODE_CFG_VF_MSIX 0xc0010000
@@ -12748,6 +12750,21 @@ struct public_drv_mb {
#define DRV_MB_PARAM_FEATURE_SUPPORT_PORT_EEE 0x00000002
#define DRV_MB_PARAM_FEATURE_SUPPORT_FUNC_VLINK 0x00010000
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ID_SHIFT 0
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ID_MASK 0x0000FFFF
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ALL_SHIFT 16
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ALL_MASK 0x00010000
+#define DRV_MB_PARAM_NVM_CFG_OPTION_INIT_SHIFT 17
+#define DRV_MB_PARAM_NVM_CFG_OPTION_INIT_MASK 0x00020000
+#define DRV_MB_PARAM_NVM_CFG_OPTION_COMMIT_SHIFT 18
+#define DRV_MB_PARAM_NVM_CFG_OPTION_COMMIT_MASK 0x00040000
+#define DRV_MB_PARAM_NVM_CFG_OPTION_FREE_SHIFT 19
+#define DRV_MB_PARAM_NVM_CFG_OPTION_FREE_MASK 0x00080000
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ENTITY_SEL_SHIFT 20
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ENTITY_SEL_MASK 0x00100000
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ENTITY_ID_SHIFT 24
+#define DRV_MB_PARAM_NVM_CFG_OPTION_ENTITY_ID_MASK 0x0f000000
+
u32 fw_mb_header;
#define FW_MSG_CODE_MASK 0xffff0000
#define FW_MSG_CODE_UNSUPPORTED 0x00000000
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 758702c..daa20cf 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -3750,3 +3750,38 @@ int qed_mcp_get_ppfid_bitmap(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
return 0;
}
+
+int qed_mcp_nvm_set_cfg(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ u16 option_id, u8 entity_id, u16 flags, u8 *p_buf,
+ u32 len)
+{
+ u32 mb_param = 0, resp, param;
+ int rc;
+
+ QED_MFW_SET_FIELD(mb_param, DRV_MB_PARAM_NVM_CFG_OPTION_ID, option_id);
+ if (flags & QED_NVM_CFG_OPTION_ALL)
+ QED_MFW_SET_FIELD(mb_param,
+ DRV_MB_PARAM_NVM_CFG_OPTION_ALL, 1);
+ if (flags & QED_NVM_CFG_OPTION_INIT)
+ QED_MFW_SET_FIELD(mb_param,
+ DRV_MB_PARAM_NVM_CFG_OPTION_INIT, 1);
+ if (flags & QED_NVM_CFG_OPTION_COMMIT)
+ QED_MFW_SET_FIELD(mb_param,
+ DRV_MB_PARAM_NVM_CFG_OPTION_COMMIT, 1);
+ if (flags & QED_NVM_CFG_OPTION_FREE)
+ QED_MFW_SET_FIELD(mb_param,
+ DRV_MB_PARAM_NVM_CFG_OPTION_FREE, 1);
+ if (flags & QED_NVM_CFG_OPTION_ENTITY_SEL) {
+ QED_MFW_SET_FIELD(mb_param,
+ DRV_MB_PARAM_NVM_CFG_OPTION_ENTITY_SEL, 1);
+ QED_MFW_SET_FIELD(mb_param,
+ DRV_MB_PARAM_NVM_CFG_OPTION_ENTITY_ID,
+ entity_id);
+ }
+
+ rc = qed_mcp_nvm_wr_cmd(p_hwfn, p_ptt,
+ DRV_MSG_CODE_SET_NVM_CFG_OPTION,
+ mb_param, &resp, ¶m, len, (u32 *)p_buf);
+
+ return rc;
+}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.h b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
index e4f8fe4..83649a8 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
@@ -251,6 +251,12 @@ struct qed_mfw_tlv_generic {
struct qed_mfw_tlv_iscsi iscsi;
};
+#define QED_NVM_CFG_OPTION_ALL BIT(0)
+#define QED_NVM_CFG_OPTION_INIT BIT(1)
+#define QED_NVM_CFG_OPTION_COMMIT BIT(2)
+#define QED_NVM_CFG_OPTION_FREE BIT(3)
+#define QED_NVM_CFG_OPTION_ENTITY_SEL BIT(4)
+
/**
* @brief - returns the link params of the hw function
*
@@ -1202,4 +1208,18 @@ void qed_mcp_resc_lock_default_init(struct qed_resc_lock_params *p_lock,
*/
int qed_mcp_get_ppfid_bitmap(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
+/**
+ * @brief Set NVM config attribute value.
+ *
+ * @param p_hwfn
+ * @param p_ptt
+ * @param option_id
+ * @param entity_id
+ * @param flags
+ * @param p_buf
+ * @param len
+ */
+int qed_mcp_nvm_set_cfg(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ u16 option_id, u8 entity_id, u16 flags, u8 *p_buf,
+ u32 len);
#endif
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v2 0/2] qed*: Support for NVM config attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-26 15:52 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
The patch series adds support for managing the NVM config attributes.
Patch (1) adds functionality to update config attributes via MFW.
Patch (2) adds driver interface for updating the config attributes.
Changes from previous versions:
-------------------------------
v2: Removed unused API.
Please consider applying this series to "net-next".
Sudarsana Reddy Kalluru (2):
qed: Add API for configuring NVM attributes.
qed: Add driver API for flashing the config attributes.
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 17 ++++++++
drivers/net/ethernet/qlogic/qed/qed_main.c | 65 ++++++++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 35 ++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 20 +++++++++
include/linux/qed/qed_if.h | 1 +
5 files changed, 138 insertions(+)
--
1.8.3.1
^ permalink raw reply
* Re: next-20190723: bpf/seccomp - systemd/journald issue?
From: Yonghong Song @ 2019-07-26 15:45 UTC (permalink / raw)
To: sedat.dilek@gmail.com, Alexei Starovoitov, Daniel Borkmann,
Martin Lau, Song Liu
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Clang-Built-Linux ML,
Kees Cook, Nick Desaulniers, Nathan Chancellor
In-Reply-To: <CA+icZUWF=B_phP8eGD3v2d9jSSK6Y-N65y-T6xewZnY91vc2_Q@mail.gmail.com>
On 7/26/19 1:26 AM, Sedat Dilek wrote:
> Hi,
>
> I have opened a new issue in the ClangBuiltLinux issue tracker.
Glad to know clang 9 has asm goto support and now It can compile
kernel again.
>
> I am seeing a problem in the area bpf/seccomp causing
> systemd/journald/udevd services to fail.
>
> [Fri Jul 26 08:08:43 2019] systemd[453]: systemd-udevd.service: Failed
> to connect stdout to the journal socket, ignoring: Connection refused
>
> This happens when I use the (LLVM) LLD ld.lld-9 linker but not with
> BFD linker ld.bfd on Debian/buster AMD64.
> In both cases I use clang-9 (prerelease).
Looks like it is a lld bug.
I see the stack trace has __bpf_prog_run32() which is used by
kernel bpf interpreter. Could you try to enable bpf jit
sysctl net.core.bpf_jit_enable = 1
If this passed, it will prove it is interpreter related.
>
> Base for testing: next-20190723.
>
> The call-trace looks like this:
>
> [Fri Jul 26 08:08:42 2019] BUG: unable to handle page fault for
> address: ffffffff85403370
> [Fri Jul 26 08:08:42 2019] #PF: supervisor read access in kernel mode
> [Fri Jul 26 08:08:42 2019] #PF: error_code(0x0000) - not-present page
> [Fri Jul 26 08:08:42 2019] PGD 7620e067 P4D 7620e067 PUD 7620f063 PMD
> 44fe85063 PTE 800fffff8a3fc062
> [Fri Jul 26 08:08:42 2019] Oops: 0000 [#1] SMP PTI
> [Fri Jul 26 08:08:42 2019] CPU: 2 PID: 417 Comm: (journald) Not
> tainted 5.3.0-rc1-5-amd64-cbl-asmgoto #5~buster+dileks1
> [Fri Jul 26 08:08:42 2019] Hardware name: LENOVO
> 20HDCTO1WW/20HDCTO1WW, BIOS N1QET83W (1.58 ) 04/18/2019
> [Fri Jul 26 08:08:42 2019] RIP: 0010:___bpf_prog_run+0x40/0x14f0
> [Fri Jul 26 08:08:42 2019] Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c 00
> 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c c3
> 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 40 85 48 83 f8 3b 7f 62 48 83
> f8 1e 0f 8f c8 00
> [Fri Jul 26 08:08:42 2019] RSP: 0018:ffff992ec028fcb8 EFLAGS: 00010246
> [Fri Jul 26 08:08:42 2019] RAX: ffff992ec028fd60 RBX: ffff992ec00e9038
> RCX: 0000000000000002
> [Fri Jul 26 08:08:42 2019] RDX: ffff992ec028fd40 RSI: 00000000000000ac
> RDI: ffff992ec028fce0
> [Fri Jul 26 08:08:42 2019] RBP: ffff992ec028fcd0 R08: 0000000000000000
> R09: ffff992ec028ff58
> [Fri Jul 26 08:08:42 2019] R10: 0000000000000000 R11: ffffffff849b8210
> R12: 000000007fff0000
> [Fri Jul 26 08:08:42 2019] R13: ffff992ec028feb8 R14: 0000000000000000
> R15: ffff992ec028fce0
> [Fri Jul 26 08:08:42 2019] FS: 00007f5d20f1d940(0000)
> GS:ffff8ba3d2500000(0000) knlGS:0000000000000000
> [Fri Jul 26 08:08:42 2019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [Fri Jul 26 08:08:42 2019] CR2: ffffffff85403370 CR3: 0000000445b3e001
> CR4: 00000000003606e0
> [Fri Jul 26 08:08:42 2019] Call Trace:
> [Fri Jul 26 08:08:42 2019] __bpf_prog_run32+0x44/0x70
> [Fri Jul 26 08:08:42 2019] ? flush_tlb_func_common+0xd8/0x230
> [Fri Jul 26 08:08:42 2019] ? mem_cgroup_commit_charge+0x8c/0x120
> [Fri Jul 26 08:08:42 2019] ? wp_page_copy+0x464/0x7a0
> [Fri Jul 26 08:08:42 2019] seccomp_run_filters+0x54/0x110
> [Fri Jul 26 08:08:42 2019] __seccomp_filter+0xf7/0x6e0
> [Fri Jul 26 08:08:42 2019] ? do_wp_page+0x32b/0x5d0
> [Fri Jul 26 08:08:42 2019] ? handle_mm_fault+0x90d/0xbf0
> [Fri Jul 26 08:08:42 2019] syscall_trace_enter+0x182/0x290
> [Fri Jul 26 08:08:42 2019] do_syscall_64+0x30/0x90
> [Fri Jul 26 08:08:42 2019] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [Fri Jul 26 08:08:42 2019] RIP: 0033:0x7f5d220d7f59
> [Fri Jul 26 08:08:42 2019] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00
> 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8
> 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00
> f7 d8 64 89 01 48
> [Fri Jul 26 08:08:42 2019] RSP: 002b:00007ffd11332b48 EFLAGS: 00000246
> ORIG_RAX: 000000000000013d
> [Fri Jul 26 08:08:42 2019] RAX: ffffffffffffffda RBX: 000055bf8ab34010
> RCX: 00007f5d220d7f59
> [Fri Jul 26 08:08:42 2019] RDX: 000055bf8ab34010 RSI: 0000000000000000
> RDI: 0000000000000001
> [Fri Jul 26 08:08:42 2019] RBP: 000055bf8ab97fb0 R08: 000055bf8abbe180
> R09: 00000000c000003e
> [Fri Jul 26 08:08:42 2019] R10: 000055bf8abbe1e0 R11: 0000000000000246
> R12: 00007ffd11332ba0
> [Fri Jul 26 08:08:42 2019] R13: 00007ffd11332b98 R14: 00007f5d21f087f8
> R15: 000000000000002c
> [Fri Jul 26 08:08:42 2019] Modules linked in: i2c_dev parport_pc
> sunrpc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4
> crc32c_generic mbcache crc16 jbd2 btrfs zstd_decompress zstd_compress
> algif_skcipher af_alg sd_mod dm_crypt dm_mod raid10 raid456
> async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> raid6_pq libcrc32c raid1 uas raid0 usb_storage multipath linear
> scsi_mod md_mod hid_cherry hid_generic usbhid hid crct10dif_pclmul
> crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64
> i915 glue_helper crypto_simd nvme i2c_algo_bit cryptd psmouse xhci_pci
> drm_kms_helper e1000e i2c_i801 xhci_hcd intel_lpss_pci nvme_core
> intel_lpss drm usbcore thermal wmi video button
> [Fri Jul 26 08:08:42 2019] CR2: ffffffff85403370
> [Fri Jul 26 08:08:42 2019] ---[ end trace 867b35c7d6c6705a ]---
> [Fri Jul 26 08:08:42 2019] RIP: 0010:___bpf_prog_run+0x40/0x14f0
> [Fri Jul 26 08:08:42 2019] Code: f3 eb 24 48 83 f8 38 0f 84 a9 0c 00
> 00 48 83 f8 39 0f 85 8a 14 00 00 0f 1f 00 48 0f bf 43 02 48 8d 1c c3
> 48 83 c3 08 0f b6 33 <48> 8b 04 f5 10 2e 40 85 48 83 f8 3b 7f 62 48 83
> f8 1e 0f 8f c8 00
> [Fri Jul 26 08:08:42 2019] RSP: 0018:ffff992ec028fcb8 EFLAGS: 00010246
> [Fri Jul 26 08:08:42 2019] RAX: ffff992ec028fd60 RBX: ffff992ec00e9038
> RCX: 0000000000000002
> [Fri Jul 26 08:08:42 2019] RDX: ffff992ec028fd40 RSI: 00000000000000ac
> RDI: ffff992ec028fce0
> [Fri Jul 26 08:08:42 2019] RBP: ffff992ec028fcd0 R08: 0000000000000000
> R09: ffff992ec028ff58
> [Fri Jul 26 08:08:42 2019] R10: 0000000000000000 R11: ffffffff849b8210
> R12: 000000007fff0000
> [Fri Jul 26 08:08:42 2019] R13: ffff992ec028feb8 R14: 0000000000000000
> R15: ffff992ec028fce0
> [Fri Jul 26 08:08:42 2019] FS: 00007f5d20f1d940(0000)
> GS:ffff8ba3d2500000(0000) knlGS:0000000000000000
> [Fri Jul 26 08:08:42 2019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [Fri Jul 26 08:08:42 2019] CR2: ffffffff85403370 CR3: 0000000445b3e001
> CR4: 00000000003606e0
>
> More details in [1] and what I tried (for example CONFIG_SECCOMP=n)
>
> I have no clue about BPF or SECCOMP.
>
> Can you comment on this?
>
> If this touches BPF: Can you give me some hints and instructions in debugging?
>
> My kernel-config and dmesg-log are attached.
>
> Thanks.
>
> Regards,
> - Sedat -
>
> [1] https://github.com/ClangBuiltLinux/linux/issues/619
>
^ permalink raw reply
* Re: INFO: rcu detected stall in vhost_worker
From: syzbot @ 2019-07-26 15:26 UTC (permalink / raw)
To: jasowang, kvm, linux-kbuild, linux-kernel, michal.lkml, mst,
netdev, syzkaller-bugs, torvalds, virtualization, yamada.masahiro
In-Reply-To: <000000000000b4358f058e924c6d@google.com>
syzbot has bisected this bug to:
commit 0ecfebd2b52404ae0c54a878c872bb93363ada36
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Jul 7 22:41:56 2019 +0000
Linux 5.2
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=118810bfa00000
start commit: 13bf6d6a Add linux-next specific files for 20190725
git tree: linux-next
kernel config: https://syzkaller.appspot.com/x/.config?x=8ae987d803395886
dashboard link: https://syzkaller.appspot.com/bug?extid=36e93b425cd6eb54fcc1
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15112f3fa00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=131ab578600000
Reported-by: syzbot+36e93b425cd6eb54fcc1@syzkaller.appspotmail.com
Fixes: 0ecfebd2b524 ("Linux 5.2")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH v2] ethtool: igb: dump RR2DCDELAY register
From: John W. Linville @ 2019-07-26 15:26 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: netdev
In-Reply-To: <20190715105933.40924-1-dedekind1@gmail.com>
On Mon, Jul 15, 2019 at 01:59:33PM +0300, Artem Bityutskiy wrote:
> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
>
> Decode 'RR2DCDELAY' register which Linux kernel provides starting from version
> 5.3. The corresponding commit in the Linux kernel is:
> cd502a7f7c9c igb: add RR2DCDELAY to ethtool registers dump
>
> The RR2DCDELAY register is present in I210 and I211 Intel Gigabit Ethernet
> chips and it stands for "Read Request To Data Completion Delay". Here is how
> this register is described in the I210 datasheet:
>
> "This field captures the maximum PCIe split time in 16 ns units, which is the
> maximum delay between the read request to the first data completion. This is
> giving an estimation of the PCIe round trip time."
>
> In practice, this register can be used to measure the time it takes the NIC to
> read data from the host memory.
>
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Queued for next release -- thanks!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: René van Dorst @ 2019-07-26 15:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, frank-w, sean.wang, f.fainelli, linux, davem,
matthias.bgg, vivien.didelot, john, linux-mediatek, linux-mips,
robh+dt, devicetree
In-Reply-To: <20190726131604.GA18223@lunn.ch>
Quoting Andrew Lunn <andrew@lunn.ch>:
> On Fri, Jul 26, 2019 at 07:19:56AM +0000, René van Dorst wrote:
>> Quoting Andrew Lunn <andrew@lunn.ch>:
>>
>> >>+ gmac0: mac@0 {
>> >>+ compatible = "mediatek,eth-mac";
>> >>+ reg = <0>;
>> >>+ phy-mode = "sgmii";
>> >>+
>> >>+ fixed-link {
>> >>+ speed = <2500>;
>> >>+ full-duplex;
>> >>+ pause;
>> >>+ };
>> >>+ };
>> >
>> >Hi René
>> >
>>
>> Hi Andrew,
>>
>> >SGMII and fixed-link is rather odd. Why do you need this combination?
>>
>> BananaPi R64 has a RTL8367S 5+2-port switch, switch interfaces with the SOC
>> by a
>> (H)SGMII and/or RGMII interface. SGMII is mainly used for the LAN ports and
>> RGMII for the WAN port.
>>
>> I mimic the SDK software which puts SGMII interface in 2.5GBit fixed-link
>> mode.
>> The RTL8367S switch code also put switch mac in forge 2.5GBit mode.
>>
>> So this is the reason why I put a fixed-link mode here.
>
> Are you sure it is using SGMII and not 2500BaseX? Can you get access
> to the signalling word? SGMII is supposed to indicate to the MAC what
> speed it is using, via inband signalling. So there should not be any
> need for a fixed-link. 2500BaseX however does not have such
> signalling, so there would need to be a fixed link.
I am not sure.
I just converted the current mainline code to support phylink and
mimic the DTS
of the SDK. But the SDK seems to be incorrect.
Realtek[0] calls these modes:
* SGMII (1.25GHz) Interface
* High SGMII (3.125GHz) Interface
Also the datasheet that I have doesn't talk about base-x modes.
But MT7622 Reference manual[1] page 1960 says:
The core leverages the 1000Base-X PCS and Auto-Negotiation from IEEE 802.3
specification (clause 36/37). This IP can support up to 3.125G baud
for 2.5Gbps
(proprietary 2500Base-X) data rate of MAC by overclocking.
So I think it phy-mode should be 2500Base-X in this case.
SGMII part is a bit hard for me to support, I don't have the hardware,
MediaTek datasheets are mostly incomplete and also I am a not familiar
with it.
But I think I know what I have to change.
Based on your explanation above.
I think this more correct implementation:
* 1000base-x and 2500base-x always force the link.
* SGMII is always inband but I need in phylink_mac_link_status() to readout
"PCS_SPEED_ABILITY Clause 45 3.5" register to see the inband status?
Or is it just the GMAC PSMR register? For me it is a bit confusing.
SGMII block has a register to set the link speed and etc. But tests on the
bananapi R64 board shows that I also need to set the GMAC register else it
didn't work. Also it is not easy to debug if you don't have the board.
> Maybe we should really consider what phy-mode = "sgmii"; means. Should
> this include the overclocked 2.5G speed, or should we add a 2500sgmii
> link mode?
No.
>
> Andrew
Greats,
René
[0]:
https://www.realtek.com/en/products/communications-network-ics/item/rtl8367s-cg
[1]:
https://drive.google.com/file/d/1cW8KQmmVpwDGmBd48KNQes9CRn7FEgBb/view?usp=sharing
^ permalink raw reply
* Re: [PATCH net-next] mvpp2: document HW checksum behaviour
From: Matteo Croce @ 2019-07-26 14:35 UTC (permalink / raw)
To: Antoine Tenart
Cc: netdev, Maxime Chevallier, Marcin Wojtas, Stefan Chulski, LKML
In-Reply-To: <20190726125715.GB5031@kwain>
On Fri, Jul 26, 2019 at 2:57 PM Antoine Tenart
<antoine.tenart@bootlin.com> wrote:
>
> Hi Matteo,
>
> On Fri, Jul 26, 2019 at 01:15:46AM +0200, Matteo Croce wrote:
> > The hardware can only offload checksum calculation on first port due to
> > the Tx FIFO size limitation. Document this in a comment.
> >
> > Fixes: 576193f2d579 ("net: mvpp2: jumbo frames support")
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> Looks good. Please note there's a similar code path in the probe. You
> could also add a comment there (or move this check/comment in a common
> place).
>
> Thanks!
> Antoine
>
> > ---
> > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index d8e5241097a9..2f7286bd203b 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -843,7 +843,10 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, int mtu)
> > /* Add port to new short & long pool */
> > mvpp2_swf_bm_pool_init(port);
> >
> > - /* Update L4 checksum when jumbo enable/disable on port */
> > + /* Update L4 checksum when jumbo enable/disable on port.
> > + * Only port 0 supports hardware checksum offload due to
> > + * the Tx FIFO size limitation.
> > + */
> > if (new_long_pool == MVPP2_BM_JUMBO && port->id != 0) {
> > dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
> > dev->hw_features &= ~(NETIF_F_IP_CSUM |
> > --
> > 2.21.0
> >
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
I see, there is a similar statement in mvpp2_port_probe().
What about adding a static function which sets the flag, and add the
comment there instead of duplicating the comment?
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [PATCH net] mvpp2: refactor MTU change code
From: Matteo Croce @ 2019-07-26 14:26 UTC (permalink / raw)
To: Antoine Tenart
Cc: netdev, Maxime Chevallier, Marcin Wojtas, Stefan Chulski, LKML
In-Reply-To: <20190726125053.GA5031@kwain>
On Fri, Jul 26, 2019 at 2:50 PM Antoine Tenart
<antoine.tenart@bootlin.com> wrote:
>
> Hi Matteo,
>
> On Fri, Jul 26, 2019 at 01:19:31AM +0200, Matteo Croce wrote:
> > The MTU change code can call napi_disable() with the device already down,
> > leading to a deadlock. Also, lot of code is duplicated unnecessarily.
> >
> > Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code.
> >
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> As this is a fix sent to net, you could add a Fixes: tag.
>
> Otherwise this looks good,
> Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
>
> Thanks!
> Antoine
>
> > ---
> > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 41 ++++++-------------
> > 1 file changed, 13 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index 2f7286bd203b..60eb98f99571 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -3612,6 +3612,7 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
> > static int mvpp2_change_mtu(struct net_device *dev, int mtu)
> > {
> > struct mvpp2_port *port = netdev_priv(dev);
> > + bool running = netif_running(dev);
> > int err;
> >
> > if (!IS_ALIGNED(MVPP2_RX_PKT_SIZE(mtu), 8)) {
> > @@ -3620,40 +3621,24 @@ static int mvpp2_change_mtu(struct net_device *dev, int mtu)
> > mtu = ALIGN(MVPP2_RX_PKT_SIZE(mtu), 8);
> > }
> >
> > - if (!netif_running(dev)) {
> > - err = mvpp2_bm_update_mtu(dev, mtu);
> > - if (!err) {
> > - port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
> > - return 0;
> > - }
> > -
> > - /* Reconfigure BM to the original MTU */
> > - err = mvpp2_bm_update_mtu(dev, dev->mtu);
> > - if (err)
> > - goto log_error;
> > - }
> > -
> > - mvpp2_stop_dev(port);
> > + if (running)
> > + mvpp2_stop_dev(port);
> >
> > err = mvpp2_bm_update_mtu(dev, mtu);
> > - if (!err) {
> > + if (err) {
> > + netdev_err(dev, "failed to change MTU\n");
> > + /* Reconfigure BM to the original MTU */
> > + mvpp2_bm_update_mtu(dev, dev->mtu);
> > + } else {
> > port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
> > - goto out_start;
> > }
> >
> > - /* Reconfigure BM to the original MTU */
> > - err = mvpp2_bm_update_mtu(dev, dev->mtu);
> > - if (err)
> > - goto log_error;
> > -
> > -out_start:
> > - mvpp2_start_dev(port);
> > - mvpp2_egress_enable(port);
> > - mvpp2_ingress_enable(port);
> > + if (running) {
> > + mvpp2_start_dev(port);
> > + mvpp2_egress_enable(port);
> > + mvpp2_ingress_enable(port);
> > + }
> >
> > - return 0;
> > -log_error:
> > - netdev_err(dev, "failed to change MTU\n");
> > return err;
> > }
> >
> > --
> > 2.21.0
> >
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
It seems to me that the fixes tag should refer to the driver inclusion:
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375
network unit")
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()
From: santosh.shilimkar @ 2019-07-26 14:24 UTC (permalink / raw)
To: Jia-Ju Bai, davem; +Cc: netdev, linux-rdma, rds-devel, linux-kernel
In-Reply-To: <20190726141705.9585-1-baijiaju1990@gmail.com>
On 7/26/19 7:17 AM, Jia-Ju Bai wrote:
> In rds_rdma_cm_event_handler_cmn(), there are some if statements to
> check whether conn is NULL, such as on lines 65, 96 and 112.
> But conn is not checked before being used on line 108:
> trans->cm_connect_complete(conn, event);
> and on lines 140-143:
> rdsdebug("DISCONNECT event - dropping connection "
> "%pI6c->%pI6c\n", &conn->c_laddr,
> &conn->c_faddr);
> rds_conn_drop(conn);
>
> Thus, possible null-pointer dereferences may occur.
>
> To fix these bugs, conn is checked before being used.
>
> These bugs are found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
That's possible. Looks good.
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH] isdn/gigaset: check endpoint null in gigaset_probe
From: Paul Bolle @ 2019-07-26 14:22 UTC (permalink / raw)
To: Phong Tran, isdn, gregkh
Cc: gigaset307x-common, netdev, linux-kernel, linux-kernel-mentees,
syzbot+35b1c403a14f5c89eba7
In-Reply-To: <20190726133528.11063-1-tranmanphong@gmail.com>
Phong Tran schreef op vr 26-07-2019 om 20:35 [+0700]:
> This fixed the potential reference NULL pointer while using variable
> endpoint.
>
> Reported-by: syzbot+35b1c403a14f5c89eba7@syzkaller.appspotmail.com
> Tested by syzbot:
> https://groups.google.com/d/msg/syzkaller-bugs/wnHG8eRNWEA/Qn2HhjNdBgAJ
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> ---
> drivers/isdn/gigaset/usb-gigaset.c | 9 +++++++++
This is now drivers/staging/isdn/gigaset/usb-gigaset.c.
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/isdn/gigaset/usb-gigaset.c b/drivers/isdn/gigaset/usb-gigaset.c
> index 1b9b43659bdf..2e011f3db59e 100644
> --- a/drivers/isdn/gigaset/usb-gigaset.c
> +++ b/drivers/isdn/gigaset/usb-gigaset.c
> @@ -703,6 +703,10 @@ static int gigaset_probe(struct usb_interface *interface,
> usb_set_intfdata(interface, cs);
>
> endpoint = &hostif->endpoint[0].desc;
> + if (!endpoint) {
> + dev_err(cs->dev, "Couldn't get control endpoint\n");
> + return -ENODEV;
> + }
When can this happen? Is this one of those bugs that one can only trigger with
a specially crafted (evil) usb device?
> buffer_size = le16_to_cpu(endpoint->wMaxPacketSize);
> ucs->bulk_out_size = buffer_size;
> @@ -722,6 +726,11 @@ static int gigaset_probe(struct usb_interface *interface,
> }
>
> endpoint = &hostif->endpoint[1].desc;
> + if (!endpoint) {
> + dev_err(cs->dev, "Endpoint not available\n");
> + retval = -ENODEV;
> + goto error;
> + }
>
> ucs->busy = 0;
>
Please note that I'm very close to getting cut off from the ISDN network, so
the chances of being able to testi this on a live system are getting small.
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH] net: tipc: Fix a possible null-pointer dereference in tipc_publ_purge()
From: Ying Xue @ 2019-07-26 14:10 UTC (permalink / raw)
To: Jia-Ju Bai, jon.maloy, davem; +Cc: netdev, tipc-discussion, linux-kernel
In-Reply-To: <20190725092021.15855-1-baijiaju1990@gmail.com>
On 7/25/19 5:20 PM, Jia-Ju Bai wrote:
> In tipc_publ_purge(), there is an if statement on 215 to
> check whether p is NULL:
> if (p)
>
> When p is NULL, it is used on line 226:
> kfree_rcu(p, rcu);
>
> Thus, a possible null-pointer dereference may occur.
>
> To fix this bug, p is checked before being used.
>
> This bug is found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> net/tipc/name_distr.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> index 44abc8e9c990..241ed2274473 100644
> --- a/net/tipc/name_distr.c
> +++ b/net/tipc/name_distr.c
> @@ -223,7 +223,8 @@ static void tipc_publ_purge(struct net *net, struct publication *publ, u32 addr)
> publ->key);
> }
>
> - kfree_rcu(p, rcu);
> + if (p)
No, I don't think so because kfree_rcu() will internally check if "p"
pointer is NULL or not.
> + kfree_rcu(p, rcu);
> }
>
> /**
>
^ permalink raw reply
* [PATCH] rtw88: pci: remove set but not used variable 'ip_sel'
From: YueHaibing @ 2019-07-26 14:20 UTC (permalink / raw)
To: yhchuang, kvalo; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtw88/pci.c: In function 'rtw_pci_phy_cfg':
drivers/net/wireless/realtek/rtw88/pci.c:993:6: warning:
variable 'ip_sel' set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/realtek/rtw88/pci.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06a..c562515 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -990,7 +990,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
u16 cut;
u16 value;
u16 offset;
- u16 ip_sel;
int i;
cut = BIT(0) << rtwdev->hal.cut_version;
@@ -1003,7 +1002,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
break;
offset = para->offset;
value = para->value;
- ip_sel = para->ip_sel;
if (para->ip_sel == RTW_IP_SEL_PHY)
rtw_mdio_write(rtwdev, offset, value, true);
else
@@ -1018,7 +1016,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
break;
offset = para->offset;
value = para->value;
- ip_sel = para->ip_sel;
if (para->ip_sel == RTW_IP_SEL_PHY)
rtw_mdio_write(rtwdev, offset, value, false);
else
--
2.7.4
^ permalink raw reply related
* [PATCH] iwlwifi: mvm: fix old-style declaration
From: YueHaibing @ 2019-07-26 14:18 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo, sara.sharon
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
There expect the 'static' keyword to come first in a
declaration, and we get a warning for this with "make W=1":
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:427:1: warning:
'static' is not at beginning of declaration [-Wold-style-declaration]
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:434:1: warning:
'static' is not at beginning of declaration [-Wold-style-declaration]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 55cd49c..6ed0c49 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -424,14 +424,14 @@ int iwl_mvm_init_fw_regd(struct iwl_mvm *mvm)
return ret;
}
-const static u8 he_if_types_ext_capa_sta[] = {
+static const u8 he_if_types_ext_capa_sta[] = {
[0] = WLAN_EXT_CAPA1_EXT_CHANNEL_SWITCHING,
[2] = WLAN_EXT_CAPA3_MULTI_BSSID_SUPPORT,
[7] = WLAN_EXT_CAPA8_OPMODE_NOTIF,
[9] = WLAN_EXT_CAPA10_TWT_REQUESTER_SUPPORT,
};
-const static struct wiphy_iftype_ext_capab he_iftypes_ext_capa[] = {
+static const struct wiphy_iftype_ext_capab he_iftypes_ext_capa[] = {
{
.iftype = NL80211_IFTYPE_STATION,
.extended_capabilities = he_if_types_ext_capa_sta,
--
2.7.4
^ permalink raw reply related
* [PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()
From: Jia-Ju Bai @ 2019-07-26 14:17 UTC (permalink / raw)
To: santosh.shilimkar, davem
Cc: netdev, linux-rdma, rds-devel, linux-kernel, Jia-Ju Bai
In rds_rdma_cm_event_handler_cmn(), there are some if statements to
check whether conn is NULL, such as on lines 65, 96 and 112.
But conn is not checked before being used on line 108:
trans->cm_connect_complete(conn, event);
and on lines 140-143:
rdsdebug("DISCONNECT event - dropping connection "
"%pI6c->%pI6c\n", &conn->c_laddr,
&conn->c_faddr);
rds_conn_drop(conn);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, conn is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/rds/rdma_transport.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/rds/rdma_transport.c b/net/rds/rdma_transport.c
index ff74c4bbb9fc..9986d6065c4d 100644
--- a/net/rds/rdma_transport.c
+++ b/net/rds/rdma_transport.c
@@ -105,7 +105,8 @@ static int rds_rdma_cm_event_handler_cmn(struct rdma_cm_id *cm_id,
break;
case RDMA_CM_EVENT_ESTABLISHED:
- trans->cm_connect_complete(conn, event);
+ if (conn)
+ trans->cm_connect_complete(conn, event);
break;
case RDMA_CM_EVENT_REJECTED:
@@ -137,6 +138,8 @@ static int rds_rdma_cm_event_handler_cmn(struct rdma_cm_id *cm_id,
break;
case RDMA_CM_EVENT_DISCONNECTED:
+ if (!conn)
+ break;
rdsdebug("DISCONNECT event - dropping connection "
"%pI6c->%pI6c\n", &conn->c_laddr,
&conn->c_faddr);
--
2.17.0
^ permalink raw reply related
* [PATCH] brcmsmac: remove three set but not used variables
From: YueHaibing @ 2019-07-26 14:15 UTC (permalink / raw)
To: kvalo, arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng
Cc: linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c: In function 'brcms_c_set_gmode':
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5257:7: warning: variable 'preamble_restrict' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5256:6: warning: variable 'preamble' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5251:7: warning: variable 'shortslot_restrict' set but not used [-Wunused-but-set-variable]
They are never used so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
index 7d4e8f5..080e829 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
@@ -5248,15 +5248,7 @@ int brcms_c_set_gmode(struct brcms_c_info *wlc, u8 gmode, bool config)
/* Default to 54g Auto */
/* Advertise and use shortslot (-1/0/1 Auto/Off/On) */
s8 shortslot = BRCMS_SHORTSLOT_AUTO;
- bool shortslot_restrict = false; /* Restrict association to stations
- * that support shortslot
- */
bool ofdm_basic = false; /* Make 6, 12, and 24 basic rates */
- /* Advertise and use short preambles (-1/0/1 Auto/Off/On) */
- int preamble = BRCMS_PLCP_LONG;
- bool preamble_restrict = false; /* Restrict association to stations
- * that support short preambles
- */
struct brcms_band *band;
/* if N-support is enabled, allow Gmode set as long as requested
@@ -5297,16 +5289,11 @@ int brcms_c_set_gmode(struct brcms_c_info *wlc, u8 gmode, bool config)
case GMODE_ONLY:
ofdm_basic = true;
- preamble = BRCMS_PLCP_SHORT;
- preamble_restrict = true;
break;
case GMODE_PERFORMANCE:
shortslot = BRCMS_SHORTSLOT_ON;
- shortslot_restrict = true;
ofdm_basic = true;
- preamble = BRCMS_PLCP_SHORT;
- preamble_restrict = true;
break;
default:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-26 14:11 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Maxime Coquelin, linux-tegra, Giuseppe Cavallaro, Robin Murphy,
David S . Miller
In-Reply-To: <BYAPR12MB3269B4A401E4DA10A07515C7D3C10@BYAPR12MB3269.namprd12.prod.outlook.com>
On 25/07/2019 16:12, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/25/2019, 15:25:59 (UTC+00:00)
>
>>
>> On 25/07/2019 14:26, Jose Abreu wrote:
>>
>> ...
>>
>>> Well, I wasn't expecting that :/
>>>
>>> Per documentation of barriers I think we should set descriptor fields
>>> and then barrier and finally ownership to HW so that remaining fields
>>> are coherent before owner is set.
>>>
>>> Anyway, can you also add a dma_rmb() after the call to
>>> stmmac_rx_status() ?
>>
>> Yes. I removed the debug print added the barrier, but that did not help.
>
> So, I was finally able to setup NFS using your replicated setup and I
> can't see the issue :(
>
> The only difference I have from yours is that I'm using TCP in NFS
> whilst you (I believe from the logs), use UDP.
So I tried TCP by setting the kernel boot params to 'nfsvers=3' and
'proto=tcp' and this does appear to be more stable, but not 100% stable.
It still appears to fail in the same place about 50% of the time.
> You do have flow control active right ? And your HW FIFO size is >= 4k ?
How can I verify if flow control is active?
The documentation for this device indicates a max transfer size of 16kB
for TX and RX.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] net/mlx5e: Fix zero table prio set by user.
From: Marcelo Ricardo Leitner @ 2019-07-26 14:01 UTC (permalink / raw)
To: wenxu
Cc: Or Gerlitz, Saeed Mahameed, Roi Dayan, Mark Bloch, Paul Blakey,
pablo, netdev@vger.kernel.org
In-Reply-To: <692b090f-c19e-aa8b-796e-17999ac79df1@ucloud.cn>
On Fri, Jul 26, 2019 at 08:39:43PM +0800, wenxu wrote:
>
> 在 2019/7/26 20:19, Or Gerlitz 写道:
> > On Fri, Jul 26, 2019 at 12:24 AM Saeed Mahameed <saeedm@mellanox.com> wrote:
> >> On Thu, 2019-07-25 at 19:24 +0800, wenxu@ucloud.cn wrote:
> >>> From: wenxu <wenxu@ucloud.cn>
> >>>
> >>> The flow_cls_common_offload prio is zero
> >>>
> >>> It leads the invalid table prio in hw.
> >>>
> >>> Error: Could not process rule: Invalid argument
> >>>
> >>> kernel log:
> >>> mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22
> >>> (table prio: 65535, level: 0, size: 4194304)
> >>>
> >>> table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
> >>> should check (chain * FDB_MAX_PRIO) + prio is not 0
> >>>
> >>> Signed-off-by: wenxu <wenxu@ucloud.cn>
> >>> ---
> >>> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git
> >>> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> index 089ae4d..64ca90f 100644
> >>> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> @@ -970,7 +970,9 @@ static int esw_add_fdb_miss_rule(struct
> >> this piece of code isn't in this function, weird how it got to the
> >> diff, patch applies correctly though !
> >>
> >>> mlx5_eswitch *esw)
> >>> flags |= (MLX5_FLOW_TABLE_TUNNEL_EN_REFORMAT |
> >>> MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
> >>>
> >>> - table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
> >>> + table_prio = (chain * FDB_MAX_PRIO) + prio;
> >>> + if (table_prio)
> >>> + table_prio = table_prio - 1;
> >>>
> >> This is black magic, even before this fix.
> >> this -1 seems to be needed in order to call
> >> create_next_size_table(table_prio) with the previous "table prio" ?
> >> (table_prio - 1) ?
> >>
> >> The whole thing looks wrong to me since when prio is 0 and chain is 0,
> >> there is not such thing table_prio - 1.
> >>
> >> mlnx eswitch guys in the cc, please advise.
> > basically, prio 0 is not something we ever get in the driver, since if
> > user space
> > specifies 0, the kernel generates some random non-zero prio, and we support
> > only prios 1-16 -- Wenxu -- what do you run to get this error?
> >
> >
> I run offload with nfatbles(but not tc), there is no prio for each rule.
>
> prio of flow_cls_common_offload init as 0.
>
> static void nft_flow_offload_common_init(struct flow_cls_common_offload *common,
>
> __be16 proto,
> struct netlink_ext_ack *extack)
> {
> common->protocol = proto;
> common->extack = extack;
> }
>
>
> flow_cls_common_offload
Note that on
[PATCH net-next] netfilter: nf_table_offload: Fix zero prio of flow_cls_common_offload
I asked Pablo on how nftables should behave on this situation.
It's the same issue as in the patch above but being fixed at a
different level.
^ permalink raw reply
* [PATCH AUTOSEL 5.2 39/85] selftests/bpf: do not ignore clang failures
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ilya Leoshkevich, Andrii Nakryiko, Daniel Borkmann, Sasha Levin,
linux-kselftest, netdev, bpf, clang-built-linux
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Ilya Leoshkevich <iii@linux.ibm.com>
[ Upstream commit 9cae4ace80ef39005da106fbb89c952b27d7b89e ]
When compiling an eBPF prog fails, make still returns 0, because
failing clang command's output is piped to llc and therefore its
exit status is ignored.
When clang fails, pipe the string "clang failed" to llc. This will make
llc fail with an informative error message. This solution was chosen
over using pipefail, having separate targets or getting rid of llc
invocation due to its simplicity.
In addition, pull Kbuild.include in order to get .DELETE_ON_ERROR target,
which would cause partial .o files to be removed.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/bpf/Makefile | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index e36356e2377e..e375f399b7a6 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+include ../../../../scripts/Kbuild.include
LIBDIR := ../../../lib
BPFDIR := $(LIBDIR)/bpf
@@ -185,8 +186,8 @@ $(ALU32_BUILD_DIR)/test_progs_32: prog_tests/*.c
$(ALU32_BUILD_DIR)/%.o: progs/%.c $(ALU32_BUILD_DIR) \
$(ALU32_BUILD_DIR)/test_progs_32
- $(CLANG) $(CLANG_FLAGS) \
- -O2 -target bpf -emit-llvm -c $< -o - | \
+ ($(CLANG) $(CLANG_FLAGS) -O2 -target bpf -emit-llvm -c $< -o - || \
+ echo "clang failed") | \
$(LLC) -march=bpf -mattr=+alu32 -mcpu=$(CPU) $(LLC_FLAGS) \
-filetype=obj -o $@
ifeq ($(DWARF2BTF),y)
@@ -197,16 +198,16 @@ endif
# Have one program compiled without "-target bpf" to test whether libbpf loads
# it successfully
$(OUTPUT)/test_xdp.o: progs/test_xdp.c
- $(CLANG) $(CLANG_FLAGS) \
- -O2 -emit-llvm -c $< -o - | \
+ ($(CLANG) $(CLANG_FLAGS) -O2 -emit-llvm -c $< -o - || \
+ echo "clang failed") | \
$(LLC) -march=bpf -mcpu=$(CPU) $(LLC_FLAGS) -filetype=obj -o $@
ifeq ($(DWARF2BTF),y)
$(BTF_PAHOLE) -J $@
endif
$(OUTPUT)/%.o: progs/%.c
- $(CLANG) $(CLANG_FLAGS) \
- -O2 -target bpf -emit-llvm -c $< -o - | \
+ ($(CLANG) $(CLANG_FLAGS) -O2 -target bpf -emit-llvm -c $< -o - || \
+ echo "clang failed") | \
$(LLC) -march=bpf -mcpu=$(CPU) $(LLC_FLAGS) -filetype=obj -o $@
ifeq ($(DWARF2BTF),y)
$(BTF_PAHOLE) -J $@
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 45/85] ISDN: hfcsusb: checking idx of ep configuration
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, syzbot+8750abbc3a46ef47d509, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit f384e62a82ba5d85408405fdd6aeff89354deaa9 ]
The syzbot test with random endpoint address which made the idx is
overflow in the table of endpoint configuations.
this adds the checking for fixing the error report from
syzbot
KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
The patch tested by syzbot [2]
Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
[1]:
https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
[2]:
https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 4c99739b937e..0e224232f746 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1955,6 +1955,9 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
/* get endpoint base */
idx = ((ep_addr & 0x7f) - 1) * 2;
+ if (idx > 15)
+ return -EIO;
+
if (ep_addr & 0x80)
idx++;
attr = ep->desc.bmAttributes;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 48/85] libbpf: fix another GCC8 warning for strncpy
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Magnus Karlsson, Alexei Starovoitov, Sasha Levin,
netdev, bpf
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Andrii Nakryiko <andriin@fb.com>
[ Upstream commit 763ff0e7d9c72e7094b31e7fb84a859be9325635 ]
Similar issue was fixed in cdfc7f888c2a ("libbpf: fix GCC8 warning for
strncpy") already. This one was missed. Fixing now.
Cc: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/xsk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 38667b62f1fe..aa37005209aa 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -561,7 +561,8 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const char *ifname,
err = -errno;
goto out_socket;
}
- strncpy(xsk->ifname, ifname, IFNAMSIZ);
+ strncpy(xsk->ifname, ifname, IFNAMSIZ - 1);
+ xsk->ifname[IFNAMSIZ - 1] = '\0';
err = xsk_set_xdp_socket_config(&xsk->config, usr_config);
if (err)
--
2.20.1
^ 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