re: CVS commit: src/sys/kern

2020-02-23 Thread matthew green
"Andrew Doran" writes:
> Module Name:  src
> Committed By: ad
> Date: Sun Feb 23 20:08:35 UTC 2020
> 
> Modified Files:
>   src/sys/kern: kern_pmf.c
> 
> Log Message:
> shutdown_all: take kernel_lock now that kern_reboot() doesn't.

ah, i am now guessing that having the kernel lock held
is why reboots hang and can't be broken into again.

we really need to have autoconf run out side of a spin
lock...  anyone want to work on this please?


.mrg.


re: CVS commit: src/sys/kern

2020-02-23 Thread matthew green
"Andrew Doran" writes:
> Module Name:  src
> Committed By: ad
> Date: Sun Feb 23 20:06:30 UTC 2020
> 
> Modified Files:
>   src/sys/kern: kern_reboot.c
> 
> Log Message:
> - If concurrent calls to kern_reboot(), only let the first do the deed.
> - Don't need kernel_lock for this (either OK, or suspendsched() called).

what happens if i enter ddb while rebooting, such that this
now sets 'rebooter' to some lwp.  inside ddb, i use 'mach cpu'
to change CPUs, which on some platforms actually swithces to
that CPU -- ie, we now have a different curlwp.

this while () will now hang forever, won't it?


.mrg.


Re: CVS commit: src

2020-02-23 Thread Andrew Doran
On Fri, Feb 21, 2020 at 02:14:31PM +0100, Kamil Rytarowski wrote:

> On 22.12.2019 20:47, Andrew Doran wrote:
> > Module Name:src
> > Committed By:   ad
> > Date:   Sun Dec 22 19:47:35 UTC 2019
> > 
> > Modified Files:
> > src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ctldir.c
> > src/sys/kern: vfs_mount.c vfs_subr.c vfs_syscalls.c
> > src/sys/miscfs/genfs: genfs_vfsops.c
> > src/sys/nfs: nfs_export.c
> > src/sys/sys: mount.h vnode.h vnode_impl.h
> > src/sys/ufs/lfs: ulfs_vfsops.c
> > src/sys/ufs/ufs: ufs_vfsops.c ufs_wapbl.c
> > 
> > Log Message:
> > Make mntvnode_lock per-mount, and address false sharing of struct mount.
> > 
> 
> This change broke kUBSan syzbot.
> 
> The sanitizer is now very noisy as struct mount requires 64 byte alignment.
> 
> http://netbsd.org/~kamil/kubsan/mount-alignment.txt

I had a look this weekend.  This is down to KMEM_SIZE messing up the
alignment, so is a DIAGNOSTIC thing.  The align_offset parameter to
pool_cache() would be a nice easy way to solve this but it seems someone
killed that off, so I'll need to give this some more thought.

Andrew

