Peter Zijlstra writes:
> On Thu, May 28, 2015 at 11:37:17AM +0930, Rusty Russell wrote:
>> That's rcu_read_lock_sched_held, not rcu_held_lock_sched_held().
>>
>> Also, your unlikely is weird and backwards.
>>
>> I changed it as below, and folded. It's in modules-next.
>>
>> I'm now going to do
On Thu, May 28, 2015 at 11:37:17AM +0930, Rusty Russell wrote:
> That's rcu_read_lock_sched_held, not rcu_held_lock_sched_held().
>
> Also, your unlikely is weird and backwards.
>
> I changed it as below, and folded. It's in modules-next.
>
> I'm now going to do some *actual* testing, and I'll
Peter Zijlstra writes:
> On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote:
Hmm, this blows up:
> +static void module_assert_mutex_or_preempt(void)
> +{
> +#ifdef CONFIG_LOCKDEP
> + if (!unlikely(debug_locks))
> + return;
> +
> + WARN_ON(!rcu_held_lock_sched_held(
On Wed, Apr 15, 2015 at 02:11:37PM +0930, Rusty Russell wrote:
> Peter Zijlstra writes:
> > On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote:
> >
> >> I was tempted to sneak in those module rcu fixes for 4.1, but seeing
> >> Ingo's comments I'll wait for 4.2.
> >
> > I can get you a n
Peter Zijlstra writes:
> On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote:
>
>> I was tempted to sneak in those module rcu fixes for 4.1, but seeing
>> Ingo's comments I'll wait for 4.2.
>
> I can get you a new version of that if you want. See below. The fixups
> are unmodified of the
On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote:
> I was tempted to sneak in those module rcu fixes for 4.1, but seeing
> Ingo's comments I'll wait for 4.2.
I can get you a new version of that if you want. See below. The fixups
are unmodified of the posting (patches 2,3).
---
Subje
Peter Zijlstra writes:
> This series is aimed at making __module_address() go fast(er).
>
> The reason for doing so is that most stack unwinders use kernel_text_address()
> to validate each frame. Perf and ftrace (can) end up doing a lot of stack
> traces from performance sensitive code.
>
> On th
* Peter Zijlstra wrote:
> This series is aimed at making __module_address() go fast(er).
>
> The reason for doing so is that most stack unwinders use kernel_text_address()
> to validate each frame. Perf and ftrace (can) end up doing a lot of stack
> traces from performance sensitive code.
>
>
This series is aimed at making __module_address() go fast(er).
The reason for doing so is that most stack unwinders use kernel_text_address()
to validate each frame. Perf and ftrace (can) end up doing a lot of stack
traces from performance sensitive code.
On the way there it:
- annotates and sa
9 matches
Mail list logo