Re: act_mirred: remove spinlock in fast path

[Eric Dumazet]

On Sat, 2016-06-18 at 11:24 -0400, Jamal Hadi Salim wrote:
> On 16-06-18 11:16 AM, Eric Dumazet wrote:
> 
> >> Given an update/replace of an action is such a rare occassion, what
> >> is wrong with init doing a spin lock on existing action?
> >> Sure, there is performance impact on fast path at that point - but:
> >> as established update/replace is _a rare occassion_ ;->
> >
> > The potential 'problem' is not the write side, but the read side.
> >
> > If you read say 3 values   you might want to read them in a
> > consistent way, instead of 
> >
> 
> That part i get.
> What i meant is: while the fast path is doing rcu_read_lock()
> of   and on the rare occassion that _init() is doing a
> write to  then if it should spin lock it would not corrupt
> what fast path sees as  during the transition.
> Am i misunderstanding?

Yes, I do not see how a change in the write side can help.

You probably need a bit of coffee ;)

Re: act_mirred: remove spinlock in fast path

[Jamal Hadi Salim]

On 16-06-18 11:16 AM, Eric Dumazet wrote:


Given an update/replace of an action is such a rare occassion, what
is wrong with init doing a spin lock on existing action?
Sure, there is performance impact on fast path at that point - but:
as established update/replace is _a rare occassion_ ;->


The potential 'problem' is not the write side, but the read side.

If you read say 3 values   you might want to read them in a
consistent way, instead of 



That part i get.
What i meant is: while the fast path is doing rcu_read_lock()
of   and on the rare occassion that _init() is doing a
write to  then if it should spin lock it would not corrupt
what fast path sees as  during the transition.
Am i misunderstanding?

cheers,
jamal

Re: act_mirred: remove spinlock in fast path

[Eric Dumazet]

On Sat, 2016-06-18 at 09:45 -0400, Jamal Hadi Salim wrote:
> On 16-06-17 06:03 PM, Eric Dumazet wrote:
> > On Fri, Jun 17, 2016 at 2:59 PM, Cong Wang  wrote:
> >
> >> Generally speaking I worry about we change multiple fields in a struct
> >> meanwhile we could still read them any time in the middle, we may
> >> get them correct for some easy case, but it is hard to insure the
> >> correctness when the struct becomes large.
> >>
> >> I am thinking to make more tc actions lockless, so this problem
> >> comes up immediately for other complex cases than mirred.
> >
> > I certainly wont object to a patch.
> >
> > Also note that instead of RCU with a pointer and the usual kfree_rcu() 
> > stuff,
> > we now can use seqcount_latch infra which might allow to not increase
> > memory foot print.
> >
> 
> Given an update/replace of an action is such a rare occassion, what
> is wrong with init doing a spin lock on existing action?
> Sure, there is performance impact on fast path at that point - but:
> as established update/replace is _a rare occassion_ ;->

The potential 'problem' is not the write side, but the read side.

If you read say 3 values   you might want to read them in a
consistent way, instead of 

Re: act_mirred: remove spinlock in fast path

[Jamal Hadi Salim]

On 16-06-17 06:03 PM, Eric Dumazet wrote:

On Fri, Jun 17, 2016 at 2:59 PM, Cong Wang  wrote:


Generally speaking I worry about we change multiple fields in a struct
meanwhile we could still read them any time in the middle, we may
get them correct for some easy case, but it is hard to insure the
correctness when the struct becomes large.

I am thinking to make more tc actions lockless, so this problem
comes up immediately for other complex cases than mirred.


I certainly wont object to a patch.

Also note that instead of RCU with a pointer and the usual kfree_rcu() stuff,
we now can use seqcount_latch infra which might allow to not increase
memory foot print.



Given an update/replace of an action is such a rare occassion, what
is wrong with init doing a spin lock on existing action?
Sure, there is performance impact on fast path at that point - but:
as established update/replace is _a rare occassion_ ;->

cheers,
jamal

Re: act_mirred: remove spinlock in fast path

[Eric Dumazet]

On Fri, Jun 17, 2016 at 2:59 PM, Cong Wang  wrote:

