linux-kernel - Re: [PATCH 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Feb 2016 10:55:28 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
	xen-devel@...ts.xen.org, konrad.wilk@...cle.com,
	david.vrabel@...rix.com
Cc:	stable@...r.kernel.org
Subject: Re: [PATCH 2/2] xen/scsiback: avoid warnings when adding multiple
 LUNs to a domain



On 02/05/2016 10:50 AM, Boris Ostrovsky wrote:
>
>
>> @@ -962,33 +973,31 @@ static int 
>> scsiback_del_translation_entry(struct vscsibk_info *info,
>>                         struct ids_tuple *v)
>>   {
>>       struct v2p_entry *entry;
>> -    struct list_head *head = &(info->v2p_entry_lists);
>>       unsigned long flags;
>>         spin_lock_irqsave(&info->v2p_lock, flags);
>>       /* Find out the translation entry specified */
>> -    list_for_each_entry(entry, head, l) {
>> -        if ((entry->v.chn == v->chn) &&
>> -            (entry->v.tgt == v->tgt) &&
>> -            (entry->v.lun == v->lun)) {
>> -            goto found;
>> -        }
>> -    }
>> -
>> -    spin_unlock_irqrestore(&info->v2p_lock, flags);
>> -    return 1;
>> -
>> -found:
>> -    /* Delete the translation entry specfied */
>> -    __scsiback_del_translation_entry(entry);
>> +    entry = scsiback_chk_translation_entry(info, v);
>> +    if (entry)
>> +        __scsiback_del_translation_entry(entry);
>>         spin_unlock_irqrestore(&info->v2p_lock, flags);
>> -    return 0;
>> +    return entry == NULL;
>
> Might be better to return -ENOENT instead of 1 above and -EEXISTS if 
> entry!=NULL, given that this returns an int.

Nevermind reference to 1, it's removed. But returning an error code 
instead of a bool is still better I think.

-boris