Hi,
>On 08/02/2018 03:31 AM, Maninder Singh wrote:
>> FILE_SZ is defined as (1UL << 35), it will overflow
>> for 32 bit system and logic will break.
>>
>> Signed-off-by: Maninder Singh <maninder1.s@xxxxxxxxxxx>
>> Signed-off-by: Vaneet Narang <v.narang@xxxxxxxxxxx>
>> ---
>> tools/testing/selftests/net/tcp_mmap.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/testing/selftests/net/tcp_mmap.c b/tools/testing/selftests/net/tcp_mmap.c
>> index e8c5dff..1d6ca12 100644
>> --- a/tools/testing/selftests/net/tcp_mmap.c
>> +++ b/tools/testing/selftests/net/tcp_mmap.c
>> @@ -85,7 +85,7 @@
>> #define MSG_ZEROCOPY 0x4000000
>> #endif
>>
>> -#define FILE_SZ (1UL << 35)
>> +#define FILE_SZ (1ULL << 35)
...
...
>> @@ -431,7 +431,7 @@ int main(int argc, char *argv[])
>> zflg = 0;
>> }
>> while (total < FILE_SZ) {
>> - long wr = FILE_SZ - total;
>> + unsigned long long wr = FILE_SZ - total;
>>
>> if (wr > chunk_size)
>> wr = chunk_size;
>>
>
>What about using more conventional size_t instead of "unsigned long long" ?
size_t is also equivalent to unsigned long and it will not hold value of (1 << 35) for 32 bit system.
So we can do two things.
(1) reduce FILE SIZE to (1 << 30), so that UL (size_t) can hold this value.
It will not show any perofrmance boost with ZEROCOPY. (checked on x86_64)
(2) use unsigned long long to work with both 32 and 64 bit system.
It will show performance boost with ZEROCOPY.(checked on x86_64)
What do you think?
Thanks and regards,
Maninder Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
