Re: uname -a output without svn revision number
El día viernes, enero 04, 2019 a las 07:52:40a. m. +0100, Dimitry Andric escribió: > On 4 Jan 2019, at 06:52, Matthias Apitz wrote: > > > > I've compiled CURRENT from svn and this gave me as 'uname -a' output: > > > > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT r342378 GENERIC > > amd64 > > > > Now I've had do modify a source file (to nail down some problem) and the > > revision number went away from the output; it now says: > > > > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 > > > > Why is this? I've read in UPDATING that: > > > > ... > > > > But this does not explain why now the SVN revision number went away. > > For me, it doesn't go away, but shows an "M" suffix, instead. In > /usr/obj/usr/src/sys/GENERIC/vers.c it shows: > > #define VERSTR "FreeBSD 13.0-CURRENT r342593M \n" > > What is the output of sh /usr/src/sys/conf/newvers.sh for you? $ ls -l /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vers.c -rw-r--r-- 1 root wheel 1919 3 ene. 11:59 /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vers.c $ tail -12 /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vers.c #define SCCSSTR "@(#)FreeBSD 13.0-CURRENT GENERIC" #define VERSTR "FreeBSD 13.0-CURRENT GENERIC\n" #define RELSTR "13.0-CURRENT" char sccs[sizeof(SCCSSTR) > 128 ? sizeof(SCCSSTR) : 128] = SCCSSTR; char version[sizeof(VERSTR) > 256 ? sizeof(VERSTR) : 256] = VERSTR; char compiler_version[] = "FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1)"; char ostype[] = "FreeBSD"; char osrelease[sizeof(RELSTR) > 32 ? sizeof(RELSTR) : 32] = RELSTR; int osreldate = 135; char kern_ident[] = "GENERIC"; $ sh /usr/src/sys/conf/newvers.sh I did around 11:50 am (i.e. the mod time of vers.c matches) a 'make buildkernel NO_CLEAN=yes' matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. signature.asc Description: PGP signature
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 29.12.2018 18:47, Dennis Clarke wrote:
> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>
>> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>>
>>> On 2018-Dec-28, at 05:13, Michal Meloun
>>> wrote:
>>>
Mark,
this is known problem with qemu-user-static.
Emulation of every single interruptible syscall is broken by design (it
have signal related races). Theses races cannot be solved without major
rewrite of syscall emulation code.
Unfortunately, nobody actively works on this, I think.
>
> Following along here quietly and I had to blink at this a few times.
> Is there a bug report somewhere within the qemu world related to this
> 'broken by design' qemu feature?
Firstly, I apologize for late answer. Writing a technically accurate but
still comprehensible report is extremely difficult for me.
Major design issue with qemu-user is the fact that guest (blocking /
interruptible) syscalls must be emulated atomically, including
delivering of asynchronous signals (including signals originated by
other thread).
This is something that cannot be emulated precisely by user mode
program, without specific kernel support. Let me explain this in a
little more details.
Assume that we have following trivial code:
void sig_alarm_handler(…)
{
if (!done) {
do some work;
alarm(10);
}
}
void foo(void)
{
install_signal_handler(SIGALARM, sig_alarm_handler);
alarm(10);
do some work;
while (true) {
rv = select(…, NULL);
if (rv == 0)
do some work;
else if (rv != EINTR)
Report error end exit;
}
}
In native environment, this code works well. It calls alarm signal
handler every 10s, irrespective if signal is fired in the program code
or in libc implementation of select() or if program is waiting in kernel
part of select() syscall.
In qemu-user environment, things get significantly harder. Qemu can
deliver signals to guest only on instruction boundary, the guest signal
handler should see emulated CPU context in consistent state. But kernel
can deliver signal to qemu in any time. Due to this, qemu must store
delivered signals into queue and emit these later, when emulator steps
over next instruction boundary.
Assume that qemu just emulates 'syscall' instruction from guest select()
call. Also assume that no other signals (but SIGALARM) are generated,
and socket used in select() never received or transmits any data.
The first version of qemu-user code emulating select() was:
abi_long do_freebsd_select(..)
{
convert input guest arguments to host;
rv = select(…);
convert output host arguments to guest;
return(rv);
}
But this is very racy. If alarm signal is fired before select(…) enters
kernel, qemu queues it (but does not deliver it to guest because it
isn't on instruction boundary) and continues in emulation. And because
(in our case) select() waits indefinitely, alarm signal is never
delivered to guest and whole program hangs.
Actual qemu code emulating select() looks like:
abi_long do_freebsd_select(..)
{
convert input guest arguments to host;
sigfillset(&mask);
sigprocmask(SIG_BLOCK, &mask, &omask);
if (ts->signal_pending) {
sigprocmask(SIG_SETMASK, &omask, NULL);
/* We have a signal pending so just poll select() and return. */
tv2.tv_sec = tv2.tv_usec = 0;
ret = select(…, , &tv2));
if (ret == 0)
ret = TARGET_EINTR;
} else {
ret = pselect(…, &omask));
sigprocmask(SIG_SETMASK, &omask, NULL);
}
convert output host arguments to guest;
return(rv);
}
This look a much better. The code blocks all signals first, then checks
if any signal is pending. If yes, then does not-blocking select()
(because timeout is zero) and correctly returns EINTR immediately.
Otherwise, it uses other variant of select(), pselect() which adjusts
right signal mask itself.
That's mean that syscall is called with blocked signal delivery, but
kernel adjusts right sigmask before it waits for event. While this looks
like perfect solution and this code closes all races from first version,
then it doesn't. pselect() uses different semantic that select(), it
doesn't update timeout argument. So this solution is also inappropriate.
Moreover, I think, we don't have p equivalents for all blocking
syscalls.
Mark, I hope that this is also the answer to your question posted to
hackers@ and also the exploitation why you see hang.
Linux uses different approach to overcome this issue, safe_syscall ->
https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4
It looks like workable workaround, but I'm not sure about ERESTART
versus EINTR return values. Imho, this can be problem.
I have list of other qemu-user problems (I mean mainly a bsd-user part
of qemu code here), not counting normal coding bugs:
- code is not thread safety but is used in threaded environment (rw
locks for example),
- emulate some sysctl's and resource limits / usage behavior is very
hard (mainly if we emulate 32-bits guest on 64-
Re: uname -a output without svn revision number
On 4 Jan 2019, at 06:52, Matthias Apitz wrote: > > I've compiled CURRENT from svn and this gave me as 'uname -a' output: > > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT r342378 GENERIC amd64 > > Now I've had do modify a source file (to nail down some problem) and the > revision number went away from the output; it now says: > > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 > > Why is this? I've read in UPDATING that: > > ... > 20180913: >Reproducible build mode is now on by default, in preparation for >FreeBSD 12.0. This eliminates build metadata such as the user, >host, and time from the kernel (and uname), unless the working tree >corresponds to a modified checkout from a version control system. >The previous behavior can be obtained by setting the /etc/src.conf >knob WITHOUT_REPRODUCIBLE_BUILD. > ... > > But this does not explain why now the SVN revision number went away. For me, it doesn't go away, but shows an "M" suffix, instead. In /usr/obj/usr/src/sys/GENERIC/vers.c it shows: #define VERSTR "FreeBSD 13.0-CURRENT r342593M \n" What is the output of sh /usr/src/sys/conf/newvers.sh for you? -Dimitry signature.asc Description: Message signed with OpenPGP
Re: kernel config question
On Wed, Jan 2, 2019 at 5:02 PM Robert Huff wrote: > > John Baldwin writes: > > > -[8] In order to have a kernel that can run the 4.x binaries needed > to > > -do an installworld, you must include the COMPAT_FREEBSD4 option in > > -your kernel. Failure to do so may leave you with a system that is > > -hard to boot to recover. A similar kernel option COMPAT_FREEBSD5 is > > -required to run the 5.x binaries on more recent kernels. And so on > > -for COMPAT_FREEBSD6 and COMPAT_FREEBSD7. > > +[8] The new kernel must be able to run existing binaries used by > > +an installworld. When upgrading across major versions, the new > > +kernel's configuration must include the correct COMPAT_FREEBSD > > +option for existing binaries (e.g. COMPAT_FREEBSD11 to run 11.x > > +binaries). Failure to do so may leave you with a system that is > > +hard to boot to recover. A GENERIC kernel will include suitable > > +compatibility options to run binaries from older branches. > > Maybe not perfect, but _much_ better. > Thanks. > > > Respectfully, > > > Robert Huff > Some ports may require compat ports. E.g. plexmediaserver requires compat9x. Oddly, compat9x requires compat10x, so I need 9, 10, and 11. Now that 10 is EOL, I wish Plex would start building their blobs against 11. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
uname -a output without svn revision number
Hello, I've compiled CURRENT from svn and this gave me as 'uname -a' output: FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT r342378 GENERIC amd64 Now I've had do modify a source file (to nail down some problem) and the revision number went away from the output; it now says: FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 Why is this? I've read in UPDATING that: ... 20180913: Reproducible build mode is now on by default, in preparation for FreeBSD 12.0. This eliminates build metadata such as the user, host, and time from the kernel (and uname), unless the working tree corresponds to a modified checkout from a version control system. The previous behavior can be obtained by setting the /etc/src.conf knob WITHOUT_REPRODUCIBLE_BUILD. ... But this does not explain why now the SVN revision number went away. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. signature.asc Description: PGP signature
