linux-kernel - kernel thread and cahche memeory at 2.4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 11 Oct 2006 14:02:23 +0200
From:	"Chava Leviatan" <chavale@...com.net.il>
To:	<linux-kernel@...r.kernel.org>
Subject:  kernel thread and cahche memeory at 2.4

Hi ,

I am trying to understand whether there is any context (thread wise)
involved when I do alloc_skb.

I have a kernel module that runs a kernel thread. (2.4.18 , regular PC with
2 ethernet interfaces)
That thread generates an ICMP packet every 50 milisec. It does it as
follows:

    -     call to alloc_skb
    -     fill ip header and icmp header
    -     fill in the necessary skb fields
    -     call to ip_rcv to inject the packet into the stack

Al of that worked just fine , and I was able to inspect the outgoing packets
through ethereal.
The problem occured while I did a rmmod for that module - the machine just
crashed (reset )

After spending some time in debugging this problem , I added a short delay
at my exit function before
the stop thread call. I have discovered that the last call to __kfree_skb
from net_tx_action must come while
my kernel thread is still alive .

I am trying to understand why is it so . Is there any importance to the
context that had performed the alloc ?

Thanks for any tip,
Chava 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/