Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754311AbbFPGq5 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 16 Jun 2015 02:46:57 -0400
Received: from mail-pd0-f174.google.com ([209.85.192.174]:33211 "EHLO
	mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752130AbbFPGqu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 16 Jun 2015 02:46:50 -0400
Message-ID: <557FC657.9080705@plumgrid.com>
Date: Mon, 15 Jun 2015 23:46:47 -0700
From: Alexei Starovoitov <ast@plumgrid.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Daniel Wagner <daniel.wagner@bmw-carit.de>, paulmck@linux.vnet.ibm.com
CC: LKML <linux-kernel@vger.kernel.org>
Subject: Re: call_rcu from trace_preempt
References: <557F509D.2000509@plumgrid.com> <20150615230702.GB3913@linux.vnet.ibm.com> <557F7764.5060707@plumgrid.com> <20150616021458.GE3913@linux.vnet.ibm.com> <557FB7E1.6080004@plumgrid.com> <557FBCCD.4050804@bmw-carit.de> <557FC14C.9080901@plumgrid.com> <557FC35F.1020506@bmw-carit.de>
In-Reply-To: <557FC35F.1020506@bmw-carit.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1532
Lines: 38

On 6/15/15 11:34 PM, Daniel Wagner wrote:
> On 06/16/2015 08:25 AM, Alexei Starovoitov wrote:
>> On 6/15/15 11:06 PM, Daniel Wagner wrote:
>>>> with the above 'fix' the trace.patch is now passing.
>>> It still crashes for me with the original test program
>>>
>>> [  145.908013]  [<ffffffff810d1da1>] ? __rcu_reclaim+0x101/0x3d0
>>> [  145.908013]  [<ffffffff810d1ca0>] ? rcu_barrier_func+0x250/0x250
>>> [  145.908013]  [<ffffffff810abc03>] ?
>>> trace_hardirqs_on_caller+0xf3/0x240
>>> [  145.908013]  [<ffffffff810d9afa>] rcu_do_batch+0x2ea/0x6b0
>>
>> yes. full bpf test still crashes.
>> That's why I said trace.patch is passing ;)
>> There is something else in there. One 'fix' at a time.
>
> Ah, sorry, I read it is working now :) Anyway, I'll keep looking
> as well.
>
> Yesterday I wrote a small torture program for the map
> implementation. Just to rule out memory corruption there.
> Are you interested in it? If yes I could clean it a bit.

of course!
We already have samples/bpf/test_maps.c that stresses map
access from user space and lib/test_bpf.c that stress JIT
and interpreter from the kernel.
Looking at your test, I think it doesn't buy as much doing it
from the kernel?
If so, I think would be great to add it to test_maps.c

Will read it more carefully tomorrow.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/