Linux kbuild/kconfig development
 help / color / mirror / Atom feed
* [PATCH] gen_initramfs.sh: add the positive check for timestamp
@ 2025-10-15  2:18 Gang Yan
  2025-10-15  5:42 ` David Disseldorp
  2025-10-15 13:39 ` Nicolas Schier
  0 siblings, 2 replies; 5+ messages in thread
From: Gang Yan @ 2025-10-15  2:18 UTC (permalink / raw)
  To: Nathan Chancellor, Nicolas Schier, David Disseldorp, linux-kbuild
  Cc: Gang Yan

The gen_initramfs.sh script has already checked that 'date' returned
somthing, but it did not verify the content of the return. This patch
adds a check to ensure the correctness of the timestamp obtained via the
'date -d'.

Signed-off-by: Gang Yan <yangang@kylinos.cn>
---
Notes:

This issue is reported in mptcp-upstream-virtme-docker. A issue in RUST
CoreUils [1] causes a compilation error:
'''
	ERROR: Timestamp out of range for cpio format
	make[4]: *** [<KERNEL_SRC>/usr/Makefile:76:
'''

The root cause of this error is the the output of 'date -d0' is 'Sat Jan 
1 00:00:00 UTC 0000'. We started a discussion on [2], and want your
suggestion about 'Is the compilation error too strict when failing to 
retrieve the date? Maybe an extra check could be added to make sure the
timestamp is positive?'

Thanks,
Gang

[1]https://github.com/uutils/coreutils/issues/8898
[2]https://patchwork.kernel.org/project/mptcp/patch/20251013101946.248420-1-yangang@kylinos.cn/
---
 usr/gen_initramfs.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/usr/gen_initramfs.sh b/usr/gen_initramfs.sh
index 7eba2fddf0ef..a076719e4d9f 100755
--- a/usr/gen_initramfs.sh
+++ b/usr/gen_initramfs.sh
@@ -223,7 +223,7 @@ while [ $# -gt 0 ]; do
 			;;
 		"-d")	# date for file mtimes
 			timestamp="$(date -d"$1" +%s || :)"
-			if test -n "$timestamp"; then
+			if test -n "$timestamp" && test "$timestamp" -ge 0; then
 				timestamp="-t $timestamp"
 			fi
 			shift
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] gen_initramfs.sh: add the positive check for timestamp
  2025-10-15  2:18 [PATCH] gen_initramfs.sh: add the positive check for timestamp Gang Yan
@ 2025-10-15  5:42 ` David Disseldorp
  2025-10-15 13:39 ` Nicolas Schier
  1 sibling, 0 replies; 5+ messages in thread
From: David Disseldorp @ 2025-10-15  5:42 UTC (permalink / raw)
  To: Gang Yan; +Cc: Nathan Chancellor, Nicolas Schier, linux-kbuild

Hi,

On Wed, 15 Oct 2025 10:18:31 +0800, Gang Yan wrote:

> The gen_initramfs.sh script has already checked that 'date' returned
> somthing, but it did not verify the content of the return. This patch
> adds a check to ensure the correctness of the timestamp obtained via the
> 'date -d'.

This change doesn't seem unreasonable, but I think failing when an
unsupported date is explicitly provided is an improvement over silent
fallback to time() based initramfs mtimes.
A change to the kbuild.rst KBUILD_BUILD_TIMESTAMP documentation would be
worthwhile. Could you add a note regarding initramfs and pre-epoch times
there?

Thanks, David

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gen_initramfs.sh: add the positive check for timestamp
@ 2025-10-15 10:18 GangYan
  2025-10-15 10:27 ` David Disseldorp
  0 siblings, 1 reply; 5+ messages in thread
From: GangYan @ 2025-10-15 10:18 UTC (permalink / raw)
  To: David Disseldorp; +Cc: Nathan Chancellor, Nicolas Schier, linux-kbuild

> Hi,

> On Wed, 15 Oct 2025 10:18:31 +0800, Gang Yan wrote:

> The gen_initramfs.sh script has already checked that 'date' returned
> somthing, but it did not verify the content of the return. This patch
> adds a check to ensure the correctness of the timestamp obtained via the
> 'date -d'.

> This change doesn't seem unreasonable, but I think failing when an
> unsupported date is explicitly provided is an improvement over silent
> fallback to time() based initramfs mtimes.
> A change to the kbuild.rst KBUILD_BUILD_TIMESTAMP documentation would be
> worthwhile. Could you add a note regarding initramfs and pre-epoch times
> there?
Sure, I will send a new one. Would you mind add your "Suggested-by"
tag in the new patch?

Thanks,
Gang
> Thanks, David

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gen_initramfs.sh: add the positive check for timestamp
  2025-10-15 10:18 GangYan
@ 2025-10-15 10:27 ` David Disseldorp
  0 siblings, 0 replies; 5+ messages in thread
