linux-kernel - Re: [PATCH] x86/intel_rdt: reinitialize cbm for new group allocation

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:   Mon, 9 Jan 2017 23:03:59 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Fenghua Yu <fenghua.yu@...el.com>
cc:     Shaohua Li <shli@...com>, LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] x86/intel_rdt: reinitialize cbm for new group
 allocation

On Mon, 9 Jan 2017, Fenghua Yu wrote:
> On Fri, Jan 06, 2017 at 04:05:19PM -0800, Shaohua Li wrote:
> But since you come here now,  I would think reseting the CBM in
> closid_free() is better.

No. closid_free() is the wrong place. closid_alloc/free() merily deal with
the bitmap and nothing else.

If you really want to do that, then this needs a seperate function called
from rmdir.

> The reason is user can see "right" max_cbm even through rdmsr after
> rmdir, ie no gap for cbm values between rmdir and the next mkdir.

And the value pf this is?

The closid is not usable after the rmdir, so it's really completely
uninteresting when the user can read the old value from that configuration
MSR.

When the closid is reused then it hardly matters either what's in those cbm
values (the old or max_cbm).

Thanks,

	tglx