summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* cciss: use consistent variable namesStephen M. Cameron2010-08-073-612/+592
| | | | | | | | | cciss: use consistent variable names "h", for the hba structure and "c" for the command structures. and get rid of trivial CCISS_LOCK macro. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: forbid hard reset of 640x boardsStephen M. Cameron2010-08-071-1/+16
| | | | | | | | | | | | | | cciss: forbid hard reset of 640x boards The 6402/6404 are two PCI devices -- two Smart Array controllers -- that fit into one slot. It is possible to reset them independently, however, they share a battery backed cache module. One of the pair controls the cache and the 2nd one access the cache through the first one. If you reset the one controlling the cache, the other one will not be a happy camper. So we just forbid resetting this conjoined mess. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: sanitize max commandsStephen M. Cameron2010-08-071-1/+13
| | | | | | | | | | | | cciss: sanitize max commands Some controllers might try to tell us they support 0 commands in performant mode. This is a lie told by buggy firmware. We have to be wary of this lest we try to allocate a negative number of command blocks, which will be treated as unsigned, and get an out of memory condition. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: fix hard reset code.Stephen M. Cameron2010-08-072-52/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | cciss: Fix hard reset code. Smart Array controllers newer than the P600 do not honor the PCI power state method of resetting the controllers. Instead, in these cases we can get them to reset via the "doorbell" register. This escaped notice until we began using "performant" mode because the fact that the controllers did not reset did not normally impede subsequent operation, and so things generally appeared to "work". Once the performant mode code was added, if the controller does not reset, it remains in performant mode. The code immediately after the reset presumes the controller is in "simple" mode (which previously, it had remained in simple mode the whole time). If the controller remains in performant mode any code which presumes it is in simple mode will not work. So the reset needs to be fixed. Unfortunately there are some controllers which cannot be reset by either method. (eg. p800). We detect these cases by noticing that the controller seems to remain in performant mode even after a reset has been attempted. In those cases we ignore the controller, as any commands outstanding on it will result in stale completions. To sum up, we try to do a better job of resetting the controller if "reset_devices" is set, and if it doesn't work, we ignore that controller. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_reset_devices()Stephen M. Cameron2010-08-072-20/+34
| | | | | | | cciss: factor out cciss_reset_devices() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_find_cfg_addrs.Stephen M. Cameron2010-08-071-12/+23
| | | | | | | | Rationale for this is that I will also need to use this code in fixing kdump host reset code prior to having the hba structure. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_enter_performant_modeStephen M. Cameron2010-08-071-39/+59
| | | | | | | cciss: factor out cciss_enter_performant_mode Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_wait_for_mode_change_ack()Stephen M. Cameron2010-08-071-12/+15
| | | | | | | cciss: factor out cciss_wait_for_mode_change_ack() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: make cciss_put_controller_into_performant_mode as __devinitStephen M. Cameron2010-08-071-2/+1
| | | | | | | cciss: make cciss_put_controller_into_performant_mode as __devinit Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: cleanup some debug ifdefsStephen M. Cameron2010-08-071-7/+3
| | | | | | | cciss: cleanup some debug ifdefs Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_p600_dma_prefetch_quirk()Stephen M. Cameron2010-08-071-18/+19
| | | | | | | cciss: factor out cciss_p600_dma_prefetch_quirk() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_enable_scsi_prefetch()Stephen M. Cameron2010-08-071-10/+13
| | | | | | | cciss: factor out cciss_enable_scsi_prefetch() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out CISS_signature_present()Stephen M. Cameron2010-08-071-5/+13
| | | | | | | cciss: factor out CISS_signature_present() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_find_board_paramsStephen M. Cameron2010-08-071-27/+25
| | | | | | | cciss: factor out cciss_find_board_params Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: fix leak of ioremapped memoryStephen M. Cameron2010-08-071-0/+12
| | | | | | | | cciss: fix leak of ioremapped memory in cciss_pci_init error path. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_find_cfgtablesStephen M. Cameron2010-08-071-34/+34
| | | | | | | cciss: factor out cciss_find_cfgtables Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_wait_for_board_ready()Stephen M. Cameron2010-08-072-15/+32
| | | | | | | cciss: factor out cciss_wait_for_board_ready() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_find_memory_BAR()Stephen M. Cameron2010-08-071-18/+19
| | | | | | | cciss: factor out cciss_find_memory_BAR() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: remove board_id parameter from cciss_interrupt_mode()Stephen M. Cameron2010-08-071-6/+5
| | | | | | | cciss: remove board_id parameter from cciss_interrupt_mode() Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_board_disabledStephen M. Cameron2010-08-071-6/+9
| | | | | | | cciss: factor out cciss_board_disabled Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: factor out cciss_lookup_board_idStephen M. Cameron2010-08-071-31/+35
| | | | | | | cciss: factor out cciss_lookup_board_id Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: save pdev pointer in per hba structure early to avoid passing it ↵Stephen M. Cameron2010-08-071-30/+31
| | | | | | | | | around so much. cciss: save pdev pointer in per hba structure early to avoid passing it around so much. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* cciss: Set the performant mode bit in the scsi half of the driverStephen M. Cameron2010-08-071-18/+2
| | | | | | | | | | | | | | cciss: Set the performant mode bit in the scsi half of the driver In a couple of places, the performant mode bit wasn't being set in the scsi half of the driver, causing commands to seem to hang. Use enqueue_cmd_and_start_io() where appropriate. This fixes a bug that echo engage scsi > /proc/driver/cciss/cciss0 would hang. Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Klog the unclean release pathDaniel Stodden2010-08-071-0/+6
| | | | | | Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Remove obsolete info->usersDaniel Stodden2010-08-071-8/+2
| | | | | | | | This is just bd_openers, protected by the bd_mutex. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Remove obsolete info->usersDaniel Stodden2010-08-071-6/+3
| | | | | | | | This is just bd_openers, protected by the bd_mutex. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Lock blockfront_info during xbdev removalDaniel Stodden2010-08-071-6/+35
| | | | | | | | | | Same approach as blkfront_closing: * Grab the bdev safely, holding the info mutex. * Zap xbdev safely, holding the info mutex. * Try bdev removal safely, holding bd_mutex. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* blkfront: Fix blkfront backend switch race (bdev release)Daniel Stodden2010-08-071-16/+33
| | | | | | | | | | | | | | | We cannot read backend state within bdev operations, because it risks grabbing the state change before xenbus gets to do it. Fixed by tracking deferral with a frontend switch to Closing. State exposure isn't strictly necessary, but the backends won't mind. For a 'clean' deferral this seems actually a more decent protocol than raising errors. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Fix blkfront backend switch race (bdev open)Daniel Stodden2010-08-071-7/+24
| | | | | | | | | | | | | We need not mind if users grab a late handle on a closing disk. We probably even should not. But we have to make sure it's not a dead one already Let the bdev deal with a gendisk deleted under its feet. Takes the info mutex to decide a race against backend closing. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Lock blkfront_info when closingDaniel Stodden2010-08-071-21/+40
| | | | | | | | | | | | | | | The bdev .open/.release fops race against backend switches to Closing, handled by the XenBus thread. The original code attempted to serialize block device holders and xenbus only via bd_mutex. This is insufficient, the info->bd pointer may already be stale (or null) while xenbus tries to bump up the refcount. Protect blkfront_info with a dedicated mutex. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* blkfront: Clean up vbd releaseDaniel Stodden2010-08-071-48/+43
| | | | | | | | | | | | | | | * Current blkfront_closing is rather a xlvbd_release_gendisk. Renamed in preparation of later patches (need the name again). * Removed the misleading comment -- this only applied to the backend switch handler, and the queue is already flushed btw. * Break out the xenbus call, callers know better when to switch frontend state. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: Fix gendisk leakDaniel Stodden2010-08-071-0/+3
| | | | | Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* blkfront: Fix backtrace in del_gendiskDaniel Stodden2010-08-071-3/+3
| | | | | | | | | The call to del_gendisk follows an non-refcounted gd->queue pointer. We release the last ref in blk_cleanup_queue. Fixed by reordering releases accordingly. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* xenbus: Make xenbus_switch_state transactionalDaniel Stodden2010-08-071-24/+66
| | | | | | | | | | | | | | | | | | | | | According to the comments, this was how it's been done years ago, but apparently took an xbt pointer from elsewhere back then. The code was removed because of consistency issues: cancellation wont't roll back the saved xbdev->state. Still, unsolicited writes to the state field remain an issue, especially if device shutdown takes thread synchronization, and subtle races cause accidental recreation of the device node. Fixed by reintroducing the transaction. An internal one is sufficient, so the xbdev->state value remains consistent. Also fixes the original hack to prevent infinite recursion. Instead of bailing out on the first attempt to switch to Closing, checks call depth now. Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* xen/blkfront: revalidate after setting capacityK. Y. Srinivasan2010-08-071-0/+1
| | | | | Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* xen/blkfront: avoid compiler warning from missing casesJeremy Fitzhardinge2010-08-071-0/+3
| | | | | | | | Fix: drivers/block/xen-blkfront.c: In function ‘blkfront_connect’: drivers/block/xen-blkfront.c:933: warning: enumeration value ‘BLKIF_STATE_DISCONNECTED’ not handled in switch Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* xen/front: Propagate changed size of VBDsK. Y. Srinivasan2010-08-071-2/+17
| | | | | | | | | Support dynamic resizing of virtual block devices. This patch supports both file backed block devices as well as physical devices that can be dynamically resized on the host side. Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* blkfront: don't access freed struct xenbus_deviceJan Beulich2010-08-071-18/+16
| | | | | | | | | | Unfortunately commit "blkfront: fixes for 'xm block-detach ... --force'" still wasn't quite right - there was a reference to freed memory left from blkfront_closing(). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* blkfront: fixes for 'xm block-detach ... --force'Jan Beulich2010-08-071-7/+81
| | | | | | | | | | | | | | | | | | Prevent prematurely freeing 'struct blkfront_info' instances (when the xenbus data structures are gone, but the Linux ones are still needed). Prevent adding a disk with the same (major, minor) [and hence the same name and sysfs entries, which leads to oopses] when the previous instance wasn't fully de-allocated yet. This still doesn't address all issues resulting from forced detach: I/O submitted after the detach still blocks forever, likely preventing subsequent un-mounting from completing. It's not clear to me (not knowing much about the block layer) how this can be avoided. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* xen: use less generic names in blkfront driver.Ian Campbell2010-08-071-6/+6
| | | | | | | | | All Xen frontend drivers have a couple of identically named functions which makes figuring out which device went wrong from a stacktrace harder than it needs to be. Rename them to something specificto the device type. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
* writeback.h: needs linux/device.hRandy Dunlap2010-08-071-0/+1
| | | | | | | | | | include/trace/events/writeback.h uses dev_name(), so it needs to include linux/device.h. include/trace/events/writeback.h:12: error: implicit declaration of function 'dev_name' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* block: fix problem with sending down discard that isn't of correct granularityJens Axboe2010-08-071-3/+12
| | | | | | | | | | | 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 <jaxboe@fusionio.com>
* blkdev: check for valid request queue before issuing flushDave Chinner2010-08-071-0/+9
| | | | | | | | | | | | 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 <dchinner@redhat.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* block: fix for block tracing build errorStephen Rothwell2010-08-071-11/+15
| | | | | | | | | block/compat_ioctl.c: In function 'compat_blkdev_ioctl': block/compat_ioctl.c:754: error: 'BLKTRACESETUP32' undeclared (first use in this function) Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* scsi/i2o: restore ioctl changesArnd Bergmann2010-08-071-5/+16
| | | | | | | | | | | | | | | | | | | | | This restores the changes from "scsi/i2o_block: cleanup ioctl handling", which accidentally got reverted. Origignal changelog: This fixes the ioctl function of the i2o_block driver, which has multiple problems: * The BLKI2OSRSTRAT and BLKI2OSWSTRAT commands always return -ENOTTY on success, where they should return 0. * Support for 32 bit compat is missing * The driver should use the .ioctl function and because .locked_ioctl is going away. The use of the big kernel lock remains for now, but gets made explictit in the ioctl function. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* scsi/sd: remove big kernel lockArnd Bergmann2010-08-072-11/+8
| | | | | | | | | | | | | | | | | | | | | | Every user of the BKL in the sd driver is the result of the pushdown from the block layer into the open/close/ioctl functions. The only place that used to rely on the BKL is the sdkp->openers variable, which gets converted into an atomic_t. Nothing else seems to rely on the BKL, since the functions do not touch global data without holding another lock, and the open/close functions are still protected from concurrent execution using the bdev->bd_mutex. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: linux-scsi@vger.kernel.org Cc: "James E.J. Bottomley" <James.Bottomley@suse.de> Acked-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* block: remove BKL from partition ioctlsArnd Bergmann2010-08-071-4/+0
| | | | | | | | | | | 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 <arnd@arndb.de> cked-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* block: remove BKL from BLKROSET and BLKFLSBUFArnd Bergmann2010-08-071-4/+0
| | | | | | | | | | | | | | | | 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 <arnd@arndb.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* block: push BKL into blktrace ioctlsArnd Bergmann2010-08-074-58/+55
| | | | | | | | | | | | | | 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 <arnd@arndb.de> Acked-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* block: push down BKL into .open and .releaseArnd Bergmann2010-08-0739-48/+334
| | | | | | | | | | | | | | | | | | | | | | | | | | | The open and release block_device_operations are currently called with the BKL held. In order to change that, we must first make sure that all drivers that currently rely on this have no regressions. This blindly pushes the BKL into all .open and .release operations for all block drivers to prepare for the next step. The drivers can subsequently replace the BKL with their own locks or remove it completely when it can be shown that it is not needed. The functions blkdev_get and blkdev_put are the only remaining users of the big kernel lock in the block layer, besides a few uses in the ioctl code, none of which need to serialize with blkdev_{get,put}. Most of these two functions is also under the protection of bdev->bd_mutex, including the actual calls to ->open and ->release, and the common code does not access any global data structures that need the BKL. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
OpenPOWER on IntegriCloud