From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F48C322B92 for ; Tue, 23 Dec 2025 14:32:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766500321; cv=none; b=F/SUgnANgt61ok82VszEimqy0B1QmuoeXOnK3boKNZVDR6E7zm0tAGX4axf+tqgIuRBTTDEUwkhO8mKbBl3zhaJLMnELptSpNhlNatlvH6KtqnP/MzYxKQ5xlwkQb+dButymhwok1ww1OiNmF0EhKqXAgi1VQi40FKBDvDcunYs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766500321; c=relaxed/simple; bh=iCxNjgh2Jb2apyi67NCDapy5cpoy/aQmSir4jaW/WnE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YIcuA0AAGmcJkO+nVbaG+7gDAzZZYZrMPbDYKzp0jDGz1jwzNRDor0w4DhWrSXS8d6B3r4qEDje/B3ICcMKUZbrsL3t49m4psWkm5Y7rTMl6anL3EsBqRwFThjComE2qQpQOnJ6YDYy0L4kcNWN+qJ02I8XL3ttGsRgdQlDu3nI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kzalloc.com; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kzalloc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-34c6f6566a7so441825a91.3 for ; Tue, 23 Dec 2025 06:32:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766500319; x=1767105119; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ijJxP8v5AVEEgKb0/Y9mwcrJkwFTeayWUwFNsqY/b5Q=; b=TPYWHBx2k+F5iL3cKsY+3+1ymu9Uh4Q1e93A08JdoOZ+85cQgpMBJCcwhLtbNOXwPv AS1N8oM1aoetZTjpeSTmEw0Q/nv37/eQvXd67jsQuUR7WunSzT7mdPUe9G+wcC5+udYC U7eiCv1l6cwuCQZWfLGU9QQW4zA87QTixfraFSMWKfEppfgWbrJxjtejh0fh+ciNE8wd 4Bgq+uUsnkQCTDMwtP+k/+kA2fLlAh0HPAA8XHjLg9lPxXnGu+Qv78pEB8lk+ZaCAsWu jDZGi97Phs5R+xlxz/H3xHWpLYMlFeQRE0EGgM7MWtOFLRmjm8cCFHTQ9bpqJHNiYuIO Oxrg== X-Forwarded-Encrypted: i=1; AJvYcCXjHaeEPTjUJA1ZfoyypZjlJRXoyQP/e1+wISrxNHMcLRcj2dHkG1OAD0ZTZcRMCrfCbv62fc6DYqzh9ls=@vger.kernel.org X-Gm-Message-State: AOJu0YxyDT2kTeEC176y0zQQLtOtp07fyS64UFoKM/TAtoTqh+GEI3Uk rJUadVjfaX46frITxhtNQn1tk013B0ABVM+K69jdfLu5F0EN1CUfS/jy X-Gm-Gg: AY/fxX46OUxg7R+9FwS6t4ZeBR8gQch0q5DgD4yZIVq1DLWmSU6mIFntJPwhCTyWZ9N Ydzyoy0i2MM6+ajQA1qMExSBEQV1mFFRpXTiLT2oC1+b4U1Scx7lWgpxu5ya0U3eXY/KKvwECKx AI1D6533V/quvV23zA4WdqyXcPN/clQARbPQW5c0j8uo9rk3njxwx0DhyoqqfM4LnpPM2EAo5x3 S/Wzj7rq11zDUJ8mlm2IbH6qVr5Y24cutgBifKqNwEKLMDtyhVK1nTmw76dQCMua31rDYou2oBH K+gOuUO7RdShOZ2eKsiIZK8hxVFkVxGhEcut5m5PhYBmxcKF+ZeX+jvYzGhWwCReMaLHVu3G8cg bCfUXflbuhHnyWCQzr11QV4YNOEj7O9p55fiXUFROxi9GYzOeT1Y+DHwaSjZcXp9X/QdAAO8VkV EdP38dj8GX0nwmo/jfsytfkSgbReKCXioOpQl/HdsjFu8GYa2rncurNkKOo1Zd62/c2cLSBSpXu y4V2K6xaAFapXw= X-Google-Smtp-Source: AGHT+IF76wK9lhAOxM/G4Y8ZDMLkkU0FNMLgoYkfxF60ieay2Upp5vjmOPdV+zrwjsOwmn7mDb+sYw== X-Received: by 2002:a17:90b:3f86:b0:340:e8e4:1166 with SMTP id 98e67ed59e1d1-34e921c1ab2mr9629255a91.5.1766500319409; Tue, 23 Dec 2025 06:31:59 -0800 (PST) Received: from [192.168.50.136] ([118.32.98.101]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7af2b60bsm14069542b3a.15.2025.12.23.06.31.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Dec 2025 06:31:59 -0800 (PST) Message-ID: <92a7c013-0676-4c81-867f-b55c69a1edd6@kzalloc.com> Date: Tue, 23 Dec 2025 23:31:54 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Question] Detecting Sleep-in-Atomic Context in PREEMPT_RT via RV (Runtime Verification) monitor rtapp:sleep To: Gabriele Monaco , Nam Cao Cc: Sebastian Andrzej Siewior , rostedt@goodmis.org, Tomas Glozar , Shung-Hsi Yu , Byungchul Park , syzkaller@googlegroups.com, linux-rt-devel@lists.linux.dev, LKML , Dan Carpenter References: <32839fb6-dbcb-4c5c-9e3f-d46f27ae9a73@kzalloc.com> <87fraslu9c.fsf@yellow.woof> <87jyz5kuf2.fsf@yellow.woof> <20251202112644.YUux4LKd@linutronix.de> <53f17978-40e5-4b2e-b719-552612b0e775@kzalloc.com> <871pl1y3oh.fsf@yellow.woof> <0d06ce4c-6ff2-401a-90d9-5a4dfd2abebb@kzalloc.com> Content-Language: en-US From: Yunseong Kim Organization: kzalloc In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Gabriele, Thanks for the follow-up and for taking the time to double-check the configuration details. On 12/22/25 4:40 PM, Gabriele Monaco wrote: > On Thu, 2025-12-11 at 16:58 +0900, Yunseong Kim wrote: >> I am currently considering how to model this to cover cases that go >> beyond what CONFIG_DEBUG_ATOMIC_SLEEP covers. >> >> My specific concern is about custom functions where might_sleep() might >> be missing. In such cases, if the code hits a fast path (no scheduling), >> CONFIG_DEBUG_ATOMIC_SLEEP won't trigger. I'm wondering if RV can detect >> these potential bugs. > > Hi Yunseong, > > I finally got to reflect a bit more on this. > As we discussed at LPC, RV wouldn't help with not annotated functions because > you'd need to add tracepoints there, so probably the best is to just add a > might_sleep and be done with it. Thanks for your insight! I agree that for unannotated functions, adding might_sleep() directly is the most straightforward approach. I will also double-check sleepable memory allocations in the context of PREEMPT_RT kernels to see if there are other patterns being missed. > Other than that, I double checked and CONFIG_DEBUG_ATOMIC_SLEEP is in fact > disabled on non-debug kernels in Fedora/RHEL (and I presume also in Debian and > friends), so the other concern you raised is indeed valid. I agree that CONFIG_DEBUG_ATOMIC_SLEEP covers most cases, but as you pointed out, the fact that it's disabled in production kernels (Fedora, RHEL, Debian, Ubuntu etc.) gives this approach real-world value. I was hesitant about whether this was worth a contribution, so I truly appreciate your encouraging feedback. > Although perhaps rather unlikely, I'm not sure we can completely rule out cases > in which non-debug kernel (where several other debugging features besides > CONFIG_DEBUG_ATOMIC_SLEEP are disabled) behave differently enough for some bugs, > otherwise invisible on debug kernels, to pop up. > > Another use could be debugging kernel modules on non-debug kernels, perhaps to > avoid some other debug features to be present while still relying on the > packaged kernel. > > For this to work you'd need to add a tracepoint on might_sleep when > CONFIG_DEBUG_ATOMIC_SLEEP is disabled (and it's currently a NOP), hopefully that > wouldn't make people too angry. My interest in this arose because I've been seeing these legacy patterns consistently reported as bugs in the Real-Time (PREEMPT_RT) kernel. It seems many kernel developers are still unaware that these patterns are problematic, partly because some older Linux learning materials actually recommended them. This makes it quite likely that such code will continue to find its way into the upstream. > Again, none of this would be ground-breaking but it doesn't look useless either. > > Any thoughts? I will keep looking into more meaningful contributions for RV. For instance, I’ve been considering a monitor to detect excessive memory compaction issues under specific workloads, which I’ve encountered during kernel development. > Thanks, > Gabriele It was a great pleasure discussing these ideas with you and Nam. I sorry for any lack of clarity in my previous explanations during LPC 25. Thanks again for your insights! :) Best regards, Yunseong