All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jürgen Groß" <jgross@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH][linux 2.6.18] remove pointless error handling in scsiback
Date: Tue, 01 Jul 2014 20:51:59 +0200	[thread overview]
Message-ID: <53B3034F.6030707@suse.com> (raw)
In-Reply-To: <53B2F256020000780001F20D@mail.emea.novell.com>

On 07/01/2014 05:39 PM, Jan Beulich wrote:
>>>> On 01.07.14 at 17:27, <"jgross@suse.com".non-mime.internet> wrote:
>> From: Juergen Gross <jgross@suse.com>
>>
>> It makes no sense to try repeating traversing the lun list in case of a
>> possible mismatch between the original counting of luns and the real
>> processing.
>
> Perhaps the retry logic isn't correct, but with the lock being dropped
> between the two loops I'm not sure the retry makes no sense. Can
> you explain?

In theory the number of LUNs could have just changed between
counting them and evaluating them. The counting isn't redone,
so what's the point of retrying? What are the chances a matching
LUN will appear and disappear in just the correct timing?

You could argue the counting should be included in the retry loop.
But then doing a limited number of retries is only decreasing the
chance of a problem, not eliminating it.

The real fix would be to process the LUNs in the first run without
using an intermediate buffer by filling the domU's buffer directly.
This would avoid all race conditions.


Juergen

>
> Jan
>
>> To make things worse, the retry itself was wrong as the number of detected
>> luns was not resetted for the retry leading to the next failing retry at
>> once.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>>
>> 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	Tue Jul 01 17:19:27 2014 +0200
>> @@ -228,7 +228,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 +244,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 +260,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@lists.xen.org
> http://lists.xen.org/xen-devel
>

  reply	other threads:[~2014-07-01 18:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 15:27 [PATCH][linux 2.6.18] remove pointless error handling in scsiback jgross
2014-07-01 15:39 ` Jan Beulich
2014-07-01 18:51   ` Jürgen Groß [this message]
2014-07-02  6:52     ` Jan Beulich
2014-07-02  7:08       ` Juergen Gross
  -- strict thread matches above, loose matches on Subject: below --
2014-07-02  7:26 jgross
2014-07-02 11:57 ` Jan Beulich
2014-07-02 12:13   ` Jürgen Groß
2014-07-02 12:27     ` Jan Beulich
2014-07-02 12:33       ` Jan Beulich
2014-07-02 12:38         ` Jürgen Groß

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B3034F.6030707@suse.com \
    --to=jgross@suse.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.