[Devel] [PATCH vz10 07/24] blk-cbt: don't WARN on a user-supplied ABI version mismatch

[Devel] [PATCH vz10 07/24] blk-cbt: don't WARN on a user-supplied ABI version mismatch

[Konstantin Khorenko]

On 7/6/26 14:11, Andrey Zhadchenko wrote:
> I don't like that. Customers do not run with panic_on_warn. If this 
> fails in our test environment, that's actually great (it means something 
> went very wrong). pr_warn_ratelimited is worse than WARN_ONCE regarding 
> intentional spamming.

i agree, i will drop this patch.
It could definitely be useful in case there was WARN() - to change it to WARN_ONCE()
because this is triggerable from inside a Container, i have just checked that.

But as this is just a single WARN_ONCE, it's not a problem.

On the other hand mainstream fights with such user triggerable WARN_ONCE messages as well, like

commit 251a8fe1b9aedccd298b77bc28426d564c5a923f
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Thu Jun 25 08:34:46 2026 +0900

    tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg

    Sashiko found that user can cause this WARN_ON_ONCE() easily
    with adding a kprobe event based on a raw address with BTF
    parameter.

    Since this is not an unexpected condition, remove the
    WARN_ON_ONCE().

    Link: https://lore.kernel.org/all/178177265367.2059927.13789953014706792126.stgit at mhiramat.tok.corp.google.com/

    Link: https://sashiko.dev/#/patchset/178165816303.269421.7302603996990753309.stgit%40devnote2

    Reported-by: Sashiko <sashiko-bot@kernel.org>
    Fixes: b576e09701c7 ("tracing/probes: Support function parameters if BTF is available")
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index fd1caa1f97233..98532c503d028 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -678,7 +678,7 @@ static int parse_btf_arg(char *varname,
        int i, is_ptr, ret;
        u32 tid;

-       if (WARN_ON_ONCE(!ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT)))
+       if (!ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT))
                return -EINVAL;

        is_ptr = split_next_field(varname, &field, ctx);

