linux/block, branch v2.6.36-rc2

block: add secure discard

2010-08-12T15:43:30Z

Secure discard is the same as discard except that all copies of the discarded sectors (perhaps created by garbage collection) must also be erased. Signed-off-by: Adrian Hunter Acked-by: Jens Axboe Cc: Kyungmin Park Cc: Madhusudhan Chikkature Cc: Christoph Hellwig Cc: Ben Gardiner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

blkdev: fix blkdev_issue_zeroout return value

2010-08-08T16:31:08Z

- If function called without barrier option retvalue is incorrect Signed-off-by: Dmitry Monakhov Signed-off-by: Jens Axboe

block: update request stacking methods to support discards

2010-08-08T16:11:33Z

Propagate REQ_DISCARD in cmd_flags when cloning a discard request. Skip blk_rq_check_limits's existing checks for discard requests because discard limits will have already been checked in blkdev_issue_discard. Signed-off-by: Mike Snitzer Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: set up rq->rq_disk properly for flush requests

2010-08-07T16:52:41Z

q->bar_rq.rq_disk is NULL. Use the rq_disk of the original request instead. Signed-off-by: FUJITA Tomonori Signed-off-by: Jens Axboe

block: set REQ_TYPE_FS on flush requests

2010-08-07T16:52:40Z

the block layer doesn't set rq->cmd_type on flush requests. By definition, it should be REQ_TYPE_FS (the lower layers build a command and interpret the result of it, that is, the block layer doesn't know the details). Signed-off-by: FUJITA Tomonori Signed-off-by: Jens Axboe

block: fix problem with sending down discard that isn't of correct granularity

2010-08-07T16:26:33Z

If the queue doesn't have a limit set, or it just set UINT_MAX like we default to, we coud be sending down a discard request that isn't of the correct granularity if the block size is > 512b. Fix this by adjusting max_discard_sectors down to the proper alignment. Signed-off-by: Jens Axboe

blkdev: check for valid request queue before issuing flush

2010-08-07T16:26:29Z

Issuing a blkdev_issue_flush() on an unconfigured loop device causes a panic as q->make_request_fn is not configured. This can occur when trying to mount the unconfigured loop device as an XFS filesystem. There are no guards that catch the bio before the request function is called because we don't add a payload to the bio. Instead, manually check this case as soon as we have a pointer to the queue to flush. Signed-off-by: Dave Chinner Signed-off-by: Jens Axboe

block: remove BKL from partition ioctls

2010-08-07T16:26:08Z

The blkpg_ioctl and blkdev_reread_part access fields of the bdev and gendisk structures, yet they always do so under the protection of bdev->bd_mutex, which seems sufficient. Signed-off-by: Arnd Bergmann cked-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: remove BKL from BLKROSET and BLKFLSBUF

2010-08-07T16:26:08Z

We only call the functions set_device_ro(), invalidate_bdev(), sync_filesystem() and sync_blockdev() while holding the BKL in these commands. All of these are also done in other code paths without the BKL, which leads me to the conclusion that the BKL is not needed here either. The reason we hold it here is that it was originally pushed down into the ioctl function from vfs_ioctl. Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: push BKL into blktrace ioctls

2010-08-07T16:26:08Z

The blktrace driver currently needs the BKL, but we should not need to take that in the block layer, so just push it down into the driver itself. It is quite likely that the BKL is not actually required in blktrace code and could be removed in a follow-on patch. Signed-off-by: Arnd Bergmann Acked-by: Christoph Hellwig Signed-off-by: Jens Axboe