- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

add_timer crashes the kernel,Why?
by lijin liu Dec. 20, 2010

Dec. 20, 2010

Hello everyone! I want to use the timer in my kernel module. I read the book _Linux kernel development 3rd version_ and LDD 3rd version. Both the two books tell me write the code like this: struct timer_list my_timer; init_timer(&my_timer); my_timer.expires = jiffies + wait; my_timer.data = 0; my_timer.function=my_function; //active the timer: add_timer(&timer); When I insmod the module, the kernel crashed, and when I change my code to *mod_timer* rather than add_timer. It just works! But why the add_timer crash the kernel?

5 4

Re: add_timer crashes the kernel,Why?
by lijin liu Dec. 20, 2010

Dec. 20, 2010

On Mon, Dec 20, 2010 at 4:42 PM, Raz <raziebe(a)gmail.com> wrote: > try to remove mytimer from stack Yes, I made a stupid mistake, It works now.

2 1

Re: strncpy_from_user called from invalid context?
by Dave Hylands Dec. 20, 2010

Dec. 20, 2010

Hi Greg, On Sat, Dec 18, 2010 at 2:27 PM, Greg Kerr <kerrgi(a)gmail.com> wrote: > In order to learn the jprobes interface, I am a writing a fairly silly example > jprobe. However, I'm having issues copying a string from userspace.... > Basically somehow I wind up calling a function that may sleep from an invalid > context (interrupts disabled or something). > > I have the source of the function in question and the stack trace below. If > anyone could give me a few pointers it would be greatly appreciated. I'd get rid of the 1K stack variable. I think on x86, the kernel stack is only 4K. Use kmalloc instead. If your stack variable is crossing the page boundary and nothing is mapped into memory there, then that could cause the page fault. I'd also recommend using strlcpy rather than strncpy. See: <http://www.gratisoft.us/todd/papers/strlcpy.html> Your use of strncpy is incomplete. To be complete, you need to do: strncpy( dest, src, sizeof( dest )); dest[ sizeof( dest ) - 1 ] = '\0'; I'm not 100% sure about strncpy_from_user but with regular strncpy, if the length of the source is >= sizeof the destination, then your destination string won't be null terminated. And of course, you should make sure that the user-mode program passed in a valid pointer. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/

1 0

Fwd: strncpy_from_user called from invalid context?
by Mulyadi Santosa Dec. 20, 2010

Dec. 20, 2010

Resending it to the new shiny mailing list address :D ---------- Forwarded message ---------- From: Mulyadi Santosa <mulyadi.santosa(a)gmail.com> Date: Sun, Dec 19, 2010 at 12:36 Subject: Re: strncpy_from_user called from invalid context? To: Greg Kerr <kerrgi(a)gmail.com> Cc: kernelnewbies(a)nl.linux.org Hi Greg.... let us see the basic situation first...since I am not an expert either... On Sun, Dec 19, 2010 at 05:27, Greg Kerr <kerrgi(a)gmail.com> wrote: > [ 421.250737] BUG: sleeping function called from invalid context at > arch/x86/mm/fault.c:1074 > [ 421.250742] in_atomic(): 0, irqs_disabled(): 1, pid: 1718, name: dmesg > [ 421.250745] Pid: 1718, comm: dmesg Not tainted 2.6.35.9-64.fc14.x86_64 #1 > [ 421.250748] Call Trace: > [ 421.250756] [<ffffffff8103d1d5>] __might_sleep+0xeb/0xf0 > [ 421.250761] [<ffffffff8146cbf4>] do_page_fault+0x15c/0x265 > [ 421.250765] [<ffffffff8146a075>] page_fault+0x25/0x30 > [ 421.250770] [<ffffffff8121db83>] ? strncpy+0xc/0x27 > [ 421.250774] [<ffffffffa000f049>] j_sys_open+0x37/0xc6 [exe_probe] I am not 100% sure if I "cut" the stack trace into the most relevant path, so let's just assume it is indeed correct. First, irqs_disabled = 1 makes me think that you probably hook into atomic code path. Before answering that, may we know, where do you put this hook anyway? at the sys_open() itself? or somewhere else? Second complication is that fairly likely, it retrieves file name (I hope I read your code correctly) from use memory area that might be swapped out. If it is the problem, then mlock() it could be the workaround. However, the solution might be non All in all, it's better to also write down the way you register the probe etc, that way we could have better understanding of your work, thus might pinpoint another root of the problem itself. PS: on a second thought, I am curious on why I see __do_fault in early "stage" of your back trace. Could it be that your code might be called during page fault itself? Thus it's something like: fault--> supposed to be atomic from here on-->read a portion of a file--> your probe called--> do something that blocks--> boom? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com

1 0

Enabling Posting to the list
by Rishi Agrawal Dec. 20, 2010

Dec. 20, 2010

-- Regards, Rishi Agrawal

1 0