public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Yury Norov <yury.norov@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Sven Schnelle <svens@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 3/5] lib/bitmap: add test for bitmap_{from,to}_arr64
Date: Sat, 25 Feb 2023 16:42:15 -0800	[thread overview]
Message-ID: <996a23fa-5ddf-4562-8675-5caeecc6368f@roeck-us.net> (raw)
In-Reply-To: <Y/qhL8kSzzhMm+tO@yury-laptop>

On 2/25/23 16:04, Yury Norov wrote:
> On Sat, Feb 25, 2023 at 10:47:02AM -0800, Guenter Roeck wrote:
>> Hi,
>>
>> On Thu, Apr 28, 2022 at 01:51:14PM -0700, Yury Norov wrote:
>>> Test newly added bitmap_{from,to}_arr64() functions similarly to
>>> already existing bitmap_{from,to}_arr32() tests.
>>>
>>> Signed-off-by: Yury Norov <yury.norov@gmail.com>
>>
>> Ever since this test is in the tree, several of my boot tests show
>> lots of messages such as
>>
>> test_bitmap: bitmap_to_arr64(nbits == 1): tail is not safely cleared: 0xa5a5a5a500000001 (must be 0x0000000000000001)
>> test_bitmap: bitmap_to_arr64(nbits == 2): tail is not safely cleared: 0xa5a5a5a500000001 (must be 0x0000000000000003)
>> test_bitmap: bitmap_to_arr64(nbits == 3): tail is not safely cleared: 0xa5a5a5a500000001 (must be 0x0000000000000007)
>> ...
>> test_bitmap: bitmap_to_arr64(nbits == 927): tail is not safely cleared: 0xa5a5a5a500000000 (must be 0x000000007fffffff)
>> test_bitmap: bitmap_to_arr64(nbits == 928): tail is not safely cleared: 0xa5a5a5a580000000 (must be 0x00000000ffffffff)
> 
> This may be a real problem. Can you share what's the system is? What's
> endianness and register length?
> 

https://kerneltests.org/builders/qemu-arm-v7-master/builds/532/steps/qemubuildcommand/logs/stdio
https://kerneltests.org/builders/qemu-arm-next/builds/2086/steps/qemubuildcommand/logs/stdio

are examples from different arm machines.

https://kerneltests.org/builders/qemu-xtensa-master/builds/2178/steps/qemubuildcommand/logs/stdio

is an example from xtensa.

https://kerneltests.org/builders/qemu-x86-master/builds/2248/steps/qemubuildcommand/logs/stdio

is an example from a 32-bit x86 test.

I am sure there are others; I only notice the messages if there is some other problem,
and came to believe that they must be noise because it happens across several
architectures and because it claimed at the end that all tests passed.

Just to confirm, I ran a test with big and little endian mips machines.
The problem is only seen with the little endian 32-bit machine. It is not
seen with the 32-bit big endian machine, and it is not seen with any of
the 64-bit machines (big and little endian).

Guenter

