Re: [PATCH/Resend] md: Push down data integrity code to personalities.

[Neil Brown <neilb@suse.de>]

On Monday August 3, maan@systemlinux.org wrote:
> On 15:06, Neil Brown wrote:
> > > Here is a revised patch that puts calls to the new functions into
> > > the ->hot_*_disk methods as you propose.
> > 
> > Thanks.  Much better.
> > Calling md_integrity_check from the ->error routines isn't a good idea
> > though.  They can be called in interrupt context, and
> > md_integrity_check can call kmalloc(..., GFP_KERNEL) which might try
> > to sleep.  That would be bad.
> > We don't need the call in ->error, having it in ->hot_remove_disk is
> > adequate, as that is called soon after any failure (it doesn't wait
> > for the sysadmin to "mdadm --remove ...".).
> > 
> > So I have made that change and updated the comment accordingly.
> 
> Thanks. Sorry if this is a FAQ, but how can one tell whether a given
> function may be called in interrupt context? Is there a better way
> than recursively checking all its callers?

I think you just have to 'know'. :-(
Some functions which mustn't be called from interrupts are
'documented' as such by calling "might_sleep()", but there is no
similar documentation for the reverse.

All ->bi_endio routines are called from interrupts.. or maybe
from softirqs or something similar.  I think the important point is
that they are called without a process context, so they cannot sleep
(i.e. no kmalloc unless you use GFP_ATOMIC, no mutex_lock, no
wait_event etc) and should use spin_lock_irqsave or spin_lock_bh
rather than a bare spin_lock.

NeilBrown