On 03/07/2018 04:25 AM, John Fastabend wrote:
[...]
> Thought about this a bit more and chatted with Daniel a bit. I think
> a better solution is to set data_start = data_end = 0 by default in the
> sendpage case. This will disallow any read/writes into the sendpage
> data. Then if the user needs
From: John Fastabend
Date: Tue, 6 Mar 2018 19:25:01 -0800
> What do you think?
Sounds good from your description, I can't wait to see it :-)
On 03/06/2018 10:18 AM, John Fastabend wrote:
> On 03/06/2018 07:47 AM, David Miller wrote:
>> From: John Fastabend
>> Date: Mon, 5 Mar 2018 23:06:01 -0800
>>
>>> On 03/05/2018 10:42 PM, David Miller wrote:
From: John Fastabend
Date:
On 03/06/2018 07:47 AM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 5 Mar 2018 23:06:01 -0800
>
>> On 03/05/2018 10:42 PM, David Miller wrote:
>>> From: John Fastabend
>>> Date: Mon, 5 Mar 2018 22:22:21 -0800
>>>
All I meant
From: John Fastabend
Date: Mon, 5 Mar 2018 23:06:01 -0800
> On 03/05/2018 10:42 PM, David Miller wrote:
>> From: John Fastabend
>> Date: Mon, 5 Mar 2018 22:22:21 -0800
>>
>>> All I meant by this is if an application uses sendfile() call
>>>
On 03/05/2018 10:42 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 5 Mar 2018 22:22:21 -0800
>
>> All I meant by this is if an application uses sendfile() call
>> there is no good way to know when/if the kernel side will copy or
>> xmit the data. So a
From: John Fastabend
Date: Mon, 5 Mar 2018 22:22:21 -0800
> All I meant by this is if an application uses sendfile() call
> there is no good way to know when/if the kernel side will copy or
> xmit the data. So a reliable user space application will need to
> only
On 03/05/2018 09:42 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 5 Mar 2018 14:53:08 -0800
>
>> I decided to make the default no-copy to mirror the existing
>> sendpage() semantics and then to add the flag later. The flag
>> support is not in this series
From: John Fastabend
Date: Mon, 5 Mar 2018 14:53:08 -0800
> I decided to make the default no-copy to mirror the existing
> sendpage() semantics and then to add the flag later. The flag
> support is not in this series simply because I wanted to get the
> base support in
On 03/05/2018 01:40 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 05 Mar 2018 11:51:22 -0800
>
>> BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
>> SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
>> case and in the
From: John Fastabend
Date: Mon, 05 Mar 2018 11:51:22 -0800
> BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and
> SK_DROP. Returning SK_DROP free's the copied data in the sendmsg
> case and in the sendpage case leaves the data untouched. Both cases
> return
This implements a BPF ULP layer to allow policy enforcement and
monitoring at the socket layer. In order to support this a new
program type BPF_PROG_TYPE_SK_MSG is used to run the policy at
the sendmsg/sendpage hook. To attach the policy to sockets a
sockmap is used with a new program attach type
12 matches
Mail list logo