* [PATCH net-next] liquidio: fix wrong information about channels reported to ethtool
From: Felix Manlunas @ 2017-01-05 0:18 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
From: Weilin Chang <weilin.chang@cavium.com>
Information reported to ethtool about channels is sometimes wrong for PF,
and always wrong for VF. Fix them by getting the information from the
right fields from the right structs.
Signed-off-by: Weilin Chang <weilin.chang@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index b00c300..50384ce 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -296,12 +296,16 @@ lio_ethtool_get_channels(struct net_device *dev,
rx_count = CFG_GET_NUM_RXQS_NIC_IF(conf6x, lio->ifidx);
tx_count = CFG_GET_NUM_TXQS_NIC_IF(conf6x, lio->ifidx);
} else if (OCTEON_CN23XX_PF(oct)) {
- struct octeon_config *conf23 = CHIP_CONF(oct, cn23xx_pf);
- max_rx = CFG_GET_OQ_MAX_Q(conf23);
- max_tx = CFG_GET_IQ_MAX_Q(conf23);
- rx_count = CFG_GET_NUM_RXQS_NIC_IF(conf23, lio->ifidx);
- tx_count = CFG_GET_NUM_TXQS_NIC_IF(conf23, lio->ifidx);
+ max_rx = oct->sriov_info.num_pf_rings;
+ max_tx = oct->sriov_info.num_pf_rings;
+ rx_count = lio->linfo.num_rxpciq;
+ tx_count = lio->linfo.num_txpciq;
+ } else if (OCTEON_CN23XX_VF(oct)) {
+ max_tx = oct->sriov_info.rings_per_vf;
+ max_rx = oct->sriov_info.rings_per_vf;
+ rx_count = lio->linfo.num_rxpciq;
+ tx_count = lio->linfo.num_txpciq;
}
channel->max_rx = max_rx;
^ permalink raw reply related
* RE: [PATCH] stmmac: Enable Clause 45 PHYs in GMAC4 (eQOS)
From: Kweh, Hock Leong @ 2017-01-05 1:37 UTC (permalink / raw)
To: Joao Pinto, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <14201d58c172f7a65b03510d36d55170f4d16cd5.1483540094.git.jpinto@synopsys.com>
> -----Original Message-----
> From: Joao Pinto [mailto:Joao.Pinto@synopsys.com]
> Sent: Wednesday, January 04, 2017 10:36 PM
> To: davem@davemloft.net
> Cc: Kweh, Hock Leong <hock.leong.kweh@intel.com>; netdev@vger.kernel.org;
> Joao Pinto <Joao.Pinto@synopsys.com>
> Subject: [PATCH] stmmac: Enable Clause 45 PHYs in GMAC4 (eQOS)
>
> The eQOS IP Core (best known in stmmac as gmac4) has a register that must be
> set if using a Clause 45 PHY. If this register is not set, the PHY won't work.
> This patch will have no impact in setups using Clause 22 PHYs.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Hi Joao,
This is not working on our environment. We are using the 4-ETH-4-MGB-101 plugin card.
Regards,
Wilson
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> index b0344c2..676ae3c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> @@ -41,6 +41,7 @@
> #define MII_GMAC4_GOC_SHIFT 2
> #define MII_GMAC4_WRITE (1 << MII_GMAC4_GOC_SHIFT)
> #define MII_GMAC4_READ (3 << MII_GMAC4_GOC_SHIFT)
> +#define MII_CLAUSE45_PHY (1 << 1)
>
> static int stmmac_mdio_busy_wait(void __iomem *ioaddr, unsigned int
> mii_addr) { @@ -125,7 +126,7 @@ static int stmmac_mdio_write(struct
> mii_bus *bus, int phyaddr, int phyreg,
> value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
> & priv->hw->mii.clk_csr_mask;
> if (priv->plat->has_gmac4)
> - value |= MII_GMAC4_WRITE;
> + value |= MII_GMAC4_WRITE | MII_CLAUSE45_PHY;
> else
> value |= MII_WRITE;
>
> --
> 2.9.3
^ permalink raw reply
* [PATCH net-next] packet: fix panic in __packet_set_timestamp on tpacket_v3 in tx mode
From: Daniel Borkmann @ 2017-01-05 1:34 UTC (permalink / raw)
To: davem; +Cc: sowmini.varadhan, willemb, netdev, Daniel Borkmann
When TX timestamping is in use with TPACKET_V3's TX ring, then we'll
hit the BUG() in __packet_set_timestamp() when ring buffer slot is
returned to user space via tpacket_destruct_skb(). This is due to v3
being assumed as unreachable here, but since 7f953ab2ba46 ("af_packet:
TX_RING support for TPACKET_V3") it's not anymore. Fix it by filling
the timestamp back into the ring slot.
Fixes: 7f953ab2ba46 ("af_packet: TX_RING support for TPACKET_V3")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
net/packet/af_packet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 7e39087..ddbda25 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -481,6 +481,9 @@ static __u32 __packet_set_timestamp(struct packet_sock *po, void *frame,
h.h2->tp_nsec = ts.tv_nsec;
break;
case TPACKET_V3:
+ h.h3->tp_sec = ts.tv_sec;
+ h.h3->tp_nsec = ts.tv_nsec;
+ break;
default:
WARN(1, "TPACKET version not supported.\n");
BUG();
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next] packet: fix panic in __packet_set_timestamp on tpacket_v3 in tx mode
From: Sowmini Varadhan @ 2017-01-05 2:10 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, willemb, netdev
In-Reply-To: <1483580068-13854-1-git-send-email-daniel@iogearbox.net>
On (01/05/17 02:34), Daniel Borkmann wrote:
> When TX timestamping is in use with TPACKET_V3's TX ring, then we'll
> hit the BUG() in __packet_set_timestamp() when ring buffer slot is
> returned to user space via tpacket_destruct_skb(). This is due to v3
> being assumed as unreachable here, but since 7f953ab2ba46 ("af_packet:
> TX_RING support for TPACKET_V3") it's not anymore. Fix it by filling
> the timestamp back into the ring slot.
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
--Sowmini
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-05 3:09 UTC (permalink / raw)
To: John Fastabend, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <586D458F.5050705@gmail.com>
On 2017年01月05日 02:57, John Fastabend wrote:
> [...]
>
>> On 2017年01月04日 00:48, John Fastabend wrote:
>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>> program load and does not block MTU changes after the program
>>>>> has loaded.
>>>>>
>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>
>>>>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>>>>> ---
> [...]
>
>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>> needs to read the mtu via
>>>
>>> virtio_cread16(vdev, ...)
>>>
>>> or we may break the negotiated mtu.
>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>> the device about the mtu in this case which is not supported by virtio now.
> Note this is not really a XDP specific problem. The guest can change the MTU
> after init time even without XDP which I assume should ideally result in a
> notification if the MTU is negotiated.
Yes, Michael, do you think we need add some mechanism to notify host
about MTU change in this case?
Thanks
^ permalink raw reply
* Re: [RFC PATCH] virtio_net: XDP support for adjust_head
From: Jason Wang @ 2017-01-05 3:10 UTC (permalink / raw)
To: John Fastabend, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <586D45DF.401@gmail.com>
On 2017年01月05日 02:58, John Fastabend wrote:
> [...]
>
>>> @@ -393,34 +397,39 @@ static u32 do_xdp_prog(struct virtnet_info *vi,
>>> struct bpf_prog *xdp_prog,
>>> void *data, int len)
>>> {
>>> - int hdr_padded_len;
>>> struct xdp_buff xdp;
>>> - void *buf;
>>> unsigned int qp;
>>> u32 act;
>>> +
>>> if (vi->mergeable_rx_bufs) {
>>> - hdr_padded_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>>> - xdp.data = data + hdr_padded_len;
>>> + int desc_room = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>>> +
>>> + /* Allow consuming headroom but reserve enough space to push
>>> + * the descriptor on if we get an XDP_TX return code.
>>> + */
>>> + xdp.data_hard_start = data - vi->headroom + desc_room;
>>> + xdp.data = data + desc_room;
>>> xdp.data_end = xdp.data + (len - vi->hdr_len);
>>> - buf = data;
>>> } else { /* small buffers */
>>> struct sk_buff *skb = data;
>>> - xdp.data = skb->data;
>>> + xdp.data_hard_start = skb->data;
>>> + xdp.data = skb->data + vi->headroom;
>>> xdp.data_end = xdp.data + len;
>>> - buf = skb->data;
>>> }
>>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>>> switch (act) {
>>> case XDP_PASS:
>>> + if (!vi->mergeable_rx_bufs)
>>> + __skb_pull((struct sk_buff *) data,
>>> + xdp.data - xdp.data_hard_start);
>> Instead of doing things here and virtnet_xdp_xmit(). How about always making
>> skb->data point to the buffer head like:
>>
>> 1) reserve headroom in add_recvbuf_small()
>> 2) skb_push(xdp->data - xdp_data_hard_start, skb) if we detect xdp->data was
>> modified afer bpf_prog_run_xdp()
>>
>> Then there's no special code in either XDP_PASS or XDP_TX?
>>
> Alternatively moving the pull into the receive_small XDP handler also
> removes the special case. I'll submit a patch shortly let me know what
> you think.
>
I'm ok with this.
Thanks
^ permalink raw reply
* [net PATCH 1/2] virtio_net: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-05 3:11 UTC (permalink / raw)
To: jasowang, mst; +Cc: john.r.fastabend, netdev, john.fastabend
XDP programs can not consume multiple pages so we cap the MTU to
avoid this case. Virtio-net however only checks the MTU at XDP
program load and does not block MTU changes after the program
has loaded.
This patch sets/clears the max_mtu value at XDP load/unload time.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
drivers/net/virtio_net.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a10500..261103d9 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1699,11 +1699,28 @@ static void virtnet_init_settings(struct net_device *dev)
.set_settings = virtnet_set_settings,
};
+#define MIN_MTU ETH_MIN_MTU
+#define MAX_MTU ETH_MAX_MTU
+
+static unsigned long int virtnet_xdp_mtu(struct bpf_prog *prog,
+ struct virtnet_info *vi)
+{
+ if (!prog && virtio_has_feature(vi->vdev, VIRTIO_NET_F_MTU))
+ return virtio_cread16(vi->vdev,
+ offsetof(struct virtio_net_config, mtu));
+ else if (!prog)
+ return ETH_MAX_MTU;
+ else if (vi->mergeable_rx_bufs)
+ return PAGE_SIZE - sizeof(struct padded_vnet_hdr);
+ else
+ return GOOD_PACKET_LEN;
+}
+
static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
{
- unsigned long int max_sz = PAGE_SIZE - sizeof(struct padded_vnet_hdr);
struct virtnet_info *vi = netdev_priv(dev);
struct bpf_prog *old_prog;
+ unsigned long int max_sz;
u16 xdp_qp = 0, curr_qp;
int i, err;
@@ -1720,6 +1737,7 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
return -EINVAL;
}
+ max_sz = virtnet_xdp_mtu(prog, vi);
if (dev->mtu > max_sz) {
netdev_warn(dev, "XDP requires MTU less than %lu\n", max_sz);
return -EINVAL;
@@ -1748,6 +1766,9 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
virtnet_set_queues(vi, curr_qp);
return PTR_ERR(prog);
}
+ dev->max_mtu = max_sz;
+ } else {
+ dev->max_mtu = ETH_MAX_MTU;
}
vi->xdp_queue_pairs = xdp_qp;
@@ -2133,9 +2154,6 @@ static bool virtnet_validate_features(struct virtio_device *vdev)
return true;
}
-#define MIN_MTU ETH_MIN_MTU
-#define MAX_MTU ETH_MAX_MTU
-
static int virtnet_probe(struct virtio_device *vdev)
{
int i, err;
^ permalink raw reply related
* [net PATCH 2/2] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: John Fastabend @ 2017-01-05 3:11 UTC (permalink / raw)
To: jasowang, mst; +Cc: john.r.fastabend, netdev, john.fastabend
In-Reply-To: <20170105031118.2636.82374.stgit@john-Precision-Tower-5810>
In the small buffer case during driver unload we currently use
put_page instead of dev_kfree_skb. Resolve this by adding a check
for virtnet mode when checking XDP queue type. Also name the
function so that the code reads correctly to match the additional
check.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
drivers/net/virtio_net.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 261103d9..a224d3e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1911,8 +1911,12 @@ static void free_receive_page_frags(struct virtnet_info *vi)
put_page(vi->rq[i].alloc_frag.page);
}
-static bool is_xdp_queue(struct virtnet_info *vi, int q)
+static bool is_xdp_raw_buffer_queue(struct virtnet_info *vi, int q)
{
+ /* For small receive mode always use kfree_skb variants */
+ if (!vi->mergeable_rx_bufs)
+ return false;
+
if (q < (vi->curr_queue_pairs - vi->xdp_queue_pairs))
return false;
else if (q < vi->curr_queue_pairs)
@@ -1929,7 +1933,7 @@ static void free_unused_bufs(struct virtnet_info *vi)
for (i = 0; i < vi->max_queue_pairs; i++) {
struct virtqueue *vq = vi->sq[i].vq;
while ((buf = virtqueue_detach_unused_buf(vq)) != NULL) {
- if (!is_xdp_queue(vi, i))
+ if (!is_xdp_raw_buffer_queue(vi, i))
dev_kfree_skb(buf);
else
put_page(virt_to_head_page(buf));
^ permalink raw reply related
* Re: [net PATCH 1/2] virtio_net: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-05 3:14 UTC (permalink / raw)
To: jasowang, mst; +Cc: john.r.fastabend, netdev
In-Reply-To: <20170105031118.2636.82374.stgit@john-Precision-Tower-5810>
On 17-01-04 07:11 PM, John Fastabend wrote:
> XDP programs can not consume multiple pages so we cap the MTU to
> avoid this case. Virtio-net however only checks the MTU at XDP
> program load and does not block MTU changes after the program
> has loaded.
>
> This patch sets/clears the max_mtu value at XDP load/unload time.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/virtio_net.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
[...]
> static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> {
> - unsigned long int max_sz = PAGE_SIZE - sizeof(struct padded_vnet_hdr);
> struct virtnet_info *vi = netdev_priv(dev);
> struct bpf_prog *old_prog;
> + unsigned long int max_sz;
> u16 xdp_qp = 0, curr_qp;
> int i, err;
>
> @@ -1720,6 +1737,7 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> return -EINVAL;
> }
>
> + max_sz = virtnet_xdp_mtu(prog, vi);
> if (dev->mtu > max_sz) {
> netdev_warn(dev, "XDP requires MTU less than %lu\n", max_sz);
> return -EINVAL;
> @@ -1748,6 +1766,9 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> virtnet_set_queues(vi, curr_qp);
> return PTR_ERR(prog);
> }
> + dev->max_mtu = max_sz;
> + } else {
> + dev->max_mtu = ETH_MAX_MTU;
> }
oops v2 needed. The else branch is not required anymore. :/
^ permalink raw reply
* Re: [net PATCH 1/2] virtio_net: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-05 3:18 UTC (permalink / raw)
To: John Fastabend; +Cc: jasowang, john.r.fastabend, netdev
In-Reply-To: <20170105031118.2636.82374.stgit@john-Precision-Tower-5810>
On Wed, Jan 04, 2017 at 07:11:18PM -0800, John Fastabend wrote:
> XDP programs can not consume multiple pages so we cap the MTU to
> avoid this case. Virtio-net however only checks the MTU at XDP
> program load and does not block MTU changes after the program
> has loaded.
Do drivers really have to tweak max mtu all the time?
Seems strange, I would say drivers just report device caps
and net core enforces rules.
Can't net core do these checks?
>
> This patch sets/clears the max_mtu value at XDP load/unload time.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/virtio_net.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4a10500..261103d9 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1699,11 +1699,28 @@ static void virtnet_init_settings(struct net_device *dev)
> .set_settings = virtnet_set_settings,
> };
>
> +#define MIN_MTU ETH_MIN_MTU
> +#define MAX_MTU ETH_MAX_MTU
> +
> +static unsigned long int virtnet_xdp_mtu(struct bpf_prog *prog,
> + struct virtnet_info *vi)
> +{
> + if (!prog && virtio_has_feature(vi->vdev, VIRTIO_NET_F_MTU))
> + return virtio_cread16(vi->vdev,
> + offsetof(struct virtio_net_config, mtu));
> + else if (!prog)
> + return ETH_MAX_MTU;
> + else if (vi->mergeable_rx_bufs)
> + return PAGE_SIZE - sizeof(struct padded_vnet_hdr);
> + else
> + return GOOD_PACKET_LEN;
> +}
> +
> static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> {
> - unsigned long int max_sz = PAGE_SIZE - sizeof(struct padded_vnet_hdr);
> struct virtnet_info *vi = netdev_priv(dev);
> struct bpf_prog *old_prog;
> + unsigned long int max_sz;
> u16 xdp_qp = 0, curr_qp;
> int i, err;
>
> @@ -1720,6 +1737,7 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> return -EINVAL;
> }
>
> + max_sz = virtnet_xdp_mtu(prog, vi);
> if (dev->mtu > max_sz) {
> netdev_warn(dev, "XDP requires MTU less than %lu\n", max_sz);
> return -EINVAL;
> @@ -1748,6 +1766,9 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> virtnet_set_queues(vi, curr_qp);
> return PTR_ERR(prog);
> }
> + dev->max_mtu = max_sz;
> + } else {
> + dev->max_mtu = ETH_MAX_MTU;
> }
>
> vi->xdp_queue_pairs = xdp_qp;
> @@ -2133,9 +2154,6 @@ static bool virtnet_validate_features(struct virtio_device *vdev)
> return true;
> }
>
> -#define MIN_MTU ETH_MIN_MTU
> -#define MAX_MTU ETH_MAX_MTU
> -
> static int virtnet_probe(struct virtio_device *vdev)
> {
> int i, err;
^ permalink raw reply
* Re: [PATCH net-next] packet: fix panic in __packet_set_timestamp on tpacket_v3 in tx mode
From: David Miller @ 2017-01-05 4:51 UTC (permalink / raw)
To: daniel; +Cc: sowmini.varadhan, willemb, netdev
In-Reply-To: <1483580068-13854-1-git-send-email-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 5 Jan 2017 02:34:28 +0100
> When TX timestamping is in use with TPACKET_V3's TX ring, then we'll
> hit the BUG() in __packet_set_timestamp() when ring buffer slot is
> returned to user space via tpacket_destruct_skb(). This is due to v3
> being assumed as unreachable here, but since 7f953ab2ba46 ("af_packet:
> TX_RING support for TPACKET_V3") it's not anymore. Fix it by filling
> the timestamp back into the ring slot.
>
> Fixes: 7f953ab2ba46 ("af_packet: TX_RING support for TPACKET_V3")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next] cxgb4: Synchronize access to mailbox
From: Hariprasad Shenai @ 2017-01-05 5:53 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, nirranjan, ganeshgr, Hariprasad Shenai
The issue comes when there are multiple threads attempting to use
the mailbox facility at the same time.
When DCB operations and interface up/down is run in a loop for every
0.1 sec, we observed mailbox collisions. And out of the two commands
one would fail with the present code, since we don't queue the second
command.
To overcome the above issue, added a queue to access the mailbox.
Whenever a mailbox command is issued add it to the queue. If its at
the head issue the mailbox command, else wait for the existing command
to complete. Usually command takes less than a milli-second to
complete.
Also timeout from the loop, if the command under execution takes
long time to run.
In reality, the number of mailbox access collisions is going to be
very rare since no one runs such abusive script.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 8 ++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 3 ++
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 59 ++++++++++++++++++++++++-
3 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 0bce1bf9ca0f..78a852c72f5d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -782,6 +782,10 @@ struct vf_info {
bool pf_set_mac;
};
+struct mbox_list {
+ struct list_head list;
+};
+
struct adapter {
void __iomem *regs;
void __iomem *bar2;
@@ -844,6 +848,10 @@ struct adapter {
struct work_struct db_drop_task;
bool tid_release_task_busy;
+ /* lock for mailbox cmd list */
+ spinlock_t mbox_lock;
+ struct mbox_list mlist;
+
/* support for mailbox command/reply logging */
#define T4_OS_LOG_MBOX_CMDS 256
struct mbox_cmd_log *mbox_log;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 6f951877430b..34ceb3518dd4 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4707,6 +4707,9 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
spin_lock_init(&adapter->stats_lock);
spin_lock_init(&adapter->tid_release_lock);
spin_lock_init(&adapter->win0_lock);
+ spin_lock_init(&adapter->mbox_lock);
+
+ INIT_LIST_HEAD(&adapter->mbox_list.list);
INIT_WORK(&adapter->tid_release_task, process_tid_release_list);
INIT_WORK(&adapter->db_full_task, process_db_full);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index e8139514d32c..7ac6ea531b0f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -284,6 +284,7 @@ int t4_wr_mbox_meat_timeout(struct adapter *adap, int mbox, const void *cmd,
1, 1, 3, 5, 10, 10, 20, 50, 100, 200
};
+ struct mbox_list entry;
u16 access = 0;
u16 execute = 0;
u32 v;
@@ -311,11 +312,61 @@ int t4_wr_mbox_meat_timeout(struct adapter *adap, int mbox, const void *cmd,
timeout = -timeout;
}
+ /* Queue ourselves onto the mailbox access list. When our entry is at
+ * the front of the list, we have rights to access the mailbox. So we
+ * wait [for a while] till we're at the front [or bail out with an
+ * EBUSY] ...
+ */
+ spin_lock(&adap->mbox_lock);
+ list_add_tail(&entry.list, &adap->mlist.list);
+ spin_unlock(&adap->mbox_lock);
+
+ delay_idx = 0;
+ ms = delay[0];
+
+ for (i = 0; ; i += ms) {
+ /* If we've waited too long, return a busy indication. This
+ * really ought to be based on our initial position in the
+ * mailbox access list but this is a start. We very rearely
+ * contend on access to the mailbox ...
+ */
+ if (i > FW_CMD_MAX_TIMEOUT) {
+ spin_lock(&adap->mbox_lock);
+ list_del(&entry.list);
+ spin_unlock(&adap->mbox_lock);
+ ret = -EBUSY;
+ t4_record_mbox(adap, cmd, size, access, ret);
+ return ret;
+ }
+
+ /* If we're at the head, break out and start the mailbox
+ * protocol.
+ */
+ if (list_first_entry(&adap->mlist.list, struct mbox_list,
+ list) == &entry)
+ break;
+
+ /* Delay for a bit before checking again ... */
+ if (sleep_ok) {
+ ms = delay[delay_idx]; /* last element may repeat */
+ if (delay_idx < ARRAY_SIZE(delay) - 1)
+ delay_idx++;
+ msleep(ms);
+ } else {
+ mdelay(ms);
+ }
+ }
+
+ /* Loop trying to get ownership of the mailbox. Return an error
+ * if we can't gain ownership.
+ */
v = MBOWNER_G(t4_read_reg(adap, ctl_reg));
for (i = 0; v == MBOX_OWNER_NONE && i < 3; i++)
v = MBOWNER_G(t4_read_reg(adap, ctl_reg));
-
if (v != MBOX_OWNER_DRV) {
+ spin_lock(&adap->mbox_lock);
+ list_del(&entry.list);
+ spin_unlock(&adap->mbox_lock);
ret = (v == MBOX_OWNER_FW) ? -EBUSY : -ETIMEDOUT;
t4_record_mbox(adap, cmd, MBOX_LEN, access, ret);
return ret;
@@ -366,6 +417,9 @@ int t4_wr_mbox_meat_timeout(struct adapter *adap, int mbox, const void *cmd,
execute = i + ms;
t4_record_mbox(adap, cmd_rpl,
MBOX_LEN, access, execute);
+ spin_lock(&adap->mbox_lock);
+ list_del(&entry.list);
+ spin_unlock(&adap->mbox_lock);
return -FW_CMD_RETVAL_G((int)res);
}
}
@@ -375,6 +429,9 @@ int t4_wr_mbox_meat_timeout(struct adapter *adap, int mbox, const void *cmd,
dev_err(adap->pdev_dev, "command %#x in mailbox %d timed out\n",
*(const u8 *)cmd, mbox);
t4_report_fw_error(adap);
+ spin_lock(&adap->mbox_lock);
+ list_del(&entry.list);
+ spin_unlock(&adap->mbox_lock);
return ret;
}
--
2.3.4
^ permalink raw reply related
* Re: [PATCH nf-next 4/4] netfilter: merge ctinfo into nfct pointer storage area
From: kbuild test robot @ 2017-01-05 6:03 UTC (permalink / raw)
To: Florian Westphal; +Cc: kbuild-all, netfilter-devel, netdev, Florian Westphal
In-Reply-To: <1483544150-10686-5-git-send-email-fw@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]
Hi Florian,
[auto build test WARNING on nf-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Westphal/netfilter-skbuff-merge-nfctinfo-bits-and-nfct-pointer/20170105-133727
base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: x86_64-randconfig-x002-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
net/ipv4/netfilter/nf_defrag_ipv4.c: In function 'ipv4_conntrack_defrag':
>> net/ipv4/netfilter/nf_defrag_ipv4.c:78:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (skb->_nfct && !nf_ct_is_template((struct nf_conn *) skb_nfct(skb)));
^~
net/ipv4/netfilter/nf_defrag_ipv4.c:79:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
return NF_ACCEPT;
^~~~~~
vim +/if +78 net/ipv4/netfilter/nf_defrag_ipv4.c
62 }
63
64 static unsigned int ipv4_conntrack_defrag(void *priv,
65 struct sk_buff *skb,
66 const struct nf_hook_state *state)
67 {
68 struct sock *sk = skb->sk;
69
70 if (sk && sk_fullsock(sk) && (sk->sk_family == PF_INET) &&
71 inet_sk(sk)->nodefrag)
72 return NF_ACCEPT;
73
74 #if IS_ENABLED(CONFIG_NF_CONNTRACK)
75 #if !IS_ENABLED(CONFIG_NF_NAT)
76 /* Previously seen (loopback)? Ignore. Do this before
77 fragment check. */
> 78 if (skb->_nfct && !nf_ct_is_template((struct nf_conn *) skb_nfct(skb)));
79 return NF_ACCEPT;
80 #endif
81 #endif
82 /* Gather fragments. */
83 if (ip_is_fragment(ip_hdr(skb))) {
84 enum ip_defrag_users user =
85 nf_ct_defrag_user(state->hook, skb);
86
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24700 bytes --]
^ permalink raw reply
* [PATCHv2 1/1] r8169: fix the typo in the comment
From: Zhu Yanjun @ 2017-01-05 8:02 UTC (permalink / raw)
To: nic_swsd, netdev; +Cc: Zhu Yanjun
>From the realtek data sheet, the PID0 should be bit 0.
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
---
Change from v1 to v2:
change the commit header.
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 44389c9..8f1623b 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -696,7 +696,7 @@ enum rtl_tx_desc_bit_1 {
enum rtl_rx_desc_bit {
/* Rx private */
PID1 = (1 << 18), /* Protocol ID bit 1/2 */
- PID0 = (1 << 17), /* Protocol ID bit 2/2 */
+ PID0 = (1 << 17), /* Protocol ID bit 0/2 */
#define RxProtoUDP (PID1)
#define RxProtoTCP (PID0)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] net/sched: cls_flower: Add user specified data
From: Simon Horman @ 2017-01-05 8:03 UTC (permalink / raw)
To: Paul Blakey
Cc: Jamal Hadi Salim, John Fastabend, David S. Miller, netdev,
Jiri Pirko, Hadar Hen Zion, Or Gerlitz, Roi Dayan, Roman Mashak
In-Reply-To: <786655e9-de6a-29e9-a043-207afedcedc2@mellanox.com>
On Wed, Jan 04, 2017 at 01:45:28PM +0200, Paul Blakey wrote:
> On 04/01/2017 12:14, Simon Horman wrote:
> >On Tue, Jan 03, 2017 at 02:22:05PM +0200, Paul Blakey wrote:
> >>
> >>On 03/01/2017 13:44, Jamal Hadi Salim wrote:
> >>>On 17-01-02 11:33 PM, John Fastabend wrote:
> >>>>On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
> >>>[..]
> >>>>>Like all cookie semantics it is for storing state. The receiver
> >>>>>(kernel)
> >>>>>is not just store it and not intepret it. The user when reading it back
> >>>>>simplifies what they have to do for their processing.
> >>>>>
> >>>>>>The tuple <ifindex:qdisc:prio:handle> really should be unique why
> >>>>>>not use this for system wide mappings?
> >>>>>>
> >>>>>I think on a single machine should be enough, however:
> >>>>>typically the user wants to define the value in a manner that
> >>>>>in a distributed system it is unique. It would be trickier to
> >>>>>do so with well defined values such as above.
> >>>>>
> >>>>Just extend the tuple <hostname:ifindex:qdisc:prio:handle> that
> >>>>should be unique in the domain of hostname's, or use some other domain
> >>>>wide machine identifier.
> >>>>
> >>>May work for the case of filter identification. The nice thing for
> >>>allowing cookies is you can let the user define it define their
> >>>own scheme.
> >>>
> >>>>Although actions can be shared so the cookie can be shared across
> >>>>filters. Maybe its useful but it doesn't uniquely identify a filter
> >>>>in the shared case but the user would have to specify that case
> >>>>so maybe its not important.
> >>>>
> >>>Note: the action cookies and filter cookies are unrelated/orthogonal.
> >>>Their basic concept of stashing something in the cookie to help improve
> >>>what user space does (in our case millions of actions of which some are
> >>>used for accounting) is similar.
> >>>I have no objections to the flow cookies; my main concern was it should
> >>>be applicable to all classifiers not just flower. And the arbitrary size
> >>>of the cookie that you pointed out is questionable.
> >>>
> >>>cheers,
> >>>jamal
> >>
> >>Hi all,
> >>Our use case is replacing OVS rules with TC filters for HW offload, and
> >>you're are right the cookie would
> >>have saved us the mapping from OVS rule ufid to the tc filter handle/prio...
> >>that was generated for it.
> >>It also was going to be used to store other info like which OVS output port
> >>corresponds to the ifindex,
> >Possibly off-topic but I am curious to know why you need to store the port.
> >My possibly naïve assumption is that a filter is attached to the netdev
> >corresponding to the input port and mirred or other actions are used to output
> >to netdevs corresponding to output ports.
>
> Right, its for the output ports, OVS uses ovs port numbers and mirred action
> uses the device ifindex, so there is need
> to translate it back to OVS port on dump.
Understood, that is a tedious abstraction to support.
But I don't see an easy way around it at this time.
If I read Jamal's emails correctly he is working on per-action cookies.
They may be better than per-flow cookies for storing the OvS port number
(though not the UUID of the flow).
...
^ permalink raw reply
* [PATCHv2 1/1] r8169: fix the typo in the comment
From: yanjun.zhu @ 2017-01-05 7:54 UTC (permalink / raw)
To: nic_swsd, netdev; +Cc: Zhu Yanjun
From: Zhu Yanjun <yanjun.zhu@oracle.com>
>From the realtek data sheet, the PID0 should be bit 0.
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
---
Change from v1 to v2:
change the commit header.
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 44389c9..8f1623b 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -696,7 +696,7 @@ enum rtl_tx_desc_bit_1 {
enum rtl_rx_desc_bit {
/* Rx private */
PID1 = (1 << 18), /* Protocol ID bit 1/2 */
- PID0 = (1 << 17), /* Protocol ID bit 2/2 */
+ PID0 = (1 << 17), /* Protocol ID bit 0/2 */
#define RxProtoUDP (PID1)
#define RxProtoTCP (PID0)
--
2.7.4
^ permalink raw reply related
* [PATCH] net: ethoc: Remove unused members from struct ethoc
From: Tobias Klauser @ 2017-01-05 8:16 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli, thierry.reding, andrew, colin.king, tremyfr
The io_region_size and dma_alloc members of struct ethoc are only
written but never read, so they might as well be removed.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/ethoc.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 45abc81f6f55..63e5e14174ee 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -180,8 +180,6 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
* struct ethoc - driver-private device structure
* @iobase: pointer to I/O memory region
* @membase: pointer to buffer memory region
- * @dma_alloc: dma allocated buffer size
- * @io_region_size: I/O memory region size
* @num_bd: number of buffer descriptors
* @num_tx: number of send buffers
* @cur_tx: last send buffer written
@@ -199,8 +197,6 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
struct ethoc {
void __iomem *iobase;
void __iomem *membase;
- int dma_alloc;
- resource_size_t io_region_size;
bool big_endian;
unsigned int num_bd;
@@ -1096,8 +1092,6 @@ static int ethoc_probe(struct platform_device *pdev)
/* setup driver-private data */
priv = netdev_priv(netdev);
priv->netdev = netdev;
- priv->dma_alloc = 0;
- priv->io_region_size = resource_size(mmio);
priv->iobase = devm_ioremap_nocache(&pdev->dev, netdev->base_addr,
resource_size(mmio));
@@ -1127,7 +1121,6 @@ static int ethoc_probe(struct platform_device *pdev)
goto free;
}
netdev->mem_end = netdev->mem_start + buffer_size;
- priv->dma_alloc = buffer_size;
}
priv->big_endian = pdata ? pdata->big_endian :
--
2.11.0
^ permalink raw reply related
* Re: [PATCH nf-next 4/4] netfilter: merge ctinfo into nfct pointer storage area
From: kbuild test robot @ 2017-01-05 8:31 UTC (permalink / raw)
To: Florian Westphal; +Cc: kbuild-all, netfilter-devel, netdev, Florian Westphal
In-Reply-To: <1483544150-10686-5-git-send-email-fw@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]
Hi Florian,
[auto build test WARNING on nf-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Westphal/netfilter-skbuff-merge-nfctinfo-bits-and-nfct-pointer/20170105-133727
base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: x86_64-randconfig-b0-01051551 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
net/ipv4/netfilter/nf_dup_ipv4.c: In function 'nf_dup_ipv4':
>> net/ipv4/netfilter/nf_dup_ipv4.c:56: warning: unused variable 'untracked'
vim +/untracked +56 net/ipv4/netfilter/nf_dup_ipv4.c
40 fl4.flowi4_flags = FLOWI_FLAG_KNOWN_NH;
41 rt = ip_route_output_key(net, &fl4);
42 if (IS_ERR(rt))
43 return false;
44
45 skb_dst_drop(skb);
46 skb_dst_set(skb, &rt->dst);
47 skb->dev = rt->dst.dev;
48 skb->protocol = htons(ETH_P_IP);
49
50 return true;
51 }
52
53 void nf_dup_ipv4(struct net *net, struct sk_buff *skb, unsigned int hooknum,
54 const struct in_addr *gw, int oif)
55 {
> 56 struct nf_conn *untracked;
57 struct iphdr *iph;
58
59 if (this_cpu_read(nf_skb_duplicated))
60 return;
61 /*
62 * Copy the skb, and route the copy. Will later return %XT_CONTINUE for
63 * the original skb, which should continue on its way as if nothing has
64 * happened. The copy should be independently delivered to the gateway.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28934 bytes --]
^ permalink raw reply
* Re: [PATCH] phy state machine: failsafe leave invalid RUNNING state
From: Zefir Kurtisi @ 2017-01-05 9:23 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: andrew
In-Reply-To: <b482e869-cc00-8b19-f18d-eb0a2d2ba67d@gmail.com>
On 01/04/2017 10:44 PM, Florian Fainelli wrote:
> On 01/04/2017 08:10 AM, Zefir Kurtisi wrote:
>> On 01/04/2017 04:30 PM, Florian Fainelli wrote:
>>>
>>>
>>> On 01/04/2017 07:27 AM, Zefir Kurtisi wrote:
>>>> On 01/04/2017 04:13 PM, Florian Fainelli wrote:
>>>>>
>>>>>
>>>>> On 01/04/2017 07:04 AM, Zefir Kurtisi wrote:
>>>>>> While in RUNNING state, phy_state_machine() checks for link changes by
>>>>>> comparing phydev->link before and after calling phy_read_status().
>>>>>> This works as long as it is guaranteed that phydev->link is never
>>>>>> changed outside the phy_state_machine().
>>>>>>
>>>>>> If in some setups this happens, it causes the state machine to miss
>>>>>> a link loss and remain RUNNING despite phydev->link being 0.
>>>>>>
>>>>>> This has been observed running a dsa setup with a process continuously
>>>>>> polling the link states over ethtool each second (SNMPD RFC-1213
>>>>>> agent). Disconnecting the link on a phy followed by a ETHTOOL_GSET
>>>>>> causes dsa_slave_get_settings() / dsa_slave_get_link_ksettings() to
>>>>>> call phy_read_status() and with that modify the link status - and
>>>>>> with that bricking the phy state machine.
>>>>>
>>>>> That's the interesting part of the analysis, how does this brick the PHY
>>>>> state machine? Is the PHY driver changing the link status in the
>>>>> read_status callback that it implements?
>>>>>
>>>> phydev->read_status points to genphy_read_status(), where the first call goes to
>>>> genphy_update_link() which updates the link status.
>>>>
>>>> Thereafter phy_state_machine():RUNNING won't be able to detect the link loss
>>>> anymore unless the link state changes again.
>>>>
>>>>
>>>> I was trying to figure out if there is a rule that forbids changing phydev->link
>>>> from outside the state machine, but found several places where it happens (either
>>>> directly, or over genphy_read_status() or over genphy_update_link()).
>>>>
>>>> Curious how this did not show up before, since within the dsa setup it is very
>>>> easy to trigger:
>>>> a) physically disconnect link
>>>> b) within one second run ethtool ethX
>>>
>>> You need to be more specific here about what "the dsa setup" is, drivers
>>> involved, which ports of the switch you are seeing this with (user
>>> facing, CPU port, DSA port?) etc.
>>>
>> I am working on top of LEDE and with that at kernel 4.4.21 - alas I checked the
>> related source files and believe the effect should be reproducible with HEAD.
>>
>> The setup is as follows:
>> mv88e6321:
>> * ports 0+1 connected to fibre-optics transceivers at fixed 100 Mbps
>> * port 4 is CPU port
>> * custom phy driver (replacement for marvell.ko) only populated with
>> * .config_init to
>> * set fixed speed for ports 0+1 (when in FO mode)
>> * run genphy_config_init() for all other modes (here: CPU port)
>> * .config_aneg=genphy_config_aneg, .read_status=genphy_read_status
>>
>>
>> To my understanding, the exact setup is irrelevant - to reproduce the issue it is
>> enough to have a means of running genphy_update_link() (as done in e.g.
>> mediatek/mtk_eth_soc.c, dsa/slave.c), or genphy_read_status() (as done in e.g.
>> hisilicon/hns/hns_enet.c) or phy_read_status() (as done in e.g.
>> ethernet/ti/netcp_ethss.c, ethernet/aeroflex/greth.c, etc.). In the observed
>> drivers it is mostly implemented in the ETHTOOL_GSET execution path.
>>
>> Once you get the link state updated outside the phy state machine, it remains in
>> invalid RUNNING. To prevent that invalid state, to my understanding upper layer
>> drivers (Ethernet, dsa) must not modify link-states in any case (including calling
>> the functions noted above), or we need the proposed fail-safe mechanism to prevent
>> getting stuck.
>
> OK, I see the code path involved now, sorry -ENOCOFFEE when I initially
> responded. Yes, clearly, we should not be mangling the PHY device's link
> by calling genphy_read_status(). At first glance, none of the users
> below should be doing what they are doing, but let's kick a separate
> patch series to collect feedback from the driver writes.
>
> Thanks!
>
Ok, thanks for taking time.
The kbuild test robot error is due to 'struct device dev' been removed from
phy_device struct since 4.4.21. Does it make sense to provide a v2 fixing that, or
do you expect that this fail-safe mechanism is not needed once all Ethernet/dsa
drivers are fixed?
I think it won't hurt to add the check simply to ensure that it got fixed and the
issue is not popping up thereafter.
Cheers,
Zefir
^ permalink raw reply
* Re: [PATCH net-next V2 3/3] tun: rx batching
From: Stefan Hajnoczi @ 2017-01-05 9:27 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <73da2ef8-2454-5614-d637-0ce7c5287433@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 830 bytes --]
On Wed, Jan 04, 2017 at 11:03:32AM +0800, Jason Wang wrote:
> On 2017年01月03日 21:33, Stefan Hajnoczi wrote:
> > On Wed, Dec 28, 2016 at 04:09:31PM +0800, Jason Wang wrote:
> > > +static int tun_rx_batched(struct tun_file *tfile, struct sk_buff *skb,
> > > + int more)
> > > +{
> > > + struct sk_buff_head *queue = &tfile->sk.sk_write_queue;
> > > + struct sk_buff_head process_queue;
> > > + int qlen;
> > > + bool rcv = false;
> > > +
> > > + spin_lock(&queue->lock);
> > Should this be spin_lock_bh()? Below and in tun_get_user() there are
> > explicit local_bh_disable() calls so I guess BHs can interrupt us here
> > and this would deadlock.
>
> sk_write_queue were accessed only in this function which runs under process
> context, so no need for spin_lock_bh() here.
I see, thanks!
Stefan
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] sh_eth: R8A7740 supports packet shecksumming
From: Sergei Shtylyov @ 2017-01-05 9:33 UTC (permalink / raw)
To: netdev, linux-renesas-soc, David Miller
In-Reply-To: <1871204.P0zXJRoIfd@wasted.cogentembedded.com>
Hello!
Oops, typo in the subject, "shecksumming". David, should I resend?
MBR, Sergei
^ permalink raw reply
* Re: [net PATCH 1/2] virtio_net: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-05 9:34 UTC (permalink / raw)
To: Michael S. Tsirkin, John Fastabend; +Cc: john.r.fastabend, netdev
In-Reply-To: <20170105051641-mutt-send-email-mst@kernel.org>
On 2017年01月05日 11:18, Michael S. Tsirkin wrote:
> On Wed, Jan 04, 2017 at 07:11:18PM -0800, John Fastabend wrote:
>> XDP programs can not consume multiple pages so we cap the MTU to
>> avoid this case. Virtio-net however only checks the MTU at XDP
>> program load and does not block MTU changes after the program
>> has loaded.
> Do drivers really have to tweak max mtu all the time?
> Seems strange, I would say drivers just report device caps
> and net core enforces rules.
> Can't net core do these checks?
I think this needs host co-operation, at least this patch prevents user
from misconfiguring mtu in guest.
^ permalink raw reply
* [PATCH] net: xilinx: emaclite: Remove xemaclite_remove_ndev()
From: Tobias Klauser @ 2017-01-05 9:41 UTC (permalink / raw)
To: netdev; +Cc: michal.simek, soren.brinkmann, davem
xemaclite_remove_ndev() is a simple wrapper around free_netdev()
checking for NULL before the call. All possible paths calling
it are guaranteed to pass a non-NULL argument, so rather call
free_netdev() directly.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 93dc10b10c09..97dcc0bd5a85 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1029,20 +1029,6 @@ static int xemaclite_send(struct sk_buff *orig_skb, struct net_device *dev)
}
/**
- * xemaclite_remove_ndev - Free the network device
- * @ndev: Pointer to the network device to be freed
- *
- * This function un maps the IO region of the Emaclite device and frees the net
- * device.
- */
-static void xemaclite_remove_ndev(struct net_device *ndev)
-{
- if (ndev) {
- free_netdev(ndev);
- }
-}
-
-/**
* get_bool - Get a parameter from the OF device
* @ofdev: Pointer to OF device structure
* @s: Property to be retrieved
@@ -1172,7 +1158,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
return 0;
error:
- xemaclite_remove_ndev(ndev);
+ free_netdev(ndev);
return rc;
}
@@ -1204,7 +1190,7 @@ static int xemaclite_of_remove(struct platform_device *of_dev)
of_node_put(lp->phy_node);
lp->phy_node = NULL;
- xemaclite_remove_ndev(ndev);
+ free_netdev(ndev);
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v3 net-next] net:mv88e6xxx: use g2 interrupt for 6097 chip
From: Volodymyr Bendiuga @ 2017-01-05 9:44 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, volodymyr.bendiuga
Cc: Volodymyr Bendiuga
This chip needs MV88E6XXX_FLAG_G2_INT
Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index dcb1b81..474e715 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -568,6 +568,7 @@ enum mv88e6xxx_cap {
(MV88E6XXX_FLAG_G1_ATU_FID | \
MV88E6XXX_FLAG_G1_VTU_FID | \
MV88E6XXX_FLAG_GLOBAL2 | \
+ MV88E6XXX_FLAG_G2_INT | \
MV88E6XXX_FLAG_G2_MGMT_EN_2X | \
MV88E6XXX_FLAG_G2_MGMT_EN_0X | \
MV88E6XXX_FLAG_G2_POT | \
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V2 1/3] net/skbuff: Introduce skb_mac_offset()
From: Amir Vadai @ 2017-01-05 9:54 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Jiri Pirko, Or Gerlitz, Hadar Har-Zion, Amir Vadai
In-Reply-To: <20170105095454.32644-1-amir@vadai.me>
Introduce skb_mac_offset() that could be used to get mac header offset.
Signed-off-by: Amir Vadai <amir@vadai.me>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
---
include/linux/skbuff.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index b53c0cfd417e..3d8f81f39c2b 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2178,6 +2178,11 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
return skb->head + skb->mac_header;
}
+static inline int skb_mac_offset(const struct sk_buff *skb)
+{
+ return skb_mac_header(skb) - skb->data;
+}
+
static inline int skb_mac_header_was_set(const struct sk_buff *skb)
{
return skb->mac_header != (typeof(skb->mac_header))~0U;
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox