kernel.git/drivers/scsi/osd, branch linux-2.6.36.y

[SCSI] fix bio.bi_rw handling

2010-09-02T20:11:55Z

Return of the bi_rw tests is no longer bool after commit 74450be1. So testing against constants doesn't make sense anymore. Fix this bug in osd_req_read by removing "== 1" in test. This is not a problem now, where REQ_WRITE is 1, but this can change in the future and we don't want to rely on that. Signed-off-by: Jiri Slaby Signed-off-by: James Bottomley

block: unify flags for struct bio and struct request

2010-08-07T16:20:39Z

Remove the current bio flags and reuse the request flags for the bio, too. This allows to more easily trace the type of I/O from the filesystem down to the block driver. There were two flags in the bio that were missing in the requests: BIO_RW_UNPLUG and BIO_RW_AHEAD. Also I've renamed two request flags that had a superflous RW in them. Note that the flags are in bio.h despite having the REQ_ name - as blkdev.h includes bio.h that is the only way to go for now. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32Z

percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo Guess-its-ok-by: Christoph Lameter Cc: Ingo Molnar Cc: Lee Schermerhorn

[SCSI] libosd: Fix unchecked err return found by smatch

2010-03-03T15:42:21Z

Doing CHECK="smatch --two-passes gives: drivers/scsi/osd/osd_initiator.c +1435 osd_finalize_request warning: assignment to 'ret' was never used Which is an unchecked possible allocation failure, Fixed. Reported-by: Dan Carpenter Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley

[SCSI] libosd: Fix blk_put_request locking again

2009-12-10T14:54:17Z

So libosd has decided to sacrifice some code simplicity for the sake of a clean API. One of these things is the possibility for users to call osd_end_request, in any condition at any state. This opens up some problems with calling blk_put_request when out-side of the completion callback but calling __blk_put_request when detecting a from-completion state. The current hack was working just fine until exofs decided to operate on all devices in parallel and wait for the sum of the requests, before deallocating all osd-requests at once. There are two new possible cases 1. All request in a group are deallocated as part of the last request's async-done, request_queue is locked. 2. All request in a group where executed asynchronously, but de-allocation was delayed to after the async-done, in the context of another thread. Async execution but request_queue is not locked. The solution I chose was to separate the deallocation of the osd_request which has the information users need, from the deallocation of the internal(2) requests which impose the locking problem. The internal block-requests are freed unconditionally inside the async-done-callback, when we know the queue is always locked. If at osd_end_request time we still have a bock-request, then we know it did not come from within an async-done-callback and we can call the regular blk_put_request. The internal requests were used for carrying error information after execution. This information is now copied to osd_request members for later analysis by user code. The external API and behaviour was unchanged, except now it really supports what was previously advertised. Reported-by: Vineet Agarwal Signed-off-by: Boaz Harrosh Cc: Stable Tree Signed-off-by: James Bottomley

[SCSI] libosd: Error handling revamped

2009-12-04T18:01:47Z

Administer some love to the osd_req_decode_sense function * Fix a bad bug with osd_req_decode_sense(). If there was no scsi residual, .i.e the request never reached the target, then all the osd_sense_info members where garbage. * Add grossly missing in/out_resid to osd_sense_info and fill them in properly. * Define an osd_err_priority enum which divides the possible errors into 7 categories in ascending severity. Each category is also assigned a Linux return code translation. Analyze the different osd/scsi/block returned errors and set the proper osd_err_priority and Linux return code accordingly. * extra check a few situations so not to get stuck with inconsistent error view. Example an empty residual with an error code, and other places ... Lots of libosd's osd_req_decode_sense clients had this logic in some form or another. Consolidate all these into one place that should actually know about osd returns. Thous translating it to a more abstract error. Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley

[SCSI] libosd: Bugfix of error handling in attributes-list decoding

2009-12-04T18:01:47Z

When an error was detected in an attribute list do to a target bug. We would print an error but spin endlessly regardless. Fix it. Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley

[SCSI] libosd: bug in osd_req_decode_sense_full()

2009-12-04T18:01:46Z

The (never tested) osd_sense_attribute_identification case has never worked. The loop was never advanced on. Fix it to work as intended. On 10/30/2009 04:39 PM, Roel Kluin wrote: I found this by code analysis, searching for while loops that test a local variable, but do not modify the variable. Reported-by: Roel Kluin Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley

[SCSI] libosd: osd_dev_info: Unique Identification of an OSD device

2009-12-04T18:01:46Z

Define an osd_dev_info structure that Uniquely identifies an OSD device lun on the network. The identification is built from unique target attributes and is the same for all network/SAN machines. osduld_info_lookup() - NEW New API that will lookup an osd_dev by its osd_dev_info. This is used by pNFS-objects for cross network global device identification. And by exofs multy-device support, the device info is specified in the on-disk exofs device table. osduld_device_info() - NEW Given an osd_dev handle returns its associated osd_dev_info. The ULD fetches this information at startup and hangs it on each OSD device. (This is a fast operation that can be called at any condition) osduld_device_same() - NEW With a given osd_dev at one hand and an osd_dev_info at another, we would like to know if they are the same device. Two osd_dev handles can be checked by: osduld_device_same(od1, osduld_device_info(od2)); osd_auto_detect_ver() - REVISED Now returns an osd_dev_info structure. Is only called once by ULD as before. See added comments for how to use. Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley

[SCSI] osduld: Use device->release instead of internal kref

2009-12-04T18:01:45Z

The true logic of this patch will be clear in the next patch where we use the class_find_device() API. When doing so the use of an internal kref leaves us a narrow window where a find is started while the actual object can go away. Using the device's kobj reference solves this problem because now the same kref is used for both operations. (Remove and find) Core changes * Embed a struct device in uld_ structure and use device_register instead of devie_create. Set __remove to be the device release function. * __uld_get/put is just get_/put_device. Now every thing is accounted for on the device object. Internal kref is removed. * At __remove() we can safely de-allocate the uld_ structure. (The function has moved to avoid forward declaration) Some cleanups * Use class register/unregister is cleaner for this driver now. * cdev ref-counting games are no longer necessary I have incremented the device version string in case of new bugs. Note: Previous bugfix of taking the reference around fput() still applies. Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley