ida: make ida_simple_get/put() IRQ safe
Subsystems (2)
PATCH 1/1 ida: make ida_simple_get/put() IRQ safe
It's often convenient to be able to release resource from IRQ context. Make ida_simple_*() use irqsave/restore spin ops so that they are IRQ safe.
---
Andrew, can you please route this through mm?
Thank you.
lib/idr.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
lib/idr.c +7 -4
@@ -944,6 +944,7 @@ int ida_simple_get(struct ida *ida, unsi {int ret, id;unsigned int max; +unsigned long flags;BUG_ON ((int )start <0 );BUG_ON ((int )end <0 );
@@ -959,7 +960,7 @@ again:if (!ida_pre_get (ida, gfp_mask))return -ENOMEM ; -spin_lock (&simple_ida_lock); +spin_lock_irqsave (&simple_ida_lock, flags); ret =ida_get_new_above (ida, start, &id);if (!ret) {if (id > max) {
@@ -969,7 +970,7 @@ again: ret = id; } } -spin_unlock (&simple_ida_lock); +spin_unlock_irqrestore (&simple_ida_lock, flags);if (unlikely (ret == -EAGAIN )) goto again;
@@ -985,10 +986,12 @@ EXPORT_SYMBOL(ida_simple_get);*/ void ida_simple_remove (struct ida *ida,unsigned int id) { +unsigned long flags; +BUG_ON ((int )id <0 ); -spin_lock (&simple_ida_lock); +spin_lock_irqsave (&simple_ida_lock, flags);ida_remove (ida, id); -spin_unlock (&simple_ida_lock); +spin_unlock_irqrestore (&simple_ida_lock, flags); }EXPORT_SYMBOL (ida_simple_remove);
Andrew Morton
maintainerQuoted 3 lines · On Wed, 26 Oct 2011 13:33:11 -0700 Tejun Heo <[email protected]> wrote:
It's often convenient to be able to release resource from IRQ context. Make ida_simple_*() use irqsave/restore spin ops so that they are IRQ safe.
The patch also accidentally makes ida_simple_get() callable from interrupt context. That's a somewhat unreliable operation due to -ENOMEM possibilities even with GFP_ATOMIC.
Quoted 32 lines
lib/idr.c +3
-2@@ -944,6 +944,7 @@ int ida_simple_get(struct ida *ida, unsi {int ret, id;unsigned int max; +unsigned long flags;BUG_ON ((int )start <0 );BUG_ON ((int )end <0 );@@ -959,7 +960,7 @@ again:if (!ida_pre_get (ida, gfp_mask))return -ENOMEM ; -spin_lock (&simple_ida_lock); +spin_lock_irqsave (&simple_ida_lock, flags); ret =ida_get_new_above (ida, start, &id);if (!ret) {if (id > max) {@@ -969,7 +970,7 @@ again: ret = id; } } -spin_unlock (&simple_ida_lock); +spin_unlock_irqrestore (&simple_ida_lock, flags);if (unlikely (ret == -EAGAIN )) goto again;@@ -985,10 +986,12 @@ EXPORT_SYMBOL(ida_simple_get);*/ void ida_simple_remove (struct ida *ida,unsigned int id) {
lib/idr.c EXPORT_SYMBOL(ida_simple_get); · line 996
Quoted 10 lines
lib/idr.c +4
-2+unsigned long flags; +BUG_ON ((int )id <0 ); -spin_lock (&simple_ida_lock); +spin_lock_irqsave (&simple_ida_lock, flags);ida_remove (ida, id); -spin_unlock (&simple_ida_lock); +spin_unlock_irqrestore (&simple_ida_lock, flags); }EXPORT_SYMBOL (ida_simple_remove);
It didn't update the kerneldoc. I wouldn't have bothered either ;) We're generally bad about documenting permissible calling environments and preconditions.
Quoted 10 lines · Andrew Morton
Quoted 3 lines · On Wed, 26 Oct 2011 13:33:11 -0700 Tejun Heo <[email protected]> wrote:
It's often convenient to be able to release resource from IRQ context. Make ida_simple_*() use irqsave/restore spin ops so that they are IRQ safe.
The patch also accidentally makes
ida_simple_get()callable from interrupt context. That's a somewhat unreliable operation due to-ENOMEMpossibilities even withGFP_ATOMIC.
Hmmm... We can add a WARN_ON_ONCE() there but do we really care? If the caller is using GFP_ATOMIC, it should be expecting unreliability.
Thanks.
Signature · 1 line
tejun
Andrew Morton
maintainerQuoted 8 lines · On Fri, 28 Oct 2011 16:11:49 -0700 Tejun Heo <[email protected]> wrote:
Quoted 7 lines · Andrew Morton
Quoted 3 lines · On Wed, 26 Oct 2011 13:33:11 -0700 Tejun Heo <[email protected]> wrote:
It's often convenient to be able to release resource from IRQ context. Make ida_simple_*() use irqsave/restore spin ops so that they are IRQ safe.
Quoted 7 lines
Quoted 3 lines
The patch also accidentally makes
ida_simple_get()callable from interrupt context. That's a somewhat unreliable operation due to-ENOMEMpossibilities even withGFP_ATOMIC.Hmmm... We can add a
WARN_ON_ONCE()there but do we really care? If the caller is usingGFP_ATOMIC, it should be expecting unreliability.
No, I don't think we care - I was just chin-scratching and augmenting some deficient changeloggery. Also, showing that I'd actually read the thing ;)