> > diff -u src/sys/sys/mount.h:1.234 src/sys/sys/mount.h:1.235
> > --- src/sys/sys/mount.h:1.234   Tue Jan  1 10:06:54 2019
> > +++ src/sys/sys/mount.h Sun Dec 22 19:47:34 2019
> > @@ -1,4 +1,4 @@
> > -/* $NetBSD: mount.h,v 1.234 2019/01/01 10:06:54 hannken Exp $  */
> > +/* $NetBSD: mount.h,v 1.235 2019/12/22 19:47:34 ad Exp $   */
> >  
> >  /*
> >   * Copyright (c) 1989, 1991, 1993
> > @@ -133,29 +133,38 @@ struct vattr;
> >   * array of operations and an instance record.
> >   */
> >  struct mount {
> > -   TAILQ_HEAD(, vnode_impl) mnt_vnodelist; /* list of vnodes this mount */
> > +   /*
> > +* Mostly stable data.
> > +*/
> > +   kmutex_t*mnt_vnodelock; /* lock on mnt_vnodelist */
> > struct vfsops   *mnt_op;/* operations on fs */
> > struct vnode*mnt_vnodecovered;  /* vnode we mounted on */
> > struct mount*mnt_lower; /* fs mounted on */
> > -   int mnt_synclist_slot;  /* synclist slot index */
> > void*mnt_transinfo; /* for FS-internal use */
> > void*mnt_data;  /* private data */
> > -   kmutex_tmnt_renamelock; /* per-fs rename lock */
> > -   int mnt_refcnt; /* ref count on this structure 
> > */
> > +   kmutex_t*mnt_renamelock;/* per-fs rename lock */
> > int mnt_flag;   /* flags */
> > int mnt_iflag;  /* internal flags */
> > int mnt_fs_bshift;  /* offset shift for lblkno */
> > int mnt_dev_bshift; /* shift for device sectors */
> > -   struct statvfs  mnt_stat;   /* cache of filesystem stats */
> > specificdata_reference
> > mnt_specdataref;/* subsystem specific data */
> > -   kmutex_tmnt_updating;   /* to serialize updates */
> > +   kmutex_t*mnt_updating;  /* to serialize updates */
> > const struct wapbl_ops
> > *mnt_wapbl_op;  /* logging ops */
> > struct wapbl*mnt_wapbl; /* log info */
> > struct wapbl_replay
> > *mnt_wapbl_replay;  /* replay support XXX: what? */
> > uint64_tmnt_gen;
> > +
> > +   /*
> > +* Volatile data: pad to keep away from the stable items.
> > +*/
> > +   int mnt_refcnt  /* ref count on this structure 
> > */
> > +   __aligned(COHERENCY_UNIT);
> > +   int mnt_synclist_slot;  /* synclist slot index */
> > +   TAILQ_HEAD(, vnode_impl) mnt_vnodelist; /* list of vnodes this mount */
> > +   struct statvfs  mnt_stat;   /* cache of filesystem stats */
> >  };
> >  
> >  #endif /* defined(_KERNEL) || defined(__EXPOSE_MOUNT) */
> > 
> 
> 
> 
> 





Re: CVS commit: src/share/man/man9

2020-02-23 Thread Andrew Doran
On Sun, Feb 23, 2020 at 08:57:44AM +, matthew green wrote:
> Module Name:  src
> Committed By: mrg
> Date: Sun Feb 23 08:57:44 UTC 2020
> 
> Modified Files:
>   src/share/man/man9: Makefile
> 
> Log Message:
> install rw_lock_op link too.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.447 -r1.448 src/share/man/man9/Makefile
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.

Oops, forgot to commit the Makefile.  Thank you.

Andrew


Re: CVS commit: src/lib/libc/stdlib

2020-02-23 Thread Valery Ushakov
On Sun, Feb 23, 2020 at 10:57:28 +0100, Kamil Rytarowski wrote:

> On 23.02.2020 08:46, Martin Husemann wrote:
> 
> > Source code consistency is a very important stylistic plus, every break of
> > that should be accompanied by a comment.
>
> Done.

Thank you.

-uwe


Re: CVS commit: src/lib/libc/stdlib

2020-02-23 Thread Kamil Rytarowski
On 23.02.2020 08:46, Martin Husemann wrote:
> On Sun, Feb 23, 2020 at 03:35:19AM +0100, Kamil Rytarowski wrote:
>> Algorithm would be changed from calculating on 32bit numbers with signed
>> integer overflows to an algorithm calculating on 64bit numbers. The
>> __dorand48() function truncates the result to least significant 16bits
>> only so it does not matter. I retained operations on 32bits avoiding
>> changes of types for stylistic reasons.
> 
> I am with uwe here - either it would not make any difference at all (on
> 32bit architectures) or it would end up with the same results and would
> make no performance difference (on 64 bit architectures), so going with
> the consistent (unsigned long) would have been fine.
> 
> Even better would be a cleanup to make it (uint32_t) everwhere, but of
> course only after carefull examination.
> 
> Source code consistency is a very important stylistic plus, every break of
> that should be accompanied by a comment.
> 
> Martin
> 

Done.



signature.asc
Description: OpenPGP digital signature