[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130207182642.GQ2875@htj.dyndns.org>
Date: Thu, 7 Feb 2013 10:26:42 -0800
From: Tejun Heo <tj@...nel.org>
To: akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org
Subject: [PATCH v2 23/77] block/loop: convert to idr_alloc()
Subject: block/loop: convert to idr_alloc()
Convert to the much saner new idr interface.
v2: loop_add() treats -1 @i as request for any free ID while any other
negative trigger -EINVAL. The v1 conversion treated any negative
number as valid request for any free ID. While this doesn't make
any difference for in-kernel users, loop_add() is almost directly
visible to userland via LOOP_CTL_ADD and this behavior change is
userland-visible. Restore -EINVAL on < -1.
Signed-off-by: Tejun Heo <tj@...nel.org>
Acked-by: Jens Axboe <axboe@...nel.dk>
---
Another mistake I noticed while auditing the conversions again. I
don't think this would actually affect anybody but no reason to change
the behavior.
Thanks.
drivers/block/loop.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1624,30 +1624,19 @@ static int loop_add(struct loop_device *
if (!lo)
goto out;
- if (!idr_pre_get(&loop_index_idr, GFP_KERNEL))
- goto out_free_dev;
-
+ /* allocate id, if @id >= 0, we're requesting that specific id */
if (i >= 0) {
- int m;
-
- /* create specific i in the index */
- err = idr_get_new_above(&loop_index_idr, lo, i, &m);
- if (err >= 0 && i != m) {
- idr_remove(&loop_index_idr, m);
+ err = idr_alloc(&loop_index_idr, lo, i, i + 1, GFP_KERNEL);
+ if (err == -ENOSPC)
err = -EEXIST;
- }
} else if (i == -1) {
- int m;
-
- /* get next free nr */
- err = idr_get_new(&loop_index_idr, lo, &m);
- if (err >= 0)
- i = m;
+ err = idr_alloc(&loop_index_idr, lo, 0, 0, GFP_KERNEL);
} else {
err = -EINVAL;
}
if (err < 0)
goto out_free_dev;
+ i = err;
err = -ENOMEM;
lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists