Re: possibility to disable relink in conf

[sven falempin]

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

[sven falempin]

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

[Bryan Steele]

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 = 
> - 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

[Reyk Floeter]

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 

Re: softraid: vnode leaks?

[Patrick Wildt]

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

perl 5.24.3 update (RC1 for testing)

[Andrew Fresh]

I know it's getting close to lock, but there's a minor perl update on
the horizon that I think would be nice to have in for 6.2 so I thought
I'd send out the RC1 to gather feedback in hopes that it will make it.

I am not quite sure when the actual release of 5.24.3 will be, but
usually it is about a week after the last RC, so I would expect sometime
next week unless they find a need for another one.


The perl changes are described in the perldelta:
(I'd list them here, but it's surprisingly long)
https://metacpan.org/pod/release/SHAY/perl-5.24.3-RC1/pod/perldelta.pod


A patch you should be able to apply to -current is here:
http://cvs.afresh1.com/~andrew/perl-update/OpenBSD-perl-5.24.3-RC1.patch

Or, you can download the pre-patched files
(which includes some extra perldeltas and tests that I didn't cvs add)
http://cvs.afresh1.com/~andrew/perl-update/OpenBSD-perl-5.24.3-RC1.tar.gz

Or, of course, you can build your own version with what is on github:
https://github.com/afresh1/OpenBSD-perl/


I will be on the Oregon coast in a tent this weekend, so while I will
bring my laptop, I doubt it will get much use or have much Internet.

l8rZ,
-- 
andrew - http://afresh1.com

People who invent random theories which only defend the vendor must have
been beaten as children.  Beaten with sticks.
At least, that's my theory.
  -- Theo De Raadt