Re: klog message buffer full

Alexander Bluhm wrote: > This also gets me closer to my goal of reliable logging. > > Do we want this feature? yes, and I'd say always. > +#ifndef SMALL_KERNEL > + if (mbp->msg_bufd > 0) { > + char buf[64]; This is not so much code that I'm worried about it on small kernels.

Re: add mirror discovery to pkg_add

Marc Espie wrote: > This would allow pkg_add to auto-configure a mirror, for the case where > PKG_PATH was not specified and where pkg.conf does not exist. > > It only triggers when a location ends up empty and when run in interactive > mode, e.g., it shouldn't interfere with local lookups. > >

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

Brent Cook wrote: > diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c > b/src/lib/libssl/src/crypto/dsa/dsa_key.c > index 2968fa2..e01bacb 100644 > --- a/src/lib/libssl/src/crypto/dsa/dsa_key.c > +++ b/src/lib/libssl/src/crypto/dsa/dsa_key.c > -#endif > +#endif > \ No newline at end of file

Re: cbfb: coreboot framebuffer console

joshua stein wrote: > +int > +cb_parse_table(paddr_t addr) > +{ > + int i, j; > + > + for (i = 0; i < (4 * 1024); i += 16) { > + struct cb_header *cbh; > + struct cb_entry *cbe; > + void *cbtable; > + > + cbh = (struct cb_header

Re: lockmgr() api removal

Martin Natano wrote: > It is time for the lockmgr() api to die. The api is only used by > filesystems, where it is a trivial change to use rrw locks instead. All > it needs is LK_* defines for the RW_* flags. (See the sys/lock.h hunk in > the diff below.) > > The ffs regress tests display the

kern continue

a few more here and there. Index: ddb/db_examine.c === RCS file: /cvs/src/sys/ddb/db_examine.c,v retrieving revision 1.21 diff -u -p -r1.21 db_examine.c --- ddb/db_examine.c19 Apr 2016 12:23:25 - 1.21 +++

more continue loops

this is in sbin. i left csh and ksh in bin for some other brave soul. Index: dump/main.c === RCS file: /cvs/src/sbin/dump/main.c,v retrieving revision 1.57 diff -u -p -r1.57 main.c --- dump/main.c 20 Aug 2015 22:02:20 -

x99token login_token etc.

We have a bunch of DES token utilities which were probably useful circa 1995 with diminishing utility over the course of the next decade, followed by a decade in which I suspect they were of very dminished utility. I think we can purge these, and if people really, really need them, they can live

Re: kdump small timespecs

Ted Unangst wrote: > Philip Guenther wrote: > > I think it would be better to include the clock_t value in the > > timespec struct tracing, then branch on that. > > I of course looked at that, but it's a lot of plumbing... If there is no serious objection, I'd like to go ah

Re: Website HTTPS

Robert Tate wrote: > It looks like the cert used when you access the site with openbsd.org > is only good for www.openbsd.org and so browsers will give warnings > when accessing https://openbsd.org/. So don't access https://openbsd.org/?

dhclient reboot interval

Is there a reason the reboot timeout is so long? Here's what I observe. I connect to one network and get a lease. Later, I connect to a different network. dhclient then spends an annoyingly long time doing this: DHCPREQUEST on iwm0 to 255.255.255.255 DHCPREQUEST on iwm0 to 255.255.255.255

Re: kdump small timespecs

Philip Guenther wrote: > On Wed, Jun 1, 2016 at 10:37 AM, Theo de Raadt > wrote: > >> Mark Kettenis wrote: > >> > I sympathise with the idea, but your implementation would still print > >> > "funny" times if your machine had been up for more than a day. > >> > >> The

kdump relative timestamps

Relative timestamps are much easier to decipher than absolute, when attempting to determine a program's behavior. Most of the time I care about how long since the last time. However, if I grep the output, then I lose the basis for relative times, and am back to doing large number substraction in

Re: kdump small timespecs

Mark Kettenis wrote: > I sympathise with the idea, but your implementation would still print > "funny" times if your machine had been up for more than a day. The perils of rebooting. I tested with an hour, then bumped to a day for margin. But really, I think even up to ten years would work. Any

continue in empty loops

I find this easier to read. My old eyes don't focus on the semicolon, which makes me wonder what's supposed to be happening. Index: pax/ar_io.c === RCS file: /cvs/src/bin/pax/ar_io.c,v retrieving revision 1.55 diff -u -p -r1.55

ancient relics in newsyslog

Let's make the defaults be the defaults. Index: Makefile === RCS file: /cvs/src/usr.bin/newsyslog/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile30 Mar 2016 06:38:46 - 1.6 +++ Makefile1 Jun

Re: utvfu driver port

Marcus Glocker wrote: > Me too. Would it be ok to merge utvfu.c and utvfu_ops.c by including > both Copyrights in this file? Should it be > > [Copyright 1] > [Code 1] > [Copyright 2] > [Code 2] > > or > > [Copyright 1] > [Copyright 2] > [Code 1] >

less rthread debug noise

since changing the malloc spinlock to a mutex, it gets roped into the rthread_debug print outs, which contribute massive noise. bypass the logging. Index: rthread.h === RCS file: /cvs/src/lib/librthread/rthread.h,v retrieving

kdump small timespecs

Small timespecs print funny: 57686 chrome CALL clock_gettime(CLOCK_MONOTONIC,0x7f7f0028) 57686 chrome STRU struct timespec { 15411<"Dec 31 23:16:51 1969">.584609082 } 57686 chrome RET clock_gettime 0 57686 chrome CALL clock_gettime(CLOCK_MONOTONIC,0x7f7eff48) 57686

delete OSIOCGIFCONF

it's dead. Index: sockio.h === RCS file: /cvs/src/sys/sys/sockio.h,v retrieving revision 1.63 diff -u -p -r1.63 sockio.h --- sockio.h2 Mar 2016 00:00:16 - 1.63 +++ sockio.h31 May 2016 18:56:49 - @@ -54,7 +54,6

Re: lockmgr() api removal

Martin Natano wrote: > It is time for the lockmgr() api to die. The api is only used by > filesystems, where it is a trivial change to use rrw locks instead. All > it needs is LK_* defines for the RW_* flags. (See the sys/lock.h hunk in > the diff below.) > > The ffs regress tests display the

Re: ptrace PT_IO write bug

Jeremie Courreges-Anglas wrote: > >> > >> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent > >> since rev. 1.1, I doubt that such an optimization is a good idea. > > > > A clear case where the documentation is wrong. > > > The documentation may have been wrong for some time

Re: poll magic for pflogd

Tobias Ulmer wrote: > On Tue, Sep 22, 2015 at 11:46:08AM -0400, Ted Unangst wrote: > > Todd C. Miller wrote: > > > On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote: > > > > > > > We can put a "long" poll() in front of pcap to

Re: pool related crashes, but "kernel did no panic"

Alexey Suslikov wrote: > On Thu, May 12, 2016 at 4:14 PM, Bob Beck wrote: > > Thank you!now that's a bug report.. > > Hi. > > Moved to 6.0-beta some time ago to make crash dumps more up > to date. Also, removed some services to minimize their impact. > > Fresh build

Re: [libcrypto] fix short ASN1 reads

Brent Cook wrote: > Hi, > > Our errata patch for fixing large memory allocations in > asn1_d2i_read_bio dropped the while (want > 0) loop, causing the > function to only read chunk_max bytes once. This limits the max size > read to 16k. This patch restores the outer loop. Noted on misc@ > >

Re: usb: cache vendor, product and serial

Patrick Wildt wrote: > The same issue can be reproduced by calling usbdevs(8) in a loop. It > uses the same ioctl and "breaks" this usb mass storage. As a rule, we should limit the contact users have with hardware. "Safe" readonly operations are no exception.

Re: New 12" Retina Macbook (Macbook9,1)

Bryan C. Everly wrote: > I just received my 12" Retina Macbook (the Macbook9,1) which is the > latest Skylake version. I would really like to get OpenBSD running on > this and am happy to trace any code, build patches, stand on my head, > etc. if I could get someone interested in working with me

cleanup pppd passwd check

Use crypt_checkpass. Note that this introduces a slight functional change. A user with a blank password will be allowed to login with a blank password. I think if you don't like that, you should give the user a password. Bonus: if the user is not found, hashing work is still performed to prevent

Re: [PATCH] Allow softraid crypto to work with write-protected keys

bytevolc...@safe-mail.net wrote: > > Index: sys/dev/softraid_crypto.c > === > RCS file: /cvs/src/sys/dev/softraid_crypto.c,v > retrieving revision 1.126 > diff -u -p -r1.126 softraid_crypto.c > --- sys/dev/softraid_crypto.c 12 Apr

Re: [ntpd] Simultaneously listen on IPv4 and IPv6

Theo de Raadt wrote: > From the beginning we were promised that modifying a program to use > IPv6 only required opening a 2nd socket using AF_INET6. Then the > recipes grew, and grew and grew. It went astray. > > 10,000 programs don't follow the practice. If everyone has to follow > this

Re: [ntpd] Simultaneously listen on IPv4 and IPv6

Theo de Raadt wrote: > In general, I think -portable's should not add it back without really > clear justification. The automatic tunnels are just as risky outside > OpenBSD, because their packet filter tools encounter the same > difficulty protecting against abuse. But in this case, using the

cleanup pppd auth

While making a small change to pppd, I noticed there is a lot of PAM and shadow code which is not relevant to us. The aspiring developer may then switch to bsd auth or even just crypt_checkpass, but first purge the tangly morass. Index: auth.c

sendbug subject

i'm tired of seeing bug reports with no subject. i also get a fair bit of spam with no subject and i am easily confused. something is better than nothing. Index: sendbug.c === RCS file: /cvs/src/usr.bin/sendbug/sendbug.c,v

bioctl errx

overzealous use of errx() hides useful information about the error. Index: bioctl.c === RCS file: /cvs/src/sbin/bioctl/bioctl.c,v retrieving revision 1.130 diff -u -p -r1.130 bioctl.c --- bioctl.c4 Feb 2016 08:31:26 -

fsync option for install

install has a "safe mode" -S option, although it's not as entirely safe as one might assume. It relies on rename() being an atomic operation, which is good. However, rename doesn't guarantee that a file's *contents* are on disk. Thus, there is a window between the rename and the eventual flushing

Re: remove kevent perm check

Theo de Raadt wrote: > > > > I think we should remove the check. It doesn't make sense, and it's > > > > different > > > > from other systems using kqueue. (I also had to work around it in > > > > rebound, > > > > where some code could be organized better if it weren't for the need to > > > >

remove kevent perm check

There is a permission check for EVFILT_PROC that is not documented. Actually, it directly contradicts the documentation, which says you can watch any process you can see. The documented behavior makes sense, since I could also just run ps in a tight loop and get the same info, only less

Re: Allow top(1) to search arguments (again)

this improves the realloc loop. there is no need to constantly call realloc to resize the memory. if we have enough, we have enough. also no need to penny pinch the initial allocation. calling sysctl all the time is still wasteful, but harder to fix. Index: machine.c

Re: tidy strstr.3

Michal Mazurek wrote: > * add explicit RETURN VALUES section > * add an EXAMPLES section, from NetBSD and FreeBSD > * mention memmem(3) does it really need an example? is strcpy next? other changes make sense.

free size for descript tables

this is tricky, but not too hard. expanded dfff context to see the malloc. Index: kern_descrip.c === RCS file: /cvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.130 diff -u -p -u -1 -7 -r1.130 kern_descrip.c --- kern_descrip.c

bcopy in libkvm

memcpy is newer and better. Index: kvm.c === RCS file: /cvs/src/lib/libkvm/kvm.c,v retrieving revision 1.59 diff -u -p -r1.59 kvm.c --- kvm.c 19 Dec 2015 18:40:30 - 1.59 +++ kvm.c 10 May 2016 22:46:07 - @@

Re: Allow top(1) to search arguments (again)

Edd Barrett wrote: > On Thu, Apr 28, 2016 at 03:26:48PM +0100, Edd Barrett wrote: > > Resubmitting this diff, as I've been unable to get an OK. > > Style tweaks fixed, as pointed out by Michal Mazurek. Thanks for this. > > OK? ok

Re: httpd: patch for portability asprintf use

Theo de Raadt wrote: > > If OpenBSD's behavior of asprintf is non-standard and everyone else is > > doing it differently, we would probably have to apply the patch. But this > > would also affect many other places in the tree were we rely on our > > asprintf semantics. > > Actually, we have fixed

Re: enable shadow only pwd

Stuart Henderson wrote: > If you'd sent this 10 days ago we could have had enough of them > fixed at p2k16. As I won't have time to do that now, here are and here i waited until after to avoid causing trouble. my bad.

enable shadow only pwd

i think it's time. otherwise we'll never find the bugs. Index: gen/getpwent.c === RCS file: /cvs/src/lib/libc/gen/getpwent.c,v retrieving revision 1.60 diff -u -p -r1.60 getpwent.c --- gen/getpwent.c 28 Dec 2015 22:08:18 -

Re: libcrypto errata

Ted Unangst wrote: > http://ftp.openbsd.org/pub/OpenBSD/patches/5.9/common/005_crypto.patch.sig There is an additional chunk in this diff, for s3_pkt.c, that should have not been included. It adds a memset that will zero a buffer after libssl is done using it to prevent info leaks. As far a

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

Alexander Bluhm wrote: > On Tue, May 03, 2016 at 12:20:34AM -0400, Ted Unangst wrote: > > Alexander Bluhm wrote: > > > > > > Can we have the same logic for KERN_FILE_BYPID and KERN_FILE_BYUID? > > > > I think this should be BYPID only. I'm not sure why. Ma

libcrypto errata

OpenSSL announced several issues today that also affect LibreSSL. - Memory corruption in the ASN.1 encoder (CVE-2016-2108) - Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) - EVP_EncodeUpdate overflow (CVE-2016-2105) - EVP_EncryptUpdate overflow (CVE-2016-2106) - ASN.1 BIO excessive memory

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

Alexander Bluhm wrote: > > Can we have the same logic for KERN_FILE_BYPID and KERN_FILE_BYUID? I think this should be BYPID only. I'm not sure why. Maybe because a user exists even when the user isn't running any processes. But a process doesn't exist when it doesn't exist.

Re: sqlite c api manpages?

Kristaps Dzonsons wrote: > If you're on OpenBSD, you started with "apropos -s3 sqlite3", were > shocked that there's nothing there, then moved on to Google with a > wounding confusion in your heart. Indeed. I see this didn't get much traction, but it sounds good to me. We are shipping sqlite as a

Re: DMA overruns and iommu's

Mark Kettenis wrote: > It is pretty clear that the DMA engine on the Davicom dc(4) hardware > is broken and will read beyond the end of the buffer that we pass it. > This is bad news for hardware that uses an IOMMU, as it will detect > the DMA overrun and (at least on sparc64) signal an

Re: multi-pool malloc wip diff

Otto Moerbeek wrote: > static void > -ofree(struct dir_info *pool, void *p) > +ofree(struct dir_info *argpool, void *p) > { > + struct dir_info *pool; > struct region_info *r; > size_t sz; > + int i; > > + pool = argpool; > r = find(pool, p); > if (r ==

Re: doas: adjust yyerror() output

Gleydson Soares wrote: > > what about just printing "doas: "? > > I prefer not hardcoded string, although I've committed as you pointed out, getprogname() doesn't seem any more portable than __progname, which is the classic means of doing this. It's useful in cases where a program may have more

Re: doas: adjust yyerror() output

Gleydson Soares wrote: > > I just stumbled over this... > > % doas abc > syntax error at line 1 > % > > I took some secs trying to figure out what was wrong with abc's command > syntax that I typed out. > But bingo, It was happenned due my doas.conf has a syntax error... > Seems that

Re: more systrace mop up 2/2: man8.${ARCH}/MAKEDEV.8

Theo Buehler wrote: > Index: share/man/man8//man8.alpha/MAKEDEV.8 please note the comment at the top of these files. they are autogenerated.

Re: Clearing environ

Todd C. Miller wrote: > On Mon, 25 Apr 2016 22:39:48 +0200, Jeremie Courreges-Anglas wrote: > > > Agreed, I also had this in mind. But then, should the memset call with > > a zero size be avoided? > > > > if (lastenv != environ) > > memcpy(P, environ, cnt * sizeof(char *)); > >

Re: Clearing environ

Jeremie Courreges-Anglas wrote: > > A few ports make use of clearenv(3), a GNU extension. This function was > rejected by POSIX, so what's left? > I think ports should probably use calloc here if we want to push those > patches upstream. But supporting the "environ = NULL" method looks >

Re: anti-ROP mechanism in libc

Robert Peichaer wrote: > On Mon, Apr 25, 2016 at 10:57:37AM -0400, Ted Unangst wrote: > > Theo de Raadt wrote: > > > + cp -p /usr/lib/$_lib /usr/lib/$_tmplib > > > + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib && > &g

Re: anti-ROP mechanism in libc

Theo de Raadt wrote: > + cp -p /usr/lib/$_lib /usr/lib/$_tmplib > + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib && > + rm -f /usr/lib/$_tmplib || > + mv /usr/lib/$_tmplib /usr/lib/$_lib I'm a

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 s

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

Re: manual section search order

Marc Espie wrote: > Parentheses are okay in urls, so I see no reason why: > > man.openbsd.org/carp(4) > > shouldn't work. There are an astounding number of text to html URL parsers/highlighters that cannot quite handle parentheses. That's not our problem, but instead of trying to boil the

Re: bufcache KNF

Mark Kettenis wrote: > And prototypes with names in public headers are still an issue. I think you misspelled standard. :)

Re: bufcache KNF

Martin Pieuchot wrote: > ok? > > -int chillbufs(struct > -bufcache *cache, struct bufqueue *queue, int64_t *queuepages); > +int chillbufs(struct bufcache *, struct bufqueue *, int64_t *); fwiw i like names in prototypes, so i know what's going on. i know style says that, but i think the

Re: tcpdump man page

Edgar Pettijohn wrote: > The -i flag doesn't appear to do what the man page suggests. Correcting > the source is above my paygrade, but the man page isn't. hmm? what do you think tcpdump does if -i isn't specified? > > Index: tcpdump.8 >

Re: patch: serialize multiple threads calling pledge(2)

Sebastien Marie wrote: > Hi, > > The following diff makes the effect of multiple threads calling > pledge(2) to be serializable. > > It adds a loop (with tsleep(9)) at pledge(2) entrance if another thread > is already inside (due to sleep), changes return to goto statment, and > wakeup other

Re: tidy syscall_mi.h

Michal Mazurek wrote: > Depending on the NOLOCK flag, the KERNEL_LOCK will, or will not be acquired > before calling pledge_syscall(). I therefore conclude that KERNEL_LOCK > is not needed to call pledge_syscall(). > > Also remove the goto. The code is simple enough to avoid it easily. > > I

Re: [patch] ftpd: unused include

frit...@alokat.org wrote: > Looks like monitor.h doesn't need to be included > in monitor_fdpass.c. > > Mentioned by att...@stalphonsos.com. it's better if the declaration and definition of functions always match.

Re: tcp syn cache random reseed

Alexander Bluhm wrote: > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > > The drawback is that the the cache lookup has to be done in two syn > > caches when an ACK arrives. > > This can be prevented most of the time. Switch the cache only after > 10 uses. So most of the

Re: Scheduler hack for multi-threaded processes

Mark Kettenis wrote: > So here is a diff that keeps yield() the same and adds the code in the > sched_yield(2) implementation instead. It also changes the logic that > picks the priority to walk the complete threads listand pick the > highest priotity of all the threads. That should be enough to

Re: uvm: shrinking amap kmem consumption

Stefan Kempf wrote: > To reduce these memory requirements, we need three flavors of amaps: > > - Tiny amaps with only one slot store the pointer to the vm_anon in the > amap directly. The two ints are not needed. This was Theo's idea. > > - Small amaps with up to 32 slots need 8 instead of 16

Re: OpenBSD ASLR and the stack

Shawn Webb wrote: > Does OpenBSD's ASLR implementation also randomize the top stack address? > Or is it simply a random gap (top of the stack still at the same > address, but application starts utilizing the stack at a random, but > properly aligned, offset)? The top of the stack, above the

Re: Replace less(1)'s stdbool clone with the real McCoy

Ingo Schwarze wrote: > Hi Michael, > > Michael McConville wrote on Fri, Jan 29, 2016 at 11:33:50AM -0500: > > > Does this make sense? > > We usually don't use bool, it is pointless. > > I'd say leave the type as int, just delete the silly macros, > and use 0 and 1 directly. To throw in my

Re: domainname(1) - make usage __dead

Gleydson Soares wrote: > -void > +__dead static void > usage(void) > { > (void)fprintf(stderr, "usage: %s [name-of-domain]\n", __progname); do we have a preferred order for these words? i always use static void __dead because i like the real C keywords first, then the annotations to

Re: bug in fputwc(3) error reporting

Ingo Schwarze wrote: > Consequently, i propose to not revert our fgetwc(3) patch and to > commit this fputwc(3) patch, too, making us agree with FreeBSD, > NetBSD, Dragonfly, SunOS, glibc, and POSIX, even tough nominally > violating the C standard (but in a way that seems less dangerous > than the

Re: security(8) mailbox check question

Ingo Schwarze wrote: > the smtpd(8) daemon supports "deliver to maildir" out of the box, > and even though putting the user maildirs below /var/mail/ is not > the default, it's one of many possible and logical choices, and i > see nothing wrong with it. I think the possibility to fill up /var

Re: [patch] ls + utf-8 support

Ingo Schwarze wrote: > The old ls(1) also weeded out non-printable bytes, in particular > control codes. The old ls only had this behavior for terminals however. Redirecting to a file or pipe would always output the original bytes.

ifconfig format bug

ifconfig.c: In function 'print_media_word': ifconfig.c:2776: error: format '%d' expects type 'int', but argument 2 has type 'long long unsigned int' maybe a cast to int is ok? but if there's no harm in printing the whole thing, i believe that's safer. Index: ifconfig.c

hash ports in trunk?

If you're trying to utilize multiple links for aggregation, etc., you have to ensure that the packets get hashed differently. Currently we use MAC address and IP address, but not port numbers. This makes it challenging to connect two servers unless you jump through some hoops and assign multiple

Re: OpenBSDVMM58 -> OpenBSDVMM59 in vmmvar.h

unless something has actually changed, it should not be necessary to increment this number. the vmm in 5.9 will still speak the same protocol as the vmm that appeared after 5.8. Michal Mazurek wrote: > Index: vmmvar.h > === > RCS

Re: allocation simplifications in yacc

Michael McConville wrote: > Christian Weisgerber wrote: > > Christian Weisgerber: > > > > > The removal of the casts causes a problem in ports/devel/mico, where > > > the yacc output is used in C++: > > > > Also: > > graphics/grap > > math/aamath > > math/logic2cnf > > ok? > "

xr mktime

Neither strftime nor strptime describe the fields inside struct tm, and while they eventually point that way in references, strftime provides no guidance as to which of its nine (9!) references I should read next. I don't like guessing. Index: strftime.3

Re: allocation simplifications in yacc

Mark Kettenis wrote: > > Date: Wed, 30 Dec 2015 11:30:11 -0500 > > From: Michael McConville > > > > Christian Weisgerber wrote: > > > Christian Weisgerber: > > > > > > > The removal of the casts causes a problem in ports/devel/mico, where > > > > the yacc output is used in

Re: [patch] kern/exec_script: avoid invalid free() in a case of error

Michael McConville wrote: > Michael McConville wrote: > > Michael McConville wrote: > > > > On Sun, Dec 13, 2015 at 9:45 PM, Maxim Pugachev > > > > wrote: > > > > > Hi, > > > > > > > > > > In exec_script_makecmds function, when EXEC_HASFD flag was set, but > > > > >

Re: ifconfig: remove undocumented -carpdev

Fabian Raetz wrote: > Hi, > > please find below a patch to remove the undocumented -carpdev command from > ifconfig(8). wouldn't it make more sense to document the command?

Re: strncpy->strlcpy question

Philip Guenther wrote: > On Fri, Dec 25, 2015 at 8:21 PM, Ricardo Mestre > wrote: > > I made an inspection on userland tree and there quite a few applications > > still > > using strncpy(3) instead of strlcpy(3). Some of them may never need that > > safety > > since

ksh rename global e

I'm slowly trimming down some of the -Wshadow warnings in bin and one big offender is ksh. Namely, it has a local variable e that shadows a global e. -struct env *e; +struct env *genv; Normally I rename the local, but in this case I think the global deserves a better name. Note that this

ksh another home/end pair

In tmux, home and end send different bytes. I don't know why, but I want things to just work. We already have two different keys here, so what's one more? (how many can there be...?) Index: emacs.c === RCS file:

Re: bug in fputwc(3) error reporting

Philip Guenther wrote: > On Tue, Dec 29, 2015 at 2:34 PM, Todd C. Miller > wrote: > ... > > Since POSIX defers to ISO C we should be following the ISO C standard > > with respect to behavior when an encoding error occurs. As such, > > I've changed my mind and now

Re: ksh another home/end pair

Mark Kettenis wrote: > > From: "Ted Unangst" <t...@tedunangst.com> > > Date: Tue, 29 Dec 2015 12:11:25 -0500 > > > > In tmux, home and end send different bytes. I don't know why, but I want > > things to just work. We already have two different ke

malloc should always abort

Long ago, malloc internally had two kinds of failures, warnings and errors. The 'A' option elevated warningst to errors, and has been the default for some time. But then warnings were effectively eliminated in favor of everything being an error, but then the 'a' flag turned errors into warnings!

Re: [patch] kern/exec_script: return error when the shell name is not specified

Maxim Pugachev wrote: > Ping? > > On Sun, Dec 13, 2015 at 12:28 AM, Maxim Pugachev > wrote: > > Hi, > > > > In a case when the shell name is not specified (i.e. just "#!" without > > a path), don't run the heavy logic that checks shell, simply return > > ENOENT. > > > >

Re: Allocation type in kern/exec_elf.c

Maxim Pugachev wrote: > Hey all, > > I'm wondering, why an allocation type in kern/exec_elf.c is equal to > M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate > memory as M_EXEC, and it looks more reasonable to me. > > What's the reason for this? I think the reason is M_TEMP

Re: [patch] malloc: size that was passed to free() should land into the same bucket

Maxim Pugachev wrote: > On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst <t...@tedunangst.com> wrote: > > Maxim Pugachev wrote: > >> Currently two checks in free() function confirm the correctness of > >> freedsize argument. I think that it's better to check

Re: preparing multitouch support - request for tests

Tati Chevron wrote: > But I don't see that touch-based devices are ever going to become the most > common devices to run OpenBSD, that's not realistic. Even ignoring servers > and headless devices, and only counting devices that are used interactively > in some way, I just don't see tablet

Re: __progname in base

Theo Buehler wrote: > ping. > ok > On Tue, Dec 08, 2015 at 07:15:39PM +0100, Theo Buehler wrote: > > On Sat, Nov 07, 2015 at 12:20:42PM +0100, Tobias Stoeckmann wrote: > > > Based on Todd's patch for at and cron, I did a grep through our base > > > tree to see if there are more occurrences of

Re: [patch] malloc: size that was passed to free() should land into the same bucket

Maxim Pugachev wrote: > Currently two checks in free() function confirm the correctness of > freedsize argument. I think that it's better to check that provided > freedsize fall into the same bucket that was recorded in kmemusage > struct: it covers both cases. I don't know. This doesn't seem

Re: [patch] malloc: add info about the largest consumers of memory

Maxim Pugachev wrote: > Hi, > > This patch adds additional informational to ddb's "show malloc" > command about the largest consumers of memory. > > This is my first patch for OpenBSD, so I will be very grateful for any > comments. Thanks in advance! > > > Index: sys/kern/kern_malloc.c >

Re: Question about shm_open and sem_open

Jeunder Yu wrote: > > geteuid may be better. though i would hope the difference doesn't matter. > > The difference is very important for me. > > In my application, I am root and change to different uid, create semaphore > and share memory, make some hand sharking to client app with different

refine canaries

This is a kind of two steps forward, one step back diff. I would like for the canary to be placed directly adjacent to the end of the user specified size. No slack. To accomplish this, we record the original size of the allocation at the end, then we can walk backwards to find the canary.

<    1   2   3   4   5   6   7   8   9   10   >