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] [day] [month] [year] [list]
Date:	Fri, 27 Mar 2015 12:01:27 +0800
From:	"Chentao (Boby)" <boby.chen@...wei.com>
To:	Roger Pau Monné <roger.pau@...rix.com>,
	<konrad.wilk@...cle.com>
CC:	<xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>,
	<wu.wubin@...wei.com>, <rudy.zhangmin@...wei.com>
Subject: Re: [PATCH] xen-blkback: enlarge the array size of blkback name

You are right, roger. Thanks.

domid is a u16, it will occupy 5 characters at most. So the biggest 
length of blkback name is 8+5+5=18.

At this situation, define BLKBACK_NAME_LEN macro to be 20 is safe.

On 2015/3/26 19:23, Roger Pau Monné wrote:
> El 13/03/15 a les 16.52, Tao Chen ha escrit:
>> The blkback name is like blkback.domid.xvd[a-z], if domid has three digits
>> (means larger than 100), then the backmost xvd wouldn't be fully shown.
>>
>> Define a BLKBACK_NAME_LEN macro which is (TASK_COMM_LEN * 2), enlarge the
>> array size of blkback name, so it will be fully shown in any case.
>>
>> Signed-off-by: Tao Chen <boby.chen@...wei.com>
>> ---
>>   drivers/block/xen-blkback/xenbus.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
>> index e3afe97..0289e21 100644
>> --- a/drivers/block/xen-blkback/xenbus.c
>> +++ b/drivers/block/xen-blkback/xenbus.c
>> @@ -21,6 +21,9 @@
>>   #include <xen/grant_table.h>
>>   #include "common.h"
>>
>> +/* Enlarge the array size in order to fully show blkback name. */
>> +#define BLKBACK_NAME_LEN (TASK_COMM_LEN * 2)
>
> Any reason to use TASK_COMM_LEN instead of just coding it to 17? Or
> maybe 20 to be on the safe side?
>
> Roger.
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