man.cgi: clean exit when absent or empty manpath.conf
Hi,
Starting to play with man.cgi (src/usr.bin/mandoc/cgi.c), it seems that
man.cgi will segfault if configuration file is absent or empty.
Here a patch that display error message and 505, like when MAN_DIR is
invalid.
Note: the segfault occurs in cgi.c:224 (http_parse), that assume
req-p is not NULL (req-q.manpath = req-p[0]).
The diff use the same style that when MAN_DIR is invalid (cgi.c:917), but that
could
be improved using err(3) ?
Thanks.
--
Sébastien Marie
Index: cgi.c
===
RCS file: /cvs/src/usr.bin/mandoc/cgi.c,v
retrieving revision 1.13
diff -u -p -r1.13 cgi.c
--- cgi.c 13 Jul 2014 15:38:06 - 1.13
+++ cgi.c 18 Jul 2014 06:43:14 -
@@ -966,8 +968,12 @@ pathgen(struct req *req)
char*dp;
size_t dpsz;
- if (NULL == (fp = fopen(manpath.conf, r)))
- return;
+ if (NULL == (fp = fopen(manpath.conf, r))) {
+ fprintf(stderr, manpath.conf not found in MAN_DIR (%s)\n,
+ MAN_DIR);
+ pg_error_internal();
+ exit(EXIT_FAILURE);
+ }
while (NULL != (dp = fgetln(fp, dpsz))) {
if ('\n' == dp[dpsz - 1])
@@ -975,5 +981,11 @@ pathgen(struct req *req)
req-p = mandoc_realloc(req-p,
(req-psz + 1) * sizeof(char *));
req-p[req-psz++] = mandoc_strndup(dp, dpsz);
+ }
+
+ if ( req-p == NULL ) {
+ fprintf(stderr, empty manpath.conf\n);
+ pg_error_internal();
+ exit(EXIT_FAILURE);
}
}
Re: man.cgi: clean exit when absent or empty manpath.conf
Salut Sebastien, Sébastien Marie wrote on Fri, Jul 18, 2014 at 08:50:17AM +0200: Starting to play with man.cgi (src/usr.bin/mandoc/cgi.c), Thank you for testing. it seems that man.cgi will segfault if configuration file is absent or empty. Here a patch that display error message and 505, like when MAN_DIR is invalid. Note: the segfault occurs in cgi.c:224 (http_parse), that assume req-p is not NULL (req-q.manpath = req-p[0]). The diff use the same style that when MAN_DIR is invalid (cgi.c:917), That is all very much to the point, thank you for finding and analysing the bug and providing a correct patch. I have tweaked the message strings a bit, committed your patch to both cvs.openbsd.org and mdocml.bsd.lv, and updated the installed man.cgi programs on both www.openbsd.org and mdocml.bsd.lv. but that could be improved using err(3) ? Well, i do like the err(3) family of functions for its clarity and conciseness, but so far, we have refrained from using them in mandoc for portability reasons. While it is trivial to provide compat functions for systems not having them, it is just as trivial to use fprintf(3), strerror(3), and exit(3) for now, so this is kind of a bikeshed. I guess at some point i will switch to using err(3), even POSIX considers adding them unless i heard an unfounded rumour... Yours, Ingo
call for bwi(4) testing
This diff for bwi(4) needs testing, both on systems where it works
and on systems where it spews these error messages to the console:
bwi0: intr fatal TX/RX (0) error 0x1000
bwi0: intr fatal TX/RX (1) error 0x1000
The point of this diff is to make the above errors go away.
But I need confirmation that it doesn't introduce any other issues.
The diff contains other small changes, such as loading the firmware
only once on startup to prevent a panic when the interrupt handler
decides to reset the device.
In my testing, the device works but I'm seeing some issues with low traffic
rates and dropped packets. However, I also had it work flawlessly for a
couple of hours. I suspect the device is not configured quite right to deal
with interference, as noted in the CAVEATS section of the bwi(4) man page.
Index: bwi.c
===
RCS file: /cvs/src/sys/dev/ic/bwi.c,v
retrieving revision 1.101
diff -u -p -r1.101 bwi.c
--- bwi.c 19 Mar 2014 10:09:19 - 1.101
+++ bwi.c 18 Jul 2014 16:08:36 -
@@ -73,6 +73,8 @@
#include dev/ic/bwireg.h
#include dev/ic/bwivar.h
+#include uvm/uvm.h
+
#ifdef BWI_DEBUG
int bwi_debug = 1;
#define DPRINTF(l, x...) do { if ((l) = bwi_debug) printf(x); } while
(0)
@@ -307,6 +309,7 @@ int bwi_dma_ring_alloc(struct bwi_soft
int bwi_dma_txstats_alloc(struct bwi_softc *, uint32_t,
bus_size_t);
voidbwi_dma_txstats_free(struct bwi_softc *);
+int bwi_dma_mbuf_create30(struct bwi_softc *);
int bwi_dma_mbuf_create(struct bwi_softc *);
voidbwi_dma_mbuf_destroy(struct bwi_softc *, int, int);
voidbwi_enable_intrs(struct bwi_softc *, uint32_t);
@@ -325,6 +328,7 @@ int bwi_init_txstats64(struct bwi_soft
voidbwi_setup_rx_desc64(struct bwi_softc *, int, bus_addr_t, int);
voidbwi_setup_tx_desc64(struct bwi_softc *, struct bwi_ring_data *,
int, bus_addr_t, int);
+int bwi_newbuf30(struct bwi_softc *, int, int);
int bwi_newbuf(struct bwi_softc *, int, int);
voidbwi_set_addr_filter(struct bwi_softc *, uint16_t,
const uint8_t *);
@@ -645,7 +649,7 @@ bwi_intr(void *xsc)
printf(intr PHY TX error\n);
/* XXX to netisr0? */
bwi_init_statechg(sc, 0);
- return (0);
+ return (1);
}
}
@@ -918,6 +922,7 @@ bwi_detach(void *arg)
bwi_mac_detach(sc-sc_mac[i]);
bwi_dma_free(sc);
+ bwi_dma_mbuf_destroy(sc, BWI_TX_NRING, 1);
return (0);
}
@@ -1720,11 +1725,14 @@ bwi_mac_fw_alloc(struct bwi_mac *mac)
char fwname[64];
int idx, error;
- error = loadfirmware(name, mac-mac_fw, mac-mac_fw_size);
- if (error != 0) {
- printf(%s: error %d, could not read firmware %s\n,
- sc-sc_dev.dv_xname, error, name);
- return (EIO);
+ if (mac-mac_fw == NULL) {
+ error = loadfirmware(name, mac-mac_fw, mac-mac_fw_size);
+ if (error != 0) {
+ printf(%s: error %d, could not read firmware %s\n,
+ sc-sc_dev.dv_xname, error, name);
+ mac-mac_fw = NULL;
+ return (EIO);
+ }
}
if (mac-mac_ucode == NULL) {
@@ -6219,6 +6227,9 @@ bwi_setup_desc32(struct bwi_softc *sc, s
struct bwi_desc32 *desc = desc_array[desc_idx];
uint32_t ctrl, addr, addr_hi, addr_lo;
+ if (sc-sc_bus_space == BWI_BUS_SPACE_30BIT paddr = 0x4000)
+ panic(bad paddr 0x%lx\n, (long)paddr);
+
addr_lo = __SHIFTOUT(paddr, BWI_DESC32_A_ADDR_MASK);
addr_hi = __SHIFTOUT(paddr, BWI_DESC32_A_FUNC_MASK);
@@ -7512,6 +7523,13 @@ bwi_node_alloc(struct ieee80211com *ic)
return ((struct ieee80211_node *)bn);
}
+struct uvm_constraint_range bwi_constraint = { 0x0, (0x4000 - 1) };
+struct kmem_pa_mode bwi_pa_mode = {
+ .kp_align = BWI_RING_ALIGN,
+ .kp_constraint = bwi_constraint,
+ .kp_zero = 1
+};
+
int
bwi_dma_alloc(struct bwi_softc *sc)
{
@@ -7529,6 +7547,14 @@ bwi_dma_alloc(struct bwi_softc *sc)
switch (sc-sc_bus_space) {
case BWI_BUS_SPACE_30BIT:
+ /* 30bit devices must use bounce buffers but
+* otherwise work like 32bit devices. */
+ sc-sc_newbuf = bwi_newbuf30;
+
+ /* XXX implement txstats for 30bit? */
+ has_txstats = 0;
+
+ /* FALLTHROUGH */
case BWI_BUS_SPACE_32BIT:
desc_sz = sizeof(struct bwi_desc32);
txrx_ctrl_step = 0x20;
@@ -7537,6 +7563,8 @@ bwi_dma_alloc(struct bwi_softc *sc)
sc-sc_free_tx_ring =
Re: LibreSSL and GOST crypto
I have been pointed that I did not formulate the question clearly. Would you prefer to have a static ENGINE thing built into the LibreSSL, providing 100% API compatibility with original ccgost implementation, or it would be better to have a cleaner well-integrated cryptosuite? As already replied by Theo, the LibReSSL position is that GOST algorithms should be implemented as `built-in' algorithm, just like the others (DES, AES, RSA, ECDH...) are; and that they should be available via the EVP interface. Speaking for myself, I am not very fond of the OpenSSL-inherited ENGINE interface; and I'd rather have my crypto built-in, than dependent upon the phase of the moon and whatever uid I might be running as, as well as filesystem permissions. Miod
Only what you need
Hi, Something that has been in my eye for a while; how about those users and groups? $ cat /etc/passwd|wc -l 56 $ cat /etc/group |wc -l 75 Maybe one group for write access to /var, one for /etc, etc? //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Only what you need
Something that has been in my eye for a while; how about those users and groups? $ cat /etc/passwd|wc -l 56 $ cat /etc/group |wc -l 75 Maybe one group for write access to /var, one for /etc, etc? Or we could run them all as root.
Re: [patch] sys/dev/ic/mfi.c
Hi,
I think is a bug in sys/dev/ic/mfi.c noticed during
PATCH: further kernel malloc - mallocarray review[1]
I see the mallocarray() patch seems to have been applied.
Want to make sure if this is in fact a bug, that it is
not overlooked.
Ignore if this is noise.
That diff looks correct to me; can anyone with mfi(4) test it and check
the sensors are behaving correctly?
Index: mfi.c
===
RCS file: /cvs/src/sys/dev/ic/mfi.c,v
retrieving revision 1.154
diff -u -p -u -p -r1.154 mfi.c
--- mfi.c 13 Jul 2014 23:10:23 - 1.154
+++ mfi.c 16 Jul 2014 17:57:04 -
@@ -2149,7 +2149,7 @@ mfi_create_sensors(struct mfi_softc *sc)
}
sc-sc_bbu_status = malloc(sizeof(*sc-sc_bbu_status) *
- sizeof(mfi_bbu_indicators), M_DEVBUF, M_WAITOK | M_ZERO);
+ nitems(mfi_bbu_indicators), M_DEVBUF, M_WAITOK | M_ZERO);
for (i = 0; i nitems(mfi_bbu_indicators); i++) {
sc-sc_bbu_status[i].type = SENSOR_INDICATOR;
[DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Hi, is this correct to reflect syslog_r(3) change? I tested chrooted internal-sftp without /dev/log in the chroot and it was logging fine. j. Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -p -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 18 Jul 2014 20:58:23 - @@ -139,16 +139,6 @@ Sets an explicit to be applied to newly-created files and directories, instead of the user's default mask. .El -.Pp -For logging to work, -.Nm -must be able to access -.Pa /dev/log . -Use of -.Nm -in a chroot configuration therefore requires that -.Xr syslogd 8 -establish a logging socket inside the chroot directory. .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -p -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 18 Jul 2014 20:58:24 - @@ -344,12 +344,7 @@ devices. For file transfer sessions using .Dq sftp , no additional configuration of the environment is necessary if the -in-process sftp server is used, -though sessions which use logging do require -.Pa /dev/log -inside the chroot directory (see -.Xr sftp-server 8 -for details). +in-process sftp server is used. .Pp The default is not to .Xr chroot 2 .
Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Unfortunately, no. The ssh manual pages are also used by the -portable effort. We do not bother documenting these divergences; there is little harm. Actually you could submit a new diff which suggest that logging might need a /dev/log setup. If written carefully to cover both kinds of systems, that would be accepted. is this correct to reflect syslog_r(3) change? I tested chrooted internal-sftp without /dev/log in the chroot and it was logging fine. j. Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -p -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 18 Jul 2014 20:58:23 - @@ -139,16 +139,6 @@ Sets an explicit to be applied to newly-created files and directories, instead of the user's default mask. .El -.Pp -For logging to work, -.Nm -must be able to access -.Pa /dev/log . -Use of -.Nm -in a chroot configuration therefore requires that -.Xr syslogd 8 -establish a logging socket inside the chroot directory. .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -p -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 18 Jul 2014 20:58:24 - @@ -344,12 +344,7 @@ devices. For file transfer sessions using .Dq sftp , no additional configuration of the environment is necessary if the -in-process sftp server is used, -though sessions which use logging do require -.Pa /dev/log -inside the chroot directory (see -.Xr sftp-server 8 -for details). +in-process sftp server is used. .Pp The default is not to .Xr chroot 2 .
Re: lynx: disable old protocols
On 17 July 2014 00:10, Stuart Henderson st...@openbsd.org wrote: On 2014/07/16 16:00, Jean-Philippe Ouellet wrote: Oh come on... It's not like the URLs are some giant uuid-based madness or something. All the mirrors have the same simple layout. If you install lots of boxes regularly, it doesn't take long to memorize the name of your closest mirror. If you don't install lots of stuff, then just set installpath in your pkg.conf and forget about it. If you choose your mirror from the list in the installer, this is already set automatically in pkg.conf. Hello Stuart, what would you suggest for situations where installXX.iso is burned to a CD to avoid downloading sets from the net due a slow Internet connection? When sets are installed from the CD it doesn't set PKG_PATH. I couldn't find any mirror list from the ISO image by grepping. Previously I've used lynx to navigate on the project's website and copypaste mirror URL with tmux. Thanks in advance, Ville
Re: lynx: disable old protocols
ftp -o - http://ftp.openbsd.org/pub/OpenBSD/snapshots/ftplist | some script, or maybe your eyes and pick one. On Fri, Jul 18, 2014 at 4:29 PM, Ville Valkonen weezeld...@gmail.com wrote: On 17 July 2014 00:10, Stuart Henderson st...@openbsd.org wrote: On 2014/07/16 16:00, Jean-Philippe Ouellet wrote: Oh come on... It's not like the URLs are some giant uuid-based madness or something. All the mirrors have the same simple layout. If you install lots of boxes regularly, it doesn't take long to memorize the name of your closest mirror. If you don't install lots of stuff, then just set installpath in your pkg.conf and forget about it. If you choose your mirror from the list in the installer, this is already set automatically in pkg.conf. Hello Stuart, what would you suggest for situations where installXX.iso is burned to a CD to avoid downloading sets from the net due a slow Internet connection? When sets are installed from the CD it doesn't set PKG_PATH. I couldn't find any mirror list from the ISO image by grepping. Previously I've used lynx to navigate on the project's website and copypaste mirror URL with tmux. Thanks in advance, Ville
tcpdump(8) not printing llc data for ieee80211
Sometimes tcpdump(8) does not print llc higher layer data when using -y IEEE802_11 or IEEE802_11_RADIO. Index: print-802_11.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v retrieving revision 1.13 diff -u -p -r1.13 print-802_11.c --- print-802_11.c 17 Jan 2013 02:53:07 - 1.13 +++ print-802_11.c 19 Jul 2014 03:48:02 - @@ -153,7 +153,7 @@ ieee80211_data(struct ieee80211_frame *w u_int8_t *t = (u_int8_t *)wh; struct ieee80211_frame_addr4 *w4; u_int datalen; - int data = !(wh-i_fc[1] IEEE80211_FC0_SUBTYPE_NODATA); + int data = !(wh-i_fc[0] IEEE80211_FC0_SUBTYPE_NODATA); u_char *esrc = NULL, *edst = NULL; TCHECK(*wh); Nathanael
misprint in cvs(1) man page
There is misprint in cvs(1) man page for import command: 'You can use this command both for initial creation of a repository, and for wholesale updates to the module _form_ the outside source' must be: 'You can use this command both for initial creation of a repository, and for wholesale updates to the module _from_ the outside source'