> Generally speaking I worry about we change multiple fields in a struct
> meanwhile we could still read them any time in the middle, we may
> get them correct for some easy case, but it is hard to insure the
> correctness when the struct becomes large.
>
> I am thinking to make more tc actions lockless, so this problem
> comes up immediately for other complex cases than mirred.

I certainly wont object to a patch.

Also note that instead of RCU with a pointer and the usual kfree_rcu() stuff,
we now can use seqcount_latch infra which might allow to not increase
memory foot print.

Re: act_mirred: remove spinlock in fast path

[Cong Wang]

On Fri, Jun 17, 2016 at 2:40 PM, Eric Dumazet  wrote:
> On Fri, Jun 17, 2016 at 2:35 PM, Cong Wang  wrote:
>> On Fri, Jun 17, 2016 at 2:24 PM, Eric Dumazet  wrote:
>>> Well, I added a READ_ONCE() to read tcf_action once.
>>>
>>> Adding rcu here would mean adding a pointer and extra cache line, to
>>> deref the values.
>>>
>>> IMHO the race here has no effect . You either read the old or new value.
>>
>> Sure, the point is we may read a new ->tcf_action and an old ->tcfm_eaction,
>> this is what I am worrying.
>>
>> If that is not a good example, what about new ->tcf_action and 
>> ->tcfm_eaction,
>> with an old ->tcfm_ifindex?
>>
>>>
>>> If the packet is processed before or after the 'change' it would have
>>> the same 'race'
>>>
>>
>> Why? As long as the change is like a transaction, we are safe.
>>
>>> All these fields are integers, they never are 'partially written'.
>>>
>>> The only case m->tcfm_eaction could be read twice is in the error
>>> path. Who cares ?
>>
>> This is not what I worry about. I guess you miss read eaction with action.
>
> No I did not. I am referring to the fact that we currently might read
> m->tcfm_eaction multiple times.
>
> Please explain what would be wrong reading a wrong pair of values ?
>
> One packet might come to a wrong device in the unlikely case an admin
> change all the fields during an update ?

