* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2018-06-01 3:59 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20180531073855.29c23fce@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
Hi all,
On Thu, 31 May 2018 07:38:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 29 May 2018 13:25:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output
> >
> > Caused by commit
> >
> > d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
> >
> > In my builds, the host is PowerPC 64 LE ...
> >
> > I have reverted that commit along with
> >
> > 61a552eb487f ("bpfilter: fix build dependency")
> > 13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug")
> >
> > for today.
>
> I am still getting this failure (well, at least yesterday I did).
Still happened today. My guess is that bpfilter_umh needs to be built
with the kernel compiler (not the host compiler - since ir is meant to
run on the some machine as the kernel, right?) but will require the
kernel architecture libc etc
I replaced the reverts above with the following:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 1 Jun 2018 13:33:28 +1000
Subject: [PATCH] net: bpfilter: mark as BROKEN for now
This does not build in a cross compile environment
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/bpfilter/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bpfilter/Kconfig b/net/bpfilter/Kconfig
index a948b072c28f..ea4be72fdf6e 100644
--- a/net/bpfilter/Kconfig
+++ b/net/bpfilter/Kconfig
@@ -2,6 +2,7 @@ menuconfig BPFILTER
bool "BPF based packet filtering framework (BPFILTER)"
default n
depends on NET && BPF && INET
+ depends on BROKEN
help
This builds experimental bpfilter framework that is aiming to
provide netfilter compatible functionality via BPF
--
2.17.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next] qed: Add srq core support for RoCE and iWARP
From: kbuild test robot @ 2018-06-01 3:41 UTC (permalink / raw)
To: Yuval Bason
Cc: kbuild-all, yuval.bason, davem, netdev, jgg, dledford, linux-rdma,
Michal Kalderon, Ariel Elior
In-Reply-To: <20180530131137.4653-1-yuval.bason@cavium.com>
Hi Yuval,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Yuval-Bason/qed-Add-srq-core-support-for-RoCE-and-iWARP/20180601-073407
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:137:5: sparse: symbol 'qed_rdma_get_sb_id' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_rdma.c:448:32: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:448:32: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:452:36: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:452:36: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:459:27: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:459:27: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:471:19: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:471:19: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:544:30: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:709:5: sparse: symbol 'qed_rdma_stop' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_rdma.c:796:33: sparse: cast removes address space of expression
drivers/net/ethernet/qlogic/qed/qed_rdma.c:899:16: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:899:16: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:921:16: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:921:16: sparse: expression using sizeof(void)
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1063:31: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] int_timeout @@ got unsignedrestricted __le16 [usertype] int_timeout @@
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1063:31: expected restricted __le16 [usertype] int_timeout
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1063:31: got unsigned short [unsigned] [usertype] int_timeout
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1165:21: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [short] [usertype] <noident> @@ got unsigned] [short] [usertype] <noident> @@
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1165:21: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1165:21: got restricted __le16 [usertype] <noident>
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1166:21: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [short] [usertype] <noident> @@ got unsigned] [short] [usertype] <noident> @@
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1166:21: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1166:21: got restricted __le16 [usertype] <noident>
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1167:21: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [short] [usertype] <noident> @@ got unsigned] [short] [usertype] <noident> @@
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1167:21: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1167:21: got restricted __le16 [usertype] <noident>
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1458:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1458:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1458:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1458:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1458:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1458:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1462:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1462:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1462:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1462:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1462:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1462:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1470:17: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1470:17: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1470:17: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1470:17: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1470:17: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1470:17: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1474:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1474:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1474:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1474:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1474:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1474:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1478:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1478:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1478:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1478:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1478:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1478:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1482:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1482:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1482:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1482:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1482:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1482:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1486:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1486:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1486:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1486:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1486:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1486:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1490:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1490:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1490:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1490:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1490:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1490:9: right side has type unsigned long long
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1493:9: sparse: invalid assignment: &=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1493:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1493:9: right side has type int
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1493:9: sparse: invalid assignment: |=
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1493:9: left side has type restricted __le16
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1493:9: right side has type unsigned long long
>> drivers/net/ethernet/qlogic/qed/qed_rdma.c:1679:29: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] wqe_limit @@ got restricted __le32 [usertype] wqe_limit @@
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1679:29: expected restricted __le32 [usertype] wqe_limit
drivers/net/ethernet/qlogic/qed/qed_rdma.c:1679:29: got restricted __le16 [usertype] <noident>
>> drivers/net/ethernet/qlogic/qed/qed_rdma.c:1655:5: sparse: symbol 'qed_rdma_modify_srq' was not declared. Should it be static?
>> drivers/net/ethernet/qlogic/qed/qed_rdma.c:1691:5: sparse: symbol 'qed_rdma_destroy_srq' was not declared. Should it be static?
>> drivers/net/ethernet/qlogic/qed/qed_rdma.c:1734:5: sparse: symbol 'qed_rdma_create_srq' was not declared. Should it be static?
Please review and possibly fold the followup patch.
vim +1679 drivers/net/ethernet/qlogic/qed/qed_rdma.c
1425
1426 static int
1427 qed_rdma_register_tid(void *rdma_cxt,
1428 struct qed_rdma_register_tid_in_params *params)
1429 {
1430 struct qed_hwfn *p_hwfn = (struct qed_hwfn *)rdma_cxt;
1431 struct rdma_register_tid_ramrod_data *p_ramrod;
1432 struct qed_sp_init_data init_data;
1433 struct qed_spq_entry *p_ent;
1434 enum rdma_tid_type tid_type;
1435 u8 fw_return_code;
1436 int rc;
1437
1438 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "itid = %08x\n", params->itid);
1439
1440 /* Get SPQ entry */
1441 memset(&init_data, 0, sizeof(init_data));
1442 init_data.opaque_fid = p_hwfn->hw_info.opaque_fid;
1443 init_data.comp_mode = QED_SPQ_MODE_EBLOCK;
1444
1445 rc = qed_sp_init_request(p_hwfn, &p_ent, RDMA_RAMROD_REGISTER_MR,
1446 p_hwfn->p_rdma_info->proto, &init_data);
1447 if (rc) {
1448 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "rc = %d\n", rc);
1449 return rc;
1450 }
1451
1452 if (p_hwfn->p_rdma_info->last_tid < params->itid)
1453 p_hwfn->p_rdma_info->last_tid = params->itid;
1454
1455 p_ramrod = &p_ent->ramrod.rdma_register_tid;
1456
1457 p_ramrod->flags = 0;
1458 SET_FIELD(p_ramrod->flags,
1459 RDMA_REGISTER_TID_RAMROD_DATA_TWO_LEVEL_PBL,
1460 params->pbl_two_level);
1461
1462 SET_FIELD(p_ramrod->flags,
1463 RDMA_REGISTER_TID_RAMROD_DATA_ZERO_BASED, params->zbva);
1464
1465 SET_FIELD(p_ramrod->flags,
1466 RDMA_REGISTER_TID_RAMROD_DATA_PHY_MR, params->phy_mr);
1467
1468 /* Don't initialize D/C field, as it may override other bits. */
1469 if (!(params->tid_type == QED_RDMA_TID_FMR) && !(params->dma_mr))
1470 SET_FIELD(p_ramrod->flags,
1471 RDMA_REGISTER_TID_RAMROD_DATA_PAGE_SIZE_LOG,
1472 params->page_size_log - 12);
1473
1474 SET_FIELD(p_ramrod->flags,
1475 RDMA_REGISTER_TID_RAMROD_DATA_REMOTE_READ,
1476 params->remote_read);
1477
1478 SET_FIELD(p_ramrod->flags,
1479 RDMA_REGISTER_TID_RAMROD_DATA_REMOTE_WRITE,
1480 params->remote_write);
1481
1482 SET_FIELD(p_ramrod->flags,
1483 RDMA_REGISTER_TID_RAMROD_DATA_REMOTE_ATOMIC,
1484 params->remote_atomic);
1485
1486 SET_FIELD(p_ramrod->flags,
1487 RDMA_REGISTER_TID_RAMROD_DATA_LOCAL_WRITE,
1488 params->local_write);
1489
> 1490 SET_FIELD(p_ramrod->flags,
1491 RDMA_REGISTER_TID_RAMROD_DATA_LOCAL_READ, params->local_read);
1492
> 1493 SET_FIELD(p_ramrod->flags,
1494 RDMA_REGISTER_TID_RAMROD_DATA_ENABLE_MW_BIND,
1495 params->mw_bind);
1496
1497 SET_FIELD(p_ramrod->flags1,
1498 RDMA_REGISTER_TID_RAMROD_DATA_PBL_PAGE_SIZE_LOG,
1499 params->pbl_page_size_log - 12);
1500
1501 SET_FIELD(p_ramrod->flags2,
1502 RDMA_REGISTER_TID_RAMROD_DATA_DMA_MR, params->dma_mr);
1503
1504 switch (params->tid_type) {
1505 case QED_RDMA_TID_REGISTERED_MR:
1506 tid_type = RDMA_TID_REGISTERED_MR;
1507 break;
1508 case QED_RDMA_TID_FMR:
1509 tid_type = RDMA_TID_FMR;
1510 break;
1511 case QED_RDMA_TID_MW_TYPE1:
1512 tid_type = RDMA_TID_MW_TYPE1;
1513 break;
1514 case QED_RDMA_TID_MW_TYPE2A:
1515 tid_type = RDMA_TID_MW_TYPE2A;
1516 break;
1517 default:
1518 rc = -EINVAL;
1519 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "rc = %d\n", rc);
1520 return rc;
1521 }
1522 SET_FIELD(p_ramrod->flags1,
1523 RDMA_REGISTER_TID_RAMROD_DATA_TID_TYPE, tid_type);
1524
1525 p_ramrod->itid = cpu_to_le32(params->itid);
1526 p_ramrod->key = params->key;
1527 p_ramrod->pd = cpu_to_le16(params->pd);
1528 p_ramrod->length_hi = (u8)(params->length >> 32);
1529 p_ramrod->length_lo = DMA_LO_LE(params->length);
1530 if (params->zbva) {
1531 /* Lower 32 bits of the registered MR address.
1532 * In case of zero based MR, will hold FBO
1533 */
1534 p_ramrod->va.hi = 0;
1535 p_ramrod->va.lo = cpu_to_le32(params->fbo);
1536 } else {
1537 DMA_REGPAIR_LE(p_ramrod->va, params->vaddr);
1538 }
1539 DMA_REGPAIR_LE(p_ramrod->pbl_base, params->pbl_ptr);
1540
1541 /* DIF */
1542 if (params->dif_enabled) {
1543 SET_FIELD(p_ramrod->flags2,
1544 RDMA_REGISTER_TID_RAMROD_DATA_DIF_ON_HOST_FLG, 1);
1545 DMA_REGPAIR_LE(p_ramrod->dif_error_addr,
1546 params->dif_error_addr);
1547 DMA_REGPAIR_LE(p_ramrod->dif_runt_addr, params->dif_runt_addr);
1548 }
1549
1550 rc = qed_spq_post(p_hwfn, p_ent, &fw_return_code);
1551 if (rc)
1552 return rc;
1553
1554 if (fw_return_code != RDMA_RETURN_OK) {
1555 DP_NOTICE(p_hwfn, "fw_return_code = %d\n", fw_return_code);
1556 return -EINVAL;
1557 }
1558
1559 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "Register TID, rc = %d\n", rc);
1560 return rc;
1561 }
1562
1563 static int qed_rdma_deregister_tid(void *rdma_cxt, u32 itid)
1564 {
1565 struct qed_hwfn *p_hwfn = (struct qed_hwfn *)rdma_cxt;
1566 struct rdma_deregister_tid_ramrod_data *p_ramrod;
1567 struct qed_sp_init_data init_data;
1568 struct qed_spq_entry *p_ent;
1569 struct qed_ptt *p_ptt;
1570 u8 fw_return_code;
1571 int rc;
1572
1573 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "itid = %08x\n", itid);
1574
1575 /* Get SPQ entry */
1576 memset(&init_data, 0, sizeof(init_data));
1577 init_data.opaque_fid = p_hwfn->hw_info.opaque_fid;
1578 init_data.comp_mode = QED_SPQ_MODE_EBLOCK;
1579
1580 rc = qed_sp_init_request(p_hwfn, &p_ent, RDMA_RAMROD_DEREGISTER_MR,
1581 p_hwfn->p_rdma_info->proto, &init_data);
1582 if (rc) {
1583 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "rc = %d\n", rc);
1584 return rc;
1585 }
1586
1587 p_ramrod = &p_ent->ramrod.rdma_deregister_tid;
1588 p_ramrod->itid = cpu_to_le32(itid);
1589
1590 rc = qed_spq_post(p_hwfn, p_ent, &fw_return_code);
1591 if (rc) {
1592 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "rc = %d\n", rc);
1593 return rc;
1594 }
1595
1596 if (fw_return_code == RDMA_RETURN_DEREGISTER_MR_BAD_STATE_ERR) {
1597 DP_NOTICE(p_hwfn, "fw_return_code = %d\n", fw_return_code);
1598 return -EINVAL;
1599 } else if (fw_return_code == RDMA_RETURN_NIG_DRAIN_REQ) {
1600 /* Bit indicating that the TID is in use and a nig drain is
1601 * required before sending the ramrod again
1602 */
1603 p_ptt = qed_ptt_acquire(p_hwfn);
1604 if (!p_ptt) {
1605 rc = -EBUSY;
1606 DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
1607 "Failed to acquire PTT\n");
1608 return rc;
1609 }
1610
1611 rc = qed_mcp_drain(p_hwfn, p_ptt);
1612 if (rc) {
1613 qed_ptt_release(p_hwfn, p_ptt);
1614 DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
1615 "Drain failed\n");
1616 return rc;
1617 }
1618
1619 qed_ptt_release(p_hwfn, p_ptt);
1620
1621 /* Resend the ramrod */
1622 rc = qed_sp_init_request(p_hwfn, &p_ent,
1623 RDMA_RAMROD_DEREGISTER_MR,
1624 p_hwfn->p_rdma_info->proto,
1625 &init_data);
1626 if (rc) {
1627 DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
1628 "Failed to init sp-element\n");
1629 return rc;
1630 }
1631
1632 rc = qed_spq_post(p_hwfn, p_ent, &fw_return_code);
1633 if (rc) {
1634 DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
1635 "Ramrod failed\n");
1636 return rc;
1637 }
1638
1639 if (fw_return_code != RDMA_RETURN_OK) {
1640 DP_NOTICE(p_hwfn, "fw_return_code = %d\n",
1641 fw_return_code);
1642 return rc;
1643 }
1644 }
1645
1646 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "De-registered TID, rc = %d\n", rc);
1647 return rc;
1648 }
1649
1650 static void *qed_rdma_get_rdma_ctx(struct qed_dev *cdev)
1651 {
1652 return QED_LEADING_HWFN(cdev);
1653 }
1654
> 1655 int qed_rdma_modify_srq(void *rdma_cxt,
1656 struct qed_rdma_modify_srq_in_params *in_params)
1657 {
1658 struct rdma_srq_modify_ramrod_data *p_ramrod;
1659 struct qed_hwfn *p_hwfn = rdma_cxt;
1660 struct qed_sp_init_data init_data;
1661 struct qed_spq_entry *p_ent;
1662 u16 opaque_fid;
1663 int rc;
1664
1665 memset(&init_data, 0, sizeof(init_data));
1666 init_data.opaque_fid = p_hwfn->hw_info.opaque_fid;
1667 init_data.comp_mode = QED_SPQ_MODE_EBLOCK;
1668
1669 rc = qed_sp_init_request(p_hwfn, &p_ent,
1670 RDMA_RAMROD_MODIFY_SRQ,
1671 p_hwfn->p_rdma_info->proto, &init_data);
1672 if (rc)
1673 return rc;
1674
1675 p_ramrod = &p_ent->ramrod.rdma_modify_srq;
1676 p_ramrod->srq_id.srq_idx = cpu_to_le16(in_params->srq_id);
1677 opaque_fid = p_hwfn->hw_info.opaque_fid;
1678 p_ramrod->srq_id.opaque_fid = cpu_to_le16(opaque_fid);
> 1679 p_ramrod->wqe_limit = cpu_to_le16(in_params->wqe_limit);
1680
1681 rc = qed_spq_post(p_hwfn, p_ent, NULL);
1682 if (rc)
1683 return rc;
1684
1685 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "modified SRQ id = %x",
1686 in_params->srq_id);
1687
1688 return rc;
1689 }
1690
> 1691 int qed_rdma_destroy_srq(void *rdma_cxt,
1692 struct qed_rdma_destroy_srq_in_params *in_params)
1693 {
1694 struct rdma_srq_destroy_ramrod_data *p_ramrod;
1695 struct qed_hwfn *p_hwfn = rdma_cxt;
1696 struct qed_sp_init_data init_data;
1697 struct qed_spq_entry *p_ent;
1698 struct qed_bmap *bmap;
1699 u16 opaque_fid;
1700 int rc;
1701
1702 opaque_fid = p_hwfn->hw_info.opaque_fid;
1703
1704 memset(&init_data, 0, sizeof(init_data));
1705 init_data.opaque_fid = opaque_fid;
1706 init_data.comp_mode = QED_SPQ_MODE_EBLOCK;
1707
1708 rc = qed_sp_init_request(p_hwfn, &p_ent,
1709 RDMA_RAMROD_DESTROY_SRQ,
1710 p_hwfn->p_rdma_info->proto, &init_data);
1711 if (rc)
1712 return rc;
1713
1714 p_ramrod = &p_ent->ramrod.rdma_destroy_srq;
1715 p_ramrod->srq_id.srq_idx = cpu_to_le16(in_params->srq_id);
1716 p_ramrod->srq_id.opaque_fid = cpu_to_le16(opaque_fid);
1717
1718 rc = qed_spq_post(p_hwfn, p_ent, NULL);
1719 if (rc)
1720 return rc;
1721
1722 bmap = &p_hwfn->p_rdma_info->srq_map;
1723
1724 spin_lock_bh(&p_hwfn->p_rdma_info->lock);
1725 qed_bmap_release_id(p_hwfn, bmap, in_params->srq_id);
1726 spin_unlock_bh(&p_hwfn->p_rdma_info->lock);
1727
1728 DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "SRQ destroyed Id = %x",
1729 in_params->srq_id);
1730
1731 return rc;
1732 }
1733
> 1734 int qed_rdma_create_srq(void *rdma_cxt,
1735 struct qed_rdma_create_srq_in_params *in_params,
1736 struct qed_rdma_create_srq_out_params *out_params)
1737 {
1738 struct rdma_srq_create_ramrod_data *p_ramrod;
1739 struct qed_hwfn *p_hwfn = rdma_cxt;
1740 struct qed_sp_init_data init_data;
1741 enum qed_cxt_elem_type elem_type;
1742 struct qed_spq_entry *p_ent;
1743 u16 opaque_fid, srq_id;
1744 struct qed_bmap *bmap;
1745 u32 returned_id;
1746 int rc;
1747
1748 bmap = &p_hwfn->p_rdma_info->srq_map;
1749 spin_lock_bh(&p_hwfn->p_rdma_info->lock);
1750 rc = qed_rdma_bmap_alloc_id(p_hwfn, bmap, &returned_id);
1751 spin_unlock_bh(&p_hwfn->p_rdma_info->lock);
1752
1753 if (rc) {
1754 DP_NOTICE(p_hwfn, "failed to allocate srq id\n");
1755 return rc;
1756 }
1757
1758 elem_type = QED_ELEM_SRQ;
1759 rc = qed_cxt_dynamic_ilt_alloc(p_hwfn, elem_type, returned_id);
1760 if (rc)
1761 goto err;
1762 /* returned id is no greater than u16 */
1763 srq_id = (u16)returned_id;
1764 opaque_fid = p_hwfn->hw_info.opaque_fid;
1765
1766 memset(&init_data, 0, sizeof(init_data));
1767 opaque_fid = p_hwfn->hw_info.opaque_fid;
1768 init_data.opaque_fid = opaque_fid;
1769 init_data.comp_mode = QED_SPQ_MODE_EBLOCK;
1770
1771 rc = qed_sp_init_request(p_hwfn, &p_ent,
1772 RDMA_RAMROD_CREATE_SRQ,
1773 p_hwfn->p_rdma_info->proto, &init_data);
1774 if (rc)
1775 goto err;
1776
1777 p_ramrod = &p_ent->ramrod.rdma_create_srq;
1778 DMA_REGPAIR_LE(p_ramrod->pbl_base_addr, in_params->pbl_base_addr);
1779 p_ramrod->pages_in_srq_pbl = cpu_to_le16(in_params->num_pages);
1780 p_ramrod->pd_id = cpu_to_le16(in_params->pd_id);
1781 p_ramrod->srq_id.srq_idx = cpu_to_le16(srq_id);
1782 p_ramrod->srq_id.opaque_fid = cpu_to_le16(opaque_fid);
1783 p_ramrod->page_size = cpu_to_le16(in_params->page_size);
1784 DMA_REGPAIR_LE(p_ramrod->producers_addr, in_params->prod_pair_addr);
1785
1786 rc = qed_spq_post(p_hwfn, p_ent, NULL);
1787 if (rc)
1788 goto err;
1789
1790 out_params->srq_id = srq_id;
1791
1792 DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
1793 "SRQ created Id = %x\n", out_params->srq_id);
1794
1795 return rc;
1796
1797 err:
1798 spin_lock_bh(&p_hwfn->p_rdma_info->lock);
1799 qed_bmap_release_id(p_hwfn, bmap, returned_id);
1800 spin_unlock_bh(&p_hwfn->p_rdma_info->lock);
1801
1802 return rc;
1803 }
1804
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] qed: qed_rdma_modify_srq() can be static
From: kbuild test robot @ 2018-06-01 3:41 UTC (permalink / raw)
To: Yuval Bason
Cc: kbuild-all, yuval.bason, davem, netdev, jgg, dledford, linux-rdma,
Michal Kalderon, Ariel Elior
In-Reply-To: <20180530131137.4653-1-yuval.bason@cavium.com>
Fixes: 27c50d39911b ("qed: Add srq core support for RoCE and iWARP")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
qed_rdma.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index bd23659..f118328 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -1652,8 +1652,8 @@ static void *qed_rdma_get_rdma_ctx(struct qed_dev *cdev)
return QED_LEADING_HWFN(cdev);
}
-int qed_rdma_modify_srq(void *rdma_cxt,
- struct qed_rdma_modify_srq_in_params *in_params)
+static int qed_rdma_modify_srq(void *rdma_cxt,
+ struct qed_rdma_modify_srq_in_params *in_params)
{
struct rdma_srq_modify_ramrod_data *p_ramrod;
struct qed_hwfn *p_hwfn = rdma_cxt;
@@ -1688,8 +1688,8 @@ int qed_rdma_modify_srq(void *rdma_cxt,
return rc;
}
-int qed_rdma_destroy_srq(void *rdma_cxt,
- struct qed_rdma_destroy_srq_in_params *in_params)
+static int qed_rdma_destroy_srq(void *rdma_cxt,
+ struct qed_rdma_destroy_srq_in_params *in_params)
{
struct rdma_srq_destroy_ramrod_data *p_ramrod;
struct qed_hwfn *p_hwfn = rdma_cxt;
@@ -1731,9 +1731,9 @@ int qed_rdma_destroy_srq(void *rdma_cxt,
return rc;
}
-int qed_rdma_create_srq(void *rdma_cxt,
- struct qed_rdma_create_srq_in_params *in_params,
- struct qed_rdma_create_srq_out_params *out_params)
+static int qed_rdma_create_srq(void *rdma_cxt,
+ struct qed_rdma_create_srq_in_params *in_params,
+ struct qed_rdma_create_srq_out_params *out_params)
{
struct rdma_srq_create_ramrod_data *p_ramrod;
struct qed_hwfn *p_hwfn = rdma_cxt;
^ permalink raw reply related
* Re: [PATCH bpf 1/2] bpf: fix alignment of netns_dev/netns_ino fields in bpf_{map,prog}_info
From: Dmitry V. Levin @ 2018-06-01 3:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eugene Syromiatnikov, netdev, linux-kernel, Martin KaFai Lau,
Daniel Borkmann, Alexei Starovoitov, David S. Miller, Jiri Olsa,
Ingo Molnar, Lawrence Brakmo, Andrey Ignatov, Jakub Kicinski,
John Fastabend
In-Reply-To: <20180530181857.GA6744@altlinux.org>
[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]
Hi,
Looks like the ABI bug in bpf_map_info and bpf_prog info introduced
in 4.16 is going to slip into 4.17, causing extra pain to 32-bit
userspace. I'm adding Linus to this thread in hope it might help
to get a fix applied before 4.17 is released.
On Wed, May 30, 2018 at 09:18:58PM +0300, Dmitry V. Levin wrote:
> On Sun, May 27, 2018 at 01:28:42PM +0200, Eugene Syromiatnikov wrote:
> > Recent introduction of netns_dev/netns_ino to bpf_map_info/bpf_prog info
> > has broken compat, as offsets of these fields are different in 32-bit
> > and 64-bit ABIs. One fix (other than implementing compat support in
> > syscall in order to handle this discrepancy) is to use __aligned_u64
> > instead of __u64 for these fields.
> >
> > Reported-by: Dmitry V. Levin <ldv@altlinux.org>
> > Fixes: 52775b33bb507 ("bpf: offload: report device information about
> > offloaded maps")
> > Fixes: 675fc275a3a2d ("bpf: offload: report device information for
> > offloaded programs")
> >
> > Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
>
> Reviewed-by: "Dmitry V. Levin" <ldv@altlinux.org>
> Cc: <stable@vger.kernel.org> # v4.16+
>
> Thanks,
>
> > ---
> > include/uapi/linux/bpf.h | 8 ++++----
> > tools/include/uapi/linux/bpf.h | 8 ++++----
> > 2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index c5ec897..903010a 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -1017,8 +1017,8 @@ struct bpf_prog_info {
> > __aligned_u64 map_ids;
> > char name[BPF_OBJ_NAME_LEN];
> > __u32 ifindex;
> > - __u64 netns_dev;
> > - __u64 netns_ino;
> > + __aligned_u64 netns_dev;
> > + __aligned_u64 netns_ino;
> > } __attribute__((aligned(8)));
> >
> > struct bpf_map_info {
> > @@ -1030,8 +1030,8 @@ struct bpf_map_info {
> > __u32 map_flags;
> > char name[BPF_OBJ_NAME_LEN];
> > __u32 ifindex;
> > - __u64 netns_dev;
> > - __u64 netns_ino;
> > + __aligned_u64 netns_dev;
> > + __aligned_u64 netns_ino;
> > } __attribute__((aligned(8)));
> >
> > /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
> > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> > index c5ec897..903010a 100644
> > --- a/tools/include/uapi/linux/bpf.h
> > +++ b/tools/include/uapi/linux/bpf.h
> > @@ -1017,8 +1017,8 @@ struct bpf_prog_info {
> > __aligned_u64 map_ids;
> > char name[BPF_OBJ_NAME_LEN];
> > __u32 ifindex;
> > - __u64 netns_dev;
> > - __u64 netns_ino;
> > + __aligned_u64 netns_dev;
> > + __aligned_u64 netns_ino;
> > } __attribute__((aligned(8)));
> >
> > struct bpf_map_info {
> > @@ -1030,8 +1030,8 @@ struct bpf_map_info {
> > __u32 map_flags;
> > char name[BPF_OBJ_NAME_LEN];
> > __u32 ifindex;
> > - __u64 netns_dev;
> > - __u64 netns_ino;
> > + __aligned_u64 netns_dev;
> > + __aligned_u64 netns_ino;
> > } __attribute__((aligned(8)));
> >
> > /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [net PATCH] net-sysfs: Fix memory leak in XPS configuration
From: David Miller @ 2018-06-01 3:03 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20180531195922.7571.86674.stgit@ahduyck-green-test.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Thu, 31 May 2018 15:59:46 -0400
> This patch reorders the error cases in showing the XPS configuration so
> that we hold off on memory allocation until after we have verified that we
> can support XPS on a given ring.
>
> Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 net] ixgbe: fix parsing of TC actions for HW offload
From: David Miller @ 2018-06-01 3:01 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: ohlavaty, netdev, andrewx.bowers
In-Reply-To: <b67b75aeb43afd4812e378673151a629f1681eea.camel@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 31 May 2018 14:46:08 -0700
> On Thu, 2018-05-31 at 23:21 +0200, Ondřej Hlavatý wrote:
>> The previous code was optimistic, accepting the offload of whole
>> action
>> chain when there was a single known action (drop/redirect). This
>> results
>> in offloading a rule which should not be offloaded, because its
>> behavior
>> cannot be reproduced in the hardware.
>>
>> For example:
>>
>> $ tc filter add dev eno1 parent ffff: protocol ip \
>> u32 ht 800: order 1 match tcp src 42 FFFF \
>> action mirred egress mirror dev enp1s16 pipe \
>> drop
>>
>> The controller is unable to mirror the packet to a VF, but still
>> offloads the rule by dropping the packet.
>>
>> Change the approach of the function to a pessimistic one, rejecting
>> the
>> chain when an unknown action is found. This is better suited for
>> future
>> extensions.
>>
>> Note that both recognized actions always return TC_ACT_SHOT,
>> therefore
>> it is safe to ignore actions behind them.
>>
>> Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Note- I am having our validation move to testing with GCC 8.1.1 or
> later so that we can catch warnings like Dave found in the future.
>
> Dave- Please go ahead and pick this up.
Ok, applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: fix error return code in virtnet_probe()
From: David Miller @ 2018-06-01 2:50 UTC (permalink / raw)
To: weiyongjun1
Cc: mst, jasowang, sridhar.samudrala, virtualization, netdev,
kernel-janitors
In-Reply-To: <1527732307-145609-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Thu, 31 May 2018 02:05:07 +0000
> Fix to return a negative error code from the failover create fail error
> handling case instead of 0, as done elsewhere in this function.
>
> Fixes: ba5e4426e80e ("virtio_net: Extend virtio to use VF datapath when available")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] rtnetlink: Remove VLA usage
From: David Miller @ 2018-06-01 2:49 UTC (permalink / raw)
To: keescook; +Cc: fw, dsahern, netdev, linux-kernel
In-Reply-To: <20180530222052.GA30622@beast>
From: Kees Cook <keescook@chromium.org>
Date: Wed, 30 May 2018 15:20:52 -0700
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the maximum size expected for all possible types and adds
> sanity-checks at both registration and usage to make sure nothing gets
> out of sync. This matches the proposed VLA solution for nfnetlink[2]. The
> values chosen here were based on finding assignments for .maxtype and
> .slave_maxtype and manually counting the enums:
>
> slave_maxtype (max 33):
...
> maxtype (max 45):
...
>
> This additionally changes maxtype and slave_maxtype fields to unsigned,
> since they're only ever using positive values.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
> [2] https://patchwork.kernel.org/patch/10439647/
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Looks good, applied, thanks.
^ permalink raw reply
* [PATCH] net: wireless: brcmsmac: Remove unnecessary parentheses
From: Varsha Rao @ 2018-06-01 2:14 UTC (permalink / raw)
To: Nicholas Mc Guire, Lukas Bulwahn, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, Kalle Valo,
David S. Miller, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, linux-kernel
Cc: Varsha Rao
This patch fixes the clang warning of extraneous parentheses, with the
following coccinelle script.
@@
identifier i;
expression e;
statement s;
@@
if (
-(i == e)
+i == e
)
s
Suggested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
index 3a13d176b221..35e3b101e5cf 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -159,7 +159,7 @@ u16 read_radio_reg(struct brcms_phy *pi, u16 addr)
{
u16 data;
- if ((addr == RADIO_IDCODE))
+ if (addr == RADIO_IDCODE)
return 0xffff;
switch (pi->pubpi.phy_type) {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
From: Qing Huang @ 2018-06-01 2:04 UTC (permalink / raw)
To: Michal Hocko, Eric Dumazet
Cc: David Miller, tariqt, haakon.bugge, yanjun.zhu, netdev,
linux-rdma, linux-kernel, gi-oh.kim, santosh.shilimkar@oracle.com
In-Reply-To: <20180531091022.GL15278@dhcp22.suse.cz>
On 5/31/2018 2:10 AM, Michal Hocko wrote:
> On Thu 31-05-18 10:55:32, Michal Hocko wrote:
>> On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
> [...]
>>> I merely copied/pasted from alloc_skb_with_frags() :/
>> I will have a look at it. Thanks!
> OK, so this is an example of an incremental development ;).
>
> __GFP_NORETRY was added by ed98df3361f0 ("net: use __GFP_NORETRY for
> high order allocations") to prevent from OOM killer. Yet this was
> not enough because fb05e7a89f50 ("net: don't wait for order-3 page
> allocation") didn't want an excessive reclaim for non-costly orders
> so it made it completely NOWAIT while it preserved __GFP_NORETRY in
> place which is now redundant. Should I send a patch?
>
Just curious, how about GFP_ATOMIC flag? Would it work in a similar
fashion? We experimented
with it a bit in the past but it seemed to cause other issue in our
tests. :-)
By the way, we didn't encounter any OOM killer events. It seemed that
the mlx4_alloc_icm() triggered slowpath.
We still had about 2GB free memory while it was highly fragmented.
#0 [ffff8801f308b380] remove_migration_pte at ffffffff811f0e0b
#1 [ffff8801f308b3e0] rmap_walk_file at ffffffff811cb890
#2 [ffff8801f308b440] rmap_walk at ffffffff811cbaf2
#3 [ffff8801f308b450] remove_migration_ptes at ffffffff811f0db0
#4 [ffff8801f308b490] __unmap_and_move at ffffffff811f2ea6
#5 [ffff8801f308b4e0] unmap_and_move at ffffffff811f2fc5
#6 [ffff8801f308b540] migrate_pages at ffffffff811f3219
#7 [ffff8801f308b5c0] compact_zone at ffffffff811b707e
#8 [ffff8801f308b650] compact_zone_order at ffffffff811b735d
#9 [ffff8801f308b6e0] try_to_compact_pages at ffffffff811b7485
#10 [ffff8801f308b770] __alloc_pages_direct_compact at ffffffff81195f96
#11 [ffff8801f308b7b0] __alloc_pages_slowpath at ffffffff811978a1
#12 [ffff8801f308b890] __alloc_pages_nodemask at ffffffff81197ec1
#13 [ffff8801f308b970] alloc_pages_current at ffffffff811e261f
#14 [ffff8801f308b9e0] mlx4_alloc_icm at ffffffffa01f39b2 [mlx4_core]
Thanks!
^ permalink raw reply
* [PATCH] net: ethernet: mlx4: Remove unnecessary parentheses
From: Varsha Rao @ 2018-06-01 2:00 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller, Nicholas Mc Guire, Lukas Bulwahn,
netdev, linux-rdma, linux-kernel
Cc: Varsha Rao
This patch fixes the clang warning of extraneous parentheses, with the
following coccinelle script.
@@
identifier i;
expression e;
statement s;
@@
if (
-(i == e)
+i == e
)
s
Suggested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/ethernet/mellanox/mlx4/port.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/port.c b/drivers/net/ethernet/mellanox/mlx4/port.c
index 3ef3406ff4cb..10fcc22f4590 100644
--- a/drivers/net/ethernet/mellanox/mlx4/port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/port.c
@@ -614,9 +614,9 @@ int __mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan,
int index_at_dup_port = -1;
for (i = MLX4_VLAN_REGULAR; i < MLX4_MAX_VLAN_NUM; i++) {
- if ((vlan == (MLX4_VLAN_MASK & be32_to_cpu(table->entries[i]))))
+ if (vlan == (MLX4_VLAN_MASK & be32_to_cpu(table->entries[i])))
index_at_port = i;
- if ((vlan == (MLX4_VLAN_MASK & be32_to_cpu(dup_table->entries[i]))))
+ if (vlan == (MLX4_VLAN_MASK & be32_to_cpu(dup_table->entries[i])))
index_at_dup_port = i;
}
/* check that same vlan is not in the tables at different indices */
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 net] mlx4_core: restore optimal ICM memory allocation
From: Qing Huang @ 2018-06-01 1:51 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Eric Dumazet, John Sperbeck, Tarick Bedeir,
Daniel Jurgens, Zhu Yanjun
In-Reply-To: <20180531125224.97098-1-edumazet@google.com>
On 5/31/2018 5:52 AM, Eric Dumazet wrote:
> Commit 1383cb8103bb ("mlx4_core: allocate ICM memory in page size chunks")
> brought two regressions caught in our regression suite.
>
> The big one is an additional cost of 256 bytes of overhead per 4096 bytes,
> or 6.25 % which is unacceptable since ICM can be pretty large.
>
> This comes from having to allocate one struct mlx4_icm_chunk (256 bytes)
> per MLX4_TABLE_CHUNK, which the buggy commit shrank to 4KB
> (instead of prior 256KB)
It would be great if you could share the test case that triggered the
KASAN report in your
environment. Our QA has been running intensive tests using 8KB or 4KB
chunk size configuration
for some time, no one has reported memory corruption issues so far,
given that we are not
running the latest upstream kernel.
IMO, it's worthwhile to find out the root cause and fix the problem.
>
> Note that mlx4_alloc_icm() is already able to try high order allocations
> and fallback to low-order allocations under high memory pressure.
>
> Most of these allocations happen right after boot time, when we get
> plenty of non fragmented memory, there is really no point being so
> pessimistic and break huge pages into order-0 ones just for fun.
>
> We only have to tweak gfp_mask a bit, to help falling back faster,
> without risking OOM killings.
Just FYI, out of memory wasn't our original concern. We didn't encounter
OOM killings.
>
> Second regression is an KASAN fault, that will need further investigations.
>
> Fixes: 1383cb8103bb ("mlx4_core: allocate ICM memory in page size chunks")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Tariq Toukan <tariqt@mellanox.com>
> Cc: John Sperbeck <jsperbeck@google.com>
> Cc: Tarick Bedeir <tarick@google.com>
> Cc: Qing Huang <qing.huang@oracle.com>
> Cc: Daniel Jurgens <danielj@mellanox.com>
> Cc: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/icm.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 685337d58276fc91baeeb64387c52985e1bc6dda..5342bd8a3d0bfaa9e76bb9b6943790606c97b181 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -43,12 +43,13 @@
> #include "fw.h"
>
> /*
> - * We allocate in page size (default 4KB on many archs) chunks to avoid high
> - * order memory allocations in fragmented/high usage memory situation.
> + * We allocate in as big chunks as we can, up to a maximum of 256 KB
> + * per chunk. Note that the chunks are not necessarily in contiguous
> + * physical memory.
> */
> enum {
> - MLX4_ICM_ALLOC_SIZE = PAGE_SIZE,
> - MLX4_TABLE_CHUNK_SIZE = PAGE_SIZE,
> + MLX4_ICM_ALLOC_SIZE = 1 << 18,
> + MLX4_TABLE_CHUNK_SIZE = 1 << 18,
> };
>
> static void mlx4_free_icm_pages(struct mlx4_dev *dev, struct mlx4_icm_chunk *chunk)
> @@ -135,6 +136,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
> struct mlx4_icm *icm;
> struct mlx4_icm_chunk *chunk = NULL;
> int cur_order;
> + gfp_t mask;
> int ret;
>
> /* We use sg_set_buf for coherent allocs, which assumes low memory */
> @@ -178,13 +180,17 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
> while (1 << cur_order > npages)
> --cur_order;
>
> + mask = gfp_mask;
> + if (cur_order)
> + mask &= ~__GFP_DIRECT_RECLAIM;
> +
> if (coherent)
> ret = mlx4_alloc_icm_coherent(&dev->persist->pdev->dev,
> &chunk->mem[chunk->npages],
> - cur_order, gfp_mask);
> + cur_order, mask);
> else
> ret = mlx4_alloc_icm_pages(&chunk->mem[chunk->npages],
> - cur_order, gfp_mask,
> + cur_order, mask,
> dev->numa_node);
>
> if (ret) {
^ permalink raw reply
* [PATCH net-next v2 2/2] qed: Fix use of incorrect shmem address.
From: Sudarsana Reddy Kalluru @ 2018-06-01 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Michal.Kalderon
In-Reply-To: <20180601014737.6164-1-sudarsana.kalluru@cavium.com>
Incorrect shared memory address is used while deriving the values
for tc and pri_type. Use shmem address corresponding to 'oem_cfg_func'
where the management firmare saves tc/pri_type values.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 2612e3e..6f9927d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1514,9 +1514,10 @@ void qed_mcp_read_ufp_config(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
}
qed_mcp_get_shmem_func(p_hwfn, p_ptt, &shmem_info, MCP_PF_ID(p_hwfn));
- val = (port_cfg & OEM_CFG_FUNC_TC_MASK) >> OEM_CFG_FUNC_TC_OFFSET;
+ val = (shmem_info.oem_cfg_func & OEM_CFG_FUNC_TC_MASK) >>
+ OEM_CFG_FUNC_TC_OFFSET;
p_hwfn->ufp_info.tc = (u8)val;
- val = (port_cfg & OEM_CFG_FUNC_HOST_PRI_CTRL_MASK) >>
+ val = (shmem_info.oem_cfg_func & OEM_CFG_FUNC_HOST_PRI_CTRL_MASK) >>
OEM_CFG_FUNC_HOST_PRI_CTRL_OFFSET;
if (val == OEM_CFG_FUNC_HOST_PRI_CTRL_VNIC) {
p_hwfn->ufp_info.pri_type = QED_UFP_PRI_VNIC;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] qed: Fix shared memory inconsistency between driver and the MFW.
From: Sudarsana Reddy Kalluru @ 2018-06-01 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Michal.Kalderon
In-Reply-To: <20180601014737.6164-1-sudarsana.kalluru@cavium.com>
The structure shared between driver and management firmware (MFW)
differ in sizes. The additional field defined by the MFW is not
relevant to the current driver. Add a dummy field to the structure.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 8e1e6e1..beba930 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -11996,6 +11996,7 @@ struct public_port {
#define EEE_REMOTE_TW_RX_MASK 0xffff0000
#define EEE_REMOTE_TW_RX_OFFSET 16
+ u32 reserved1;
u32 oem_cfg_port;
#define OEM_CFG_CHANNEL_TYPE_MASK 0x00000003
#define OEM_CFG_CHANNEL_TYPE_OFFSET 0
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v2 0/2] qed: Fix issues in UFP feature commit 'cac6f691'.
From: Sudarsana Reddy Kalluru @ 2018-06-01 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Michal.Kalderon, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
This patch series fixes couple of issues in the UFP feature commit,
cac6f691: Add support for Unified Fabric Port.
Changes from previous version:
------------------------------
v2: Added "Fixes:" tag.
Please consider applying it to "net-next".
Sudarsana Reddy Kalluru (2):
qed: Fix shared memory inconsistency between driver and the MFW.
qed: Fix use of incorrect shmem address.
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH net-next] net: phy: consider PHY_IGNORE_INTERRUPT in state machine PHY_NOLINK handling
From: David Miller @ 2018-06-01 1:26 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <0a4e472d-cb7f-ef1f-420c-1327fa41e8cd@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 30 May 2018 22:13:20 +0200
> We can bail out immediately also in case of PHY_IGNORE_INTERRUPT because
> phy_mac_interupt() informs us once the link is up.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
When state is PHY_NOLINK, the phy_mac_interrupt() code paths
will change the state to PHY_CHANGELINK before queueing up
the state machine invocation.
So I can't even see how we can enter phy_state_machine with
->state == PHY_NOLINK is the mac interrupt paths are being
used properly.
Therefore it looks like the code as written is harmless.
Did you actually hit a problem with this test or is this
a change based purely upon code inspection?
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: prevent non-IPv4 socket to be added into sock hash
From: Eric Dumazet @ 2018-06-01 1:00 UTC (permalink / raw)
To: John Fastabend; +Cc: Wei Wang, netdev, Willem de Bruijn
In-Reply-To: <c6aae1fa-3ad1-9192-3e99-e177b1098f06@gmail.com>
On Thu, May 31, 2018 at 7:32 PM John Fastabend <john.fastabend@gmail.com> wrote:
>
>
> Hi Wei,
>
> Thanks for the report and fix. It would be better to fix the
> root cause so that IPv6 works as intended.
>
> I'm testing the following now,
>
> Author: John Fastabend <john.fastabend@gmail.com>
> Date: Thu May 31 14:38:59 2018 -0700
>
> sockmap: fix crash when ipv6 sock is added by adding support for IPv6
>
> Apparently we had a testing escape and missed IPv6. This fixes a crash
> where we assign tcp_prot to IPv6 sockets instead of tcpv6_prot.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>
Hi John
In any case, please forward correct attribution for Wei's work, and
syzbot 'Reported-by'
Are you sure you are handling IPv4 mapped in IPv6 sockets as well ?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/ncsi: Avoid GFP_KERNEL in response handler
From: Samuel Mendoza-Jonas @ 2018-06-01 0:33 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: David S . Miller, linux-kernel, openbmc
In-Reply-To: <69fcb143-00a2-2ddf-e2d4-c692b650f292@gmail.com>
On Thu, 2018-05-31 at 04:50 -0400, Eric Dumazet wrote:
>
> On 05/31/2018 03:02 AM, Samuel Mendoza-Jonas wrote:
> > ncsi_rsp_handler_gc() allocates the filter arrays using GFP_KERNEL in
> > softirq context, causing the below backtrace. This allocation is only a
> > few dozen bytes during probing so allocate with GFP_ATOMIC instead.
> >
>
> Hi Samuel
>
> You forgot to add
>
> Fixes: 062b3e1b6d4f ("net/ncsi: Refactor MAC, VLAN filters")
>
> size = (rsp->uc_cnt + rsp->mc_cnt + rsp->mixed_cnt) * ETH_ALEN;
>
> -> seems to be able to reach more than few dozen bytes...
Hi Eric,
The NCSI spec (at least in the v1.1.0 version I'm looking at) sets the
total number of MAC address filters at 8, so we would be looking at a
maximum of 8 * ETH_ALEN = 48 bytes.
That said it shouldn't be too arduous to move the allocation to later in
the probe/configure cycle so if needed we could do that.
>
> Also, what prevents ncsi_rsp_handler_gc() to be called multiples times ?
>
> nc->mac_filter.addrs & nc->vlan_filter.vids would be re-allocated and memory would leak.
>
Good point, we should put a check there just in case to see if it's
allocated. We should be safe though as ncsi_rsp_handler_gc() should only
be called via ncsi_probe_channel() which only happens through
ncsi_start_dev(), and addrs/vids is cleaned up in ncsi_remove_channel().
Rogue packets shouldn't hit the ncsi_rsp_handler_gc() handler without an
outstanding request.. but it probably is safer to check regardless.
Regards,
Sam
^ permalink raw reply
* Re: [PATCH bpf-next] xsk: temporarily disable AF_XDP
From: Björn Töpel @ 2018-06-01 0:24 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Netdev
Cc: Björn Töpel, Karlsson, Magnus, Magnus Karlsson
In-Reply-To: <20180531001754.15923-1-bjorn.topel@gmail.com>
Den ons 30 maj 2018 kl 17:22 skrev Björn Töpel <bjorn.topel@gmail.com>:
>
> From: Björn Töpel <bjorn.topel@intel.com>
>
> Temporarily disable AF_XDP sockets, and hide uapi.
>
[...]
Alexei/Daniel,
Ignore this patch, please.
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: phy: improve PHY suspend/resume
From: Andrew Lunn @ 2018-06-01 0:10 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <f48b0978-7891-487b-d2b1-3f23b269578c@gmail.com>
> Configuring the different WoL options isn't handled by writing to
> the PHY registers but by writing to chip / MAC registers.
> Therefore phy_suspend() isn't able to figure out whether WoL is
> enabled or not. Only the parent has the full picture.
Hi Heiner
I think you need to look at your different runtime PM domains. If i
understand the code right, you runtime suspend if there is no
link. But for this to work correctly, your PHY needs to keep working.
You also cannot assume all accesses to the PHY go via the MAC. Some
calls will go direct to the PHY, and they can trigger MDIO bus
accesses. So i think you need two runtime PM domains. MAC and MDIO
bus. Maybe just the pll? An MDIO bus is a device, so it can have its
on PM callbacks. It is not clear what you need to resume in order to
make MDIO work.
It might also help if you do the phy_connect in .ndo_open and
disconnect in .ndo_stop. This is a common pattern in drivers. But some
also do it is probe and remove.
Andrew
^ permalink raw reply
* Re: suspicius csum initialization in vmxnet3_rx_csum
From: Neil Horman @ 2018-05-31 23:32 UTC (permalink / raw)
To: Ronak Doshi; +Cc: Paolo Abeni, Guolin Yang, Boon Ang, Louis Luo, netdev
In-Reply-To: <alpine.OSX.2.21.1805311048380.47071@doshir-m01.vmware.com>
On Thu, May 31, 2018 at 11:02:34AM -0700, Ronak Doshi wrote:
>
> On Wed, 30 May 2018, Paolo Abeni wrote:
>
> > Hi,
> >
> > On Thu, 2018-05-24 at 21:48 +0000, Guolin Yang wrote:
> > > Yes, that code is not correct, we should fix that code
> >
> > Did you have any chance to address the issue and/or to give a more in-
> > deepth look to the change proposed in my initial email?
> >
> Hi Paolo,
>
> Can you provide the esx build you are using? It can be found using
> "vmware -vl" on ESX host.
>
> Did you try your proposed fix and did it work? Are you sure the packet
> hits the below if block and not the else block? I still don't think the
> ICMP packet will go through the below if block.
>
> if (gdesc->rcd.csum) {
> skb->csum = htons(gdesc->rcd.csum);
> skb->ip_summed = CHECKSUM_PARTIAL;
> } else {
> skb_checksum_none_assert(skb);
> }
>
> The vmxnet3 emulation does not calculate rcd.csum for ICMP packet and
> hence should go through the else block i.e. checksum none.
>
What packet types will rcd.csum be set for?
Neil
> Thanks,
> Ronak
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: prevent non-IPv4 socket to be added into sock hash
From: John Fastabend @ 2018-05-31 23:31 UTC (permalink / raw)
To: Wei Wang, netdev; +Cc: Eric Dumazet, Willem de Bruijn
In-Reply-To: <20180530212928.190650-1-tracywwnj@gmail.com>
On 05/30/2018 02:29 PM, Wei Wang wrote:
> From: Wei Wang <weiwan@google.com>
>
> Sock hash only supports IPv4 socket proto right now.
> If a non-IPv4 socket gets stored in the BPF map, sk->sk_prot gets
> overwritten with the v4 tcp prot.
>
> Syskaller reported the following related issue on an IPv6 socket:
> BUG: KASAN: slab-out-of-bounds in ip6_dst_idev include/net/ip6_fib.h:203 [inline]
> BUG: KASAN: slab-out-of-bounds in ip6_xmit+0x2002/0x23f0 net/ipv6/ip6_output.c:264
> Read of size 8 at addr ffff8801b300edb0 by task syz-executor888/4522
>
> CPU: 0 PID: 4522 Comm: syz-executor888 Not tainted 4.17.0-rc4+ #17
> 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
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> ip6_dst_idev include/net/ip6_fib.h:203 [inline]
> ip6_xmit+0x2002/0x23f0 net/ipv6/ip6_output.c:264
> inet6_csk_xmit+0x377/0x630 net/ipv6/inet6_connection_sock.c:139
> tcp_transmit_skb+0x1be0/0x3e40 net/ipv4/tcp_output.c:1159
> tcp_send_syn_data net/ipv4/tcp_output.c:3441 [inline]
> tcp_connect+0x2207/0x45a0 net/ipv4/tcp_output.c:3480
> tcp_v4_connect+0x1934/0x1d50 net/ipv4/tcp_ipv4.c:272
> __inet_stream_connect+0x943/0x1120 net/ipv4/af_inet.c:655
> tcp_sendmsg_fastopen net/ipv4/tcp.c:1162 [inline]
> tcp_sendmsg_locked+0x2859/0x3ee0 net/ipv4/tcp.c:1209
> tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1447
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> ___sys_sendmsg+0x805/0x940 net/socket.c:2117
> __sys_sendmsg+0x115/0x270 net/socket.c:2155
> __do_sys_sendmsg net/socket.c:2164 [inline]
> __se_sys_sendmsg net/socket.c:2162 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43ff99
> RSP: 002b:00007ffc00bd1cf8 EFLAGS: 00000217 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043ff99
> RDX: 0000000020000000 RSI: 0000000020000580 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 00000000004002c8 R11: 0000000000000217 R12: 00000000004018c0
> R13: 0000000000401950 R14: 0000000000000000 R15: 0000000000000000
>
> Fixes: 81110384441a ("bpf: sockmap, add hash map support")
> Reported-by: syzbot+5c063698bdbfac19f363@syzkaller.appspotmail.com
> Signed-off-by: Wei Wang <weiwan@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Willem de Bruijn <willemb@google.com>
> ---
Hi Wei,
Thanks for the report and fix. It would be better to fix the
root cause so that IPv6 works as intended.
I'm testing the following now,
Author: John Fastabend <john.fastabend@gmail.com>
Date: Thu May 31 14:38:59 2018 -0700
sockmap: fix crash when ipv6 sock is added by adding support for IPv6
Apparently we had a testing escape and missed IPv6. This fixes a crash
where we assign tcp_prot to IPv6 sockets instead of tcpv6_prot.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 52a91d8..e191122 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -41,6 +41,7 @@
#include <linux/mm.h>
#include <net/strparser.h>
#include <net/tcp.h>
+#include <net/transp_v6.h>
#include <linux/ptr_ring.h>
#include <net/inet_common.h>
#include <linux/sched/signal.h>
@@ -162,6 +163,8 @@ static bool bpf_tcp_stream_read(const struct sock *sk)
}
static struct proto tcp_bpf_proto;
+static struct proto tcpv6_bpf_proto;
+
static int bpf_tcp_init(struct sock *sk)
{
struct smap_psock *psock;
@@ -182,13 +185,21 @@ static int bpf_tcp_init(struct sock *sk)
psock->sk_proto = sk->sk_prot;
if (psock->bpf_tx_msg) {
+ tcpv6_bpf_proto.sendmsg = bpf_tcp_sendmsg;
+ tcpv6_bpf_proto.sendpage = bpf_tcp_sendpage;
+ tcpv6_bpf_proto.recvmsg = bpf_tcp_recvmsg;
+ tcpv6_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
tcp_bpf_proto.sendmsg = bpf_tcp_sendmsg;
tcp_bpf_proto.sendpage = bpf_tcp_sendpage;
tcp_bpf_proto.recvmsg = bpf_tcp_recvmsg;
tcp_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
}
- sk->sk_prot = &tcp_bpf_proto;
+ if (sk->sk_family == AF_INET6)
+ sk->sk_prot = &tcpv6_bpf_proto;
+ else
+ sk->sk_prot = &tcp_bpf_proto;
+
rcu_read_unlock();
return 0;
}
@@ -1113,6 +1124,8 @@ static int bpf_tcp_ulp_register(void)
{
tcp_bpf_proto = tcp_prot;
tcp_bpf_proto.close = bpf_tcp_close;
+ tcpv6_bpf_proto = tcpv6_prot;
+ tcpv6_bpf_proto.close = bpf_tcp_close;
/* Once BPF TX ULP is registered it is never unregistered. It
* will be in the ULP list for the lifetime of the system. Doing
* duplicate registers is not a problem.
^ permalink raw reply related
* [PATCH net-next 2/2] selftests: forwarding: mirror_vlan: Change test description
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah, idosch
In-Reply-To: <cover.1527805500.git.petrm@mellanox.com>
The test description is displayed with the PASS/FAIL resolution after
the test is ran. There however already is one other test described
exactly like this, which makes it unclear which of the tests passed or
failed. Make the description unique.
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
tools/testing/selftests/net/forwarding/mirror_vlan.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/mirror_vlan.sh b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
index c22e949..efade19 100755
--- a/tools/testing/selftests/net/forwarding/mirror_vlan.sh
+++ b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
@@ -129,7 +129,7 @@ test_tagged_vlan_dir()
192.0.2.17 192.0.2.18
mirror_uninstall $swp1 $direction
- log_test "$direction mirror to vlan ($tcflags)"
+ log_test "$direction mirror tagged to vlan ($tcflags)"
}
test_tagged_vlan()
--
2.4.11
^ permalink raw reply related
* [PATCH net-next 1/2] selftests: forwarding: mirror_vlan: Uninstall trap
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah, idosch
In-Reply-To: <cover.1527805500.git.petrm@mellanox.com>
Instead of installing a trap before tests run and uninstalling it after
they run, mirror_vlan.sh installs it twice due to a typo. Fix the typo.
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
tools/testing/selftests/net/forwarding/mirror_vlan.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/mirror_vlan.sh b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
index 1e10520..c22e949 100755
--- a/tools/testing/selftests/net/forwarding/mirror_vlan.sh
+++ b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
@@ -146,7 +146,7 @@ test_all()
tests_run
- trap_install $h3 ingress
+ trap_uninstall $h3 ingress
slow_path_trap_uninstall $swp1 egress
slow_path_trap_uninstall $swp1 ingress
}
--
2.4.11
^ permalink raw reply related
* [PATCH net-next 0/2] selftests: forwarding: mirror_vlan: Fixlets
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah, idosch
This patchset includes two small fixes for the tests that were
introduced in commit 1bb58d2d3cbe ("Merge branch
'Mirroring-tests-involving-VLAN'").
In patch #1, a "tc action trap" is uninstalled after the suite runs,
instead of being installed again.
In patch #2, a test in suite is renamed to differentiate it from another
test of the same name.
Petr Machata (2):
selftests: forwarding: mirror_vlan: Uninstall trap
selftests: forwarding: mirror_vlan: Change test description
tools/testing/selftests/net/forwarding/mirror_vlan.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.4.11
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox