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]
Message-ID: <20170710175418.ghphbgunhswrravh@intel.com>
Date:   Mon, 10 Jul 2017 10:54:18 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Shivappa Vikas <vikas.shivappa@...el.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org, hpa@...or.com,
        peterz@...radead.org, ravi.v.shankar@...el.com,
        fenghua.yu@...el.com, andi.kleen@...el.com
Subject: Re: [PATCH 21/21] x86/intel_rdt/mbm: Handle counter overflow

On Fri, Jul 07, 2017 at 08:50:40AM +0200, Thomas Gleixner wrote:
> Aside of that, are you really serious about serializing the world and
> everything on a single global mutex?

It would be nice to not do that, but there are challenges. At
any instant someone else might run:

# rmdir /sys/fs/resctrl/{some_control_group}

and blow away the control group and all the monitor groups under
it.

Someone else might do:

# echo 0 > /sys/devices/system/cpu/cpu{N}/online

where "N" is the last online cpu in a domain, which will
blow away an rdt_domain structure and ask kernfs to remove
some monitor files from every monitor directory.


If we change how we handle rdt_domains to

1) Not delete them when last CPU goes away (and re-use them
   if they come back)
2) Have a safe way to search rdt_resource.domains for a domain
   that we know is there even though another may be in the middle
   of being added

Then we could probably make:

$ cat /sys/fs/restrl/ ... /llc_occupancy

etc. not need to grab the mutex.  We'd still need something
to protect against a cross processor interrupt geting in the
middle of the access to IA32_QM_EVTSEL/IA32_QM_CTR and for
MBM counters to serialize access to mbm_state ... but it would
be a lot finer granularity.

-Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