Re: request for testing: rbootd timeout fix
On Thu, Apr 14, 2016 at 3:15 PM, Martin Natano wrote: > In rbootd a struct bpf_timeval (with 32bit tv_sec) is copied to a struct > timeval (with 64 tv_sec) via bcopy(). This most likely causes > connections to not time out correctly in rbootd. I don't have an HP > machine to test this with. Who owns such a machine and is willing to > test this? The current code is simply wrong: sizeof(struct timeval) > sizeof(struct bpf_timeval). I think we should make this change (ok guenther@) and then work to update struct bpf_hdr or a replacement thereof to not be limited to 32bit time_t values. Maybe it should be using a timespec instead too? Have any other free OSes added timespec (or bintime) APIs? (BPF has been around since 1990; the time from then to now is less than the time from now to 2038 when 32bit time_t fails...) Philip Guenther
Re: inteldrm diff that requires testing
On Fri, Apr 15, 2016 at 8:01 AM, Mark Kettenis wrote: > The diff below makes the HDMI output on Intel Bay Trail machines work. > Very useful for machines like the Lenovo Ideacentre Stick 300. But > this needs to be tested on other hardware as well. Especially on > machines with external displays. No change of behavior (AFAICT) on my Lenovo Yoga12, whether docked (w/DVI monitor) or undocked. Philip Guenther
Re: librthread: don't change thread flags after fork()
Ping?
Is no one using the GNUstep port?
On Sun, Apr 10, 2016 at 10:05 PM, Philip Guenther wrote:
>
> The libpthread fork() wrapper makes two changes to the flags for the
> process: it clears the 'detached' flag and sets the 'original' flag. I
> now believe those are both wrong and should be left as they are from the
> original process.
>
> For the 'detached' flag, the POSIX spec does *not* mention the detached
> state as changed by fork() and GNU libc doesn't change it across fork().
> A ping to the austin-group mailing list appears to confirm this reading. I
> apparently introduced this bug when I submitted the fork() wrapper before
> I was a committer; about time I fixed it!
>
> The 'original' flag just controls the result of the pthread_main_np()
> function. The description of that function isn't 100% clear: "identifies
> the main thread", ok, but where is "main thread" defined? We had
> interpreted it as meaning "the first thread in *this* process", and so
> would return 1 in the thread created by fork(). However it can also be
> interpreted as "this thread's call history traces back to main()", which
> is true of the child of fork() iff it was true in the parent, and is what
> the THREAD_INITIAL_STACK flag already conveys. So I looked at the ports
> tree and the only code that I can see using pthread_main_np() is
> x11/gnustep/base where the latter semantic appears to be the desired
> behavior. This diff thus eliminates the separate THREAD_ORIGINAL flag and
> change pthread_main_np() to test THREAD_INITIAL_STACK.
>
> So, any GNUstep users who can test this?
>
> oks?
>
>
> Philip Guenther
>
>
> Index: rthread.c
> ===
> RCS file: /data/src/openbsd/src/lib/librthread/rthread.c,v
> retrieving revision 1.90
> diff -u -p -r1.90 rthread.c
> --- rthread.c 2 Apr 2016 19:56:53 - 1.90
> +++ rthread.c 11 Apr 2016 04:37:28 -
> @@ -193,7 +193,7 @@ _rthread_init(void)
> thread->tid = getthrid();
> thread->donesem.lock = _SPINLOCK_UNLOCKED_ASSIGN;
> thread->flags |= THREAD_CANCEL_ENABLE | THREAD_CANCEL_DEFERRED |
> - THREAD_ORIGINAL | THREAD_INITIAL_STACK;
> + THREAD_INITIAL_STACK;
> thread->flags_lock = _SPINLOCK_UNLOCKED_ASSIGN;
> strlcpy(thread->name, "Main process", sizeof(thread->name));
> LIST_INSERT_HEAD(&_thread_list, thread, threads);
> Index: rthread.h
> ===
> RCS file: /data/src/openbsd/src/lib/librthread/rthread.h,v
> retrieving revision 1.56
> diff -u -p -r1.56 rthread.h
> --- rthread.h 2 Apr 2016 19:00:51 - 1.56
> +++ rthread.h 11 Apr 2016 04:37:39 -
> @@ -189,7 +189,6 @@ struct pthread {
> #defineTHREAD_CANCEL_DEFERRED 0x010
> #defineTHREAD_CANCEL_DELAY 0x020
> #defineTHREAD_DYING0x040
> -#defineTHREAD_ORIGINAL 0x080 /* original thread from fork
> */
> #defineTHREAD_INITIAL_STACK0x100 /* thread with stack from
> exec */
>
> #defineIS_CANCELED(thread) \
> Index: rthread_fork.c
> ===
> RCS file: /data/src/openbsd/src/lib/librthread/rthread_fork.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 rthread_fork.c
> --- rthread_fork.c 2 Apr 2016 19:00:51 - 1.16
> +++ rthread_fork.c 11 Apr 2016 04:31:13 -
> @@ -99,11 +99,7 @@ _dofork(int is_vfork)
> /* update this thread's structure */
> me->tid = getthrid();
> me->donesem.lock = _SPINLOCK_UNLOCKED_ASSIGN;
> - me->flags &= ~THREAD_DETACHED;
> me->flags_lock = _SPINLOCK_UNLOCKED_ASSIGN;
> -
> - /* this thread is the initial thread for the new process */
> - me->flags |= THREAD_ORIGINAL;
>
> /* reinit the thread list */
> LIST_INIT(&_thread_list);
> Index: rthread_np.c
> ===
> mRCS file: /data/src/openbsd/src/lib/librthread/rthread_np.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 rthread_np.c
> --- rthread_np.c2 Apr 2016 19:00:51 - 1.18
> +++ rthread_np.c11 Apr 2016 04:38:09 -
> @@ -47,8 +47,8 @@ pthread_set_name_np(pthread_t thread, co
> int
> pthread_main_np(void)
> {
> - return (!_threads_ready || (pthread_self()->flags & THREAD_ORIGINAL)
> - ? 1 : 0);
> + return (!_threads_ready ||
> + (pthread_self()->flags & THREAD_INITIAL_STACK) ? 1 : 0);
> }
>
>
Re: better rm / diff
Todd C. Miller wrote: > On Fri, 15 Apr 2016 14:04:20 -0400, "Ted Unangst" wrote: > > > I think this is a more reliable way of detecting rm -rf /. > > Previous effort was reverted due to false positives. > > I think it makes more sense to just check st_dev and st_ino. > Otherwise there is a race that can cause the check to fail due to > things like the timestamp changing. right, got lazy. fixed.
smu(4) fan speed
Yesterday I've installed macppc -current on a G5.
Since OF_getprop() for the 'unmanage-value' parameter fails on it,
smu(4) sets the fan speed to 'max-value' instead, which is 3200RPM
in my case. This makes the G5 sound louder than my vacuum cleaner.
First I thought 'unmanage-value' is a typo and it should be
'unmanaged-value' like in the FreeBSD driver, but unfortunately it
still did fail. I saw that the FreeBSD driver doesn't set the fan
speed at all initially in their driver. When I do the same on the
G5, the fan speed goes to a decent of ~1000RPM:
hw.sensors.smu0.fan0=999 RPM (Rear Fan 0)
hw.sensors.smu0.fan1=999 RPM (Rear fan 1)
hw.sensors.smu0.fan2=999 RPM (Front Fan)
I don't know what the right way is to fix this, but skipping to set
the fan speed when the 'unmanage-value' isn't available seems to work
fine in this case.
Index: sys/arch/macppc/dev/smu.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/smu.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 smu.c
--- sys/arch/macppc/dev/smu.c 4 Jun 2015 18:01:44 - 1.27
+++ sys/arch/macppc/dev/smu.c 15 Apr 2016 18:17:12 -
@@ -281,15 +281,17 @@ smu_attach(struct device *parent, struct
val = 0x;
fan->max_rpm = val;
if (OF_getprop(node, "unmanage-value", &val, sizeof val) <= 0)
- val = fan->max_rpm;
+ val = 0;
fan->unmanaged_rpm = val;
if (OF_getprop(node, "location", loc, sizeof loc) <= 0)
strlcpy(loc, "Unknown", sizeof loc);
strlcpy(fan->sensor.desc, loc, sizeof sensor->sensor.desc);
- /* Start running fans at their "unmanaged" speed. */
- smu_fan_set_rpm(sc, fan, fan->unmanaged_rpm);
+ if (fan->unmanaged_rpm) {
+ /* Start running fans at their "unmanaged" speed. */
+ smu_fan_set_rpm(sc, fan, fan->unmanaged_rpm);
+ }
#ifndef SMALL_KERNEL
sensor_attach(&sc->sc_sensordev, &fan->sensor);
Re: better rm / diff
On Fri, 15 Apr 2016 14:04:20 -0400, "Ted Unangst" wrote: > I think this is a more reliable way of detecting rm -rf /. > Previous effort was reverted due to false positives. I think it makes more sense to just check st_dev and st_ino. Otherwise there is a race that can cause the check to fail due to things like the timestamp changing. - todd
better rm / diff
I think this is a more reliable way of detecting rm -rf /. Previous effort was
reverted due to false positives.
Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.36
diff -u -p -r1.36 rm.c
--- rm.c1 Feb 2016 22:34:19 - 1.36
+++ rm.c15 Apr 2016 17:59:35 -
@@ -395,9 +395,17 @@ checkdot(char **argv)
{
char *p, **save, **t;
int complained;
+ struct stat sb, root;
+ stat("/", &root);
complained = 0;
for (t = argv; *t;) {
+ if (lstat(*t, &sb) == 0 &&
+ memcmp(&root, &sb, sizeof(struct stat)) == 0) {
+ if (!complained++)
+ warnx("\"/\" may not be removed");
+ goto skip;
+ }
/* strip trailing slashes */
p = strrchr(*t, '\0');
while (--p > *t && *p == '/')
@@ -412,6 +420,7 @@ checkdot(char **argv)
if (ISDOT(p)) {
if (!complained++)
warnx("\".\" and \"..\" may not be removed");
+skip:
eval = 1;
for (save = t; (t[0] = t[1]) != NULL; ++t)
continue;
intro.2 mention of pledge(2)
Does this make sense? Rob Index: intro.2 === RCS file: /cvs/src/lib/libc/sys/intro.2,v retrieving revision 1.63 diff -u -p -r1.63 intro.2 --- intro.2 6 Mar 2016 22:32:09 - 1.63 +++ intro.2 15 Apr 2016 16:26:24 - @@ -42,6 +42,9 @@ .Sh DESCRIPTION The manual pages in section 2 provide an overview of the system calls, their error returns, and other common definitions and concepts. +.Pp +Programs may be restricted to a subset of system calls with +.Xr pledge 2 . .\".Pp .\".Sy System call restart .\".Pp @@ -725,6 +728,7 @@ Each socket has an address chosen from t socket was created. .El .Sh SEE ALSO +.Xr pledge 2 , .Xr intro 3 , .Xr perror 3 .Sh HISTORY
inteldrm diff that requires testing
The diff below makes the HDMI output on Intel Bay Trail machines work. Very useful for machines like the Lenovo Ideacentre Stick 300. But this needs to be tested on other hardware as well. Especially on machines with external displays. Index: intel_i2c.c === RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_i2c.c,v retrieving revision 1.7 diff -u -p -r1.7 intel_i2c.c --- intel_i2c.c 26 Sep 2015 22:00:00 - 1.7 +++ intel_i2c.c 15 Apr 2016 14:58:13 - @@ -144,6 +144,8 @@ intel_gmbus_acquire_bus(void *cookie, in struct intel_gmbus *bus = cookie; struct inteldrm_softc *dev_priv = bus->dev_priv; + intel_aux_display_runtime_get(dev_priv); + I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, bus->reg0); return (0); @@ -156,6 +158,8 @@ intel_gmbus_release_bus(void *cookie, in struct inteldrm_softc *dev_priv = bus->dev_priv; I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0); + + intel_aux_display_runtime_put(dev_priv); } int @@ -371,8 +375,12 @@ intel_setup_gmbus(struct drm_device *dev struct drm_i915_private *dev_priv = dev->dev_private; int i; - if (HAS_PCH_SPLIT(dev)) + if (HAS_PCH_NOP(dev)) + return 0; + else if (HAS_PCH_SPLIT(dev)) dev_priv->gpio_mmio_base = PCH_GPIOA - GPIOA; + else if (IS_VALLEYVIEW(dev)) + dev_priv->gpio_mmio_base = VLV_DISPLAY_BASE; else dev_priv->gpio_mmio_base = 0; @@ -399,6 +407,8 @@ intel_setup_gmbus(struct drm_device *dev bus->controller.ic_read_byte = intel_gpio_read_byte; bus->controller.ic_write_byte = intel_gpio_write_byte; } + + intel_i2c_reset(dev_priv->dev); return (0); }
Re: less handrolled mbuf freeing code in uipc_mbuf.c
On 15 April 2016 at 07:35, David Gwynne wrote: > m_freem checks for NULL so the caller doesnt have to. > > ml_purge and m_purge were invented after some of the mq and ml code > was written, so fix that code to use the "new" functions. > > ok? > OK mikeb
Re: httpd: $DOCUMENT_URI macro fix for FastCGI
On 2016-04-14 Tim Baumgard wrote: > > Christopher Zimmermann wrote: > > Tim Baumgard wrote: > >> According to convention and httpd.conf(5), the $DOCUMENT_URI macro > >> for FastCGI calls should expand to the request path instead of the > >> path alias. > > > > FastCGI / CGI is poorly documented. As far as convention goes, at > > least nginx uses the rewritten url, too: > > > > $document_uri > >same as $uri > > > > $uri > >current URI in request, normalized > > > >The value of $uri may change during request processing, e.g. when > >doing internal redirects, or when using index files. > > > > This behavior has the effect that the CGI script will know the > > "canonical" url of the requested ressource, not an alias that the > > client happened to request. We call the rewritten, canonical url > > "alias" in our code, so that might be confusing. > > Indeed, nginx works as you described. Also, it appears lighttpd works > in a similar way. > > "Convention" was a bad word choice. I meant that it's what Apache and > many implementations of SSI do. It's also what I was finding when > searching using queries along the lines of "CGI DOCUMENT_URI", which I > was doing because the CGI RFC doesn't include DOCUMENT_URI. > > The current behavior is redundant since SCRIPT_NAME, which is in the > RFC, and DOCUMENT_URI are always set to the same thing. That's not always the case. DOCUMENT_URI is SCRIPT_NAME ^ PATH_INFO. If you want the original URI, you can always use REQUEST_URI and strip the query string, which is easy to do. > Also, the man > page says that the $DOCUMENT_URI macro is "the request path" and the > $REQUEST_URI macro is "the request path and optional query string." I > suppose it's OK to use different meanings for the same term in these > two different places since they're serving different purposes, but > it's a little misleading. > > Anyway, while I now think the current behavior is probably best in > terms of the semantics of "DOCUMENT_URI," the point I just tried to > make with my drawn-out explanation is that it's pretty easy to come > to the same incorrect conclusion that I did. CGI variables are poorly documented, not really standardised and confusing. > So, instead of > considering what I sent previously, here's a diff for the > httpd.conf(5) man page that adds a list of the variables (and their > descriptions) that are given to the FastCGI handler. Making the > behavior for these values explicit should avoid any similar > confusion, and I'm sure it would be helpful in other ways as well. Thanks for the effort. This will indeed be helpfull for many users. > > Index: httpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v > retrieving revision 1.68 > diff -u -p -r1.68 httpd.conf.5 > --- httpd.conf.5 19 Jul 2015 05:17:27 - 1.68 > +++ httpd.conf.5 15 Apr 2016 00:55:25 - > @@ -274,6 +274,59 @@ root directory of > .Xr httpd 8 > and defaults to > .Pa /run/slowcgi.sock . > +.Pp > +The FastCGI handler will be given the following variables: > +.Pp > +.Bl -tag -width GATEWAY_INTERFACE -offset indent -compact > +.It Ic DOCUMENT_ROOT > +The document root in which the script is located as configured by the > +.Ic root > +option for the server or location that matches the request. > +.It Ic DOCUMENT_URI > +The URI path to the script. Rather the canonicalised URI, possibly with '/' and/or index appended. NOT necessarily the path to the script; neither virtual nor physical (see above). > +.It Ic GATEWAY_INTERFACE > +The revision of the CGI specification used. > +.It Ic HTTP_* > +Additional HTTP headers the connected client sent in the request, if > +any. > +.It Ic HTTPS > +A variable that is set to > +.Qq on > +when the server has been configured to use TLS. This variable is not > +given otherwise. Put REQUEST_PATH, DOCUMENT_URI, SCRIPT_NAME, PATH_INFO and SCRIPT_FILENAME here, they are best understood in context of each other. > +.It Ic PATH_INFO > +The optional path appended after the script name in the request path. > +This variable is empty if no path is appended after the script name. > +.It Ic QUERY_STRING > +The optional query string of the request. > +.It Ic REMOTE_ADDR > +The IP address of the connected client. > +.It Ic REMOTE_PORT > +The TCP source port of the connected client > +.It Ic REMOTE_USER > +The remote user when using HTTP authentication. > +.It Ic REQUEST_METHOD > +The HTTP method the connected client used when making the request. > +.It Ic REQUEST_URI > +The request path and optional query string. The _original_ request path. > +.It Ic SCRIPT_FILENAME > +The absolute path to the script within the > +.Xr chroot 2 > +directory. Maybe add "physical path" ? > +.It Ic SCRIPT_NAME > +The URI path to the script. The RFC calls this "virtual". > +.It Ic SERVER_ADDR > +The configured IP address of the server. > +.It Ic SERVER_NAME > +The name of the se
Re: Any reason there's no way to persist pledge(2) state across exec?
>What's the use for this? What program could use it? EXACTLY. Any proposal like yours requires a justification, so SHOW a program which needs it right now. At least show one. >On Sun, Apr 10, 2016 at 08:48:08AM -0700, Brennan Vincent wrote: >> Subject basically says it all. I think some could find it useful to have >> `pledge` promises optionally persist even after the process calls >> execve. This could, for example, be implemented with an `exec_noreset` >> pledge that gives access to the same syscalls as `exec`, but with this >> restricted behavior. >> >> Is there a good technically reason this can't or shouldn't be done, or >> has it simply not been implemented yet? >> > >
Re: Pledge error handling
>I noticed there are (at least 2) diferent ways to handle a pledge error (eg=
>: /usr/src/usr.bin/):
>If (pledge(args, NULL) =3D=3D -1)
>. err(1, "pledge"); (wc; w; ..)
>. perror("pledge"); exit(EXIT_CODE); (vi; openssl; ...)
>
>I am not familiar with the case of use of each function but perror + exit i=
>snt the same as err ?
>Can we use just one function (either error or perror) to handle pledge
>I've also seen the use of fatal(...) I guess this might be another mechanis=
>m which is useful.
We use the style of the existing code.
