linux-kernel - Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

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, 28 Feb 2017 23:00:23 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...nel.org, tglx@...utronix.de, walken@...gle.com,
        boqun.feng@...il.com, kirill@...temov.name,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        npiggin@...il.com, kernel-team@....com
Subject: Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Tue, Feb 28, 2017 at 02:35:21PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 28, 2017 at 10:28:20PM +0900, Byungchul Park wrote:
> > On Tue, Feb 28, 2017 at 02:05:13PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote:
> > > > +#define MAX_XHLOCKS_NR 64UL
> > > 
> > > > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > > > +	if (tsk->xhlocks) {
> > > > +		void *tmp = tsk->xhlocks;
> > > > +		/* Disable crossrelease for current */
> > > > +		tsk->xhlocks = NULL;
> > > > +		vfree(tmp);
> > > > +	}
> > > > +#endif
> > > 
> > > > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > > > +	p->xhlock_idx = 0;
> > > > +	p->xhlock_idx_soft = 0;
> > > > +	p->xhlock_idx_hard = 0;
> > > > +	p->xhlock_idx_nmi = 0;
> > > > +	p->xhlocks = vzalloc(sizeof(struct hist_lock) * MAX_XHLOCKS_NR);
> > > 
> > > I don't think we need vmalloc for this now.
> > 
> > Really? When is a better time to do it?
> > 
> > I think the time creating a task is the best time to initialize it. No?
> 
> The place is fine, but I would use kmalloc() now (and subsequently kfree
> on the other end) for the allocation. Its not _that_ large anymore,
> right?

Did you mean that? OK, I will do it.

Thank you.