* Re: [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e
From: Jiri Pirko @ 2017-10-11 20:38 UTC (permalink / raw)
To: Alexander Duyck
Cc: Amritha Nambiar, intel-wired-lan, Jeff Kirsher,
Duyck, Alexander H, Netdev, Jamal Hadi Salim, Cong Wang
In-Reply-To: <CAKgT0UcP8refj2KLMT258xPNS2h3KhLqKD5sJkNLXRdNJrRCVg@mail.gmail.com>
Wed, Oct 11, 2017 at 07:46:27PM CEST, alexander.duyck@gmail.com wrote:
>On Wed, Oct 11, 2017 at 5:56 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, Oct 11, 2017 at 02:24:12AM CEST, amritha.nambiar@intel.com wrote:
>>>This patch series enables configuring cloud filters in i40e
>>>using the tc-flower classifier. The classification function
>>>of the filter is to match a packet to a class. cls_flower is
>>>extended to offload classid to hardware. The offloaded classid
>>>is used direct matched packets to a traffic class on the device.
>>>The approach here is similar to the tc 'prio' qdisc which uses
>>>the classid for band selection. The ingress qdisc is called ffff:0,
>>>so traffic classes are ffff:1 to ffff:8 (i40e has max of 8 TCs).
>>
>>
>> NACK. This clearly looks like abuse of classid to something
>> else. Classid is here to identify qdisc instance. However, you use it
>> for hw tclass identification. This is mixing of apples and oranges.
>>
>> Why?
>>
>> Please don't try to abuse things! This is not nice.
>
>This isn't an abuse. This is reproducing in hardware what is already
>the behavior for software. Isn't that how offloads are supposed to
>work?
What is meaning of classid in HW? Classid is SW only identification of
qdisc instances. No relation to HW instances = abuse.
>
>This is exactly how prio currently handles this. We are essentially
>doing the exact same thing in the hardware where we are choosing a
>queueing group based on the class ID. You could setup a prio qdisc. If
>you are offloading a qdisc behavior into hardware how are you supposed
>to emulate the behavior if you aren't allowing the offload to use the
>same mechanism?
I believe that the correct way to solve is to introduce SETTCLASS
termination action (similar to TRAP, GOTO_CHAIN, etc), which would allow
user to instruct the destination tclass and driver can offload it.
^ permalink raw reply
* Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode
From: Eric Dumazet @ 2017-10-11 20:28 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, linux-arm-kernel, netdev, Catalin Marinas,
David S. Miller, Florian Westphal
In-Reply-To: <20171011194355.n6mb4oe7qt76d6wh@yury-thinkpad>
On Wed, 2017-10-11 at 22:43 +0300, Yury Norov wrote:
> The fix works for me, thanks.
>
> Tested-by: Yury Norov <ynorov@caviumnetworks.com>
Thanks Yury !
^ permalink raw reply
* [PATCH net-next] tcp: fix tcp_unlink_write_queue()
From: Eric Dumazet @ 2017-10-11 20:27 UTC (permalink / raw)
To: Yury Norov
Cc: netdev, Catalin Marinas, David S. Miller, Wei Wang, Neal Cardwell
In-Reply-To: <20171011194355.n6mb4oe7qt76d6wh@yury-thinkpad>
From: Eric Dumazet <edumazet@google.com>
Yury reported crash with this signature :
[ 554.034021] [<ffff80003ccd5a58>] 0xffff80003ccd5a58
[ 554.034156] [<ffff00000888fd34>] skb_release_all+0x14/0x30
[ 554.034288] [<ffff00000888fd64>] __kfree_skb+0x14/0x28
[ 554.034409] [<ffff0000088ece6c>] tcp_sendmsg_locked+0x4dc/0xcc8
[ 554.034541] [<ffff0000088ed68c>] tcp_sendmsg+0x34/0x58
[ 554.034659] [<ffff000008919fd4>] inet_sendmsg+0x2c/0xf8
[ 554.034783] [<ffff0000088842e8>] sock_sendmsg+0x18/0x30
[ 554.034928] [<ffff0000088861fc>] SyS_sendto+0x84/0xf8
Problem is that skb->destructor contains garbage, and this is
because I accidentally removed tcp_skb_tsorted_anchor_cleanup()
from tcp_unlink_write_queue()
This would trigger with a write(fd, <invalid_memory>, len) attempt,
and we will add to packetdrill this capability to avoid future
regressions.
Fixes: 75c119afe14f ("tcp: implement rb-tree based retransmit queue")
Reported-by: Yury Norov <ynorov@caviumnetworks.com>
Tested-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 5a95e5886b55e03e4a8bfeac3506c657a4f97dde..15163454174babdcb465904f725b919268dd1bc7 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1712,6 +1712,7 @@ static inline void tcp_insert_write_queue_before(struct sk_buff *new,
static inline void tcp_unlink_write_queue(struct sk_buff *skb, struct sock *sk)
{
+ tcp_skb_tsorted_anchor_cleanup(skb);
__skb_unlink(skb, &sk->sk_write_queue);
}
^ permalink raw reply related
* (unknown),
From: kindergartenchaos2 @ 2017-10-11 19:55 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 150646856.zip --]
[-- Type: application/zip, Size: 2805 bytes --]
^ permalink raw reply
* [PATCH 3/4] net: qcom/emac: enforce DMA address restrictions
From: Timur Tabi @ 2017-10-11 19:52 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: timur
In-Reply-To: <1507751546-10265-1-git-send-email-timur@codeaurora.org>
The EMAC has a restriction that the upper 32 bits of the base addresses
for the RFD and RRD rings must be the same. The ensure that restriction,
we allocate twice the space for the RRD and locate it at an appropriate
address.
We also re-arrange the allocations so that invalid addresses are even
less likely.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 39 ++++++++++++++++-----------
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 9cbb27263742..0f5ece5d9507 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -734,6 +734,11 @@ static int emac_rx_descs_alloc(struct emac_adapter *adpt)
rx_q->rrd.size = rx_q->rrd.count * (adpt->rrd_size * 4);
rx_q->rfd.size = rx_q->rfd.count * (adpt->rfd_size * 4);
+ /* Check if the RRD and RFD are aligned properly, and if not, adjust. */
+ if (upper_32_bits(ring_header->dma_addr) !=
+ upper_32_bits(ring_header->dma_addr + ALIGN(rx_q->rrd.size, 8)))
+ ring_header->used = ALIGN(rx_q->rrd.size, 8);
+
rx_q->rrd.dma_addr = ring_header->dma_addr + ring_header->used;
rx_q->rrd.v_addr = ring_header->v_addr + ring_header->used;
ring_header->used += ALIGN(rx_q->rrd.size, 8);
@@ -767,11 +772,18 @@ int emac_mac_rx_tx_rings_alloc_all(struct emac_adapter *adpt)
/* Ring DMA buffer. Each ring may need up to 8 bytes for alignment,
* hence the additional padding bytes are allocated.
+ *
+ * Also double the memory allocated for the RRD so that we can
+ * re-align it if necessary. The EMAC has a restriction that the
+ * upper 32 bits of the base addresses for the RFD and RRD rings
+ * must be the same. It is extremely unlikely that this is not the
+ * case, since the rings are only a few KB in size. However, we
+ * need to check for this anyway, and if the two rings are not
+ * compliant, then we re-align.
*/
- ring_header->size = num_tx_descs * (adpt->tpd_size * 4) +
- num_rx_descs * (adpt->rfd_size * 4) +
- num_rx_descs * (adpt->rrd_size * 4) +
- 8 + 2 * 8; /* 8 byte per one Tx and two Rx rings */
+ ring_header->size = ALIGN(num_tx_descs * (adpt->tpd_size * 4), 8) +
+ ALIGN(num_rx_descs * (adpt->rfd_size * 4), 8) +
+ ALIGN(num_rx_descs * (adpt->rrd_size * 4), 8) * 2;
ring_header->used = 0;
ring_header->v_addr = dma_zalloc_coherent(dev, ring_header->size,
@@ -780,26 +792,23 @@ int emac_mac_rx_tx_rings_alloc_all(struct emac_adapter *adpt)
if (!ring_header->v_addr)
return -ENOMEM;
- ring_header->used = ALIGN(ring_header->dma_addr, 8) -
- ring_header->dma_addr;
-
- ret = emac_tx_q_desc_alloc(adpt, &adpt->tx_q);
- if (ret) {
- netdev_err(adpt->netdev, "error: Tx Queue alloc failed\n");
- goto err_alloc_tx;
- }
-
ret = emac_rx_descs_alloc(adpt);
if (ret) {
netdev_err(adpt->netdev, "error: Rx Queue alloc failed\n");
goto err_alloc_rx;
}
+ ret = emac_tx_q_desc_alloc(adpt, &adpt->tx_q);
+ if (ret) {
+ netdev_err(adpt->netdev, "transmit queue allocation failed\n");
+ goto err_alloc_tx;
+ }
+
return 0;
-err_alloc_rx:
- emac_tx_q_bufs_free(adpt);
err_alloc_tx:
+ emac_rx_q_bufs_free(adpt);
+err_alloc_rx:
dma_free_coherent(dev, ring_header->size,
ring_header->v_addr, ring_header->dma_addr);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 4/4] net: qcom/emac: clean up some TX/RX error messages
From: Timur Tabi @ 2017-10-11 19:52 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: timur
In-Reply-To: <1507751546-10265-1-git-send-email-timur@codeaurora.org>
Some of the error messages that are printed by the interrupt handlers
are poorly written. For example, many don't include a device prefix,
so there's no indication that they are EMAC errors.
Also use rate limiting for all messages that could be printed from
interrupt context.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 15 ++++++---------
drivers/net/ethernet/qualcomm/emac/emac.c | 8 ++++----
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 29ba37a08372..e8ab512ee7e3 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -68,10 +68,10 @@ static void emac_sgmii_link_init(struct emac_adapter *adpt)
writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
}
-static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u32 irq_bits)
+static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits)
{
struct emac_sgmii *phy = &adpt->phy;
- u32 status;
+ u8 status;
writel_relaxed(irq_bits, phy->base + EMAC_SGMII_PHY_INTERRUPT_CLEAR);
writel_relaxed(IRQ_GLOBAL_CLEAR, phy->base + EMAC_SGMII_PHY_IRQ_CMD);
@@ -86,9 +86,8 @@ static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u32 irq_bits)
EMAC_SGMII_PHY_INTERRUPT_STATUS,
status, !(status & irq_bits), 1,
SGMII_PHY_IRQ_CLR_WAIT_TIME)) {
- netdev_err(adpt->netdev,
- "error: failed clear SGMII irq: status:0x%x bits:0x%x\n",
- status, irq_bits);
+ net_err_ratelimited("%s: failed to clear SGMII irq: status:0x%x bits:0x%x\n",
+ adpt->netdev->name, status, irq_bits);
return -EIO;
}
@@ -109,7 +108,7 @@ static irqreturn_t emac_sgmii_interrupt(int irq, void *data)
{
struct emac_adapter *adpt = data;
struct emac_sgmii *phy = &adpt->phy;
- u32 status;
+ u8 status;
status = readl(phy->base + EMAC_SGMII_PHY_INTERRUPT_STATUS);
status &= SGMII_ISR_MASK;
@@ -139,10 +138,8 @@ static irqreturn_t emac_sgmii_interrupt(int irq, void *data)
atomic_set(&phy->decode_error_count, 0);
}
- if (emac_sgmii_irq_clear(adpt, status)) {
- netdev_warn(adpt->netdev, "failed to clear SGMII interrupt\n");
+ if (emac_sgmii_irq_clear(adpt, status))
schedule_work(&adpt->work_thread);
- }
return IRQ_HANDLED;
}
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index ee6f2d27502c..70c92b649b29 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -148,9 +148,8 @@ static irqreturn_t emac_isr(int _irq, void *data)
goto exit;
if (status & ISR_ERROR) {
- netif_warn(adpt, intr, adpt->netdev,
- "warning: error irq status 0x%lx\n",
- status & ISR_ERROR);
+ net_err_ratelimited("%s: error interrupt 0x%lx\n",
+ adpt->netdev->name, status & ISR_ERROR);
/* reset MAC */
schedule_work(&adpt->work_thread);
}
@@ -169,7 +168,8 @@ static irqreturn_t emac_isr(int _irq, void *data)
emac_mac_tx_process(adpt, &adpt->tx_q);
if (status & ISR_OVER)
- net_warn_ratelimited("warning: TX/RX overflow\n");
+ net_warn_ratelimited("%s: TX/RX overflow interrupt\n",
+ adpt->netdev->name);
exit:
/* enable the interrupt */
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 2/4] net: qcom/emac: remove unused address arrays
From: Timur Tabi @ 2017-10-11 19:52 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: timur
In-Reply-To: <1507751546-10265-1-git-send-email-timur@codeaurora.org>
The EMAC is capable of multiple TX and RX rings, but the driver only
supports one ring for each. One function had some left-over unused
code that supports multiple rings, but all it did was make the code
harder to read.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 3ed9033e56db..9cbb27263742 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -309,22 +309,12 @@ void emac_mac_mode_config(struct emac_adapter *adpt)
/* Config descriptor rings */
static void emac_mac_dma_rings_config(struct emac_adapter *adpt)
{
- static const unsigned short tpd_q_offset[] = {
- EMAC_DESC_CTRL_8, EMAC_H1TPD_BASE_ADDR_LO,
- EMAC_H2TPD_BASE_ADDR_LO, EMAC_H3TPD_BASE_ADDR_LO};
- static const unsigned short rfd_q_offset[] = {
- EMAC_DESC_CTRL_2, EMAC_DESC_CTRL_10,
- EMAC_DESC_CTRL_12, EMAC_DESC_CTRL_13};
- static const unsigned short rrd_q_offset[] = {
- EMAC_DESC_CTRL_5, EMAC_DESC_CTRL_14,
- EMAC_DESC_CTRL_15, EMAC_DESC_CTRL_16};
-
/* TPD (Transmit Packet Descriptor) */
writel(upper_32_bits(adpt->tx_q.tpd.dma_addr),
adpt->base + EMAC_DESC_CTRL_1);
writel(lower_32_bits(adpt->tx_q.tpd.dma_addr),
- adpt->base + tpd_q_offset[0]);
+ adpt->base + EMAC_DESC_CTRL_8);
writel(adpt->tx_q.tpd.count & TPD_RING_SIZE_BMSK,
adpt->base + EMAC_DESC_CTRL_9);
@@ -334,9 +324,9 @@ static void emac_mac_dma_rings_config(struct emac_adapter *adpt)
adpt->base + EMAC_DESC_CTRL_0);
writel(lower_32_bits(adpt->rx_q.rfd.dma_addr),
- adpt->base + rfd_q_offset[0]);
+ adpt->base + EMAC_DESC_CTRL_2);
writel(lower_32_bits(adpt->rx_q.rrd.dma_addr),
- adpt->base + rrd_q_offset[0]);
+ adpt->base + EMAC_DESC_CTRL_5);
writel(adpt->rx_q.rfd.count & RFD_RING_SIZE_BMSK,
adpt->base + EMAC_DESC_CTRL_3);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 0/4] net: qcom/emac: various minor fixes
From: Timur Tabi @ 2017-10-11 19:52 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: timur
A set of patches for 4.15 that clean up some code, apply minors fixes,
and so on. Some of the code also prepares the driver for a future
version of the EMAC controller.
Timur Tabi (4):
net: qcom/emac: specify the correct DMA mask
net: qcom/emac: remove unused address arrays
net: qcom/emac: enforce DMA address restrictions
net: qcom/emac: clean up some TX/RX error messages
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 55 ++++++++++++-------------
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 15 +++----
drivers/net/ethernet/qualcomm/emac/emac.c | 25 ++++-------
3 files changed, 41 insertions(+), 54 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH] [net-next]NFC: Convert timers to use timer_setup()
From: Allen @ 2017-10-11 19:52 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, keescook-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <1507718024-2134-1-git-send-email-allen.pais-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Switch to using the new timer_setup() and from_timer()
> for net/nfc/*
>
> Signed-off-by: Allen Pais <allen.pais-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> ---
> net/nfc/core.c | 8 +++-----
> net/nfc/hci/core.c | 7 +++----
> net/nfc/hci/llc_shdlc.c | 23 +++++++++--------------
> net/nfc/llcp_core.c | 14 ++++++--------
> 4 files changed, 21 insertions(+), 31 deletions(-)
>
My bad, I missed the Reviewed-by.
Reviewed-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
- Allen
^ permalink raw reply
* [PATCH 1/4] net: qcom/emac: specify the correct DMA mask
From: Timur Tabi @ 2017-10-11 19:52 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: timur
In-Reply-To: <1507751546-10265-1-git-send-email-timur@codeaurora.org>
The 64/32-bit DMA mask hackery in the EMAC driver is not actually necessary,
and is technically not accurate. The EMAC hardware is limted to a 45-bit
DMA address. Although no EMAC-enabled system can have that much DDR,
an IOMMU could possible provide a larger address. Rather than play games
with the DMA mappings, the driver should provide a correct value and
trust the DMA/IOMMU layers to do the right thing.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index f477ba29c569..ee6f2d27502c 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -615,20 +615,11 @@ static int emac_probe(struct platform_device *pdev)
u32 reg;
int ret;
- /* The EMAC itself is capable of 64-bit DMA, so try that first. */
- ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+ /* The TPD buffer address is limited to 45 bits. */
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(45));
if (ret) {
- /* Some platforms may restrict the EMAC's address bus to less
- * then the size of DDR. In this case, we need to try a
- * smaller mask. We could try every possible smaller mask,
- * but that's overkill. Instead, just fall to 32-bit, which
- * should always work.
- */
- ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
- if (ret) {
- dev_err(&pdev->dev, "could not set DMA mask\n");
- return ret;
- }
+ dev_err(&pdev->dev, "could not set DMA mask\n");
+ return ret;
}
netdev = alloc_etherdev(sizeof(struct emac_adapter));
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode
From: Yury Norov @ 2017-10-11 19:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, linux-arm-kernel, netdev, Catalin Marinas,
David S. Miller, Florian Westphal
In-Reply-To: <1507747717.31614.28.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Eric,
On Wed, Oct 11, 2017 at 11:48:37AM -0700, Eric Dumazet wrote:
> On Wed, 2017-10-11 at 11:41 -0700, Eric Dumazet wrote:
> > On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote:
> > > Hi all,
> > >
> > > It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test
> > > in sys_sendto() path, like this:
> >
> > Thanks for the report.
> > Probably caused by one of my recent patches, so I am taking a look.
>
> Yes, this was silly.
>
> Please test this fix :
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 5a95e5886b55e03e4a8bfeac3506c657a4f97dde..15163454174babdcb465904f725b919268dd1bc7 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1712,6 +1712,7 @@ static inline void tcp_insert_write_queue_before(struct sk_buff *new,
>
> static inline void tcp_unlink_write_queue(struct sk_buff *skb, struct sock *sk)
> {
> + tcp_skb_tsorted_anchor_cleanup(skb);
> __skb_unlink(skb, &sk->sk_write_queue);
> }
The fix works for me, thanks.
Tested-by: Yury Norov <ynorov@caviumnetworks.com>
^ permalink raw reply
* Re: BUG:af_packet fails to TX TSO frames
From: Anton Ivanov @ 2017-10-11 19:39 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Anton Ivanov, Network Development, David Miller
In-Reply-To: <CAF=yD-+MCLAoP5=orUyG0tQjXykde++QrOdE7v44srR54yP32Q@mail.gmail.com>
On 11/10/17 19:57, Willem de Bruijn wrote:
> On Wed, Oct 11, 2017 at 2:39 PM, Anton Ivanov
> <anton.ivanov@kot-begemot.co.uk> wrote:
>> The check as now insists that the actual driver supports GSO_ROBUST, because
>> we have marked the skb dodgy.
>>
>> The specific bit which does this check is in net_gso_ok()
>>
>> Now, lets's see how many Ethernet drivers set GSO_ROBUST.
>>
>> find drivers/net/ethernet -type f -name "*.[c,h]" -exec grep -H GSO_ROBUST
>> {} \;
>>
>> That returns nothing in 4.x
>>
>> IMHO - af_packet allocates the skb, does all checks (and extra may be added)
>> on the gso, why is this set dodgy in the first place?
> It is set when the header has to be validated.
>
> The segmentation logic will validate and fixup gso_segs. See for
> instance tcp_gso_segment:
>
> if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
> /* Packet is from an untrusted source, reset gso_segs. */
>
> skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
>
> segs = NULL;
> goto out;
> }
>
> If the device would have the robust bit set and otherwise supports the
> required features, fix up gso_segs and pass the large packet to the
> device.
>
> Else it continues to the software gso path.
>
> Large packets generated with psock_txring_vnet.c pass this test. I
That test is indeed a different path - this goes via the tpacket_snd
which allocs via sock_alloc_send_skb. That results in a non-fragged skb
as it calls pskb after that with data_len = 0 asking for a contiguous one.
My stuff is using sendmmsg which ends up via packet_snd which allocs
via sock_alloc_send_pskb which is invoked in a way which always creates
2 segments - one for the linear section and one for the rest (and more
if needed). It is faster than tpacket by the way (several times).
As a comparison tap and other virtual drivers use sock_alloc_send_pskb
with non-zero data length which results in multiple frags. The code in
packet_snd is in fact identical with tap (+/- some cosmetic differences).
That is the difference between the tests and that is why your test works
and mine fails.
Now, alloc-ing a 64k contiguous skb every time IMHO is wrong.
So the logic in the xmit check at present works only because it is given
only a very corner case for a GSO frame and tested versus it. It should
work with the generic case which is what comes out of
sock_alloc_send_pskb (same as in tap).
A.
> suspect that there is a subtle difference in the virtio_net_hdr fields
> that that generates vs. your program.
>
^ permalink raw reply
* [PATCH] vxge: Clean up unused variables in vxge-traffic
From: Christos Gkekas @ 2017-10-11 19:26 UTC (permalink / raw)
To: Jon Mason, netdev, linux-kernel; +Cc: Christos Gkekas
Delete unused channel variables in vxge-traffic.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
---
drivers/net/ethernet/neterion/vxge/vxge-traffic.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
index 5f630a2..0c3b5de 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
@@ -1209,9 +1209,6 @@ void vxge_hw_ring_rxd_pre_post(struct __vxge_hw_ring *ring, void *rxdh)
void vxge_hw_ring_rxd_post_post(struct __vxge_hw_ring *ring, void *rxdh)
{
struct vxge_hw_ring_rxd_1 *rxdp = (struct vxge_hw_ring_rxd_1 *)rxdh;
- struct __vxge_hw_channel *channel;
-
- channel = &ring->channel;
rxdp->control_0 = VXGE_HW_RING_RXD_LIST_OWN_ADAPTER;
@@ -1359,11 +1356,8 @@ enum vxge_hw_status vxge_hw_ring_rxd_next_completed(
enum vxge_hw_status vxge_hw_ring_handle_tcode(
struct __vxge_hw_ring *ring, void *rxdh, u8 t_code)
{
- struct __vxge_hw_channel *channel;
enum vxge_hw_status status = VXGE_HW_OK;
- channel = &ring->channel;
-
/* If the t_code is not supported and if the
* t_code is other than 0x5 (unparseable packet
* such as unknown UPV6 header), Drop it !!!
@@ -1399,10 +1393,6 @@ enum vxge_hw_status vxge_hw_ring_handle_tcode(
static void __vxge_hw_non_offload_db_post(struct __vxge_hw_fifo *fifo,
u64 txdl_ptr, u32 num_txds, u32 no_snoop)
{
- struct __vxge_hw_channel *channel;
-
- channel = &fifo->channel;
-
writeq(VXGE_HW_NODBW_TYPE(VXGE_HW_NODBW_TYPE_NODBW) |
VXGE_HW_NODBW_LAST_TXD_NUMBER(num_txds) |
VXGE_HW_NODBW_GET_NO_SNOOP(no_snoop),
@@ -1506,9 +1496,6 @@ void vxge_hw_fifo_txdl_buffer_set(struct __vxge_hw_fifo *fifo,
{
struct __vxge_hw_fifo_txdl_priv *txdl_priv;
struct vxge_hw_fifo_txd *txdp, *txdp_last;
- struct __vxge_hw_channel *channel;
-
- channel = &fifo->channel;
txdl_priv = __vxge_hw_fifo_txdl_priv(fifo, txdlh);
txdp = (struct vxge_hw_fifo_txd *)txdlh + txdl_priv->frags;
@@ -1554,9 +1541,6 @@ void vxge_hw_fifo_txdl_post(struct __vxge_hw_fifo *fifo, void *txdlh)
struct __vxge_hw_fifo_txdl_priv *txdl_priv;
struct vxge_hw_fifo_txd *txdp_last;
struct vxge_hw_fifo_txd *txdp_first;
- struct __vxge_hw_channel *channel;
-
- channel = &fifo->channel;
txdl_priv = __vxge_hw_fifo_txdl_priv(fifo, txdlh);
txdp_first = txdlh;
@@ -1672,10 +1656,7 @@ enum vxge_hw_status vxge_hw_fifo_handle_tcode(struct __vxge_hw_fifo *fifo,
void *txdlh,
enum vxge_hw_fifo_tcode t_code)
{
- struct __vxge_hw_channel *channel;
-
enum vxge_hw_status status = VXGE_HW_OK;
- channel = &fifo->channel;
if (((t_code & 0x7) < 0) || ((t_code & 0x7) > 0x4)) {
status = VXGE_HW_ERR_INVALID_TCODE;
--
2.7.4
^ permalink raw reply related
* Re: BUG:af_packet fails to TX TSO frames
From: Anton Ivanov @ 2017-10-11 18:39 UTC (permalink / raw)
To: Willem de Bruijn, Anton Ivanov; +Cc: Network Development, David Miller
In-Reply-To: <CAF=yD-+JaS8JwEC2TyUG=Ebaho-MM+gjumrbHYM-H0EK1Hu62Q@mail.gmail.com>
The check as now insists that the actual driver supports GSO_ROBUST,
because we have marked the skb dodgy.
The specific bit which does this check is in net_gso_ok()
Now, lets's see how many Ethernet drivers set GSO_ROBUST.
find drivers/net/ethernet -type f -name "*.[c,h]" -exec grep -H
GSO_ROBUST {} \;
That returns nothing in 4.x
IMHO - af_packet allocates the skb, does all checks (and extra may be
added) on the gso, why is this set dodgy in the first place?
A.
On 11/10/17 17:26, Willem de Bruijn wrote:
> On Wed, Oct 11, 2017 at 11:54 AM, Anton Ivanov
> <anton.ivanov@cambridgegreys.com> wrote:
>> It is that patch.
>>
>> I rolled it back and immediately got it to work correctly on a Broadcom
>> Tigon. I can test on all other scenarios, I have tried, I suspect it will
>> come back alive on all of them.
>>
>> I am going to try to trace it through and see exactly where it drops a skb
>> which the card has no issues in accepting.
> It might be in the initialization of gso_type and csum. The virtio_net_hdr
> can encode various combinations of flags that are not allowed by the
> validation logic.
>
^ permalink raw reply
* Re: [PATCH] net: ftgmac100: Request clock and set speed
From: David Miller @ 2017-10-11 19:08 UTC (permalink / raw)
To: joel; +Cc: benh, netdev, linux-kernel, andrew
In-Reply-To: <20171010044925.21078-1-joel@jms.id.au>
From: Joel Stanley <joel@jms.id.au>
Date: Tue, 10 Oct 2017 15:19:25 +1030
> According to the ASPEED datasheet, gigabit speeds require a clock of
> 100MHz or higher. Other speeds require 25MHz or higher.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Hey Joel, it seems that Benjamin would like you to guard this new
logic with whether we have an aspeed configuration or not.
Thank you.
^ permalink raw reply
* act_skbedit unable to check queue_mapping at init time
From: Florian Fainelli @ 2017-10-11 19:02 UTC (permalink / raw)
To: netdev, jhs, jiri, alexander.h.duyck, xiyou.wangcong
Hi all,
It is perfectly possible for the following to happen:
# ls /sys/class/net/gphy/queues
rx-0 tx-0 tx-1 tx-2 tx-3
# tc qdisc add dev gphy root handle 1: multiq
# tc filter add dev gphy parent 1: protocol ip prio 1 u32
match ip dst 192.168.1.1 action skbedit queue_mapping 5
that specifies a queue_mapping value that exceeds what the underlying
device supports. There is a check for dev->real_num_tx_queue >
d->queue_mapping in tcf_skbedit() which makes sure we won't overflow the
queue space, but this will essentially render the action inactive.
I can't find a way to get a reference on a network device from a
tc_action_ops->init function in order to validate that the queue_mapping
is valid at ->init() time and return an appropriate error if we are
exceeding what the device does. This is an action chained to a match and
a filter, so somehow one would think it would be possible to obtain a
reference on the network device the filter was installed on...
Any clues how we could fix that?
--
Florian
^ permalink raw reply
* Re: BUG:af_packet fails to TX TSO frames
From: Willem de Bruijn @ 2017-10-11 18:57 UTC (permalink / raw)
To: Anton Ivanov; +Cc: Anton Ivanov, Network Development, David Miller
In-Reply-To: <23ace6d6-afa7-9a3a-aa61-1245ee6c0498@kot-begemot.co.uk>
On Wed, Oct 11, 2017 at 2:39 PM, Anton Ivanov
<anton.ivanov@kot-begemot.co.uk> wrote:
> The check as now insists that the actual driver supports GSO_ROBUST, because
> we have marked the skb dodgy.
>
> The specific bit which does this check is in net_gso_ok()
>
> Now, lets's see how many Ethernet drivers set GSO_ROBUST.
>
> find drivers/net/ethernet -type f -name "*.[c,h]" -exec grep -H GSO_ROBUST
> {} \;
>
> That returns nothing in 4.x
>
> IMHO - af_packet allocates the skb, does all checks (and extra may be added)
> on the gso, why is this set dodgy in the first place?
It is set when the header has to be validated.
The segmentation logic will validate and fixup gso_segs. See for
instance tcp_gso_segment:
if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
/* Packet is from an untrusted source, reset gso_segs. */
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
segs = NULL;
goto out;
}
If the device would have the robust bit set and otherwise supports the
required features, fix up gso_segs and pass the large packet to the
device.
Else it continues to the software gso path.
Large packets generated with psock_txring_vnet.c pass this test. I
suspect that there is a subtle difference in the virtio_net_hdr fields
that that generates vs. your program.
^ permalink raw reply
* Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode
From: Eric Dumazet @ 2017-10-11 18:48 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, linux-arm-kernel, netdev, Catalin Marinas,
David S. Miller, Florian Westphal
In-Reply-To: <1507747313.31614.27.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 2017-10-11 at 11:41 -0700, Eric Dumazet wrote:
> On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote:
> > Hi all,
> >
> > It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test
> > in sys_sendto() path, like this:
>
> Thanks for the report.
> Probably caused by one of my recent patches, so I am taking a look.
Yes, this was silly.
Please test this fix :
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 5a95e5886b55e03e4a8bfeac3506c657a4f97dde..15163454174babdcb465904f725b919268dd1bc7 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1712,6 +1712,7 @@ static inline void tcp_insert_write_queue_before(struct sk_buff *new,
static inline void tcp_unlink_write_queue(struct sk_buff *skb, struct sock *sk)
{
+ tcp_skb_tsorted_anchor_cleanup(skb);
__skb_unlink(skb, &sk->sk_write_queue);
}
^ permalink raw reply related
* Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode
From: Eric Dumazet @ 2017-10-11 18:41 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, linux-arm-kernel, netdev, Catalin Marinas,
David S. Miller, Florian Westphal
In-Reply-To: <20171011183522.tm2xxgzbdspjtsax@yury-thinkpad>
On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote:
> Hi all,
>
> It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test
> in sys_sendto() path, like this:
Thanks for the report.
Probably caused by one of my recent patches, so I am taking a look.
^ permalink raw reply
* Re: [Patch net-next] tcp: add a tracepoint for tcp_retransmit_skb()
From: Eric Dumazet @ 2017-10-11 18:38 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Hannes Frederic Sowa, Cong Wang, netdev, Eric Dumazet,
Yuchung Cheng, Neal Cardwell, Martin KaFai Lau, Brendan Gregg,
Song Liu
In-Reply-To: <20171011182113.rdxgrebygmiijpqs@ast-mbp>
On Wed, 2017-10-11 at 11:21 -0700, Alexei Starovoitov wrote:
> On Wed, Oct 11, 2017 at 06:31:45AM -0700, Eric Dumazet wrote:
> > On Tue, 2017-10-10 at 19:56 -0700, Alexei Starovoitov wrote:
> >
> > > actually we hit that too for completely different tracing use case.
> > > Indeed would be good to generate socket cookie unconditionally
> > > for all sockets. I don't think there is any harm.
> > >
> >
> > Simply call sock_gen_cookie() when needed.
> >
> > If a tracepoint needs the cookie and the cookie was not yet generated,
> > it will be generated at this point.
>
> we already have bpf_get_socket_cookie() that will call it,
> but this helper is for bpf socket filters, clsact and other
> networking related prog types, whereas all of tracing is
> read-only and side-effect-free, so we cannot use
> bpf_get_socket_cookie() there.
> Hence for tracing in kprobe-bpf we use raw sk pointer
> as map key and full tuple when passing the socket info to user
> space. If we could use socket cookie vs full tuple it would
> make a nice difference.
Since this sock_gen_cookie() is lock-free and IRQ ready, it should be
not be a problem to pretend it works with a const socket.
I am a bit unsure about revealing in socket cookie a precise count of
sockets created on a netns. Some attackers might use this in a side
channel attack.
^ permalink raw reply
* next: arm64: LTP sendto01 test causes system crash in ilp32 mode
From: Yury Norov @ 2017-10-11 18:35 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, netdev
Cc: Catalin Marinas, David S. Miller, Florian Westphal
[-- Attachment #1: Type: text/plain, Size: 5837 bytes --]
Hi all,
It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test
in sys_sendto() path, like this:
[ 554.034021] [<ffff80003ccd5a58>] 0xffff80003ccd5a58
[ 554.034156] [<ffff00000888fd34>] skb_release_all+0x14/0x30
[ 554.034288] [<ffff00000888fd64>] __kfree_skb+0x14/0x28
[ 554.034409] [<ffff0000088ece6c>] tcp_sendmsg_locked+0x4dc/0xcc8
[ 554.034541] [<ffff0000088ed68c>] tcp_sendmsg+0x34/0x58
[ 554.034659] [<ffff000008919fd4>] inet_sendmsg+0x2c/0xf8
[ 554.034783] [<ffff0000088842e8>] sock_sendmsg+0x18/0x30
[ 554.034928] [<ffff0000088861fc>] SyS_sendto+0x84/0xf8
I cannot reproduce it in lp64 mode, and test is passed in ilp32 mode
if I run it alone, even in infinite loop. But in ltplite scenario the
fail is always reproducible.
The brief analisys of dump shows that kernel crashes due to bad value
in ->destructor field of struct sk_buff, when tries to call
skb->destructor() in skb_release_all(). It looks very unusual,
comparing to typical ilp32 ABI bugs, and I suspect that here is generic
issue - maybe some race condition?
Kernel v4.14-rc4 works well. If no ideas, I'll bisect it a bit later.
Ooops log is below. Config is attached, and kernel sources are:
https://github.com/norov/linux/tree/ilp32-20171009
Yury
[ 554.026522] Unable to handle kernel read from unreadable memory at virtual address ffff80003ccd5a58
[ 554.027005] Mem abort info:
[ 554.027124] Exception class = IABT (current EL), IL = 32 bits
[ 554.027292] SET = 0, FnV = 0
[ 554.027378] EA = 0, S1PTW = 0
[ 554.027537] swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff000009069000
[ 554.027732] [ffff80003ccd5a58] *pgd=000000007eff7003, *pud=000000007eff6003, *pmd=00f800007cc00711
[ 554.028128] Internal error: Oops: 8600000e [#1] PREEMPT SMP
[ 554.028308] Modules linked in:
[ 554.028480] CPU: 1 PID: 6388 Comm: send01 Not tainted 4.14.0-rc4-next-20171009-00025-g6229c950955a #256
[ 554.028684] Hardware name: linux,dummy-virt (DT)
[ 554.028797] task: ffff80003b6d0e80 task.stack: ffff000009d70000
[ 554.028959] PC is at 0xffff80003ccd5a58
[ 554.029272] LR is at skb_release_head_state+0x5c/0xf8
[ 554.029406] pc : [<ffff80003ccd5a58>] lr : [<ffff00000888fc84>] pstate: 40000145
[ 554.029676] sp : ffff000009d73c00
[ 554.029806] x29: ffff000009d73c00 x28: ffff800039a86c80
[ 554.030021] x27: ffff800039a86dd8 x26: 00000000fffffff2
[ 554.030139] x25: ffff80003ccd5a00 x24: 0000000000000000
[ 554.030258] x23: ffff000009d73de8 x22: 0000000000000000
[ 554.030375] x21: ffff000009d73df8 x20: 0000000000000000
[ 554.030490] x19: ffff80003ccd5a00 x18: 00000000f7e73df8
[ 554.030606] x17: 00000000f7f40320 x16: ffff000008886178
[ 554.030721] x15: 0000000000000126 x14: 00000000f7fea700
[ 554.030840] x13: 00000000f7e75b8c x12: 00000000f7e7e43c
[ 554.030959] x11: 6f732064696c6176 x10: 0101010101010101
[ 554.031060] x9 : 206d305b1b535341 x8 : 0000000000005555
[ 554.031159] x7 : ffff80003b6d0e80 x6 : ffff80003c0aa910
[ 554.031256] x5 : ffff80003c0aad10 x4 : 0000000000000000
[ 554.031354] x3 : 000000010000f809 x2 : 0000000000000700
[ 554.031452] x1 : ffff80003ccd5a58 x0 : ffff80003ccd5a00
[ 554.031566] Process send01 (pid: 6388, stack limit = 0xffff000009d70000)
[ 554.031753] Call trace:
[ 554.031870] Exception stack(0xffff000009d73ac0 to 0xffff000009d73c00)
[ 554.032064] 3ac0: ffff80003ccd5a00 ffff80003ccd5a58 0000000000000700 000000010000f809
[ 554.032224] 3ae0: 0000000000000000 ffff80003c0aad10 ffff80003c0aa910 ffff80003b6d0e80
[ 554.032380] 3b00: 0000000000005555 206d305b1b535341 0101010101010101 6f732064696c6176
[ 554.032584] 3b20: 00000000f7e7e43c 00000000f7e75b8c 00000000f7fea700 0000000000000126
[ 554.032732] 3b40: ffff000008886178 00000000f7f40320 00000000f7e73df8 ffff80003ccd5a00
[ 554.032883] 3b60: 0000000000000000 ffff000009d73df8 0000000000000000 ffff000009d73de8
[ 554.033066] 3b80: 0000000000000000 ffff80003ccd5a00 00000000fffffff2 ffff800039a86dd8
[ 554.033233] 3ba0: ffff800039a86c80 ffff000009d73c00 ffff00000888fc84 ffff000009d73c00
[ 554.033386] 3bc0: ffff80003ccd5a58 0000000040000145 ffff0000089a2a64 0000000000000145
[ 554.033656] 3be0: 0001000000000000 ffff00000888fd08 ffff000009d73c00 ffff80003ccd5a58
[ 554.034021] [<ffff80003ccd5a58>] 0xffff80003ccd5a58
[ 554.034156] [<ffff00000888fd34>] skb_release_all+0x14/0x30
[ 554.034288] [<ffff00000888fd64>] __kfree_skb+0x14/0x28
[ 554.034409] [<ffff0000088ece6c>] tcp_sendmsg_locked+0x4dc/0xcc8
[ 554.034541] [<ffff0000088ed68c>] tcp_sendmsg+0x34/0x58
[ 554.034659] [<ffff000008919fd4>] inet_sendmsg+0x2c/0xf8
[ 554.034783] [<ffff0000088842e8>] sock_sendmsg+0x18/0x30
[ 554.034928] [<ffff0000088861fc>] SyS_sendto+0x84/0xf8
[ 554.035046] Exception stack(0xffff000009d73ec0 to 0xffff000009d74000)
[ 554.035186] 3ec0: 0000000000000004 00000000ffffffff 0000000000000400 0000000000000000
[ 554.035334] 3ee0: 0000000000000000 0000000000000000 20203130646e6573 1b20203220202020
[ 554.035503] 3f00: 00000000000000ce 206d305b1b535341 0101010101010101 6f732064696c6176
[ 554.035657] 3f20: 00000000f7e7e43c 00000000f7e75b8c 00000000f7fea700 0000000000000126
[ 554.035825] 3f40: 00000000004240e0 00000000f7f40320 00000000f7e73df8 000000000040e000
[ 554.035981] 3f60: 00000000f7feaea0 0000000000424000 0000000000424000 0000000000447000
[ 554.036148] 3f80: 0000000000447000 000000000040e000 000000000000002c 000000000040ee28
[ 554.036315] 3fa0: 0000000000447450 00000000fffef5b0 0000000000402748 00000000fffef5b0
[ 554.036520] 3fc0: 00000000f7f40348 0000000000000000 0000000000000004 00000000000000ce
[ 554.036683] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 554.036853] [<ffff0000080837dc>] el0_svc_naked+0x20/0x24
[ 554.037052] Code: 00000000 00000000 00000000 00000000 (00000000)
[ 554.037369] ---[ end trace c38823b11ae81586 ]---
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 36439 bytes --]
^ permalink raw reply
* Re: [Patch net-next] tcp: add a tracepoint for tcp_retransmit_skb()
From: Alexei Starovoitov @ 2017-10-11 18:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, Cong Wang, netdev, Eric Dumazet,
Yuchung Cheng, Neal Cardwell, Martin KaFai Lau, Brendan Gregg,
Song Liu
In-Reply-To: <1507728705.31614.24.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Oct 11, 2017 at 06:31:45AM -0700, Eric Dumazet wrote:
> On Tue, 2017-10-10 at 19:56 -0700, Alexei Starovoitov wrote:
>
> > actually we hit that too for completely different tracing use case.
> > Indeed would be good to generate socket cookie unconditionally
> > for all sockets. I don't think there is any harm.
> >
>
> Simply call sock_gen_cookie() when needed.
>
> If a tracepoint needs the cookie and the cookie was not yet generated,
> it will be generated at this point.
we already have bpf_get_socket_cookie() that will call it,
but this helper is for bpf socket filters, clsact and other
networking related prog types, whereas all of tracing is
read-only and side-effect-free, so we cannot use
bpf_get_socket_cookie() there.
Hence for tracing in kprobe-bpf we use raw sk pointer
as map key and full tuple when passing the socket info to user
space. If we could use socket cookie vs full tuple it would
make a nice difference.
^ permalink raw reply
* Re: [PATCH][bpf-next] bpf: remove redundant variable old_flags
From: Alexei Starovoitov @ 2017-10-11 18:15 UTC (permalink / raw)
To: Colin King
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20171011105623.19998-1-colin.king@canonical.com>
On Wed, Oct 11, 2017 at 11:56:23AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable old_flags is being assigned but is never read; it is redundant
> and can be removed.
>
> Cleans up clang warning: Value stored to 'old_flags' is never read
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> kernel/bpf/cgroup.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index e88abc0865d5..3db5a17fcfe8 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -192,7 +192,6 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
> struct cgroup_subsys_state *css;
> struct bpf_prog_list *pl;
> bool pl_was_allocated;
> - u32 old_flags;
> int err;
>
> if ((flags & BPF_F_ALLOW_OVERRIDE) && (flags & BPF_F_ALLOW_MULTI))
> @@ -239,7 +238,6 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
> pl->prog = prog;
> }
>
> - old_flags = cgrp->bpf.flags[type];
Acked-by: Alexei Starovoitov <ast@kernel.org>
thanks for the cleanup. That was a leftover of one of the previous
experiments I did.
The patch is for net-next.
^ permalink raw reply
* [PATCH net-next] sched: tc_mirred: Remove whitespaces
From: Florian Fainelli @ 2017-10-11 18:14 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
open list
This file contains unnecessary whitespaces as newlines, remove them,
found by looking at what struct tc_mirred looks like.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/uapi/linux/tc_act/tc_mirred.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/tc_act/tc_mirred.h b/include/uapi/linux/tc_act/tc_mirred.h
index 3d7a2b352a62..69038c29e8a9 100644
--- a/include/uapi/linux/tc_act/tc_mirred.h
+++ b/include/uapi/linux/tc_act/tc_mirred.h
@@ -9,13 +9,13 @@
#define TCA_EGRESS_MIRROR 2 /* mirror packet to EGRESS */
#define TCA_INGRESS_REDIR 3 /* packet redirect to INGRESS*/
#define TCA_INGRESS_MIRROR 4 /* mirror packet to INGRESS */
-
+
struct tc_mirred {
tc_gen;
int eaction; /* one of IN/EGRESS_MIRROR/REDIR */
__u32 ifindex; /* ifindex of egress port */
};
-
+
enum {
TCA_MIRRED_UNSPEC,
TCA_MIRRED_TM,
@@ -24,5 +24,5 @@ enum {
__TCA_MIRRED_MAX
};
#define TCA_MIRRED_MAX (__TCA_MIRRED_MAX - 1)
-
+
#endif
--
2.9.3
^ permalink raw reply related
* Re: [PATCH iproute2 2/2] ss: print MD5 signature keys configured on TCP sockets
From: Stephen Hemminger @ 2017-10-11 18:06 UTC (permalink / raw)
To: Ivan Delalande; +Cc: netdev
In-Reply-To: <20171006234820.27567-2-colona@arista.com>
On Fri, 6 Oct 2017 16:48:20 -0700
Ivan Delalande <colona@arista.com> wrote:
> These keys are reported by kernel 4.14 and later under the
> INET_DIAG_MD5SIG attribute, when INET_DIAG_INFO is requested (ss -i)
> and we have CAP_NET_ADMIN. The additional output looks like:
>
> md5keys:fe80::/64=signing_key,10.1.2.0/24=foobar,::1/128=Test
>
> Signed-off-by: Ivan Delalande <colona@arista.com>
Sure makes sense applied.
^ 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