[PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-27 Thread Marc Kleine-Budde
From: Eric Dumazet Zhang Yanmin reported crashes [1] and provided a patch adding a synchronize_rcu() call in can_rx_unregister() The main problem seems that the sockets themselves are not RCU protected. If CAN uses RCU for delivery, then sockets should be freed only after one RCU grace period.

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-14 Thread Eric Dumazet
On Sat, 2017-01-14 at 14:53 +0100, Oliver Hartkopp wrote: > Hello Eric, > > On 01/14/2017 04:43 AM, Liu Shuo wrote: > > On Thu 12.Jan'17 at 17:33:38 +0100, Oliver Hartkopp wrote: > >> On 01/12/2017 02:01 PM, Eric Dumazet wrote: > > >>> The main problem seems that the sockets themselves are not RC

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-14 Thread Oliver Hartkopp
Hello Eric, On 01/14/2017 04:43 AM, Liu Shuo wrote: On Thu 12.Jan'17 at 17:33:38 +0100, Oliver Hartkopp wrote: On 01/12/2017 02:01 PM, Eric Dumazet wrote: The main problem seems that the sockets themselves are not RCU protected. If CAN uses RCU for delivery, then sockets should be freed onl

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-13 Thread Liu Shuo
On Thu 12.Jan'17 at 17:33:38 +0100, Oliver Hartkopp wrote: On 01/12/2017 02:01 PM, Eric Dumazet wrote: On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote: But my main concern is: The reason why can_rx_delete_receiver() was introduced was the need to remove a huge number of receivers wi

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-12 Thread Eric Dumazet
On Thu, 2017-01-12 at 14:40 -0800, william.c.robe...@intel.com wrote: > From: Zhang Yanmin > > The patch is for fix the below kernel panic: > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0 Same patch was sent earlier, and we gave a

[PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-12 Thread william . c . roberts
From: Zhang Yanmin The patch is for fix the below kernel panic: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: [] security_sock_rcv_skb+0x4c/0x60 [] sk_filter+0x41/0x210 [] sock_queue_rcv_skb+0x53/0x3a0 [] raw_rcv+0

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-12 Thread Oliver Hartkopp
On 01/12/2017 02:01 PM, Eric Dumazet wrote: On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote: But my main concern is: The reason why can_rx_delete_receiver() was introduced was the need to remove a huge number of receivers with can_rx_unregister(). When you call synchronize_rcu() aft

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-12 Thread Eric Dumazet
On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote: > > On 01/12/2017 07:33 AM, Liu ShuoX wrote: > > From: Zhang Yanmin > > > > The patch is for fix the below kernel panic: > > BUG: unable to handle kernel NULL pointer dereference at (null) > > IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-12 Thread Oliver Hartkopp
On 01/12/2017 07:33 AM, Liu ShuoX wrote: From: Zhang Yanmin The patch is for fix the below kernel panic: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: [] security_sock_rcv_skb+0x4c/0x60 [] sk_filter+0x41/0x210 [

[PATCH] can: Fix kernel panic at security_sock_rcv_skb

2017-01-11 Thread Liu ShuoX
From: Zhang Yanmin The patch is for fix the below kernel panic: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: [] security_sock_rcv_skb+0x4c/0x60 [] sk_filter+0x41/0x210 [] sock_queue_rcv_skb+0x53/0x3a0 [] raw_rcv+0