All of lore.kernel.org
 help / color / mirror / Atom feed
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: Jason Wang <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [PATCH net 5/7] virtio_net: Don't process redirected XDP frames when XDP is disabled
Date: Fri, 18 Jan 2019 13:02:01 +0900	[thread overview]
Message-ID: <deacbf4d-48da-56a7-d547-f2399c562846@lab.ntt.co.jp> (raw)
In-Reply-To: <cf705fbb-d2cf-95d1-680a-739fa3652b6b@redhat.com>

On 2019/01/18 12:52, Jason Wang wrote:
> On 2019/1/18 上午9:56, Toshiaki Makita wrote:
>> On 2019/01/17 22:05, Jason Wang wrote:
>>> On 2019/1/17 下午8:53, Jason Wang wrote:
>>>> On 2019/1/17 下午7:20, Toshiaki Makita wrote:
>>>>> Commit 8dcc5b0ab0ec ("virtio_net: fix ndo_xdp_xmit crash towards
>>>>> dev not
>>>>> ready for XDP") tried to avoid access to unexpected sq while XDP is
>>>>> disabled, but was not complete.
>>>>>
>>>>> There was a small window which causes out of bounds sq access in
>>>>> virtnet_xdp_xmit() while disabling XDP.
>>>>>
>>>>> An example case of
>>>>>    - curr_queue_pairs = 6 (2 for SKB and 4 for XDP)
>>>>>    - online_cpu_num = xdp_queue_paris = 4
>>>>> when XDP is enabled:
>>>>>
>>>>> CPU 0                         CPU 1
>>>>> (Disabling XDP)               (Processing redirected XDP frames)
>>>>>
>>>>>                                 virtnet_xdp_xmit()
>>>>> virtnet_xdp_set()
>>>>>    _virtnet_set_queues()
>>>>>     set curr_queue_pairs (2)
>>>>>                                  check if rq->xdp_prog is not NULL
>>>>>                                  virtnet_xdp_sq(vi)
>>>>>                                   qp = curr_queue_pairs -
>>>>>                                        xdp_queue_pairs +
>>>>>                                        smp_processor_id()
>>>>>                                      = 2 - 4 + 1 = -1
>>>>>                                   sq = &vi->sq[qp] // out of bounds
>>>>> access
>>>>>     set xdp_queue_pairs (0)
>>>>>     rq->xdp_prog = NULL
>>>>>
>>>>> Basically we should not change curr_queue_pairs and xdp_queue_pairs
>>>>> while someone can read the values. Thus, when disabling XDP, assign
>>>>> NULL
>>>>> to rq->xdp_prog first, and wait for RCU grace period, then change
>>>>> xxx_queue_pairs.
>>>>> Note that we need to keep the current order when enabling XDP though.
>>>>>
>>>>> Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT")
>>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>
>>>> I wonder whether or not we could simply do:
>>>>
>>>>
>>>> if (prog) {
>>>
>>> Should be !prog
>>>
>>>
>>>>      rcu_assign_pointer()
>>>>
>>>>      synchronize_net()
>>>>
>>>> }
>>>>
>>>> set queues
>>>>
>>>> if (!prog) {
>>>
>>> Should be prog.
>> Either would work.
>>
>> With your suggestion the code will look like:
>>
>> ---
>> if (!prog) {
>>     for (...) {
>>         rcu_assign_pointer();
>>         ...
>>     }
>>     synchronize_net();
>> }
>>
>> virtnet_set_queues();
>> netif_set_real_num_rx_queues();
>> vi->xdp_queue_pairs = xdp_qp;
>>
>> if (prog) {
>>     for (...) {
>>         rcu_assign_pointer();
>>         ...
>>     }
>> }
> 
> 
> Yes, I think this makes code more easier to be understand.
> 
> 
>> ---
>>
>> But strictly speaking, virtnet_set_queues() should not be necessary if
>> (prog != NULL && old_prog != NULL).
> 
> 
> Yes, but it was another possible 'issue'.
> 
> 
>> If you prefer this, I can modify it accordingly.
> 
> 
> I prefer to do this change.

OK, will do in v2.

-- 
Toshiaki Makita


  parent reply	other threads:[~2019-01-18  4:02 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 11:20 [PATCH net 0/7] virtio_net: Fix problems around XDP tx and napi_tx Toshiaki Makita
2019-01-17 11:20 ` [PATCH net 1/7] virtio_net: Don't enable NAPI when interface is down Toshiaki Makita
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 12:38   ` Jason Wang
2019-01-17 12:38   ` Jason Wang
2019-01-17 11:20 ` [PATCH net 2/7] virtio_net: Don't call free_old_xmit_skbs for xdp_frames Toshiaki Makita
2019-01-17 12:39   ` Jason Wang
2019-01-17 12:39   ` Jason Wang
2019-01-18  1:44     ` Toshiaki Makita
2019-01-18  1:44     ` Toshiaki Makita
2019-01-18  3:50       ` Jason Wang
2019-01-18  3:50       ` Jason Wang
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 11:20 ` [PATCH net 3/7] virtio_net: Fix not restoring real_num_rx_queues Toshiaki Makita
2019-01-17 12:39   ` Jason Wang
2019-01-17 12:39   ` Jason Wang
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 11:20 ` [PATCH net 4/7] virtio_net: Fix out of bounds access of sq Toshiaki Makita
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 12:42   ` Jason Wang
2019-01-17 12:42   ` Jason Wang
2019-01-17 11:20 ` [PATCH net 5/7] virtio_net: Don't process redirected XDP frames when XDP is disabled Toshiaki Makita
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 12:53   ` Jason Wang
2019-01-17 12:53   ` Jason Wang
2019-01-17 13:05     ` Jason Wang
2019-01-18  1:56       ` Toshiaki Makita
2019-01-18  3:52         ` Jason Wang
2019-01-18  4:02           ` Toshiaki Makita
2019-01-18  4:02           ` Toshiaki Makita [this message]
2019-01-18  3:52         ` Jason Wang
2019-01-18  1:56       ` Toshiaki Makita
2019-01-17 13:05     ` Jason Wang
2019-01-17 11:20 ` [PATCH net 6/7] virtio_net: Use xdp_return_frame to free xdp_frames on destroying vqs Toshiaki Makita
2019-01-17 12:56   ` Jason Wang
2019-01-17 13:39     ` Jesper Dangaard Brouer
2019-01-17 13:39     ` Jesper Dangaard Brouer
2019-01-17 12:56   ` Jason Wang
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 11:20 ` [PATCH net 7/7] virtio_net: Differentiate sk_buff and xdp_frame on freeing Toshiaki Makita
2019-01-17 13:04   ` Jason Wang
2019-01-17 13:04   ` Jason Wang
2019-01-17 11:20 ` Toshiaki Makita
2019-01-17 14:55 ` [PATCH net 0/7] virtio_net: Fix problems around XDP tx and napi_tx Michael S. Tsirkin
2019-01-17 14:55 ` Michael S. Tsirkin
2019-01-18  2:01   ` Toshiaki Makita
2019-01-18  2:01   ` Toshiaki Makita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=deacbf4d-48da-56a7-d547-f2399c562846@lab.ntt.co.jp \
    --to=makita.toshiaki@lab.ntt.co.jp \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.