linux-kernel - Re: [RFC][PATCH 0/4] memcg: add support for hwpoison testing

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: <20090901022514.GA11974@localhost>
Date:	Tue, 1 Sep 2009 10:25:14 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mel@....ul.ie>,
	"lizf@...fujitsu.com" <lizf@...fujitsu.com>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"menage@...gle.com" <menage@...gle.com>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC][PATCH 0/4] memcg: add support for hwpoison testing

On Tue, Sep 01, 2009 at 07:46:26AM +0800, KAMEZAWA Hiroyuki wrote:
> On Mon, 31 Aug 2009 18:26:40 +0800
> Wu Fengguang <fengguang.wu@...el.com> wrote:
> 
> > Hi all,
> > 
> > In hardware poison testing, we want to inject hwpoison errors to pages
> > of a collection of selected tasks, so that random tasks (eg. init) won't
> > be killed in stress tests and lead to test failure.
> > 
> > Memory cgroup provides an ideal tool for tracking and testing these target
> > process pages. All we have to do is to
> > - export the memory cgroup id via cgroupfs
> > - export two functions/structs for hwpoison_inject.c
> > 
> > This might be an unexpected usage of memory cgroup. The last patch and this
> > script demonstrates how the exported interfaces are to be used to limit the
> > scope of hwpoison injection.
> > 
> > 	test -d /cgroup/hwpoison && rmdir /cgroup/hwpoison
> > 	mkdir /cgroup/hwpoison
> > 
> > 	usemem -m 100 -s 100 &   # eat 100MB and sleep 100s
> > 	echo `pidof usemem` > /cgroup/hwpoison/tasks
> > 
> > ==>     memcg_id=$(</cgroup/hwpoison/memory.id)
> > ==>     echo $memcg_id > /debug/hwpoison/corrupt-filter-memcg
> > 
> > 	# hwpoison all pfn
> > 	pfn=0
> > 	while true
> > 	do      
> > 		let pfn=pfn+1
> > 		echo $pfn > /debug/hwpoison/corrupt-pfn
> > 		if [ $? -ne 0 ]; then
> > 			break
> > 		fi
> > 	done
> > 
> 
> I don't like this.
> 
> 1. plz put all under CONFIG_DEBUG_HWPOISON or some
> 2. plz don't export memcg's id. you can do it without it.

No problem.

My intention was, as memcg users grow in future, the export of
memcg functions and maybe its id will be generally useful then.

Matching by memcg dir name is acceptable for our case, however
won't be suitable for general use: there are file name uniqueness,
string escaping and efficiency issues.

> 3. If I was you, just adds following file
> 
> 	memory.hwpoison_test
>    Then, if you allow test
> 	#echo 1 >	memory.hwpoison_test

No that would look ugly in the long term. I'd rather go for dir name
matching for now.

> 4. I can't understand why you need this. I wonder you can get pfn via
>    /proc/<pid>/????. And this may insert HWPOISON to page-cache of shared
>    library and "unexpected" process will be poisoned.

Sorry I should have explained this. It's mainly for correctness.
When a user space tool queries the task PFNs in /proc/pid/pagemap and
then send to /debug/hwpoison/corrupt-pfn, there is a racy window that
the page could be reclaimed and allocated by some one else. It would
be awkward to try to pin the pages in user space. So we need the
guarantees provided by /debug/hwpoison/corrupt-filter-memcg, which
will be checked inside the page lock with elevated reference count.

Thanks,
Fengguang
--
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/