ufs_ihash.c double handles LIST entry invalidation

src/sys/queue.h invalidates pointers in lists if DIAGNOSTIC is enabled, so ufs_ihash.c doesnt have to. ok? Index: ufs_ihash.c === RCS file: /cvs/src/sys/ufs/ufs/ufs_ihash.c,v retrieving revision 1.20 diff -u -p -r1.20 ufs_ihash.c ---

siphash for ufs disk quota hash

can someone test this? and eyeball the use of a pointer as data to get mixed into the hash? Index: ufs_quota.c === RCS file: /cvs/src/sys/ufs/ufs/ufs_quota.c,v retrieving revision 1.35 diff -u -p -r1.35 ufs_quota.c --- ufs_quota.c 13

remvoe some copystr

The historic copystr API is like copyinstr/copyoutstr but only for kernel strings. A much more familiar API is strlcpy. This converts three examples in kern. One where the return value is unchecked. One where the return is checked. And one more complicated conversion where the outlen param is use

less strlen in bgpctl

Not sure how I ended up reading this file, but all the redundant strlen calls make me twitchy. Noting that when word == null -> wordlen == 0, many of the tests can also be simplified to only check wordlen, but I saved that for next diff. Index: parser.c ===

Re: patch: check patch file size

On Sun, Nov 16, 2014 at 23:33, Ingo Schwarze wrote: > Hi Tobias, > > Tobias Stoeckmann wrote on Sun, Nov 16, 2014 at 09:58:43PM +0100: >> On Sun, Nov 16, 2014 at 09:39:32PM +0100, Alexander Bluhm wrote: > >>> Can we change p_filesize type to off_t instead? > >> Definitely, but it takes closer lo

Re: ressl blocking semantics

On Sun, Nov 16, 2014 at 17:01, Dirk Engling wrote: > Now I noticed that libtls's tls_client.c only allows for tls_connect > which creates blocking sockets only or tls_connect_socket which appears > to use the underlying socket's blocking state. The socket itself is > opaque to me, so that I can not

Re: patch: check patch file size

Hi Tobias, Tobias Stoeckmann wrote on Sun, Nov 16, 2014 at 09:58:43PM +0100: > On Sun, Nov 16, 2014 at 09:39:32PM +0100, Alexander Bluhm wrote: >> Can we change p_filesize type to off_t instead? > Definitely, but it takes closer looks for a review. Diff exists, OK schwarze@ (from careful code

Re: systrace: modify calloc() size argument

On Sun, Nov 16, 2014 at 4:13 AM, Nicolas Bedos wrote: > In the same vein as yesterday's diff for 'locate', I (well, Clang static > analyzer and me) found in bin/systrace/alias.c that the variable > 'reverse' is defined as a pointer to struct systrace_revalias but is > initialized as follows > >

Re: Posix RealTime Extensions.

On Sun, Nov 16, 2014 at 1:25 AM, David Carlier wrote: > sorry I m far to be an OpenBSD expert but I was wondering why it lacks some > functions like sigqueue and such ... Is there any plan to add them in the > future and if not what is the reasoning behind it ? It lacks them because no one has wr

Re: patch: check patch file size

On Sun, Nov 16, 2014 at 09:39:32PM +0100, Alexander Bluhm wrote: > Can we change p_filesize type to off_t instead? Definitely, but it takes closer looks for a review. Diff exists, I was just not sure if it's worth to support patch files which are larger than 2 GB on 32 bit systems. Tobias Inde

Re: patch: check patch file size

On Sun, Nov 16, 2014 at 09:23:49PM +0100, Tobias Stoeckmann wrote: > p_filesize is of type long, but we assign an off_t. Before assignment, > check if it will fit. Can we change p_filesize type to off_t instead? bluhm

patch: check patch file size

Hi, p_filesize is of type long, but we assign an off_t. Before assignment, check if it will fit. Also, check if fstat was successful or not. Tobias Index: pch.c === RCS file: /cvs/src/usr.bin/patch/pch.c,v retrieving revision 1.4

Re: siphash for ffs inode hash

>> part of me thinks we shoudl apply siphash to all the kernel hashes >> as a matter of course rather than waste the effort trying to figure >> out if they are attackable or not. > >Almost replied to tell you that, then I finished reading your email. :) i agree also.

Re: siphash for ffs inode hash

On Mon, Nov 17, 2014 at 00:25, David Gwynne wrote: > im in two minds about this. > > on the one hand, its not like this can be attacked remotely. on the > other hand, maybe someone would create a metric buttload of files > and open all the ones with inodes whose values are 4096 apart. > > discuss

ressl blocking semantics

dear ressl fellows, when trying to properly reimplement a curses client (i.e. handling stdin with select) with a tls connection using ressl (i.e. handling a server socket with select), I stumbled upon conflicting recommendations in man pages regarding whether to use blocking sockets in BIOs. The

siphash for ffs inode hash

im in two minds about this. on the one hand, its not like this can be attacked remotely. on the other hand, maybe someone would create a metric buttload of files and open all the ones with inodes whose values are 4096 apart. discussion? tests? ok? part of me thinks we shoudl apply siphash to all

Posix RealTime Extensions.

Hi all, sorry I m far to be an OpenBSD expert but I was wondering why it lacks some functions like sigqueue and such ... Is there any plan to add them in the future and if not what is the reasoning behind it ? Thanks in advance.

systrace: modify calloc() size argument

In the same vein as yesterday's diff for 'locate', I (well, Clang static analyzer and me) found in bin/systrace/alias.c that the variable 'reverse' is defined as a pointer to struct systrace_revalias but is initialized as follows reverse = calloc(1, sizeof(struct systrace_alias)); On amd64 :

Posix Realtime extensions

Hi all, sorry I m far to be an OpenBSD expert but I was wondering why it lacks some functions like sigqueue and such ... Is there any plan to add them in the future and if not what is the reasoning behind it ? Thanks in advance.