From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpcmd13146.aruba.it (smtpcmd13146.aruba.it [62.149.156.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC59A1B4257 for ; Sun, 14 Jun 2026 08:53:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.149.156.146 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781427197; cv=none; b=L9l0fW9sw7CvChhuhR6lBMJcsacgykJxz2CgQUH4yv2Qr1OeNykh9laIOzOTE2EVFeji5TsD6ztxiVbjNir7KQvN1gHzqYW8Q9Z0D1uINqs8mdqzxm99RSE8SeG9k9JOweT+hAhFD5HfqXAZk1anFUj/ROdY1J1LOiLJ7gJc5gA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781427197; c=relaxed/simple; bh=P3fnjj2KwTKjwfrQmvVxl7ks501P+ByIjLI4HYUw9dw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ax9YWH4kzW6DOopCxlIFw873UVFUjiMHfD6t4ruY8XlQAC4/uWmlWZx9G6z5q9KCSO9UTr1gp+CDwg2O3s3KJLPZRdeeYiyF5trycp2ZmKoR7hiOloxnoR1s6leKFeyW4SaEWQJlF5cbemgHB/lsqZNIt4UyqGU0UjatogR+mVQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com; spf=pass smtp.mailfrom=enneenne.com; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b=KCQz+ebW; arc=none smtp.client-ip=62.149.156.146 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=enneenne.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b="KCQz+ebW" Received: from [192.168.0.186] ([101.57.122.26]) by Aruba SMTP with ESMTPSA id YgaWwtwmLRHshYgaWw62eS; Sun, 14 Jun 2026 10:53:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1781427184; bh=P3fnjj2KwTKjwfrQmvVxl7ks501P+ByIjLI4HYUw9dw=; h=Date:MIME-Version:Subject:To:From:Content-Type; b=KCQz+ebW+MeWUVsweeXACPN2xTUXg3PRIm1nKgUWCzi0r2F+CBc3uoTd7Riy0KlgE 59aTAX2sckNHTKQcU77/PZRNRg1cKm2cTYelrRfNn07Gkv0HZQ0d3H1EnKdzpfAJFO CeLC9GgcUlk2r+g31HiFSP5ehmD3eSEDJ9pNlU5CMn9/JDBV87+NtQqZfUq+CRc3Ra EP3fcJ/1sQNyGu4E7qrnxsRlTnQGgs8l1GiuzxielSrrKVB0Eg7w0kyPieGoqvhVYp fioiGd5f3KiZSzhkQ9+mz3BNNP5rOgUVzvSXjlnKwqmisnRKoEDr2Qs1Eb97gpwJla EG/DtutN4GpYw== Message-ID: <47a6c9ef-d657-4b5a-8e8e-ff6349259797@enneenne.com> Date: Sun, 14 Jun 2026 10:53:03 +0200 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: [PATCH v2] pps: Don't try to wait for negative timeouts in PPS_FETCH Content-Language: en-US To: Calvin Owens , linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman References: From: Rodolfo Giometti In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfLiThwp8Ao0ndrdEoG5c6mtM+WGZoDExGbjSzHM0OpXBrL1Fdkve4OOP7HNtbIaTyyXpHch7X8AMbTGh067UC5ALUGVHeDv3LbkDQRuYnwyzbVnLbYiz t99nGIupXbMR1Rp8JFirc7seDZubjyIeSAaOFMU/wWF7yzyrpy39c0/6OSXKsWza9oCQn9p2J3WbpUg+g0IeEqLB1oYdSXz1Of97h9DRAlNZjfs9lf+lAdBh DgNPynFD/pf7Q/drELye9ISr1e6cDhLKxEX27FlrcRk= On 12/06/2026 20:52, 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 > > Here is a trivial reproducer that works with the PPS_CLIENT_KTIMER test > device enabled in the kernel: > > #include > #include > #include > #include > #include > #include > > int main() { > struct pps_fdata fdata; > int fd; > > fd = open("/dev/pps0", O_RDWR); > if (fd == -1) > err(1, "Failed to open /dev/pps0"); > > fdata.timeout.sec = -1; > fdata.timeout.nsec = 0; > > if (ioctl(fd, PPS_FETCH, &fdata)) > err(2, "PPS_FETCH failed"); > > close(fd); > return 0; > } > > 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 using timespec64_to_jiffies(), which hard limits > the timeout to LONG_MAX jiffies. To be safe, explicitly preserve the > -ETIMEDOUT return value userspace sees today if it passes a negative > timeout. > > If you really squint, this is still a slight behavior change in that > there are "denormalized" combinations of tv_sec and tv_nsec which used > to work but will now return -ETIMEDOUT. I can't imagine anybody will > care about that... > > 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 Acked-by: Rodolfo Giometti > --- > Changes in v2: > * Explicitly check that tv_sec is non-negative [Rodolfo] > * Use timespec64_to_jiffies() instead of open coding tick math [Rodolfo] > > (I dropped the RT people/lists in v2 because I realized get_maintainer > was only including them due to "PREEMPT_RT" in the pasted trace.) > > v1: https://lore.kernel.org/lkml/b5241c09ac0dfb82ee076d06367ac6319471c773.1780071212.git.calvin@wbinvd.org/ > > drivers/pps/pps.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c > index de1122bb69ea..7ecdd774a44b 100644 > --- a/drivers/pps/pps.c > +++ b/drivers/pps/pps.c > @@ -66,13 +66,19 @@ static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata) > err = wait_event_interruptible(pps->queue, > ev != pps->last_ev); > else { > + struct timespec64 ts; > unsigned 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 (fdata->timeout.sec < 0) > + return -ETIMEDOUT; > + > + ts.tv_sec = fdata->timeout.sec; > + ts.tv_nsec = fdata->timeout.nsec; > + ticks = timespec64_to_jiffies(&ts); > > if (ticks != 0) { > err = wait_event_interruptible_timeout( -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming