Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to panic

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR kern/53850; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to
 panic
Date: Fri, 11 Jan 2019 02:50:36 +0100

 On 10.01.2019 08:00, David Holland wrote:
 > The following reply was made to PR kern/53850; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to
 >  panic
 > Date: Thu, 10 Jan 2019 06:59:24 +0000
 > 
 >  On Thu, Jan 10, 2019 at 03:45:00AM +0000, n54%gmx.com@localhost wrote:
 >   > Updating a mounted partition to MNT_UNION will lead to a panic.
 >  
 >  Urrgh...
 >  
 >   > int
 >   > main(int argc, char **argv)
 >   > {
 >   >         char A[1024];
 >   >         mount(NULL, "/", MNT_UNION | MNT_UPDATE, A, 0);
 >   >         return 0;
 >   > }
 >  
 >  Does it also die if you do this on a mount point other than /, where
 >  there is actually another fs underneath?
 >  
 >  (and if you mount over /, does it then not die?)
 >  
 >  I kinda think MNT_UPDATE ought not to be allowed to turn MNT_UNION on
 >  and off, but if it otherwise works...
 >  
 
 It looks like some types of partitions return error (EOPNOTSUPP).
 
 I've not reproduced the crash with tmpfs on /var/shm.
 
 I miss some details but probably forbidding MNT_UNION bit switching on
 MNT_UPDATE is the way to go.
 
 >  -- 
 >  David A. Holland
 >  dholland%netbsd.org@localhost
 >  
 >