linux-kernel - Re: [PATCH v4 15/18] x86/intel

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]

Message-ID: <20161017221739.GA5978@intel.com>
Date:   Mon, 17 Oct 2016 15:17:40 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        "H. Peter Anvin" <h.peter.anvin@...el.com>,
        Ingo Molnar <mingo@...e.hu>,
        Peter Zijlstra <peterz@...radead.org>,
        Stephane Eranian <eranian@...gle.com>,
        Borislav Petkov <bp@...e.de>,
        Dave Hansen <dave.hansen@...el.com>,
        Nilay Vaish <nilayvaish@...il.com>, Shaohua Li <shli@...com>,
        David Carrillo-Cisneros <davidcc@...gle.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Sai Prakhya <sai.praneeth.prakhya@...el.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v4 15/18] x86/intel_rdt: Add tasks files

On Tue, Oct 18, 2016 at 12:01:01AM +0200, Thomas Gleixner wrote:
> > +	/* Don't allow if there are processes in this group */
> > +	read_lock(&tasklist_lock);
> > +	for_each_process(p) {
> > +		if (p->closid == rdtgrp->closid) {
> > +			read_unlock(&tasklist_lock);
> > +			rdtgroup_kn_unlock(kn);
> > +			return -EBUSY;
> > +		}
> > +	}
> > +	read_unlock(&tasklist_lock);
> 
> I wonder, whether we should simply give those tasks back to the default
> group, same as we do with the cpus.

Leftover inherited semantics from the cgroup version. It would
simplify the code here (one less error case to handle) if we
did drop this.  I can't come up with a good reason why we'd
want to make the rmdir fail. I can imagine that a sysadmin
dealing with an application that is a fork bomb being happy
about not having to race to move things out so they can do the
rmdir.

-Tony