From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52456)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1ZMAVA-00074m-Ai
	for qemu-devel@nongnu.org; Mon, 03 Aug 2015 03:49:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@kamp.de>) id 1ZMAV5-0007HK-Pc
	for qemu-devel@nongnu.org; Mon, 03 Aug 2015 03:49:40 -0400
Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:41535 helo=mx01.kamp.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1ZMAV5-0007Gt-EX
	for qemu-devel@nongnu.org; Mon, 03 Aug 2015 03:49:35 -0400
Message-ID: <55BF1D0A.8090006@kamp.de>
Date: Mon, 03 Aug 2015 09:49:30 +0200
From: Peter Lieven <pl@kamp.de>
MIME-Version: 1.0
References: <CABYiri9Zmm1aZzsOop7ZzwnZRufRjYYsDf-sA8xTbyoor0Ae_A@mail.gmail.com>
	<55BF0DFA.4000403@kamp.de>
	<CABYiri-sdjeJfFEGUg6xX-Wc+Z37H9u9e4LxgD4XEbVe3N5zUA@mail.gmail.com>
In-Reply-To: <CABYiri-sdjeJfFEGUg6xX-Wc+Z37H9u9e4LxgD4XEbVe3N5zUA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Forbid to pass lun 0 to iscsi driver
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andrey Korolyov <andrey@xdel.ru>
Cc: Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, ronnie sahlberg <ronniesahlberg@gmail.com>

Am 03.08.2015 um 09:47 schrieb Andrey Korolyov:
> On Mon, Aug 3, 2015 at 9:45 AM, Peter Lieven <pl@kamp.de> wrote:
>> Am 02.08.2015 um 13:42 schrieb Andrey Korolyov:
>>> Hello,
>>>
>>> As we will never pass LUN#0 as a storage lun, it would be better to
>>> prohibit this at least in iscsi.c, otherwise it will result in an FPU
>>> exception and emulator crash:
>>>
>>> traps: qemu-system-x86[32430] trap divide error ip:7f1dab7b5073
>>> sp:7f1d713e4ae0 error:0 in block-iscsi.so[7f1dab7b0000+8000]
>>>
>>>       353 static bool is_request_lun_aligned(int64_t sector_num, int
>>> nb_sectors,
>>>       354                                       IscsiLun *iscsilun)
>>>       355 {
>>>       356     if ((sector_num * BDRV_SECTOR_SIZE) % iscsilun->block_size ||
>>>       357         (nb_sectors * BDRV_SECTOR_SIZE) % iscsilun->block_size) {
>>>
>>> As far as I can see the LUN#0 can be thrown out on a top level, as one
>>> will never use it directly as an iSCSI backend. Please correct me if
>>> I`m wrong in this assumption.
>>
>> Hi Andrey,
>>
>> LUN 0 is quite common on iSCSI targets. I think what causes the problem
>> is not the LUN ID, but the target which returns 0 for the blocksize. Which
>> target are you using?
>>
>> Peter
> Hi Peter,
>
> I`ve mistyped lun for tgtd upon volume hotplug, which resulted in an
> accidental crash, there is nothing but human factor. Until only LUN0
> may possess such unusual properties, I`d vote to explicitly work it
> around instead of adding generic protection from volumes with
> advertized zero block size.

I will work out a patch that forbids to mount a LUN with zero blocksize.

Peter