* linux-next: Tree for November 30
From: Stephen Rothwell @ 2010-11-30 2:07 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8287 bytes --]
Hi all,
Changes since 20101129:
Linus' tree lost its build failure.
The v4l-dvb tree still has its build failure for which I applied a patch.
The net tree gained lost its failure.
The security-testing tree lost its build failures.
The tip tree still has its build failures so I have reverted 3 commits.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 180 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/rc-fixes
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging fbdev-current/fbdev-fixes-for-linus
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pci-sysfs.c
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-input.c
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging v4l-dvb/master
Applying: media: const and __devinitdata do not mix
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/mfd/wm8994-core.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security-testing/next
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in drivers/scsi/bfa/bfa_fcpim.c
Merging audit/for-next
Merging suspend/linux-next
Merging fsnotify/for-next
Merging irda/for-next
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
CONFLICT (content): Merge conflict in lib/Kconfig
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging tip/auto-latest
[master b339e5c] Revert "x86, nmi_watchdog: Remove all stub function calls from old nmi_watchdog"
[master 33e4ad8] Revert "x86, nmi_watchdog: Remove the old nmi_watchdog"
[master dedd770] Revert "perf, arch: Cleanup perf-pmu init vs lockup-detector"
Merging rcu/rcu/next
Merging oprofile/for-next
Merging xen/upstream/xen
Merging swiotlb-xen/master
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging driver-core/driver-core-next
Merging tty/tty-next
Merging usb/usb-next
Merging staging/staging-next
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/hard-interface.c
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/soft-interface.c
Merging slabh/slabh
Merging bkl-trivial/trivial
Merging bkl-llseek/llseek
Merging bkl-vfs/vfs
Merging bkl-config/config
CONFLICT (content): Merge conflict in arch/powerpc/kernel/setup_64.c
CONFLICT (content): Merge conflict in include/linux/hardirq.h
CONFLICT (content): Merge conflict in include/linux/smp_lock.h
Merging irqflags/master
Merging cleancache/linux-next
CONFLICT (content): Merge conflict in fs/ocfs2/super.c
CONFLICT (content): Merge conflict in include/linux/fs.h
CONFLICT (content): Merge conflict in mm/Kconfig
Merging scsi-post-merge/merge-base:master
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3 V13] RO/NX protection for loadable kernel
From: Rusty Russell @ 2010-11-29 23:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: matthieu castet, linux-kernel, linux-security-module, linux-next,
Arjan van de Ven, James Morris, Andrew Morton, Andi Kleen,
Thomas Gleixner, H. Peter Anvin, Ingo Molnar, Stephen Rothwell,
Dave Jones, Siarhei Liakh, Kees Cook, Peter Zijlstra
In-Reply-To: <20101129181542.GA11630@home.goodmis.org>
On Tue, 30 Nov 2010 04:45:42 am Steven Rostedt wrote:
> This patch breaks function tracer:
...
> Here we set the text read only before we call the notifiers. The
> function tracer changes the calls to mcount into nops via a notifier
> call so this must be done after the module notifiers.
That seems fine.
I note that both before and after this patch we potentially execute code
in the module (via parse_args) before we set it ro & nx. But fixing this
last bit of coverage is probably not worth the pain...
Cheers,
Rusty.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tip tree related)
From: Peter Zijlstra @ 2010-11-29 22:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
linux-kernel
In-Reply-To: <20101129135045.15aec5ed.sfr@canb.auug.org.au>
On Mon, 2010-11-29 at 13:50 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/kernel/perf_event.c:1326: error: 'init_hw_perf_event' undeclared here (not in a function)
>
> Caused by commit 004417a6d468e24399e383645c068b498eed84ad ("perf, arch:
> Cleanup perf-pmu init vs lockup-detector").
>
> I reverted that commit for today.
Ingo, can we back-merge this?
---
arch/sparc/kernel/perf_event.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index 75c5b12..39348b1 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -1323,7 +1323,7 @@ int __init init_hw_perf_events(void)
return 0;
}
-early_initcall(init_hw_perf_event);
+early_initcall(init_hw_perf_events);
void perf_callchain_kernel(struct perf_callchain_entry *entry,
struct pt_regs *regs)
^ permalink raw reply related
* Re: [PATCH] keys: add missing include file for trusted and encrypted keys
From: James Morris @ 2010-11-29 22:21 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-kernel, linux-next, Stephen Rothwell, David Safford,
Rajiv Andrade, Mimi Zohar, linux-security-module
In-Reply-To: <1291065604-9113-1-git-send-email-zohar@linux.vnet.ibm.com>
On Mon, 29 Nov 2010, Mimi Zohar wrote:
> This patch fixes the linux-next powerpc build errors as reported by
> Stephen Rothwell.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
> Tested-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Thanks!
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] keys: add missing include file for trusted and encrypted keys
From: Mimi Zohar @ 2010-11-29 21:20 UTC (permalink / raw)
To: linux-kernel
Cc: Mimi Zohar, linux-next, Stephen Rothwell, James Morris,
David Safford, Rajiv Andrade, Mimi Zohar
This patch fixes the linux-next powerpc build errors as reported by
Stephen Rothwell.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Tested-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
---
security/keys/encrypted_defined.c | 1 +
security/keys/trusted_defined.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/security/keys/encrypted_defined.c b/security/keys/encrypted_defined.c
index 0e558dc..3f40857 100644
--- a/security/keys/encrypted_defined.c
+++ b/security/keys/encrypted_defined.c
@@ -17,6 +17,7 @@
#include <linux/slab.h>
#include <linux/parser.h>
#include <linux/string.h>
+#include <linux/err.h>
#include <keys/user-type.h>
#include <keys/trusted-type.h>
#include <keys/encrypted-type.h>
diff --git a/security/keys/trusted_defined.c b/security/keys/trusted_defined.c
index 1bec72e..aaaa069 100644
--- a/security/keys/trusted_defined.c
+++ b/security/keys/trusted_defined.c
@@ -17,6 +17,7 @@
#include <linux/slab.h>
#include <linux/parser.h>
#include <linux/string.h>
+#include <linux/err.h>
#include <keys/user-type.h>
#include <keys/trusted-type.h>
#include <linux/key-type.h>
--
1.7.2.2
^ permalink raw reply related
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 20:46 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <4CF40EFB.60008@oracle.com>
On 29.11.2010, 21:37 Randy Dunlap wrote:
> On 11/29/10 12:21, Mathias Krause wrote:
>> On 29.11.2010, 21:11 Randy Dunlap wrote:
>>> On 11/29/10 12:02, Mathias Krause wrote:
>>>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> Changes since 20101126:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>>>
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>>>
>>>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>>>
>>>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>>>
>>>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>>>> instead of
>>>>>>>>>>> #ifdef __x86_64__
>>>>>>>>>>> or does that not matter?
>>>>>>>>>>>
>>>>>>>>>>> or is this a toolchain issue?
>>>>>>>>>>
>>>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>>>> your toolchain, too.
>>>>>>>>>>
>>>>>>>>>> But it looks like linux-next is just missing
>>>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>>>> That should fix the build issue.
>>>>>>>>>
>>>>>>>>> The build problem still happens when that patch is applied.
>>>>>>>>
>>>>>>>> That's weird. So it must be something with your toolchain.
>>>>>>>> Can you please post the output of the following commands?:
>>>>>>>>
>>>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>>
>>>>>>> #define __i386 1
>>>>>>> #define __i386__ 1
>>>>>>> #define i386 1
>>>>>>> #define __i586 1
>>>>>>> #define __i586__ 1
>>>>>>>
>>>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>>
>>>>>>> #define __x86_64 1
>>>>>>> #define __x86_64__ 1
>>>>>>>
>>>>>>> So that's not the problem... and the patch below didn't help.
>>>>>>
>>>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>>>> should be left out for 32-bit builds. :/
>>>>>>
>>>>>>> Sorry that I even asked about that. What next?
>>>>>>
>>>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>>>> linux-next tree, trying to reproduce your problem.
>>>>>>
>>>>>
>>>>> I just built with "make V=1" to see the full commands that are used, but
>>>>> that didn't help me either:
>>>>>
>>>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>>>
>>>>>
>>>>> There are 2945 lines like this:
>>>>>
>>>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>
>>>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>>>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>>>> more to be sure. ;)
>>>
>>> Touche.
>>> What does that patch have to do with aesni-intel??
>>
>> The description should be clear enough: "crypto: aesni-intel - Fixed build error
>> on x86-32".
>> Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
>> top of your linux-next build.
>>
>>> I'm using the linux-next tarball of 20111129.
>>> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
>>
>> Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
>> to apply in your tree since obviously 559ad0ff is missing.
>>
>>> new output file:
>>> http://oss.oracle.com/~rdunlap/doc/cry4.out
>>
>> Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
>
> Thanks for persisting/continuing with me.
> I apologize, I had applied the most recent patch in Herbert's cryptodev repo,
> not the one that you referred me to.
>
> Yes, the build is now fixed.
Great! Have fun with your new AESNI-accelerated crypto :)
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Randy Dunlap @ 2010-11-29 20:37 UTC (permalink / raw)
To: Mathias Krause
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <41CA6D05-C836-4F43-8DD8-C7EA9948DACC@googlemail.com>
On 11/29/10 12:21, Mathias Krause wrote:
> On 29.11.2010, 21:11 Randy Dunlap wrote:
>> On 11/29/10 12:02, Mathias Krause wrote:
>>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Changes since 20101126:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>>
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>>
>>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>>
>>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>>
>>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>>> instead of
>>>>>>>>>> #ifdef __x86_64__
>>>>>>>>>> or does that not matter?
>>>>>>>>>>
>>>>>>>>>> or is this a toolchain issue?
>>>>>>>>>
>>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>>> your toolchain, too.
>>>>>>>>>
>>>>>>>>> But it looks like linux-next is just missing
>>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>>> That should fix the build issue.
>>>>>>>>
>>>>>>>> The build problem still happens when that patch is applied.
>>>>>>>
>>>>>>> That's weird. So it must be something with your toolchain.
>>>>>>> Can you please post the output of the following commands?:
>>>>>>>
>>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>
>>>>>> #define __i386 1
>>>>>> #define __i386__ 1
>>>>>> #define i386 1
>>>>>> #define __i586 1
>>>>>> #define __i586__ 1
>>>>>>
>>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>
>>>>>> #define __x86_64 1
>>>>>> #define __x86_64__ 1
>>>>>>
>>>>>> So that's not the problem... and the patch below didn't help.
>>>>>
>>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>>> should be left out for 32-bit builds. :/
>>>>>
>>>>>> Sorry that I even asked about that. What next?
>>>>>
>>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>>> linux-next tree, trying to reproduce your problem.
>>>>>
>>>>
>>>> I just built with "make V=1" to see the full commands that are used, but
>>>> that didn't help me either:
>>>>
>>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>>
>>>>
>>>> There are 2945 lines like this:
>>>>
>>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>
>>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>>> more to be sure. ;)
>>
>> Touche.
>> What does that patch have to do with aesni-intel??
>
> The description should be clear enough: "crypto: aesni-intel - Fixed build error
> on x86-32".
> Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
> top of your linux-next build.
>
>> I'm using the linux-next tarball of 20111129.
>> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
>
> Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
> to apply in your tree since obviously 559ad0ff is missing.
>
>> new output file:
>> http://oss.oracle.com/~rdunlap/doc/cry4.out
>
> Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
Thanks for persisting/continuing with me.
I apologize, I had applied the most recent patch in Herbert's cryptodev repo,
not the one that you referred me to.
Yes, the build is now fixed.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 20:21 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <4CF408FB.4060905@oracle.com>
On 29.11.2010, 21:11 Randy Dunlap wrote:
> On 11/29/10 12:02, Mathias Krause wrote:
>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Changes since 20101126:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>
>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>
>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>
>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>> instead of
>>>>>>>>> #ifdef __x86_64__
>>>>>>>>> or does that not matter?
>>>>>>>>>
>>>>>>>>> or is this a toolchain issue?
>>>>>>>>
>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>> your toolchain, too.
>>>>>>>>
>>>>>>>> But it looks like linux-next is just missing
>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>> That should fix the build issue.
>>>>>>>
>>>>>>> The build problem still happens when that patch is applied.
>>>>>>
>>>>>> That's weird. So it must be something with your toolchain.
>>>>>> Can you please post the output of the following commands?:
>>>>>>
>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>
>>>>> #define __i386 1
>>>>> #define __i386__ 1
>>>>> #define i386 1
>>>>> #define __i586 1
>>>>> #define __i586__ 1
>>>>>
>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>
>>>>> #define __x86_64 1
>>>>> #define __x86_64__ 1
>>>>>
>>>>> So that's not the problem... and the patch below didn't help.
>>>>
>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>> should be left out for 32-bit builds. :/
>>>>
>>>>> Sorry that I even asked about that. What next?
>>>>
>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>> linux-next tree, trying to reproduce your problem.
>>>>
>>>
>>> I just built with "make V=1" to see the full commands that are used, but
>>> that didn't help me either:
>>>
>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>
>>>
>>> There are 2945 lines like this:
>>>
>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>
>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>> more to be sure. ;)
>
> Touche.
> What does that patch have to do with aesni-intel??
The description should be clear enough: "crypto: aesni-intel - Fixed build error
on x86-32".
Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
top of your linux-next build.
> I'm using the linux-next tarball of 20111129.
> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
to apply in your tree since obviously 559ad0ff is missing.
> new output file:
> http://oss.oracle.com/~rdunlap/doc/cry4.out
Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Randy Dunlap @ 2010-11-29 20:11 UTC (permalink / raw)
To: Mathias Krause
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <D271AB83-0E5F-4C1C-A4A7-CD0588E6C7B6@googlemail.com>
On 11/29/10 12:02, Mathias Krause wrote:
> On 29.11.2010, 20:54 Randy Dunlap wrote:
>> On 11/29/10 11:45, Mathias Krause wrote:
>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Changes since 20101126:
>>>>>>>>
>>>>>>>>
>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>
>>>>>>>> even though the kernel .config file says:
>>>>>>>>
>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>
>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>> instead of
>>>>>>>> #ifdef __x86_64__
>>>>>>>> or does that not matter?
>>>>>>>>
>>>>>>>> or is this a toolchain issue?
>>>>>>>
>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>> your toolchain, too.
>>>>>>>
>>>>>>> But it looks like linux-next is just missing
>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>> That should fix the build issue.
>>>>>>
>>>>>> The build problem still happens when that patch is applied.
>>>>>
>>>>> That's weird. So it must be something with your toolchain.
>>>>> Can you please post the output of the following commands?:
>>>>>
>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>
>>>> #define __i386 1
>>>> #define __i386__ 1
>>>> #define i386 1
>>>> #define __i586 1
>>>> #define __i586__ 1
>>>>
>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>
>>>> #define __x86_64 1
>>>> #define __x86_64__ 1
>>>>
>>>> So that's not the problem... and the patch below didn't help.
>>>
>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>> should be left out for 32-bit builds. :/
>>>
>>>> Sorry that I even asked about that. What next?
>>>
>>> Can you please post the full error message. Meanwhile I'm checking out a
>>> linux-next tree, trying to reproduce your problem.
>>>
>>
>> I just built with "make V=1" to see the full commands that are used, but
>> that didn't help me either:
>>
>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>
>>
>> There are 2945 lines like this:
>>
>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>
> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
> more to be sure. ;)
Touche.
What does that patch have to do with aesni-intel??
I'm using the linux-next tarball of 20111129.
However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
new output file:
http://oss.oracle.com/~rdunlap/doc/cry4.out
>> It's around 311 KB, so I'll just put it here instead of emailing it:
>> http://oss.oracle.com/~rdunlap/doc/cry32.out
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 20:02 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <4CF40504.5060506@oracle.com>
On 29.11.2010, 20:54 Randy Dunlap wrote:
> On 11/29/10 11:45, Mathias Krause wrote:
>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Changes since 20101126:
>>>>>>>
>>>>>>>
>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>
>>>>>>> even though the kernel .config file says:
>>>>>>>
>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>
>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>> #ifdef CONFIG_X86_64
>>>>>>> instead of
>>>>>>> #ifdef __x86_64__
>>>>>>> or does that not matter?
>>>>>>>
>>>>>>> or is this a toolchain issue?
>>>>>>
>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>> your toolchain, too.
>>>>>>
>>>>>> But it looks like linux-next is just missing
>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>> That should fix the build issue.
>>>>>
>>>>> The build problem still happens when that patch is applied.
>>>>
>>>> That's weird. So it must be something with your toolchain.
>>>> Can you please post the output of the following commands?:
>>>>
>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>
>>> #define __i386 1
>>> #define __i386__ 1
>>> #define i386 1
>>> #define __i586 1
>>> #define __i586__ 1
>>>
>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>
>>> #define __x86_64 1
>>> #define __x86_64__ 1
>>>
>>> So that's not the problem... and the patch below didn't help.
>>
>> That's odd. The output of the commands looks good so the x86-64 specific code
>> should be left out for 32-bit builds. :/
>>
>>> Sorry that I even asked about that. What next?
>>
>> Can you please post the full error message. Meanwhile I'm checking out a
>> linux-next tree, trying to reproduce your problem.
>>
>
> I just built with "make V=1" to see the full commands that are used, but
> that didn't help me either:
>
> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>
>
> There are 2945 lines like this:
>
> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
more to be sure. ;)
> It's around 311 KB, so I'll just put it here instead of emailing it:
> http://oss.oracle.com/~rdunlap/doc/cry32.out
>
> --
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Randy Dunlap @ 2010-11-29 19:56 UTC (permalink / raw)
To: Mathias Krause
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <358E1F68-6B24-4067-835E-94240025B0A3@googlemail.com>
On 11/29/10 11:52, Mathias Krause wrote:
> On 29.11.2010, 20:31 Randy Dunlap wrote:
>> On 11/29/10 11:21, Mathias Krause wrote:
>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101126:
>>>>>>
>>>>>>
>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>
>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>
>>>>>> even though the kernel .config file says:
>>>>>>
>>>>>> CONFIG_CRYPTO_AES=m
>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>
>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>> #ifdef CONFIG_X86_64
>>>>>> instead of
>>>>>> #ifdef __x86_64__
>>>>>> or does that not matter?
>>>>>>
>>>>>> or is this a toolchain issue?
>>>>>
>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>> your toolchain, too.
>>>>>
>>>>> But it looks like linux-next is just missing
>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>> That should fix the build issue.
>>>>
>>>> The build problem still happens when that patch is applied.
>>>
>>> That's weird. So it must be something with your toolchain.
>>> Can you please post the output of the following commands?:
>>>
>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __i386 1
>> #define __i386__ 1
>> #define i386 1
>> #define __i586 1
>> #define __i586__ 1
>>
>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> So that's not the problem... and the patch below didn't help.
>> Sorry that I even asked about that. What next?
>
> Sorry, I cannot reproduce the problem with the latest linux-next and commit
> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from cryptodev-2.6 applied. Please
> ensure you've applied that patch.
OK, thanks for trying.
Yes, I have applied that patch.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Randy Dunlap @ 2010-11-29 19:54 UTC (permalink / raw)
To: Mathias Krause
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <45B80502-8597-4650-990F-F23B4FC751B8@googlemail.com>
On 11/29/10 11:45, Mathias Krause wrote:
> On 29.11.2010, 20:31 Randy Dunlap wrote:
>> On 11/29/10 11:21, Mathias Krause wrote:
>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101126:
>>>>>>
>>>>>>
>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>
>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>
>>>>>> even though the kernel .config file says:
>>>>>>
>>>>>> CONFIG_CRYPTO_AES=m
>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>
>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>> #ifdef CONFIG_X86_64
>>>>>> instead of
>>>>>> #ifdef __x86_64__
>>>>>> or does that not matter?
>>>>>>
>>>>>> or is this a toolchain issue?
>>>>>
>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>> your toolchain, too.
>>>>>
>>>>> But it looks like linux-next is just missing
>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>> That should fix the build issue.
>>>>
>>>> The build problem still happens when that patch is applied.
>>>
>>> That's weird. So it must be something with your toolchain.
>>> Can you please post the output of the following commands?:
>>>
>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __i386 1
>> #define __i386__ 1
>> #define i386 1
>> #define __i586 1
>> #define __i586__ 1
>>
>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> So that's not the problem... and the patch below didn't help.
>
> That's odd. The output of the commands looks good so the x86-64 specific code
> should be left out for 32-bit builds. :/
>
>> Sorry that I even asked about that. What next?
>
> Can you please post the full error message. Meanwhile I'm checking out a
> linux-next tree, trying to reproduce your problem.
>
I just built with "make V=1" to see the full commands that are used, but
that didn't help me either:
gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
There are 2945 lines like this:
linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
It's around 311 KB, so I'll just put it here instead of emailing it:
http://oss.oracle.com/~rdunlap/doc/cry32.out
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 19:52 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <4CF3FFAE.40906@oracle.com>
On 29.11.2010, 20:31 Randy Dunlap wrote:
> On 11/29/10 11:21, Mathias Krause wrote:
>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101126:
>>>>>
>>>>>
>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>
>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>
>>>>> even though the kernel .config file says:
>>>>>
>>>>> CONFIG_CRYPTO_AES=m
>>>>> CONFIG_CRYPTO_AES_586=m
>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>
>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>> #ifdef CONFIG_X86_64
>>>>> instead of
>>>>> #ifdef __x86_64__
>>>>> or does that not matter?
>>>>>
>>>>> or is this a toolchain issue?
>>>>
>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>> So by using the latter we should be on the safe side but if your compiler
>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>> your toolchain, too.
>>>>
>>>> But it looks like linux-next is just missing
>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>> That should fix the build issue.
>>>
>>> The build problem still happens when that patch is applied.
>>
>> That's weird. So it must be something with your toolchain.
>> Can you please post the output of the following commands?:
>>
>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __i386 1
> #define __i386__ 1
> #define i386 1
> #define __i586 1
> #define __i586__ 1
>
>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __x86_64 1
> #define __x86_64__ 1
>
> So that's not the problem... and the patch below didn't help.
> Sorry that I even asked about that. What next?
Sorry, I cannot reproduce the problem with the latest linux-next and commit
559ad0ff1368baea14dbc3207d55b02bd69bda4b from cryptodev-2.6 applied. Please
ensure you've applied that patch.
Regards,
Mathias
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 19:45 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <4CF3FFAE.40906@oracle.com>
On 29.11.2010, 20:31 Randy Dunlap wrote:
> On 11/29/10 11:21, Mathias Krause wrote:
>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101126:
>>>>>
>>>>>
>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>
>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>
>>>>> even though the kernel .config file says:
>>>>>
>>>>> CONFIG_CRYPTO_AES=m
>>>>> CONFIG_CRYPTO_AES_586=m
>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>
>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>> #ifdef CONFIG_X86_64
>>>>> instead of
>>>>> #ifdef __x86_64__
>>>>> or does that not matter?
>>>>>
>>>>> or is this a toolchain issue?
>>>>
>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>> So by using the latter we should be on the safe side but if your compiler
>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>> your toolchain, too.
>>>>
>>>> But it looks like linux-next is just missing
>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>> That should fix the build issue.
>>>
>>> The build problem still happens when that patch is applied.
>>
>> That's weird. So it must be something with your toolchain.
>> Can you please post the output of the following commands?:
>>
>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __i386 1
> #define __i386__ 1
> #define i386 1
> #define __i586 1
> #define __i586__ 1
>
>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __x86_64 1
> #define __x86_64__ 1
>
> So that's not the problem... and the patch below didn't help.
That's odd. The output of the commands looks good so the x86-64 specific code
should be left out for 32-bit builds. :/
> Sorry that I even asked about that. What next?
Can you please post the full error message. Meanwhile I'm checking out a
linux-next tree, trying to reproduce your problem.
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Randy Dunlap @ 2010-11-29 19:31 UTC (permalink / raw)
To: Mathias Krause
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto
In-Reply-To: <1291058505-9384-1-git-send-email-minipli@googlemail.com>
On 11/29/10 11:21, Mathias Krause wrote:
> On 29.11.2010, 19:54 Randy Dunlap wrote:
>> On 11/29/10 10:26, Mathias Krause wrote:
>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Changes since 20101126:
>>>>
>>>>
>>>> on i386 builds, I get tons of these (and more) errors:
>>>>
>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>
>>>> even though the kernel .config file says:
>>>>
>>>> CONFIG_CRYPTO_AES=m
>>>> CONFIG_CRYPTO_AES_586=m
>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>
>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>> #ifdef CONFIG_X86_64
>>>> instead of
>>>> #ifdef __x86_64__
>>>> or does that not matter?
>>>>
>>>> or is this a toolchain issue?
>>>
>>> Well, __x86_64__ should be a build-in define of the compiler while
>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>> So by using the latter we should be on the safe side but if your compiler
>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>> your toolchain, too.
>>>
>>> But it looks like linux-next is just missing
>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>> That should fix the build issue.
>>
>> The build problem still happens when that patch is applied.
>
> That's weird. So it must be something with your toolchain.
> Can you please post the output of the following commands?:
>
> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
#define __i386 1
#define __i386__ 1
#define i386 1
#define __i586 1
#define __i586__ 1
> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
#define __x86_64 1
#define __x86_64__ 1
So that's not the problem... and the patch below didn't help.
Sorry that I even asked about that. What next?
> Beside that, the patch below should fix the issue with your toolchain by using
> CONFIG_X86_64 instead of __x86_64__.
>
> Sorry for the inconvenience,
> Mathias
>
> [PATCH] crypto: aesni-intel - Fixed another build error on x86-32
>
> It looks like not all compilers undef __x86_64__ for 32-bit builds so
> switch to CONFIG_X86_64 to test if we're building for 64 or 32 bit.
>
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> ---
> arch/x86/crypto/aesni-intel_asm.S | 40 ++++++++++++++++++------------------
> 1 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
> index d528fde..de0ec32 100644
> --- a/arch/x86/crypto/aesni-intel_asm.S
> +++ b/arch/x86/crypto/aesni-intel_asm.S
> @@ -32,7 +32,7 @@
> #include <linux/linkage.h>
> #include <asm/inst.h>
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> .data
> POLY: .octa 0xC2000000000000000000000000000001
> TWOONE: .octa 0x00000001000000000000000000000001
> @@ -105,7 +105,7 @@ enc: .octa 0x2
> #define CTR %xmm11
> #define INC %xmm12
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> #define AREG %rax
> #define KEYP %rdi
> #define OUTP %rsi
> @@ -132,7 +132,7 @@ enc: .octa 0x2
> #endif
>
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> /* GHASH_MUL MACRO to implement: Data*HashKey mod (128,127,126,121,0)
> *
> *
> @@ -1333,7 +1333,7 @@ _key_expansion_256b:
> * unsigned int key_len)
> */
> ENTRY(aesni_set_key)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> movl 8(%esp), KEYP # ctx
> movl 12(%esp), UKEYP # in_key
> @@ -1435,7 +1435,7 @@ ENTRY(aesni_set_key)
> cmp TKEYP, KEYP
> jb .Ldec_key_loop
> xor AREG, AREG
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KEYP
> #endif
> ret
> @@ -1444,7 +1444,7 @@ ENTRY(aesni_set_key)
> * void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
> */
> ENTRY(aesni_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> pushl KLEN
> movl 12(%esp), KEYP
> @@ -1455,7 +1455,7 @@ ENTRY(aesni_enc)
> movups (INP), STATE # input
> call _aesni_enc1
> movups STATE, (OUTP) # output
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> #endif
> @@ -1630,7 +1630,7 @@ _aesni_enc4:
> * void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
> */
> ENTRY(aesni_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> pushl KLEN
> movl 12(%esp), KEYP
> @@ -1642,7 +1642,7 @@ ENTRY(aesni_dec)
> movups (INP), STATE # input
> call _aesni_dec1
> movups STATE, (OUTP) #output
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> #endif
> @@ -1818,7 +1818,7 @@ _aesni_dec4:
> * size_t len)
> */
> ENTRY(aesni_ecb_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl LEN
> pushl KEYP
> pushl KLEN
> @@ -1863,7 +1863,7 @@ ENTRY(aesni_ecb_enc)
> cmp $16, LEN
> jge .Lecb_enc_loop1
> .Lecb_enc_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1875,7 +1875,7 @@ ENTRY(aesni_ecb_enc)
> * size_t len);
> */
> ENTRY(aesni_ecb_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl LEN
> pushl KEYP
> pushl KLEN
> @@ -1921,7 +1921,7 @@ ENTRY(aesni_ecb_dec)
> cmp $16, LEN
> jge .Lecb_dec_loop1
> .Lecb_dec_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1933,7 +1933,7 @@ ENTRY(aesni_ecb_dec)
> * size_t len, u8 *iv)
> */
> ENTRY(aesni_cbc_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl IVP
> pushl LEN
> pushl KEYP
> @@ -1961,7 +1961,7 @@ ENTRY(aesni_cbc_enc)
> jge .Lcbc_enc_loop
> movups STATE, (IVP)
> .Lcbc_enc_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1974,7 +1974,7 @@ ENTRY(aesni_cbc_enc)
> * size_t len, u8 *iv)
> */
> ENTRY(aesni_cbc_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl IVP
> pushl LEN
> pushl KEYP
> @@ -1998,7 +1998,7 @@ ENTRY(aesni_cbc_dec)
> movaps IN1, STATE1
> movups 0x10(INP), IN2
> movaps IN2, STATE2
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> movups 0x20(INP), IN3
> movaps IN3, STATE3
> movups 0x30(INP), IN4
> @@ -2011,7 +2011,7 @@ ENTRY(aesni_cbc_dec)
> #endif
> call _aesni_dec4
> pxor IV, STATE1
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> pxor IN1, STATE2
> pxor IN2, STATE3
> pxor IN3, STATE4
> @@ -2049,7 +2049,7 @@ ENTRY(aesni_cbc_dec)
> .Lcbc_dec_ret:
> movups IV, (IVP)
> .Lcbc_dec_just_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -2057,7 +2057,7 @@ ENTRY(aesni_cbc_dec)
> #endif
> ret
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> .align 16
> .Lbswap_mask:
> .byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 19:21 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, Stephen Rothwell, Huang Ying, Vinodh Gopal,
linux-next, LKML, linux-crypto, Mathias Krause
In-Reply-To: <4CF3F6CB.8080904@oracle.com>
On 29.11.2010, 19:54 Randy Dunlap wrote:
> On 11/29/10 10:26, Mathias Krause wrote:
>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> Changes since 20101126:
>>>
>>>
>>> on i386 builds, I get tons of these (and more) errors:
>>>
>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>
>>> even though the kernel .config file says:
>>>
>>> CONFIG_CRYPTO_AES=m
>>> CONFIG_CRYPTO_AES_586=m
>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>
>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>> #ifdef CONFIG_X86_64
>>> instead of
>>> #ifdef __x86_64__
>>> or does that not matter?
>>>
>>> or is this a toolchain issue?
>>
>> Well, __x86_64__ should be a build-in define of the compiler while
>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>> So by using the latter we should be on the safe side but if your compiler
>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>> showed quite a few more places using __x86_64__ so those would miscompile on
>> your toolchain, too.
>>
>> But it looks like linux-next is just missing
>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>> That should fix the build issue.
>
> The build problem still happens when that patch is applied.
That's weird. So it must be something with your toolchain.
Can you please post the output of the following commands?:
$ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
$ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
Beside that, the patch below should fix the issue with your toolchain by using
CONFIG_X86_64 instead of __x86_64__.
Sorry for the inconvenience,
Mathias
[PATCH] crypto: aesni-intel - Fixed another build error on x86-32
It looks like not all compilers undef __x86_64__ for 32-bit builds so
switch to CONFIG_X86_64 to test if we're building for 64 or 32 bit.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
arch/x86/crypto/aesni-intel_asm.S | 40 ++++++++++++++++++------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index d528fde..de0ec32 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -32,7 +32,7 @@
#include <linux/linkage.h>
#include <asm/inst.h>
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
.data
POLY: .octa 0xC2000000000000000000000000000001
TWOONE: .octa 0x00000001000000000000000000000001
@@ -105,7 +105,7 @@ enc: .octa 0x2
#define CTR %xmm11
#define INC %xmm12
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
#define AREG %rax
#define KEYP %rdi
#define OUTP %rsi
@@ -132,7 +132,7 @@ enc: .octa 0x2
#endif
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
/* GHASH_MUL MACRO to implement: Data*HashKey mod (128,127,126,121,0)
*
*
@@ -1333,7 +1333,7 @@ _key_expansion_256b:
* unsigned int key_len)
*/
ENTRY(aesni_set_key)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
movl 8(%esp), KEYP # ctx
movl 12(%esp), UKEYP # in_key
@@ -1435,7 +1435,7 @@ ENTRY(aesni_set_key)
cmp TKEYP, KEYP
jb .Ldec_key_loop
xor AREG, AREG
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KEYP
#endif
ret
@@ -1444,7 +1444,7 @@ ENTRY(aesni_set_key)
* void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
*/
ENTRY(aesni_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
pushl KLEN
movl 12(%esp), KEYP
@@ -1455,7 +1455,7 @@ ENTRY(aesni_enc)
movups (INP), STATE # input
call _aesni_enc1
movups STATE, (OUTP) # output
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
#endif
@@ -1630,7 +1630,7 @@ _aesni_enc4:
* void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
*/
ENTRY(aesni_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
pushl KLEN
movl 12(%esp), KEYP
@@ -1642,7 +1642,7 @@ ENTRY(aesni_dec)
movups (INP), STATE # input
call _aesni_dec1
movups STATE, (OUTP) #output
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
#endif
@@ -1818,7 +1818,7 @@ _aesni_dec4:
* size_t len)
*/
ENTRY(aesni_ecb_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl LEN
pushl KEYP
pushl KLEN
@@ -1863,7 +1863,7 @@ ENTRY(aesni_ecb_enc)
cmp $16, LEN
jge .Lecb_enc_loop1
.Lecb_enc_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1875,7 +1875,7 @@ ENTRY(aesni_ecb_enc)
* size_t len);
*/
ENTRY(aesni_ecb_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl LEN
pushl KEYP
pushl KLEN
@@ -1921,7 +1921,7 @@ ENTRY(aesni_ecb_dec)
cmp $16, LEN
jge .Lecb_dec_loop1
.Lecb_dec_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1933,7 +1933,7 @@ ENTRY(aesni_ecb_dec)
* size_t len, u8 *iv)
*/
ENTRY(aesni_cbc_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl IVP
pushl LEN
pushl KEYP
@@ -1961,7 +1961,7 @@ ENTRY(aesni_cbc_enc)
jge .Lcbc_enc_loop
movups STATE, (IVP)
.Lcbc_enc_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1974,7 +1974,7 @@ ENTRY(aesni_cbc_enc)
* size_t len, u8 *iv)
*/
ENTRY(aesni_cbc_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl IVP
pushl LEN
pushl KEYP
@@ -1998,7 +1998,7 @@ ENTRY(aesni_cbc_dec)
movaps IN1, STATE1
movups 0x10(INP), IN2
movaps IN2, STATE2
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
movups 0x20(INP), IN3
movaps IN3, STATE3
movups 0x30(INP), IN4
@@ -2011,7 +2011,7 @@ ENTRY(aesni_cbc_dec)
#endif
call _aesni_dec4
pxor IV, STATE1
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
pxor IN1, STATE2
pxor IN2, STATE3
pxor IN3, STATE4
@@ -2049,7 +2049,7 @@ ENTRY(aesni_cbc_dec)
.Lcbc_dec_ret:
movups IV, (IVP)
.Lcbc_dec_just_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -2057,7 +2057,7 @@ ENTRY(aesni_cbc_dec)
#endif
ret
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
.align 16
.Lbswap_mask:
.byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: Tree for November 22 (kvm)
From: Randy Dunlap @ 2010-11-29 19:05 UTC (permalink / raw)
To: Zachary Amsden
Cc: Avi Kivity, Glauber Costa, Stephen Rothwell, kvm, linux-next,
LKML
In-Reply-To: <4CF3EC1E.7050707@redhat.com>
On 11/29/10 10:08, Zachary Amsden wrote:
> On 11/29/2010 07:52 AM, Randy Dunlap wrote:
>> On 11/29/10 09:47, Zachary Amsden wrote:
>>
>>> On 11/29/2010 06:35 AM, Avi Kivity wrote:
>>>
>>>> On 11/29/2010 06:33 PM, Randy Dunlap wrote:
>>>>
>>>>> On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:
>>>>>
>>>>>
>>>>>> On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101119:
>>>>>>>
>>>>>>
>>>>>> kvm.c:(.init.text+0x11f49): undefined reference to
>>>>>>
>>>>> `kvm_register_clock'
>>>>>
>>>>>> when CONFIG_KVM_CLOCK is not enabled.
>>>>>>
>>>>>
>>>>> BUild error still present in linux-next-2010-NOV-29.
>>>>>
>>>>>
>>>> Glauber, Zach?
>>>>
>>>>
>>> I can only speculate this reference is being called from smpboot without
>>> CONFIG guarding?
>>>
>> Sorry, looks like I dropped the first line of the error messages:
>>
>> arch/x86/built-in.o: In function `kvm_smp_prepare_boot_cpu':
>> kvm.c:(.init.text+0xad38): undefined reference to `kvm_register_clock'
>>
>> from arch/x86/kernel/kvm.c:
>>
>> #ifdef CONFIG_SMP
>> static void __init kvm_smp_prepare_boot_cpu(void)
>> {
>> WARN_ON(kvm_register_clock("primary cpu clock"));
>> kvm_guest_cpu_init();
>> native_smp_prepare_boot_cpu();
>> }
>>
>> so it looks like you are correct...
>>
>
> Looks like this is the appropriate fix:
>
> #ifdef CONFIG_SMP
> static void __init kvm_smp_prepare_boot_cpu(void)
> {
> #ifdef CONFIG_KVM_CLOCK
> WARN_ON(kvm_register_clock("primary cpu clock"));
> #endif
> kvm_guest_cpu_init();
> native_smp_prepare_boot_cpu();
> }
Sure, that works. Thanks.
>
> The SMP code is still buggy as well, wrt printk timing, in that it
> doesn't get called early enough, correct? Has anyone thought of a good
> solution to that problem?
>
> Basically the problem is CPU-1 will get CPU-0's per-cpu areas copied
> over, and these are not valid for CPU-1. If the clocksource is used on
> CPU-1 before kvm clock gets setup, it can go backwards, wreaking havoc,
> causing panic, etc.
>
> What is the best test to guard against this? Perhaps we should keep the
> CPU number in the per-cpu data and test against it?
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Randy Dunlap @ 2010-11-29 18:54 UTC (permalink / raw)
To: Mathias Krause
Cc: Stephen Rothwell, Huang Ying, Vinodh Gopal, linux-next, LKML,
linux-crypto
In-Reply-To: <DAEDA952-8AD2-406D-9F37-33740F86FC59@googlemail.com>
On 11/29/10 10:26, Mathias Krause wrote:
> On 29.11.2010, 17:31 Randy Dunlap wrote:
>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20101126:
>>
>>
>> on i386 builds, I get tons of these (and more) errors:
>>
>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>
>> even though the kernel .config file says:
>>
>> CONFIG_CRYPTO_AES=m
>> CONFIG_CRYPTO_AES_586=m
>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>
>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>> #ifdef CONFIG_X86_64
>> instead of
>> #ifdef __x86_64__
>> or does that not matter?
>>
>> or is this a toolchain issue?
>
> Well, __x86_64__ should be a build-in define of the compiler while
> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
> So by using the latter we should be on the safe side but if your compiler
> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
> showed quite a few more places using __x86_64__ so those would miscompile on
> your toolchain, too.
>
> But it looks like linux-next is just missing
> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
> That should fix the build issue.
The build problem still happens when that patch is applied.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 29
From: Zimny Lech @ 2010-11-29 18:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: Stephen Rothwell, linux-next, LKML, Linux Crypto Mailing List
In-Reply-To: <20101129145717.GA20232@gondor.apana.org.au>
2010/11/29 Herbert Xu <herbert@gondor.apana.org.au>:
> On Mon, Nov 29, 2010 at 09:47:38AM +0000, Zimny Lech wrote:
>> Ave
>>
>> 2010/11/29 Stephen Rothwell <sfr@canb.auug.org.au>:
>> > Hi all,
>> >
>> > Changes since 20101126:
>>
>>
>> Setup is 14188 bytes (padded to 14336 bytes).
>> System is 1267 kB
>> CRC 61cea148
>> Kernel: arch/x86/boot/bzImage is ready (#1)
>> Building modules, stage 2.
>> MODPOST 537 modules
>> ERROR: "sock_no_mmap" [crypto/algif_skcipher.ko] undefined!
>
> I hope this patch fixes it for you.
Thanks, I'll check it in tomorrows -next.
>
> commit 7451708f39db19a8303bb7fb95f00aca9f673cb5
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Mon Nov 29 22:56:03 2010 +0800
>
> crypto: af_alg - Add dependency on NET
>
> Add missing dependency on NET since we require sockets for our
> interface.
>
> Should really be a select but kconfig doesn't like that:
>
> net/Kconfig:6:error: found recursive dependency: NET -> NETWORK_FILESYSTEMS -> AFS_FS -> AF_RXRPC -> CRYPTO -> CRYPTO_USER_API_HASH -> CRYPTO_USER_API -> NET
>
> Reported-by: Zimny Lech <napohybelskurwysynom2010@gmail.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 467491d..96b0e55 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -848,6 +848,7 @@ config CRYPTO_USER_API
>
> config CRYPTO_USER_API_HASH
> tristate "User-space interface for hash algorithms"
> + depends on NET
> select CRYPTO_HASH
> select CRYPTO_USER_API
> help
> @@ -856,6 +857,7 @@ config CRYPTO_USER_API_HASH
>
> config CRYPTO_USER_API_SKCIPHER
> tristate "User-space interface for symmetric key cipher algorithms"
> + depends on NET
> select CRYPTO_BLKCIPHER
> select CRYPTO_USER_API
> help
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
--
Slawa!
Zimny "Spie dziadu!" Lech z Wawelu
That is not dead which can eternal lie.
And with strange aeons even death may die.
^ permalink raw reply
* Re: linux-next: Tree for November 29 (aesni-intel)
From: Mathias Krause @ 2010-11-29 18:26 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Huang Ying, Vinodh Gopal, linux-next, LKML,
linux-crypto
In-Reply-To: <20101129083105.e202e922.randy.dunlap@oracle.com>
On 29.11.2010, 17:31 Randy Dunlap wrote:
> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20101126:
>
>
> on i386 builds, I get tons of these (and more) errors:
>
> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>
> even though the kernel .config file says:
>
> CONFIG_CRYPTO_AES=m
> CONFIG_CRYPTO_AES_586=m
> CONFIG_CRYPTO_AES_NI_INTEL=m
>
> Should arch/x86/crypto/aesni-intel_asm.S be testing
> #ifdef CONFIG_X86_64
> instead of
> #ifdef __x86_64__
> or does that not matter?
>
> or is this a toolchain issue?
Well, __x86_64__ should be a build-in define of the compiler while
CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
So by using the latter we should be on the safe side but if your compiler
defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
showed quite a few more places using __x86_64__ so those would miscompile on
your toolchain, too.
But it looks like linux-next is just missing
559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
That should fix the build issue.
Kind Regards,
Mathias
^ permalink raw reply
* Re: [PATCH 3/3 V13] RO/NX protection for loadable kernel
From: Steven Rostedt @ 2010-11-29 18:15 UTC (permalink / raw)
To: matthieu castet
Cc: linux-kernel, linux-security-module, linux-next, Arjan van de Ven,
James Morris, Andrew Morton, Andi Kleen, Thomas Gleixner,
H. Peter Anvin, Ingo Molnar, Rusty Russell, Stephen Rothwell,
Dave Jones, Siarhei Liakh, Kees Cook, Peter Zijlstra
In-Reply-To: <4CE2F914.9070106@free.fr>
This patch breaks function tracer:
------------[ cut here ]------------
WARNING: at kernel/trace/ftrace.c:1014 ftrace_bug+0x114/0x171()
Hardware name: Precision WorkStation 470
Modules linked in: i2c_core(+)
Pid: 86, comm: modprobe Not tainted 2.6.37-rc2+ #68
Call Trace:
[<ffffffff8104e957>] warn_slowpath_common+0x85/0x9d
[<ffffffffa00026db>] ? __process_new_adapter+0x7/0x34 [i2c_core]
[<ffffffffa00026db>] ? __process_new_adapter+0x7/0x34 [i2c_core]
[<ffffffff8104e989>] warn_slowpath_null+0x1a/0x1c
[<ffffffff810a9dfe>] ftrace_bug+0x114/0x171
[<ffffffffa00026db>] ? __process_new_adapter+0x7/0x34 [i2c_core]
[<ffffffff810aa0db>] ftrace_process_locs+0x1ae/0x274
[<ffffffffa00026db>] ? __process_new_adapter+0x7/0x34 [i2c_core]
[<ffffffff810aa29e>] ftrace_module_notify+0x39/0x44
[<ffffffff814405cf>] notifier_call_chain+0x37/0x63
[<ffffffff8106e054>] __blocking_notifier_call_chain+0x46/0x5b
[<ffffffff8106e07d>] blocking_notifier_call_chain+0x14/0x16
[<ffffffff8107ffde>] sys_init_module+0x73/0x1f3
[<ffffffff8100acf2>] system_call_fastpath+0x16/0x1b
---[ end trace 2aff4f4ca53ec746 ]---
ftrace faulted on writing [<ffffffffa00026db>]
__process_new_adapter+0x7/0x34 [i2c_core]
On Tue, Nov 16, 2010 at 10:35:16PM +0100, matthieu castet wrote:
>
> @@ -2650,6 +2810,18 @@ static struct module *load_module(void __user *umod,
> kfree(info.strmap);
> free_copy(&info);
>
> + /* Set RO and NX regions for core */
> + set_section_ro_nx(mod->module_core,
> + mod->core_text_size,
> + mod->core_ro_size,
> + mod->core_size);
> +
> + /* Set RO and NX regions for init */
> + set_section_ro_nx(mod->module_init,
> + mod->init_text_size,
> + mod->init_ro_size,
> + mod->init_size);
> +
Here we set the text read only before we call the notifiers. The
function tracer changes the calls to mcount into nops via a notifier
call so this must be done after the module notifiers.
> /* Done! */
> trace_module_load(mod);
> return mod;
> @@ -2753,6 +2925,7 @@ SYSCALL_DEFINE3(init_module, void __user *, umod,
> mod->symtab = mod->core_symtab;
> mod->strtab = mod->core_strtab;
> #endif
> + unset_section_ro_nx(mod, mod->module_init);
> module_free(mod, mod->module_init);
> mod->module_init = NULL;
> mod->init_size = 0;
Below is the patch that fixes this bug.
-- Steve
Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
diff --git a/kernel/module.c b/kernel/module.c
index ba421e6..5ccf52c 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2804,18 +2804,6 @@ static struct module *load_module(void __user *umod,
kfree(info.strmap);
free_copy(&info);
- /* Set RO and NX regions for core */
- set_section_ro_nx(mod->module_core,
- mod->core_text_size,
- mod->core_ro_size,
- mod->core_size);
-
- /* Set RO and NX regions for init */
- set_section_ro_nx(mod->module_init,
- mod->init_text_size,
- mod->init_ro_size,
- mod->init_size);
-
/* Done! */
trace_module_load(mod);
return mod;
@@ -2876,6 +2864,18 @@ SYSCALL_DEFINE3(init_module, void __user *, umod,
blocking_notifier_call_chain(&module_notify_list,
MODULE_STATE_COMING, mod);
+ /* Set RO and NX regions for core */
+ set_section_ro_nx(mod->module_core,
+ mod->core_text_size,
+ mod->core_ro_size,
+ mod->core_size);
+
+ /* Set RO and NX regions for init */
+ set_section_ro_nx(mod->module_init,
+ mod->init_text_size,
+ mod->init_ro_size,
+ mod->init_size);
+
do_mod_ctors(mod);
/* Start the module */
if (mod->init != NULL)
^ permalink raw reply related
* Re: linux-next: Tree for November 22 (kvm)
From: Zachary Amsden @ 2010-11-29 18:08 UTC (permalink / raw)
To: Randy Dunlap
Cc: Avi Kivity, Glauber Costa, Stephen Rothwell, kvm, linux-next,
LKML
In-Reply-To: <4CF3E870.4040308@oracle.com>
On 11/29/2010 07:52 AM, Randy Dunlap wrote:
> On 11/29/10 09:47, Zachary Amsden wrote:
>
>> On 11/29/2010 06:35 AM, Avi Kivity wrote:
>>
>>> On 11/29/2010 06:33 PM, Randy Dunlap wrote:
>>>
>>>> On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:
>>>>
>>>>
>>>>> On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101119:
>>>>>>
>>>>>
>>>>> kvm.c:(.init.text+0x11f49): undefined reference to
>>>>>
>>>> `kvm_register_clock'
>>>>
>>>>> when CONFIG_KVM_CLOCK is not enabled.
>>>>>
>>>>
>>>> BUild error still present in linux-next-2010-NOV-29.
>>>>
>>>>
>>> Glauber, Zach?
>>>
>>>
>> I can only speculate this reference is being called from smpboot without
>> CONFIG guarding?
>>
> Sorry, looks like I dropped the first line of the error messages:
>
> arch/x86/built-in.o: In function `kvm_smp_prepare_boot_cpu':
> kvm.c:(.init.text+0xad38): undefined reference to `kvm_register_clock'
>
> from arch/x86/kernel/kvm.c:
>
> #ifdef CONFIG_SMP
> static void __init kvm_smp_prepare_boot_cpu(void)
> {
> WARN_ON(kvm_register_clock("primary cpu clock"));
> kvm_guest_cpu_init();
> native_smp_prepare_boot_cpu();
> }
>
> so it looks like you are correct...
>
Looks like this is the appropriate fix:
#ifdef CONFIG_SMP
static void __init kvm_smp_prepare_boot_cpu(void)
{
#ifdef CONFIG_KVM_CLOCK
WARN_ON(kvm_register_clock("primary cpu clock"));
#endif
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
}
The SMP code is still buggy as well, wrt printk timing, in that it
doesn't get called early enough, correct? Has anyone thought of a good
solution to that problem?
Basically the problem is CPU-1 will get CPU-0's per-cpu areas copied
over, and these are not valid for CPU-1. If the clocksource is used on
CPU-1 before kvm clock gets setup, it can go backwards, wreaking havoc,
causing panic, etc.
What is the best test to guard against this? Perhaps we should keep the
CPU number in the per-cpu data and test against it?
^ permalink raw reply
* Re: linux-next: Tree for November 22 (kvm)
From: Randy Dunlap @ 2010-11-29 17:52 UTC (permalink / raw)
To: Zachary Amsden
Cc: Avi Kivity, Glauber Costa, Stephen Rothwell, kvm, linux-next,
LKML
In-Reply-To: <4CF3E733.8090809@redhat.com>
On 11/29/10 09:47, Zachary Amsden wrote:
> On 11/29/2010 06:35 AM, Avi Kivity wrote:
>> On 11/29/2010 06:33 PM, Randy Dunlap wrote:
>>> On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:
>>>
>>> > On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > Changes since 20101119:
>>> >
>>> >
>>> > kvm.c:(.init.text+0x11f49): undefined reference to
>>> `kvm_register_clock'
>>> >
>>> > when CONFIG_KVM_CLOCK is not enabled.
>>>
>>>
>>> BUild error still present in linux-next-2010-NOV-29.
>>>
>>
>> Glauber, Zach?
>>
>
> I can only speculate this reference is being called from smpboot without
> CONFIG guarding?
Sorry, looks like I dropped the first line of the error messages:
arch/x86/built-in.o: In function `kvm_smp_prepare_boot_cpu':
kvm.c:(.init.text+0xad38): undefined reference to `kvm_register_clock'
from arch/x86/kernel/kvm.c:
#ifdef CONFIG_SMP
static void __init kvm_smp_prepare_boot_cpu(void)
{
WARN_ON(kvm_register_clock("primary cpu clock"));
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
}
so it looks like you are correct...
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for November 22 (kvm)
From: Zachary Amsden @ 2010-11-29 17:47 UTC (permalink / raw)
To: Avi Kivity
Cc: Glauber Costa, Randy Dunlap, Stephen Rothwell, kvm, linux-next,
LKML
In-Reply-To: <4CF3D637.6060204@redhat.com>
On 11/29/2010 06:35 AM, Avi Kivity wrote:
> On 11/29/2010 06:33 PM, Randy Dunlap wrote:
>> On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:
>>
>> > On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote:
>> >
>> > > Hi all,
>> > >
>> > > Changes since 20101119:
>> >
>> >
>> > kvm.c:(.init.text+0x11f49): undefined reference to
>> `kvm_register_clock'
>> >
>> > when CONFIG_KVM_CLOCK is not enabled.
>>
>>
>> BUild error still present in linux-next-2010-NOV-29.
>>
>
> Glauber, Zach?
>
I can only speculate this reference is being called from smpboot without
CONFIG guarding?
^ permalink raw reply
* Re: [PATCH 3/3 V13] RO/NX protection for loadable kernel
From: Valdis.Kletnieks @ 2010-11-29 16:59 UTC (permalink / raw)
To: mat
Cc: linux-kernel, linux-security-module, linux-next, Arjan van de Ven,
James Morris, Andrew Morton, Andi Kleen, Thomas Gleixner,
H. Peter Anvin, Ingo Molnar, Rusty Russell, Stephen Rothwell,
Dave Jones, Siarhei Liakh, Kees Cook
In-Reply-To: <20101126182355.62615dff@mat-laptop>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
On Fri, 26 Nov 2010 18:23:55 +0100, mat said:
> Le Wed, 24 Nov 2010 22:41:07 -0500,
> Valdis.Kletnieks@vt.edu a =E9crit :
> > This is incompatible with CONFIG_JUMP_LABEL:
> >
> > [ 252.093624] BUG: unable to handle kernel paging request at
> > ffffffffa0680764 [ 252.094008] IP: [<ffffffff81225ee0>]
> > generic_swap+0xa/0x1a [ 252.094008] PGD 1a1e067 PUD 1a22063 PMD
> > 1093ac067 PTE 8000000109786161 [ 252.094008] Oops: 0003 [#1] PREEMPT
> > SMP
> > > +config DEBUG_SET_MODULE_RONX
> > > + bool "Set loadable kernel module data as NX and text as RO"
> > > + default n
> > > + depends on X86 && MODULES
> >
> > depends on X86 && MODULES && !JUMP_LABEL
> could you try the attached patch ?
>
> on module load, we sort the __jump_table section. So we should make it
> writable.
> diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_la
bel.h
> index f52d42e..574dbc2 100644
> --- a/arch/x86/include/asm/jump_label.h
> +++ b/arch/x86/include/asm/jump_label.h
> @@ -14,7 +14,7 @@
> do { \
> asm goto("1:" \
> JUMP_LABEL_INITIAL_NOP \
> - ".pushsection __jump_table, \"a\" \n\t"\
> + ".pushsection __jump_table, \"aw\" \n\t"\
Confirming that fixes the issue I was seeing, thanks...
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox