acpivout(4): directly call ws_[gs]et_param
Hi,
this is the second attempt of a diff that prepares acpivout(4) to work
with the X395. The previous one broke due to recursive ACPI locking.
So apparently we cannot change the brightness using the acpivout(4) ACPI
methods. Instead we need to call amdgpu(4) to change the brightness.
But the brightness key events are still reported by acpivout(4). That
means that we need to seperate the keystroke events from the actual
brightness change.
This diff changes the code to always use ws_[gs]et_param instead of just
calling the ACPI methods. This means that the function pointers can
point to acpivout(4) or amdgpu(4), it shouldn't matter.
Unfortunately there's an issue with acpivout(4) calling itself. The
keystroke event handler runs with the ACPI lock, so if we call our own
function, we try to grab the ACPI lock again and panic. So, in this
diff I check whether we already have it and skip taking it again.
I'm sure this looks ugly, and I'm wondering if it's too ugly. If it is
indeed too ugly, I hope you'll also provide another idea how we can work
around it.
More testing would be appreciated.
Thanks,
Patrick
diff --git a/sys/dev/acpi/acpivout.c b/sys/dev/acpi/acpivout.c
index 58e8e3d431c..f3de0c582fb 100644
--- a/sys/dev/acpi/acpivout.c
+++ b/sys/dev/acpi/acpivout.c
@@ -66,6 +66,7 @@ void acpivout_brightness_cycle(struct acpivout_softc *);
void acpivout_brightness_step(struct acpivout_softc *, int);
void acpivout_brightness_zero(struct acpivout_softc *);
intacpivout_get_brightness(struct acpivout_softc *);
+intacpivout_select_brightness(struct acpivout_softc *, int);
intacpivout_find_brightness(struct acpivout_softc *, int);
void acpivout_set_brightness(struct acpivout_softc *, int);
void acpivout_get_bcl(struct acpivout_softc *);
@@ -124,6 +125,9 @@ acpivout_notify(struct aml_node *node, int notify, void
*arg)
{
struct acpivout_softc *sc = arg;
+ if (ws_get_param == NULL || ws_set_param == NULL)
+ return (0);
+
switch (notify) {
case NOTIFY_BRIGHTNESS_CYCLE:
acpivout_brightness_cycle(sc);
@@ -151,12 +155,13 @@ acpivout_notify(struct aml_node *node, int notify, void
*arg)
void
acpivout_brightness_cycle(struct acpivout_softc *sc)
{
- int cur_level;
+ struct wsdisplay_param dp;
- if (sc->sc_bcl_len == 0)
+ dp.param = WSDISPLAYIO_PARAM_BRIGHTNESS;
+ if (ws_get_param(&dp))
return;
- cur_level = acpivout_get_brightness(sc);
- if (cur_level == sc->sc_bcl[sc->sc_bcl_len - 1])
+
+ if (dp.curval == dp.max)
acpivout_brightness_zero(sc);
else
acpivout_brightness_step(sc, 1);
@@ -165,33 +170,45 @@ acpivout_brightness_cycle(struct acpivout_softc *sc)
void
acpivout_brightness_step(struct acpivout_softc *sc, int dir)
{
- int level, nindex;
+ struct wsdisplay_param dp;
+ int delta, new;
- if (sc->sc_bcl_len == 0)
- return;
- level = acpivout_get_brightness(sc);
- if (level == -1)
+ dp.param = WSDISPLAYIO_PARAM_BRIGHTNESS;
+ if (ws_get_param(&dp))
return;
- nindex = acpivout_find_brightness(sc, level + (dir * BRIGHTNESS_STEP));
- if (sc->sc_bcl[nindex] == level) {
- if (dir == 1 && (nindex + 1 < sc->sc_bcl_len))
- nindex++;
- else if (dir == -1 && (nindex - 1 >= 0))
- nindex--;
+ new = dp.curval;
+ delta = ((dp.max - dp.min) * BRIGHTNESS_STEP) / 100;
+ if (dir > 0) {
+ if (delta > dp.max - dp.curval)
+ new = dp.max;
+ else
+ new += delta;
+ } else if (dir < 0) {
+ if (delta > dp.curval - dp.min)
+ new = dp.min;
+ else
+ new -= delta;
}
- if (sc->sc_bcl[nindex] == level)
+
+ if (dp.curval == new)
return;
- acpivout_set_brightness(sc, sc->sc_bcl[nindex]);
+ dp.curval = new;
+ ws_set_param(&dp);
}
void
acpivout_brightness_zero(struct acpivout_softc *sc)
{
- if (sc->sc_bcl_len == 0)
+ struct wsdisplay_param dp;
+
+ dp.param = WSDISPLAYIO_PARAM_BRIGHTNESS;
+ if (ws_get_param(&dp))
return;
- acpivout_set_brightness(sc, sc->sc_bcl[0]);
+
+ dp.curval = dp.min;
+ ws_set_param(&dp);
}
int
@@ -211,6 +228,26 @@ acpivout_get_brightness(struct acpivout_softc *sc)
return (level);
}
+int
+acpivout_select_brightness(struct acpivout_softc *sc, int nlevel)
+{
+ int nindex, level;
+
+ level = acpivout_get_brightness(sc);
+ if (level == -1)
+ return level;
+
+ nindex = acpivout_find_brightness(sc, nlevel);
+ if (sc->sc_bcl[nindex] == level) {
+ if (nlevel > level && (nindex + 1 < sc->sc_bcl_len))
+
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Thu, Jan 23, 2020 at 02:36:43PM +1100, Damien Miller wrote: > On Wed, 22 Jan 2020, Stuart Henderson wrote: > > > On 2020/01/21 15:39, Damien Miller wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > > > Modified files: > > > usr.bin/ssh: sshd.c > > > > > > Log message: > > > expose the number of currently-authenticating connections > > > along with the MaxStartups limit in the proctitle; > > > suggestion from Philipp Marek, w/ feedback from Craig Miskell > > > ok dtucker@ > > > > > > > It's nice to have this information visible, but it brings some problems. > > You can't now distinguish between multiple sshd processes (e.g. if you > > run several on different ports it's hard to figure out which one to > > signal if needed). > > How could you discern between different sshd processes before? Just the > command-line args? Yes. e.g. for 2 different sshd running: root 92105 0.0 0.0 1360 1296 ?? I Wed07AM0:00.05 /usr/sbin/sshd root 68236 0.0 0.0 1372 1364 ?? S 7:08AM0:00.00 /usr/sbin/sshd -f /etc/ssh/sshd_config2 > What information would you like there? We could put the first N listen > addrs in the proctitle if that would help. Can't we put the args back and append the new things we expose? That will also be easier to know which currently-authenticating / MaxStartups sshd process we are talking about if we run several. proctitle bit us in the arse several times in the past with rc.d. My 2 cents, maybe I am talking garbage. -- Antoine
Re: bgpd max-prefix out limit
On Wed, Jan 22, 2020 at 05:02:32AM +0100, Claudio Jeker wrote: > This diff implements 'max-prefix NUM out' which is a simple way to > avoid leaking full tables to upstream or peers. If the limit is > triggered the session will be closed with a NOTIFICATION (kind of > suicide for the good of the Internet). > > In bgpctl the counters are visible in the 'bgpctl show nei' output. > > Works for me (adopting the maxprefix regress test to test for > 'max-prefix NUM out'. This is an implementation of https://tools.ietf.org/html/draft-sa-idr-maxprefix-00 OK job@
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Thu, 23 Jan 2020, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
>
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > >
> > > Modified files:
> > > usr.bin/ssh: sshd.c
> > >
> > > Log message:
> > > expose the number of currently-authenticating connections
> > > along with the MaxStartups limit in the proctitle;
> > > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > > ok dtucker@
> > >
> >
> > It's nice to have this information visible, but it brings some problems.
> > You can't now distinguish between multiple sshd processes (e.g. if you
> > run several on different ports it's hard to figure out which one to
> > signal if needed).
>
> How could you discern between different sshd processes before? Just the
> command-line args?
>
> What information would you like there? We could put the first N listen
> addrs in the proctitle if that would help.
Maybe like this:
63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 10-100
ok?
diff --git a/sshd.c b/sshd.c
index ec644c9..15014d1 100644
--- a/sshd.c
+++ b/sshd.c
@@ -240,6 +240,9 @@ void destroy_sensitive_data(void);
void demote_sensitive_data(void);
static void do_ssh2_kex(struct ssh *);
+/* Listen info for proctitle */
+static char *proctitle_listen_addr;
+
/*
* Close all listening sockets
*/
@@ -913,7 +916,7 @@ listen_on_addrs(struct listenaddr *la)
{
int ret, listen_sock;
struct addrinfo *ai;
- char ntop[NI_MAXHOST], strport[NI_MAXSERV];
+ char *cp, ntop[NI_MAXHOST], strport[NI_MAXSERV];
for (ai = la->addrs; ai; ai = ai->ai_next) {
if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6)
@@ -973,6 +976,15 @@ listen_on_addrs(struct listenaddr *la)
ntop, strport,
la->rdomain == NULL ? "" : " rdomain ",
la->rdomain == NULL ? "" : la->rdomain);
+ if (num_listen_socks < 3) {
+ cp = proctitle_listen_addr;
+ xasprintf(&proctitle_listen_addr, "%s%s[%s]:%s%s%s",
+ cp == NULL ? "" : cp, cp == NULL ? "" : ", ",
+ ntop, strport,
+ la->rdomain == NULL ? "" : " rdomain ",
+ la->rdomain == NULL ? "" : la->rdomain);
+ free(cp);
+ }
}
}
@@ -1030,7 +1042,9 @@ server_accept_loop(int *sock_in, int *sock_out, int
*newsock, int *config_s)
*/
for (;;) {
if (ostartups != startups) {
- setproctitle("[listener] %d of %d-%d startups",
+ setproctitle("[listen] on %s%s, "
+ "%d of %d-%d startups", proctitle_listen_addr,
+ num_listen_socks > 3 ? " [...]" : "",
startups, options.max_startups_begin,
options.max_startups);
ostartups = startups;
exit status of isakmpd(8)
ok?
When isakmpd's main process dies abnormally, currently its "monitor"
process exits with status 0. Fix it to use the exit status of main
process.
Index: sbin/isakmpd/monitor.c
===
RCS file: /var/cvs/openbsd/src/sbin/isakmpd/monitor.c,v
retrieving revision 1.80
diff -u -p -r1.80 monitor.c
--- sbin/isakmpd/monitor.c 19 Dec 2019 19:09:53 - 1.80
+++ sbin/isakmpd/monitor.c 23 Jan 2020 03:54:35 -
@@ -146,7 +146,7 @@ monitor_init(int debug)
void
monitor_exit(int code)
{
- int status;
+ int status = 0, gotstatus = 0;
pid_t pid;
if (m_state.pid != 0) {
@@ -156,6 +156,8 @@ monitor_exit(int code)
do {
pid = waitpid(m_state.pid, &status, 0);
} while (pid == -1 && errno == EINTR);
+ if (pid != -1)
+ gotstatus = 1;
/* Remove FIFO and pid files. */
unlink(ui_fifo);
@@ -163,7 +165,10 @@ monitor_exit(int code)
}
close(m_state.s);
- exit(code);
+ if (code == 0 && gotstatus)
+ exit(WIFEXITED(status)? WEXITSTATUS(status) : 1);
+ else
+ exit(code);
}
int
Re: amdgpu (and possible radeondrm) fix
On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote: > The attached diff fixes amdgpu(4) and might very well fix radeondrm(4) > as well. [...] For the record, this fixes running piglit with radeon on my HD7570 since this was committed. It used to lock up on the test spec/arb_sync/sync_api, but now piglit completes. I haven't done further investigations how that may be related, but though it may be good to know that this means progress with the piglit testing suite. -- tfrohw...@fastmail.com PGP Public Key: https://pgp.mit.edu/pks/lookup?op=get&search=0xE1A22D58D20C6D22
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Wed, 22 Jan 2020, Stuart Henderson wrote: > On 2020/01/21 15:39, Damien Miller wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > Modified files: > > usr.bin/ssh: sshd.c > > > > Log message: > > expose the number of currently-authenticating connections > > along with the MaxStartups limit in the proctitle; > > suggestion from Philipp Marek, w/ feedback from Craig Miskell > > ok dtucker@ > > > > It's nice to have this information visible, but it brings some problems. > You can't now distinguish between multiple sshd processes (e.g. if you > run several on different ports it's hard to figure out which one to > signal if needed). How could you discern between different sshd processes before? Just the command-line args? What information would you like there? We could put the first N listen addrs in the proctitle if that would help. -d
hyperv(4): tsleep(9) -> tsleep_nsec(9)
Sleep for the same duration as the delay(9) in the cold path.
ok?
Index: pv/hyperv.c
===
RCS file: /cvs/src/sys/dev/pv/hyperv.c,v
retrieving revision 1.44
diff -u -p -r1.44 hyperv.c
--- pv/hyperv.c 7 Oct 2019 15:36:01 - 1.44
+++ pv/hyperv.c 23 Jan 2020 02:09:12 -
@@ -560,8 +560,10 @@ hv_start(struct hv_softc *sc, struct hv_
s = splnet();
hv_intr();
splx(s);
- } else
- tsleep(wchan, PRIBIO, wchan, 1);
+ } else {
+ tsleep_nsec(wchan, PRIBIO, wchan,
+ USEC_TO_NSEC(delays[i]));
+ }
}
if (status != 0) {
printf("%s: posting vmbus message failed with %d\n",
@@ -622,8 +624,10 @@ hv_wait(struct hv_softc *sc, int (*cond)
s = splnet();
hv_intr();
splx(s);
- } else
- tsleep(wchan, PRIBIO, wmsg ? wmsg : "hvwait", 1);
+ } else {
+ tsleep_nsec(wchan, PRIBIO, wmsg ? wmsg : "hvwait",
+ USEC_TO_NSEC(1000));
+ }
}
}
Re: umb(4) WIP diff and questions
On Thu Jan 23, 2020 at 3:05 AM, Claudio Jeker wrote: > On Thu, Jan 23, 2020 at 10:48:06AM +0900, Lee B wrote: > > > > OK, the umb_softc part was straightforward enough, thanks. I'd like > > some advice on how to handle the ifconfig(8) changes to accomodate > > this though. I see the wifi code appears to use a separate ioctl pair > > to handle the authentication credentials (WPA/PSK). Is this the right > > way to go, or have I missed an easier solution? > > > > > No that is the best way. Create a new ioctl to set the data. You can > decide if you want to pass the data together ot split in two commands. I > think a single ioctl has benefits for the driver but is more annoying to > handle in ifconfig. > Great, thank you. I'll hopefully get some time to finish this over the weekend. Lee.
Re: umb(4) WIP diff and questions
On Thu, Jan 23, 2020 at 10:48:06AM +0900, Lee B wrote: > On Tue Jan 14, 2020 at 5:59 PM, Claudio Jeker wrote: > > > > Since the credentials should not be passed back to userland I would not > > add them to struct umb_parameter but instead to struct umb_softc. > > Then you don't need to use struct umb_parameter for the ioctl and > > instead > > could just pass the (utf16) string to the kernel. > > Apart form that it looks good. > > > > > > OK, the umb_softc part was straightforward enough, thanks. I'd like > some advice on how to handle the ifconfig(8) changes to accomodate > this though. I see the wifi code appears to use a separate ioctl pair > to handle the authentication credentials (WPA/PSK). Is this the right > way to go, or have I missed an easier solution? > No that is the best way. Create a new ioctl to set the data. You can decide if you want to pass the data together ot split in two commands. I think a single ioctl has benefits for the driver but is more annoying to handle in ifconfig. -- :wq Claudio
ihidev(4): tsleep(9) -> tsleep_nsec(9)
Ticks to milliseconds.
ok?
Index: i2c/ihidev.c
===
RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v
retrieving revision 1.21
diff -u -p -r1.21 ihidev.c
--- i2c/ihidev.c31 Jul 2019 16:09:12 - 1.21
+++ i2c/ihidev.c23 Jan 2020 02:00:25 -
@@ -74,8 +74,6 @@ int ihidev_maxrepid(void *buf, int len);
intihidev_print(void *aux, const char *pnp);
intihidev_submatch(struct device *parent, void *cf, void *aux);
-extern int hz;
-
struct cfattach ihidev_ca = {
sizeof(struct ihidev_softc),
ihidev_match,
@@ -264,15 +262,10 @@ ihidev_activate(struct device *self, int
void
ihidev_sleep(struct ihidev_softc *sc, int ms)
{
- int to = ms * hz / 1000;
-
if (cold)
delay(ms * 1000);
- else {
- if (to <= 0)
- to = 1;
- tsleep(&sc, PWAIT, "ihidev", to);
- }
+ else
+ tsleep_nsec(&sc, PWAIT, "ihidev", MSEC_TO_NSEC(ms));
}
int
Re: umb(4) WIP diff and questions
On Tue Jan 14, 2020 at 5:59 PM, Claudio Jeker wrote: > > Since the credentials should not be passed back to userland I would not > add them to struct umb_parameter but instead to struct umb_softc. > Then you don't need to use struct umb_parameter for the ioctl and > instead > could just pass the (utf16) string to the kernel. > Apart form that it looks good. > > OK, the umb_softc part was straightforward enough, thanks. I'd like some advice on how to handle the ifconfig(8) changes to accomodate this though. I see the wifi code appears to use a separate ioctl pair to handle the authentication credentials (WPA/PSK). Is this the right way to go, or have I missed an easier solution? Lee.
Re: [Patch]: Integrate VA-API into xenocara
On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote: > This is a rather large patch that moves my previously submitted > VA-API ports into xenocara. For your convenience, I've inlined > a diff that shows you all of the changes I made to existing files > that you can easily read in your MUA. The attached patch also > contains these changes and should be the only xenocara patch > you need to apply. > > Summary of Changes: > - libva added to xenocara/lib/libva > - vainfo added to xenocara/app/vainfo > - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver > - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag > - 3RDPARTY file updated to include libva, libva-utils, and intel-vaapi-driver > - BSD.x11.dist updated to include /usr/X11R6/include/va/ (separate patch) It is difficult to see where you have made changes, can you send patches against source from particular tarballs?
ciss(4): tsleep(9) -> tsleep_nsec(9)
Now that we've separated the sleeping path and the busy-waiting path
we can remove the ticks.
"i" is a count of milliseconds here. Convert it to a timespec to
get a starting interval "ts" and add that to the current time "now"
to get an absolute timeout "end".
Then we chip away at it as we loop through until the poll succeeds or
we reach "end".
An absolute timeout version of tsleep would be better here but we
don't have one yet, so this is the best we can do.
ok?
Index: ic/ciss.c
===
RCS file: /cvs/src/sys/dev/ic/ciss.c,v
retrieving revision 1.77
diff -u -p -r1.77 ciss.c
--- ic/ciss.c 23 Jan 2020 00:30:59 - 1.77
+++ ic/ciss.c 23 Jan 2020 00:50:30 -
@@ -442,13 +442,15 @@ cissminphys(struct buf *bp, struct scsi_
int
ciss_cmd(struct ciss_ccb *ccb, int flags, int wait)
{
+ struct timespec end, now, ts;
struct ciss_softc *sc = ccb->ccb_sc;
struct ciss_cmd *cmd = &ccb->ccb_cmd;
struct ciss_ccb *ccb1;
bus_dmamap_t dmap = ccb->ccb_dmamap;
u_int64_t addr;
+ uint64_t nsecs;
u_int32_t id;
- int i, tohz, error = 0;
+ int i, error = 0, ret;
splassert(IPL_BIO);
@@ -522,29 +524,27 @@ ciss_cmd(struct ciss_ccb *ccb, int flags
if (!(wait & SCSI_POLL))
return (error);
- struct timeval tv;
- int etick;
CISS_DPRINTF(CISS_D_CMD, ("waiting "));
i = ccb->ccb_xs? ccb->ccb_xs->timeout : 6;
- tv.tv_sec = i / 1000;
- tv.tv_usec = (i % 1000) * 1000;
- tohz = tvtohz(&tv);
- if (tohz == 0)
- tohz = 1;
if (!(wait & SCSI_NOSLEEP)) {
- for (etick = tick + tohz;;) {
+ NSEC_TO_TIMESPEC(MSEC_TO_NSEC(i), &ts);
+ nanouptime(&now);
+ timespecadd(&now, &ts, &end);
+
+ for (;;) {
ccb->ccb_state = CISS_CCB_POLL;
- CISS_DPRINTF(CISS_D_CMD, ("tsleep(%d) ", tohz));
- if (tsleep(ccb, PRIBIO + 1, "ciss_cmd",
- tohz) == EWOULDBLOCK) {
+ nsecs = TIMESPEC_TO_NSEC(&ts);
+ CISS_DPRINTF(CISS_D_CMD, ("tsleep_nsec(%llu) ", nsecs));
+ ret = tsleep_nsec(ccb, PRIBIO + 1, "ciss_cmd", nsecs);
+ if (ret == EWOULDBLOCK)
break;
- }
if (ccb->ccb_state != CISS_CCB_ONQ) {
- tohz = etick - tick;
- if (tohz <= 0)
+ nanouptime(&now);
+ if (timespeccmp(&end, &now, <=))
break;
+ timespecsub(&end, &now, &ts);
CISS_DPRINTF(CISS_D_CMD, ("T"));
continue;
}
Re: ksyms(4) and allowkmem
On Wed, 22 Jan 2020 14:55:08 -0700, "Theo de Raadt" wrote: > You can see where an object would be, but you can't read the object. > This is unlike dt where you can see the object and via parameter > inspection deeply reason about the value plaed at object addresses. > > However, the permissions look good: > > -rwx-- 1 root wheel 18480588 Jan 21 08:22 /bsd* > crw-r- 1 root kmem50, 0 Jan 14 23:39 /dev/ksyms > > We don't have any setgid kmem programs anymore, so the disclosure > is limited to root who can read the kernel. Right, /dev/ksyms doesn't have any data that is not also in /bsd and, for the most part, /var/db/kvm_bsd.db. It doesn't make sense to make access to /dev/ksyms much stricter than access to the others. - todd
Re: em(4) diff to test
On Tue, Jan 21, 2020 at 12:31:52PM +0100, Martin Pieuchot wrote: > New diff that works with 82576, previous breakage reported by Hrvoje > Popovski. So far the following models have been tested, I'm looking for > more tests :o) > > em3 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 0 int 16 > em0 at pci1 dev 0 function 0 "Intel 82572EI" rev 0x06: apic 0 int 16 > em0 at pci1 dev 0 function 0 "Intel 82576" rev 0x01: msi > em0 at pci0 dev 25 function 0 "Intel 82577LM" rev 0x06: msi > em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi > em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi > em0 at pci0 dev 25 function 0 "Intel I218-V" rev 0x03: msi > em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x04: msi > em0 at pci0 dev 31 function 6 "Intel I219-V" rev 0x21: msi > em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi On my regress machines I found these: em2 at pci0 dev 4 function 0 "Intel 82540EM" rev 0x02: apic 9 int 14 em1 at pci3 dev 1 function 0 "Intel 82545GM" rev 0x04: apic 4 int 0 em0 at pci3 dev 1 function 0 "Intel 82546GB" rev 0x03: apic 3 int 0 em2 at pci5 dev 0 function 0 "Intel 82573E" rev 0x03: msi em3 at pci6 dev 0 function 0 "Intel 82573L" rev 0x00: msi Tested on i386. bluhm
Re: dt(4) for hppa & alpha
Mark Kettenis wrote: > Theo de Raadt schreef op 2020-01-22 23:20: > > this is not actually surprising. there are only about 3 majors > > which can't > > move around without problem. It is a MD detail, which is why tables > > have > > to know about it > > > > ok > > I sometimes wish we'd split the majors into MI and MD "ranges", but > that'd need a giant flag day and I can't motivate myself to do the > work for that. such a flag day would require "cleaning out old /dev nodes", which have unsafe owner/permissions I think it is impossible! However I also share the attraction to the idea, it would be similar to our unified syscall numbers. (Don't mention the seccomp!)
Unix Hardware Givaway Sun Sparc Vax etc...
Hello All, Just to let you know that someone has posted on twitter in German that they are giving away aload of Unix Gear, some Sun Sparc stuff in there that may be of use to people who are supporting or trying to do builds it was re-tweeted by Philip Jocks, and it is in German, but you can make out specs It may be of help for maintaining / supporting the other platforms you run your code / develop your code on I hope this helps https://twitter.com/NikTheDusky/status/1219770675247886337 -- Kindest regards, Tom Smyth.
Re: dt(4) for hppa & alpha
Theo de Raadt schreef op 2020-01-22 23:20: this is not actually surprising. there are only about 3 majors which can't move around without problem. It is a MD detail, which is why tables have to know about it ok I sometimes wish we'd split the majors into MI and MD "ranges", but that'd need a giant flag day and I can't motivate myself to do the work for that. Anyway, the diff is ok kettenis@ as well Martin Pieuchot wrote: Major 30 is taken on both platforms, so use 32 to give a chance for people to use dt(4) and btrace(8) on these platforms. Ok? === RCS file: /cvs/src/etc/etc.alpha/MAKEDEV.md,v retrieving revision 1.72 diff -u -p -r1.72 MAKEDEV.md --- etc/etc.alpha/MAKEDEV.md17 Dec 2019 13:08:54 - 1.72 +++ etc/etc.alpha/MAKEDEV.md22 Jan 2020 14:31:49 - @@ -64,6 +64,7 @@ _DEV(bio, 53) _DEV(bktr, 58) _DEV(bpf, 11) _DEV(diskmap, 63) +_DEV(dt, 32) _DEV(fdesc, 10) _DEV(fuse, 67) _DEV(hotplug, 56) Index: etc/etc.hppa/MAKEDEV.md === RCS file: /cvs/src/etc/etc.hppa/MAKEDEV.md,v retrieving revision 1.61 diff -u -p -r1.61 MAKEDEV.md --- etc/etc.hppa/MAKEDEV.md 17 Dec 2019 13:08:55 - 1.61 +++ etc/etc.hppa/MAKEDEV.md 22 Jan 2020 14:31:49 - @@ -62,6 +62,7 @@ _DEV(au, 35) _DEV(bio, 37) _DEV(bpf, 17) _DEV(diskmap,56) +_DEV(dt, 32) _DEV(fdesc, 16) _DEV(fuse, 58) _DEV(hotplug, 47) Index: sys/arch/alpha/alpha/conf.c === RCS file: /cvs/src/sys/arch/alpha/alpha/conf.c,v retrieving revision 1.85 diff -u -p -r1.85 conf.c --- sys/arch/alpha/alpha/conf.c 17 Dec 2019 13:08:54 - 1.85 +++ sys/arch/alpha/alpha/conf.c 22 Jan 2020 14:28:47 - @@ -115,6 +115,7 @@ cdev_decl(cy); #include "ugen.h" #include "ulpt.h" #include "ucom.h" +#include "dt.h" #include "pf.h" #ifdef USER_PCICONF #include "pci.h" @@ -161,7 +162,7 @@ struct cdevsw cdevsw[] = cdev_mouse_init(NWSKBD,wskbd), /* 29: /dev/kbd XXX */ cdev_mouse_init(NWSMOUSE,wsmouse), /* 30: /dev/mouse XXX */ cdev_lpt_init(NLPT,lpt),/* 31: parallel printer */ - cdev_notdef(), /* 32: */ + cdev_dt_init(NDT,dt), /* 32: dynamic tracer */ cdev_uk_init(NUK,uk), /* 33: SCSI unknown */ cdev_random_init(1,random), /* 34: random data source */ cdev_pf_init(NPF, pf), /* 35: packet filter */ Index: sys/arch/hppa/hppa/conf.c === RCS file: /cvs/src/sys/arch/hppa/hppa/conf.c,v retrieving revision 1.67 diff -u -p -r1.67 conf.c --- sys/arch/hppa/hppa/conf.c 17 Dec 2019 13:08:55 - 1.67 +++ sys/arch/hppa/hppa/conf.c 22 Jan 2020 14:33:43 - @@ -98,6 +98,7 @@ cdev_decl(lpt); #include "com.h" cdev_decl(com); +#include "dt.h" #include "pf.h" #include "hotplug.h" @@ -158,7 +159,7 @@ struct cdevsw cdevsw[] = #else cdev_notdef(), /* 31: */ #endif - cdev_notdef(), /* 32 */ + cdev_dt_init(NDT,dt), /* 32: dynamic tracer */ cdev_video_init(NVIDEO,video), /* 33: generic video I/O */ cdev_notdef(), /* 34 */ cdev_audio_init(NAUDIO,audio), /* 35: /dev/audio */
Re: amdgpu (and possible radeondrm) fix
Todd C. Miller schreef op 2020-01-22 17:25: On Wed, 22 Jan 2020 03:10:01 +0100, Mark Kettenis wrote: The attached diff fixes amdgpu(4) and might very well fix radeondrm(4) as well. The problems with the hardware cursor are gone, various screen corruptions no longer seem to happen and the laptop I have here suspends and resumes now. I still occasionally see some glitches playing youtube videos, but overall this seems to be huge improvement. Just out of curiosity, do you have any plans to replace the drm_vma_node_unmap() stub with something similar? That function is used in other places too. One other place, which is already #ifdef __linux__. I'd like to implement it properly, but that is hard given the differences between uvm and Linux's VM system. At least jsg@ went ahead and poisoned the function. Cheers, Mark
Re: acme-client calloc fix
Matthew Martin wrote:
> On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> > should not size the size until the allocation succeeds, or the free path
> > will
> > try to deref the null array.
> >
> >
> > Index: json.c
> > ===
> > RCS file: /home/cvs/src/usr.sbin/acme-client/json.c,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 json.c
> > --- json.c 18 Jun 2019 18:50:07 - 1.14
> > +++ json.c 22 Jan 2020 05:37:59 -
> > @@ -459,12 +459,13 @@ json_parse_order(struct jsmnn *n, struct
> > if ((array = json_getarray(n, "authorizations")) == NULL)
> > goto err;
> >
> > - if ((order->authsz = array->fields) > 0) {
> > + if (array->fields > 0) {
> > order->auths = calloc(sizeof(*order->auths), order->authsz);
>
> Shouldn't the second argument be switched to array->fields to maintain
> the same behavior?
thanks!
Re: dt(4) for hppa & alpha
this is not actually surprising. there are only about 3 majors which can't move around without problem. It is a MD detail, which is why tables have to know about it ok Martin Pieuchot wrote: > Major 30 is taken on both platforms, so use 32 to give a chance for > people to use dt(4) and btrace(8) on these platforms. > > Ok? > > === > RCS file: /cvs/src/etc/etc.alpha/MAKEDEV.md,v > retrieving revision 1.72 > diff -u -p -r1.72 MAKEDEV.md > --- etc/etc.alpha/MAKEDEV.md 17 Dec 2019 13:08:54 - 1.72 > +++ etc/etc.alpha/MAKEDEV.md 22 Jan 2020 14:31:49 - > @@ -64,6 +64,7 @@ _DEV(bio, 53) > _DEV(bktr, 58) > _DEV(bpf, 11) > _DEV(diskmap, 63) > +_DEV(dt, 32) > _DEV(fdesc, 10) > _DEV(fuse, 67) > _DEV(hotplug, 56) > Index: etc/etc.hppa/MAKEDEV.md > === > RCS file: /cvs/src/etc/etc.hppa/MAKEDEV.md,v > retrieving revision 1.61 > diff -u -p -r1.61 MAKEDEV.md > --- etc/etc.hppa/MAKEDEV.md 17 Dec 2019 13:08:55 - 1.61 > +++ etc/etc.hppa/MAKEDEV.md 22 Jan 2020 14:31:49 - > @@ -62,6 +62,7 @@ _DEV(au, 35) > _DEV(bio, 37) > _DEV(bpf, 17) > _DEV(diskmap,56) > +_DEV(dt, 32) > _DEV(fdesc, 16) > _DEV(fuse, 58) > _DEV(hotplug, 47) > Index: sys/arch/alpha/alpha/conf.c > === > RCS file: /cvs/src/sys/arch/alpha/alpha/conf.c,v > retrieving revision 1.85 > diff -u -p -r1.85 conf.c > --- sys/arch/alpha/alpha/conf.c 17 Dec 2019 13:08:54 - 1.85 > +++ sys/arch/alpha/alpha/conf.c 22 Jan 2020 14:28:47 - > @@ -115,6 +115,7 @@ cdev_decl(cy); > #include "ugen.h" > #include "ulpt.h" > #include "ucom.h" > +#include "dt.h" > #include "pf.h" > #ifdef USER_PCICONF > #include "pci.h" > @@ -161,7 +162,7 @@ struct cdevsw cdevsw[] = > cdev_mouse_init(NWSKBD,wskbd), /* 29: /dev/kbd XXX */ > cdev_mouse_init(NWSMOUSE,wsmouse), /* 30: /dev/mouse XXX */ > cdev_lpt_init(NLPT,lpt),/* 31: parallel printer */ > - cdev_notdef(), /* 32: */ > + cdev_dt_init(NDT,dt), /* 32: dynamic tracer */ > cdev_uk_init(NUK,uk), /* 33: SCSI unknown */ > cdev_random_init(1,random), /* 34: random data source */ > cdev_pf_init(NPF, pf), /* 35: packet filter */ > Index: sys/arch/hppa/hppa/conf.c > === > RCS file: /cvs/src/sys/arch/hppa/hppa/conf.c,v > retrieving revision 1.67 > diff -u -p -r1.67 conf.c > --- sys/arch/hppa/hppa/conf.c 17 Dec 2019 13:08:55 - 1.67 > +++ sys/arch/hppa/hppa/conf.c 22 Jan 2020 14:33:43 - > @@ -98,6 +98,7 @@ cdev_decl(lpt); > #include "com.h" > cdev_decl(com); > > +#include "dt.h" > #include "pf.h" > > #include "hotplug.h" > @@ -158,7 +159,7 @@ struct cdevsw cdevsw[] = > #else > cdev_notdef(), /* 31: */ > #endif > - cdev_notdef(), /* 32 */ > + cdev_dt_init(NDT,dt), /* 32: dynamic tracer */ > cdev_video_init(NVIDEO,video), /* 33: generic video I/O */ > cdev_notdef(), /* 34 */ > cdev_audio_init(NAUDIO,audio), /* 35: /dev/audio */ >
Re: acme-client calloc fix
oops, no kidding, otherwise it is the older value.
Matthew Martin wrote:
> On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> > should not size the size until the allocation succeeds, or the free path
> > will
> > try to deref the null array.
> >
> >
> > Index: json.c
> > ===
> > RCS file: /home/cvs/src/usr.sbin/acme-client/json.c,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 json.c
> > --- json.c 18 Jun 2019 18:50:07 - 1.14
> > +++ json.c 22 Jan 2020 05:37:59 -
> > @@ -459,12 +459,13 @@ json_parse_order(struct jsmnn *n, struct
> > if ((array = json_getarray(n, "authorizations")) == NULL)
> > goto err;
> >
> > - if ((order->authsz = array->fields) > 0) {
> > + if (array->fields > 0) {
> > order->auths = calloc(sizeof(*order->auths), order->authsz);
>
> Shouldn't the second argument be switched to array->fields to maintain
> the same behavior?
>
> > if (order->auths == NULL) {
> > warn("malloc");
> > goto err;
> > }
> > + order->authsz = array->fields;
> > }
> >
> > for (i = 0; i < array->fields; i++) {
> >
>
Re: dt(4) and allowkmem
Todd C. Miller wrote: > On Wed, 22 Jan 2020 15:12:25 +0100, Martin Pieuchot wrote: > > > dt(4) is a debugging interface that allows userland to read kernel > > addresses. So its access should be restricted by default, just like > > mem(4). > > > > Diff prevent opening the pseudo-device unless `allowkmem' is set. > > Does it really make sense to reuse `allowkmem' for this? This will > mean that in order to use dt(4) you also have to open up mem(4). > I don't think that is desirable. The things you can learn via dt are a stong inspection window into kmem. I think it's stronger than immediately obvious. > If you want to disable dt(4) by default I think you are better off > using a new sysctl knob. I'm on the fence about it. But it is small, so I think allowdt is better.
Re: ksyms(4) and allowkmem
Todd C. Miller wrote: > On Wed, 22 Jan 2020 15:17:32 +0100, Martin Pieuchot wrote: > > > Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel > > addresses. > > > > Diff below makes `allowkmem' a requirement for opening the > > pseudo-device. > > Won't this break everything that uses /dev/ksyms? The default for > allowkmem is 0. > > Furthermore, ksyms doesn't provide kernel _addresses_, it provides > kernel _symbols_. There shouldn't be anything available via > /dev/ksyms that is not also available from reading the booted kernel. Well, symbols are resolved to contain addresses. Especially in text segment, immediately you know text gadgets. Knowing layout of text, you can determine .o linkage order for a correctly-dated-kernel, and therefore estimate data segment layout for data location attacks. You can see where an object would be, but you can't read the object. This is unlike dt where you can see the object and via parameter inspection deeply reason about the value plaed at object addresses. However, the permissions look good: -rwx-- 1 root wheel 18480588 Jan 21 08:22 /bsd* crw-r- 1 root kmem50, 0 Jan 14 23:39 /dev/ksyms We don't have any setgid kmem programs anymore, so the disclosure is limited to root who can read the kernel. Having layed out all the arguments, I agree with Todd that ksyms doesn't seem to require further protection.
Re: umb(4) WIP diff and questions
Hi, Disclaimer: I don't have such hardware to test with or without the diff below, but I think if we add this change in any shape or form then we should add this as well otherwise we could bump into the vuln [0] that Ilja found on NetBSD which could leak the credentials. [0] https://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2020-001.txt.asc Index: if_umb.c === RCS file: /cvs/src/sys/dev/usb/if_umb.c,v retrieving revision 1.31 diff -u -p -u -r1.31 if_umb.c --- if_umb.c26 Nov 2019 23:04:28 - 1.31 +++ if_umb.c21 Jan 2020 23:23:43 - @@ -699,6 +699,8 @@ umb_ioctl(struct ifnet *ifp, u_long cmd, usb_add_task(sc->sc_udev, &sc->sc_umb_task); break; case SIOCGUMBINFO: + if ((error = suser(p)) != 0) + break; error = copyout(&sc->sc_info, ifr->ifr_data, sizeof (sc->sc_info)); break; On 12:40 Tue 14 Jan , Theo de Raadt wrote: > Theo de Raadt wrote: > > > Stuart Henderson wrote: > > > > > On 2020/01/14 10:27, Theo de Raadt wrote: > > > > Unfortunate part of this diff is that the password is (very > > > > momentarily) visible with ps(1) in the root-run ifconfig argv[] array. > > > > It's a tight race, but still it is visible. > > > > > > > > People do run "sh /etc/netstart umb0" to activate the interface > > > > during multiuser. > > > > > > > > If the password is truly sensitive, it should be placed in a file, > > > > and the ifconfig's extension should be changed to read the file. > > > > > > That's not unique to umb though, it's been a problem forever with carp, > > > pppoe and especially wlan interfaces. > > > > When creating new versions of the same problem... that's a great time > > to reconsider the old solutions. > > > > > Another fix would be to accept > > > ifconfig options on stdin, which is more convenient for quick runtime > > > changes than two steps of writing to a file then pointing ifconfig at > > > it, and changing netstart to use it would improve things for existing > > > users without them needing to touch any config files. > > > > I think using the shell is silly, because what if there are two such > > options? Then you can't seperate the stdin. > > > > Additionally, most of the time when creating such temporary configuration, > > the pattern is that if it works you'll want to apply it permanent. > > > > Another thought is to create both versions of the option. One on the > > commandline, and one pointing at a file. > > > > Channeling a conversation from 15 years ago: "How about wpakeyfile" > > > Another consideration is... many of these passwords are locked to narrow > usage cases, so does it really matter all that much? >
Re: cwm: remove menu-ssh
On Wed, Jan 22, 2020 at 03:15:37PM -0500, Okan Demirmen wrote: > Remove menu-ssh. OK kn
Re: cwm: remove menu-ssh
On Wed, Jan 22, 2020 at 03:15:37PM -0500, Okan Demirmen wrote:
> Hi,
>
> I think we've (or at least I have) mused about this for a while; a
> recent mail reminded me that this feature should go - a window manager
> doesn't need to parse the ssh known_hosts file for a menu; there are
> better tools for this.
>
> Remove menu-ssh.
>
> okay?
I remember agreeing last time. Had this in .cwmrc for awhile. :-)
unbind-key M-period # ssh menu
ok brynet@
> Index: calmwm.h
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.372
> diff -u -p -r1.372 calmwm.h
> --- calmwm.h 22 Jan 2020 19:58:35 - 1.372
> +++ calmwm.h 22 Jan 2020 20:09:13 -
> @@ -304,7 +304,6 @@ struct conf {
> int xrandr;
> int xrandr_event_base;
> char*conf_file;
> - char*known_hosts;
> char*wm_argv;
> int debug;
> };
> @@ -517,7 +516,6 @@ void kbfunc_menu_cmd(void *, struct
> c
> void kbfunc_menu_group(void *, struct cargs *);
> void kbfunc_menu_wm(void *, struct cargs *);
> void kbfunc_menu_exec(void *, struct cargs *);
> -void kbfunc_menu_ssh(void *, struct cargs *);
> void kbfunc_client_menu_label(void *, struct cargs *);
> void kbfunc_exec_cmd(void *, struct cargs *);
> void kbfunc_exec_lock(void *, struct cargs *);
> Index: conf.c
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.249
> diff -u -p -r1.249 conf.c
> --- conf.c7 Mar 2019 12:54:21 - 1.249
> +++ conf.c22 Jan 2020 20:09:24 -
> @@ -179,7 +179,6 @@ static const struct {
>
> { FUNC_SC(menu-cmd, menu_cmd, 0) },
> { FUNC_SC(menu-group, menu_group, 0) },
> - { FUNC_SC(menu-ssh, menu_ssh, 0) },
> { FUNC_SC(menu-window, menu_client, CWM_MENU_WINDOW_ALL) },
> { FUNC_SC(menu-window-hidden, menu_client, CWM_MENU_WINDOW_HIDDEN) },
> { FUNC_SC(menu-exec, menu_exec, 0) },
> @@ -210,7 +209,6 @@ static const struct {
> { "CM-Delete", "lock" },
> { "M-question", "menu-exec" },
> { "CM-w", "menu-exec-wm" },
> - { "M-period", "menu-ssh" },
> { "M-Return", "window-hide" },
> { "M-Down", "window-lower" },
> { "M-Up", "window-raise" },
> @@ -316,7 +314,6 @@ conf_init(struct conf *c)
> home = "/";
> }
> xasprintf(&c->conf_file, "%s/%s", home, ".cwmrc");
> - xasprintf(&c->known_hosts, "%s/%s", home, ".ssh/known_hosts");
> }
>
> void
> @@ -363,7 +360,6 @@ conf_clear(struct conf *c)
> free(c->color[i]);
>
> free(c->conf_file);
> - free(c->known_hosts);
> free(c->font);
> free(c->wmname);
> }
> Index: cwm.1
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/cwm.1,v
> retrieving revision 1.65
> diff -u -p -r1.65 cwm.1
> --- cwm.1 9 Jul 2019 21:38:44 - 1.65
> +++ cwm.1 22 Jan 2020 20:08:19 -
> @@ -140,15 +140,6 @@ Resize window by a large amount; see
> Spawn
> .Dq exec program
> dialog.
> -.It Ic M-period
> -Spawn
> -.Dq ssh to
> -dialog.
> -This parses
> -.Pa $HOME/.ssh/known_hosts
> -to provide host auto-completion.
> -.Xr ssh 1
> -will be executed via the configured terminal emulator.
> .It Ic CM-w
> Spawn
> .Dq exec WindowManager
> Index: cwmrc.5
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/cwmrc.5,v
> retrieving revision 1.73
> diff -u -p -r1.73 cwmrc.5
> --- cwmrc.5 2 Jul 2019 23:37:47 - 1.73
> +++ cwmrc.5 22 Jan 2020 20:07:57 -
> @@ -280,10 +280,6 @@ menu.
> Launch
> .Dq exec WindowManager
> menu.
> -.It menu-ssh
> -Launch
> -.Dq ssh
> -menu.
> .It group-toggle-[n]
> Toggle visibility of group n, where n is 1-9.
> .It group-only-[n]
> Index: kbfunc.c
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
> retrieving revision 1.167
> diff -u -p -r1.167 kbfunc.c
> --- kbfunc.c 21 Jan 2020 15:50:03 - 1.167
> +++ kbfunc.c 22 Jan 2020 20:09:03 -
> @@ -647,72 +647,6 @@ out:
> }
>
> void
> -kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
> -{
> - struct screen_ctx *sc = ctx;
> - struct cmd_ctx *cmd;
> - struct menu *mi;
> - struct menu_qmenuq;
> - FILE*fp;
> - char*buf, *lbuf, *p;
> - char hostbuf[HOST_NAME_MAX+1];
> - char path[PATH_MAX];
> - int l;
> - size_t
cwm: remove menu-ssh
Hi,
I think we've (or at least I have) mused about this for a while; a
recent mail reminded me that this feature should go - a window manager
doesn't need to parse the ssh known_hosts file for a menu; there are
better tools for this.
Remove menu-ssh.
okay?
Index: calmwm.h
===
RCS file: /home/open/cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.372
diff -u -p -r1.372 calmwm.h
--- calmwm.h22 Jan 2020 19:58:35 - 1.372
+++ calmwm.h22 Jan 2020 20:09:13 -
@@ -304,7 +304,6 @@ struct conf {
int xrandr;
int xrandr_event_base;
char*conf_file;
- char*known_hosts;
char*wm_argv;
int debug;
};
@@ -517,7 +516,6 @@ void kbfunc_menu_cmd(void *, struct
c
voidkbfunc_menu_group(void *, struct cargs *);
voidkbfunc_menu_wm(void *, struct cargs *);
voidkbfunc_menu_exec(void *, struct cargs *);
-voidkbfunc_menu_ssh(void *, struct cargs *);
voidkbfunc_client_menu_label(void *, struct cargs *);
voidkbfunc_exec_cmd(void *, struct cargs *);
voidkbfunc_exec_lock(void *, struct cargs *);
Index: conf.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.249
diff -u -p -r1.249 conf.c
--- conf.c 7 Mar 2019 12:54:21 - 1.249
+++ conf.c 22 Jan 2020 20:09:24 -
@@ -179,7 +179,6 @@ static const struct {
{ FUNC_SC(menu-cmd, menu_cmd, 0) },
{ FUNC_SC(menu-group, menu_group, 0) },
- { FUNC_SC(menu-ssh, menu_ssh, 0) },
{ FUNC_SC(menu-window, menu_client, CWM_MENU_WINDOW_ALL) },
{ FUNC_SC(menu-window-hidden, menu_client, CWM_MENU_WINDOW_HIDDEN) },
{ FUNC_SC(menu-exec, menu_exec, 0) },
@@ -210,7 +209,6 @@ static const struct {
{ "CM-Delete", "lock" },
{ "M-question", "menu-exec" },
{ "CM-w", "menu-exec-wm" },
- { "M-period", "menu-ssh" },
{ "M-Return", "window-hide" },
{ "M-Down", "window-lower" },
{ "M-Up", "window-raise" },
@@ -316,7 +314,6 @@ conf_init(struct conf *c)
home = "/";
}
xasprintf(&c->conf_file, "%s/%s", home, ".cwmrc");
- xasprintf(&c->known_hosts, "%s/%s", home, ".ssh/known_hosts");
}
void
@@ -363,7 +360,6 @@ conf_clear(struct conf *c)
free(c->color[i]);
free(c->conf_file);
- free(c->known_hosts);
free(c->font);
free(c->wmname);
}
Index: cwm.1
===
RCS file: /home/open/cvs/xenocara/app/cwm/cwm.1,v
retrieving revision 1.65
diff -u -p -r1.65 cwm.1
--- cwm.1 9 Jul 2019 21:38:44 - 1.65
+++ cwm.1 22 Jan 2020 20:08:19 -
@@ -140,15 +140,6 @@ Resize window by a large amount; see
Spawn
.Dq exec program
dialog.
-.It Ic M-period
-Spawn
-.Dq ssh to
-dialog.
-This parses
-.Pa $HOME/.ssh/known_hosts
-to provide host auto-completion.
-.Xr ssh 1
-will be executed via the configured terminal emulator.
.It Ic CM-w
Spawn
.Dq exec WindowManager
Index: cwmrc.5
===
RCS file: /home/open/cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.73
diff -u -p -r1.73 cwmrc.5
--- cwmrc.5 2 Jul 2019 23:37:47 - 1.73
+++ cwmrc.5 22 Jan 2020 20:07:57 -
@@ -280,10 +280,6 @@ menu.
Launch
.Dq exec WindowManager
menu.
-.It menu-ssh
-Launch
-.Dq ssh
-menu.
.It group-toggle-[n]
Toggle visibility of group n, where n is 1-9.
.It group-only-[n]
Index: kbfunc.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.167
diff -u -p -r1.167 kbfunc.c
--- kbfunc.c21 Jan 2020 15:50:03 - 1.167
+++ kbfunc.c22 Jan 2020 20:09:03 -
@@ -647,72 +647,6 @@ out:
}
void
-kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
-{
- struct screen_ctx *sc = ctx;
- struct cmd_ctx *cmd;
- struct menu *mi;
- struct menu_qmenuq;
- FILE*fp;
- char*buf, *lbuf, *p;
- char hostbuf[HOST_NAME_MAX+1];
- char path[PATH_MAX];
- int l;
- size_t len;
- ssize_t slen;
- int mflags = (CWM_MENU_DUMMY);
-
- TAILQ_FOREACH(cmd, &Conf.cmdq, entry) {
- if (strcmp(cmd->name, "term") == 0)
- break;
- }
- TAILQ_INIT(&menuq);
-
- if ((fp = fopen(Conf.known_hosts,
Re: dt(4) and allowkmem
On Wed, 22 Jan 2020 15:12:25 +0100, Martin Pieuchot wrote: > dt(4) is a debugging interface that allows userland to read kernel > addresses. So its access should be restricted by default, just like > mem(4). > > Diff prevent opening the pseudo-device unless `allowkmem' is set. Does it really make sense to reuse `allowkmem' for this? This will mean that in order to use dt(4) you also have to open up mem(4). I don't think that is desirable. If you want to disable dt(4) by default I think you are better off using a new sysctl knob. - todd
Re: ksyms(4) and allowkmem
On Wed, 22 Jan 2020 15:17:32 +0100, Martin Pieuchot wrote: > Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel > addresses. > > Diff below makes `allowkmem' a requirement for opening the > pseudo-device. Won't this break everything that uses /dev/ksyms? The default for allowkmem is 0. Furthermore, ksyms doesn't provide kernel _addresses_, it provides kernel _symbols_. There shouldn't be anything available via /dev/ksyms that is not also available from reading the booted kernel. - todd
Re: amdgpu (and possible radeondrm) fix
On Wed, 22 Jan 2020 03:10:01 +0100, Mark Kettenis wrote: > The attached diff fixes amdgpu(4) and might very well fix radeondrm(4) > as well. The problems with the hardware cursor are gone, various screen > corruptions no longer seem to happen and the laptop I have here suspends > and resumes now. > I still occasionally see some glitches playing youtube videos, but > overall this seems to be huge improvement. Just out of curiosity, do you have any plans to replace the drm_vma_node_unmap() stub with something similar? That function is used in other places too. - todd
dt(4) for hppa & alpha
Major 30 is taken on both platforms, so use 32 to give a chance for people to use dt(4) and btrace(8) on these platforms. Ok? === RCS file: /cvs/src/etc/etc.alpha/MAKEDEV.md,v retrieving revision 1.72 diff -u -p -r1.72 MAKEDEV.md --- etc/etc.alpha/MAKEDEV.md17 Dec 2019 13:08:54 - 1.72 +++ etc/etc.alpha/MAKEDEV.md22 Jan 2020 14:31:49 - @@ -64,6 +64,7 @@ _DEV(bio, 53) _DEV(bktr, 58) _DEV(bpf, 11) _DEV(diskmap, 63) +_DEV(dt, 32) _DEV(fdesc, 10) _DEV(fuse, 67) _DEV(hotplug, 56) Index: etc/etc.hppa/MAKEDEV.md === RCS file: /cvs/src/etc/etc.hppa/MAKEDEV.md,v retrieving revision 1.61 diff -u -p -r1.61 MAKEDEV.md --- etc/etc.hppa/MAKEDEV.md 17 Dec 2019 13:08:55 - 1.61 +++ etc/etc.hppa/MAKEDEV.md 22 Jan 2020 14:31:49 - @@ -62,6 +62,7 @@ _DEV(au, 35) _DEV(bio, 37) _DEV(bpf, 17) _DEV(diskmap,56) +_DEV(dt, 32) _DEV(fdesc, 16) _DEV(fuse, 58) _DEV(hotplug, 47) Index: sys/arch/alpha/alpha/conf.c === RCS file: /cvs/src/sys/arch/alpha/alpha/conf.c,v retrieving revision 1.85 diff -u -p -r1.85 conf.c --- sys/arch/alpha/alpha/conf.c 17 Dec 2019 13:08:54 - 1.85 +++ sys/arch/alpha/alpha/conf.c 22 Jan 2020 14:28:47 - @@ -115,6 +115,7 @@ cdev_decl(cy); #include "ugen.h" #include "ulpt.h" #include "ucom.h" +#include "dt.h" #include "pf.h" #ifdef USER_PCICONF #include "pci.h" @@ -161,7 +162,7 @@ struct cdevsw cdevsw[] = cdev_mouse_init(NWSKBD,wskbd), /* 29: /dev/kbd XXX */ cdev_mouse_init(NWSMOUSE,wsmouse), /* 30: /dev/mouse XXX */ cdev_lpt_init(NLPT,lpt),/* 31: parallel printer */ - cdev_notdef(), /* 32: */ + cdev_dt_init(NDT,dt), /* 32: dynamic tracer */ cdev_uk_init(NUK,uk), /* 33: SCSI unknown */ cdev_random_init(1,random), /* 34: random data source */ cdev_pf_init(NPF, pf), /* 35: packet filter */ Index: sys/arch/hppa/hppa/conf.c === RCS file: /cvs/src/sys/arch/hppa/hppa/conf.c,v retrieving revision 1.67 diff -u -p -r1.67 conf.c --- sys/arch/hppa/hppa/conf.c 17 Dec 2019 13:08:55 - 1.67 +++ sys/arch/hppa/hppa/conf.c 22 Jan 2020 14:33:43 - @@ -98,6 +98,7 @@ cdev_decl(lpt); #include "com.h" cdev_decl(com); +#include "dt.h" #include "pf.h" #include "hotplug.h" @@ -158,7 +159,7 @@ struct cdevsw cdevsw[] = #else cdev_notdef(), /* 31: */ #endif - cdev_notdef(), /* 32 */ + cdev_dt_init(NDT,dt), /* 32: dynamic tracer */ cdev_video_init(NVIDEO,video), /* 33: generic video I/O */ cdev_notdef(), /* 34 */ cdev_audio_init(NAUDIO,audio), /* 35: /dev/audio */
Re: acme-client calloc fix
On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> should not size the size until the allocation succeeds, or the free path will
> try to deref the null array.
>
>
> Index: json.c
> ===
> RCS file: /home/cvs/src/usr.sbin/acme-client/json.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 json.c
> --- json.c18 Jun 2019 18:50:07 - 1.14
> +++ json.c22 Jan 2020 05:37:59 -
> @@ -459,12 +459,13 @@ json_parse_order(struct jsmnn *n, struct
> if ((array = json_getarray(n, "authorizations")) == NULL)
> goto err;
>
> - if ((order->authsz = array->fields) > 0) {
> + if (array->fields > 0) {
> order->auths = calloc(sizeof(*order->auths), order->authsz);
Shouldn't the second argument be switched to array->fields to maintain
the same behavior?
> if (order->auths == NULL) {
> warn("malloc");
> goto err;
> }
> + order->authsz = array->fields;
> }
>
> for (i = 0; i < array->fields; i++) {
>
ksyms(4) and allowkmem
Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel
addresses.
Diff below makes `allowkmem' a requirement for opening the
pseudo-device.
ok?
Index: sys/dev/ksyms.c
===
RCS file: /cvs/src/sys/dev/ksyms.c,v
retrieving revision 1.32
diff -u -p -r1.32 ksyms.c
--- sys/dev/ksyms.c 25 Jan 2019 00:19:26 - 1.32
+++ sys/dev/ksyms.c 22 Jan 2020 14:14:20 -
@@ -114,13 +114,14 @@ ksymsattach(int num)
int
ksymsopen(dev_t dev, int flag, int mode, struct proc *p)
{
+ extern int allowkmem;
/* There are no non-zero minor devices */
if (minor(dev) != 0)
return (ENXIO);
/* This device is read-only */
- if ((flag & FWRITE))
+ if ((flag & FWRITE) || !allowkmem)
return (EPERM);
/* ksym_syms must be initialized */
Index: share/man/man4/ksyms.4
===
RCS file: /cvs/src/share/man/man4/ksyms.4,v
retrieving revision 1.14
diff -u -p -r1.14 ksyms.4
--- share/man/man4/ksyms.4 25 Jan 2019 00:19:26 - 1.14
+++ share/man/man4/ksyms.4 22 Jan 2020 14:14:57 -
@@ -63,7 +63,10 @@ An open of
will fail if:
.Bl -tag -width Er
.It Bq Er EPERM
-An open was attempted with write permissions.
+An open was attempted with write permissions or the
+.Va kern.allowkmem
+.Xr sysctl 2
+is not set.
.It Bq Er ENXIO
No kernel symbols were saved by the boot loader (usually because
they were removed with
dt(4) and allowkmem
dt(4) is a debugging interface that allows userland to read kernel
addresses. So its access should be restricted by default, just like
mem(4).
Diff prevent opening the pseudo-device unless `allowkmem' is set.
ok?
Index: sys/dev/dt/dt_dev.c
===
RCS file: /cvs/src/sys/dev/dt/dt_dev.c,v
retrieving revision 1.1
diff -u -p -r1.1 dt_dev.c
--- sys/dev/dt/dt_dev.c 21 Jan 2020 16:16:23 - 1.1
+++ sys/dev/dt/dt_dev.c 22 Jan 2020 13:59:01 -
@@ -132,6 +132,10 @@ dtopen(dev_t dev, int flags, int mode, s
{
struct dt_softc *sc;
int unit = minor(dev);
+ extern int allowkmem;
+
+ if (!allowkmem)
+ return EPERM;
KASSERT(dtlookup(unit) == NULL);
Index: share/man/man4/dt.4
===
RCS file: /cvs/src/share/man/man4/dt.4,v
retrieving revision 1.1
diff -u -p -r1.1 dt.4
--- share/man/man4/dt.4 21 Jan 2020 16:18:28 - 1.1
+++ share/man/man4/dt.4 22 Jan 2020 14:01:13 -
@@ -28,6 +28,11 @@ It has to be configured and enabled thro
.Xr ioctl 2
interface exposed by the pseudo-device
.Pa /dev/dt .
+.Pp
+This device can only be opened when the
+.Va kern.allowkmem
+.Xr sysctl 2
+variable is set.
.\"Sh IOCTL INTERFACE
.\"
.Sh FILES
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
I guess this needs to be changed again, to retain more info from the
original title.
Stuart Henderson wrote:
> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> >
> > Modified files:
> > usr.bin/ssh: sshd.c
> >
> > Log message:
> > expose the number of currently-authenticating connections
> > along with the MaxStartups limit in the proctitle;
> > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > ok dtucker@
> >
>
> It's nice to have this information visible, but it brings some problems.
> You can't now distinguish between multiple sshd processes (e.g. if you
> run several on different ports it's hard to figure out which one to
> signal if needed).
>
> The rc.d script also needs updating because it uses pgrep to find the
> matching process:
>
> Index: sshd
> ===
> RCS file: /cvs/src/etc/rc.d/sshd,v
> retrieving revision 1.4
> diff -u -p -r1.4 sshd
> --- sshd 11 Jan 2018 19:52:12 - 1.4
> +++ sshd 22 Jan 2020 12:52:15 -
> @@ -6,6 +6,8 @@ daemon="/usr/sbin/sshd"
>
> . /etc/rc.d/rc.subr
>
> +pexp="sshd: \[listener\].*"
> +
> rc_reload() {
> ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
> }
>
>
sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On 2020/01/21 15:39, Damien Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
>
> Modified files:
> usr.bin/ssh: sshd.c
>
> Log message:
> expose the number of currently-authenticating connections
> along with the MaxStartups limit in the proctitle;
> suggestion from Philipp Marek, w/ feedback from Craig Miskell
> ok dtucker@
>
It's nice to have this information visible, but it brings some problems.
You can't now distinguish between multiple sshd processes (e.g. if you
run several on different ports it's hard to figure out which one to
signal if needed).
The rc.d script also needs updating because it uses pgrep to find the
matching process:
Index: sshd
===
RCS file: /cvs/src/etc/rc.d/sshd,v
retrieving revision 1.4
diff -u -p -r1.4 sshd
--- sshd11 Jan 2018 19:52:12 - 1.4
+++ sshd22 Jan 2020 12:52:15 -
@@ -6,6 +6,8 @@ daemon="/usr/sbin/sshd"
. /etc/rc.d/rc.subr
+pexp="sshd: \[listener\].*"
+
rc_reload() {
${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
}
Re: em(4) diff to test
On Tue, Jan 21, 2020 at 12:31:52PM +0100, Martin Pieuchot wrote: > On 20/01/20(Mon) 16:42, Martin Pieuchot wrote: > > Diff below is a refactoring of the actual em(4) code and defines that > > will allows me to present a shorter diff to interrupt multiple CPUs and > > make use of multiple queues. > > > > It contains the following items: > > > > - Abstract the allocation/freeing of TX/RX ring into em_dma_malloc(). > > This will ease the introduction of multiple rings. > > > > - Split the 82576 variant out of 82575. The distinction is necessary > > when it comes to setting multiple queues. > > > > - Change multiple TX/RX related macro to take an index argument > > corresponding to a ring. Currently only the index 0 and 1 are used. > > > > - Gather and print more stats counters > > > > - Switch to using a function, like FreeBSD, to translate 82542 > > registers and get rid of a set of defines. > > > > It has been tested one the models below, I'd like to be sure there isn't > > any fallout with this part before continuing the effort. > > New diff that works with 82576, previous breakage reported by Hrvoje > Popovski. So far the following models have been tested, I'm looking for > more tests :o) > > em3 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 0 int 16 > em0 at pci1 dev 0 function 0 "Intel 82572EI" rev 0x06: apic 0 int 16 > em0 at pci1 dev 0 function 0 "Intel 82576" rev 0x01: msi > em0 at pci0 dev 25 function 0 "Intel 82577LM" rev 0x06: msi > em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi > em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi > em0 at pci0 dev 25 function 0 "Intel I218-V" rev 0x03: msi > em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x04: msi > em0 at pci0 dev 31 function 6 "Intel I219-V" rev 0x21: msi > em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi Lightly tested on 82575 here: em0 at pci0 dev 2 function 0 "Intel 82575GB" rev 0x02: msi no problems seen. I read through the previous version and the only issues I saw were fixed in the second version.
Re: snmpd(8) timer.c garbage collect
You're right, this diff does some massive pointer juggling that I
overlooked.
I'll drop the diff.
On 1/22/20 10:59 AM, Otto Moerbeek wrote:
> On Wed, Jan 22, 2020 at 10:51:45AM +0100, Martijn van Duren wrote:
>
>> Trying to wrap my head around some of the snmpd code I found this pearl
>> that appears to do nothing more than warm up the room.
>
> Do you really want to get rid of the init of snmpd_env->sc_cpustates ?
>
> -Otto
>
>>
>> OK?
>>
>> martijn@
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
>> retrieving revision 1.16
>> diff -u -p -r1.16 Makefile
>> --- Makefile 11 May 2019 17:46:02 - 1.16
>> +++ Makefile 22 Jan 2020 09:50:51 -
>> @@ -3,7 +3,7 @@
>> PROG= snmpd
>> MAN=snmpd.8 snmpd.conf.5
>> SRCS= parse.y log.c control.c snmpe.c \
>> -mps.c trap.c mib.c smi.c kroute.c snmpd.c timer.c \
>> +mps.c trap.c mib.c smi.c kroute.c snmpd.c \
>> pf.c proc.c usm.c agentx.c traphandler.c util.c
>>
>> LDADD= -levent -lutil -lkvm -lcrypto
>> Index: snmpd.h
>> ===
>> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
>> retrieving revision 1.86
>> diff -u -p -r1.86 snmpd.h
>> --- snmpd.h 2 Jan 2020 10:55:53 - 1.86
>> +++ snmpd.h 22 Jan 2020 09:50:51 -
>> @@ -745,9 +745,6 @@ unsigned int smi_application(struct ber
>> void smi_debug_elements(struct ber_element *);
>> char*smi_print_element(struct ber_element *);
>>
>> -/* timer.c */
>> -void timer_init(void);
>> -
>> /* snmpd.c */
>> int snmpd_socket_af(struct sockaddr_storage *, in_port_t, int);
>> u_long snmpd_engine_time(void);
>> Index: snmpe.c
>> ===
>> RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
>> retrieving revision 1.60
>> diff -u -p -r1.60 snmpe.c
>> --- snmpe.c 24 Oct 2019 12:39:27 - 1.60
>> +++ snmpe.c 22 Jan 2020 09:50:51 -
>> @@ -103,7 +103,6 @@ snmpe_init(struct privsep *ps, struct pr
>>
>> kr_init();
>> trap_init();
>> -timer_init();
>> usm_generate_keys();
>>
>> /* listen for incoming SNMP UDP/TCP messages */
>> Index: timer.c
>> ===
>> RCS file: timer.c
>> diff -N timer.c
>> --- timer.c 28 Oct 2016 08:01:53 - 1.7
>> +++ /dev/null1 Jan 1970 00:00:00 -
>> @@ -1,169 +0,0 @@
>> -/* $OpenBSD: timer.c,v 1.7 2016/10/28 08:01:53 rzalamena Exp $ */
>> -
>> -/*
>> - * Copyright (c) 2008 Reyk Floeter
>> - *
>> - * Permission to use, copy, modify, and distribute this software for any
>> - * purpose with or without fee is hereby granted, provided that the above
>> - * copyright notice and this permission notice appear in all copies.
>> - *
>> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
>> - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>> - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
>> - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>> - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
>> - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>> - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>> - */
>> -
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -#include "snmpd.h"
>> -#include "mib.h"
>> -
>> -void timer_cpu(int, short, void *);
>> -int percentages(int, int64_t *, int64_t *, int64_t *, int64_t *);
>> -
>> -static int64_t **cp_time;
>> -static int64_t **cp_old;
>> -static int64_t **cp_diff;
>> -struct event cpu_ev;
>> -
>> -void
>> -timer_cpu(int fd, short event, void *arg)
>> -{
>> -struct event*ev = (struct event *)arg;
>> -struct timeval tv = { 60, 0 };/* every 60 seconds */
>> -int mib[3] = { CTL_KERN, KERN_CPTIME2, 0 }, n;
>> -size_t len;
>> -int64_t *cptime2;
>> -
>> -len = CPUSTATES * sizeof(int64_t);
>> -for (n = 0; n < snmpd_env->sc_ncpu; n++) {
>> -mib[2] = n;
>> -cptime2 = snmpd_env->sc_cpustates + (CPUSTATES * n);
>> -if (sysctl(mib, 3, cp_time[n], &len, NULL, 0) == -1)
>> -continue;
>> -(void)percentages(CPUSTATES, cptime2, cp_time[n],
>> -cp_old[n], cp_diff[n]);
>> -#ifdef DEBUG
>> -log_debug("timer_cpu: cpu%d %lld%% idle in %llds", n,
>> -
Re: snmpd(8) timer.c garbage collect
On Wed, Jan 22, 2020 at 10:51:45AM +0100, Martijn van Duren wrote:
> Trying to wrap my head around some of the snmpd code I found this pearl
> that appears to do nothing more than warm up the room.
Do you really want to get rid of the init of snmpd_env->sc_cpustates ?
-Otto
>
> OK?
>
> martijn@
>
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
> retrieving revision 1.16
> diff -u -p -r1.16 Makefile
> --- Makefile 11 May 2019 17:46:02 - 1.16
> +++ Makefile 22 Jan 2020 09:50:51 -
> @@ -3,7 +3,7 @@
> PROG=snmpd
> MAN= snmpd.8 snmpd.conf.5
> SRCS=parse.y log.c control.c snmpe.c \
> - mps.c trap.c mib.c smi.c kroute.c snmpd.c timer.c \
> + mps.c trap.c mib.c smi.c kroute.c snmpd.c \
> pf.c proc.c usm.c agentx.c traphandler.c util.c
>
> LDADD= -levent -lutil -lkvm -lcrypto
> Index: snmpd.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
> retrieving revision 1.86
> diff -u -p -r1.86 snmpd.h
> --- snmpd.h 2 Jan 2020 10:55:53 - 1.86
> +++ snmpd.h 22 Jan 2020 09:50:51 -
> @@ -745,9 +745,6 @@ unsigned int smi_application(struct ber
> void smi_debug_elements(struct ber_element *);
> char *smi_print_element(struct ber_element *);
>
> -/* timer.c */
> -void timer_init(void);
> -
> /* snmpd.c */
> int snmpd_socket_af(struct sockaddr_storage *, in_port_t, int);
> u_longsnmpd_engine_time(void);
> Index: snmpe.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
> retrieving revision 1.60
> diff -u -p -r1.60 snmpe.c
> --- snmpe.c 24 Oct 2019 12:39:27 - 1.60
> +++ snmpe.c 22 Jan 2020 09:50:51 -
> @@ -103,7 +103,6 @@ snmpe_init(struct privsep *ps, struct pr
>
> kr_init();
> trap_init();
> - timer_init();
> usm_generate_keys();
>
> /* listen for incoming SNMP UDP/TCP messages */
> Index: timer.c
> ===
> RCS file: timer.c
> diff -N timer.c
> --- timer.c 28 Oct 2016 08:01:53 - 1.7
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,169 +0,0 @@
> -/* $OpenBSD: timer.c,v 1.7 2016/10/28 08:01:53 rzalamena Exp $ */
> -
> -/*
> - * Copyright (c) 2008 Reyk Floeter
> - *
> - * Permission to use, copy, modify, and distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include "snmpd.h"
> -#include "mib.h"
> -
> -void timer_cpu(int, short, void *);
> -int percentages(int, int64_t *, int64_t *, int64_t *, int64_t *);
> -
> -static int64_t **cp_time;
> -static int64_t **cp_old;
> -static int64_t **cp_diff;
> -struct event cpu_ev;
> -
> -void
> -timer_cpu(int fd, short event, void *arg)
> -{
> - struct event*ev = (struct event *)arg;
> - struct timeval tv = { 60, 0 };/* every 60 seconds */
> - int mib[3] = { CTL_KERN, KERN_CPTIME2, 0 }, n;
> - size_t len;
> - int64_t *cptime2;
> -
> - len = CPUSTATES * sizeof(int64_t);
> - for (n = 0; n < snmpd_env->sc_ncpu; n++) {
> - mib[2] = n;
> - cptime2 = snmpd_env->sc_cpustates + (CPUSTATES * n);
> - if (sysctl(mib, 3, cp_time[n], &len, NULL, 0) == -1)
> - continue;
> - (void)percentages(CPUSTATES, cptime2, cp_time[n],
> - cp_old[n], cp_diff[n]);
> -#ifdef DEBUG
> - log_debug("timer_cpu: cpu%d %lld%% idle in %llds", n,
> - (cptime2[CP_IDLE] > 1000 ?
> - 1000 : (cptime2[CP_IDLE] / 10)), (long long) tv.tv_sec);
> -#endif
> - }
> -
> - evtimer_add(ev, &tv);
> -}
> -
> -void
> -timer_init(void)
> -{
> - int mib[] = { CTL_HW, HW_NCPU }, i;
> - size_t len;
> -
> - len
snmpd(8) timer.c garbage collect
Trying to wrap my head around some of the snmpd code I found this pearl
that appears to do nothing more than warm up the room.
OK?
martijn@
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile11 May 2019 17:46:02 - 1.16
+++ Makefile22 Jan 2020 09:50:51 -
@@ -3,7 +3,7 @@
PROG= snmpd
MAN= snmpd.8 snmpd.conf.5
SRCS= parse.y log.c control.c snmpe.c \
- mps.c trap.c mib.c smi.c kroute.c snmpd.c timer.c \
+ mps.c trap.c mib.c smi.c kroute.c snmpd.c \
pf.c proc.c usm.c agentx.c traphandler.c util.c
LDADD= -levent -lutil -lkvm -lcrypto
Index: snmpd.h
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
retrieving revision 1.86
diff -u -p -r1.86 snmpd.h
--- snmpd.h 2 Jan 2020 10:55:53 - 1.86
+++ snmpd.h 22 Jan 2020 09:50:51 -
@@ -745,9 +745,6 @@ unsigned int smi_application(struct ber
voidsmi_debug_elements(struct ber_element *);
char *smi_print_element(struct ber_element *);
-/* timer.c */
-voidtimer_init(void);
-
/* snmpd.c */
int snmpd_socket_af(struct sockaddr_storage *, in_port_t, int);
u_long snmpd_engine_time(void);
Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.60
diff -u -p -r1.60 snmpe.c
--- snmpe.c 24 Oct 2019 12:39:27 - 1.60
+++ snmpe.c 22 Jan 2020 09:50:51 -
@@ -103,7 +103,6 @@ snmpe_init(struct privsep *ps, struct pr
kr_init();
trap_init();
- timer_init();
usm_generate_keys();
/* listen for incoming SNMP UDP/TCP messages */
Index: timer.c
===
RCS file: timer.c
diff -N timer.c
--- timer.c 28 Oct 2016 08:01:53 - 1.7
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,169 +0,0 @@
-/* $OpenBSD: timer.c,v 1.7 2016/10/28 08:01:53 rzalamena Exp $ */
-
-/*
- * Copyright (c) 2008 Reyk Floeter
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "snmpd.h"
-#include "mib.h"
-
-voidtimer_cpu(int, short, void *);
-int percentages(int, int64_t *, int64_t *, int64_t *, int64_t *);
-
-static int64_t **cp_time;
-static int64_t **cp_old;
-static int64_t **cp_diff;
-struct event cpu_ev;
-
-void
-timer_cpu(int fd, short event, void *arg)
-{
- struct event*ev = (struct event *)arg;
- struct timeval tv = { 60, 0 };/* every 60 seconds */
- int mib[3] = { CTL_KERN, KERN_CPTIME2, 0 }, n;
- size_t len;
- int64_t *cptime2;
-
- len = CPUSTATES * sizeof(int64_t);
- for (n = 0; n < snmpd_env->sc_ncpu; n++) {
- mib[2] = n;
- cptime2 = snmpd_env->sc_cpustates + (CPUSTATES * n);
- if (sysctl(mib, 3, cp_time[n], &len, NULL, 0) == -1)
- continue;
- (void)percentages(CPUSTATES, cptime2, cp_time[n],
- cp_old[n], cp_diff[n]);
-#ifdef DEBUG
- log_debug("timer_cpu: cpu%d %lld%% idle in %llds", n,
- (cptime2[CP_IDLE] > 1000 ?
- 1000 : (cptime2[CP_IDLE] / 10)), (long long) tv.tv_sec);
-#endif
- }
-
- evtimer_add(ev, &tv);
-}
-
-void
-timer_init(void)
-{
- int mib[] = { CTL_HW, HW_NCPU }, i;
- size_t len;
-
- len = sizeof(snmpd_env->sc_ncpu);
- if (sysctl(mib, 2, &snmpd_env->sc_ncpu, &len, NULL, 0) == -1)
- fatal("sysctl");
-
- snmpd_env->sc_cpustates = calloc(snmpd_env->sc_ncpu,
- CPUSTATES * sizeof(int64_t));
- cp_time = calloc(snmpd_env->sc_ncpu, sizeof(int64_t *));
- cp_old = calloc(snmpd_env->sc_ncpu, sizeof(int64_t *));
- cp_diff = calloc(snmpd_en
Re: SMP friendly pfsync(4) ready for testing
Hello, sorry for typo in my earlier mail. > cd sys/arch/`uname -p`/conf > echo 'option WIT_PF_LOCK' >> GENERIC.MP > config GENERIC.MP > cd ../compile/GENERIC.MP/ > make clean > make do s/WIT_PF_LOCK/WITH_PF_LOCK in the snippet above. my apologize. thanks and regards sashan
Re: slaacd(8) improve movement between IPv6 & legacy-IP-only networks
Hello, Florian, Apologies for the delay in my response. I was mostly off-line for the last ten days or so. Inn-line On 10/1/20 03:56, Florian Obser wrote: Hi Fernando, On Thu, Jan 09, 2020 at 08:49:15AM -0300, Fernando Gont wrote: Hi, Pamela, [] Just happened to see this (sorry for the bad timing!). Note: It may be appropriate to remove existing addresses as soon as you realize you've connected to a different link (e.g., different SSID for wifi, or if you somehow detect a different net as per RFC6059). However, a link-state shouldn't, per-se, lead to addresses being removed. Otherwise, you might break e.g. existing TCP connections upon transient network problems. Pamela is currently busy with other things, so let me jump in here. I helped testing this and gave a bit of guidance where things are in slaacd(8) so I know a bit about the history. This had been considered and was actully my biggest fear so I always refused to implement something like this. For example what would happen if you hover right at the edge of wifi reception. Pamela and others then convinced me to try and see, and operational experience shows that this is not an issue at all. In fact the diff has been received overwhelmingly positive. No issues had been reported at all (and it has been in for a long time). We don't just nuke addresses on link state change, we go through the normal procedure of sending 3 router solicitations. Only if we receive no response do we remove the addreses. This seems to be good enough. A couple of things that might be worth considering. 1) If there has been a link sate change, there has been no obvious indication that the current network attachment point has changed, it may make sense to keep the addresses. e.g., consider the case where you experience a link state change, but the AP is the same, or there's no other advertised prefix, vs. the case where there has been a link state change event and the AP is a different one and/or a new prefix is advertised but the previous one isn't. One might argue that this one is a special case of https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-01 , where in this particular case (the one you've addressed) benefits of link state signaling, vs. the case we describe in our IETF draft, where you don't necessarily get link state events. (Proposed protocol updates here: https://raw.githubusercontent.com/fgont/draft-slaac-renum/master/draft-gont-6man-slaac-renum-02.txt) P.S.: Bottom-line is that if you cannot positively know you're on a different net, and you don't hear of a new prefix, you keep the addresses. And you try to remove them in a timely manner otherwise. Thanks! Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
