* On sg_miter_next sg_miter_stop
@ 2011-03-16 1:40 va stg2010
2011-03-16 4:50 ` Mulyadi Santosa
0 siblings, 1 reply; 5+ messages in thread
From: va stg2010 @ 2011-03-16 1:40 UTC (permalink / raw)
To: kernelnewbies
Hi
Can someone explain to me reason for the comment at line 332-333 of this code
http://lxr.linux.no/#linux+v2.6.27.7/lib/scatterlist.c#L332
comment is:
" IRQ must stay disabled till @miter@ is stopped."
Thankyou
vks
^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop
2011-03-16 1:40 On sg_miter_next sg_miter_stop va stg2010
@ 2011-03-16 4:50 ` Mulyadi Santosa
2011-03-16 17:26 ` va stg2010
0 siblings, 1 reply; 5+ messages in thread
From: Mulyadi Santosa @ 2011-03-16 4:50 UTC (permalink / raw)
To: kernelnewbies
Hi..
On Wed, Mar 16, 2011 at 08:40, va stg2010 <va.storage2010@gmail.com> wrote:
> Hi
> Can someone explain to me reason for the comment at line 332-333 of this code
> http://lxr.linux.no/#linux+v2.6.27.7/lib/scatterlist.c#L332
>
> comment is:
> " ? IRQ must stay disabled till @miter@ is stopped."
OK, is this the complete comment you referred?
"Context:
332 * IRQ disabled if SG_MITER_ATOMIC. IRQ must stay disabled till
333 * @miter@ is stopped. May sleep if !SG_MITER_ATOMIC."
well, then, my raw guess is, because it must be done atomically (when
asked to do so). Usually, atomic operation has tight relationship with
something that must be done in short time and/or must not be
interrupted by interrupt handler.
Since this is talking about scatter list, I could only guess few
example...perhaps in bio handling?
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop
2011-03-16 4:50 ` Mulyadi Santosa
@ 2011-03-16 17:26 ` va stg2010
2011-03-16 17:49 ` Mulyadi Santosa
0 siblings, 1 reply; 5+ messages in thread
From: va stg2010 @ 2011-03-16 17:26 UTC (permalink / raw)
To: kernelnewbies
Mulyadi,
I referred to this comment. "IRQ must stay disabled till @miter@
is stopped. "
Yes my operations are atomic and I set miter->flag as SG_MITER_ATOMIC
when i call sg_miter_start()
But from comment it seems sg_miter_stop should be called before
IRQ is enabled.
I also looked into sg_miter_next() and sg_miter_stop()
implementations. They are calling kmap_atomic() and
kunmap_atomic() respectively. Based on comment -- Is following an
illegal operation? and why?
1) IRQ disabled
2) sg_miter_next , meaning kmap_atomic
3) IRQ enabled
4) IRQ disabled again little later
5) sg_miter_stop, meaning kunmap_atomic()
The above sequence caused following scheduler messages (if
sg_miter_stop() is moved between step1 & step3 then following error
messages disappeared) :--------
BUG: scheduling while atomic: swapper/0/0xffffffff
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
BUG: scheduling while atomic: swapper/0/0x00000001
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
[<ffffffff81134318>] cpu_idle+0x48/0x50
BUG: scheduling while atomic: swapper/0/0x00000001
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
[<ffffffff81134318>] cpu_idle+0x48/0x50
BUG: scheduling while atomic: swapper/0/0x00000001
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
[<ffffffff81134318>] cpu_idle+0x48/0x50
On Tue, Mar 15, 2011 at 9:50 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> Hi..
>
> On Wed, Mar 16, 2011 at 08:40, va stg2010 <va.storage2010@gmail.com> wrote:
>> Hi
>> Can someone explain to me reason for the comment at line 332-333 of this code
>> http://lxr.linux.no/#linux+v2.6.27.7/lib/scatterlist.c#L332
>>
>> comment is:
>> " ? IRQ must stay disabled till @miter@ is stopped."
>
> OK, is this the complete comment you referred?
> "Context:
> ?332 * ? IRQ disabled if SG_MITER_ATOMIC. ?IRQ must stay disabled till
> ?333 * ? @miter@ is stopped. ?May sleep if !SG_MITER_ATOMIC."
>
> well, then, my raw guess is, because it must be done atomically (when
> asked to do so). Usually, atomic operation has tight relationship with
> something that must be done in short time and/or must not be
> interrupted by interrupt handler.
>
> Since this is talking about scatter list, I could only guess few
> example...perhaps in bio handling?
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop
2011-03-16 17:26 ` va stg2010
@ 2011-03-16 17:49 ` Mulyadi Santosa
2011-03-16 18:48 ` va stg2010
0 siblings, 1 reply; 5+ messages in thread
From: Mulyadi Santosa @ 2011-03-16 17:49 UTC (permalink / raw)
To: kernelnewbies
Hi...
On Thu, Mar 17, 2011 at 00:26, va stg2010 <va.storage2010@gmail.com> wrote:
> I also looked into sg_miter_next() ? and sg_miter_stop()
> implementations. ?They ?are calling ?kmap_atomic() ? and
> kunmap_atomic() respectively. ? ?Based on comment -- ?Is following an
> illegal operation? and why?
> 1) ?IRQ disabled
> 2) sg_miter_next , meaning kmap_atomic
> 3) IRQ enabled
> 4) ?IRQ ?disabled again little later
> 5) sg_miter_stop, meaning kunmap_atomic()
>
> The above sequence caused following scheduler messages (if
> sg_miter_stop() ?is moved between step1 & step3 then following error
> messages disappeared) :--------
> BUG: scheduling while atomic: swapper/0/0xffffffff
> Modules linked in: my_scsi_lld
quite likely the error was triggered not due to kmap_atomic() and
kunmap_atomic(), but due to something that you do toward the page
allocated via kmap_atomic() itself.
kmap_atomic() theoritically should not be affected by the state of
interrupt delivery....
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop
2011-03-16 17:49 ` Mulyadi Santosa
@ 2011-03-16 18:48 ` va stg2010
0 siblings, 0 replies; 5+ messages in thread
From: va stg2010 @ 2011-03-16 18:48 UTC (permalink / raw)
To: kernelnewbies
On Wed, Mar 16, 2011 at 10:49 AM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> Hi...
>
> On Thu, Mar 17, 2011 at 00:26, va stg2010 <va.storage2010@gmail.com> wrote:
>> I also looked into sg_miter_next() ? and sg_miter_stop()
>> implementations. ?They ?are calling ?kmap_atomic() ? and
>> kunmap_atomic() respectively. ? ?Based on comment -- ?Is following an
>> illegal operation? and why?
>> 1) ?IRQ disabled
>> 2) sg_miter_next , meaning kmap_atomic
>> 3) IRQ enabled
>> 4) ?IRQ ?disabled again little later
>> 5) sg_miter_stop, meaning kunmap_atomic()
>>
>> The above sequence caused following scheduler messages (if
>> sg_miter_stop() ?is moved between step1 & step3 then following error
>> messages disappeared) :--------
>> BUG: scheduling while atomic: swapper/0/0xffffffff
>> Modules linked in: my_scsi_lld
>
> quite likely the error was triggered not due to kmap_atomic() and
> kunmap_atomic(), but due to something that you do toward the page
> allocated via kmap_atomic() itself.
The page is given to my scsi mid layer LLDD by linux-scsi layer for
SCSI read request. When sg_miter_stop() happens the page will have
READ data available and I call scsi_done().
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-16 18:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-16 1:40 On sg_miter_next sg_miter_stop va stg2010
2011-03-16 4:50 ` Mulyadi Santosa
2011-03-16 17:26 ` va stg2010
2011-03-16 17:49 ` Mulyadi Santosa
2011-03-16 18:48 ` va stg2010
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).