* Re: [PATCH net V2] ip: frags: fix crash in ip_do_fragment()
From: Taehee Yoo @ 2018-09-09 18:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Peter Oskolkov, netdev, Pablo Neira Ayuso,
Florian Westphal
In-Reply-To: <CANn89i+pBEuH-dg=f+3rxiheQyjJfg2=SqgoRmB4S7VEaVgeow@mail.gmail.com>
2018-09-10 3:24 GMT+09:00 Eric Dumazet <edumazet@google.com>:
> On Sun, Sep 9, 2018 at 10:47 AM Taehee Yoo <ap420073@gmail.com> wrote:
>>
>> A kernel crash occurrs when defragmented packet is fragmented
>> in ip_do_fragment().
>> In defragment routine, skb_orphan() is called and
>> skb->ip_defrag_offset is set. but skb->sk and
>> skb->ip_defrag_offset are same union member. so that
>> frag->sk is not NULL.
>> Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
>> defragmented packet is fragmented.
>>
>> test commands:
>> %iptables -t nat -I POSTROUTING -j MASQUERADE
>> %hping3 192.168.4.2 -s 1000 -p 2000 -d 60000
>>
>> splat looks like:
>>
>> v2:
>> - clear skb->sk at reassembly routine.(Eric Dumarzet)
>>
>> Fixes: fa0f527358bd ("ip: use rb trees for IP frag queue.")
>> Suggested-by: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
>> ---
>> net/ipv4/ip_fragment.c | 1 +
>> net/ipv6/netfilter/nf_conntrack_reasm.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
>> index 88281fbce88c..e7227128df2c 100644
>> --- a/net/ipv4/ip_fragment.c
>> +++ b/net/ipv4/ip_fragment.c
>> @@ -599,6 +599,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
>> nextp = &fp->next;
>> fp->prev = NULL;
>> memset(&fp->rbnode, 0, sizeof(fp->rbnode));
>> + fp->sk = NULL;
>> head->data_len += fp->len;
>> head->len += fp->len;
>> if (head->ip_summed != fp->ip_summed)
>> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
>> index 2a14d8b65924..8f68a518d9db 100644
>> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
>> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
>> @@ -445,6 +445,7 @@ nf_ct_frag6_reasm(struct frag_queue *fq, struct sk_buff *prev, struct net_devic
>> else if (head->ip_summed == CHECKSUM_COMPLETE)
>> head->csum = csum_add(head->csum, fp->csum);
>> head->truesize += fp->truesize;
>> + fp->sk = NULL;
>
> This is not needed. IPv6 paths were not changed by recent commits.
>
>> }
>> sub_frag_mem_limit(fq->q.net, head->truesize);
>>
>> --
>> 2.17.1
>>
Hi Eric,
Thank you for review!
I think netfilter side ipv6 code change is needed
because netfilter ipv6 defrag routine also set fp->ip_defrag_offset value
so that fp->sk will not be NULL.
And I think these crash in ip_do_fragment() and ip6_fragment() are
actually same bug.
My ipv6 test environment is below
PC1<----------------->FW<----------------->PC2
cd::02/64 cd::01/64 ab::01/64 ab::02/64
FW command:
%ip6tables -t nat -I POSTROUTING -j MASQUERADE
PC2 command:
%ping6 cd::02 -s 60000
FW crash message:
[ 502.676552] kernel BUG at net/ipv6/ip6_output.c:658!
[ 502.682641] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 502.683545] CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.19.0-rc2+ #12
[ 502.692231] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
[ 502.692231] RIP: 0010:ip6_fragment+0x16fa/0x3580
[ 502.692231] Code: 45 00 f8 0f 85 c3 03 00 00 49 8d 7f 18 48 89 f8
48 c1 e8 03 42 80 3c 28 00 0f 85 23 18 00 00 49 83 7f 18 00 0f 84 22
fe ff ff <0f> 0b 48 85 c0 0f 85 43 02 00 00 49 83 e6 fe 48 b8 00 00 00
00 00
[ 502.692231] RSP: 0018:ffff88011561eb58 EFLAGS: 00010202
[ 502.692231] RAX: 1ffff1002142e37b RBX: ffff8801062c16c0 RCX: 0000000000000004
[ 502.692231] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88010a171bd8
[ 502.692231] RBP: ffffed0022ac3d89 R08: ffffed002142e395 R09: ffffed002142e395
[ 502.692231] R10: 0000000000000001 R11: ffffed002142e394 R12: 0000000000000028
[ 502.692231] R13: dffffc0000000000 R14: ffff88010a171ca4 R15: ffff88010a171bc0
[ 502.692231] FS: 0000000000000000(0000) GS:ffff880116600000(0000)
knlGS:0000000000000000
[ 502.692231] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 502.692231] CR2: 0000000002452c64 CR3: 0000000105fea000 CR4: 00000000001006e0
[ 502.692231] Call Trace:
[ 502.692231] ? ip6_forward_finish+0x370/0x370
[ 502.692231] ? ip6_forward+0x34e0/0x34e0
[ 502.813859] ? ip6_mtu+0x24d/0x310
[ 502.813859] ? ip6_negative_advice+0x160/0x160
[ 502.813859] ? rcu_is_watching+0x77/0x120
[ 502.813859] ? nf_nat_ipv6_out+0x206/0x4d0 [nf_nat_ipv6]
[ 502.813859] ? ip6_finish_output+0x35e/0x920
[ 502.813859] ip6_output+0x1e5/0x870
[ 502.813859] ? ip6_finish_output+0x920/0x920
[ 502.813859] ? __lock_acquire+0x4500/0x4500
[ 502.813859] ? __nf_nat_alloc_null_binding+0x20c/0x340 [nf_nat]
[ 502.813859] ? ip6_fragment+0x3580/0x3580
[ 502.813859] ip6_forward+0x1328/0x34e0
[ 502.813859] ? nf_nat_inet_fn+0x446/0x970 [nf_nat]
[ 502.813859] ? ip6_autoflowlabel+0xb0/0xb0
[ 502.813859] ? ip6_route_input+0x639/0xc80
[ 502.813859] ? save_trace+0x300/0x300
[ 502.813859] ? ip6_route_info_create+0x35e0/0x35e0
[ 502.813859] ? ip6_rcv_finish_core.isra.10+0x152/0x520
[ 502.813859] ? nf_hook.constprop.19+0x780/0x780
[ 502.813859] ? nf_nat_ipv6_out+0x4d0/0x4d0 [nf_nat_ipv6]
[ 502.813859] ? ipv6_rcv+0x40b/0x500
[ 502.813859] ? ip6_autoflowlabel+0xb0/0xb0
[ 502.813859] ipv6_rcv+0x40b/0x500
[ 502.813859] ? ip6_rcv_core.isra.14+0x1dd0/0x1dd0
[ 502.813859] ? lock_acquire+0x196/0x470
[ 502.813859] ? ip6_rcv_finish_core.isra.10+0x520/0x520
[ 502.813859] ? ip6_rcv_core.isra.14+0x1dd0/0x1dd0
[ 502.813859] __netif_receive_skb_one_core+0x115/0x1a0
[ 502.813859] ? rcu_is_watching+0x77/0x120
[ 502.813859] ? __netif_receive_skb_core+0x2ac0/0x2ac0
[ 502.813859] ? _rcu_barrier_trace+0x400/0x400
[ 502.813859] ? rcu_pm_notify+0xc0/0xc0
[ 502.813859] netif_receive_skb_internal+0xd8/0x570
[ 502.813859] ? dev_cpu_dead+0x980/0x980
[ 502.813859] ? rcu_read_lock_sched_held+0x114/0x130
[ 502.813859] ? kmem_cache_alloc+0x1ea/0x280
[ 502.813859] ? memset+0x1f/0x40
[ 502.813859] ? rcu_pm_notify+0xc0/0xc0
[ 502.813859] napi_gro_receive+0x344/0x410
[ 502.813859] ? dev_gro_receive+0x29b0/0x29b0
[ 502.813859] ? build_skb+0x63/0x2b0
[ 502.813859] ? eth_gro_receive+0x8f0/0x8f0
[ 502.813859] ? __build_skb+0x3b0/0x3b0
[ 502.813859] igb_poll+0x16e1/0x4650
[ 502.813859] ? igb_alloc_rx_buffers+0xa80/0xa80
[ 502.813859] ? sched_clock_cpu+0x126/0x170
[ 502.813859] ? stop_critical_timings+0x420/0x420
[ 502.813859] ? net_rx_action+0x3f0/0x1440
[ 502.813859] ? net_rx_action+0x3f0/0x1440
[ 502.813859] ? rcu_pm_notify+0xc0/0xc0
[ 502.813859] net_rx_action+0x5db/0x1440
[ 502.813859] ? _raw_spin_unlock+0x24/0x30
[ 502.813859] ? napi_complete_done+0x4c0/0x4c0
[ 502.813859] ? pfifo_fast_peek+0x1c0/0x1c0
[ 502.813859] ? cyc2ns_read_end+0x10/0x10
[ 502.813859] ? save_trace+0x300/0x300
[ 502.813859] ? save_trace+0x300/0x300
[ 502.813859] ? sched_clock_cpu+0x126/0x170
[ 502.813859] ? find_held_lock+0x39/0x1c0
[ 502.813859] ? lock_acquire+0x196/0x470
[ 502.813859] ? check_flags.part.36+0x450/0x450
[ 502.813859] ? check_flags.part.36+0x450/0x450
[ 502.813859] ? __run_timers+0x6ff/0x990
[ 502.813859] ? do_raw_spin_unlock+0xa5/0x330
[ 502.813859] ? do_raw_spin_trylock+0x1a0/0x1a0
[ 502.813859] ? do_raw_spin_trylock+0x101/0x1a0
[ 502.813859] ? _raw_spin_unlock+0x24/0x30
[ 502.813859] ? net_tx_action+0x6cb/0xad0
[ 502.813859] ? dev_queue_xmit_nit+0xe70/0xe70
[ 502.813859] ? _raw_spin_unlock_irq+0x31/0x40
[ 502.813859] ? stop_critical_timings+0x420/0x420
[ 502.813859] ? finish_task_switch+0x183/0x740
[ 502.813859] ? __switch_to_asm+0x30/0x60
[ 502.813859] ? __switch_to_asm+0x24/0x60
[ 502.813859] ? __do_softirq+0x263/0xa11
[ 502.813859] ? __do_softirq+0x263/0xa11
[ 502.813859] ? rcu_pm_notify+0xc0/0xc0
[ 502.813859] __do_softirq+0x2a5/0xa11
[ 502.813859] ? __sched_text_start+0x8/0x8
[ 502.813859] ? __irqentry_text_end+0x1fa51c/0x1fa51c
[ 502.813859] ? smpboot_thread_fn+0xd5/0x700
[ 502.813859] ? tracer_hardirqs_on+0x420/0x420
[ 502.813859] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 502.813859] ? run_ksoftirqd+0xb/0x50
[ 502.813859] ? trace_hardirqs_off+0x6b/0x210
[ 502.813859] ? trace_hardirqs_on_caller+0x210/0x210
[ 502.813859] ? takeover_tasklets+0x860/0x860
[ 502.813859] ? takeover_tasklets+0x860/0x860
[ 502.813859] run_ksoftirqd+0x24/0x50
[ 502.813859] smpboot_thread_fn+0x3cd/0x700
[ 502.813859] ? sort_range+0x20/0x20
[ 502.813859] ? __kthread_parkme+0xb6/0x180
[ 502.813859] ? sort_range+0x20/0x20
[ 502.813859] kthread+0x322/0x3e0
[ 502.813859] ? kthread_create_worker_on_cpu+0xc0/0xc0
[ 502.813859] ret_from_fork+0x3a/0x50
[ 502.813859] Modules linked in: ip6t_MASQUERADE ip6table_nat
nf_nat_ipv6 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
ip6_tables ip_tables x_tables
[ 503.279587] ---[ end trace 49127255558e40c3 ]---
[ 503.284881] RIP: 0010:ip6_fragment+0x16fa/0x3580
[ 503.290150] Code: 45 00 f8 0f 85 c3 03 00 00 49 8d 7f 18 48 89 f8
48 c1 e8 03 42 80 3c 28 00 0f 85 23 18 00 00 49 83 7f 18 00 0f 84 22
fe ff ff <0f> 0b 48 85 c0 0f 85 43 02 00 00 49 83 e6 fe 48 b8 00 00 00
00 00
[ 503.311356] RSP: 0018:ffff88011561eb58 EFLAGS: 00010202
[ 503.317328] RAX: 1ffff1002142e37b RBX: ffff8801062c16c0 RCX: 0000000000000004
[ 503.325438] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88010a171bd8
[ 503.333574] RBP: ffffed0022ac3d89 R08: ffffed002142e395 R09: ffffed002142e395
[ 503.341686] R10: 0000000000000001 R11: ffffed002142e394 R12: 0000000000000028
[ 503.349803] R13: dffffc0000000000 R14: ffff88010a171ca4 R15: ffff88010a171bc0
[ 503.357916] FS: 0000000000000000(0000) GS:ffff880116600000(0000)
knlGS:0000000000000000
[ 503.367102] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 503.373642] CR2: 0000000002452c64 CR3: 0000000105fea000 CR4: 00000000001006e0
[ 503.381803] Kernel panic - not syncing: Fatal exception in interrupt
[ 503.382721] Kernel Offset: 0xa000000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 503.382721] Rebooting in 5 seconds..
^ permalink raw reply
* Re: [PATCH net V2] ip: frags: fix crash in ip_do_fragment()
From: Eric Dumazet @ 2018-09-09 18:24 UTC (permalink / raw)
To: Taehee Yoo
Cc: David Miller, Peter Oskolkov, netdev, Pablo Neira Ayuso,
Florian Westphal
In-Reply-To: <20180909174705.3677-1-ap420073@gmail.com>
On Sun, Sep 9, 2018 at 10:47 AM Taehee Yoo <ap420073@gmail.com> wrote:
>
> A kernel crash occurrs when defragmented packet is fragmented
> in ip_do_fragment().
> In defragment routine, skb_orphan() is called and
> skb->ip_defrag_offset is set. but skb->sk and
> skb->ip_defrag_offset are same union member. so that
> frag->sk is not NULL.
> Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
> defragmented packet is fragmented.
>
> test commands:
> %iptables -t nat -I POSTROUTING -j MASQUERADE
> %hping3 192.168.4.2 -s 1000 -p 2000 -d 60000
>
> splat looks like:
>
> v2:
> - clear skb->sk at reassembly routine.(Eric Dumarzet)
>
> Fixes: fa0f527358bd ("ip: use rb trees for IP frag queue.")
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> ---
> net/ipv4/ip_fragment.c | 1 +
> net/ipv6/netfilter/nf_conntrack_reasm.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
> index 88281fbce88c..e7227128df2c 100644
> --- a/net/ipv4/ip_fragment.c
> +++ b/net/ipv4/ip_fragment.c
> @@ -599,6 +599,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
> nextp = &fp->next;
> fp->prev = NULL;
> memset(&fp->rbnode, 0, sizeof(fp->rbnode));
> + fp->sk = NULL;
> head->data_len += fp->len;
> head->len += fp->len;
> if (head->ip_summed != fp->ip_summed)
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index 2a14d8b65924..8f68a518d9db 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -445,6 +445,7 @@ nf_ct_frag6_reasm(struct frag_queue *fq, struct sk_buff *prev, struct net_devic
> else if (head->ip_summed == CHECKSUM_COMPLETE)
> head->csum = csum_add(head->csum, fp->csum);
> head->truesize += fp->truesize;
> + fp->sk = NULL;
This is not needed. IPv6 paths were not changed by recent commits.
> }
> sub_frag_mem_limit(fq->q.net, head->truesize);
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v4 3/3] IB/ipoib: Log sysfs 'dev_id' accesses from userspace
From: Arseny Maslennikov @ 2018-09-09 18:11 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma, Doug Ledford, netdev
In-Reply-To: <20180907154359.GA14627@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]
On Fri, Sep 07, 2018 at 09:43:59AM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 06, 2018 at 05:51:12PM +0300, Arseny Maslennikov wrote:
> > Some tools may currently be using only the deprecated attribute;
> > let's print an elaborate and clear deprecation notice to kmsg.
> >
> > To do that, we have to replace the whole sysfs file, since we inherit
> > the original one from netdev.
> >
> > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > drivers/infiniband/ulp/ipoib/ipoib_main.c | 31 +++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > index 30f840f874b3..74732726ec6f 100644
> > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > @@ -2386,6 +2386,35 @@ int ipoib_add_pkey_attr(struct net_device *dev)
> > return device_create_file(&dev->dev, &dev_attr_pkey);
> > }
> >
> > +/*
> > + * We erroneously exposed the iface's port number in the dev_id
> > + * sysfs field long after dev_port was introduced for that purpose[1],
> > + * and we need to stop everyone from relying on that.
> > + * Let's overload the shower routine for the dev_id file here
> > + * to gently bring the issue up.
> > + *
> > + * [1] https://www.spinics.net/lists/netdev/msg272123.html
> > + */
> > +static ssize_t dev_id_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct net_device *ndev = to_net_dev(dev);
> > +
> > + if (ndev->dev_id == ndev->dev_port)
> > + netdev_info_once(ndev,
> > + "\"%s\" wants to know my dev_id. Should it look at dev_port instead? See Documentation/ABI/testing/sysfs-class-net for more info.\n",
> > + current->comm);
> > +
> > + return sprintf(buf, "%#x\n", ndev->dev_id);
> > +}
> > +static DEVICE_ATTR_RO(dev_id);
> > +
> > +int ipoib_intercept_dev_id_attr(struct net_device *dev)
> > +{
> > + device_remove_file(&dev->dev, &dev_attr_dev_id);
> > + return device_create_file(&dev->dev, &dev_attr_dev_id);
> > +}
>
> Isn't this racey with userspace? Ie what happens if udev is querying
> the dev_id right here?
udev in particular does not use dev_id at all since 2014, because "why
would we keep using dev_id if it is not the right thing to use?".
>
> Do we know there is no userspace doing this?
>
Not for sure.
If we move all the sysfs handling stuff we introduce in _add_port():
- pkey
- umcast
- {create,delete}_child
- connected/datagram mode
to _ndo_init(), which is called by register_netdev before it sends
the netlink message, would that suffice to eliminate the race?
(Sysfs files for {create,delete}_child go to _parent_init() then).
> > static struct net_device *ipoib_add_port(const char *format,
> > struct ib_device *hca, u8 port)
> > {
> > @@ -2427,6 +2456,8 @@ static struct net_device *ipoib_add_port(const char *format,
> > */
> > ndev->priv_destructor = ipoib_intf_free;
> >
> > + if (ipoib_intercept_dev_id_attr(ndev))
> > + goto sysfs_failed;
>
> No device_remove_file needed?
>
As far as I understand, unregister_netdevice takes care of it
while destroying the related kobject.
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net V2] ip: frags: fix crash in ip_do_fragment()
From: Taehee Yoo @ 2018-09-09 17:47 UTC (permalink / raw)
To: davem, posk, netdev; +Cc: ap420073, pablo, fw, edumazet
A kernel crash occurrs when defragmented packet is fragmented
in ip_do_fragment().
In defragment routine, skb_orphan() is called and
skb->ip_defrag_offset is set. but skb->sk and
skb->ip_defrag_offset are same union member. so that
frag->sk is not NULL.
Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
defragmented packet is fragmented.
test commands:
%iptables -t nat -I POSTROUTING -j MASQUERADE
%hping3 192.168.4.2 -s 1000 -p 2000 -d 60000
splat looks like:
[ 261.069429] kernel BUG at net/ipv4/ip_output.c:636!
[ 261.075753] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 261.083854] CPU: 1 PID: 1349 Comm: hping3 Not tainted 4.19.0-rc2+ #3
[ 261.100977] RIP: 0010:ip_do_fragment+0x1613/0x2600
[ 261.106945] Code: e8 e2 38 e3 fe 4c 8b 44 24 18 48 8b 74 24 08 e9 92 f6 ff ff 80 3c 02 00 0f 85 da 07 00 00 48 8b b5 d0 00 00 00 e9 25 f6 ff ff <0f> 0b 0f 0b 44 8b 54 24 58 4c 8b 4c 24 18 4c 8b 5c 24 60 4c 8b 6c
[ 261.127015] RSP: 0018:ffff8801031cf2c0 EFLAGS: 00010202
[ 261.134156] RAX: 1ffff1002297537b RBX: ffffed0020639e6e RCX: 0000000000000004
[ 261.142156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880114ba9bd8
[ 261.150157] RBP: ffff880114ba8a40 R08: ffffed0022975395 R09: ffffed0022975395
[ 261.158157] R10: 0000000000000001 R11: ffffed0022975394 R12: ffff880114ba9ca4
[ 261.166159] R13: 0000000000000010 R14: ffff880114ba9bc0 R15: dffffc0000000000
[ 261.174169] FS: 00007fbae2199700(0000) GS:ffff88011b400000(0000) knlGS:0000000000000000
[ 261.183012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 261.189013] CR2: 00005579244fe000 CR3: 0000000119bf4000 CR4: 00000000001006e0
[ 261.198158] Call Trace:
[ 261.199018] ? dst_output+0x180/0x180
[ 261.205011] ? save_trace+0x300/0x300
[ 261.209018] ? ip_copy_metadata+0xb00/0xb00
[ 261.213034] ? sched_clock_local+0xd4/0x140
[ 261.218158] ? kill_l4proto+0x120/0x120 [nf_conntrack]
[ 261.223014] ? rt_cpu_seq_stop+0x10/0x10
[ 261.227014] ? find_held_lock+0x39/0x1c0
[ 261.233008] ip_finish_output+0x51d/0xb50
[ 261.237006] ? ip_fragment.constprop.56+0x220/0x220
[ 261.243011] ? nf_ct_l4proto_register_one+0x5b0/0x5b0 [nf_conntrack]
[ 261.250152] ? rcu_is_watching+0x77/0x120
[ 261.255010] ? nf_nat_ipv4_out+0x1e/0x2b0 [nf_nat_ipv4]
[ 261.261033] ? nf_hook_slow+0xb1/0x160
[ 261.265007] ip_output+0x1c7/0x710
[ 261.269005] ? ip_mc_output+0x13f0/0x13f0
[ 261.273002] ? __local_bh_enable_ip+0xe9/0x1b0
[ 261.278152] ? ip_fragment.constprop.56+0x220/0x220
[ 261.282996] ? nf_hook_slow+0xb1/0x160
[ 261.287007] raw_sendmsg+0x21f9/0x4420
[ 261.291008] ? dst_output+0x180/0x180
[ 261.297003] ? sched_clock_cpu+0x126/0x170
[ 261.301003] ? find_held_lock+0x39/0x1c0
[ 261.306155] ? stop_critical_timings+0x420/0x420
[ 261.311004] ? check_flags.part.36+0x450/0x450
[ 261.315005] ? _raw_spin_unlock_irq+0x29/0x40
[ 261.320995] ? _raw_spin_unlock_irq+0x29/0x40
[ 261.326142] ? cyc2ns_read_end+0x10/0x10
[ 261.330139] ? raw_bind+0x280/0x280
[ 261.334138] ? sched_clock_cpu+0x126/0x170
[ 261.338995] ? check_flags.part.36+0x450/0x450
[ 261.342991] ? __lock_acquire+0x4500/0x4500
[ 261.348994] ? inet_sendmsg+0x11c/0x500
[ 261.352989] ? dst_output+0x180/0x180
[ 261.357012] inet_sendmsg+0x11c/0x500
[ ... ]
v2:
- clear skb->sk at reassembly routine.(Eric Dumarzet)
Fixes: fa0f527358bd ("ip: use rb trees for IP frag queue.")
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
net/ipv4/ip_fragment.c | 1 +
net/ipv6/netfilter/nf_conntrack_reasm.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 88281fbce88c..e7227128df2c 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -599,6 +599,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
nextp = &fp->next;
fp->prev = NULL;
memset(&fp->rbnode, 0, sizeof(fp->rbnode));
+ fp->sk = NULL;
head->data_len += fp->len;
head->len += fp->len;
if (head->ip_summed != fp->ip_summed)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 2a14d8b65924..8f68a518d9db 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -445,6 +445,7 @@ nf_ct_frag6_reasm(struct frag_queue *fq, struct sk_buff *prev, struct net_devic
else if (head->ip_summed == CHECKSUM_COMPLETE)
head->csum = csum_add(head->csum, fp->csum);
head->truesize += fp->truesize;
+ fp->sk = NULL;
}
sub_frag_mem_limit(fq->q.net, head->truesize);
--
2.17.1
^ permalink raw reply related
* Re: Containers and checkpoint/restart micro-conference at LPC2018
From: Steve French @ 2018-09-09 17:38 UTC (permalink / raw)
To: James Bottomley
Cc: stgraber, containers, linux-security-module, linux-fsdevel,
Network Development
In-Reply-To: <1536507039.3192.5.camel@HansenPartnership.com>
On Sun, Sep 9, 2018 at 10:32 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2018-08-13 at 12:10 -0400, Stéphane Graber wrote:
> > Details can be found here:
> >
> > https://discuss.linuxcontainers.org/t/containers-micro-conference-a
> > t-linux-plumbers-2018/2417
>
> This website was giving a 503 error when I looked.
>
> However, if you want a discussion on the requirements for shiftfs (and
> whether we still need it), I'm up for that.
I also put in a proposal for a fs miniconference if we have any file
system developers that will be at plumbers
--
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH] r8169: inform about CLKRUN protocol issue when behind a CardBus bridge
From: Maciej S. Szmigiero @ 2018-09-09 22:01 UTC (permalink / raw)
To: David Miller; +Cc: nic_swsd, netdev, linux-kernel
In-Reply-To: <20180909.080907.992434701890231030.davem@davemloft.net>
On 09.09.2018 17:09, David Miller wrote:
> From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
> Date: Thu, 6 Sep 2018 18:10:53 +0200
>
>> It turns out that at least some r8169 CardBus cards don't operate correctly
>> when CLKRUN protocol is enabled - the symptoms are recurring timeouts
>> during PHY reads / writes and a very high packet drop rate.
>> This is true of at least RTL8169sc/8110sc (XID 18000000) chip in
>> Sunrich C-160 CardBus NIC.
>>
>> Such behavior was observed on two separate laptops, the first one has
>> TI PCIxx12 CardBus bridge, while the second one has Ricoh RL5c476II.
>>
>> Setting CLKRUN_En bit in CONFIG 3 register via an EEPROM write didn't
>> improve things in either case (this is probably why it wasn't set by the
>> card manufacturer).
>> The only way to fix the issue was to disable the CLKRUN protocol either
>> in the CardBus bridge (only possible in the TI one) or in the southbridge.
>>
>> Since the problem takes some time to debug let's warn people that have
>> the suspect configuration (Conventional PCI r8169 NIC behind a CardBus
>> bridge) so they know what they can do if they encounter it.
>>
>> Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
>
> I don't know about this.
>
> Barking at the user in the kernel log about an obscure knob (which btw
> doesn't exist for all cardbus bridges without other patches you are
> posting elsewhere) is rarely effective.
>
> We should just disable clkrun automatically we know it causes problems.
Unfortunately, as you wrote above, this workaround is only available on
TI CardBus bridges (and I hope will be available for two Ricoh ones soon,
too), while for other CardBus bridges it is either not implemented or
not available at all.
So we can't reliably just turn it on automatically when needed.
BTW, it seems that my RTL8169 card isn't the only model affected.
In fact, the original CLKRUN protocol disabling workaround on TI bridges
was implemented in 2005 because somebody's RTL8139 also had this
problem: https://lkml.org/lkml/2005/2/5/129
The main reason I wanted to add this warning is to save people time
debugging this issue, as it is rather unobvious.
But if this solution is unacceptable then I hope at least this
description will pop out in search results when searching for some
related keywords.
Thanks,
Maciej
^ permalink raw reply
* Re: [PATCH net V2 0/7] bug fixes for ENA Ethernet driver
From: David Miller @ 2018-09-09 16:41 UTC (permalink / raw)
To: netanel
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, evgenys,
gtzalik
In-Reply-To: <20180909081526.83979-1-netanel@amazon.com>
From: <netanel@amazon.com>
Date: Sun, 9 Sep 2018 08:15:19 +0000
> From: Netanel Belgazal <netanel@amazon.com>
>
> Netanel Belgazal (7):
> net: ena: fix surprise unplug NULL dereference kernel crash
> net: ena: fix driver when PAGE_SIZE == 64kB
> net: ena: fix device destruction to gracefully free resources
> net: ena: fix potential double ena_destroy_device()
> net: ena: fix missing lock during device destruction
> net: ena: fix missing calls to READ_ONCE
> net: ena: fix incorrect usage of memory barriers
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Jonathan Corbet @ 2018-09-09 21:12 UTC (permalink / raw)
To: Henrik Austad
Cc: Mark Rutland, linux-mips, linux-fbdev, x86, kvm, linux-doc,
Peter Zijlstra, James Hogan, Will Deacon, dri-devel,
Masahiro Yamada, Jan Kandziora, Paul Mackerras, Henrik Austad,
Pavel Machek, H. Peter Anvin, Evgeniy Polyakov, linux-s390,
Ian Kent, linux-security-module, Paul Moore, Michael Ellerman,
Helge Deller, Radim Krčmář, James E.J. Bottomley,
Ingo Molnar
In-Reply-To: <1536012923-16275-1-git-send-email-henrik@austad.us>
On Tue, 4 Sep 2018 00:15:23 +0200
Henrik Austad <henrik@austad.us> wrote:
> I don't really have an opinion to whether or not we /should/ have 00-INDEX,
> but the above 00-INDEX should either be removed or be kept up to date. If
> we should keep the files, I can try to keep them updated, but I rather not
> if we just want to delete them anyway.
>
> As a starting point, remove all index-files and references to 00-INDEX and
> see where the discussion is going.
Applied, thanks.
jon
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH net 00/13] cls_u32 cleanups and fixes.
From: Al Viro @ 2018-09-09 15:48 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, Cong Wang, Jiri Pirko
In-Reply-To: <20180909141538.GG19965@ZenIV.linux.org.uk>
On Sun, Sep 09, 2018 at 03:15:38PM +0100, Al Viro wrote:
> Umm... Interesting - TCA_U32_SEL is not the only thing that
> gets ignored there; TCA_U32_MARK gets the same treatment.
> And then there's a lovely question what to do with n->pf -
> it's an array of n->sel.nkeys counters, and apparently we
> want (at least in common cases) to avoid resetting those.
>
> *If* we declare that ->nkeys mismatch means failure, it's
> all relatively easy to implement. Alternatively, we could
> declare that selector change means resetting the stats.
> Preferences?
BTW, shouldn't we issue u32_clear_hw_hnode() every time
we destroy an hnode? It's done on u32_delete(), it's
done (for root ht) on u32_destroy(), but it's not done
for any other hnodes when you remove the entire (not shared)
filter. Looks fishy...
^ permalink raw reply
* Re: Containers and checkpoint/restart micro-conference at LPC2018
From: James Bottomley @ 2018-09-09 15:30 UTC (permalink / raw)
To: Stéphane Graber, lxc-devel, lxc-users, containers,
linux-security-module, linux-fsdevel, netdev
In-Reply-To: <20180813161015.GD18492@castiana>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On Mon, 2018-08-13 at 12:10 -0400, Stéphane Graber wrote:
> Details can be found here:
>
> https://discuss.linuxcontainers.org/t/containers-micro-conference-a
> t-linux-plumbers-2018/2417
This website was giving a 503 error when I looked.
However, if you want a discussion on the requirements for shiftfs (and
whether we still need it), I'm up for that.
James
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next, net v2] net/tls: Set count of SG entries if sk_alloc_sg returns -ENOSPC
From: David Miller @ 2018-09-09 15:10 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson, doronrk
In-Reply-To: <20180906161140.14710-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Thu, 6 Sep 2018 21:41:40 +0530
> tls_sw_sendmsg() allocates plaintext and encrypted SG entries using
> function sk_alloc_sg(). In case the number of SG entries hit
> MAX_SKB_FRAGS, sk_alloc_sg() returns -ENOSPC and sets the variable for
> current SG index to '0'. This leads to calling of function
> tls_push_record() with 'sg_encrypted_num_elem = 0' and later causes
> kernel crash. To fix this, set the number of SG elements to the number
> of elements in plaintext/encrypted SG arrays in case sk_alloc_sg()
> returns -ENOSPC.
>
> Fixes: 3c4d7559159b ("tls: kernel TLS support")
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied to 'net' and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06
From: Kristian Evensen @ 2018-09-09 14:37 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Network Development
In-Reply-To: <87musst6wo.fsf@miraculix.mork.no>
Hei Bjørn,
Thanks for the feedback!
On Sat, Sep 8, 2018 at 4:12 PM Bjørn Mork <bjorn@mork.no> wrote:
> That's annoying, but hardly surprising. They obviously try to make life
> as hard as possible for the drivers. I wonder what the Windows drivers
> do here, if there are any? Or are these modules only used in embedded
> Linux devices?
There are Windows-drivers, but I don't have access to them (or a
machine to test on if I could get them). I would not be surprised if
the modules turn up in Windows-machines, they seems to be quite
popular. EP06/EG06/EM06 all refer to the same module, they just have
different connectors. P is mini-PCIe, G is embedded and M is M.2.
Perhaps the assumption is that Windows-users wont mess around with
these settings? :)
> Could this break if more/other functions are enabled? Are you sure
> there can't be any other type of serial function with 3 endpoints and
> ff/ff/ff?
I forgot to include the listing of all interfaces in my commit, so I
have inserted it at the bottom of this reply. With the current
firmware and interfaces, only QMI has three endpoints and ff/ff/ff. I
guess we just have do as you suggest, wait and refine the approach if
or when something breaks.
Output of lsusb -v for EG06 with all interfaces enabled (I have
checked that EP06 produces the same output):
Bus 002 Device 008: ID 2c7c:0306 Quectel Wireless Solutions Co., Ltd.
EG06/EP06/EM06 LTE-A modem
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 9
idVendor 0x2c7c Quectel Wireless Solutions Co., Ltd.
idProduct 0x0306 EG06/EP06/EM06 LTE-A modem
bcdDevice 3.10
iManufacturer 1 Quectel
iProduct 2 LTE-A Module
iSerial 3 c1494706
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 328
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 126mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 66
bInterfaceProtocol 1
iInterface 4 ADB Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a EP 10 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 22
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000f
Device can operate at Low Speed (1Mbps)
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 1 micro seconds
bU2DevExitLat 500 micro seconds
Device Status: 0x0000
(Bus Powered)
Order of interfaces is diag, nmea, at, ppp, qmi, adb.
BR,
Kristian
^ permalink raw reply
* Re: [lxc-users] Containers and checkpoint/restart micro-conference at LPC2018
From: Lucas Oketch @ 2018-09-09 19:08 UTC (permalink / raw)
To: lucas.oketch-Re5JQEeQqe8AvxtiuMwx3w
Cc: containers-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I,
Miklos Szeredi, Netdev, overlayfs, LSM List,
lxc-devel-cunTk1MwBs9qMoObBWhMNEqPaTDuhLve2LY78lusg7I,
linux-fsdevel, Vivek Goyal
In-Reply-To: <CAOQ4uxiQEpofdS97kxnii8LtVW2QiKAGvjjaH0Px-Bj3eHVCFA@mail.gmail.com>
[-- Attachment #1: Type: text/html, Size: 171 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
^ permalink raw reply
* Re: [PATCH net 00/13] cls_u32 cleanups and fixes.
From: Al Viro @ 2018-09-09 14:15 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, Cong Wang, Jiri Pirko
In-Reply-To: <5f835727-3f86-1532-889f-d11ae17e16d4@mojatatu.com>
On Sun, Sep 09, 2018 at 08:58:50AM -0400, Jamal Hadi Salim wrote:
>
> Since you have the momentum here: i noticed something
> unusual while i was trying to craft a test that would
> vet some of your changes. This has nothing to do with
> your changes, same happens on my stock debian laptop
> with kernel:
> 4.17.0-0.bpo.3-amd64 #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27)
>
> Looking at git - possibly introduced around the time u32
> lockless was being introduced and maybe even earlier
> than that.
It's always been that way, actually - before that point the old
knode simply got reused, which excluded any chance of changing
n->sel.
> Unfortunately i dont have time to dig
> further.
>
> To reproduce what i am referring to, here's a setup:
>
> $tc filter add dev eth0 parent ffff: protocol ip prio 102 u32 \
> classid 1:2 match ip src 192.168.8.0/8
> $tc filter replace dev eth0 parent ffff: protocol ip prio 102 \
> handle 800:0:800 u32 classid 1:2 match ip src 1.1.0.0/24
>
> u32_change() code path should have allowed changing of the
> keynode.
Umm... Interesting - TCA_U32_SEL is not the only thing that
gets ignored there; TCA_U32_MARK gets the same treatment.
And then there's a lovely question what to do with n->pf -
it's an array of n->sel.nkeys counters, and apparently we
want (at least in common cases) to avoid resetting those.
*If* we declare that ->nkeys mismatch means failure, it's
all relatively easy to implement. Alternatively, we could
declare that selector change means resetting the stats.
Preferences?
^ permalink raw reply
* [PATCH] linux-next :cfg80211: Fix warnings while make xmldocs
From: Masanari Iida @ 2018-09-09 13:55 UTC (permalink / raw)
To: davem, linux-kernel, sgruszka, johannes.berg, netdev, corbet,
linux-doc
Cc: Masanari Iida
During 4.19-rc1 merger period, 38cb87ee47fb8 was merged.
In the patch, one of an argument "*ptr" was removed from
the function. But in the comment of the function "@ptr"
still exist. Which causes 109 lines of following warning
during "make xmldocs"
./include/net/cfg80211.h:4869: warning: Excess function
parameter 'ptr' description in 'reg_query_regdb_wmm'
After apply this patch and make xmldocs does not show
this message any more.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
include/net/cfg80211.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8ebabc9873d1..4de121e24ce5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4852,8 +4852,6 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator);
*
* @alpha2: the ISO/IEC 3166 alpha2 wmm rule to be queried.
* @freq: the freqency(in MHz) to be queried.
- * @ptr: pointer where the regdb wmm data is to be stored (or %NULL if
- * irrelevant). This can be used later for deduplication.
* @rule: pointer to store the wmm rule from the regulatory db.
*
* Self-managed wireless drivers can use this function to query
--
2.19.0.rc2
^ permalink raw reply related
* Re: [PATCH] net/sock: move memory_allocated over to percpu_counter variables
From: Eric Dumazet @ 2018-09-09 18:38 UTC (permalink / raw)
To: Olof Johansson
Cc: Herbert Xu, David Miller, Neil Horman, Marcelo Ricardo Leitner,
Vladislav Yasevich, Alexey Kuznetsov, Hideaki YOSHIFUJI,
linux-crypto, LKML, linux-sctp, netdev, linux-decnet-user,
kernel-team, Yuchung Cheng, Neal Cardwell
In-Reply-To: <CAOesGMi31UA2d-Bj2jo53Wz_YV424-rD3qk9rS5_-Yng0VC=0w@mail.gmail.com>
On Sat, Sep 8, 2018 at 10:02 AM Olof Johansson <olof@lixom.net> wrote:
>
> Hi,
>
> On Fri, Sep 7, 2018 at 12:21 AM, Eric Dumazet <edumazet@google.com> wrote:
> > On Fri, Sep 7, 2018 at 12:03 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> >> Problem is : we have platforms with more than 100 cpus, and
> >> sk_memory_allocated() cost will be too expensive,
> >> especially if the host is under memory pressure, since all cpus will
> >> touch their private counter.
> >>
> >> per cpu variables do not really scale, they were ok 10 years ago when
> >> no more than 16 cpus were the norm.
> >>
> >> I would prefer change TCP to not aggressively call
> >> __sk_mem_reduce_allocated() from tcp_write_timer()
> >>
> >> Ideally only tcp_retransmit_timer() should attempt to reduce forward
> >> allocations, after recurring timeout.
> >>
> >> Note that after 20c64d5cd5a2bdcdc8982a06cb05e5e1bd851a3d ("net: avoid
> >> sk_forward_alloc overflows")
> >> we have better control over sockets having huge forward allocations.
> >>
> >> Something like :
> >
> > Or something less risky :
>
> I gave both of these patches a run, and neither do as well on the
> system that has slower atomics. :(
>
> The percpu version:
>
> 8.05% workload [kernel.vmlinux]
> [k] __do_softirq
> 7.04% swapper [kernel.vmlinux]
> [k] cpuidle_enter_state
> 5.54% workload [kernel.vmlinux]
> [k] _raw_spin_unlock_irqrestore
> 1.66% swapper [kernel.vmlinux]
> [k] __do_softirq
> 1.55% workload [kernel.vmlinux]
> [k] finish_task_switch
> 1.24% swapper [kernel.vmlinux]
> [k] finish_task_switch
> 1.07% workload [kernel.vmlinux]
> [k] net_rx_action
>
> The first patch from you still has significant amount of time spent in
> the atomics paths (non-inlined versions used):
>
> 7.87% workload [kernel.vmlinux]
> [k] __ll_sc_atomic64_sub
The second patch I gave should not enter this path at all, please try it.
> 7.48% workload [kernel.vmlinux]
> [k] __do_softirq
> 5.05% workload [kernel.vmlinux]
> [k] _raw_spin_unlock_irqrestore
> 2.42% workload [kernel.vmlinux]
> [k] __ll_sc_atomic64_add_return
> 1.49% swapper [kernel.vmlinux]
> [k] cpuidle_enter_state
> 1.31% workload [kernel.vmlinux]
> [k] finish_task_switch
> 1.09% workload [kernel.vmlinux]
> [k] tcp_sendmsg_locked
> 1.08% workload [kernel.vmlinux]
> [k] __arch_copy_from_user
> 1.02% workload [kernel.vmlinux]
> [k] net_rx_action
>
> I think a lot of the overhead from percpu approach can be alleviated
> if we can use percpu_counter_read() instead of _sum() (i.e. no need to
> iterate through the local per-cpu recent delta). I don't know the TCP
> stack well enough to tell where it's OK to use a bit of slack in the
> numbers though -- by default count will at most be off by 32*online
> cpus. Might not be a significant number in reality.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] tcp: fix the error count of tcpInSegs
From: Eric Dumazet @ 2018-09-09 18:32 UTC (permalink / raw)
To: Yafang Shao; +Cc: David Miller, netdev, LKML
In-Reply-To: <1536462862-11767-2-git-send-email-laoar.shao@gmail.com>
On Sat, Sep 8, 2018 at 8:14 PM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> In RFC1213, the tcpInSegs is the total number of segments received.
> While currently it is the total number of SKBs received.
> The number of SKBs may be not equal with the numer of segments because of
> GRO.
> So fix this error count.
>
We have discussed this in the past and the consensus was it was too
late to change this.
IP counters have the same issue, so after your patch, we would have
quite a difference between transport and network layers.
Adding all these max_t(u16, 1, skb_shinfo(skb)->gso_segs)) everywhere add a cost
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] tcp: show number of network segments in some SNMP counters
From: Eric Dumazet @ 2018-09-09 18:27 UTC (permalink / raw)
To: Yafang Shao; +Cc: David Miller, netdev, LKML
In-Reply-To: <1536462862-11767-1-git-send-email-laoar.shao@gmail.com>
On Sat, Sep 8, 2018 at 8:14 PM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> It is better to show the number of network segments in bellow SNMP
> counters, because that could be more useful for the user.
> For example, the user could easily figure out how mant packets are
> dropped and how many packets are queued in the out-of-oder queue.
>
> - LINUX_MIB_TCPRCVQDROP
> - LINUX_MIB_TCPZEROWINDOWDROP
> - LINUX_MIB_TCPBACKLOGDROP
> - LINUX_MIB_TCPMINTTLDROP
> - LINUX_MIB_TCPOFODROP
> - LINUX_MIB_TCPOFOQUEUE
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> ---
> net/ipv4/tcp_input.c | 18 ++++++++++++------
> net/ipv4/tcp_ipv4.c | 9 ++++++---
> net/ipv6/tcp_ipv6.c | 6 ++++--
> 3 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 62508a2..c2ce334 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4496,7 +4496,8 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
> tcp_ecn_check_ce(sk, skb);
>
> if (unlikely(tcp_try_rmem_schedule(sk, skb, skb->truesize))) {
> - NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPOFODROP);
> + NET_ADD_STATS(sock_net(sk), LINUX_MIB_TCPOFODROP,
> + max_t(u16, 1, skb_shinfo(skb)->gso_segs));
>
I am nacking this patch. These counters are counting events really.
^ permalink raw reply
* Re: [PATCH net 00/13] cls_u32 cleanups and fixes.
From: Jamal Hadi Salim @ 2018-09-09 12:58 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Cong Wang, Jiri Pirko
In-Reply-To: <20180909013132.3222-1-viro@ZenIV.linux.org.uk>
Since you have the momentum here: i noticed something
unusual while i was trying to craft a test that would
vet some of your changes. This has nothing to do with
your changes, same happens on my stock debian laptop
with kernel:
4.17.0-0.bpo.3-amd64 #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27)
Looking at git - possibly introduced around the time u32
lockless was being introduced and maybe even earlier
than that. Unfortunately i dont have time to dig
further.
To reproduce what i am referring to, here's a setup:
$tc filter add dev eth0 parent ffff: protocol ip prio 102 u32 \
classid 1:2 match ip src 192.168.8.0/8
$tc filter replace dev eth0 parent ffff: protocol ip prio 102 \
handle 800:0:800 u32 classid 1:2 match ip src 1.1.0.0/24
u32_change() code path should have allowed changing of the
keynode.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 13/13] net: sched: cls_u32: simplify the hell out u32_delete() emptiness check
From: Jamal Hadi Salim @ 2018-09-09 12:51 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Cong Wang, Jiri Pirko
In-Reply-To: <20180909013132.3222-14-viro@ZenIV.linux.org.uk>
On 2018-09-08 9:31 p.m., Al Viro wrote:
> From: Al Viro <viro@zeniv.linux.org.uk>
>
> Now that we have the knode count, we can instantly check if
> any hnodes are non-empty. And that kills the check for extra
> references to root hnode - those could happen only if there was
> a knode to carry such a link.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 12/13] net: sched: cls_u32: keep track of knodes count in tc_u_common
From: Jamal Hadi Salim @ 2018-09-09 12:50 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Cong Wang, Jiri Pirko
In-Reply-To: <20180909013132.3222-13-viro@ZenIV.linux.org.uk>
On 2018-09-08 9:31 p.m., Al Viro wrote:
> From: Al Viro <viro@zeniv.linux.org.uk>
>
> allows to simplify u32_delete() considerably
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 11/13] net: sched: cls_u32: get rid of hnode ->tp_c and tp_c argument of u32_set_parms()
From: Jamal Hadi Salim @ 2018-09-09 12:49 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Cong Wang, Jiri Pirko
In-Reply-To: <20180909013132.3222-12-viro@ZenIV.linux.org.uk>
On 2018-09-08 9:31 p.m., Al Viro wrote:
> From: Al Viro <viro@zeniv.linux.org.uk>
>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 10/13] net: sched: cls_u32: the tp_c argument of u32_set_parms() is always tp->data
From: Jamal Hadi Salim @ 2018-09-09 12:48 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Cong Wang, Jiri Pirko
In-Reply-To: <20180909013132.3222-11-viro@ZenIV.linux.org.uk>
On 2018-09-08 9:31 p.m., Al Viro wrote:
> From: Al Viro <viro@zeniv.linux.org.uk>
>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH net-next v9 4/6] net: vhost: add rx busy polling in tx path
From: xiangxia.m.yue @ 2018-09-09 11:51 UTC (permalink / raw)
To: jasowang, mst, makita.toshiaki; +Cc: virtualization, netdev, Tonghao Zhang
In-Reply-To: <1536493887-2637-1-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
This patch improves the guest receive performance.
On the handle_tx side, we poll the sock receive queue at the
same time. handle_rx do that in the same way.
We set the poll-us=100us and use the netperf to test throughput
and mean latency. When running the tests, the vhost-net kthread
of that VM, is alway 100% CPU. The commands are shown as below.
Rx performance is greatly improved by this patch. There is not
notable performance change on tx with this series though. This
patch is useful for bi-directional traffic.
netperf -H IP -t TCP_STREAM -l 20 -- -O "THROUGHPUT, THROUGHPUT_UNITS, MEAN_LATENCY"
Topology:
[Host] ->linux bridge -> tap vhost-net ->[Guest]
TCP_STREAM:
* Without the patch: 19842.95 Mbps, 6.50 us mean latency
* With the patch: 37598.20 Mbps, 3.43 us mean latency
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
drivers/vhost/net.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 3f68265..d372c14 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -508,31 +508,24 @@ static void vhost_net_busy_poll(struct vhost_net *net,
}
static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
- struct vhost_net_virtqueue *nvq,
+ struct vhost_net_virtqueue *tnvq,
unsigned int *out_num, unsigned int *in_num,
bool *busyloop_intr)
{
- struct vhost_virtqueue *vq = &nvq->vq;
- unsigned long uninitialized_var(endtime);
- int r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
+ struct vhost_net_virtqueue *rnvq = &net->vqs[VHOST_NET_VQ_RX];
+ struct vhost_virtqueue *rvq = &rnvq->vq;
+ struct vhost_virtqueue *tvq = &tnvq->vq;
+
+ int r = vhost_get_vq_desc(tvq, tvq->iov, ARRAY_SIZE(tvq->iov),
out_num, in_num, NULL, NULL);
- if (r == vq->num && vq->busyloop_timeout) {
- if (!vhost_sock_zcopy(vq->private_data))
- vhost_net_signal_used(nvq);
- preempt_disable();
- endtime = busy_clock() + vq->busyloop_timeout;
- while (vhost_can_busy_poll(endtime)) {
- if (vhost_has_work(vq->dev)) {
- *busyloop_intr = true;
- break;
- }
- if (!vhost_vq_avail_empty(vq->dev, vq))
- break;
- cpu_relax();
- }
- preempt_enable();
- r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
+ if (r == tvq->num && tvq->busyloop_timeout) {
+ if (!vhost_sock_zcopy(tvq->private_data))
+ vhost_net_signal_used(tnvq);
+
+ vhost_net_busy_poll(net, rvq, tvq, busyloop_intr, false);
+
+ r = vhost_get_vq_desc(tvq, tvq->iov, ARRAY_SIZE(tvq->iov),
out_num, in_num, NULL, NULL);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v9 3/6] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: xiangxia.m.yue @ 2018-09-09 11:51 UTC (permalink / raw)
To: jasowang, mst, makita.toshiaki; +Cc: virtualization, netdev, Tonghao Zhang
In-Reply-To: <1536493887-2637-1-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Factor out generic busy polling logic and will be
used for in tx path in the next patch. And with the patch,
qemu can set differently the busyloop_timeout for rx queue.
To avoid duplicate codes, introduce the helper functions:
* sock_has_rx_data(changed from sk_has_rx_data)
* vhost_net_busy_poll_try_queue
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
drivers/vhost/net.c | 109 +++++++++++++++++++++++++++++++++-------------------
1 file changed, 69 insertions(+), 40 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 32c1b52..3f68265 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -440,6 +440,73 @@ static void vhost_net_signal_used(struct vhost_net_virtqueue *nvq)
nvq->done_idx = 0;
}
+static int sock_has_rx_data(struct socket *sock)
+{
+ if (unlikely(!sock))
+ return 0;
+
+ if (sock->ops->peek_len)
+ return sock->ops->peek_len(sock);
+
+ return skb_queue_empty(&sock->sk->sk_receive_queue);
+}
+
+static void vhost_net_busy_poll_try_queue(struct vhost_net *net,
+ struct vhost_virtqueue *vq)
+{
+ if (!vhost_vq_avail_empty(&net->dev, vq)) {
+ vhost_poll_queue(&vq->poll);
+ } else if (unlikely(vhost_enable_notify(&net->dev, vq))) {
+ vhost_disable_notify(&net->dev, vq);
+ vhost_poll_queue(&vq->poll);
+ }
+}
+
+static void vhost_net_busy_poll(struct vhost_net *net,
+ struct vhost_virtqueue *rvq,
+ struct vhost_virtqueue *tvq,
+ bool *busyloop_intr,
+ bool poll_rx)
+{
+ unsigned long busyloop_timeout;
+ unsigned long endtime;
+ struct socket *sock;
+ struct vhost_virtqueue *vq = poll_rx ? tvq : rvq;
+
+ mutex_lock_nested(&vq->mutex, poll_rx ? VHOST_NET_VQ_TX: VHOST_NET_VQ_RX);
+ vhost_disable_notify(&net->dev, vq);
+ sock = rvq->private_data;
+
+ busyloop_timeout = poll_rx ? rvq->busyloop_timeout:
+ tvq->busyloop_timeout;
+
+ preempt_disable();
+ endtime = busy_clock() + busyloop_timeout;
+
+ while (vhost_can_busy_poll(endtime)) {
+ if (vhost_has_work(&net->dev)) {
+ *busyloop_intr = true;
+ break;
+ }
+
+ if ((sock_has_rx_data(sock) &&
+ !vhost_vq_avail_empty(&net->dev, rvq)) ||
+ !vhost_vq_avail_empty(&net->dev, tvq))
+ break;
+
+ cpu_relax();
+ }
+
+ preempt_enable();
+
+ if (poll_rx || sock_has_rx_data(sock))
+ vhost_net_busy_poll_try_queue(net, vq);
+ else if (!poll_rx) /* On tx here, sock has no rx data. */
+ vhost_enable_notify(&net->dev, rvq);
+
+ mutex_unlock(&vq->mutex);
+}
+
static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
struct vhost_net_virtqueue *nvq,
unsigned int *out_num, unsigned int *in_num,
@@ -753,16 +820,6 @@ static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
return len;
}
-static int sk_has_rx_data(struct sock *sk)
-{
- struct socket *sock = sk->sk_socket;
-
- if (sock->ops->peek_len)
- return sock->ops->peek_len(sock);
-
- return skb_queue_empty(&sk->sk_receive_queue);
-}
-
static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk,
bool *busyloop_intr)
{
@@ -770,41 +827,13 @@ static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk,
struct vhost_net_virtqueue *tnvq = &net->vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *rvq = &rnvq->vq;
struct vhost_virtqueue *tvq = &tnvq->vq;
- unsigned long uninitialized_var(endtime);
int len = peek_head_len(rnvq, sk);
- if (!len && tvq->busyloop_timeout) {
+ if (!len && rvq->busyloop_timeout) {
/* Flush batched heads first */
vhost_net_signal_used(rnvq);
/* Both tx vq and rx socket were polled here */
- mutex_lock_nested(&tvq->mutex, VHOST_NET_VQ_TX);
- vhost_disable_notify(&net->dev, tvq);
-
- preempt_disable();
- endtime = busy_clock() + tvq->busyloop_timeout;
-
- while (vhost_can_busy_poll(endtime)) {
- if (vhost_has_work(&net->dev)) {
- *busyloop_intr = true;
- break;
- }
- if ((sk_has_rx_data(sk) &&
- !vhost_vq_avail_empty(&net->dev, rvq)) ||
- !vhost_vq_avail_empty(&net->dev, tvq))
- break;
- cpu_relax();
- }
-
- preempt_enable();
-
- if (!vhost_vq_avail_empty(&net->dev, tvq)) {
- vhost_poll_queue(&tvq->poll);
- } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
- vhost_disable_notify(&net->dev, tvq);
- vhost_poll_queue(&tvq->poll);
- }
-
- mutex_unlock(&tvq->mutex);
+ vhost_net_busy_poll(net, rvq, tvq, busyloop_intr, true);
len = peek_head_len(rnvq, sk);
}
--
1.8.3.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