Re: CVS commit: src/sys/arch/xen/xen

2020-04-13 Thread Manuel Bouyer
On Mon, Apr 13, 2020 at 08:09:13PM +, Jaromir Dolecek wrote:
> Module Name:  src
> Committed By: jdolecek
> Date: Mon Apr 13 20:09:13 UTC 2020
> 
> Modified Files:
>   src/sys/arch/xen/xen: xbd_xenbus.c
> 
> Log Message:
> KASSERT() that requested I/O size is <= XBD_MAX_XFER - this can happen
> e.g. with custom DomU kernel which doesn't have the value for MAXPHYS
> reduced to 32k like the XEN3_DOMU config

I though we were now splitting the requests ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--


Re: CVS commit: src/sys/kern

2020-04-13 Thread Andrew Doran
On Mon, Apr 13, 2020 at 04:34:48PM +0100, Roy Marples wrote:
> On 13/04/2020 16:31, Andrew Doran wrote:
> > Hi Roy.
> > 
> > On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote:
> > > On 10/04/2020 23:34, Andrew Doran wrote:
> > > > Module Name:src
> > > > Committed By:   ad
> > > > Date:   Fri Apr 10 22:34:36 UTC 2020
> > > > 
> > > > Modified Files:
> > > > src/sys/kern: vfs_mount.c
> > > > 
> > > > Log Message:
> > > > vfs_mountroot(): don't needlessly grab a second reference to the root 
> > > > vnode
> > > > (the kernel never chdirs) nor a lock on it.
> > > 
> > > So the kernel chrooting to sysctl init.root is still ok?
> > 
> > How is that accomplished?  I couldn't find the code and don't recall seeing
> > it.
> 
> sysctl -w init.root=/altroot
> 
> See the ZFS Root ramdisk:
> https://nxr.netbsd.org/xref/src/distrib/common/zfsroot.rc#33
> 
> I tested kernel from yesterdays sources and it still works fine, so I guess
> nothing was needed here.

I had a look and it's init that chroots, not the kernel, so no issue.  The
kernel chrooting would be evil.

Andrew


Re: CVS commit: src/sys/kern

2020-04-13 Thread Roy Marples

On 13/04/2020 16:31, Andrew Doran wrote:

Hi Roy.

On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote:

On 10/04/2020 23:34, Andrew Doran wrote:

Module Name:src
Committed By:   ad
Date:   Fri Apr 10 22:34:36 UTC 2020

Modified Files:
src/sys/kern: vfs_mount.c

Log Message:
vfs_mountroot(): don't needlessly grab a second reference to the root vnode
(the kernel never chdirs) nor a lock on it.


So the kernel chrooting to sysctl init.root is still ok?


How is that accomplished?  I couldn't find the code and don't recall seeing
it.


sysctl -w init.root=/altroot

See the ZFS Root ramdisk:
https://nxr.netbsd.org/xref/src/distrib/common/zfsroot.rc#33

I tested kernel from yesterdays sources and it still works fine, so I guess 
nothing was needed here.


Roy


Re: CVS commit: src/sys/kern

2020-04-13 Thread Andrew Doran
Hi Roy.

On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote:
> On 10/04/2020 23:34, Andrew Doran wrote:
> > Module Name:src
> > Committed By:   ad
> > Date:   Fri Apr 10 22:34:36 UTC 2020
> > 
> > Modified Files:
> > src/sys/kern: vfs_mount.c
> > 
> > Log Message:
> > vfs_mountroot(): don't needlessly grab a second reference to the root vnode
> > (the kernel never chdirs) nor a lock on it.
> 
> So the kernel chrooting to sysctl init.root is still ok?

How is that accomplished?  I couldn't find the code and don't recall seeing
it.

Andrew


[disk changes] CVS commit: src/sys/dev/dkwedge

2020-04-13 Thread Maxime Villard
> Module Name:src
> Committed By:   jdolecek
> Date:   Sat Apr 11 16:00:34 UTC 2020
>
> Modified Files:
> src/sys/dev/dkwedge: dkwedge_apple.c dkwedge_bsdlabel.c dkwedge_gpt.c
> dkwedge_mbr.c dkwedge_rdb.c

It appears that since your recent changes, there is a systematic
use-after-free:

panic: ASan: Unauthorized Access in 0x...: Addr 0x... [2 bytes, read, 
PoolUseAfterFree]
wdc_ata_bio()
wdstart1()
wd_diskstart()
dk_start()
bdev_strategy()
spec_strategy()
VOP_STRATEGY()
genfs_getpages()
VOP_GETPAGES()
ubc_fault()
uvm_fault_internal()
trap()
--- trap (number 6) ---
copyout()
uiomove()
ubc_uiomove()
ffs_read()
VOP_READ()
vn_read()
dofileread()
sys_read()
syscall()

This is reliably reproductible by just booting KASAN on amd64.

Can you give a look?

Thanks,
Maxime