Yes, that is what in my mind, since I only did code review, not actually
saw any real problem (mostly because here we don't use standalone actions).

>
> Is it going to crash or reveal highly sensitive security data ?
>
> If yes, then please send a patch. I considered all this when writing
> my patch and maybe I was wrong.

I don't know.

Generally speaking I worry about we change multiple fields in a struct
meanwhile we could still read them any time in the middle, we may
get them correct for some easy case, but it is hard to insure the
correctness when the struct becomes large.

I am thinking to make more tc actions lockless, so this problem
comes up immediately for other complex cases than mirred.

Re: act_mirred: remove spinlock in fast path

[Eric Dumazet]

On Fri, Jun 17, 2016 at 2:35 PM, Cong Wang  wrote:
> On Fri, Jun 17, 2016 at 2:24 PM, Eric Dumazet  wrote:
>> Well, I added a READ_ONCE() to read tcf_action once.
>>
>> Adding rcu here would mean adding a pointer and extra cache line, to
>> deref the values.
>>
>> IMHO the race here has no effect . You either read the old or new value.
>
> Sure, the point is we may read a new ->tcf_action and an old ->tcfm_eaction,
> this is what I am worrying.
>
> If that is not a good example, what about new ->tcf_action and ->tcfm_eaction,
> with an old ->tcfm_ifindex?
>
>>
>> If the packet is processed before or after the 'change' it would have
>> the same 'race'
>>
>
> Why? As long as the change is like a transaction, we are safe.
>
>> All these fields are integers, they never are 'partially written'.
>>
>> The only case m->tcfm_eaction could be read twice is in the error
>> path. Who cares ?
>
> This is not what I worry about. I guess you miss read eaction with action.

No I did not. I am referring to the fact that we currently might read
m->tcfm_eaction multiple times.

Please explain what would be wrong reading a wrong pair of values ?

One packet might come to a wrong device in the unlikely case an admin
change all the fields during an update ?

Is it going to crash or reveal highly sensitive security data ?

If yes, then please send a patch. I considered all this when writing
my patch and maybe I was wrong.

Re: act_mirred: remove spinlock in fast path

[Cong Wang]

On Fri, Jun 17, 2016 at 2:24 PM, Eric Dumazet  wrote:
> Well, I added a READ_ONCE() to read tcf_action once.
>
> Adding rcu here would mean adding a pointer and extra cache line, to
> deref the values.
>
> IMHO the race here has no effect . You either read the old or new value.

Sure, the point is we may read a new ->tcf_action and an old ->tcfm_eaction,
this is what I am worrying.

If that is not a good example, what about new ->tcf_action and ->tcfm_eaction,
with an old ->tcfm_ifindex?

>
> If the packet is processed before or after the 'change' it would have
> the same 'race'
>

Why? As long as the change is like a transaction, we are safe.

> All these fields are integers, they never are 'partially written'.
>
> The only case m->tcfm_eaction could be read twice is in the error
> path. Who cares ?

This is not what I worry about. I guess you miss read eaction with action.

Re: act_mirred: remove spinlock in fast path

[Eric Dumazet]

On Fri, Jun 17, 2016 at 2:03 PM, Cong Wang  wrote:
> Hi, Eric
>
> During code review, I notice we might have some problem after we go
> lockless for the fast path in act_mirred.
>
> That is, what prevents us from the following possible race condition?
>
> change a standalone action with tcf_mirred_init():
>   // search for an existing action in hash
>   // found it and got struct tcf_common
>   m = to_mirred(a);
>   m->tcf_action = parm->action;
>   // Interrupted by BH
>
> tcf_mirred() jumps in:
>   rcu_read_lock()
>   retval = READ_ONCE(m->tcf_action);
>   if (m->tcfm_eaction != TCA_EGRESS_MIRROR)
>   
>   rcu_unread_lock()
>
> now go back to tcf_mirred_init():
>   m->tcfm_eaction = parm->eaction;
>   
>
> IOW, the fast path could read a partially written change which could
> be a problem? We need to allocate a new copy and then replace the old
> one with it via RCU, don't we?
>
> I can work on some patches, I want to make sure I don't miss anything here.
>
> Thanks!

Well, I added a READ_ONCE() to read tcf_action once.

Adding rcu here would mean adding a pointer and extra cache line, to
deref the values.

IMHO the race here has no effect . You either read the old or new value.

If the packet is processed before or after the 'change' it would have
the same 'race'

All these fields are integers, they never are 'partially written'.

The only case m->tcfm_eaction could be read twice is in the error
path. Who cares ?

act_mirred: remove spinlock in fast path

[Cong Wang]

Hi, Eric

During code review, I notice we might have some problem after we go
lockless for the fast path in act_mirred.

That is, what prevents us from the following possible race condition?

change a standalone action with tcf_mirred_init():
  // search for an existing action in hash
  // found it and got struct tcf_common
  m = to_mirred(a);
  m->tcf_action = parm->action;
  // Interrupted by BH

tcf_mirred() jumps in:
  rcu_read_lock()
  retval = READ_ONCE(m->tcf_action);
  if (m->tcfm_eaction != TCA_EGRESS_MIRROR)
  
  rcu_unread_lock()

now go back to tcf_mirred_init():
  m->tcfm_eaction = parm->eaction;
  

IOW, the fast path could read a partially written change which could
be a problem? We need to allocate a new copy and then replace the old
one with it via RCU, don't we?

I can work on some patches, I want to make sure I don't miss anything here.

Thanks!

Re: [PATCH v3 net-next 7/7] net_sched: act_mirred: remove spinlock in fast path

[Jamal Hadi Salim]

On 07/06/15 08:18, Eric Dumazet wrote:

Like act_gact, act_mirred can be lockless in packet processing

1) Use percpu stats
2) update lastuse only every clock tick to avoid false sharing
3) use rcu to protect tcfm_dev
4) Remove spinlock usage, as it is no longer needed.

Next step : add multi queue capability to ifb device

Signed-off-by: Eric Dumazet eduma...@google.com


Looks good to me ;-
Acked-by: Jamal Hadi Salim j...@mojatatu.com

