r338446: network access freezing on em/igb NICs
Running CURRENT (FreeBSD 12.0-ALPHA4 #19 r338446: Mon Sep 3 21:07:45 CEST 2018 amd64) on a PCengine APU2C4 (NIC is 3x Intel i210: [...] igb0@pci0:2:0:0:class=0x02 card=0x8086 chip=0x157b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfe50, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x1000, size 32, disabled bar [1c] = type Memory, range 32, base 0xfe52, size 16384, enabled [...] ) When connecting to the as router acting APU from inside my SoHo network from any machine or via serial console, there is no obvious problem so far detectable. Using top(1), which is my indicator for the problem, is sending normal output. The router has igb0 as tun0 and is spanning the network via vlans via igb1. Connecting to a host inside my network and havinf heavy net I/O doesn't reveal any problems so far. Direct access to the APU from outside is prohobited. When loggin into a host inside my private net from my department and then from there toward the router (APU) as a wheel-grouped user also doesn't reveal problems using top - but I have users restricted to see only there own ID and also there groups are limited via some bsd_see_others... sysctls. It gets funny when sudo su -'ing to root on the APU and then using top. Immediately the net traffic freezes forever! Kind regrads oh ___ 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"
github freebsd and svn freebsd
Hello list, What's the difference between github freebsd and svn freebsd, other than one is on github and the other is on svn? How does one transcode or translate a git commit reference into a svn reference number? thanks, -- J. ___ 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"
Re: github freebsd and svn freebsd
Hi! > What's the difference between github freebsd and svn freebsd, other than > one is on github and the other is on svn? The github repo isn't official, because there are still some consistency issues. The consistency problem is: If an repo-copy from svn to git is done, how can that repo-copy be done a second time and still keep the same commit ids (in the git repo) ? > How does one transcode or translate a git commit reference into a svn > reference number? That's a good question. There's a small team working on the github stuff: https://www.freebsd.org/administration.html#t-github-automation -- p...@freebsd.org +49 171 3101372 2 years to go ! ___ 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"
Re: github freebsd and svn freebsd
On Tue, Sep 4, 2018 at 3:32 AM, tech-lists wrote: > Hello list, > > What's the difference between github freebsd and svn freebsd, other than one > is on github and the other is on svn? The github repository is read-only mirror -- new additions all come through SVN. > How does one transcode or translate a git commit reference into a svn > reference number? See https://wiki.freebsd.org/GitWorkflow and look for "notes." Best, Conrad ___ 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"
Re: FreeBSD -CURRENT on AMD Ryzen5
Hi Jake, Please try setting hw.pci.mcfg=0 from the boot loader and see if it helps. On Tue, Sep 4, 2018 at 2:34 AM Jake Champlin wrote: > Testing out various BSD's with a Huawei Matebook D, and FreeBSD -CURRENT is > failing to boot from an installer image. No serial console, so unable to > grab full boot output, any other info or boot flags that would help would > be awesome. > https://i.imgur.com/WAqwbza.jpg, shows where boot process hangs, and fails > to move past. > > Thanks > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ 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"
Re: FreeBSD -CURRENT on AMD Ryzen5
On Tue, Sep 04, 2018 at 09:49:32PM +0530, Rajesh Kumar wrote: > Hi Jake, > > Please try setting hw.pci.mcfg=0 from the boot loader and see if it helps. > > On Tue, Sep 4, 2018 at 2:34 AM Jake Champlin wrote: > > > Testing out various BSD's with a Huawei Matebook D, and FreeBSD -CURRENT is > > failing to boot from an installer image. No serial console, so unable to > > grab full boot output, any other info or boot flags that would help would > > be awesome. > > https://i.imgur.com/WAqwbza.jpg, shows where boot process hangs, and fails > > to move past. > > > > Thanks > > ___ > > freebsd-hack...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > Works to boot the laptop, but no wireless at that point :) Thanks though. ___ 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"
newfs silently fails if random is not ready (?)
Hello FreeBSD, I have problems with diskless install when kernel doesn't have tmpfs and random device takes long time to unlock. Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail to create FS. I've added '-XL' options to mdmfs and it looks like this: da0: quirks=0x2 arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache *** Figure out our NFS root path *** *** handle_remount /conf *** *** templates are base default *** *** handle_remount /conf/base/etc *** *** handle_remount /conf/base/var *** *** handle_remount /conf/default/etc *** *** handle_remount /conf/default/var *** *** create_md etc with size 20480 *** DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B DEBUG: running: /sbin/newfs -U /dev/md0 random: read_random_uio unblock wait random: read_random_uio unblock wait random: unblocking device. DEBUG: running: /sbin/mount /dev/md0 /etc mount: /dev/md0: No such file or directory mdmfs: mount exited with error code 1 "/dev/md0" is here, but it is empty, without any FS. I could run "/sbin/newfs -U /dev/md0" later by hands and it works. -- Best regards, Lev mailto:l...@freebsd.org ___ 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"
Celeron J3160 with enabled Turbo mode stays at 480MHz (lowest setting) forever and can not lower frequency without Tuebo mode
Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz even if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. -- Best regards, Lev mailto:l...@freebsd.org ___ 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"
Re: newfs silently fails if random is not ready (?)
Hi Lev, Newfs just uses arc4random(3) to generate its FSID and generation numbers. arc4random(3) is seeded from getentropy(3) -> getrandom(2) -> read_random_uio(9), which is what produces the "random: read_random_uio unblock wait" messages. Is newfs tripping on a raise()/abort() in arc4random(3) / getentropy(3)? Is your program that runs newfs checking for non-zero exit status? Do you see any newfs cores when this happens? Thanks, Conrad On Tue, Sep 4, 2018 at 1:08 PM, Lev Serebryakov wrote: > Hello FreeBSD, > > I have problems with diskless install when kernel doesn't have tmpfs and > random device takes long time to unlock. > > Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail > to create FS. > > I've added '-XL' options to mdmfs and it looks like this: > > da0: quirks=0x2 > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > *** Figure out our NFS root path *** > *** handle_remount /conf *** > *** templates are base default *** > *** handle_remount /conf/base/etc *** > *** handle_remount /conf/base/var *** > *** handle_remount /conf/default/etc *** > *** handle_remount /conf/default/var *** > *** create_md etc with size 20480 *** > DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B > DEBUG: running: /sbin/newfs -U /dev/md0 > random: read_random_uio unblock wait > random: read_random_uio unblock wait > random: unblocking device. > DEBUG: running: /sbin/mount /dev/md0 /etc > mount: /dev/md0: No such file or directory > mdmfs: mount exited with error code 1 > > "/dev/md0" is here, but it is empty, without any FS. > > I could run "/sbin/newfs -U /dev/md0" later by hands and it works. > > -- > Best regards, > Lev mailto:l...@freebsd.org > > ___ > freebsd...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" ___ 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"
Re: newfs silently fails if random is not ready (?)
Hello Conrad, Tuesday, September 4, 2018, 11:37:59 PM, you wrote: > Newfs just uses arc4random(3) to generate its FSID and generation > numbers. arc4random(3) is seeded from getentropy(3) -> getrandom(2) ->> read_random_uio(9), which is what produces the "random: > read_random_uio unblock wait" messages. > Is newfs tripping on a raise()/abort() in arc4random(3) / > getentropy(3)? Nope, it is silently does nothing > Is your program that runs newfs checking for non-zero > exit status? It is not "my" program, it is system mdmfs(8), and it checks exit statuses, as far as I can see from source code. > Do you see any newfs cores when this happens? It is very first step in diskless boot, so no cores are possible, but I don't see "core dumped" messages too. > Thanks, > Conrad > On Tue, Sep 4, 2018 at 1:08 PM, Lev Serebryakov wrote: >> Hello FreeBSD, >> >> I have problems with diskless install when kernel doesn't have tmpfs and >> random device takes long time to unlock. >> >> Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail >> to create FS. >> >> I've added '-XL' options to mdmfs and it looks like this: >> >> da0: quirks=0x2 >> arc4random: no preloaded entropy cache >> arc4random: no preloaded entropy cache >> *** Figure out our NFS root path *** >> *** handle_remount /conf *** >> *** templates are base default *** >> *** handle_remount /conf/base/etc *** >> *** handle_remount /conf/base/var *** >> *** handle_remount /conf/default/etc *** >> *** handle_remount /conf/default/var *** >> *** create_md etc with size 20480 *** >> DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B >> DEBUG: running: /sbin/newfs -U /dev/md0 >> random: read_random_uio unblock wait >> random: read_random_uio unblock wait >> random: unblocking device. >> DEBUG: running: /sbin/mount /dev/md0 /etc >> mount: /dev/md0: No such file or directory >> mdmfs: mount exited with error code 1 >> >> "/dev/md0" is here, but it is empty, without any FS. >> >> I could run "/sbin/newfs -U /dev/md0" later by hands and it works. >> >> -- >> Best regards, >> Lev mailto:l...@freebsd.org >> >> ___ >> freebsd...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" -- Best regards, Levmailto:l...@freebsd.org ___ 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"
Re: newfs silently fails if random is not ready (?)
Hi Lev, On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov wrote: > Tuesday, September 4, 2018, 11:37:59 PM, you wrote: >> Is newfs tripping on a raise()/abort() in arc4random(3) / >> getentropy(3)? > Nope, it is silently does nothing I think it is tripping on raise/abort() in one of these routines, but nothing is printing that information. See below. >> Is your program that runs newfs checking for non-zero >> exit status? > It is not "my" program, it is system mdmfs(8), and it checks exit > statuses, as far as I can see from source code. Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) the same as programs that exit with success. This is a (major) problem and the reason raise/abort is not visible. Best, Conrad ___ 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"
sh(1) and more(1) hangs on serial terminal at [ttydcd] state.
Hello FreeBSD, When I use serial console (configured as console + "getty std.115200 xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever. If I hit ^T system shows that locked process is in "[ttydcd]" state. ^C kills locked process. What do I have misconfigured? -- Best regards, Lev mailto:l...@freebsd.org ___ 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"
Re: newfs silently fails if random is not ready (?)
Hello Conrad, Wednesday, September 5, 2018, 12:05:43 AM, you wrote: > On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov wrote: >> Tuesday, September 4, 2018, 11:37:59 PM, you wrote: >>> Is newfs tripping on a raise()/abort() in arc4random(3) / >>> getentropy(3)? >> Nope, it is silently does nothing > I think it is tripping on raise/abort() in one of these routines, but > nothing is printing that information. See below. Maybe, it should be fixed? One second after that random is ready to use and newfs works as intended. It is, really, some race between early init script (rc.initdiskless) and kernel. I don't think, that newfs must be killed/aborted in such situation, it could wait! >>> Is your program that runs newfs checking for non-zero >>> exit status? >> It is not "my" program, it is system mdmfs(8), and it checks exit >> statuses, as far as I can see from source code. > Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. > It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) > the same as programs that exit with success. This is a (major) > problem and the reason raise/abort is not visible. And it is another problem. But if it will be fixed, it doesn't help to init system properly in my case, only diagnostic will be better. -- Best regards, Levmailto:l...@freebsd.org ___ 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"
Re: sh(1) and more(1) hangs on serial terminal at [ttydcd] state.
On Wed, 2018-09-05 at 00:07 +0300, Lev Serebryakov wrote: > Hello FreeBSD, > > When I use serial console (configured as console + "getty std.115200 > xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever. > If I hit > ^T system shows that locked process is in "[ttydcd]" state. ^C kills > locked > process. > > What do I have misconfigured? > Change the std.115200 to 3wire.115200 so that it ignores modem-control signals. -- Ian ___ 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"
Re: newfs silently fails if random is not ready (?)
On Tue, Sep 4, 2018 at 2:10 PM, Lev Serebryakov wrote: > Wednesday, September 5, 2018, 12:05:43 AM, you wrote: >> I think it is tripping on raise/abort() in one of these routines, but >> nothing is printing that information. See below. > > Maybe, it should be fixed? Yes, it should. > One second after that random is ready to use and > newfs works as intended. It is, really, some race between early init script > (rc.initdiskless) and kernel. I don't think, that newfs must be > killed/aborted in such situation, it could wait! I agree. It looks like it is waiting, in fact, but then Something Bad Happens when the random device is unblocked. >> Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. >> It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) >> the same as programs that exit with success. This is a (major) >> problem and the reason raise/abort is not visible. > > And it is another problem. But if it will be fixed, it doesn't help to init > system properly in my case, only diagnostic will be better. Yep. Best, Conrad ___ 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"
RE: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
Are you running powers? Do you use c-states? What happens if you boot in (instead of switch to) turbo mode? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Lev Serebryakov Sent: 04/09/2018 13:50 To: FreeBSD Current; freebsd-hack...@freebsd.org Subject: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz even if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. -- Best regards, Lev mailto:l...@freebsd.org ___ freebsd-hack...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ 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"
RE: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mod
Powers s/b powers (autocorrect). --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Cy Schubert Sent: 04/09/2018 17:15 To: l...@freebsd.org; FreeBSD Current; freebsd-hack...@freebsd.org Subject: RE: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode Are you running powers? Do you use c-states? What happens if you boot in (instead of switch to) turbo mode? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Lev Serebryakov Sent: 04/09/2018 13:50 To: FreeBSD Current; freebsd-hack...@freebsd.org Subject: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz even if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. -- Best regards, Lev mailto:l...@freebsd.org ___ freebsd-hack...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ 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" ___ 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"
Re: newfs silently fails if random is not ready (?)
Hi Lev,
I took a first attempt at reproducing this problem on a fast
desktop-class system. First steps, give us a way to revert back to
unseeded status:
--- a/sys/dev/random/fortuna.c
+++ b/sys/dev/random/fortuna.c
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
#ifdef _KERNEL
#include
+#include
#include
#include
#include
@@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
return;
}
+ /*
+* When set, pretend we do not have enough entropy to reseed yet.
+*/
+ KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
+ if (RETURN_VALUE != 0) {
+ RANDOM_RESEED_UNLOCK();
+ return;
+ }
+ });
+
+
#ifdef _KERNEL
fortuna_state.fs_lasttime = now;
#endif
@@ -442,5 +454,11 @@ bool
random_fortuna_seeded(void)
{
+ /* When set, act as if we are not seeded. */
+ KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
+ if (RETURN_VALUE != 0)
+ fortuna_state.fs_counter = UINT128_ZERO;
+ });
+
return (!uint128_is_zero(fortuna_state.fs_counter));
}
Second step, enable the failpoints and launch repro program:
$ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
debug.fail_point.random_fortuna_pre_read: off -> return(1)
$ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
debug.fail_point.random_fortuna_seeded: off -> return(1)
$ cat ./blocked_random_poc.c
#include
#include
#include
int
main(int argc, char **argv)
{
printf("%x\n", arc4random());
return (0);
}
$ ./blocked_random_poc
...
Third step, I looked at what that process was doing:
Curiously, it is not in getrandom() at all, but instead the ARND
sysctl fallback. I probably need to rebuild world (libc) to test this
(new libc arc4random based on Chacha).
$ procstat -kk 1196
PIDTID COMMTDNAME KSTACK
1196 100435 blocked_random_poc - read_random+0x3d
sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
amd64_syscall+0x940 fast_syscall_common+0x101
When I unblocked the failpoints, it completed successfully:
$ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
debug.fail_point.random_fortuna_pre_read: return(1) -> off
$ sudo sysctl debug.fail_point.random_fortuna_seeded=off
debug.fail_point.random_fortuna_seeded: return(1) -> off
...
9e5eb30f
Best,
Conrad
___
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"
Re: newfs silently fails if random is not ready (?)
With current libc, I instead see:
load: 0.10 cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s
0% 2328k (SIGINFO)
$ procstat -kk 1668
PIDTID COMMTDNAME KSTACK
1668 100609 blocked_random_poc - mi_switch+0xd3
sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272
read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940
fast_syscall_common+0x101
and:
$ truss ./blocked_random_poc
...
getrandom(0x7fffd340,40,0) ERR#35 'Resource
temporarily unavailable'
thr_self(0x7fffd310) = 0 (0x0)
thr_kill(100609,SIGKILL) = 0 (0x0)
SIGNAL 9 (SIGKILL) code=SI_NOINFO
So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN
after we have already slept until random was seeded. This bubbles up
to getentropy(3) -> arc4random(3), which sees a surprising failure
from getentropy(3) and raises KILL against the program.
I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
condition. This may be sufficient to fix the problem:
--- a/sys/dev/random/randomdev.c
+++ b/sys/dev/random/randomdev.c
@@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
error = tsleep(&random_alg_context, PCATCH, "randseed", hz/10);
if (error == ERESTART || error == EINTR)
break;
+ /* Squash hz/10 timeout condition */
+ if (error == EWOULDBLOCK)
+ error = 0;
+ KASSERT(error == 0, ("unexpected %d", error));
}
if (error == 0) {
read_rate_increment((uio->uio_resid +
sizeof(uint32_t))/sizeof(uint32_t));
Best,
Conrad
On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer wrote:
> Hi Lev,
>
> I took a first attempt at reproducing this problem on a fast
> desktop-class system. First steps, give us a way to revert back to
> unseeded status:
>
> --- a/sys/dev/random/fortuna.c
> +++ b/sys/dev/random/fortuna.c
> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>
> #ifdef _KERNEL
> #include
> +#include
> #include
> #include
> #include
> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
> return;
> }
>
> + /*
> +* When set, pretend we do not have enough entropy to reseed yet.
> +*/
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
> + if (RETURN_VALUE != 0) {
> + RANDOM_RESEED_UNLOCK();
> + return;
> + }
> + });
> +
> +
> #ifdef _KERNEL
> fortuna_state.fs_lasttime = now;
> #endif
> @@ -442,5 +454,11 @@ bool
> random_fortuna_seeded(void)
> {
>
> + /* When set, act as if we are not seeded. */
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
> + if (RETURN_VALUE != 0)
> + fortuna_state.fs_counter = UINT128_ZERO;
> + });
> +
> return (!uint128_is_zero(fortuna_state.fs_counter));
> }
>
>
> Second step, enable the failpoints and launch repro program:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
> debug.fail_point.random_fortuna_pre_read: off -> return(1)
> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
> debug.fail_point.random_fortuna_seeded: off -> return(1)
>
> $ cat ./blocked_random_poc.c
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
> printf("%x\n", arc4random());
> return (0);
> }
>
>
> $ ./blocked_random_poc
> ...
>
>
> Third step, I looked at what that process was doing:
>
> Curiously, it is not in getrandom() at all, but instead the ARND
> sysctl fallback. I probably need to rebuild world (libc) to test this
> (new libc arc4random based on Chacha).
>
> $ procstat -kk 1196
> PIDTID COMMTDNAME KSTACK
> 1196 100435 blocked_random_poc - read_random+0x3d
> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
> amd64_syscall+0x940 fast_syscall_common+0x101
>
>
> When I unblocked the failpoints, it completed successfully:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
> debug.fail_point.random_fortuna_pre_read: return(1) -> off
> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
> debug.fail_point.random_fortuna_seeded: return(1) -> off
>
> ...
> 9e5eb30f
>
>
> Best,
> Conrad
___
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"
Re: newfs silently fails if random is not ready (?)
On 9/4/18 21:39, Conrad Meyer wrote:
> With current libc, I instead see:
>
> load: 0.10 cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s
> 0% 2328k (SIGINFO)
>
> $ procstat -kk 1668
> PIDTID COMMTDNAME KSTACK
> 1668 100609 blocked_random_poc - mi_switch+0xd3
> sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272
> read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940
> fast_syscall_common+0x101
>
> and:
>
> $ truss ./blocked_random_poc
> ...
> getrandom(0x7fffd340,40,0) ERR#35 'Resource
> temporarily unavailable'
> thr_self(0x7fffd310) = 0 (0x0)
> thr_kill(100609,SIGKILL) = 0 (0x0)
> SIGNAL 9 (SIGKILL) code=SI_NOINFO
>
> So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN
> after we have already slept until random was seeded. This bubbles up
> to getentropy(3) -> arc4random(3), which sees a surprising failure
> from getentropy(3) and raises KILL against the program.
>
> I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
> condition. This may be sufficient to fix the problem:
>
> --- a/sys/dev/random/randomdev.c
> +++ b/sys/dev/random/randomdev.c
> @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
> error = tsleep(&random_alg_context, PCATCH, "randseed",
> hz/10);
> if (error == ERESTART || error == EINTR)
> break;
> + /* Squash hz/10 timeout condition */
> + if (error == EWOULDBLOCK)
> + error = 0;
> + KASSERT(error == 0, ("unexpected %d", error));
> }
> if (error == 0) {
> read_rate_increment((uio->uio_resid +
> sizeof(uint32_t))/sizeof(uint32_t));
+markm, re
I think the proposed change is reasonable (note that I think the same
theory applies to the tsleep_sbt() case below as well, which should be
handled similarly).
> Best,
> Conrad
>
>
> On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer wrote:
>> Hi Lev,
>>
>> I took a first attempt at reproducing this problem on a fast
>> desktop-class system. First steps, give us a way to revert back to
>> unseeded status:
>>
>> --- a/sys/dev/random/fortuna.c
>> +++ b/sys/dev/random/fortuna.c
>> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>>
>> #ifdef _KERNEL
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>> return;
>> }
>>
>> + /*
>> +* When set, pretend we do not have enough entropy to reseed yet.
>> +*/
>> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
>> + if (RETURN_VALUE != 0) {
>> + RANDOM_RESEED_UNLOCK();
>> + return;
>> + }
>> + });
>> +
>> +
>> #ifdef _KERNEL
>> fortuna_state.fs_lasttime = now;
>> #endif
>> @@ -442,5 +454,11 @@ bool
>> random_fortuna_seeded(void)
>> {
>>
>> + /* When set, act as if we are not seeded. */
>> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
>> + if (RETURN_VALUE != 0)
>> + fortuna_state.fs_counter = UINT128_ZERO;
>> + });
>> +
>> return (!uint128_is_zero(fortuna_state.fs_counter));
>> }
>>
>>
>> Second step, enable the failpoints and launch repro program:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
>> debug.fail_point.random_fortuna_pre_read: off -> return(1)
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
>> debug.fail_point.random_fortuna_seeded: off -> return(1)
>>
>> $ cat ./blocked_random_poc.c
>> #include
>> #include
>> #include
>>
>> int
>> main(int argc, char **argv)
>> {
>> printf("%x\n", arc4random());
>> return (0);
>> }
>>
>>
>> $ ./blocked_random_poc
>> ...
>>
>>
>> Third step, I looked at what that process was doing:
>>
>> Curiously, it is not in getrandom() at all, but instead the ARND
>> sysctl fallback. I probably need to rebuild world (libc) to test this
>> (new libc arc4random based on Chacha).
>>
>> $ procstat -kk 1196
>> PIDTID COMMTDNAME KSTACK
>> 1196 100435 blocked_random_poc - read_random+0x3d
>> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
>> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
>> amd64_syscall+0x940 fast_syscall_common+0x101
>>
>>
>> When I unblocked the failpoints, it completed successfully:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
>> debug.fail_point.random_fortuna_pre_read: return(1) -> off
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
>> debug.fail_point.random_fortuna_seeded: return(1) -> off
>>
>> ...
>> 9e5eb30f
>>
>>
>> Best,
>> Conrad
signature.asc
Description: OpenPGP digital signature