> + Alexander Lobakin, the author of the exact subtest.
>   
>> but then:
>>
>> test_bitmap: all 6550 tests passed
> 
> It's because corresponding error path doesn't increment failed_tests
> counter. I'll send a fix shortly.
> 
>>
>> The message suggests an error, given that it is displayed with pr_err,
>> but the summary suggests otherwise.
>>
>> Is the message just noise, or is there a problem ?
>>
>> Thanks,
>> Guenter
>>
>>> ---
>>>   lib/test_bitmap.c | 25 +++++++++++++++++++++++++
>>>   1 file changed, 25 insertions(+)
>>>
>>> diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
>>> index 0c82f07f74fc..d5923a640457 100644
>>> --- a/lib/test_bitmap.c
>>> +++ b/lib/test_bitmap.c
>>> @@ -585,6 +585,30 @@ static void __init test_bitmap_arr32(void)
>>>   	}
>>>   }
>>>   
>>> +static void __init test_bitmap_arr64(void)
>>> +{
>>> +	unsigned int nbits, next_bit;
>>> +	u64 arr[EXP1_IN_BITS / 64];
>>> +	DECLARE_BITMAP(bmap2, EXP1_IN_BITS);
>>> +
>>> +	memset(arr, 0xa5, sizeof(arr));
>>> +
>>> +	for (nbits = 0; nbits < EXP1_IN_BITS; ++nbits) {
>>> +		memset(bmap2, 0xff, sizeof(arr));
>>> +		bitmap_to_arr64(arr, exp1, nbits);
>>> +		bitmap_from_arr64(bmap2, arr, nbits);
>>> +		expect_eq_bitmap(bmap2, exp1, nbits);
>>> +
>>> +		next_bit = find_next_bit(bmap2, round_up(nbits, BITS_PER_LONG), nbits);
>>> +		if (next_bit < round_up(nbits, BITS_PER_LONG))
>>> +			pr_err("bitmap_copy_arr64(nbits == %d:"
>>> +				" tail is not safely cleared: %d\n", nbits, next_bit);
>>> +
>>> +		if (nbits < EXP1_IN_BITS - 64)
>>> +			expect_eq_uint(arr[DIV_ROUND_UP(nbits, 64)], 0xa5a5a5a5);
>>> +	}
>>> +}
>>> +
>>>   static void noinline __init test_mem_optimisations(void)
>>>   {
>>>   	DECLARE_BITMAP(bmap1, 1024);
>>> @@ -852,6 +876,7 @@ static void __init selftest(void)
>>>   	test_copy();
>>>   	test_replace();
>>>   	test_bitmap_arr32();
>>> +	test_bitmap_arr64();
>>>   	test_bitmap_parse();
>>>   	test_bitmap_parselist();
>>>   	test_bitmap_printlist();
>>> -- 
>>> 2.32.0
>>>


  parent reply	other threads:[~2023-02-26  0:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 20:51 [PATCH v2 0/5] bitmap: fix conversion from/to fix-sized arrays Yury Norov
2022-04-28 20:51 ` [PATCH 1/5] lib/bitmap: extend comment for bitmap_(from,to)_arr32() Yury Norov
2022-04-28 20:51 ` [PATCH 2/5] lib: add bitmap_{from,to}_arr64 Yury Norov
2022-04-29 12:59   ` Andy Shevchenko
2022-04-29 15:45     ` Yury Norov
2022-05-02 20:06       ` Yury Norov
2022-05-03  9:56         ` Andy Shevchenko
2022-04-28 20:51 ` [PATCH 3/5] lib/bitmap: add test for bitmap_{from,to}_arr64 Yury Norov
2022-05-19 15:09   ` Guenter Roeck
2022-05-19 16:01     ` Yury Norov
2022-05-19 18:04       ` Guenter Roeck
2022-05-20 16:18         ` Yury Norov
2022-05-21  7:38     ` Yury Norov
2023-02-25 18:47   ` Guenter Roeck
2023-02-26  0:04     ` Yury Norov
2023-02-26  0:06       ` Yury Norov
2023-02-27 14:46         ` Alexander Lobakin
2023-02-27 14:59           ` Guenter Roeck
2023-02-27 19:24             ` Yury Norov
2023-02-27 20:12               ` Guenter Roeck
2023-02-27 20:23                 ` Yury Norov
2023-02-26  0:42       ` Guenter Roeck [this message]
2022-04-28 20:51 ` [PATCH 4/5] KVM: s390: replace bitmap_copy with bitmap_{from,to}_arr64 where appropriate Yury Norov
2022-04-28 20:51 ` [PATCH 5/5] drm/amd/pm: use bitmap_{from,to}_arr32 " Yury Norov

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=996a23fa-5ddf-4562-8675-5caeecc6368f@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=agordeev@linux.ibm.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=svens@linux.ibm.com \
    --cc=yury.norov@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox