Re: possibility to disable relink in conf
On Thu, Sep 14, 2017 at 10:26 AM, sven falempin wrote: > > > On Wed, Sep 13, 2017 at 9:07 PM, Theo de Raadt wrote: >> >> > +[[ $reorder != NO ]] && /usr/libexec/reorder_kernel & >> >> No. Kernels get relinked. >> >> if you don't like it, make your own personal changes and suffer >> the consequences. >> >> We are not going to add buttons for 1 person. >> >> Stop suggesting changes which reduce safety. You provided no >> justifaction. "Here have a diff" is a stupid process. Ever wonder >> why you don't have an account? Hint: You don't discuss, you >> don't read commit messages, you don't read our justifications, >> you don't act in the same directions. D. >> > > > I completly missed the > > library_aslr > > and/but for kernel > > # Skip if /usr/share is on a nfs mounted filesystem. > > So yes, Kernels _often_ get relinked, > instead of being smart and guessing the NFS > is the only problem, being to explicitly in local conf is the only problem, being ABLE to explicitly WRITE in local conf > droping the cool re-link would be more visible THAT the cool re-link is being DROPPED ... > > and my diff is garbage. > > -- > -- > - > The 1 %on -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: possibility to disable relink in conf
On Wed, Sep 13, 2017 at 9:07 PM, Theo de Raadt wrote: > > +[[ $reorder != NO ]] && /usr/libexec/reorder_kernel & > > No. Kernels get relinked. > > if you don't like it, make your own personal changes and suffer > the consequences. > > We are not going to add buttons for 1 person. > > Stop suggesting changes which reduce safety. You provided no > justifaction. "Here have a diff" is a stupid process. Ever wonder > why you don't have an account? Hint: You don't discuss, you > don't read commit messages, you don't read our justifications, > you don't act in the same directions. D. > > I completly missed the library_aslr and/but for kernel # Skip if /usr/share is on a nfs mounted filesystem. So yes, Kernels _often_ get relinked, instead of being smart and guessing the NFS is the only problem, being to explicitly in local conf droping the cool re-link would be more visible and my diff is garbage. -- -- - The 1 %on
Re: syslogd preopen console
On Wed, Sep 13, 2017 at 05:48:04PM +0200, Alexander Bluhm wrote: > Hi, > > syslogd has special code for reporting errors before it has been > initialized. Then it tries to log to console. For every message > it reopens the console with file descriptor passing from the privsep > parent. Of course that does not work when we have reached our file > descriptor limit. I think is is better to have the console preopend, > so we can always get a message out. > > ok? makes sense. ok brynet@ > > bluhm > > Index: usr.sbin/syslogd/syslogd.c > === > RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v > retrieving revision 1.246 > diff -u -p -r1.246 syslogd.c > --- usr.sbin/syslogd/syslogd.c12 Sep 2017 15:17:20 - 1.246 > +++ usr.sbin/syslogd/syslogd.c13 Sep 2017 14:59:20 - > @@ -483,6 +483,10 @@ main(int argc, char *argv[]) > consfile.f_type = F_CONSOLE; > (void)strlcpy(consfile.f_un.f_fname, ctty, > sizeof(consfile.f_un.f_fname)); > + consfile.f_file = open(consfile.f_un.f_fname, O_WRONLY|O_NONBLOCK, 0); > + if (consfile.f_file == -1) > + log_warn("open %s", consfile.f_un.f_fname); > + > (void)gethostname(LocalHostName, sizeof(LocalHostName)); > if ((p = strchr(LocalHostName, '.')) != NULL) { > *p++ = '\0'; > @@ -1780,16 +1784,14 @@ logline(int pri, int flags, char *from, > /* log the message to the particular outputs */ > if (!Initialized) { > f = &consfile; > - f->f_file = priv_open_tty(ctty); > - > - if (f->f_file >= 0) { > + if (f->f_type == F_CONSOLE) { > strlcpy(f->f_lasttime, timestamp, > sizeof(f->f_lasttime)); > strlcpy(f->f_prevhost, from, > sizeof(f->f_prevhost)); > fprintlog(f, flags, msg); > - (void)close(f->f_file); > - f->f_file = -1; > + /* May be set to F_UNUSED, try again next time. */ > + f->f_type = F_CONSOLE; > } > return; > } > >
Re: Improve the accuracy of the TSC frequency calibration - Updated Patch
On Fri, Aug 25, 2017 at 12:43:44PM +0200, Mike Belopuhov wrote: > On Fri, Aug 25, 2017 at 00:40 -0700, Mike Larkin wrote: > > On Thu, Aug 24, 2017 at 12:39:33PM +0800, Adam Steen wrote: > > > On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin wrote: > > > > On Wed, Aug 23, 2017 at 09:29:15PM +0800, Adam Steen wrote: > > > >> > > > >> Thank you Mike on the feedback on the last patch, please see the diff > > > >> below, update with your input and style(9) > > > >> > > > >> I have continued to use tsc as my timecounter and /var/db/ntpd.driff > > > >> has stayed under 10. > > > >> > > > >> cat /var/db/ntpd.drift > > > >> 6.665 > > > >> > > > >> ntpctl -s all > > > >> 4/4 peers valid, constraint offset -1s, clock synced, stratum 3 > > > >> > > > >> peer > > > >>wt tl st next poll offset delay jitter > > > >> 144.48.166.166 from pool pool.ntp.org > > > >> 1 10 24s 32s-3.159ms87.723ms10.389ms > > > >> 13.55.50.68 from pool pool.ntp.org > > > >> 1 10 3 11s 32s-3.433ms86.053ms18.095ms > > > >> 14.202.204.182 from pool pool.ntp.org > > > >> 1 10 1 14s 32s 1.486ms86.545ms16.483ms > > > >> 27.124.125.250 from pool pool.ntp.org > > > >> * 1 10 2 12s 30s -10.275ms54.156ms70.389ms > > > >> > > > >> Cheers > > > >> Adam > > > > > > > > IIRC you have an x220, right? > > > > > > > > If so, could you try letting the clock run for a bit (while using tsc > > > > timecounter selection) after apm -L to drop the speed? (make sure > > > > apm shows that it dropped). > > > > > > > > Even though my x230 supposedly has a constant/invar TSC (according to > > > > cpuid), the TSC drops from 2.5GHz to 1.2GHz when apm -L runs, which > > > > causes time to run too slowly when tsc is selected there. > > > > > > > > -ml > > > > > > > > > > Yes, x220 > > > (bios: LENOVO version "8DET69WW (1.39 )" date 07/18/2013) > > > (cpu: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz) > > > > > > I took some measurements to before starting the test. > > > > > > note: the laptop has been up for a few days with apm -A set via > > > rc.conf.local > > > and sysctl kern.timecounter.hardware as tsc via sysctl.conf and mostly > > > idle. > > > > > > cat /var/db/ntpd.drift > > > 6.459 > > > > > > apm -v > > > Battery state: high, 100% remaining, unknown life estimate > > > A/C adapter state: connected > > > Performance adjustment mode: auto (800 MHz) > > > > > > 6 hours ago i ran apm -L, verified it was running slowly (800 MHz), > > > and got the following results > > > > > > The clock appears correct (comparing to other computers) > > > > > > apm -v > > > Battery state: high, 100% remaining, unknown life estimate > > > A/C adapter state: connected > > > Performance adjustment mode: manual (800 MHz) > > > > > > cat /var/db/ntpd.drift > > > 6.385 > > > > > > ntpctl -s all > > > 4/4 peers valid, constraint offset 0s, clock synced, stratum 4 > > > > > > peer > > >wt tl st next poll offset delay jitter > > > 203.23.237.200 from pool pool.ntp.org > > > 1 10 2 153s 1505s -25.546ms73.450ms 2.644ms > > > 203.114.73.24 from pool pool.ntp.org > > > 1 10 2 253s 1560s-1.042ms75.133ms 0.752ms > > > 192.189.54.33 from pool pool.ntp.org > > > * 1 10 2 204s 1558s31.644ms70.910ms 3.388ms > > > 54.252.165.245 from pool pool.ntp.org > > > 1 10 2 238s 1518s 0.146ms73.005ms 2.025ms > > > > > > I will leave the laptop in lower power mode over the weekend and see > > > what happens. > > > > > > > No need, I think you've convinced me that it works :) > > But does it actually work on x230 as well? I'm surprised to learn > that you've observed TSC frequency change on Ivy Bridge. I was > under impression that everything since at least Sandy Bridge (x220) > has constant and invariant TSC as advertised. > > Adam, I've readjusted and simplified your diff a bit. The biggest > change is that we can select the reference tc based on it's quality > so there's no need to have acpitimer and acpihpet specific functions > and variables. > > There's one big thing missing here: increasing the timecounter > quality so that OS can pick it. Something like this: > > https://github.com/mbelop/src/commit/99d6ef3ae95bbd8ea93c27e0425eb65e5a3359a1 > > I'd say we should try getting this in after 6.3 unlock unless there > are objections. Further cleanup and testing is welcome of course. > > I'd like to raise another point: as we figured out, the TSC frequency can be different than the CPU frequency on modern Intel CPUs. The const+invar TSC can even run faster than the CPU. For example, my X1 4th Gen currently boots up with the following speeds: cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2808.00 MHz ... cpu0: Enhanced SpeedStep 2808 MHz: speeds: 2701, 2700, 2600, 2500, 2300, 2100, 1900, 1800, 1600, 1400, 1300, 1100, 800, 700, 600, 400 MHz The 2.8GHz is actual
Re: softraid: vnode leaks?
On Wed, Sep 13, 2017 at 08:36:10PM -0700, Philip Guenther wrote: > On Wed, 13 Sep 2017, Patrick Wildt wrote: > > I think softraid is leaking vnodes. When taking a device offline with > > bioctl -O /dev/sd0a sd2, then wiping the disk with dd (including the > > disklabel), I cannot change sd0's disklabel as it would say "open part- > > ition would change/shrink". This is because on assembly (and rebuild) > > the device is VOP_OPEN()d, but never closed. > > > > With this diff, whenever a disk goes offline (I/O error or bioctl -O), > > we actively close the vnode. One thing I wonder is, this still works > > when the backing device has already detached (USB drive being pulled). > > The logic of this idea makes sense to me, though I cannot confirm the > placement of these bits. Joel? > > I will note that the exact same chunk of non-trivial code in four > different places certainly calls for a function. Indeed, if the inside of > the 'if' was a function ("sr_entry_close"?), that could be reused in > sr_chunks_unwind()...and the XXX comment there moves to this new function. > > > Philip Guenther > Yep, agreed, that calls for a function. Especially since that piece was copied from sr_chunks_unwind() and is now used a few times. Will send a new diff with that changed as soon as Joel commented on this as well. Thanks, Patrick