commit 40c88c429a598006f91ad7a2b89856cd50b3a008
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Tue May 16 11:04:09 2023 -0700

    bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log

    [ Upstream commit cff36398bd4c7d322d424433db437f3c3391c491 ]

    It's trivial for user to trigger "verifier log line truncated" warning,
    as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at
    least two pieces of user-provided information that can be output through
    this buffer, and both can be arbitrarily sized by user:
      - BTF names;
      - BTF.ext source code lines strings.

    Verifier log buffer should be properly sized for typical verifier state
    output. But it's sort-of expected that this buffer won't be long enough
    in some circumstances. So let's drop the check. In any case code will
    work correctly, at worst truncating a part of a single line output.

    Reported-by: syzbot+8b2a08dfbd25fd933d75 at syzkaller.appspotmail.com
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20230516180409.3549088-1-andrii at kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c
index 920061e38d2e1..cd1b7113fbfd0 100644
--- a/kernel/bpf/log.c
+++ b/kernel/bpf/log.c
@@ -22,9 +22,6 @@ void bpf_verifier_vlog(struct bpf_verifier_log *log, const char *fmt,

        n = vscnprintf(log->kbuf, BPF_VERIFIER_TMP_LOG_SIZE, fmt, args);

-       WARN_ONCE(n >= BPF_VERIFIER_TMP_LOG_SIZE - 1,
-                 "verifier log line truncated - local buffer too short\n");
-
        if (log->level == BPF_LOG_KERNEL) {
                bool newline = n > 0 && log->kbuf[n - 1] == '\n';


> On 7/6/26 12:59, Konstantin Khorenko wrote:
>> blk_cbt_ioctl() reads abi_version straight from the ioctl argument and
>> WARN_ONCE()s if it does not match CBT_ABI_VERSION. The value is fully
>> userspace-controlled, so any process issuing a BLKCBT* ioctl with a
>> stale/newer struct taints the kernel, dumps a backtrace, and can panic a
>> host that runs with panic_on_warn. Downgrade to pr_warn_ratelimited();
>> the -EOPNOTSUPP return is the actual contract.
>>
>> Fixes: 6e42f62a2c88 ("block/blk-cbt: introduce ABI versioning")
>> Feature: cbt: changed block tracking (for backup)
>> https://virtuozzo.atlassian.net/browse/VSTOR-137234
>> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
>> ---
>>   block/blk-cbt.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/blk-cbt.c b/block/blk-cbt.c
>> index 90219f58f1ae..91a888770411 100644
>> --- a/block/blk-cbt.c
>> +++ b/block/blk-cbt.c
>> @@ -1093,8 +1093,8 @@ int blk_cbt_ioctl(struct block_device *bdev, unsigned cmd, char __user *arg)
>>   		return -EFAULT;
>>   
>>   	if (abi_version != CBT_ABI_VERSION) {
>> -		WARN_ONCE(1, "blk-cbt ABI mimatch: kernel has %d, userspace uses %d",
>> -			  CBT_ABI_VERSION, abi_version);
>> +		pr_warn_ratelimited("blk-cbt: ABI mismatch: kernel has %d, userspace uses %d\n",
>> +				    CBT_ABI_VERSION, abi_version);
>>   		return -EOPNOTSUPP;
>>   	}
>>   
> 

Re: [Devel] [PATCH vz10 12/24] oracle/mm: enter COW seqcount/mmu-notifier section in copy_page_range_mt()

[Konstantin Khorenko]

i'm dropping this patch.
The bug is fixed by another patch, taken from Oracle UEK8 kernel:

[PATCH hci-8.1 1/8] oracle/mm: fix VM_BUG_ON hit when preserving memory

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 7/24/26 15:09, Pavel Tikhomirov wrote:
> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
> 
> This is really non-obvious, the logic behind "mirroring" is sound, also
> we should report this to oracle, I don't see full miroring there, they have
> raw_write_seqcount_begin(), but not mmu_notifier_...
> 
> On 7/6/26 12:59, Konstantin Khorenko wrote:
>> copy_page_range_mt() is the padata-multithreaded copy used by vma_dup()
>> to preserve a VM_EXEC_KEEP (MADV_DOEXEC) VMA across exec. A MADV_DOEXEC
>> VMA is private anon, so is_cow_mapping() is true and the copy write
>> protects the source PTEs - a permission downgrade. Unlike the normal
>> fork path copy_page_range(), this helper jumped straight into
>> padata_do_multithreaded() without the COW prologue/epilogue, so it:
>>
>>   - never entered src_mm->write_protect_seq (left it even), which trips
>>     the DEBUG_VM invariant in folio_needs_cow_for_dma() reached from
>>     folio_try_dup_anon_rmap_pte() during the copy:
>>
>>       kernel BUG at include/linux/mm.h:2054!
>>       copy_present_ptes <- copy_pte_range <- copy_page_range_chunk
>>         <- padata_do_multithreaded <- copy_page_range_mt <- vma_dup
>>         <- exec_mmap <- begin_new_exec <- load_elf_binary
>>
>>   - never called mmu_notifier_invalidate_range_start/end(), a real latent
>>     bug: a secondary MMU (KVM, IOMMU SVA, GPU) registered on the old mm
>>     outlives de_thread() and could keep writable mappings of pages whose
>>     PTEs the exec copy just wrprotected and shared into the new mm.
>>
>> Mirror copy_page_range(): for a COW mapping, invalidate secondary MMUs
>> and take the write_protect_seq write side around the padata job. The
>> exec'ing task is single-threaded by now and is the only user of src_mm,
>> so there is no concurrent seqcount writer (fork needs mmap_write_lock)
>> or GUP-fast reader; taking the raw write side while holding only
>> mmap_read_lock is safe, which is why vma_assert_write_locked() from
>> copy_page_range() is intentionally not carried over here.
>>
>> Fixes: 11e4b1dc50e3 ("oracle/mm: use padata for copying page ranges in vma_dup()")
>> Feature: oracle/mm: MADV_DOEXEC madvise() flag
>> https://virtuozzo.atlassian.net/browse/VSTOR-137234
>> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
>> ---
>>  mm/memory.c | 35 ++++++++++++++++++++++++++++++++++-
>>  1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 837194e87664..4d04591f8f40 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -1478,6 +1478,10 @@ static int copy_page_range_chunk(unsigned long addr,
>>  int copy_page_range_mt(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma)
>>  {
>>  	struct copy_page_range_args args = { dst_vma, src_vma };
>> +	struct mm_struct *src_mm = src_vma->vm_mm;
>> +	struct mmu_notifier_range range;
>> +	bool is_cow;
>> +	int ret;
>>  	struct padata_mt_job job = {
>>  		.thread_fn   = copy_page_range_chunk,
>>  		.fn_arg      = &args,
>> @@ -1490,7 +1494,36 @@ int copy_page_range_mt(struct vm_area_struct *dst_vma, struct vm_area_struct *sr
>>  
>>  	BUG_ON(!(src_vma->vm_flags & VM_EXEC_KEEP));
>>  
>> -	return padata_do_multithreaded(&job);
>> +	/*
>> +	 * Mirror copy_page_range(): for a COW mapping the copy write
>> +	 * protects the source PTEs, which is a permission downgrade, so
>> +	 * secondary MMUs must be invalidated, and write_protect_seq must be
>> +	 * entered (odd) so GUP-fast cannot race with the wrprotect
>> +	 * (folio_needs_cow_for_dma() asserts this under CONFIG_DEBUG_VM).
>> +	 *
>> +	 * The exec'ing task is single-threaded by now and the only user of
>> +	 * src_mm, so no concurrent write_protect_seq writer (fork, which
>> +	 * needs mmap_write_lock) or GUP-fast reader can exist; taking the
>> +	 * raw write side while holding only mmap_read_lock is safe here, and
>> +	 * the padata helper threads only read the seqcount.
>> +	 */
>> +	is_cow = is_cow_mapping(src_vma->vm_flags);
>> +	if (is_cow) {
>> +		mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_PAGE,
>> +					0, src_mm, src_vma->vm_start,
>> +					src_vma->vm_end);
>> +		mmu_notifier_invalidate_range_start(&range);
>> +		raw_write_seqcount_begin(&src_mm->write_protect_seq);
>> +	}
>> +
>> +	ret = padata_do_multithreaded(&job);
>> +
>> +	if (is_cow) {
>> +		raw_write_seqcount_end(&src_mm->write_protect_seq);
>> +		mmu_notifier_invalidate_range_end(&range);
>> +	}
>> +
>> +	return ret;
>>  }
>>  #endif /* CONFIG_PADATA */
>>  
> 

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel