linux-kernel - Re: [PATCH 3/3] page-flags: rectify forward declaration

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:	Tue, 22 Sep 2015 14:26:08 +0530
From:	Sudip Mukherjee <sudipm.mukherjee@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Haavard Skinnemoen <hskinnemoen@...il.com>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH 3/3] page-flags: rectify forward declaration

On Mon, Sep 21, 2015 at 03:35:09PM -0700, Andrew Morton wrote:
> On Sat, 19 Sep 2015 22:42:59 +0530 Sudip Mukherjee <sudipm.mukherjee@...il.com> wrote:
> 
<snip>
> 
> Is it fixable?  Can we use the traditional define-before-using structure?
How about this:

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index ab1a0e9..d7a1055 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -133,6 +133,19 @@ enum pageflags {
 
 #ifndef __GENERATING_BOUNDS_H
 
+/* Forward declarations */
+struct page;
+static inline int PageCompound(struct page *page);
+static inline int PageTail(struct page *page);
+static inline struct page *compound_head(struct page *page)
+{
+	unsigned long head = READ_ONCE(page->compound_head);
+
+	if (unlikely(head & 1))
+		return (struct page *) (head - 1);
+	return page;
+}
+
 /* Page flags policies wrt compound pages */
 #define PF_ANY(page, enforce)	page
 #define PF_HEAD(page, enforce)	compound_head(page)
@@ -223,12 +236,6 @@ static inline int __TestClearPage##uname(struct page *page) { return 0; }
 #define TESTSCFLAG_FALSE(uname)						\
 	TESTSETFLAG_FALSE(uname) TESTCLEARFLAG_FALSE(uname)
 
-/* Forward declarations */
-struct page;
-static inline int PageCompound(struct page *page);
-static inline int PageTail(struct page *page);
-static struct page *compound_head(struct page *page);
-
 __PAGEFLAG(Locked, locked, PF_NO_TAIL)
 PAGEFLAG(Error, error, PF_NO_COMPOUND) TESTCLEARFLAG(Error, error, PF_NO_COMPOUND)
 PAGEFLAG(Referenced, referenced, PF_HEAD)
@@ -450,15 +457,6 @@ static inline void clear_compound_head(struct page *page)
 	WRITE_ONCE(page->compound_head, 0);
 }
 
-static inline struct page *compound_head(struct page *page)
-{
-	unsigned long head = READ_ONCE(page->compound_head);
-
-	if (unlikely(head & 1))
-		return (struct page *) (head - 1);
-	return page;
-}
-
 static inline int PageCompound(struct page *page)
 {
 	return PageHead(page) || PageTail(page);


---
It builds properly. Tested with allmodconfig of x86_64 and avr32.

> 
> Also, I'm finding that the patch series introduces a pretty large
> bisection hole:
> 
> include/linux/page-flags.h: In function 'PageYoung':
> include/linux/page-flags.h:327: error: implicit declaration of function 'PF_ANY'
> include/linux/page-flags.h:327: error: invalid type argument of '->' (have 'int')
> include/linux/page-flags.h:327: error: invalid type argument of '->' (have 'int')
> 
> which later gets fixed up by
> page-flags-rectify-forward-declaration.patch.
How to test this? Should I apply them on top of v4.2 and bisect? And I
don't see any relation between the first two patches and this patch of
the series, then how does it fail in bisect? Am I missing something?
Confused.. :(
> 
> Maybe it's time to do a wholesale refactoring of the patchset?
If this patch is the first in the series will that help?
And besides I got the auto mail from you that the patch is applied.
Now totally confused.. :(

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