* Re: [PATCH net] net/sched: act_pedit: fix memory leak when IDR allocation fails
From: Cong Wang @ 2018-11-14 20:36 UTC (permalink / raw)
To: Davide Caratti
Cc: Jiri Pirko, David Miller, Vlad Buslov,
Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <8ae2ff111546be071b461a0678939078353dff27.1542193853.git.dcaratti@redhat.com>
(Cc'ing Jamal)
On Wed, Nov 14, 2018 at 3:26 AM Davide Caratti <dcaratti@redhat.com> wrote:
>
> tcf_idr_check_alloc() can return a negative value, on allocation failures
> (-ENOMEM) or IDR exhaustion (-ENOSPC): don't leak keys_ex in these cases.
I think the comments above tcf_idr_check_alloc() need to improve too,
they imply tcf_idr_check_alloc() returns either 0 or 1.
Of course, this can be done with a separated patch.
>
> Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
I think your patch is correct.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 6:46 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <88eaf53b-b148-7b27-491a-30706398ae06@redhat.com>
On 2018/11/15 12:19, Jason Wang wrote:
>
> On 2018/11/15 上午11:56, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
>>
>> Before the implement, I want to discuss with everyone again, and
>> want to know everyone's suggestions.
>>
>> After the discussion, based on this point I will try to implement
>> this idea, but I am not familiar with the virtio-net, that is a
>> pity. :(
>
>
> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>
>
>> -------------------------Simple idea------------------------------
>>
>> 1. The packet layout will become as follows:
>>
>> +---------------------------------+
>> | Virtio-net header |
>> |(struct virtio_net_hdr_mrg_rxbuf)|
>> +---------------------------------+
>> | Vsock header |
>> | (struct virtio_vsock_hdr) |
>> +---------------------------------+
>> | payload |
>> | (until end of packet) |
>> +---------------------------------+
>>
>> 2. The Guest->Host basic code flow as follow:
>> +------------+
>> | Client |
>> +------------+
>> |
>> |
>> +------------------------------------------------------------------+
>> |VSOCK Core Module |
>> |ops->sendmsg; (vsock_stream_sendmsg) |
>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>> | * hdr and payload */ |
>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>> |vsock hdr and payload, and then call |
>> +------------------------------------------------------------------+
>
>
> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
Hi Jason,
You mean we should not register netdev if use vsock, and in order to
avoid confusion, then I think whether we should keep vsock and export
some virtio-net's functions that can be shared. In this way, first, vsock
may keep existing architecture and will not affect virtio-net. In addition,
vsock doesn't need to use virtio_net header too, then it don't need to pack
skb structure.
Thanks,
Yiwen.
>
>
>> |
>> |
>> +------------------------------------------------------------------+
>> |Virtio-net Module |
>> |start_xmit |
>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>> +------------------------------------------------------------------+
>> |
>> |
>> +------------------------------------------------------------------+
>> |Vhost-net Module |
>> |handle_tx |
>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>> | /* This point has some differences, vhost-net use ->sendmsg to |
>> | * forward information, however vsock only need to notify server |
>> | * that data ready. */ |
>> +------------------------------------------------------------------+
>
>
> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>
>
>> |
>> |
>> +------------------------------------------------------------------+
>> |VSOCK Core Module |
>> |alloc_pkt, copy skb data to pkt. |
>> |add pkt to rx_queue and notify server to get data. |
>> +------------------------------------------------------------------+
>>
>> 3. To Host->Guest
>> I have a problem and difficult, mainly I know about virtio-net a little),
>> because I have been doing work related with storage and file system.
>>
>> The problem as follows:
>> we should monitor all of socket of vsock in handle_rx, when there are
>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>> get data, it is different with socket. To vsock, I think host will
>> not call ->recvmsg when it need to send message to guest. To net,
>> vhost-net only as forwarding layer.
>
> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
For vsock, Host->Guest, it's code flow as follows:
Server call send()
-> sendmsg(); (vsock_stream_sendmsg)
-> virtio_trasnport_send_pkt_info
-> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
Vhost_worker
-> vhost_transport_send_pkt_work
-> get pkt from send_pkt_list
-> get vq input desc and then fill data to desc addr
-> update used ring and then signal guest
In the whole process, host don't call recvmsg() because it is a net device, and
it also receives any messages.
For vhost-net, I understand it is a tap device, so it can receive messages
from other net device.
This is my understanding, it may have some errors.
Thanks.
>
> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>
> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>
> Thanks
>
>
>>
>
> .
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 6:49 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED162C.5070902@huawei.com>
On 2018/11/15 14:46, jiangyiwen wrote:
> On 2018/11/15 12:19, Jason Wang wrote:
>>
>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>> Hi Stefan, Michael, Jason and everyone,
>>>
>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>> This idea has two advantages:
>>> First, it can use many great features of virtio-net, like batching,
>>> mergeable rx buffer and multiqueue, etc.
>>> Second, it can reduce many duplicate codes and make it easy to be
>>> maintained.
>>>
>>> Before the implement, I want to discuss with everyone again, and
>>> want to know everyone's suggestions.
>>>
>>> After the discussion, based on this point I will try to implement
>>> this idea, but I am not familiar with the virtio-net, that is a
>>> pity. :(
>>
>>
>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>
>>
>>> -------------------------Simple idea------------------------------
>>>
>>> 1. The packet layout will become as follows:
>>>
>>> +---------------------------------+
>>> | Virtio-net header |
>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> +---------------------------------+
>>> | Vsock header |
>>> | (struct virtio_vsock_hdr) |
>>> +---------------------------------+
>>> | payload |
>>> | (until end of packet) |
>>> +---------------------------------+
>>>
>>> 2. The Guest->Host basic code flow as follow:
>>> +------------+
>>> | Client |
>>> +------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>> | * hdr and payload */ |
>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>> |vsock hdr and payload, and then call |
>>> +------------------------------------------------------------------+
>>
>>
>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>
> Hi Jason,
>
> You mean we should not register netdev if use vsock, and in order to
> avoid confusion, then I think whether we should keep vsock and export
> some virtio-net's functions that can be shared. In this way, first, vsock
> may keep existing architecture and will not affect virtio-net. In addition,
> vsock doesn't need to use virtio_net header too, then it don't need to pack
> skb structure.
>
> Thanks,
> Yiwen.
>
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Virtio-net Module |
>>> |start_xmit |
>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>> +------------------------------------------------------------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Vhost-net Module |
>>> |handle_tx |
>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>> | * forward information, however vsock only need to notify server |
>>> | * that data ready. */ |
>>> +------------------------------------------------------------------+
>>
>>
>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |alloc_pkt, copy skb data to pkt. |
>>> |add pkt to rx_queue and notify server to get data. |
>>> +------------------------------------------------------------------+
>>>
>>> 3. To Host->Guest
>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>> because I have been doing work related with storage and file system.
>>>
>>> The problem as follows:
>>> we should monitor all of socket of vsock in handle_rx, when there are
>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>> get data, it is different with socket. To vsock, I think host will
>>> not call ->recvmsg when it need to send message to guest. To net,
>>> vhost-net only as forwarding layer.
>>
>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>
> For vsock, Host->Guest, it's code flow as follows:
> Server call send()
> -> sendmsg(); (vsock_stream_sendmsg)
> -> virtio_trasnport_send_pkt_info
> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>
> Vhost_worker
> -> vhost_transport_send_pkt_work
> -> get pkt from send_pkt_list
> -> get vq input desc and then fill data to desc addr
> -> update used ring and then signal guest
>
> In the whole process, host don't call recvmsg() because it is a net device, and
> it also receives any messages.
Sorry, it is *not* a net device, it *does not* receive any messages.
Thanks.
>
> For vhost-net, I understand it is a tap device, so it can receive messages
> from other net device.
>
> This is my understanding, it may have some errors.
>
> Thanks.
>
>>
>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>
>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>
>> Thanks
>>
>>
>>>
>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v2 net-next 06/21] net: usb: aqc111: Introduce link management
From: Andrew Lunn @ 2018-11-14 21:16 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <6a92f825-576e-3826-66c7-791304661174@aquantia.com>
> > Thats again because of this product has tightly integrated MAC+Phy.
> > MAC FW controls system interface and reports/alters link state
> > as a joint state on copper and SIF (even in dpa direct phy mode).
> >
> > We can't extract phy api into a standalone fully functional phylib therefore.
> > Also as far as I know this particular phy is not available in the wild.
>
> So the point is that MAC firmware is managing SERDES and system interface link.
Linux can manage that SERDES link between the MAC and the PHY. There
are two ways this can go:
1) You use phylib. When the PHY reports link, the adjust_link callback
in the MAC is called. The phydev structure contains information about
how you should configure the SERDES, SGMII, 2500Base-X, 5000Base-X. It
works, but it is not so nice.
2) phylink gives you a much nicer API to do the same. Again, the PHY
reports the link is up. phylink will then tell the MAC how to
configure its end of the SERDES. The problem with phylink is that it
expects a DT building. You don't have that, since this is a USB
device. But you also don't need a lot of the features of phylink like
SFPs, the i2c bus for the SFPs, GPIOs etc. So it should not be to hard
to make this work without device tree.
By using core linux code, we avoid bugs in firmware which nobody can
fix. The Linux core code should be well tested and supported, but
phylink is rather new, so might still have some corner cases.
I also cannot imaging parts of the PHY driver will not be re-usable
for other Aquantia PHYs. I have a board with an AQCS109 under my desk
waiting for me to do something with it. I really would like a better
PHY driver for it than the kernel currently has. Hopefully there is
some code reuse possibilities here.
Andrew
^ permalink raw reply
* Re: [PATCH v2 net-next 19/21] net: usb: aqc111: Add support for wake on LAN by MAGIC packet
From: Andrew Lunn @ 2018-11-14 21:30 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <3c322e27-06c7-69a1-cbe8-271741da0bb3@aquantia.com>
> We've considered that, but then thought about the following case:
>
> After such a sleep state where partner's capabilities were considered,
> user may move with the unit and replug it into different link partner with
> other, incompatible speed mask. That will anyway lead to wol link failure.
WOL for a nomadic device? Is that even a real use case?
Anyway, looking at the link partner capabilities is just really a
corner case, that the LP only supports 1G. Do such devices exist?
So skipping this is fine. But if you use phylib, you pretty much get
it for free if you want it.
Andrew
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 7:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181115015547-mutt-send-email-mst@kernel.org>
On 2018/11/15 15:04, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
>
> I'm not sure I get the motivation. Which features of
> virtio net are relevant to vsock? The ones that you mention
> all seem to be mostly of use to the networking stack.
>
>
>> Before the implement, I want to discuss with everyone again, and
>> want to know everyone's suggestions.
>>
>> After the discussion, based on this point I will try to implement
>> this idea, but I am not familiar with the virtio-net, that is a
>> pity. :(
>>
>> -------------------------Simple idea------------------------------
>>
>> 1. The packet layout will become as follows:
>>
>> +---------------------------------+
>> | Virtio-net header |
>> |(struct virtio_net_hdr_mrg_rxbuf)|
>
> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>
Hi Michael,
Yes, currently vsock has poor performance, first, it only support transport
small packet, in order to make the balance between performance and guest memory.
In order to solve this problem, there are two features vsock can used,
mergeable rx buffer and multiqueue. Based on this, there are some shared
codes vsock can use.
Thanks,
Yiwen.
>> +---------------------------------+
>> | Vsock header |
>> | (struct virtio_vsock_hdr) |
>> +---------------------------------+
>> | payload |
>> | (until end of packet) |
>> +---------------------------------+
>
> Thanks,
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Michael S. Tsirkin @ 2018-11-15 8:10 UTC (permalink / raw)
To: jiangyiwen; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <5BED2267.8030306@huawei.com>
On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
> > On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
> >> Hi Stefan, Michael, Jason and everyone,
> >>
> >> Several days ago, I discussed with jason about "Vsock over Virtio-net".
> >> This idea has two advantages:
> >> First, it can use many great features of virtio-net, like batching,
> >> mergeable rx buffer and multiqueue, etc.
> >> Second, it can reduce many duplicate codes and make it easy to be
> >> maintained.
> >
> > I'm not sure I get the motivation. Which features of
> > virtio net are relevant to vsock? The ones that you mention
> > all seem to be mostly of use to the networking stack.
> >
> >
> >> Before the implement, I want to discuss with everyone again, and
> >> want to know everyone's suggestions.
> >>
> >> After the discussion, based on this point I will try to implement
> >> this idea, but I am not familiar with the virtio-net, that is a
> >> pity. :(
> >>
> >> -------------------------Simple idea------------------------------
> >>
> >> 1. The packet layout will become as follows:
> >>
> >> +---------------------------------+
> >> | Virtio-net header |
> >> |(struct virtio_net_hdr_mrg_rxbuf)|
> >
> > Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
> >
>
> Hi Michael,
>
> Yes, currently vsock has poor performance, first, it only support transport
> small packet, in order to make the balance between performance and guest memory.
>
> In order to solve this problem, there are two features vsock can used,
> mergeable rx buffer and multiqueue. Based on this, there are some shared
> codes vsock can use.
>
> Thanks,
> Yiwen.
Supporting more queues with vsock is probably significantly
less work than a completely new interface.
For mergeable, as buffers are split arbitrarily, why can't you combine
them within guest driver before sending them up the stack?
Probably better than relying on host to do it.
> >> +---------------------------------+
> >> | Vsock header |
> >> | (struct virtio_vsock_hdr) |
> >> +---------------------------------+
> >> | payload |
> >> | (until end of packet) |
> >> +---------------------------------+
> >
> > Thanks,
> >
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:19 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED162C.5070902@huawei.com>
On 2018/11/15 下午2:46, jiangyiwen wrote:
> On 2018/11/15 12:19, Jason Wang wrote:
>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>> Hi Stefan, Michael, Jason and everyone,
>>>
>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>> This idea has two advantages:
>>> First, it can use many great features of virtio-net, like batching,
>>> mergeable rx buffer and multiqueue, etc.
>>> Second, it can reduce many duplicate codes and make it easy to be
>>> maintained.
>>>
>>> Before the implement, I want to discuss with everyone again, and
>>> want to know everyone's suggestions.
>>>
>>> After the discussion, based on this point I will try to implement
>>> this idea, but I am not familiar with the virtio-net, that is a
>>> pity. :(
>>
>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>
>>
>>> -------------------------Simple idea------------------------------
>>>
>>> 1. The packet layout will become as follows:
>>>
>>> +---------------------------------+
>>> | Virtio-net header |
>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> +---------------------------------+
>>> | Vsock header |
>>> | (struct virtio_vsock_hdr) |
>>> +---------------------------------+
>>> | payload |
>>> | (until end of packet) |
>>> +---------------------------------+
>>>
>>> 2. The Guest->Host basic code flow as follow:
>>> +------------+
>>> | Client |
>>> +------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>> | * hdr and payload */ |
>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>> |vsock hdr and payload, and then call |
>>> +------------------------------------------------------------------+
>>
>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
> Hi Jason,
>
> You mean we should not register netdev if use vsock, and in order to
> avoid confusion, then I think whether we should keep vsock and export
> some virtio-net's functions that can be shared. In this way, first, vsock
> may keep existing architecture and will not affect virtio-net.
At least it needs new feature bits which will be a functional
duplication of virtio-net (e.g mrg_rxbuf).
> In addition,
> vsock doesn't need to use virtio_net header too, then it don't need to pack
> skb structure.
For mergeable rx buffer it need I think?
>
> Thanks,
> Yiwen.
>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Virtio-net Module |
>>> |start_xmit |
>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>> +------------------------------------------------------------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Vhost-net Module |
>>> |handle_tx |
>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>> | * forward information, however vsock only need to notify server |
>>> | * that data ready. */ |
>>> +------------------------------------------------------------------+
>>
>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |alloc_pkt, copy skb data to pkt. |
>>> |add pkt to rx_queue and notify server to get data. |
>>> +------------------------------------------------------------------+
>>>
>>> 3. To Host->Guest
>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>> because I have been doing work related with storage and file system.
>>>
>>> The problem as follows:
>>> we should monitor all of socket of vsock in handle_rx, when there are
>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>> get data, it is different with socket. To vsock, I think host will
>>> not call ->recvmsg when it need to send message to guest. To net,
>>> vhost-net only as forwarding layer.
>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
> For vsock, Host->Guest, it's code flow as follows:
> Server call send()
> -> sendmsg(); (vsock_stream_sendmsg)
> -> virtio_trasnport_send_pkt_info
> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>
> Vhost_worker
> -> vhost_transport_send_pkt_work
> -> get pkt from send_pkt_list
> -> get vq input desc and then fill data to desc addr
> -> update used ring and then signal guest
>
> In the whole process, host don't call recvmsg() because it is a net device, and
> it also receives any messages.
If I understand this correctly, there's no a socket object on host that
represent vosck in guest? If yes, maybe we can invent one.
Thanks
>
> For vhost-net, I understand it is a tap device, so it can receive messages
> from other net device.
>
> This is my understanding, it may have some errors.
>
> Thanks.
>
>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>
>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>
>> Thanks
>>
>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:24 UTC (permalink / raw)
To: Michael S. Tsirkin, jiangyiwen; +Cc: virtualization, kvm, stefanha, netdev
In-Reply-To: <20181115015547-mutt-send-email-mst@kernel.org>
On 2018/11/15 下午3:04, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
> I'm not sure I get the motivation. Which features of
> virtio net are relevant to vsock?
Vsock is just a L2 (and above) protocol from the view of the device. So
I think we should answer the question why we need two different paths
for networking traffic? Or what is the fundamental reason that makes
vsock does not go for virtio-net?
I agree they could be different type of devices but codes could be
shared in both guest and host (or even qemu) for not duplicating
features(bugs).
Thanks
> The ones that you mention
> all seem to be mostly of use to the networking stack.
>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH AUTOSEL 4.18 10/59] bpf: fix bpf_prog_get_info_by_fd to return 0 func_lens for unpriv
From: Sasha Levin @ 2018-11-14 22:22 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Daniel Borkmann, Sandipan Das, Song Liu, Alexei Starovoitov,
Sasha Levin, netdev
In-Reply-To: <20181114222335.99339-1-sashal@kernel.org>
From: Daniel Borkmann <daniel@iogearbox.net>
[ Upstream commit 28c2fae726bf5003cd209b0d5910a642af98316f ]
While dbecd7388476 ("bpf: get kernel symbol addresses via syscall")
zeroed info.nr_jited_ksyms in bpf_prog_get_info_by_fd() for queries
from unprivileged users, commit 815581c11cc2 ("bpf: get JITed image
lengths of functions via syscall") forgot about doing so and therefore
returns the #elems of the user set up buffer which is incorrect. It
also needs to indicate a info.nr_jited_func_lens of zero.
Fixes: 815581c11cc2 ("bpf: get JITed image lengths of functions via syscall")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Sandipan Das <sandipan@linux.vnet.ibm.com>
Cc: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/syscall.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index a31a1ba0f8ea..482215292b0f 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1896,6 +1896,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
info.jited_prog_len = 0;
info.xlated_prog_len = 0;
info.nr_jited_ksyms = 0;
+ info.nr_jited_func_lens = 0;
goto done;
}
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 12/59] net: dsa: microchip: initialize mutex before use
From: Sasha Levin @ 2018-11-14 22:22 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Tristram Ha, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181114222335.99339-1-sashal@kernel.org>
From: Tristram Ha <Tristram.Ha@microchip.com>
[ Upstream commit 284fb78ed7572117846f8e1d1d8e3dbfd16880c2 ]
Initialize mutex before use. Avoid kernel complaint when
CONFIG_DEBUG_LOCK_ALLOC is enabled.
Fixes: b987e98e50ab90e5 ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/dsa/microchip/ksz_common.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 7210c49b7922..c3103bdb6cf6 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -1108,11 +1108,6 @@ static int ksz_switch_init(struct ksz_device *dev)
{
int i;
- mutex_init(&dev->reg_mutex);
- mutex_init(&dev->stats_mutex);
- mutex_init(&dev->alu_mutex);
- mutex_init(&dev->vlan_mutex);
-
dev->ds->ops = &ksz_switch_ops;
for (i = 0; i < ARRAY_SIZE(ksz_switch_chips); i++) {
@@ -1197,6 +1192,11 @@ int ksz_switch_register(struct ksz_device *dev)
if (dev->pdata)
dev->chip_id = dev->pdata->chip_id;
+ mutex_init(&dev->reg_mutex);
+ mutex_init(&dev->stats_mutex);
+ mutex_init(&dev->alu_mutex);
+ mutex_init(&dev->vlan_mutex);
+
if (ksz_switch_detect(dev))
return -EINVAL;
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 13/59] net: bcmgenet: protect stop from timeout
From: Sasha Levin @ 2018-11-14 22:22 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Doug Berger, Florian Fainelli, David S . Miller, Sasha Levin,
netdev
In-Reply-To: <20181114222335.99339-1-sashal@kernel.org>
From: Doug Berger <opendmb@gmail.com>
[ Upstream commit 09e805d2570a3a94f13dd9c9ad2bcab23da76e09 ]
A timing hazard exists when the network interface is stopped that
allows a watchdog timeout to be processed by a separate core in
parallel. This creates the potential for the timeout handler to
wake the queues while the driver is shutting down, or access
registers after their clocks have been removed.
The more common case is that the watchdog timeout will produce a
warning message which doesn't lead to a crash. The chances of this
are greatly increased by the fact that bcmgenet_netif_stop stops
the transmit queues which can easily precipitate a watchdog time-
out because of stale trans_start data in the queues.
This commit corrects the behavior by ensuring that the watchdog
timeout is disabled before enterring bcmgenet_netif_stop. There
are currently only two users of the bcmgenet_netif_stop function:
close and suspend.
The close case already handles the issue by exiting the RUNNING
state before invoking the driver close service.
The suspend case now performs the netif_device_detach to exit the
PRESENT state before the call to bcmgenet_netif_stop rather than
after it.
These behaviors prevent any future scheduling of the driver timeout
service during the window. The netif_tx_stop_all_queues function
in bcmgenet_netif_stop is replaced with netif_tx_disable to ensure
synchronization with any transmit or timeout threads that may
already be executing on other cores.
For symmetry, the netif_device_attach call upon resume is moved to
after the call to bcmgenet_netif_start. Since it wakes the transmit
queues it is not necessary to invoke netif_tx_start_all_queues from
bcmgenet_netif_start so it is moved into the driver open service.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 20c1681bb1af..2d6f090bf644 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2855,7 +2855,6 @@ static void bcmgenet_netif_start(struct net_device *dev)
umac_enable_set(priv, CMD_TX_EN | CMD_RX_EN, true);
- netif_tx_start_all_queues(dev);
bcmgenet_enable_tx_napi(priv);
/* Monitor link interrupts now */
@@ -2937,6 +2936,8 @@ static int bcmgenet_open(struct net_device *dev)
bcmgenet_netif_start(dev);
+ netif_tx_start_all_queues(dev);
+
return 0;
err_irq1:
@@ -2958,7 +2959,7 @@ static void bcmgenet_netif_stop(struct net_device *dev)
struct bcmgenet_priv *priv = netdev_priv(dev);
bcmgenet_disable_tx_napi(priv);
- netif_tx_stop_all_queues(dev);
+ netif_tx_disable(dev);
/* Disable MAC receive */
umac_enable_set(priv, CMD_RX_EN, false);
@@ -3620,13 +3621,13 @@ static int bcmgenet_suspend(struct device *d)
if (!netif_running(dev))
return 0;
+ netif_device_detach(dev);
+
bcmgenet_netif_stop(dev);
if (!device_may_wakeup(d))
phy_suspend(dev->phydev);
- netif_device_detach(dev);
-
/* Prepare the device for Wake-on-LAN and switch to the slow clock */
if (device_may_wakeup(d) && priv->wolopts) {
ret = bcmgenet_power_down(priv, GENET_POWER_WOL_MAGIC);
@@ -3700,8 +3701,6 @@ static int bcmgenet_resume(struct device *d)
/* Always enable ring 16 - descriptor ring */
bcmgenet_enable_dma(priv, dma_ctrl);
- netif_device_attach(dev);
-
if (!device_may_wakeup(d))
phy_resume(dev->phydev);
@@ -3710,6 +3709,8 @@ static int bcmgenet_resume(struct device *d)
bcmgenet_netif_start(dev);
+ netif_device_attach(dev);
+
return 0;
out_clk_disable:
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 02/27] netfilter: ipset: list:set: Decrease refcount synchronously on deletion and replace
From: Sasha Levin @ 2018-11-14 22:24 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Stefano Brivio, Jozsef Kadlecsik, Pablo Neira Ayuso, Sasha Levin,
netfilter-devel, coreteam, netdev
In-Reply-To: <20181114222520.99926-1-sashal@kernel.org>
From: Stefano Brivio <sbrivio@redhat.com>
[ Upstream commit 439cd39ea136d2c026805264d58a91f36b6b64ca ]
Commit 45040978c899 ("netfilter: ipset: Fix set:list type crash
when flush/dump set in parallel") postponed decreasing set
reference counters to the RCU callback.
An 'ipset del' command can terminate before the RCU grace period
is elapsed, and if sets are listed before then, the reference
counter shown in userspace will be wrong:
# ipset create h hash:ip; ipset create l list:set; ipset add l
# ipset del l h; ipset list h
Name: h
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 88
References: 1
Number of entries: 0
Members:
# sleep 1; ipset list h
Name: h
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 88
References: 0
Number of entries: 0
Members:
Fix this by making the reference count update synchronous again.
As a result, when sets are listed, ip_set_name_byindex() might
now fetch a set whose reference count is already zero. Instead
of relying on the reference count to protect against concurrent
set renaming, grab ip_set_ref_lock as reader and copy the name,
while holding the same lock in ip_set_rename() as writer
instead.
Reported-by: Li Shuang <shuali@redhat.com>
Fixes: 45040978c899 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/netfilter/ipset/ip_set.h | 2 +-
net/netfilter/ipset/ip_set_core.c | 23 +++++++++++------------
net/netfilter/ipset/ip_set_list_set.c | 17 +++++++++++------
3 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/include/linux/netfilter/ipset/ip_set.h b/include/linux/netfilter/ipset/ip_set.h
index 8e42253e5d4d..91a533bd3eb1 100644
--- a/include/linux/netfilter/ipset/ip_set.h
+++ b/include/linux/netfilter/ipset/ip_set.h
@@ -312,7 +312,7 @@ enum {
extern ip_set_id_t ip_set_get_byname(struct net *net,
const char *name, struct ip_set **set);
extern void ip_set_put_byindex(struct net *net, ip_set_id_t index);
-extern const char *ip_set_name_byindex(struct net *net, ip_set_id_t index);
+extern void ip_set_name_byindex(struct net *net, ip_set_id_t index, char *name);
extern ip_set_id_t ip_set_nfnl_get_byindex(struct net *net, ip_set_id_t index);
extern void ip_set_nfnl_put(struct net *net, ip_set_id_t index);
diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
index 9d2ce1459cec..a3f1dc7cf538 100644
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -668,21 +668,20 @@ ip_set_put_byindex(struct net *net, ip_set_id_t index)
EXPORT_SYMBOL_GPL(ip_set_put_byindex);
/* Get the name of a set behind a set index.
- * We assume the set is referenced, so it does exist and
- * can't be destroyed. The set cannot be renamed due to
- * the referencing either.
- *
+ * Set itself is protected by RCU, but its name isn't: to protect against
+ * renaming, grab ip_set_ref_lock as reader (see ip_set_rename()) and copy the
+ * name.
*/
-const char *
-ip_set_name_byindex(struct net *net, ip_set_id_t index)
+void
+ip_set_name_byindex(struct net *net, ip_set_id_t index, char *name)
{
- const struct ip_set *set = ip_set_rcu_get(net, index);
+ struct ip_set *set = ip_set_rcu_get(net, index);
BUG_ON(!set);
- BUG_ON(set->ref == 0);
- /* Referenced, so it's safe */
- return set->name;
+ read_lock_bh(&ip_set_ref_lock);
+ strncpy(name, set->name, IPSET_MAXNAMELEN);
+ read_unlock_bh(&ip_set_ref_lock);
}
EXPORT_SYMBOL_GPL(ip_set_name_byindex);
@@ -1128,7 +1127,7 @@ static int ip_set_rename(struct net *net, struct sock *ctnl,
if (!set)
return -ENOENT;
- read_lock_bh(&ip_set_ref_lock);
+ write_lock_bh(&ip_set_ref_lock);
if (set->ref != 0) {
ret = -IPSET_ERR_REFERENCED;
goto out;
@@ -1145,7 +1144,7 @@ static int ip_set_rename(struct net *net, struct sock *ctnl,
strncpy(set->name, name2, IPSET_MAXNAMELEN);
out:
- read_unlock_bh(&ip_set_ref_lock);
+ write_unlock_bh(&ip_set_ref_lock);
return ret;
}
diff --git a/net/netfilter/ipset/ip_set_list_set.c b/net/netfilter/ipset/ip_set_list_set.c
index 178d4eba013b..75d52aed6fdb 100644
--- a/net/netfilter/ipset/ip_set_list_set.c
+++ b/net/netfilter/ipset/ip_set_list_set.c
@@ -156,9 +156,7 @@ __list_set_del_rcu(struct rcu_head * rcu)
{
struct set_elem *e = container_of(rcu, struct set_elem, rcu);
struct ip_set *set = e->set;
- struct list_set *map = set->data;
- ip_set_put_byindex(map->net, e->id);
ip_set_ext_destroy(set, e);
kfree(e);
}
@@ -166,15 +164,21 @@ __list_set_del_rcu(struct rcu_head * rcu)
static inline void
list_set_del(struct ip_set *set, struct set_elem *e)
{
+ struct list_set *map = set->data;
+
set->elements--;
list_del_rcu(&e->list);
+ ip_set_put_byindex(map->net, e->id);
call_rcu(&e->rcu, __list_set_del_rcu);
}
static inline void
-list_set_replace(struct set_elem *e, struct set_elem *old)
+list_set_replace(struct ip_set *set, struct set_elem *e, struct set_elem *old)
{
+ struct list_set *map = set->data;
+
list_replace_rcu(&old->list, &e->list);
+ ip_set_put_byindex(map->net, old->id);
call_rcu(&old->rcu, __list_set_del_rcu);
}
@@ -306,7 +310,7 @@ list_set_uadd(struct ip_set *set, void *value, const struct ip_set_ext *ext,
INIT_LIST_HEAD(&e->list);
list_set_init_extensions(set, ext, e);
if (n)
- list_set_replace(e, n);
+ list_set_replace(set, e, n);
else if (next)
list_add_tail_rcu(&e->list, &next->list);
else if (prev)
@@ -497,6 +501,7 @@ list_set_list(const struct ip_set *set,
const struct list_set *map = set->data;
struct nlattr *atd, *nested;
u32 i = 0, first = cb->args[IPSET_CB_ARG0];
+ char name[IPSET_MAXNAMELEN];
struct set_elem *e;
int ret = 0;
@@ -515,8 +520,8 @@ list_set_list(const struct ip_set *set,
nested = ipset_nest_start(skb, IPSET_ATTR_DATA);
if (!nested)
goto nla_put_failure;
- if (nla_put_string(skb, IPSET_ATTR_NAME,
- ip_set_name_byindex(map->net, e->id)))
+ ip_set_name_byindex(map->net, e->id, name);
+ if (nla_put_string(skb, IPSET_ATTR_NAME, name))
goto nla_put_failure;
if (ip_set_put_extensions(skb, set, e, true))
goto nla_put_failure;
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 07/27] net: systemport: Protect stop from timeout
From: Sasha Levin @ 2018-11-14 22:24 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Florian Fainelli, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181114222520.99926-1-sashal@kernel.org>
From: Florian Fainelli <f.fainelli@gmail.com>
[ Upstream commit 7cb6a2a2c72c1ed8f42fb01f1a661281b568dead ]
A timing hazard exists when the network interface is stopped that
allows a watchdog timeout to be processed by a separate core in
parallel. This creates the potential for the timeout handler to
wake the queues while the driver is shutting down, or access
registers after their clocks have been removed.
The more common case is that the watchdog timeout will produce a
warning message which doesn't lead to a crash. The chances of this
are greatly increased by the fact that bcm_sysport_netif_stop stops
the transmit queues which can easily precipitate a watchdog time-
out because of stale trans_start data in the queues.
This commit corrects the behavior by ensuring that the watchdog
timeout is disabled before enterring bcm_sysport_netif_stop. There
are currently only two users of the bcm_sysport_netif_stop function:
close and suspend.
The close case already handles the issue by exiting the RUNNING
state before invoking the driver close service.
The suspend case now performs the netif_device_detach to exit the
PRESENT state before the call to bcm_sysport_netif_stop rather than
after it.
These behaviors prevent any future scheduling of the driver timeout
service during the window. The netif_tx_stop_all_queues function
in bcm_sysport_netif_stop is replaced with netif_tx_disable to ensure
synchronization with any transmit or timeout threads that may
already be executing on other cores.
For symmetry, the netif_device_attach call upon resume is moved to
after the call to bcm_sysport_netif_start. Since it wakes the transmit
queues it is not necessary to invoke netif_tx_start_all_queues from
bcm_sysport_netif_start so it is moved into the driver open service.
Fixes: 40755a0fce17 ("net: systemport: add suspend and resume support")
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 6e7f9a470ea1..45462557e51c 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1774,9 +1774,6 @@ static void bcm_sysport_netif_start(struct net_device *dev)
intrl2_1_mask_clear(priv, 0xffffffff);
else
intrl2_0_mask_clear(priv, INTRL2_0_TDMA_MBDONE_MASK);
-
- /* Last call before we start the real business */
- netif_tx_start_all_queues(dev);
}
static void rbuf_init(struct bcm_sysport_priv *priv)
@@ -1922,6 +1919,8 @@ static int bcm_sysport_open(struct net_device *dev)
bcm_sysport_netif_start(dev);
+ netif_tx_start_all_queues(dev);
+
return 0;
out_clear_rx_int:
@@ -1945,7 +1944,7 @@ static void bcm_sysport_netif_stop(struct net_device *dev)
struct bcm_sysport_priv *priv = netdev_priv(dev);
/* stop all software from updating hardware */
- netif_tx_stop_all_queues(dev);
+ netif_tx_disable(dev);
napi_disable(&priv->napi);
phy_stop(dev->phydev);
@@ -2267,12 +2266,12 @@ static int bcm_sysport_suspend(struct device *d)
if (!netif_running(dev))
return 0;
+ netif_device_detach(dev);
+
bcm_sysport_netif_stop(dev);
phy_suspend(dev->phydev);
- netif_device_detach(dev);
-
/* Disable UniMAC RX */
umac_enable_set(priv, CMD_RX_EN, 0);
@@ -2356,8 +2355,6 @@ static int bcm_sysport_resume(struct device *d)
goto out_free_rx_ring;
}
- netif_device_attach(dev);
-
/* RX pipe enable */
topctrl_writel(priv, 0, RX_FLUSH_CNTL);
@@ -2402,6 +2399,8 @@ static int bcm_sysport_resume(struct device *d)
bcm_sysport_netif_start(dev);
+ netif_device_attach(dev);
+
return 0;
out_free_rx_ring:
--
2.17.1
^ permalink raw reply related
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 8:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181115025622-mutt-send-email-mst@kernel.org>
On 2018/11/15 16:10, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
>> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
>>> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>>
>>> I'm not sure I get the motivation. Which features of
>>> virtio net are relevant to vsock? The ones that you mention
>>> all seem to be mostly of use to the networking stack.
>>>
>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity. :(
>>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>
>>> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>>>
>>
>> Hi Michael,
>>
>> Yes, currently vsock has poor performance, first, it only support transport
>> small packet, in order to make the balance between performance and guest memory.
>>
>> In order to solve this problem, there are two features vsock can used,
>> mergeable rx buffer and multiqueue. Based on this, there are some shared
>> codes vsock can use.
>>
>> Thanks,
>> Yiwen.
>
> Supporting more queues with vsock is probably significantly
> less work than a completely new interface.
> For mergeable, as buffers are split arbitrarily, why can't you combine
> them within guest driver before sending them up the stack?
> Probably better than relying on host to do it.
>
Actually, I want to said the mergeable *rx* buffer, it cause the
default packet size of vsock is set to 4k. For tx buffer, it is
actually can be scattered in tx vq only need to modify very few codes.
In addition, I has already first version about vsock support mergeable
rx buffer and send patch to the VSOCK community, these codes are
revisited from virtio-net, and some codes are duplicated. Based on
this, we want to use virtio-net as transport of vsock. It can make
the vsock code easy to maintained.
Thanks.
>>>> +---------------------------------+
>>>> | Vsock header |
>>>> | (struct virtio_vsock_hdr) |
>>>> +---------------------------------+
>>>> | payload |
>>>> | (until end of packet) |
>>>> +---------------------------------+
>>>
>>> Thanks,
>>>
>>
>
> .
>
^ permalink raw reply
* re: xfrm: policy: add inexact policy search tree infrastructure
From: Colin Ian King @ 2018-11-14 22:26 UTC (permalink / raw)
To: Florian Westphal
Cc: Steffen Klassert, Herbert Xu, David S. Miller,
netdev@vger.kernel.org
Hi,
Static analysis with CoverityScan found a potential issue with the commit:
commit 6be3b0db6db82cf056a72cc18042048edd27f8ee
Author: Florian Westphal <fw@strlen.de>
Date: Wed Nov 7 23:00:37 2018 +0100
xfrm: policy: add inexact policy search tree infrastructure
It seems that pointer pol is set to NULL and then a check to see if it
is non-null is used to set pol to tmp; howeverm this check is always
going to be false because pol is always NULL.
The issue is reported by CoverityScan as follows:
Line
1658
assignment: Assigning: pol = NULL.
1659 pol = NULL;
1660 for (i = 0; i < ARRAY_SIZE(cand.res); i++) {
1661 struct xfrm_policy *tmp;
1662
1663 tmp = __xfrm_policy_bysel_ctx(cand.res[i], mark,
1664 if_id, type, dir,
1665 sel, ctx);
null: At condition pol, the value of pol must be NULL.
dead_error_condition: The condition pol cannot be true.
CID 1475480 (#1 of 1): Logically dead code
(DEADCODE) dead_error_line: Execution cannot reach the expression
tmp->pos < pol->pos inside this statement: if (tmp && pol && tmp->pos ....
1666 if (tmp && pol && tmp->pos < pol->pos)
1667 pol = tmp;
1668 }
I suspect this is not intentional and is probably a bug.
Colin
^ permalink raw reply
* Re: xfrm: policy: add inexact policy search tree infrastructure
From: Florian Westphal @ 2018-11-14 22:44 UTC (permalink / raw)
To: Colin Ian King
Cc: Florian Westphal, Steffen Klassert, Herbert Xu, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <f09a304d-54b3-b781-ec4c-e06dd3b3c7b6@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> Hi,
>
> Static analysis with CoverityScan found a potential issue with the commit:
>
> commit 6be3b0db6db82cf056a72cc18042048edd27f8ee
> Author: Florian Westphal <fw@strlen.de>
> Date: Wed Nov 7 23:00:37 2018 +0100
>
> xfrm: policy: add inexact policy search tree infrastructure
>
> It seems that pointer pol is set to NULL and then a check to see if it
> is non-null is used to set pol to tmp; howeverm this check is always
> going to be false because pol is always NULL.
Right. This is in the control-plane code to retrieve a policy
via netlink or PF_KEY.
> The issue is reported by CoverityScan as follows:
>
> Line
> 1658
> assignment: Assigning: pol = NULL.
> 1659 pol = NULL;
> 1660 for (i = 0; i < ARRAY_SIZE(cand.res); i++) {
> 1661 struct xfrm_policy *tmp;
> 1662
> 1663 tmp = __xfrm_policy_bysel_ctx(cand.res[i], mark,
> 1664 if_id, type, dir,
> 1665 sel, ctx);
>
> null: At condition pol, the value of pol must be NULL.
> dead_error_condition: The condition pol cannot be true.
>
> CID 1475480 (#1 of 1): Logically dead code
>
> (DEADCODE) dead_error_line: Execution cannot reach the expression
> tmp->pos < pol->pos inside this statement: if (tmp && pol && tmp->pos ....
>
> 1666 if (tmp && pol && tmp->pos < pol->pos)
> 1667 pol = tmp;
>
>
> I suspect this is not intentional and is probably a bug.
Right, bug. Would like to just break after first 'tmp != NULL' but
that might make us return a different policy than old linear search.
So we should update pol in case its NULL as well.
Steffen, let me know if you want an incremental fix or if you
prefer to squash this:
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1663,7 +1663,10 @@ struct xfrm_policy *xfrm_policy_bysel_ctx(struct net *net, u32 mark, u32 if_id,
tmp = __xfrm_policy_bysel_ctx(cand.res[i], mark,
if_id, type, dir,
sel, ctx);
- if (tmp && pol && tmp->pos < pol->pos)
+ if (!tmp)
+ continue;
+
+ if (!pol || tmp->pos < pol->pol)
pol = tmp;
}
} else {
^ permalink raw reply
* Re: [PATCH v2 net-next 06/21] net: usb: aqc111: Introduce link management
From: Florian Fainelli @ 2018-11-14 22:53 UTC (permalink / raw)
To: Andrew Lunn, Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181114211643.GF32305@lunn.ch>
On 11/14/18 1:16 PM, Andrew Lunn wrote:
>>> Thats again because of this product has tightly integrated MAC+Phy.
>>> MAC FW controls system interface and reports/alters link state
>>> as a joint state on copper and SIF (even in dpa direct phy mode).
>>>
>>> We can't extract phy api into a standalone fully functional phylib therefore.
>>> Also as far as I know this particular phy is not available in the wild.
>>
>> So the point is that MAC firmware is managing SERDES and system interface link.
>
> Linux can manage that SERDES link between the MAC and the PHY. There
> are two ways this can go:
>
> 1) You use phylib. When the PHY reports link, the adjust_link callback
> in the MAC is called. The phydev structure contains information about
> how you should configure the SERDES, SGMII, 2500Base-X, 5000Base-X. It
> works, but it is not so nice.
>
> 2) phylink gives you a much nicer API to do the same. Again, the PHY
> reports the link is up. phylink will then tell the MAC how to
> configure its end of the SERDES. The problem with phylink is that it
> expects a DT building. You don't have that, since this is a USB
> device. But you also don't need a lot of the features of phylink like
> SFPs, the i2c bus for the SFPs, GPIOs etc. So it should not be to hard
> to make this work without device tree.
>
> By using core linux code, we avoid bugs in firmware which nobody can
> fix. The Linux core code should be well tested and supported, but
> phylink is rather new, so might still have some corner cases.
>
> I also cannot imaging parts of the PHY driver will not be re-usable
> for other Aquantia PHYs. I have a board with an AQCS109 under my desk
> waiting for me to do something with it. I really would like a better
> PHY driver for it than the kernel currently has. Hopefully there is
> some code reuse possibilities here.
Even if the firmware is helping, there is still value in using PHYLINK
to report things to Linux as Andrew is saying in that you get a lot of
things for free: auto-negotiation results, link_ksetttings_{get,set} etc.
--
Florian
^ permalink raw reply
* [net-next 04/14] i40e: Replace strncpy with strlcpy to ensure null termination
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Patryk Małek, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181114231032.4013-1-jeffrey.t.kirsher@intel.com>
From: Patryk Małek <patryk.malek@intel.com>
Using strncpy allows destination buffer to be not null terminated
after the copying takes place. strlcpy ensures that's not the
case by explicitly setting last element in the buffer as '\0'.
Signed-off-by: Patryk Małek <patryk.malek@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 14 +++++++-------
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 7e4c07227832..b6f4ebb4557e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14301,23 +14301,23 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
switch (hw->bus.speed) {
case i40e_bus_speed_8000:
- strncpy(speed, "8.0", PCI_SPEED_SIZE); break;
+ strlcpy(speed, "8.0", PCI_SPEED_SIZE); break;
case i40e_bus_speed_5000:
- strncpy(speed, "5.0", PCI_SPEED_SIZE); break;
+ strlcpy(speed, "5.0", PCI_SPEED_SIZE); break;
case i40e_bus_speed_2500:
- strncpy(speed, "2.5", PCI_SPEED_SIZE); break;
+ strlcpy(speed, "2.5", PCI_SPEED_SIZE); break;
default:
break;
}
switch (hw->bus.width) {
case i40e_bus_width_pcie_x8:
- strncpy(width, "8", PCI_WIDTH_SIZE); break;
+ strlcpy(width, "8", PCI_WIDTH_SIZE); break;
case i40e_bus_width_pcie_x4:
- strncpy(width, "4", PCI_WIDTH_SIZE); break;
+ strlcpy(width, "4", PCI_WIDTH_SIZE); break;
case i40e_bus_width_pcie_x2:
- strncpy(width, "2", PCI_WIDTH_SIZE); break;
+ strlcpy(width, "2", PCI_WIDTH_SIZE); break;
case i40e_bus_width_pcie_x1:
- strncpy(width, "1", PCI_WIDTH_SIZE); break;
+ strlcpy(width, "1", PCI_WIDTH_SIZE); break;
default:
break;
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
index 1199f0502d6d..e6fc0aff8c99 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
@@ -694,7 +694,7 @@ static long i40e_ptp_create_clock(struct i40e_pf *pf)
if (!IS_ERR_OR_NULL(pf->ptp_clock))
return 0;
- strncpy(pf->ptp_caps.name, i40e_driver_name,
+ strlcpy(pf->ptp_caps.name, i40e_driver_name,
sizeof(pf->ptp_caps.name) - 1);
pf->ptp_caps.owner = THIS_MODULE;
pf->ptp_caps.max_adj = 999999999;
--
2.19.1
^ permalink raw reply related
* [net-next 03/14] i40e: Add capability flag for stopping FW LLDP
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Krzysztof Galazka, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181114231032.4013-1-jeffrey.t.kirsher@intel.com>
From: Krzysztof Galazka <krzysztof.galazka@intel.com>
Add HW capability flag to indicate that firmware supports stopping
LLDP agent. This feature has been added in FW API 1.7 for XL710
devices and 1.6 for X722. Also raise expected minor version number
for X722 FW API to 6.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 6 ++++++
drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h | 4 +++-
drivers/net/ethernet/intel/i40e/i40e_type.h | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.c b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
index 501ee718177f..7ab61f6ebb5f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
@@ -588,6 +588,12 @@ i40e_status i40e_init_adminq(struct i40e_hw *hw)
hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
hw->aq.api_min_ver >= I40E_MINOR_VER_GET_LINK_INFO_XL710) {
hw->flags |= I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE;
+ hw->flags |= I40E_HW_FLAG_FW_LLDP_STOPPABLE;
+ }
+ if (hw->mac.type == I40E_MAC_X722 &&
+ hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
+ hw->aq.api_min_ver >= I40E_MINOR_VER_FW_LLDP_STOPPABLE_X722) {
+ hw->flags |= I40E_HW_FLAG_FW_LLDP_STOPPABLE;
}
/* Newer versions of firmware require lock when reading the NVM */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
index 80e3eec6134e..11506102471c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
@@ -11,7 +11,7 @@
*/
#define I40E_FW_API_VERSION_MAJOR 0x0001
-#define I40E_FW_API_VERSION_MINOR_X722 0x0005
+#define I40E_FW_API_VERSION_MINOR_X722 0x0006
#define I40E_FW_API_VERSION_MINOR_X710 0x0007
#define I40E_FW_MINOR_VERSION(_h) ((_h)->mac.type == I40E_MAC_XL710 ? \
@@ -20,6 +20,8 @@
/* API version 1.7 implements additional link and PHY-specific APIs */
#define I40E_MINOR_VER_GET_LINK_INFO_XL710 0x0007
+/* API version 1.6 for X722 devices adds ability to stop FW LLDP agent */
+#define I40E_MINOR_VER_FW_LLDP_STOPPABLE_X722 0x0006
struct i40e_aq_desc {
__le16 flags;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h
index 7df969c59855..2781ab91ca82 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_type.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
@@ -615,6 +615,7 @@ struct i40e_hw {
#define I40E_HW_FLAG_802_1AD_CAPABLE BIT_ULL(1)
#define I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE BIT_ULL(2)
#define I40E_HW_FLAG_NVM_READ_REQUIRES_LOCK BIT_ULL(3)
+#define I40E_HW_FLAG_FW_LLDP_STOPPABLE BIT_ULL(4)
u64 flags;
/* Used in set switch config AQ command */
--
2.19.1
^ permalink raw reply related
* [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2018-11-14
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to i40e and virtchnl.
Lance Roy updates i40e to use lockdep_assert_held() instead of
spin_is_locked(), since it is better suited to check locking
requirements.
Jan improves the code readability in XDP by adding the use of a local
variable. Provides protection on methods that create/modify/destroy
VF's via locking mechanism to prevent unstable behaviour and potential
kernel panics.
Krzysztof adds a hardware capability flag to indicate whether firmware
supports stopping the LLDP agent.
Patryk replaces the use of strncpy() with strlcpy() to ensure the buffer
is NULL terminated.
Mitch fixes the issue of trying to start nway on devices that do not
support auto-negotiation, by checking the autoneg state before
attempting to restart nway.
Alice updates virtchnl to keep the checks all together for ease of
readability and consistency. Also fixed a "off by one" error in the
number of traffic classes being calculated.
Richard fixed VF port VLANs, where the priority bits were incorrectly
set because the incorrect shift and mask bits were being used.
Alan adds a bit to set and check if a timeout recovery is already
pending to prevent overlapping transmit timeout recovery.
The following are changes since commit 15cef30974c5f8b256008beb62dcbf15792b77a9:
Merge branch 'aquantia-add-rx-flow-filter-support'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Alan Brady (1):
i40e: prevent overlapping tx_timeout recover
Alice Michael (3):
i40e: update driver version
virtchnl: white space and reorder
virtchnl: Fix off by one error
Jacob Keller (1):
i40e: always set ks->base.speed in i40e_get_settings_link_up
Jan Sokolowski (2):
i40e: Use a local variable for readability
i40e: Protect access to VF control methods
Krzysztof Galazka (1):
i40e: Add capability flag for stopping FW LLDP
Lance Roy (1):
i40e: Replace spin_is_locked() with lockdep
Mitch Williams (2):
i40e: don't restart nway if autoneg not supported
i40e: suppress bogus error message
Patryk Małek (2):
i40e: Replace strncpy with strlcpy to ensure null termination
i40e: Allow disabling FW LLDP on X722 devices
Richard Rodriguez (1):
i40e: Use correct shift for VLAN priority
drivers/net/ethernet/intel/i40e/i40e.h | 3 +-
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 6 ++
.../net/ethernet/intel/i40e/i40e_adminq_cmd.h | 4 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 3 +
.../net/ethernet/intel/i40e/i40e_ethtool.c | 24 ++++---
drivers/net/ethernet/intel/i40e/i40e_main.c | 41 ++++++------
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 4 +-
drivers/net/ethernet/intel/i40e/i40e_type.h | 1 +
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 67 +++++++++++++++++--
.../ethernet/intel/i40e/i40e_virtchnl_pf.h | 4 +-
include/linux/avf/virtchnl.h | 10 +--
12 files changed, 121 insertions(+), 48 deletions(-)
--
2.19.1
^ permalink raw reply
* [net-next 01/14] i40e: Replace spin_is_locked() with lockdep
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Lance Roy, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181114231032.4013-1-jeffrey.t.kirsher@intel.com>
From: Lance Roy <ldr709@gmail.com>
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy <ldr709@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 21c2688d6308..7e4c07227832 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1493,8 +1493,7 @@ int i40e_del_mac_filter(struct i40e_vsi *vsi, const u8 *macaddr)
bool found = false;
int bkt;
- WARN(!spin_is_locked(&vsi->mac_filter_hash_lock),
- "Missing mac_filter_hash_lock\n");
+ lockdep_assert_held(&vsi->mac_filter_hash_lock);
hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist) {
if (ether_addr_equal(macaddr, f->macaddr)) {
__i40e_del_filter(vsi, f);
--
2.19.1
^ permalink raw reply related
* [net-next 02/14] i40e: Use a local variable for readability
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Jan Sokolowski, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181114231032.4013-1-jeffrey.t.kirsher@intel.com>
From: Jan Sokolowski <jan.sokolowski@intel.com>
Use a local variable to make the code a bit more readable.
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 1384a5a006a4..c4d44096cdaf 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -3528,6 +3528,7 @@ static int i40e_xmit_xdp_ring(struct xdp_frame *xdpf,
u16 i = xdp_ring->next_to_use;
struct i40e_tx_buffer *tx_bi;
struct i40e_tx_desc *tx_desc;
+ void *data = xdpf->data;
u32 size = xdpf->len;
dma_addr_t dma;
@@ -3535,8 +3536,7 @@ static int i40e_xmit_xdp_ring(struct xdp_frame *xdpf,
xdp_ring->tx_stats.tx_busy++;
return I40E_XDP_CONSUMED;
}
-
- dma = dma_map_single(xdp_ring->dev, xdpf->data, size, DMA_TO_DEVICE);
+ dma = dma_map_single(xdp_ring->dev, data, size, DMA_TO_DEVICE);
if (dma_mapping_error(xdp_ring->dev, dma))
return I40E_XDP_CONSUMED;
--
2.19.1
^ permalink raw reply related
* [net-next 09/14] i40e: always set ks->base.speed in i40e_get_settings_link_up
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181114231032.4013-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
In i40e_get_settings_link_up, set ks->base.speed to SPEED_UNKNOWN
in the case where we don't know the link speed.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1ed241a5c3f4..a6bc7847346b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -906,6 +906,7 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
ks->base.speed = SPEED_100;
break;
default:
+ ks->base.speed = SPEED_UNKNOWN;
break;
}
ks->base.duplex = DUPLEX_FULL;
--
2.19.1
^ permalink raw reply related
* [net-next 06/14] i40e: update driver version
From: Jeff Kirsher @ 2018-11-14 23:10 UTC (permalink / raw)
To: davem; +Cc: Alice Michael, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181114231032.4013-1-jeffrey.t.kirsher@intel.com>
From: Alice Michael <alice.michael@intel.com>
The version numbers have not been kept up to date and this is
an effort to ammend that.
Signed-off-by: Alice Michael <alice.michael@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index b6f4ebb4557e..dbd6fffd9b85 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -26,8 +26,8 @@ static const char i40e_driver_string[] =
#define DRV_KERN "-k"
#define DRV_VERSION_MAJOR 2
-#define DRV_VERSION_MINOR 3
-#define DRV_VERSION_BUILD 2
+#define DRV_VERSION_MINOR 7
+#define DRV_VERSION_BUILD 6
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
--
2.19.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox