linux-kernel - Re: [PATCH] cpuset: fix allocating page cache/slab object on the unallowed node when memory spread is set

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: <4993BA44.2070809@cn.fujitsu.com>
Date:	Thu, 12 Feb 2009 13:57:24 +0800
From:	Miao Xie <miaox@...fujitsu.com>
To:	Paul Menage <menage@...gle.com>
CC:	Nick Piggin <nickpiggin@...oo.com.au>, Paul Jackson <pj@....net>,
	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
	Derek Fults <dfults@....com>
Subject: Re: [PATCH] cpuset: fix allocating page cache/slab object on the
 unallowed node when memory spread is set

on 2009-2-12 9:19 Paul Menage wrote:
> On Wed, Feb 11, 2009 at 4:54 PM, Nick Piggin <nickpiggin@...oo.com.au> wrote:
>> It would be possible, depending on timing, for the allocating thread to
>> see either pre or post mems_allowed even if access was fully locked.
> 
> Right - seeing either the pre set or the post set is fine.
> 
>> The only difference is that a partially changed mems_allowed could be
>> seen. But what does this really mean? Some combination of the new and
>> the old nodes. I don't think this is too much of a problem.
> 
> But if the old and new nodes are disjoint, that could lead to seeing no nodes.
> 
> Also, having the results of cpuset_zone_allowed() and
> cpuset_current_mems_allowed change at random times over the course of
> a call to alloc_pages() might cause interesting effects (e.g. we make
> progress freeing pages from one set of nodes, and then call
> get_page_from_freelist() on a different set of nodes).
> 
>> This could work if we *really* need an atomic snapshot of mems_allowed.
>> seqcount synchronisation would be an alternative too that could allow
>> sleeping more easily than SRCU (OTOH if you don't need sleeping, then
>> RCU should be faster than seqcount).
>>
>> But I'm not convinced we do need this to be atomic.
> 
> It's possible that I'm being overly-paranoid here. The decision to
> make mems_allowed updates be purely pulled by the task itself predates
> my involvement with cpusets code by a long time. Paul Jackson (CC'd)
> may have opinions here, but I suspect his sgi.com email address no
> longer works, and I don't have any more recent address for him.

I think it's pj@....net(CC'd).

Author: Paul Jackson <pj@....com>
Date:   Fri Oct 3 15:23:42 2008 -0700

    cpusets: remove pj from cpuset maintainers

    Remove myself from the kernel MAINTAINERS file for cpusets.  I am leaving
    SGI and probably will not be active in Linux kernel work.  I can be
    reached at <pj@....net>.  Contact Derek Fults <dfults@....com> for future
    SGI+cpuset related issues.  I'm off to the next chapter of this good life.

    Signed-off-by: Paul Jackson <pj@....com>
    Cc: Paul Menage <menage@...gle.com>
    Cc: Derek Fults <dfults@....com>
    Cc: John Hesterberg <jh@....com>
    Cc: Paul Jackson <pj@....net>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

Thanks!
Miao

> 
> Paul
> 
> 
> 


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