cant wait for the multi queue ifb.

cheers,
jamal
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 net-next 7/7] net_sched: act_mirred: remove spinlock in fast path

[Alexei Starovoitov]

On 7/6/15 5:18 AM, Eric Dumazet wrote:

Like act_gact, act_mirred can be lockless in packet processing

1) Use percpu stats
2) update lastuse only every clock tick to avoid false sharing
3) use rcu to protect tcfm_dev
4) Remove spinlock usage, as it is no longer needed.

Next step : add multi queue capability to ifb device

Signed-off-by: Eric Dumazeteduma...@google.com


Nice!
Acked-by: Alexei Starovoitov a...@plumgrid.com

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 net-next 7/7] net_sched: act_mirred: remove spinlock in fast path

[Eric Dumazet]

ifb patch seems to work very well ;)

# tc -s -d qd sh dev ifb10
qdisc mq 1: root
 Sent 190952 bytes 31798616 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 29460b 491p requeues 0
qdisc netem 8002: parent 1:1 limit 10 delay 3.0ms
 Sent 238320936 bytes 3971225 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9723Kbit 20255pps backlog 3840b 64p requeues 0
qdisc netem 8003: parent 1:2 limit 10 delay 3.0ms
 Sent 238581473 bytes 3975830 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9763Kbit 20341pps backlog 4320b 72p requeues 0
qdisc netem 8004: parent 1:3 limit 10 delay 3.0ms
 Sent 238583840 bytes 3975172 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9752Kbit 20316pps backlog 3360b 56p requeues 0
qdisc netem 8005: parent 1:4 limit 10 delay 3.0ms
 Sent 238849458 bytes 3980058 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9792Kbit 20392pps backlog 3720b 62p requeues 0
qdisc netem 8006: parent 1:5 limit 10 delay 3.0ms
 Sent 238423191 bytes 3973198 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9729Kbit 20268pps backlog 4020b 67p requeues 0
qdisc netem 8007: parent 1:6 limit 10 delay 3.0ms
 Sent 238417904 bytes 3972338 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9733Kbit 20277pps backlog 3Kb 51p requeues 0
qdisc netem 8008: parent 1:7 limit 10 delay 3.0ms
 Sent 239878967 bytes 3976960 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9801Kbit 20417pps backlog 3420b 57p requeues 0
qdisc netem 8009: parent 1:8 limit 10 delay 3.0ms
 Sent 238464411 bytes 3973838 pkt (dropped 0, overlimits 0 requeues 0)
 rate 9765Kbit 20344pps backlog 3540b 59p requeues 0

