IRQs and memory consistency

[wink@saville.com (Wink Saville)]

Sounds to me like there needs to be a flush of the processor cache
by using memory barriers.

I'm guessing that the IRQ is taken on a different thread and possibly
a different processor and the value needs to be flushed. You might
try having devid be an atomic_t and then use atomic_set
and atomic_read so that the "proper" memory barriers are used.

See: http://www.kernel.org/doc/Documentation/atomic_ops.txt

-- Wink


On Tue, Apr 10, 2012 at 1:22 PM, Christopher Harvey
<chris@basementcode.com>wrote:

> This is a high level question about how IRQs work in the kernel.
>
> I have a struct that was kmalloc'd into ram. Within this struct there
> is an int, called devid. When I set this devid to a number that isn't
> 0, I print the following:
>
> checking devid value....327683 in 0xcb6953d4
>
> where 327683 is the value of the int and 0xcb6953d4 is the address of
> the struct that the devid value is in.
>
> Then an interrupt happens and when I print this value again at the
> beginning of the interrupt handler I get the following printed text:
>
> checking devid value....0 in 0xcb6953d4
>
> notice that the devid has been set to 0. I can't find any code on my
> end that would do this. Is there something, maybe related to memory
> address spaces in IRQ handlers that I don't know about?
>
> The IRQ and the setting of the devid value happen fairly close to
> each other in time. (like less than a second, or closer)
>
> Any ideas or guesses are appreciated.
>
> -Chris
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120410/885355e9/attachment.html