lkml.org 
[lkml]   [2008]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes
    Date
    Am Donnerstag, 7. August 2008 18:23 schrieb Wolfgang Walter:
    > Am Mittwoch, 6. August 2008 22:14 schrieb Suresh Siddha:
    > > On Wed, Aug 06, 2008 at 10:33:25AM -0700, Wolfgang Walter wrote:
    > > > Hello Herbert,
    > > >
    > > > I think I finally found the problem.
    > > >
    > > > Here a short description again: all our routers with a via C3 using
    > > > padlock for AES-encryption are crashing with 2.6.26 while they work
    > > > fine with 2.6.25. Not using padlock (i.e. using the i386 assembler
    > > > version of AES) they just work fine.
    > >
    > > Both the padlock version or asm version don't use FP/math registers,
    > > right? It is interesting that you don't see the problem with asm version
    > > but see the problem with padlock version.
    > >
    > > Does disabling CONFIG_PREEMPT in 2.6.26 change anything? And also,
    >
    > Didn't check that yet as I'm still running my modified 2.6.26. It now runs
    > almost one day flawlessly.
    >
    > But yesterday I tried the following patch on top of a vanilla 2.6.26:
    >
    > =======================================================
    > diff -ur ../linux-2.6.26/drivers/crypto/padlock-aes.c
    > ./drivers/crypto/padlock-aes.c ---
    > ../linux-2.6.26/drivers/crypto/padlock-aes.c 2008-07-15 11:29:32.000000000
    > +0200 +++ ./drivers/crypto/padlock-aes.c 2008-08-07 17:46:55.000000000
    > +0200 @@ -16,6 +16,7 @@
    > #include <linux/interrupt.h>
    > #include <linux/kernel.h>
    > #include <asm/byteorder.h>
    > +#include <asm/i387.h>
    > #include "padlock.h"
    >
    > /* Control word. */
    > @@ -144,9 +145,11 @@
    > static inline void padlock_xcrypt(const u8 *input, u8 *output, void *key,
    > void *control_word)
    > {
    > + kernel_fpu_begin();
    > asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */
    >
    > : "+S"(input), "+D"(output)
    > : "d"(control_word), "b"(key), "c"(1));
    >
    > + kernel_fpu_end();
    > }
    >
    > static void aes_crypt_copy(const u8 *in, u8 *out, u32 *key, struct cword
    > *cword) @@ -179,6 +182,7 @@
    > return;
    > }
    >
    > + kernel_fpu_begin();
    > asm volatile ("test $1, %%cl;"
    > "je 1f;"
    > "lea -1(%%ecx), %%eax;"
    > @@ -190,15 +194,18 @@
    >
    > : "+S"(input), "+D"(output)
    > : "d"(control_word), "b"(key), "c"(count)
    > : "ax");
    >
    > + kernel_fpu_end();
    > }
    >
    > static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void
    > *key, u8 *iv, void *control_word, u32 count)
    > {
    > /* rep xcryptcbc */
    > + kernel_fpu_begin();
    > asm volatile (".byte 0xf3,0x0f,0xa7,0xd0"
    >
    > : "+S" (input), "+D" (output), "+a" (iv)
    > : "d" (control_word), "b" (key), "c" (count));
    >
    > + kernel_fpu_end();
    > return iv;
    > }
    >
    > =============================================================
    >
    > I found that kernel_fpu_begin(); kernel_fpu_begin(); is used with
    > MMX and/or SSE:
    >
    > include/asm/xor_32.h
    > drivers/md/raid6mmx.c
    > drivers/md/raid6sse1.c
    > drivers/md/raid6sse2.c
    >
    >
    > With this change I its a little bit more stable, I needed more then 5
    > minutes to crash the kernel (repeated it several times). If I read
    > the code correctly this disables preemption for the time the padlock cmd
    > is executing.

    Forget that - I booted the wrong kernel.

    I now really test this modification and it seems to be stable. The router now
    runs for 45 minutes without oops.

    Regards,
    --
    Wolfgang Walter
    Studentenwerk München
    Anstalt des öffentlichen Rechts
    Leiter EDV
    Leopoldstraße 15
    80802 München
    Tel: +49 89 38196 276
    Fax: +49 89 38196 150
    Email: wolfgang.walter@stwm.de
    http://www.studentenwerk-muenchen.de/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2008-08-08 12:39    [W:3.994 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site