On Thu, 2018-01-18 at 11:26 -0800, Tom Herbert wrote:
> On Thu, Jan 18, 2018 at 10:08 AM, Eric Dumazet wrote:
> > On Thu, 2018-01-18 at 09:46 -0800, Tom Herbert wrote:
> > >
> > > Then that's increasing the udp_sock structure size for a narrow use
> > > case which will get push back. I think it's
On Thu, Jan 18, 2018 at 10:08 AM, Eric Dumazet wrote:
> On Thu, 2018-01-18 at 09:46 -0800, Tom Herbert wrote:
>>
>> Then that's increasing the udp_sock structure size for a narrow use
>> case which will get push back. I think it's going to be better to
>> stick with one sock pointer. We could mayb
On Thu, 2018-01-18 at 09:46 -0800, Tom Herbert wrote:
>
> Then that's increasing the udp_sock structure size for a narrow use
> case which will get push back. I think it's going to be better to
> stick with one sock pointer. We could maybe redefine sk_user_data as a
> pointer to an allocated struc
On Thu, Jan 18, 2018 at 7:40 AM, James Chapman wrote:
> On 18 January 2018 at 15:18, Guillaume Nault wrote:
>> On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote:
>>> From: James Chapman
>>> Date: Wed, 17 Jan 2018 11:13:33 +
>>>
>>> > On 16 January 2018 at 19:00, David Miller wrot
On Wed, Jan 17, 2018 at 11:25 AM, David Miller wrote:
> From: James Chapman
> Date: Wed, 17 Jan 2018 11:13:33 +
>
>> On 16 January 2018 at 19:00, David Miller wrote:
>>> From: Tom Herbert
>>> Date: Tue, 16 Jan 2018 09:36:41 -0800
>>>
sk_user_data is set with the sk_callback lock held i
On 18 January 2018 at 16:29, Guillaume Nault wrote:
> On Thu, Jan 18, 2018 at 03:40:52PM +, James Chapman wrote:
>> On 18 January 2018 at 15:18, Guillaume Nault wrote:
>> > On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote:
>> >> If all else was equal, even though it doesn't make m
On Thu, Jan 18, 2018 at 03:40:52PM +, James Chapman wrote:
> On 18 January 2018 at 15:18, Guillaume Nault wrote:
> > On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote:
> >> If all else was equal, even though it doesn't make much sense to KCM
> >> attach L2TP sockets to KCM, I would
On 18 January 2018 at 15:18, Guillaume Nault wrote:
> On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote:
>> From: James Chapman
>> Date: Wed, 17 Jan 2018 11:13:33 +
>>
>> > On 16 January 2018 at 19:00, David Miller wrote:
>> >> From: Tom Herbert
>> >> Date: Tue, 16 Jan 2018 09:36
On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote:
> From: James Chapman
> Date: Wed, 17 Jan 2018 11:13:33 +
>
> > On 16 January 2018 at 19:00, David Miller wrote:
> >> From: Tom Herbert
> >> Date: Tue, 16 Jan 2018 09:36:41 -0800
> >>
> >>> sk_user_data is set with the sk_callbac
From: James Chapman
Date: Wed, 17 Jan 2018 11:13:33 +
> On 16 January 2018 at 19:00, David Miller wrote:
>> From: Tom Herbert
>> Date: Tue, 16 Jan 2018 09:36:41 -0800
>>
>>> sk_user_data is set with the sk_callback lock held in code below.
>>> Should be able to take the lock earlier can do
On 16 January 2018 at 19:00, David Miller wrote:
> From: Tom Herbert
> Date: Tue, 16 Jan 2018 09:36:41 -0800
>
>> sk_user_data is set with the sk_callback lock held in code below.
>> Should be able to take the lock earlier can do this check under the
>> lock.
>
> csock, and this csk, is obtained
From: Tom Herbert
Date: Tue, 16 Jan 2018 09:36:41 -0800
> sk_user_data is set with the sk_callback lock held in code below.
> Should be able to take the lock earlier can do this check under the
> lock.
csock, and this csk, is obtained from an arbitrary one of the
process's FDs. It can be any so
On Sun, Jan 14, 2018 at 3:32 AM, James Chapman wrote:
> SIOCKCMATTACH writes a connected socket's sk_user_data for its own
> use. Prevent it doing so if the socket's sk_user_data is already set
> since some sockets (e.g. encapsulated sockets) use sk_user_data
> internally.
>
> This issue was found
On Tue, 2018-01-16 at 11:44 +0100, Guillaume Nault wrote:
>
> Tom, if I understand KCM correctly, it only makes sense to attach it to
> SOCK_STREAM sockets. Shouldn't that be enforced? Maybe we should
> restrict it even further, so that only known KCM-safe sockets could be
> attached (that is, rej
On Sun, Jan 14, 2018 at 11:32:57AM +, James Chapman wrote:
> SIOCKCMATTACH writes a connected socket's sk_user_data for its own
> use. Prevent it doing so if the socket's sk_user_data is already set
> since some sockets (e.g. encapsulated sockets) use sk_user_data
> internally.
>
> diff --git
SIOCKCMATTACH writes a connected socket's sk_user_data for its own
use. Prevent it doing so if the socket's sk_user_data is already set
since some sockets (e.g. encapsulated sockets) use sk_user_data
internally.
This issue was found by syzbot.
kernel BUG at net/l2tp/l2tp_ppp.c:176!
invalid opcode
16 matches
Mail list logo