From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f178.google.com (mail-dy1-f178.google.com [74.125.82.178]) (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 8350E43CECA for ; Wed, 10 Jun 2026 15:48:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781106519; cv=none; b=l0ekgeheH2RYWA9vbZHPcKY/t5IQd226ERKD93KirF0H722cVNRXuf9TZDGWlAemSCND+hM/EP5kOZjZFG8akDB8Yg+DOG/EoW4FZWYHsTONhVvHCTxnd+eVcArhMog2BuhdP6HiOWsIzndal6jq/VkY9onvreTUucUl4zeDQcE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781106519; c=relaxed/simple; bh=S3KAhpf4xujIbCA3wC4jg7ZR7gt0eH2uJ8Y7pXZd/vA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jm6X6mVCJktZU+G89CZ56AnQiIh6zCVULI1ixvhP5agBxCu6+vEsUePpzljfr1jbiiHjrzJozucL2tLCVVSGJH6aaIIVnJe8N0go4Ehx6/mpSUAqWM7Nhf32Y08NwVo57DpUKyoCIQ5qZkTrFGrkmmcvA0SxObjwOyEi+pmi4Dc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org; spf=pass smtp.mailfrom=wbinvd.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b=E9URqXDO; arc=none smtp.client-ip=74.125.82.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b="E9URqXDO" Received: by mail-dy1-f178.google.com with SMTP id 5a478bee46e88-30759632453so1130732eec.1 for ; Wed, 10 Jun 2026 08:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1781106516; x=1781711316; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FYvKr4nak3jtm5t4zlYpeWn3sAcIPq6YcBo6UMsGgP4=; b=E9URqXDOq3Svmd/5EV4VWPPXGnfFBZzyb7IqdoDxqQJ6JdNEm9D5AHmzemDRUCEbyd OPe5zpvxfLskCvtUsWmNpqVk52y8FRout8YMTdzi9lQmNOXbV4ohxey5J/PbI/+Pnc+I EkO674NRGySzTIcY0w05Bd7BdEx/qwhypQggeQ9AJ2/QcpCQfuaJ1U+oUQD6VZHvJeQ/ KAjaaBREA1tWhDA73CAk7uqZkSKUMN7NCR7KHadK6TDD5FlsC6ifLkJxMgjn+aZAQEs8 N6JzlcC/qi+8ogGS+N/8E5rWoK/cmBWdvmNdW26ijc7dvtkQ2cna1RPB18p0DqcFIisZ 9qiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781106516; x=1781711316; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FYvKr4nak3jtm5t4zlYpeWn3sAcIPq6YcBo6UMsGgP4=; b=U5crLdXtU/MSf47xpTHif7HIY/U9FaQ00BZi6SPPPx3tODi3P9ezzdXWYAYO/G9UDg HP1qymuLYluljS8+lAgvrNshtNma0YqO+/Y81udpddKRznm6KNSrOeJW47zXVB/nCxsk kasotoSKtaenYFnKNanizM3ByZ3vEJ8WJFU7edveJybDN8oYmUU2aVoSlXDJYDAGKVXu XQTxyGTEavKKnMhtdIIkdJndqAGwlk6wfhBRiMPFaJsRWXkGikcVmvJJo50qY2KVZGep hRY8zq+hZy1bxV0EJxom4ImNF2XMMu7Sw2V+B/5uvGjhrta93h2JI4rfuflswtTjbeSW Caqw== X-Gm-Message-State: AOJu0YwR47QRzFK/ydRD5yoCaHahNdtciROmLspDYTSTDjshlQLWloOs Mj6k/iPqzBAhvcxn+Gju3qP2O21LbJ8XY0ULA6PDPyGO/inLxaTjaf8IdbcQUJU93OI= X-Gm-Gg: Acq92OE+HtW8b8hDmbVhSsMAO3WsFRg+PBTHlaW8X2Hcnz3Du3gLrV1v1+qMq7YXzrw opHsoxZQzxMPslaheDQlu/5p4keFbK2I3KhTxvMuu9zDKH9mjEyYZUH6pLmeNYaGMeK5MJp4DBe hNDsgO0rItMma9cSfVCClufnBUuTYsnw9B5p48SSwcmp5Yok3SwEZfzhS6pQFyBMPm1kQBEFIfC wZEbY/iAXNYAsqK8+Kk0P0h/LvNKGsKlzWVzSqvKoRI4UKPtCRr3sxe8nXrwFxdGu8C3gkR7TXM HdpOUf9ReSrbHjbvve3reQDeqcWnZILh9um33XEVpAU24Fz6p1gq2R4LftCU6XlFzzWIH9vU3av vW1lZ4uYnQD2gKpZf7uOUGD3QnIKiWAgNwJmEUIFaJ/y+csD6YGqruUIZUg1Z/5lywt7WF1tRGR 32GLRz569jyNDJw+lcq+ixbxmCqO25eRzOqCY= X-Received: by 2002:a05:7300:3250:b0:2f5:5dd3:1fd8 with SMTP id 5a478bee46e88-3077aea9ef1mr17051622eec.8.1781106516402; Wed, 10 Jun 2026 08:48:36 -0700 (PDT) Received: from mozart.vkv.me ([2001:5a8:468b:d015:375a:a215:7d4e:6ae]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3074dea8708sm27747706eec.15.2026.06.10.08.48.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 08:48:36 -0700 (PDT) Date: Wed, 10 Jun 2026 08:48:33 -0700 From: Calvin Owens To: Rodolfo Giometti Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Andrew Morton Subject: Re: [PATCH] pps: Don't try to wait for negative timeouts in PPS_FETCH Message-ID: References: <20ed84f3-14d9-4936-b6d1-915ab605b7fa@enneenne.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Monday 06/01 at 09:04 +0200, Rodolfo Giometti wrote: > On 30/05/2026 16:54, Calvin Owens wrote: > > On Saturday 05/30 at 11:50 +0200, Rodolfo Giometti wrote: > > > On 29/05/2026 18:21, Calvin Owens wrote: > > > > If userspace passes a negative timeout to PPS_FETCH, it triggers a > > > > kernel splat from schedule_timeout(): > > > > > > > > schedule_timeout: wrong timeout value fffffffffff0bfb4 > > > > CPU: 17 UID: 0 PID: 4720 Comm: a.out Not tainted 7.1.0-rc5-x86-kvm-00150-g331d97e36b37 #1 PREEMPT_RT > > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-20240910_120124-localhost 04/01/2014 > > > > Call Trace: > > > > > > > > dump_stack_lvl+0x4b/0x70 > > > > schedule_timeout+0xb7/0xe0 > > > > pps_cdev_pps_fetch.isra.0+0x93/0x150 > > > > pps_cdev_ioctl+0x70/0x310 > > > > __x64_sys_ioctl+0x7b/0xc0 > > > > do_syscall_64+0xb6/0xfc0 > > > > entry_SYSCALL_64_after_hwframe+0x4b/0x53 > > > > > > > > Sashiko imagines this to be some sort of security problem, which is > > > > obviously really silly. But I think it is still worth fixing, so buggy > > > > userspace code can't trigger the splat. > > > > > > > > Silence the splat by skipping the wait if the ticks count is negative. > > > > The current behavior is to return -ETIMEDOUT in that case, so keep that > > > > return value in case any userspace code might rely on it. > > > > > > > > Fixes: eae9d2ba0cfc ("LinuxPPS: core support") > > > > Reported-by: Sashiko > > > > Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=3 > > > > Signed-off-by: Calvin Owens > > > > Hi Rodolfo, > > > > Thanks for taking a look at this and the others. > > > > > > --- > > > > drivers/pps/pps.c | 6 ++++-- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c > > > > index de1122bb69ea..6755901fbdae 100644 > > > > --- a/drivers/pps/pps.c > > > > +++ b/drivers/pps/pps.c > > > > @@ -65,17 +65,19 @@ static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata) > > > > if (fdata->timeout.flags & PPS_TIME_INVALID) > > > > err = wait_event_interruptible(pps->queue, > > > > ev != pps->last_ev); > > > > else { > > > > - unsigned long ticks; > > > > + long ticks; > > > > dev_dbg(&pps->dev, "timeout %lld.%09d\n", > > > > (long long) fdata->timeout.sec, > > > > fdata->timeout.nsec); > > > > ticks = fdata->timeout.sec * HZ; > > > > ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ); > > > > - if (ticks != 0) { > > > > + if (ticks < 0) { > > > > + return -ETIMEDOUT; > > > > + } else if (ticks > 0) { > > > > err = wait_event_interruptible_timeout( > > > > pps->queue, > > > > ev != pps->last_ev, > > > > ticks); > > > > > > Should the problem originate from user-space data, I deem it more > > > appropriate to verify them directly, rather than relying on computed data. > > > > > > unsigned long ticks; > > > > > > if (fdata->timeout.sec < 0 || fdata->timeout.nsec < 0) > > > return -ETIMEDOUT; > > > > I agree your way is nicer to read. > > We can also do as follow: > > /* Canonical validation of nanoseconds */ > if (fdata->timeout.nsec < 0 || fdata->timeout.nsec >= NSEC_PER_SEC) > return -EINVAL; > > /* Preserve historical API behavior for negative seconds */ > if (fdata->timeout.sec < 0) > return -ETIMEDOUT; Thinking about this a little more... code in the kernel generally doesn't try to enforce tv_nsec < NSEC_PER_SEC from userspace today. I think nobody cares: let's just not worry about tv_nsec unless you really think a real user will care. If it's worth fixing, it ought to be done more systematically throughout the kernel, I feel like adding the check in random places makes the situation more confusing overall. But again... I seriously doubt any real user cares. I'll look into the history around this a bit more, but I'm very disinclined to think it's worth the reviewer time to try and push it more broadly... This KC code also depends on CONFIG_HZ_PERIODIC, which no distro ships, so any user must necessarily be building their own kernel. > > Pedantically, it's a user visable behavior change: today, the user > > can pass absurd values for sec and nsec, and everything works so long as > > the math works out to positive ticks (e.g. sec=ULONG_MAX/HZ, > > nsec=2*HZ*NSEC_PER_SEC). > > > > If it was just that, it wouldn't really matter IMO, but... > > > > > dev_dbg(&pps->dev, "timeout %lld.%09d\n", > > > (long long) fdata->timeout.sec, > > > fdata->timeout.nsec); > > > > > > ticks = fdata->timeout.sec * HZ; > > > > ...the multiplication by HZ could also overflow even if sec is positive, > > so I think userspace would still be able to trigger the splat this way. > > > > > ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ); > > > > > > if (ticks > 0) { > > We can do as follow: > > /* Safe conversion using standard kernel API */ > ts.tv_sec = fdata->timeout.sec; > ts.tv_nsec = fdata->timeout.nsec; > ticks = timespec64_to_jiffies(&ts); Ah that helper is nicer, thanks. This plus the (tv_sec < 0) change should be sufficient, I'll send that along soon unless you reply that you want the tv_nsec check too. > if (ticks > 0) { > err = wait_event_interruptible_timeout( > pps->queue, > ev != pps->last_ev, > ticks); > } > > Ciao, > > Rodolfo > > -- > GNU/Linux Solutions e-mail: giometti@enneenne.com > Linux Device Driver giometti@linux.it > Embedded Systems phone: +39 349 2432127 > UNIX programming