On Thu, Aug 29 2024 at 16:25, Gianfranco Trad wrote:
Please add a proper subsystem prefix to the subject.
On Mon, Aug 26 2024 at 12:45, Christophe Leroy wrote:
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
>> On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe
On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>> But tglx pointed out in that thread that this actually isn't necessary:
>>
>> | All of this is pointless because if a 32-bit application runs on a
>> | 64-bit kernel it has to use the 64-
On Wed, Jul 31 2024 at 22:42, Thomas Gleixner wrote:
> Aside of that the proposed parser does not even work anymore on 6.11
> because we switched ARM[64] over to per device domains during the merge
> window.
>
> So if we want a selftest for the correctness of the hardware interrupt
On Wed, Jul 31 2024 at 14:24, Bjorn Helgaas wrote:
> On Wed, May 29, 2024 at 06:27:27PM -0700, Joseph Jang wrote:
>> Validate there are no duplicate ITS-MSI hwirqs from the
>> /sys/kernel/irq/*/hwirq.
>>
>> One example log show 2 duplicated MSI entries in the /proc/interrupts.
>>
>> 150: 0 ... IT
On Wed, Apr 17 2024 at 08:37, Nathan Chancellor wrote:
> into the more idiomatic
>
> if (ret)
> ksft_exit_fail();
> ksft_exit_pass();
>
> as well as a few style clean ups now that the code is shorter.
Reviewed-by: Thomas Gleixner
On Thu, Apr 11 2024 at 11:45, Nathan Chancellor wrote:
> I have based this change on timers/urgent, as the commit that introduces
> this particular warning is there and it is marked for stable, even
> though this appears to be a generic kselftest issue. I think it makes
> the most sense for this ch
Shuah!
On Thu, Apr 11 2024 at 15:01, Shuah Khan wrote:
>
> Applied to linux-kselftest next for Linux6.10-rc1.
I took this already through my tree as I have more timer selftest
related stuff pending and coming up soon along with actual kernel
changes.
Thanks,
tglx
On Thu, Apr 11 2024 at 13:44, Mark Brown wrote:
> On Sat, Apr 06, 2024 at 05:09:51PM +0200, Oleg Nesterov wrote:
>> Thomas says:
>>
>> The signal distribution test has a tendency to hang for a long
>> time as the signal delivery is not really evenly distributed. In
>> fact it might
On Wed, Apr 10 2024 at 15:21, John Stultz wrote:
> On Tue, Apr 9, 2024 at 6:39 AM Oleg Nesterov wrote:
> This is working great here (on both 6.6 and the older 6.1)! Thanks so
> much for fixing this!
> One nit below, but otherwise:
> Tested-by: John Stultz
>
>> +err:
>> + ksft_print_msg(er
On Tue, Apr 09 2024 at 13:10, Oleg Nesterov wrote:
> On 04/09, Thomas Gleixner wrote:
> It seems that this is because in your tree check_timer_distribution() does
>
> if (timer_delete(id)) {
> ksft_perror("Can't delete timer");
>
On Mon, Apr 08 2024 at 20:49, Oleg Nesterov wrote:
> To me this test should simply do
>
> ksft_test_result(!ctd_failed, "check signal distribution\n");
> return 0;
Right.
> but I am not familiar with tools/testing/selftests/ and I am not sure
> I understand the last email from Thomas.
On Mon, Apr 08 2024 at 10:30, Dmitry Vyukov wrote:
> On Sat, 6 Apr 2024 at 17:12, Oleg Nesterov wrote:
>> if (ctd_failed)
>> ksft_test_result_skip("No signal distribution. Assuming old
>> kernel\n");
>
> Shouldn't the test fail here? The goal of a test is to fail when
> th
On Sat, Apr 06 2024 at 17:10, Oleg Nesterov wrote:
> Yes, this changes the "semantics" of check_timer_distribution(), perhaps it
> should be renamed.
Definitely.
> But I do not see a better approach, and in fact I think that
>
> Test that all running threads _eventually_ receive
> CLOCK_PR
On Thu, Apr 04 2024 at 16:54, Oleg Nesterov wrote:
> On 04/04, Thomas Gleixner wrote:
>>
>> IOW, we cannot test this reliably at all with the current approach.
>
> Agreed!
>
> So how about a REALLY SIMPLE test-case below?
>
> Lacks error checking, should
On Thu, Apr 04 2024 at 15:43, Oleg Nesterov wrote:
> On 04/04, Dmitry Vyukov wrote:
>> they all should get a signal eventually.
>
> Well, yes and no.
>
> No, in a sense that the motivation was not to ensure that all threads
> get a signal, the motivation was to ensure that cpu_timer_fire() paths
>
On Wed, Apr 03 2024 at 12:35, John Stultz wrote:
> On Wed, Apr 3, 2024 at 12:10 PM Thomas Gleixner wrote:
>>
>> On Wed, Apr 03 2024 at 11:16, John Stultz wrote:
>> > On Wed, Apr 3, 2024 at 9:32 AM Thomas Gleixner wrote:
>> > Thanks for this, Thomas!
>> >
On Wed, Apr 03 2024 at 11:16, John Stultz wrote:
> On Wed, Apr 3, 2024 at 9:32 AM Thomas Gleixner wrote:
> Thanks for this, Thomas!
>
> Just FYI: testing with 6.1, the test no longer hangs, but I don't see
> the SKIP behavior. It just fails:
> not ok 6 check signal distribu
On Wed, Apr 03 2024 at 17:43, Thomas Gleixner wrote:
> On Wed, Apr 03 2024 at 17:03, Oleg Nesterov wrote:
>>
>> Why distribution_thread() can't simply exit if got_signal != 0 ?
>>
>> See https://lore.kernel.org/all/20230128195641.ga14...@redhat.com/
>
> Indeed
On Wed, Apr 03 2024 at 17:03, Oleg Nesterov wrote:
> On 04/03, Thomas Gleixner wrote:
>> The test if fragile as hell as there is absolutely no guarantee that the
>> signal target distribution is as expected. The expectation is based on a
>> statistical assumption which
On Tue, Apr 02 2024 at 10:23, John Stultz wrote:
> On Tue, Apr 2, 2024 at 7:57 AM Thomas Gleixner wrote:
>> This test in particular exercises new functionality/behaviour, which
>> really has no business to be backported into stable just to make the
>> relevant test us
On Mon, Apr 01 2024 at 13:17, John Stultz wrote:
> Apologies for drudging up this old thread.
> I wanted to ask if anyone had objections to including this in the -stable
> trees?
>
> After this and the follow-on patch e797203fb3ba
> ("selftests/timers/posix_timers: Test delivery of signals across
On Thu, Mar 07 2024 at 13:34, Edward Liaw wrote:
>> Thanks for picking those up and moving them forward. Any particular
>> reason why you didn't pick up the full set?
>
> I didn't know enough about the code to resolve some of the merges in the
> full set. I had run into the issue with the test tim
On Mon, Mar 04 2024 at 18:11, Edward Liaw wrote:
> I'm sending some patches that were orignally in
> https://lore.kernel.org/lkml/20230606132949.068951...@linutronix.de/
> to prevent the timer_distribution test from hanging and also fix some
> format inconsistencies.
Thanks for picking those up an
ms can follow the results of the
> individual cases that get run.
>
> Signed-off-by: Mark Brown
Acked-by: Thomas Gleixner
"selftests: timers: clocksource-switch: adapt to
> kselftest framework")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Thomas Gleixner
>
> There are more tests that don't use KTAP, several of them just run a
> single test so don't really benefit from KTAP and there were a couple
> where the conversion was a bit more complex so I've left them for now.
Acked-by: Thomas Gleixner
27 matches
Mail list logo
