linux-kernel - Re: [PATCH v2 1/2] sched/cputime: Use only pi_lock to protect sum_exec

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] [day] [month] [year] [list]

Message-ID: <20160905191617.GC3318@worktop.controleur.wifipass.org>
Date:   Mon, 5 Sep 2016 21:16:17 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Stanislaw Gruszka <sgruszka@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Mike Galbraith <mgalbraith@...e.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Rik van Riel <riel@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wanpeng Li <wanpeng.li@...mail.com>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v2 1/2] sched/cputime: Use only pi_lock to protect
 sum_exec_runtime read

On Mon, Sep 05, 2016 at 04:16:57PM +0200, Stanislaw Gruszka wrote:
> On Mon, Sep 05, 2016 at 11:13:01AM +0200, Stanislaw Gruszka wrote:
> > Currently we protect 64bit sum_exec_runtime read on 32bit cpus using
> > task_rq_lock() which internally takes t->pi_lock and rq->lock. Taking
> > rq->lock is not needed in this case.
> 
> I looked more at kernel/sched/ code and now I'm not sure about this.
> I assumed that update_curr() is called with rq->curr->pi_lock, but
> looks like it can be called with some other task->pi_lock not
> necessary the rq->curr, hence looks that we need rq->lock to assure
> protection

Correct, rq->lock needs be held for this.

update_curr() is called from places like the tick and schedule(),
neither of which hold pi_lock.