NetBSD Problem Report #60364

From www@netbsd.org  Wed Jun 24 15:18:14 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D64381A923A
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 24 Jun 2026 15:18:14 +0000 (UTC)
Message-Id: <20260624151813.B44721A923B@mollari.NetBSD.org>
Date: Wed, 24 Jun 2026 15:18:13 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: if_spppsubr.c uses nonportable 64-bit atomics
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60364
>Category:       kern
>Synopsis:       if_spppsubr.c uses nonportable 64-bit atomics
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yamaguchi
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 24 15:20:00 +0000 2026
>Closed-Date:    
>Last-Modified:  Wed Jun 24 15:50:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current as of today
>Organization:
The NetPPP Foundatime, Inc.
>Environment:
>Description:

	The recent change to use atomic_load/store for last tx/rx
	activity in if_spppsubr.c broke the build on most or all 32-bit
	platforms because it operates on time_t, which is 64-bit, wider
	than allowed for atomic loads and stores:

--- if_spppsubr.o ---
In file included from /tmp/build/2026.06.24.13.51.21-i386/src/sys/rump/net/lib/libnet/../../../../net/if_spppsubr.c:43:
/tmp/build/2026.06.24.13.51.21-i386/src/sys/rump/net/lib/libnet/../../../../net/if_spppsubr.c: In function 'sppp_input':
/tmp/build/2026.06.24.13.51.21-i386/src/sys/rump/net/lib/libnet/../../../../sys/cdefs.h:172:48: error: negative width in bit-field '__ctassert27'
...
/tmp/build/2026.06.24.13.51.21-i386/src/sys/rump/net/lib/libnet/../../../../sys/atomic.h:427:9: note: in expansion of macro 'CTASSERT'
  427 |         CTASSERT(sizeof(*(p)) <= __ATOMIC_SIZE_MAX);                          \
      |         ^~~~~~~~
/tmp/build/2026.06.24.13.51.21-i386/src/sys/rump/net/lib/libnet/../../../../sys/atomic.h:485:9: note: in expansion of macro '__ATOMIC_PTR_CHECK'
  485 |         __ATOMIC_PTR_CHECK(__as_ptr);                                         \
      |         ^~~~~~~~~~~~~~~~~~
/tmp/build/2026.06.24.13.51.21-i386/src/sys/rump/net/lib/libnet/../../../../net/if_spppsubr.c:759:25: note: in expansion of macro 'atomic_store_relaxed'
  759 |                         atomic_store_relaxed(&sp->pp_last_activity, time_uptime);
      |                         ^~~~~~~~~~~~~~~~~~~~

>How-To-Repeat:

	./build.sh -m i386 kernel=GENERIC

>Fix:

	Use uint32_t and time_uptime32 -- the times are checked
	periodically long before a 32-bit number of seconds can roll
	over, and it is not reasonable to set >=68-year timeouts.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->yamaguchi
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Wed, 24 Jun 2026 15:36:06 +0000
Responsible-Changed-Why:
I went ahead and committed a change to use 32-bit arithmetic for the
times in question, since this is holding up the primary releng testbed
running on i386.  Please review and feel free to do it differently!
(Or if you're happy with this, feel free to just close the PR.)


State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 24 Jun 2026 15:36:06 +0000
State-Changed-Why:
candidate fix committed


From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60364 CVS commit: src/sys/net
Date: Wed, 24 Jun 2026 15:30:45 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Wed Jun 24 15:30:45 UTC 2026

 Modified Files:
 	src/sys/net: if_spppsubr.c if_spppvar.h

 Log Message:
 ppp(4): Use 32-bit timeouts, not 64-bit timeouts.

 The timeouts are checked every 15sec so there is no real need to
 record starting and ending times in units of seconds with more than 5
 bits of precision.  So 32-bit starting and ending times are more than
 enough.  And there is surely no need for decades-long timeouts.

 1. Clamp the timeouts in SPPPSETIDLETO(struct spppidletimeout) and
    SPPPSETKEEPALIVE(struct spppkeepalivesettings) to INT32_MAX/2,
    which is over 34 years worth of seconds.

    (We should never have spent any effort on time_t compat for these:
    we should have just left them at 32-bit!  Oh well.)

 2. Use time_uptime32, not time_uptime, since 32-bit unsigned
    arithmetic is large enough to handle all the differences we will
    encounter when timeouts are clamped to INT32_MAX/2 without any
    risk of trouble from wraparound.

 PR kern/60364: if_spppsubr.c uses nonportable 64-bit atomics


 To generate a diff of this commit:
 cvs rdiff -u -r1.296 -r1.297 src/sys/net/if_spppsubr.c
 cvs rdiff -u -r1.52 -r1.53 src/sys/net/if_spppvar.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search