linux-kernel - Re: [RFC] cpuset relative memory policies

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: <Pine.LNX.4.64.0710311402300.22599@schroedinger.engr.sgi.com>
Date:	Wed, 31 Oct 2007 14:05:20 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Paul Jackson <pj@....com>
cc:	rientjes@...gle.com, Lee.Schermerhorn@...com,
	linux-kernel@...r.kernel.org, ak@...e.de
Subject: Re: [RFC] cpuset relative memory policies - second choice

On Wed, 31 Oct 2007, Paul Jackson wrote:

> > Make both policy and the mode char?
> 
> Well, the mpol_nodemask_mode already is char.  So I guess you're
> asking if we should change 'policy' to type char as well.

Right.

> > Could we shorten the mpol_nodemask_mode to mode?
> 
> Huh - I don't know what "shorten ... to mode" means.  If it means
> "shorten ... to char", then see my previous comment above.

No it means shorted the identifier which is a bit long for a structure 
member.

> > Hmmm... I would rather have numactl manage this flag
> 
> Well, numactl is a command line utility.  It doesn't manage this flag
> as an -alternative- to some sort of changes to the mbind, set_mempolicy
> and get_mempolicy calls, but rather layers on top of changes to those
> system calls.  So I'm not sure what you mean, but I guess it is not
> relevant to this patch discussion.

s/numactl/libnuma/

> The question is:
> 
>     Should this mode be per-task, or per-system call?
> 
> The basic reason that I went with an additional per-task modal
> state, rather than a modal flag for each mbind, set_mempolicy and
> get_mempolicy call was to reduce the likely rate of bugs in user
> level C code using this API.

What bugs?

>     Programs that code to this API in C usually first spend some number
>     of lines of code preparing bitmasks that represent sets of nodes,
>     which they will then pass into these mempolicy system calls.
> 
>     The bits are numbered differently between Choices A and B.    

Right.

>     If a piece of code adapts Choice B numbering, because it is
>     better suited to that codes needs, and if we used your suggested
>     per-system call flag, then if they miss passing in the new special
>     flag on -even-one- mbind, set_mempolicy or get_mempolicy system
>     call, they have an obscure code bug.  They will be passing in
>     a bitmask that they calculated using Choice B node numbering,
>     but (implicitly) telling the kernel to interpret that bitmask
>     using Choice A semantics.

But that is only done in libnuma. User code does not call this directly.

> Why do you prefer a per-system call modal flag, rather than a per-task
> modal flag?

It is a change of behavior of the function call. If some mysterious flag 
somewhere influences that behavior then we have difficulties finding bugs. 
The presence of the flag makes it obvious to the reviewer that we do 
something special here.

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