linux-kernel - Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 28 Jul 2017 06:25:55 +0200
From:   Willy Tarreau <w@....eu>
To:     Leo Yan <leo.yan@...aro.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joel Fernandes <joelaf@...gle.com>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

Hi Leo,

There was no upstream commit ID here but I found it in mainline here :

  commit 109704492ef637956265ec2eb72ae7b3b39eb6f4
  Author: Joel Fernandes <joelaf@...gle.com>
  Date:   Thu Oct 20 00:34:00 2016 -0700

    pstore: Make spinlock per zone instead of global
    
What worries me is that some later fixes were issued, apparently to fix
an oops and a warning after this patch :

  commit 76d5692a58031696e282384cbd893832bc92bd76
  Author: Kees Cook <keescook@...omium.org>
  Date:   Thu Feb 9 15:43:44 2017 -0800

    pstore: Correctly initialize spinlock and flags
    
    The ram backend wasn't always initializing its spinlock correctly. Since
    it was coming from kzalloc memory, though, it was harmless on
    architectures that initialize unlocked spinlocks to 0 (at least x86 and
    ARM). This also fixes a possibly ignored flag setting too.

and :

  commit e9a330c4289f2ba1ca4bf98c2b430ab165a8931b
  Author: Kees Cook <keescook@...omium.org>
  Date:   Sun Mar 5 22:08:58 2017 -0800

    pstore: Use dynamic spinlock initializer
    
    The per-prz spinlock should be using the dynamic initializer so that
    lockdep can correctly track it. Without this, under lockdep, we get a
    warning at boot that the lock is in non-static memory.

So I'm fine with merging this patch as long as Kees is OK with this and
we know what exact patch series needs to be merged.

Also, the information you added to the commit message references a trace
on a 4.4 kernel. Do you confirm that you got the same issue on 3.10 ? I
just prefer to avoid blindly backporting sensitive patches if they're not
absolutely needed.

> [   65.103905] hrtimer: interrupt took 2759375 ns
> [   65.108721] BUG: spinlock recursion on CPU#0, kschedfreq:0/1246
> [   65.108760]  lock: buffer_lock+0x0/0x38, .magic: dead4ead, .owner: kschedfreq:0/1246, .owner_cpu: 0
> [   65.108779] CPU: 0 PID: 1246 Comm: kschedfreq:0 Not tainted 4.4.74-07294-g5c996a9-dirty #130

Thanks!
willy