On Fri, Sep 2, 2016 at 11:13 AM, Brenden Blanco wrote:
> On Mon, Aug 29, 2016 at 10:46:38AM -0700, Tom Herbert wrote:
> [...]
>> Brenden, tracking down how the structure is freed needed a few steps,
>> please make sure the RCU requirements are well documented. Also, I'm
> Really? It's just bpf_pro
On Mon, Aug 29, 2016 at 10:46:38AM -0700, Tom Herbert wrote:
[...]
> Brenden, tracking down how the structure is freed needed a few steps,
> please make sure the RCU requirements are well documented. Also, I'm
Really? It's just bpf_prog_put->call_rcu(__bpf_prog_put_rcu). I suppose
what's missing is
On Fri, Sep 02, 2016 at 01:59:40AM +0300, Saeed Mahameed wrote:
> On Wed, Aug 31, 2016 at 4:50 AM, Brenden Blanco wrote:
> > On Tue, Aug 30, 2016 at 12:35:58PM +0300, Saeed Mahameed wrote:
[...]
> >> Sorry folks I am with Tariq on this, you can't just add a single
> >> instruction which is only va
On Thu, Sep 01, 2016 at 04:30:28PM -0700, Tom Herbert wrote:
[...]
> > Yep, but this is an unlikely condition and the critical code here is
> > much smaller and it is more clear that the rcu_read_lock here meant to
> > protect the ring->xdp_prog under this small xdp critical section in
> > comparis
On Thu, Sep 1, 2016 at 3:59 PM, Saeed Mahameed
wrote:
> On Wed, Aug 31, 2016 at 4:50 AM, Brenden Blanco wrote:
>> On Tue, Aug 30, 2016 at 12:35:58PM +0300, Saeed Mahameed wrote:
>>> On Mon, Aug 29, 2016 at 8:46 PM, Tom Herbert wrote:
>>> > On Mon, Aug 29, 2016 at 8:55 AM, Brenden Blanco
>>> >
On Wed, Aug 31, 2016 at 4:50 AM, Brenden Blanco wrote:
> On Tue, Aug 30, 2016 at 12:35:58PM +0300, Saeed Mahameed wrote:
>> On Mon, Aug 29, 2016 at 8:46 PM, Tom Herbert wrote:
>> > On Mon, Aug 29, 2016 at 8:55 AM, Brenden Blanco
>> > wrote:
>> >> On Mon, Aug 29, 2016 at 05:59:26PM +0300, Tariq
On Tue, Aug 30, 2016 at 12:35:58PM +0300, Saeed Mahameed wrote:
> On Mon, Aug 29, 2016 at 8:46 PM, Tom Herbert wrote:
> > On Mon, Aug 29, 2016 at 8:55 AM, Brenden Blanco
> > wrote:
> >> On Mon, Aug 29, 2016 at 05:59:26PM +0300, Tariq Toukan wrote:
> >>> Hi Brenden,
> >>>
> >>> The solution direc
On Mon, Aug 29, 2016 at 8:46 PM, Tom Herbert wrote:
> On Mon, Aug 29, 2016 at 8:55 AM, Brenden Blanco wrote:
>> On Mon, Aug 29, 2016 at 05:59:26PM +0300, Tariq Toukan wrote:
>>> Hi Brenden,
>>>
>>> The solution direction should be XDP specific that does not hurt the
>>> regular flow.
>> An rcu_re
Hi Brenden,
The solution direction should be XDP specific that does not hurt the
regular flow.
On 26/08/2016 11:38 PM, Brenden Blanco wrote:
Depending on the preempt mode, the bpf_prog stored in xdp_prog may be
freed despite the use of call_rcu inside bpf_prog_put. The situation is
possible w
On Mon, Aug 29, 2016 at 8:55 AM, Brenden Blanco wrote:
> On Mon, Aug 29, 2016 at 05:59:26PM +0300, Tariq Toukan wrote:
>> Hi Brenden,
>>
>> The solution direction should be XDP specific that does not hurt the
>> regular flow.
> An rcu_read_lock is _already_ taken for _every_ packet. This is 1/64th
On Mon, Aug 29, 2016 at 05:59:26PM +0300, Tariq Toukan wrote:
> Hi Brenden,
>
> The solution direction should be XDP specific that does not hurt the
> regular flow.
An rcu_read_lock is _already_ taken for _every_ packet. This is 1/64th of
that.
>
> On 26/08/2016 11:38 PM, Brenden Blanco wrote:
>
On Fri, Aug 26, 2016 at 01:38:08PM -0700, Brenden Blanco wrote:
> Depending on the preempt mode, the bpf_prog stored in xdp_prog may be
> freed despite the use of call_rcu inside bpf_prog_put. The situation is
> possible when running in PREEMPT_RCU=y mode, for instance, since the rcu
> callback for
Depending on the preempt mode, the bpf_prog stored in xdp_prog may be
freed despite the use of call_rcu inside bpf_prog_put. The situation is
possible when running in PREEMPT_RCU=y mode, for instance, since the rcu
callback for destroying the bpf prog can run even during the bh handling
in the mlx4
13 matches
Mail list logo
