Hi,
I am working on Linux Kernel 2.4.25. I am trying to
add cryptoapi (cryptoapi-0.1.0) support to wireless
lan driver (linux-wlan-ng-0.2.1.pre14) of prism-based
cards. Cardctl version is 3.1.31.
When I am using "null" as a encryption cipher to check
the coding sequence, everything is working fine. But
when I change it to any other cipher for e.g.
"blowfish" or "rc5", it is giving kernel panic. I have
included Ksymoops extract from the kernel Ooops
reports below.
Can anyone please help me in what can be possible
error by looking at the log ?
I will greatly appreciate any help in this matter.
Regards,
-Niranjan
Research Assistant, UMASS.
Ksymoops extract from the kernel Ooops reports:
===============================================
ksymoops 2.4.8 on i686 2.4.25. Options used
-V (default)
-k log4_ksyms (specified)
-l log4_modules (specified)
-o /lib/modules/2.4.25/ (specified)
-m /boot/System.map-2.4.25 (specified)
kernel bug at sched.c:564!
CPU: 0
EIP: 0010:[<c0117be6>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000018 ebx: 00000000 ecx: cf244000 edx:
cf245f7c
esi: c6d44000 edi: 00000000 ebp: c6d45af4 esp:
c6d45ac8
ds: 0018 es: 0018 ss: 0018
Process ping (pid:2814, stackpage=c6d45000)
Stack: c02f10aa 00000000 c5d77e00 d08fd0b9 c6d45aec
c6d44000 cb846034 3acbc7bc
c6d45b18 d08390c6 00000000 c5d77e08 d08fd93b
cd577e00 c6d45b18 00000000
00000008 00000000 00000001 c6d44000 bcc7cb3a
c698f6d0 00000000 cb846000
Call Trace: [<d08fd0b9>] [<d08e90c6>] [<d08fd93b>]
[<d08390be>] [<d08e06b6>]
[<d08e90be>] [<d08fd0b9>] [<d08e90be>] [<d08e5c79>]
[<d08e90be>] [<d08e3240>]
[<d08e93c0>] [<d08e8394>] [<d08e6826>] [<c0116630>]
[<c028c4e3>] [<c0281f80>]
[<c02b7975>] [<c02b7365>] [<c02879d6>] [<c028831c>]
[<c027d0de>] [<c029882d>]
[<c0297ff7>] [<c02b476a>] [<c02b4460>] [<c02b776b>]
[<c02bd7f2>] [<c027a445>]
[<c027bb57>] [<c012c1af>] [<c012c105>] [<c012c381>]
[<c01167b8>] [<c01bf87a>]
[<c02bb84d>] [<c027c056>] [<c01075ff>]
Code: 0f 0b 34 02 a2 10 2f c0 e9 b7 fb ff ff 0f 0b 2d
02 a2 10 2f
From: Matt Mackall <hidden> Date: 2004-07-26 21:06:13
On Sat, Jul 24, 2004 at 03:33:10PM -0700, Niranjan wrote:
Hi,
I am working on Linux Kernel 2.4.25. I am trying to
add cryptoapi (cryptoapi-0.1.0) support to wireless
lan driver (linux-wlan-ng-0.2.1.pre14) of prism-based
cards. Cardctl version is 3.1.31.
When I am using "null" as a encryption cipher to check
the coding sequence, everything is working fine. But
when I change it to any other cipher for e.g.
"blowfish" or "rc5", it is giving kernel panic. I have
included Ksymoops extract from the kernel Ooops
reports below.
Can anyone please help me in what can be possible
error by looking at the log ?
I will greatly appreciate any help in this matter.
The cryptoapi currently decides to sleep at various points internally
when digesting a block which is probably what you're seeing.
--
Mathematics is the supreme nostalgia of our time.
From: Vladimir Kondratiev <hidden> Date: 2004-07-27 18:02:39
We also saw the same (crypto modules goes to sleep).
Due to this, we decided to not use cryptoapi for our wireless driver, but
compile the same crypto functions into the driver. I know this is code
duplication, but Tx and Rx paths work in BH context (I reschedule it on IRQ
Rx to use cheaper time).
Do cryptoapi maintainers aware of this issue?
On Tuesday 27 July 2004 00:06, Matt Mackall wrote:
On Sat, Jul 24, 2004 at 03:33:10PM -0700, Niranjan wrote:
quoted
Hi,
I am working on Linux Kernel 2.4.25. I am trying to
add cryptoapi (cryptoapi-0.1.0) support to wireless
lan driver (linux-wlan-ng-0.2.1.pre14) of prism-based
cards. Cardctl version is 3.1.31.
When I am using "null" as a encryption cipher to check
the coding sequence, everything is working fine. But
when I change it to any other cipher for e.g.
"blowfish" or "rc5", it is giving kernel panic. I have
included Ksymoops extract from the kernel Ooops
reports below.
Can anyone please help me in what can be possible
error by looking at the log ?
I will greatly appreciate any help in this matter.
The cryptoapi currently decides to sleep at various points internally
when digesting a block which is probably what you're seeing.
From: James Morris <hidden> Date: 2004-07-27 18:39:25
On Tue, 27 Jul 2004, Vladimir Kondratiev wrote:
We also saw the same (crypto modules goes to sleep).
Due to this, we decided to not use cryptoapi for our wireless driver, but
compile the same crypto functions into the driver. I know this is code
duplication, but Tx and Rx paths work in BH context (I reschedule it on IRQ
Rx to use cheaper time).
Do cryptoapi maintainers aware of this issue?
The crypto functions should be safe to use in softirq context.
- James
--
James Morris
[off-list ref]
From: Vladimir Kondratiev <hidden> Date: 2004-07-27 18:50:27
On Tuesday 27 July 2004 21:39, James Morris wrote:
On Tue, 27 Jul 2004, Vladimir Kondratiev wrote:
quoted
We also saw the same (crypto modules goes to sleep).
Due to this, we decided to not use cryptoapi for our wireless driver, but
compile the same crypto functions into the driver. I know this is code
duplication, but Tx and Rx paths work in BH context (I reschedule it on
IRQ Rx to use cheaper time).
Do cryptoapi maintainers aware of this issue?
The crypto functions should be safe to use in softirq context.
It should be, but:
<crypto/api.c:121>
struct crypto_tfm *crypto_alloc_tfm(const char *name, u32 flags)
{
struct crypto_tfm *tfm = NULL;
struct crypto_alg *alg;
alg = crypto_alg_mod_lookup(name);
if (alg == NULL)
goto out;
tfm = kmalloc(sizeof(*tfm) + alg->cra_ctxsize, GFP_KERNEL);
Note kmalloc(GFP_KERNEL)
Thanks for all your help. I didn't found any group
which is maintaining CryptoAPI.
I am using cryptoapi-0.1.0 and there is no
crypto/api.c file. But the memory allocation in this
version (cryptoapi-0.1.0) is using GFP_KERNEL.
I really didn't understand how to solve the problem
using BH. Now, I am reading kernel locking HOWTO to
understand BH and softirq.
I will also try adding crypto functions inside the
WLAN driver.
Warm Regards,
-Niranjan
UMASS.
--- Vladimir Kondratiev <vkondra@mail.ru> wrote:
On Tuesday 27 July 2004 21:39, James Morris wrote:
quoted
On Tue, 27 Jul 2004, Vladimir Kondratiev wrote:
quoted
We also saw the same (crypto modules goes to
sleep).
quoted
quoted
Due to this, we decided to not use cryptoapi for
our wireless driver, but
quoted
quoted
compile the same crypto functions into the
driver. I know this is code
quoted
quoted
duplication, but Tx and Rx paths work in BH
context (I reschedule it on
quoted
quoted
IRQ Rx to use cheaper time).
Do cryptoapi maintainers aware of this issue?
The crypto functions should be safe to use in
softirq context.
It should be, but:
<crypto/api.c:121>
struct crypto_tfm *crypto_alloc_tfm(const char
*name, u32 flags)
{
struct crypto_tfm *tfm = NULL;
struct crypto_alg *alg;
alg = crypto_alg_mod_lookup(name);
if (alg == NULL)
goto out;
tfm = kmalloc(sizeof(*tfm) +
alg->cra_ctxsize, GFP_KERNEL);
Note kmalloc(GFP_KERNEL)
Hi,
I got the code working by including the encrypt() and
decrypt() function inside the WLAN driver.
Is there any better way to get the CrytoAPI code
working from the driver or some other CryptoAPI
implementation ?
Warm Regards,
-Niranjan
--- James Morris <jmorris@redhat.com> wrote:
On Tue, 27 Jul 2004, Vladimir Kondratiev wrote:
quoted
quoted
The crypto functions should be safe to use in
softirq context.
quoted
It should be, but:
<crypto/api.c:121>
struct crypto_tfm *crypto_alloc_tfm(const char
From: James Morris <hidden> Date: 2004-07-28 16:10:43
On Wed, 28 Jul 2004, Niranjan wrote:
Hi,
I got the code working by including the encrypt() and
decrypt() function inside the WLAN driver.
Is there any better way to get the CrytoAPI code
working from the driver or some other CryptoAPI
implementation ?
Where is the driver code?
- James
--
James Morris
[off-list ref]
The driver code is in kernel loadable module. The
linux-wlan-ng driver for the linux wireless cards has
two kernel loadable modules - prism2_cs and p80211.
I included the encrypt() and decrypt() function of
cryptoapi inside the p80211.o kernel module instead of
using cipher-<cipher_name>.o module for encryption and
decryption. The cipher context (cipher name and cipher
mode) and key (key length and cipher key) is still set
through cryptoapi.o module.
Warm Regards,
-Niranjan
--- James Morris <jmorris@redhat.com> wrote:
On Wed, 28 Jul 2004, Niranjan wrote:
quoted
Hi,
I got the code working by including the encrypt()
and
quoted
decrypt() function inside the WLAN driver.
Is there any better way to get the CrytoAPI code
working from the driver or some other CryptoAPI
implementation ?
Where is the driver code?
- James
--
James Morris
[off-list ref]