Re: CVS commit: src
Le 23/02/2020 à 23:19, Andrew Doran a écrit : 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 kmem guarantees alignment on 8 bytes, but not more. Changing the backend allocators to enforce more alignment still may not result in aligned buffers, because kmem has the right to modify the buffers for debugging purposes, like with KMEM_SIZE. If you want a buffer aligned to a specific value, don't use kmem, rather a pool(_cache) with COHERENCY_UNIT in "align". If the goal is to have kmem really enforce COHERENCY_UNIT alignment, then this should be documented and the debugging features should be adapted to respect that constraint. "align_offset" got removed because it increased complexity in subr_pool for no reason (two users in all of the kernel, one was actually a bug).
Re: CVS commit: src/external/bsd/libarchive/dist/libarchive
Earlier, I wrote: > > cvs rdiff -u -r1.1.1.4 -r1.2 \ > > src/external/bsd/libarchive/dist/libarchive/archive_read.c > > What kind of sorcery is this? Why is the diff not relative to 1.1? To answer my own question, "vendor branch sorcery". What confused me about this in the first place was that if you look at the history of this file in cvsweb, at http://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/libarchive/dist/libarchive/archive_read.c?only_with_tag=MAIN it says "Diff to previous 1.1 (colored)", and if you click on that, you see a diff that's much larger than the upstream patch at https://github.com/libarchive/libarchive/commit/ec5b86b48e99c5501374b01606f1ccdae6a8a93e.patch Bug in cvsweb? -- Andreas Gustafsson, g...@gson.org
Re: CVS commit: src/external/bsd/libarchive/dist/libarchive
I repled to you and gson off-list. > On Feb 25, 2020, at 8:24 AM, Kamil Rytarowski wrote: > > On 25.02.2020 16:24, Andreas Gustafsson wrote: >> Kamil Rytarowski wrote: >>> To generate a diff of this commit: >>> cvs rdiff -u -r1.1.1.4 -r1.2 \ >>>src/external/bsd/libarchive/dist/libarchive/archive_read.c >> >> What kind of sorcery is this? Why is the diff not relative to 1.1? >> > > I don't know. I was on the HEAD branch. > -- thorpej
Re: CVS commit: src/external/bsd/libarchive/dist/libarchive
On 25.02.2020 16:24, Andreas Gustafsson wrote: > Kamil Rytarowski wrote: >> To generate a diff of this commit: >> cvs rdiff -u -r1.1.1.4 -r1.2 \ >> src/external/bsd/libarchive/dist/libarchive/archive_read.c > > What kind of sorcery is this? Why is the diff not relative to 1.1? > I don't know. I was on the HEAD branch. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/bsd/libarchive/dist/libarchive
Kamil Rytarowski wrote: > To generate a diff of this commit: > cvs rdiff -u -r1.1.1.4 -r1.2 \ > src/external/bsd/libarchive/dist/libarchive/archive_read.c What kind of sorcery is this? Why is the diff not relative to 1.1? -- Andreas Gustafsson, g...@gson.org
Re: CVS commit: src/sys/kern
On 24.02.2020 21:47, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Feb 24 20:47:47 UTC 2020
>
> Modified Files:
> src/sys/kern: init_main.c
>
> Log Message:
> move config_init_mi() call before vfsinit(), which can trigger loading
> of VFS modules
>
> fixes crash with LOCKDEBUG due to uninitialized mutex when zfs
> module is loaded in boot, because zfs's spa_init() calls config_mountroot()
> which now requires the config init having been done
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.521 -r1.522 src/sys/kern/init_main.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>
kASan is still broken on boot. Please fix.
[ 1.0188350] acpicpu1 at cpu1: ACPI CPU
[ 1.0188350] cpu0 has 2 core siblings: cpu1 cpu0
[ 1.0188350] cpu0 has 2 pkg siblings: cpu1 cpu0
[ 1.0188350] cpu0 has 1 1st siblings: cpu0
[ 1.0188350] cpu0 first in package: cpu0
[ 1.0188350] cpu1 has 2 core siblings: cpu0 cpu1
[ 1.0188350] cpu1 has 2 pkg siblings: cpu0 cpu1
[ 1.0188350] cpu1 has 1 1st siblings: cpu0
[ 1.0188350] cpu1 first in package: cpu0
[ 1.2307575] panic: ASan: Unauthorized Access In 0x811e6be6:
Addr 0x98000f382b58 [8 bytes, read, PoolUseAfterFree]
[ 1.2401020] cpu1: Begin traceback...
[ 1.2501232] vpanic() at netbsd:vpanic+0x241
[ 1.2701652] snprintf() at netbsd:snprintf
[ 1.2902064] kasan_report() at netbsd:kasan_report+0x98
[ 1.3102484] __asan_load8() at netbsd:__asan_load8+0x294
[ 1.3302897] config_interrupts_thread() at
netbsd:config_interrupts_thread+0x68
[ 1.3403126] cpu1: End traceback...
[ 1.3403126] fatal breakpoint trap in supervisor mode
[ 1.3503263] trap type 1 code 0 rip 0x8021e4b5 cs 0x8 rflags
0x246 cr2 0 ilevel 0 rsp 0x98017de07d60
[ 1.3603479] curlwp 0x9800116a16c0 pid 0.30 lowest kstack
0x98017de002c0
Stopped in pid 0.30 (system) at netbsd:breakpoint+0x5: leave
db{1}>
https://syzkaller.appspot.com/bug?id=aa6e0c00233b3e55340da80d7636bb2c18181e5f
signature.asc
Description: OpenPGP digital signature
