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@xxxxxxxxx> 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 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