On Mon, Jul 6, 2015 at 4:56 PM, Eric Dumazet eduma...@google.com wrote:
 On Mon, Jul 6, 2015 at 2:53 PM, Jamal Hadi Salim j...@mojatatu.com wrote:

 cant wait for the multi queue ifb.


 Yeah, me too ;)

 Do not try this on a production host :

 ip link add ifb10 numtxqueues 100 type ifb

 [284151.950695] kernel BUG at /build/buildd/linux-3.13.0/net/core/dev.c:5868!
 [284151.950762] invalid opcode:  [#1] SMP
 [284151.950779] Modules linked in: ifb uvcvideo videobuf2_vmalloc
 videobuf2_memops videobuf2_core videodev e1000e ptp pps_core ctr ccm
 sch_codel sch_htb tcp_diag inet_diag nfnetlink_log nfnetlink xt_recent
 arc4 iwldvm mac80211 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
 xt_hl ip6t_rt ipt_REJECT xt_LOG snd_hda_codec_hdmi
 snd_hda_codec_realtek ipt_ULOG xt_limit xt_tcpudp snd_hda_intel
 snd_hda_codec nf_conntrack_ipv4 nf_defrag_ipv4 snd_hwdep xt_addrtype
 snd_pcm xt_owner xt_conntrack ip6table_filter thinkpad_acpi
 snd_page_alloc ip6_tables nvram xt_state xt_helper nf_nat_tftp
 nf_conntrack_tftp nf_nat_irc snd_seq_midi nf_conntrack_irc
 snd_seq_midi_event nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack
 iptable_filter snd_rawmidi ip_tables x_tables snd_seq snd_seq_device
 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp btusb
 kvm_intel iwlwifi kvm snd_timer cfg80211 rfcomm bnep joydev serio_raw
 bluetooth snd parport_pc wmi ppdev mac_hid mei_me lpc_ich shpchp mei
 lp soundcore parport btrfs xor raid6_pq libcrc32c dm_crypt
 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
 aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci psmouse
 i915 libahci sdhci_pci sdhci i2c_algo_bit drm_kms_helper video drm
 [last unloaded: videobuf2_memops]
 [284151.968991] CPU: 3 PID: 1298 Comm: ip Tainted: GW
 3.13.0-55-generic #94-Ubuntu
 [284151.972108] Hardware name: LENOVO 2429CY7/2429CY7, BIOS G4ET94WW
 (2.54 ) 05/23/2013
 [284151.973847] task: 8800a3e6b000 ti: 8801ba4da000 task.ti:
 8801ba4da000
 [284151.975993] RIP: 0010:[8162b5b2]  [8162b5b2]
 alloc_netdev_mqs+0x392/0x3c0
 [284151.979497] RSP: 0018:8801ba4db870  EFLAGS: 00010206
 [284151.982916] RAX: 000f4240 RBX: 8804082a3000 RCX:
 
 [284151.986433] RDX:  RSI:  RDI:
 8801ba4db7e0
 [284151.989907] RBP: 8801ba4db8a0 R08: a9d3373c R09:
 8801ba4db7d6
 [284151.993381] R10: 323f6b16 R11: 2c647ed6 R12:
 000f423f
 [284151.996862] R13: 0001 R14: 8801ba4dba70 R15:
 1312d000
 [284152.000335] FS:  7efdbf71f740() GS:88041e2c()
 knlGS:
 [284152.003865] CS:  0010 DS:  ES:  CR0: 80050033
 [284152.007382] CR2: 7ffd2acd1f88 CR3: 0001b39cc000 CR4:
 001407e0
 [284152.010870] Stack:
 [284152.014321]  091f 88040431e800 8801ba4db958
 a024c020
 [284152.017798]  fff4 81cdab40 8801ba4db8e8
 816357bb
 [284152.021287]  8189d340 8801ba4db8f8 88040431e800
 81cdab40
 [284152.024770] Call Trace:
 [284152.028167]  [816357bb] rtnl_create_link+0x5b/0x1c0
 [284152.031558]  [816396aa] rtnl_newlink+0x4ba/0x610
 [284152.034960]  [8163932f] ? rtnl_newlink+0x13f/0x610
 [284152.038301]  [81635e85] rtnetlink_rcv_msg+0x95/0x250
 

Re: [PATCH v3 net-next 7/7] net_sched: act_mirred: remove spinlock in fast path

[Eric Dumazet]

On Mon, Jul 6, 2015 at 2:53 PM, Jamal Hadi Salim j...@mojatatu.com wrote:

 cant wait for the multi queue ifb.


Yeah, me too ;)

Do not try this on a production host :

ip link add ifb10 numtxqueues 100 type ifb

