15.05.2025 13:05, Mark Kettenis пишет:
>> Date: Thu, 15 May 2025 11:22:17 +0200
>> From: Claudio Jeker <[email protected]>
>>
>> On Thu, May 15, 2025 at 06:28:42PM +1000, Jonathan Matthew wrote:
>>> On Tue, May 13, 2025 at 07:55:03AM +0200, Otto Moerbeek wrote:
>>>> On Mon, May 12, 2025 at 08:07:11PM +0200, Sebastien Marie wrote:
>>>>
>>>>>> I suppose the same could occurs with lld (untested for now).
>>>>>
>>>>> I confirm it is the same problem with lld.
>>>>>
>>>>> $ cd /usr/share/relink/kernel/GENERIC.MP
>>>>> $ ld -T ld.script -X --warn-common -nopie -o /tmp/newbsd *.o && echo ok
>>>>>
>>>>> /tmp: write failed, file system is full
>>>>> ok
>>>>> $ ls -l /tmp/newbsd
>>>>> -rwxr-xr-x 1 semarie wheel 236434608 May 12 20:05 /tmp/newbsd*
>>>>>
>>>>> And my dmesg has the following:
>>>>> uvn_flush: obj=0xfffffd86e3311608, offset=0x16b0000. error during
>>>>> pageout.
>>>>> uvn_flush: WARNING: changes to page may be lost!
>>>>
>>>> So this code is using mmapped files for writing, which makes proper
>>>> error handling extremely difficult or even impossible. Best bet is
>>>> making sure enough space is available before starting.
>>>
>>> lld has a --no-mmap-output-file option that causes it to use plain write(2)
>>> calls to generate the output file. Perhaps it'd be worth using that for
>>> kernel linking and other stuff we relink at boot time?
>>
>> Maybe that should be the default. Having lld produce bad binaries but exit
>> 0 is just very wrong. Not sure if this a problem that only manifests on
>> OpenBSD since there is no unified buffer cache or if other systems would
>> hit the same issue as well. As Otto mentioned detection IO errors when
>> using mmap to write files is not trivial.
>
> I think the same problem exists on other OSes, even those with a
> unified buffer cache. I suppose lld(1) could use msync(2) (with the
> MS_SYNC) flag to make sure everything lands on disk correctly. But
> that obviously would remove some of the benefits of using mmap(),
> namely the async completion of the writes.
>
> It would be intersting to see what the impact on build times of
> changing the defaults would be. But I'm somewhat hesitant to change
> the default since the --no-mmap-output-file code path isn't tested
> much on other OSes.
Shall we first try it for kernels only?
# make && make install && reboot
ld -T ld.script -X --warn-common -nopie --no-mmap-output-file -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
text data bss dec hex
26918218 492744 1351680 28762642 1b6e212
mv bsd bsd.gdb
ctfstrip -S -o bsd bsd.gdb
$ cat /usr/share/relink/kernel/GENERIC.MP/relink.log
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0xcccccccc gapdummy.o
ld -T ld.script -X --warn-common -nopie --no-mmap-output-file -o newbsd
${SYSTEM_HEAD} vers.o ${OBJS}
text data bss dec hex
26908374 489800 1347584 28745758 1b6a01e
mv newbsd newbsd.gdb
[...]
This also effects installs and upgrades.
Index: sys/arch/amd64/conf/Makefile.amd64
===================================================================
RCS file: /cvs/src/sys/arch/amd64/conf/Makefile.amd64,v
diff -u -p -r1.142 Makefile.amd64
--- sys/arch/amd64/conf/Makefile.amd64 5 May 2025 20:43:32 -0000 1.142
+++ sys/arch/amd64/conf/Makefile.amd64 22 May 2025 02:44:05 -0000
@@ -111,6 +111,8 @@ COPTIMIZE?= -O2
CFLAGS= ${DEBUG} ${CWARNFLAGS} ${CMACHFLAGS} ${COPTIMIZE}
${COPTS} ${PIPE}
AFLAGS= -D_LOCORE -x assembler-with-cpp ${CWARNFLAGS}
${CMACHFLAGS}
LINKFLAGS= -T ld.script -X --warn-common -nopie
+# propagate failure like ENOSPC on relink
+LINKFLAGS+= --no-mmap-output-file
HOSTCC?= ${CC}
HOSTED_CPPFLAGS=${CPPFLAGS:S/^-nostdinc$//}
