idr: introduce idr_alloc_cyclic()

As Tejun points out, there are several users of the IDR facility that
attempt to use it in a cyclic fashion.  These users are likely to see
-ENOSPC errors after the counter wraps one or more times however.

This patchset adds a new idr_alloc_cyclic routine and converts several
of these users to it.  Many of these users are in obscure parts of the
kernel, and I don't have a good way to test some of them.  The change is
pretty straightforward though, so hopefully it won't be an issue.

There is one other cyclic user of idr_alloc that I didn't touch in
ipc/util.c.  That one is doing some strange stuff that I didn't quite
understand, but it looks like it should probably be converted later
somehow.

This patch:

Thus spake Tejun Heo:

    Ooh, BTW, the cyclic allocation is broken.  It's prone to -ENOSPC
    after the first wraparound.  There are several cyclic users in the
    kernel and I think it probably would be best to implement cyclic
    support in idr.

This patch does that by adding new idr_alloc_cyclic function that such
users in the kernel can use.  With this, there's no need for a caller to
keep track of the last value used as that's now tracked internally.  This
should prevent the ENOSPC problems that can hit when the "last allocated"
counter exceeds INT_MAX.

Later patches will convert existing cyclic users to the new interface.

Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Tejun Heo <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: "J. Bruce Fields" <[email protected]>
Cc: Eric Paris <[email protected]>
Cc: Jack Morgenstein <[email protected]>
Cc: John McCutchan <[email protected]>
Cc: Neil Horman <[email protected]>
Cc: Or Gerlitz <[email protected]>
Cc: Robert Love <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Sridhar Samudrala <[email protected]>
Cc: Steve Wise <[email protected]>
Cc: Tom Tucker <[email protected]>
Cc: Vlad Yasevich <[email protected]>

Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

0 files changed, 0 insertions, 0 deletions