linux-kernel - Re: [GIT PULL] orphaned patches for 6.11

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <28a0f793-b0d6-4abb-b83c-f54e5a588994@I-love.SAKURA.ne.jp>
Date: Thu, 25 Jul 2024 20:06:54 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] orphaned patches for 6.11

On 2024/07/25 14:11, Linus Torvalds wrote:
> So no. This is not happening, and you just showed exactly why nobody
> wants to take your patch set. Because you make things more complicated
> than they need to be for no reason.

I'm sending you as a patch set. But that is a result of nobody taking care
on individual patch (even fine-and-simple the other patch). People fixing
unpopular bugs are having difficulty with finding maintainers or getting
responses from maintainers (regardless of whether individual patch is
complicated). For example,
https://lkml.kernel.org/r/20230423012744.24320-1-chenzhongjin@huawei.com was
a result of several comments but still not accepted. I appreciate if you can
help such people with persuading appropriate maintainers to review/accept.

> And yes, apparently we should just also move the 'prof_buffer' test
> earlier, and do it in profile_tick() too, so that we don't need to
> even worry about the cpumask_available thing.

Do you mean

 void profile_tick(int type)
 {
 	struct pt_regs *regs = get_irq_regs();

-	if (!user_mode(regs) && cpumask_available(prof_cpu_mask) &&
+	if (!user_mode(regs) && prof_buffer &&
 	    cpumask_test_cpu(smp_processor_id(), prof_cpu_mask))
 		profile_hit(type, (void *)profile_pc(regs));
 }

because prof_cpu_mask != NULL is guaranteed if prof_buffer != NULL
because prof_cpu_mask is assigned before prof_buffer is assigned and
prof_buffer is never reassigned? That resembles
https://lkml.kernel.org/r/20230410022226.181812-3-chenzhongjin@huawei.com
but Chen Zhongjin did not remove the cpumask_available() test.

Can that change survive memory fetch reordering like

	if (!user_mode(regs) &&
 	    cpumask_test_cpu(smp_processor_id(), prof_cpu_mask) &&
	    prof_buffer)
 		profile_hit(type, (void *)profile_pc(regs));

if cpumask_available() test is removed? We after all cannot forget about
the cpumask_available thing?

If we can forget about the cpumask_available thing, can we tolerate discarding
CONFIG_CPUMASK_OFFSTACK=n optimization because we can't remove duplicated
prof_buffer != NULL test in profile_hits() because do_profile_hits() assumes
that prof_buffer != NULL?

Conditions/preferences are too much complicated...