[284151.950695] kernel BUG at /build/buildd/linux-3.13.0/net/core/dev.c:5868!
[284151.950762] invalid opcode:  [#1] SMP
[284151.950779] Modules linked in: ifb uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_core videodev e1000e ptp pps_core ctr ccm
sch_codel sch_htb tcp_diag inet_diag nfnetlink_log nfnetlink xt_recent
arc4 iwldvm mac80211 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
xt_hl ip6t_rt ipt_REJECT xt_LOG snd_hda_codec_hdmi
snd_hda_codec_realtek ipt_ULOG xt_limit xt_tcpudp snd_hda_intel
snd_hda_codec nf_conntrack_ipv4 nf_defrag_ipv4 snd_hwdep xt_addrtype
snd_pcm xt_owner xt_conntrack ip6table_filter thinkpad_acpi
snd_page_alloc ip6_tables nvram xt_state xt_helper nf_nat_tftp
nf_conntrack_tftp nf_nat_irc snd_seq_midi nf_conntrack_irc
snd_seq_midi_event nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack
iptable_filter snd_rawmidi ip_tables x_tables snd_seq snd_seq_device
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp btusb
kvm_intel iwlwifi kvm snd_timer cfg80211 rfcomm bnep joydev serio_raw
bluetooth snd parport_pc wmi ppdev mac_hid mei_me lpc_ich shpchp mei
lp soundcore parport btrfs xor raid6_pq libcrc32c dm_crypt
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci psmouse
i915 libahci sdhci_pci sdhci i2c_algo_bit drm_kms_helper video drm
[last unloaded: videobuf2_memops]
[284151.968991] CPU: 3 PID: 1298 Comm: ip Tainted: GW
3.13.0-55-generic #94-Ubuntu
[284151.972108] Hardware name: LENOVO 2429CY7/2429CY7, BIOS G4ET94WW
(2.54 ) 05/23/2013
[284151.973847] task: 8800a3e6b000 ti: 8801ba4da000 task.ti:
8801ba4da000
[284151.975993] RIP: 0010:[8162b5b2]  [8162b5b2]
alloc_netdev_mqs+0x392/0x3c0
[284151.979497] RSP: 0018:8801ba4db870  EFLAGS: 00010206
[284151.982916] RAX: 000f4240 RBX: 8804082a3000 RCX:

[284151.986433] RDX:  RSI:  RDI:
8801ba4db7e0
[284151.989907] RBP: 8801ba4db8a0 R08: a9d3373c R09:
8801ba4db7d6
[284151.993381] R10: 323f6b16 R11: 2c647ed6 R12:
000f423f
[284151.996862] R13: 0001 R14: 8801ba4dba70 R15:
1312d000
[284152.000335] FS:  7efdbf71f740() GS:88041e2c()
knlGS:
[284152.003865] CS:  0010 DS:  ES:  CR0: 80050033
[284152.007382] CR2: 7ffd2acd1f88 CR3: 0001b39cc000 CR4:
001407e0
[284152.010870] Stack:
[284152.014321]  091f 88040431e800 8801ba4db958
a024c020
[284152.017798]  fff4 81cdab40 8801ba4db8e8
816357bb
[284152.021287]  8189d340 8801ba4db8f8 88040431e800
81cdab40
[284152.024770] Call Trace:
[284152.028167]  [816357bb] rtnl_create_link+0x5b/0x1c0
[284152.031558]  [816396aa] rtnl_newlink+0x4ba/0x610
[284152.034960]  [8163932f] ? rtnl_newlink+0x13f/0x610
[284152.038301]  [81635e85] rtnetlink_rcv_msg+0x95/0x250
[284152.041605]  [8161765e] ? __alloc_skb+0x7e/0x2b0
[284152.044552]  [81635df0] ? rtnetlink_rcv+0x30/0x30
[284152.047950]  [81654479] netlink_rcv_skb+0xa9/0xc0
[284152.051202]  [81635de8] rtnetlink_rcv+0x28/0x30
[284152.054429]  [81653b65] netlink_unicast+0xd5/0x1b0
[284152.057644]  [81653f4e] netlink_sendmsg+0x30e/0x680
[284152.060847]  [8160e08b] sock_sendmsg+0x8b/0xc0
[284152.064088]  [8160ddba] ? move_addr_to_kernel.part.14+0x5a/0x60
[284152.067276]  [8160ebb1] ? move_addr_to_kernel+0x21/0x30
[284152.070458]  [8160e499] ___sys_sendmsg+0x389/0x3a0
[284152.073628]  [816530ed] ? netlink_insert+0x14d/0x240
[284152.076764]  [8172f334] ? __do_page_fault+0x204/0x570
[284152.079919]  [810fd1fd] ? audit_filter_rules.isra.7+0x77d/0xf20
[284152.083061]  [8160f282] __sys_sendmsg+0x42/0x80
[284152.086180]  [8160f2d2] SyS_sendmsg+0x12/0x20
[284152.089268]  [81733d5d] system_call_fastpath+0x1a/0x1f
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html