Building with the attached random configuration file,
In file included from ./arch/x86/include/asm/spinlock.h:46:0,
from include/linux/spinlock.h:87,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from crypto/jitterentropy.c:52:
In function ‘native_queued_spin_unlock’,
inlined from ‘queued_spin_unlock’ at ./arch/x86/include/asm/qspinlock.h:38:2
,
inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2,
inlined from ‘__raw_spin_unlock’ at include/linux/spinlock_api_smp.h:153:2,
inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2,
inlined from ‘jent_kcapi_cleanup’ at crypto/jitterentropy.c:844:2:
./arch/x86/include/asm/qspinlock.h:17:317: error: call to
‘__compiletime_assert_17’ declared with attribute error: Need native
word sized stores/loads for atomicity.
In function ‘native_queued_spin_unlock’,
inlined from ‘queued_spin_unlock’ at ./arch/x86/include/asm/qspinlock.h:38:2
,
inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2,
inlined from ‘__raw_spin_unlock’ at include/linux/spinlock_api_smp.h:153:2,
inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2,
inlined from ‘jent_kcapi_random’ at crypto/jitterentropy.c:856:2:
./arch/x86/include/asm/qspinlock.h:17:317: error: call to
‘__compiletime_assert_17’ declared with attribute error: Need native
word sized stores/loads for atomicity.
scripts/Makefile.build:264: recipe for target 'crypto/jitterentropy.o' failed
On Fri, May 29, 2015 at 10:14 PM, Jim Davis <[email protected]> wrote:
> Building with the attached random configuration file,
Hit the very same error against next-20150605.
The issue with that file we have no compiler optimization enabled. So,
guys, how you would recommend to fix it?
By the way, I'm building the x86_64_defconfig with following changes
diff --git a/arch/x86/configs/x86_64_defconfig
b/arch/x86/configs/x86_64_defconfig
index 315b861..363824f 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -172,9 +172,11 @@ CONFIG_TIGON3=y
CONFIG_NET_TULIP=y
CONFIG_E100=y
CONFIG_E1000=y
+CONFIG_E1000E=y
CONFIG_SKY2=y
CONFIG_FORCEDETH=y
CONFIG_8139TOO=y
+CONFIG_R8169=y
CONFIG_FDDI=y
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
@@ -198,7 +200,7 @@ CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_NVRAM=y
-CONFIG_HPET=y
+# CONFIG_HPET is not set
# CONFIG_HPET_MMAP is not set
CONFIG_I2C_I801=y
CONFIG_WATCHDOG=y
@@ -206,8 +208,8 @@ CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
-CONFIG_DRM_I915=y
-CONFIG_DRM_I915_KMS=y
+# CONFIG_DRM_I915 is not set
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_EFI=y
@@ -224,8 +226,8 @@ CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_HRTIMER=y
-CONFIG_SND_HDA_INTEL=y
-CONFIG_SND_HDA_HWDEP=y
+# CONFIG_SND_HDA_INTEL is not set
+# CONFIG_SND_HDA_HWDEP is not set
CONFIG_HIDRAW=y
CONFIG_HID_GYRATION=y
CONFIG_LOGITECH_FF=y
@@ -307,3 +309,56 @@ CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_DISABLE=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_FUNCTION_TRACER=y
+CONFIG_I2C_DESIGNWARE_PCI=y
+CONFIG_I2C_DESIGNWARE_PLATFORM=m
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_INTEL_MID=y
+CONFIG_INTEL_MID_WATCHDOG=y
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_CHIPIDEA=y
+CONFIG_USB_CHIPIDEA_UDC=y
+CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_X86_EXTENDED_PLATFORM=y
+CONFIG_X86_INTEL_MID=y
+CONFIG_EFI_STUB=y
+CONFIG_EFI_MIXED=y
+CONFIG_EARLY_PRINTK_EFI=y
+CONFIG_FB=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_SERIAL=y
+CONFIG_USB_SERIAL_PL2303=y
+CONFIG_USB_USBNET=y
+CONFIG_USB_NET_AX88179_178A=y
+CONFIG_USB_NET_MCS7830=y
+CONFIG_USB_NET_AX8817X=y
+CONFIG_X86_INTEL_LPSS=y
+CONFIG_PM_RUNTIME=y
+CONFIG_DW_DMAC_CORE=m
+CONFIG_DW_DMAC=m
+CONFIG_DW_DMAC_PCI=m
+CONFIG_DMATEST=m
+CONFIG_SERIAL_8250_DMA=y
+CONFIG_SERIAL_8250_PCI=y
+CONFIG_SERIAL_8250_DW=m
+CONFIG_MMC=m
+CONFIG_MMC_SDHCI=m
+CONFIG_MMC_SDHCI_ACPI=m
+CONFIG_ACPI_DEBUG=y
+CONFIG_ACPI_PROCFS_POWER=y
+CONFIG_DMA_API_DEBUG=y
+CONFIG_DEBUG_LOCKDEP=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_BAYTRAIL=y
+CONFIG_PWM=y
+CONFIG_PWM_LPSS=m
+CONFIG_PWM_LPSS_PCI=m
+CONFIG_PWM_LPSS_PLATFORM=m
+CONFIG_SPI=y
+CONFIG_SPI_PXA2XX_PCI=m
+CONFIG_SPI_PXA2XX=m
>
> In file included from ./arch/x86/include/asm/spinlock.h:46:0,
> from include/linux/spinlock.h:87,
> from include/linux/seqlock.h:35,
> from include/linux/time.h:5,
> from include/linux/stat.h:18,
> from include/linux/module.h:10,
> from crypto/jitterentropy.c:52:
> In function ‘native_queued_spin_unlock’,
> inlined from ‘queued_spin_unlock’ at ./arch/x86/include/asm/qspinlock.h:38:2
> ,
> inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2,
> inlined from ‘__raw_spin_unlock’ at include/linux/spinlock_api_smp.h:153:2,
> inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2,
> inlined from ‘jent_kcapi_cleanup’ at crypto/jitterentropy.c:844:2:
> ./arch/x86/include/asm/qspinlock.h:17:317: error: call to
> ‘__compiletime_assert_17’ declared with attribute error: Need native
> word sized stores/loads for atomicity.
> In function ‘native_queued_spin_unlock’,
> inlined from ‘queued_spin_unlock’ at ./arch/x86/include/asm/qspinlock.h:38:2
> ,
> inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2,
> inlined from ‘__raw_spin_unlock’ at include/linux/spinlock_api_smp.h:153:2,
> inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2,
> inlined from ‘jent_kcapi_random’ at crypto/jitterentropy.c:856:2:
> ./arch/x86/include/asm/qspinlock.h:17:317: error: call to
> ‘__compiletime_assert_17’ declared with attribute error: Need native
> word sized stores/loads for atomicity.
> scripts/Makefile.build:264: recipe for target 'crypto/jitterentropy.o' failed
--
With Best Regards,
Andy Shevchenko
On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2015 at 10:14 PM, Jim Davis <[email protected]> wrote:
> > Building with the attached random configuration file,
>
> Hit the very same error against next-20150605.
>
> The issue with that file we have no compiler optimization enabled. So,
> guys, how you would recommend to fix it?
Stephan, can we get rid of the no optimisation requirement?
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Adding Stephan to Cc.
On Mon, 2015-06-08 at 20:25 +0800, Herbert Xu wrote:
> On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> > On Fri, May 29, 2015 at 10:14 PM, Jim Davis <[email protected]> wrote:
> > > Building with the attached random configuration file,
> >
> > Hit the very same error against next-20150605.
> >
> > The issue with that file we have no compiler optimization enabled. So,
> > guys, how you would recommend to fix it?
>
> Stephan, can we get rid of the no optimisation requirement?
Would something like
#pragma GCC push_options
#pragma GCC optimize ("-O0")
static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
__u64 *folded, __u64 loop_cnt)
{
...
}
#pragma GCC pop_options
Be an option to allow the file to be compiled with regular optimizations
enabled?
Am Montag, 8. Juni 2015, 14:36:30 schrieb Peter Zijlstra:
Hi Peter,
> Adding Stephan to Cc.
>
> On Mon, 2015-06-08 at 20:25 +0800, Herbert Xu wrote:
> > On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 29, 2015 at 10:14 PM, Jim Davis <[email protected]> wrote:
> > > > Building with the attached random configuration file,
> > >
> > > Hit the very same error against next-20150605.
> > >
> > > The issue with that file we have no compiler optimization enabled. So,
> > > guys, how you would recommend to fix it?
> >
> > Stephan, can we get rid of the no optimisation requirement?
>
> Would something like
>
> #pragma GCC push_options
> #pragma GCC optimize ("-O0")
> static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> __u64 *folded, __u64 loop_cnt)
> {
> ...
> }
> #pragma GCC pop_options
>
> Be an option to allow the file to be compiled with regular optimizations
> enabled?
Yes, that is also possible. I was not aware of the fact that the optimization
is the problem. I got another report fom Fengguang Wu about a compile issue on
AVR32 which I found out relates to the same issue.
I will prepare a patch shortly.
--
Ciao
Stephan
Am Monday 08 June 2015, 14:36:30 schrieb Peter Zijlstra:
Hi Peter,
>
>Would something like
>
>#pragma GCC push_options
>#pragma GCC optimize ("-O0")
>static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> __u64 *folded, __u64 loop_cnt)
>{
> ...
>}
>#pragma GCC pop_options
>
>Be an option to allow the file to be compiled with regular optimizations
>enabled?
After doing some tests, I see that neither the min entropy nor the Shannon
Entropy of the raw noise is affected by using the mentioned pragmas at the
right locations.
So I will prepare a patch tonight.
Just for my edification: why does an -O0 on a self contained file break the
compile run? Any why do the pragmas work?
Thanks
Stephan
On Mon, 2015-06-08 at 17:52 +0200, Stephan Mueller wrote:
> Am Monday 08 June 2015, 14:36:30 schrieb Peter Zijlstra:
>
> Hi Peter,
> >
> >Would something like
> >
> >#pragma GCC push_options
> >#pragma GCC optimize ("-O0")
> >static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> > __u64 *folded, __u64 loop_cnt)
> >{
> > ...
> >}
> >#pragma GCC pop_options
> >
> >Be an option to allow the file to be compiled with regular optimizations
> >enabled?
>
> After doing some tests, I see that neither the min entropy nor the Shannon
> Entropy of the raw noise is affected by using the mentioned pragmas at the
> right locations.
>
> So I will prepare a patch tonight.
>
> Just for my edification: why does an -O0 on a self contained file break the
> compile run?
We rely on -finline-functions, which is disabled with -O0.
By inlining some things, the compiler can do constant value propagation
etc. and compile time evaluate things.
We often (as is the case here) use this to generate compiler warns
without generating actual code.
> Any why do the pragmas work?
They are placed such that the code affected by the above creativity is
outside of the forced -O0 compile and life is good again.
On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2015 at 10:14 PM, Jim Davis <[email protected]> wrote:
> > Building with the attached random configuration file,
>
> Hit the very same error against next-20150605.
>
There are also several failing default configurations.
Guenter
---
um:defconfig:
include/asm-generic/fixmap.h: In function 'fix_to_virt':
include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative
---
x86_64:defconfig:
i386:defconfig:
./arch/x86/include/asm/qspinlock.h: In function 'native_queued_spin_unlock':
./arch/x86/include/asm/qspinlock.h:17:2: error:
call to '__compiletime_assert_17' declared with attribute error:
Need native word sized stores/loads for atomicity.
---
openrisc:defconfig:
In file included from ./arch/openrisc/include/asm/timex.h:23:0,
...
from crypto/jitterentropy.c:52:
./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle':
./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably doesn't
match constraints
./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm'
---
nios2:3c120_defconfig:
ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined!
Am Monday 08 June 2015, 12:54:12 schrieb Guenter Roeck:
Hi Guenter,
Thanks for the note.
...
>
>---
>
>openrisc:defconfig:
>
>In file included from ./arch/openrisc/include/asm/timex.h:23:0,
> ...
> from crypto/jitterentropy.c:52:
>./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle':
>./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably
>doesn't match constraints
>./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm'
I received this one also before. But that seems to be an error on the OpenRISC
platform as the random_get_entropy() function or the get_cycles function is
not implemented as defined.
The crypto code uses the following which triggers the issue:
__u64 tmp = 0;
tmp = random_get_entropy();
That one seems to be an appropriate use of random_get_entropy() which on
almost all arches is an alias for get_cycles().
>
>---
>
>nios2:3c120_defconfig:
>
>ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined!
Ciao
Stephan
On 06/08/2015 03:36 PM, Stephan Mueller wrote:
> Am Monday 08 June 2015, 12:54:12 schrieb Guenter Roeck:
>
> Hi Guenter,
>
> Thanks for the note.
>
> ...
>>
>> ---
>>
>> openrisc:defconfig:
>>
>> In file included from ./arch/openrisc/include/asm/timex.h:23:0,
>> ...
>> from crypto/jitterentropy.c:52:
>> ./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle':
>> ./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably
>> doesn't match constraints
>> ./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm'
>
> I received this one also before. But that seems to be an error on the OpenRISC
> platform as the random_get_entropy() function or the get_cycles function is
> not implemented as defined.
>
> The crypto code uses the following which triggers the issue:
>
> __u64 tmp = 0;
>
> tmp = random_get_entropy();
>
> That one seems to be an appropriate use of random_get_entropy() which on
> almost all arches is an alias for get_cycles().
Yes and no. I suspect it may have something to do with the compiler options.
The code compiles with the following patch applied.
---
diff --git a/arch/openrisc/include/asm/spr.h b/arch/openrisc/include/asm/spr.h
index 1cccb42dd477..373532cc41f4 100644
--- a/arch/openrisc/include/asm/spr.h
+++ b/arch/openrisc/include/asm/spr.h
@@ -24,7 +24,7 @@
"l.mtspr %0,%1,%2" \
: : "r" (_off), "r" (_val), "K" (_spr))
-static inline unsigned long mfspr(unsigned long add)
+static inline unsigned long mfspr(const unsigned long add)
{
unsigned long ret;
__asm__ __volatile__ ("l.mfspr %0,r0,%1" : "=r" (ret) : "K" (add));
---
get_cycles is implemented as static inline which executes mfspr(SPR_TTCR).
SPR_TTCR is a constant. Normally that information seems to be passed on,
but not when get_cycles() is compiled through jitterentropy.
Any idea what might cause this ?
Thanks,
Guenter
Am Monday 08 June 2015, 16:30:09 schrieb Guenter Roeck:
Hi Guenter,
>
>get_cycles is implemented as static inline which executes mfspr(SPR_TTCR).
>SPR_TTCR is a constant. Normally that information seems to be passed on,
>but not when get_cycles() is compiled through jitterentropy.
>
>Any idea what might cause this ?
Then it may be the optimization issue as well that Peter indicated. May I ask
you for testing purposes (I do not have an OpenRISC) to remove the following
line from crypto/Makefile:
CFLAGS_jitterentropy.o = -O0
Note, that should just serve for testing. I will post a patch later that will
replace the -O0 statement with a pragma.
Thanks a lot.
>
>Thanks,
>Guenter
Ciao
Stephan
On 06/08/2015 04:33 PM, Stephan Mueller wrote:
> Am Monday 08 June 2015, 16:30:09 schrieb Guenter Roeck:
>
> Hi Guenter,
>
>>
>> get_cycles is implemented as static inline which executes mfspr(SPR_TTCR).
>> SPR_TTCR is a constant. Normally that information seems to be passed on,
>> but not when get_cycles() is compiled through jitterentropy.
>>
>> Any idea what might cause this ?
>
> Then it may be the optimization issue as well that Peter indicated. May I ask
> you for testing purposes (I do not have an OpenRISC) to remove the following
> line from crypto/Makefile:
>
> CFLAGS_jitterentropy.o = -O0
>
Yes, that fixes the problem (after I also removed the associated #error from
jitterentropy.c).
Guenter
Am Monday 08 June 2015, 16:51:24 schrieb Guenter Roeck:
Hi Guenter,
>
>Yes, that fixes the problem (after I also removed the associated #error from
>jitterentropy.c).
Thank you for the confirmation. The patch will come tonight on this issue as I
tested the cryptographic impact already.
Thanks a lot for your help.
Ciao
Stephan