From: David Disseldorp @ 2025-10-15 10:27 UTC (permalink / raw)
  To: GangYan; +Cc: Nathan Chancellor, Nicolas Schier, linux-kbuild

On Wed, 15 Oct 2025 18:18:23 +0800, GangYan wrote:

> > This change doesn't seem unreasonable, but I think failing when an
> > unsupported date is explicitly provided is an improvement over silent
> > fallback to time() based initramfs mtimes.
> > A change to the kbuild.rst KBUILD_BUILD_TIMESTAMP documentation would be
> > worthwhile. Could you add a note regarding initramfs and pre-epoch times
> > there?  
> Sure, I will send a new one.

Thanks.

> Would you mind add your "Suggested-by" tag in the new patch?

Sure, I don't mind.

Cheers, David

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gen_initramfs.sh: add the positive check for timestamp
  2025-10-15  2:18 [PATCH] gen_initramfs.sh: add the positive check for timestamp Gang Yan
  2025-10-15  5:42 ` David Disseldorp
@ 2025-10-15 13:39 ` Nicolas Schier
  1 sibling, 0 replies; 5+ messages in thread
From: Nicolas Schier @ 2025-10-15 13:39 UTC (permalink / raw)
  To: Gang Yan; +Cc: Nathan Chancellor, David Disseldorp, linux-kbuild

On Wed, Oct 15, 2025 at 10:18:31AM +0800, Gang Yan wrote:
> The gen_initramfs.sh script has already checked that 'date' returned
> somthing, but it did not verify the content of the return. This patch
> adds a check to ensure the correctness of the timestamp obtained via the
> 'date -d'.
> 
> Signed-off-by: Gang Yan <yangang@kylinos.cn>
> ---
> Notes:
> 
> This issue is reported in mptcp-upstream-virtme-docker. A issue in RUST
> CoreUils [1] causes a compilation error:
> '''
> 	ERROR: Timestamp out of range for cpio format
> 	make[4]: *** [<KERNEL_SRC>/usr/Makefile:76:
> '''
> 
> The root cause of this error is the the output of 'date -d0' is 'Sat Jan 
> 1 00:00:00 UTC 0000'. We started a discussion on [2], and want your
> suggestion about 'Is the compilation error too strict when failing to 
> retrieve the date? Maybe an extra check could be added to make sure the
> timestamp is positive?'
> 
> Thanks,
> Gang
> 
> [1]https://github.com/uutils/coreutils/issues/8898
> [2]https://patchwork.kernel.org/project/mptcp/patch/20251013101946.248420-1-yangang@kylinos.cn/
> ---
>  usr/gen_initramfs.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/usr/gen_initramfs.sh b/usr/gen_initramfs.sh
> index 7eba2fddf0ef..a076719e4d9f 100755
> --- a/usr/gen_initramfs.sh
> +++ b/usr/gen_initramfs.sh
> @@ -223,7 +223,7 @@ while [ $# -gt 0 ]; do
>  			;;
>  		"-d")	# date for file mtimes
>  			timestamp="$(date -d"$1" +%s || :)"
> -			if test -n "$timestamp"; then
> +			if test -n "$timestamp" && test "$timestamp" -ge 0; then

This will hide invalid timestamps w/o notice.  As KBUILD_BUILD_TIMESTAMP 
is documented in Documentation/kbuild/reproducible-builds.rst, I think 
it's a good thing to fail if it will not be considered while generating 
the cpio archive.

Is there a good reason do support pre-epoch timestamps?

If you explicitly want to keep feeding KBUILD_BUILD_TIMESTAMP="@0" (for 
reproducibility), you might also want to set TZ=UTC (also for 
reproducibility)?

Kind regards,
Nicolas

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-10-15 13:45 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-15  2:18 [PATCH] gen_initramfs.sh: add the positive check for timestamp Gang Yan
2025-10-15  5:42 ` David Disseldorp
2025-10-15 13:39 ` Nicolas Schier
  -- strict thread matches above, loose matches on Subject: below --
2025-10-15 10:18 GangYan
2025-10-15 10:27 ` David Disseldorp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox