linux-kernel - Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace

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: <20120807160337.GC16877@mudshark.cambridge.arm.com>
Date:	Tue, 7 Aug 2012 17:03:37 +0100
From:	Will Deacon <will.deacon@....com>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hillf Danton <dhillf@...il.com>,
	Russell King <linux@....linux.org.uk>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge
 page to userspace

<resurrecting this thread>

On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
> On Thu 12-07-12 12:26:45, Will Deacon wrote:
> > Well, the comment in linux/page-flags.h does state that:
> > 
> >  * PG_arch_1 is an architecture specific page state bit.  The generic code
> >  * guarantees that this bit is cleared for a page when it first is entered into
> >  * the page cache.
> > 
> > so it's not completely clear cut that the architecture should be responsible
> > for clearing this bit when allocating pages from the hugepage pool.
> 
> I think the wording is quite clear. It guarantees it gets cleared not
> clears it. So it is up to an arch specific functions called from the
> generic code to do that.

If we have to do this in arch-specific functions then:

	1. Where should we do it?
	2. Why don't we also do this for normal (non-huge) pages?

I looked at what happens for non-huge pages and the page flags are
cleared by *generic* code in free_pages_check:


  /*
   * Flags checked when a page is prepped for return by the page allocator.
   * Pages being prepped should not have any flags set.  It they are set,
   * there has been a kernel bug or struct page corruption.
   */
  #define PAGE_FLAGS_CHECK_AT_PREP	((1 << NR_PAGEFLAGS) - 1)

  static inline int free_pages_check(struct page *page)
  {
  	[...]
  	if (page->flags & PAGE_FLAGS_CHECK_AT_PREP)
  		page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
  	return 0;
  }


Which guarantees to the arch-code that any new pages coming back from the
allocator will have PG_arch_1 clear. Why can't we just do something similar
for the hugepage pool?

Sorry to nag, but the discrepancy seems both unnecessary and unsolvable
at the arch level with the current hooks.

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