From mboxrd@z Thu Jan  1 00:00:00 1970
From: chris@basementcode.com (Christopher Harvey)
Date: Wed, 11 Apr 2012 06:53:27 -0500
Subject: IRQs and memory consistency
In-Reply-To: <CAGdaadYCNy5B14xe+Wrpc6cOsXx7K-4pFaOvrhFt+TAN8VwSOA@mail.gmail.com>
References: <18680507ce5fe185f8355a813376bd26@basementcode.com>
	<CAGdaadYCNy5B14xe+Wrpc6cOsXx7K-4pFaOvrhFt+TAN8VwSOA@mail.gmail.com>
Message-ID: <7f3d57699a606aa5f9d4b73bd89b58ab@basementcode.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

On 10.04.2012 22:18, Mulyadi Santosa wrote:
> Hi....
>
> On Wed, Apr 11, 2012 at 03:22, Christopher Harvey
> <chris@basementcode.com> wrote:
>> The IRQ and the setting of the devid value happen fairly close to
>> each other in time. (like less than a second, or closer)
>
> Hmmm, and how about the order? which one do you guess go first?
> setting value? or the IRQ handler?
>
> I had a sense that your code flow might (in reality) goes like this
>
> allocating struct RAM --> interrupted --> printing struct content -->
> back to initialize struct
>
> If that's true, then no wonder 0 (zero) is printed.
>
> I suggest to grab a spin lock if you really need atomicity during
> allocation and setting initial value, which in IRQ handler, you grab
> the lock before printing. Oh and since memory allocation could go
> slow, you might need to do allocation with GFP_ATOMIC.

well, actually my does does this:

set variable->init hardware->interrupt

the interrupt can't happen until 'init hardware'