linux-kernel - Re: [PATCH 2/2] cpusets: update tasks' cpus_allowed and mems

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:	Wed, 4 Jun 2008 13:02:43 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Jackson <pj@....com>
cc:	menage@...gle.com, miaox@...fujitsu.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] cpusets: update tasks' cpus_allowed and mems_allowed
 after CPU/NODE offline/online

On Wed, 4 Jun 2008, Paul Jackson wrote:

> How about also adding this check (NULL mm and struct subset cpus)
> to sched_setaffinity?
> 
> Granted, this pair of checks, in cpusets and sched_setaffinity,
> is getting to be a little more work than the PF_* flag.
> 

Yes, an alterative to the PF_CPU_BIND flag is to prevent calls to 
set_cpus_allowed() for kthreads that should not change affinity.

> I guess one question would be how hard we want to work to avoid
> consuming another PF_* flag.  I thought they were scarce, but I
> might be wrong.
> 

I think we both agree that in terms of the code itself, adding the flag 
and doing the check in set_cpus_allowed() is the optimal solution.  It can 
simply return -EINVAL for PF_CPU_BIND threads and the threads don't get 
moved.

It's debatable whether allocating an additional PF_* flag for this purpose 
is worthwhile.

I usually don't advocate against adding such bits that have a clear and 
defined purpose for the sole reason that perhaps later we will need 
additional bits that can't be worked around so easily as this one.  It's 
helpful to be conservative in allocating new flags but not at the expense 
of the code itself, especially when loopholes can easily be introduced 
that would have been otherwise prevented.

So I'll repost the patch and see where it goes.

		David
--
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/