[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH][linux 2.6.18] remove pointless error handling in scsiback



From: Juergen Gross <jgross@xxxxxxxx>

Changeset 610:3bcc901cbd7a added a retry logic for reporting LUNs to the
frontend. The idea was to retry the operation if a LUN was added between
counting the LUNs (needed for calculating the needed buffer size) and
processing them (filling the buffer). The number of retries was limited to
three. Reasoning was "one error is very unlikely, 4 of them are way off".

Unfortunately above changeset was wrong: The retry didn't include recounting
the LUNs, so the buffer size would not be changed. The number of found was not
resetted, so the first found LUN would again trigger the retry logic until the
number of retries would be exhausted.

While one error is really very unlikely (there was no report of failure and
as shown above, the first error would have led to failure at once), even in
case of a correct retry logic following errors are not completely impossible:
If a target with many LUNs is being added to the frontend, the single LUNs are
added one after another. A parallel running "report LUNs" could see a fast
increasing number of LUNs, so even a few retries might fail.

So just remove the retry logic again.

Signed-off-by: Juergen Gross <jgross@xxxxxxxx>

diff -r 0251893a7d5a drivers/xen/scsiback/emulate.c
--- a/drivers/xen/scsiback/emulate.c    Mon Jun 16 16:11:33 2014 +0200
+++ b/drivers/xen/scsiback/emulate.c    Wed Jul 02 09:10:49 2014 +0200
@@ -212,7 +212,6 @@ static int __nr_luns_under_host(struct v
 
 /* REPORT LUNS Define*/
 #define VSCSI_REPORT_LUNS_HEADER       8
-#define VSCSI_REPORT_LUNS_RETRY                3
 
 /* quoted scsi_debug.c/resp_report_luns() */
 static void __report_luns(pending_req_t *pending_req, void *data)
@@ -228,7 +227,6 @@ static void __report_luns(pending_req_t 
        unsigned int alloc_luns = 0;
        unsigned int req_bufflen = 0;
        unsigned int actual_len = 0;
-       unsigned int retry_cnt = 0;
        int select_report = (int)cmd[2];
        int i, lun_cnt = 0, lun, upper, err = 0;
        
@@ -245,7 +243,7 @@ static void __report_luns(pending_req_t 
        alloc_luns = __nr_luns_under_host(info);
        alloc_len  = sizeof(struct scsi_lun) * alloc_luns
                                + VSCSI_REPORT_LUNS_HEADER;
-retry:
+
        if ((buff = kzalloc(alloc_len, GFP_KERNEL)) == NULL) {
                printk(KERN_ERR "scsiback:%s kmalloc err\n", __FUNCTION__);
                goto fail;
@@ -261,14 +259,6 @@ retry:
                        if (lun_cnt >= alloc_luns) {
                                spin_unlock_irqrestore(&info->v2p_lock,
                                                        flags);
-
-                               if (retry_cnt < VSCSI_REPORT_LUNS_RETRY) {
-                                       retry_cnt++;
-                                       if (buff)
-                                               kfree(buff);
-                                       goto retry;
-                               }
-
                                goto fail;
                        }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.