Bob Beck wrote: > On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote: > > Here's the PR: > > > > https://gnats.netbsd.org/50381 > > > > And the commit: > > > > https://marc.info/?l=netbsd-source-changes&m=144694603617544&w=2 > > > > We have very few local changes to tmpfs and we share the > > KASSERT(de->td_node == NULL), so I think this applies to us. > > > > Thoughts? ok? > > > > > > Index: sys/tmpfs/tmpfs_subr.c > > =================================================================== > > RCS file: /cvsroot/src/sys/fs/tmpfs/tmpfs_subr.c,v > > retrieving revision 1.96.4.1 > > retrieving revision 1.96.4.1.2.1 > > diff -u -p -r1.96.4.1 -r1.96.4.1.2.1 > > --- sys/fs/tmpfs/tmpfs_subr.c 22 Dec 2014 02:05:08 -0000 1.96.4.1 > > +++ sys/fs/tmpfs/tmpfs_subr.c 8 Nov 2015 01:27:10 -0000 > > 1.96.4.1.2.1 > > @@ -451,6 +451,7 @@ tmpfs_alloc_dirent(tmpfs_mount_t *tmp, c > > nde->td_namelen = len; > > memcpy(nde->td_name, name, len); > > nde->td_seq = TMPFS_DIRSEQ_NONE; > > + nde->td_node = NULL; /* for asserts */ > > > > *de = nde; > > return 0; > > > > Well, that diff won't apply directly, and in my opinion this is a > safter way, considering the tmpfs code, to accomplish the same thing.
It applies directly, unless I'm missing something. I just forgot to share the OpenBSD diff, so the file path is different (drop the fs dir). That said, using M_ZERO does sound like a safety improvement. However, that also looks like a big struct (in the process of getting an actual number). Thoughts on the performance impact?
