linux-kernel - Re: [PATCH] percpu: use raw_local_irq_* in _this

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Feb 2012 22:53:38 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Yong Zhang <yong.zhang0@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] percpu: use raw_local_irq_* in _this_cpu op

On Tue, Feb 14, 2012 at 3:40 PM, Yong Zhang <yong.zhang0@...il.com> wrote:
> On Tue, Feb 14, 2012 at 11:30:06AM +0800, Ming Lei wrote:
>> Hi,
>>
>> On Tue, Feb 14, 2012 at 1:23 AM, Tejun Heo <tj@...nel.org> wrote:
>> > On Mon, Feb 13, 2012 at 07:03:38PM +0800, Ming Lei wrote:
>> >> It doesn't make sense to trace irq off or do irq flags
>> >> lock proving inside 'this_cpu' operations, so replace local_irq_*
>> >> with raw_local_irq_* in 'this_cpu' op.
>> >>
>> >> Also the patch fixes one lockdep warning[1], which is caused
>> >> by the added local_irq_save/restore(flags) in this_cpu_inc
>> >> called by __debug_atomic_inc: kernel/lockdep.c
>> >
>> > I think this isn't gonna hurt anything but I don't understand why the
>> > lockdep warning is triggering when using traced version. ?Can you
>> > please explain that in a bit more detail in the patch description?
>>
>> In trace_hardirqs_on_caller:kernel/lockdep.c, __debug_atomic_inc
>> will be called to add on 'this_cpu' variable, so may introduce recursive
>> trace_hardirqs_on|off_caller called.
>
> Don't we need to prevent this kind of recursion first?

IMO, lockdep is designed as not tracing or proving itself, and
just avoiding to trace __debug_atomic_inc is enough to fix the warning,
so it is not necessary to enlarge the protection range with
current->lockdep_recursion.

>
> UNTESTED patch, I guess it'll smooth your concern.
> ---
> diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> index 8889f7d..028b4c5 100644
> --- a/kernel/lockdep.c
> +++ b/kernel/lockdep.c
> @@ -2561,6 +2561,8 @@ void trace_hardirqs_on_caller(unsigned long ip)
>        if (unlikely(!debug_locks || current->lockdep_recursion))
>                return;
>
> +       current->lockdep_recursion = 1;
> +
>        if (unlikely(current->hardirqs_enabled)) {
>                /*
>                 * Neither irq nor preemption are disabled here
> @@ -2568,7 +2570,7 @@ void trace_hardirqs_on_caller(unsigned long ip)
>                 * in a stat is not a big deal.
>                 */
>                __debug_atomic_inc(redundant_hardirqs_on);
> -               return;
> +               goto out;
>        }
>
>        /*
> @@ -2577,23 +2579,24 @@ void trace_hardirqs_on_caller(unsigned long ip)
>         * enabled.. someone messed up their IRQ state tracing.
>         */
>        if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> -               return;
> +               goto out;
>
>        /*
>         * See the fine text that goes along with this variable definition.
>         */
>        if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
> -               return;
> +               goto out;
>
>        /*
>         * Can't allow enabling interrupts while in an interrupt handler,
>         * that's general bad form and such. Recursion, limited stack etc..
>         */
>        if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
> -               return;
> +               goto out;
>
> -       current->lockdep_recursion = 1;
>        __trace_hardirqs_on_caller(ip);
> +
> +out:
>        current->lockdep_recursion = 0;
>  }
>  EXPORT_SYMBOL(trace_hardirqs_on_caller);


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