[SOLVED] Function that only works when casting types?

yaplej · 11-02-2009, 06:36 PM

Hey all,

I have been working on this function that I could only get to work by casting the types when assigning values to a structure pointer. I have other function that work fine without type casting, and even fail when I try to type cast them.

Is there any reason that this function would require the type to be cast in order to work? When I tried just simply assigning them with "currentsession->field = 0". I would get a kernel panic.

Code:

static void clearsession(struct index *currentindex){
	struct session *currentsession = NULL;

	/* Clear this session. */
	
	if (currentindex != NULL){
		spin_lock(&currentindex->lock);
		currentindex->used = (__u8)0;
		currentsession = currentindex->slot;
		
		if (currentsession != NULL){
			spin_lock(&currentsession->lock);
			currentsession->largerIP = (__u32)0;
			currentsession->largerIPPort = (__u16)0;
			currentsession->smallerIP = (__u32)0;
			currentsession->smallerIPPort = (__u16)0;
			currentsession->local = (__u32)0;
			currentsession->remote = (__u32)0;
			currentsession->state = (__u8)0;
			spin_unlock(&currentsession->lock);
		}
		spin_unlock(&currentindex->lock);
	}

}

johnsfine · 11-02-2009, 06:45 PM

It is surprising that those casts even change the generated code. It is so surprising that I think looking at the change in the generated code might provide some insight into the nature of the failure.

Can you generate .s files (compiling with -S in gcc) with and without those casts, and find the difference in the generated code?

yaplej · 11-02-2009, 07:24 PM

Well this is a kernel module, and I have not been able to compile directly with gcc, but am using a makefile to compile it.

yaplej · 11-02-2009, 08:45 PM

I was able to compile them using gcc into h.gch files, and compare them. They are definatly different. I cannot upload them here, but I uploaded them to my skydrive if you want to see them.

http://cid-c52d2fb289c57329.skydrive...ger.h.gch?uc=2

johnsfine · 11-02-2009, 10:33 PM

Sorry, I have no idea how to learn anything from a .gch file. The fact that the partially compiled code is different in that form does not mean that the fully compiled code would be different in the final machine code nor even in assembler.

yaplej · 11-03-2009, 12:27 AM

Here is the entire LKM. So you can see all the code.
http://bbfdnq.blu.livefilestore.com/...7.zip?download

johnsfine · 11-03-2009, 09:49 AM

I haven't done any Linux kernel debugging other than one small project so long ago that even if I remembered how, it wouldn't remain relevant.

So I lack the time and probably the expertise to do anything with your code. I also doubt others reading this thread have the time.

Regarding your first post in this thread, I'm pretty sure those casts are not directly relevant to the problem that causes your kernel panic.

If you have some random memory clobber and/or error in allocating, deallocating or mapping the memory, it is very possible for "stirring the pot" to move the symptoms around. That means you might make some change that is not related to the bug but will move or hide the symptoms.

I think those casts are just stirring the pot (not somehow fixing some bug). As I said before, I don't really understand how they are even stirring the pot. I would have expected the compiler to filter out all effects of that code change. So if you could post the before and after versions of that chunk of assembler code, I might give you some insight about it. But I'm not going to try to generate that before and after assembler code myself. Even if I wanted to spend the time, there are too many other variables between what you did and what I might do.

It looks like you were getting better help in your related previous thread
http://www.linuxquestions.org/questi...-array-760651/

But maybe you didn't really solve that problem, just moved the symptoms. I can't help noticing the similarity between the kind of problem you have in this thread and the kind of problem you would have if you hadn't gotten the solution to that thread quite right.

yaplej · 11-03-2009, 03:37 PM

The previous thread had to do with allocating memory. I found that the method I was trying to use just would not work in my module because the functions I am writing are executed in an interrupt context, and there are some limitations of what can be done in that context. Primarily nothing can sleep. Sleeping in an interrupt context will cause the kernel to panic.

I re-wrote the method I was storing data to use a linked list rather than an array. This allows me to get the large quantity of memory I need using kmalloc()/kcalloc() atomically so its compatible with running in an interrupt context.

I have never used gcc to create assembler code. I will try to figure that out for a kernel module if that would help debugging. I thought that if it were trying to save "0" as a 32-bit or 64-bit version of "0" to some of the fields in the structure I am using it might be able to clobber memory next to the memory assigned to the structure. I am not sure if thats a possibility or not though.

yaplej · 11-19-2009, 06:35 PM

I found some other problems, and after getting them fixed this problem went away. It was definatly a case of "stiring the pot". Thanks for the help.