Re: [PATCH net-next v2 03/16] l2tp: don't use inet_shutdown on tunnel destroy

2018-02-12 Thread Guillaume Nault 
On Mon, Feb 12, 2018 at 10:11:07AM +, James Chapman wrote:
> Previously, if a tunnel was closed, we called inet_shutdown to mark
> the socket as unconnected such that userspace would get errors and
> then close the socket. This could race with userspace closing the
> socket. Instead, leave userspace to close the socket in its own time
> (our tunnel will be detached anyway).
> 
Acked-by: Guillaume Nault

Re: [PATCH net-next v2 03/16] l2tp: don't use inet_shutdown on tunnel destroy

2018-02-12 Thread James Chapman 
On 12/02/18 16:22, David Miller wrote:
> From: James Chapman 
> Date: Mon, 12 Feb 2018 10:11:07 +
>
>> Previously, if a tunnel was closed, we called inet_shutdown to mark
>> the socket as unconnected such that userspace would get errors and
>> then close the socket. This could race with userspace closing the
>> socket. Instead, leave userspace to close the socket in its own time
>> (our tunnel will be detached anyway).
>>
>> Fixes: 309795f4be ("l2tp: Add netlink control API for L2TP")
>  ...
>>  BUG: unable to handle kernel NULL pointer dereference at 00a0
>>  IP: __lock_acquire+0x263/0x1630
> Ok, all of these are like this.
>
> Please fix this up, put the kernel log message into the message body
> and add an appropriate signoff.
>
> Thank you.

Oh stupid me. I'll do so straight away. Sorry!

Re: [PATCH net-next v2 03/16] l2tp: don't use inet_shutdown on tunnel destroy

2018-02-12 Thread David Miller 
From: James Chapman 
Date: Mon, 12 Feb 2018 10:11:07 +

> Previously, if a tunnel was closed, we called inet_shutdown to mark
> the socket as unconnected such that userspace would get errors and
> then close the socket. This could race with userspace closing the
> socket. Instead, leave userspace to close the socket in its own time
> (our tunnel will be detached anyway).
> 
> Fixes: 309795f4be ("l2tp: Add netlink control API for L2TP")
 ...
>  BUG: unable to handle kernel NULL pointer dereference at 00a0
>  IP: __lock_acquire+0x263/0x1630

Ok, all of these are like this.

Please fix this up, put the kernel log message into the message body
and add an appropriate signoff.

Thank you.