linux-kernel - Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree

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:	Thu, 11 Oct 2012 15:08:01 +0200
From:	Alexander Graf <agraf@...e.de>
To:	David Howells <dhowells@...hat.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>, B04825@...escale.com,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Liu Yu <yu.liu@...escale.com>,
	Stuart Yoder <stuart.yoder@...escale.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree


On 11.10.2012, at 11:27, David Howells wrote:

> Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> 
>> I just removed epapr_hcalls.h from the Kbuild file as I am not sure how
>> it should be broken up.  David, can you have a look at this, please?
> 
> Files should be broken up along around __KERNEL__ conditionals.  If there are
> no __KERNEL__ conditionals, it is assumed that the file is entirely UAPI and
> can just be moved.
> 
> The problem appears to be this commit:
> 
> 	https://github.com/agraf/linux-2.6/commit/4c09029a5639c955fcf6d65205796e4f1208aed3
> 
> 	From: Liu Yu <yu.liu@...escale.com>
> 	Subject: KVM: PPC: Add support for ePAPR idle hcall in host kernel
> 
> Just makes epapr_hcalls.h part of the userspace API in its entirety by this bit
> of the patch:
> 
> 	+header-y += epapr_hcalls.h
> 
> whilst not adding any __KERNEL__ guards - which is almost certainly incorrect.
> 
> At the very least, I would say that the global variable declarations need
> limiting to kernel space, and thus so do the inline functions as they emit
> inline assembly to jump somewhere specified by one of the global variables
> (actually a code array).
> 
> So for manual splitting purposes, I would go with just moving all the #defines
> prior to the __ASSEMBLY__ guard out to uapi.  Everything within the
> __ASSEMBLY__ guard is KABI only by the looks of it.

Do I have to move them to their own header file or can I just #ifdef __KERNEL__ around the place where __ASSEMBLY__ starts to the end of the file?


Alex

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