Adam,
If you are calling af_add from inside icmp_rcv() then it will be
called in BH context. If from inside such a function you try to write to a
disk (an operation that might sleep) the scheduler will be called which
will try to schdeule the process (as it just wants to sleep), Now inside
the schedule function there is a check to find out if it is called inside
IRQ or BH context, which is causing that panic. You should not do anything
inside IRQ and BH that might cause it to sleep. A kernel thread will be a
good candidate for writing to disk. In general writing to disk from inside
the kernel is a bad idea, you can do what the linux logger does, make that
data (that you have to write to disk) available to a user process (via
system call, /proc whatever) and then that process should read from there
and write to the disk.
Hope that helps.
tomar
On Wed, 16 Jul 2003, Adam Flizikowski wrote:
> Hello,
>
> i have already writen onthis subject.
>
> i have added function af_add() to icmp.c code that is called everytime
> ping
> xx.xx.xx.xx is done.
>
> this function is given some informative data as a param, and puts this
> into
> buffer (kmalloced).
>
> whenever buffer is full it swaps data from memory to file.
>
> so i use
>
> - spin_lock()/unlock() at the beginning and end of the func
>
> - i kmalloc mem once at the first call to the fucntion af_add
>
> - and switch between user/kernel when writing to file
>
> That is all the idea.
>
>
> But i get oops (but non-deterministically) when i try to run this (of
> course
> after kernel compilation)
>
> ooops says: sth about kernel BUG at sched.c 564 or somewhere else
> slub.c...
> (i don personally think this is tru reason)
>
> At the end of ooops there is: Kernel panic. Aiee, killing irq handler
> In irq handler - not syncing
>
> This is the code:
>
> ********************************************************
> #define ELEMENT_MAX 4
> #define write(f, buf, sz) (f->f_op->write(f, buf, sz, &f->f_pos))
>
> struct element {
> int data[16];
> };
>
>
> struct element *ptr=0;
> unsigned int c_element = 0;
>
> void af_add(struct element t) {
>
> struct file *f;
> char path[24];
> mm_segment_t oldfs;
>
> spinlock_t af_add_lock = SPIN_LOCK_UNLOCKED;
>
> spin_lock(&af_add_lock); // or
> lock_kernel();
>
> if ((c_element + 1) != ELEMENT_MAX){
>
> if(!ptr) {
>
> ptr = kmalloc(sizeof(struct element)*ELEMENT_MAX,
> GFP_KERNEL);
> if(!ptr){
> printk("nie moge zaalokowac mem..\n");
> return;
> }
>
> }else{
> memcpy(ptr + c_element, &t, sizeof(struct element));
> }
>
>
> }else {
>
> snprintf(path, sizeof(path), "/tmp/dumplog"); //
> open file
> f = filp_open(path, O_CREAT | O_APPEND, 00600);
>
> if (IS_ERR(f) || !f) { //
> check if it
> properly opened
> printk("blad przy otwieraniu..\n");
> return;
> }
>
> oldfs = get_fs(); //
> switch
> user/kernel
> set_fs(get_ds());
>
> printk("write: %d\n", write(f, (void *) ptr, sizeof(struct
> element) * ELEMENT_MAX)); // write to file
>
> set_fs(oldfs);
>
> filp_close(f, 0);
>
> c_swap++;
> c_element = 0;
> }
>
> c_element++;
>
>
> spin_unlock(&af_add_lock); // or unlock_kernel();
>
>
> }
>
>
> ***************************************************************
>
>
> This is added to icmp.c code just to be able to test easily.
>
> In icmp.c it is called for every packet like this:
>
> ***************************************
> static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
> {
> ... /* original icmp.c code */
>
> struct element t;
> int ii;
> // for(ii=0; ii<8; ii++)
> t.data[0]=222;
> af_add(t);
>
> ... /* original icmp.c code */
>
> }
> ***************************************
>
> And sometimes it works .. .some strange data are writen to dumplog
> file.....
>
>
> please help this is part of my research.. and i can not go ANY FURTHER
> witouh it
>
> thank you in advance
>
>
> adam
>
> -
> : send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
