linux-kernel - Re: [patch] sched: prevent bound kthreads from changing cpus

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: <20080605152953.dcfefa47.pj@sgi.com>
Date:	Thu, 5 Jun 2008 15:29:53 -0500
From:	Paul Jackson <pj@....com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	mingo@...e.hu, peterz@...radead.org, menage@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] sched: prevent bound kthreads from changing
 cpus_allowed

A couple of questions on this:

 1) Sometimes threads are bound to a set of CPUs, such as the CPUs
    on a particular node:

	drivers/pci/pci-driver.c:       set_cpus_allowed_ptr(current, nodecpumask);
	net/sunrpc/svc.c:               set_cpus_allowed_ptr(current, nodecpumask);

    Such cases can't invoke kthread_bind(), as that only binds to a single CPU.
    I only see one place in your patch that sets PF_THREAD_BOUND; would it make
    sense for such multi-CPU binds as above to be PF_THREAD_BOUND as well?

 2) Sometimes calls to kthread_bind are binding to any online cpu, such as in:

	drivers/infiniband/hw/ehca/ehca_irq.c:	kthread_bind(cct->task, any_online_cpu(cpu_online_map));

    In such cases, the PF_THREAD_BOUND seems inappropriate.  The caller of
    kthread_bind() really doesn't seem to care where that thread is bound;
    they just want it on a CPU that is still online.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/