NetBSD Problem Report #52056
From martin@duskware.de Thu Mar 9 18:59:55 2017
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 98E1C7A20D
for <gnats-bugs@gnats.NetBSD.org>; Thu, 9 Mar 2017 18:59:55 +0000 (UTC)
Date: Thu, 09 Mar 2017 19:59:52 CET
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: mount -u / causes a kernel assertion
X-Send-Pr-Version: 3.95
>Number: 52056
>Category: kern
>Synopsis: mount -u / causes a kernel assertion
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: jdolecek
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Mar 09 19:00:01 +0000 2017
>Closed-Date: Sat Mar 11 22:38:24 +0000 2017
>Last-Modified: Mon Apr 10 20:25:00 +0000 2017
>Originator: Martin Husemann
>Release: NetBSD 7.99.65
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD drowsy.duskware.de 7.99.65 NetBSD 7.99.65 (DROWSY) #3: Tue Mar 7 09:35:27 CET 2017 martin@martins.aprisoft.de:/ssd/src/sys/arch/shark/compile/DROWSY shark
Architecture: earmv4
Machine: shark
>Description:
After a fsck in single user mode I rebooted with boot -s,
then at the single user prompt:
mount -u /
and edited /etc/rc.conf. After exiting the single user shell (w/o another
reboot):
Starting syslogd.
Setting date via ntp.
Starting rpcbind.
Mounting all file systems...
Clearing temporary files.
panic: kernel diagnostic assertion "!(bp->b_oflags & BO_DELWRI)" failed: file "../../../../kern/vfs_wapbl.c", line 1142
Stopped in pid 0.38 (system) at netbsd:cpu_Debugger+0x4: mov pc, r14
db> bt
0xf60a4e2c: netbsd:vpanic+0xc
0xf60a4e44: netbsd:kern_assert+0x40
0xf60a4e7c: netbsd:wapbl_add_buf+0x108
0xf60a4e9c: netbsd:bdwrite+0xc0
0xf60a4f04: netbsd:ffs_update.part.3+0x284
0xf60a4f5c: netbsd:ffs_sync+0x128
0xf60a4fac: netbsd:sched_sync+0x278
>How-To-Repeat:
s/a
>Fix:
n/a
>Release-Note:
>Audit-Trail:
From: coypu@SDF.ORG
To: gnats-bugs@netbsd.org
Cc: martin@NetBSD.org
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Thu, 9 Mar 2017 19:34:05 +0000
There were a couple of commits and bug reports regarding very similar
things. can you try a slightly newer than mar 7 current?
From: Martin Husemann <martin@duskware.de>
To: coypu@SDF.ORG
Cc: gnats-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Thu, 9 Mar 2017 20:46:28 +0100
On Thu, Mar 09, 2017 at 07:34:05PM +0000, coypu@SDF.ORG wrote:
> There were a couple of commits and bug reports regarding very similar
> things. can you try a slightly newer than mar 7 current?
The latest relevant change I am aware of is already included:
$NetBSD: vfs_syscalls.c,v 1.509 2017/03/07 11:54:16 hannken Exp $
Martin
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Thu, 9 Mar 2017 23:30:52 +0100
I've looked on the code, and basically this assertion means that there
was a bdwrite() done with same buf before MNT_LOG was enabled, and no
bwrite() happened between that bdwrite() and the bdwrite() triggering
the assertion.
wapbl_add_buf() is invoked in bdwrite(), before the BO_DELWRI flag is
set. It adds the buffer to internal WAPBL list, then sets the B_LOCKED
flag.
The assertion fires only when buf still doesn't have B_LOCKED set, but
already has BO_DELWRI set. This flow should be impossible.
I suspect something is still not quite right with the ro/rw switch
after recent changes. Juergen, any idea? Perhaps having the filesystem
mounted async might possibly trigger some arcane flow?
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 00:06:51 +0100
I confirmed setting the async flag for the filesystem makes the system
trigger the assertion. I can reproduce it apparently reliably in
VirtualBox VM. It triggers for me immediatelly after 'Starting file
system checks" as the boot continues.
Steps to reproduce:
0. add flags 'log,async' to /etc/fstab for /
1. boot singleuser
2. mount -u /
3. /rescue/vi /etc/rc.conf # change, save
4. exit # and let the system boot
For some reason, skipping 0) and doing "mount -u -o log,async /" in
step 2), otherwise same steps, did not trigger the panic during
following boot.
2017-03-09 23:35 GMT+01:00 Jarom=C3=ADr Dole=C4=8Dek <jaromir.dolecek@gmail=
.com>:
> The following reply was made to PR kern/52056; it has been noted by GNATS=
.
>
> From: =3D?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=3D?=3D <jaromir.dolecek@gmail.c=
om>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/52056: mount -u / causes a kernel assertion
> Date: Thu, 9 Mar 2017 23:30:52 +0100
>
> I've looked on the code, and basically this assertion means that there
> was a bdwrite() done with same buf before MNT_LOG was enabled, and no
> bwrite() happened between that bdwrite() and the bdwrite() triggering
> the assertion.
>
> wapbl_add_buf() is invoked in bdwrite(), before the BO_DELWRI flag is
> set. It adds the buffer to internal WAPBL list, then sets the B_LOCKED
> flag.
>
> The assertion fires only when buf still doesn't have B_LOCKED set, but
> already has BO_DELWRI set. This flow should be impossible.
>
> I suspect something is still not quite right with the ro/rw switch
> after recent changes. Juergen, any idea? Perhaps having the filesystem
> mounted async might possibly trigger some arcane flow?
>
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 09:38:12 +0100
On Thu, Mar 09, 2017 at 10:35:02PM +0000, Jaromír Dole?ek wrote:
> I suspect something is still not quite right with the ro/rw switch
> after recent changes. Juergen, any idea? Perhaps having the filesystem
> mounted async might possibly trigger some arcane flow?
I have not mounted it async:
/dev/wd0a on / type ffs (log, local)
but maybe important: this is a shark, ancient IDE interface, very slow
disk access:
wdc0 at ofisa0 (ide@i1f0)
wd0 at atabus0 drive 0
wd0: <SAMSUNG HM120IC>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
boot device: wd0
root on wd0a dumps on wd0b
and I think it is doing all IO in "PIO mode 4".
Martin
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 10:31:52 +0100
> On 9 Mar 2017, at 23:35, Jarom=C3=ADr Dole=C4=8Dek =
<jaromir.dolecek@gmail.com> wrote:
>=20
> The following reply was made to PR kern/52056; it has been noted by =
GNATS.
>=20
> From: =3D?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=3D?=3D =
<jaromir.dolecek@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc:=20
> Subject: Re: kern/52056: mount -u / causes a kernel assertion
> Date: Thu, 9 Mar 2017 23:30:52 +0100
>=20
> I've looked on the code, and basically this assertion means that there
> was a bdwrite() done with same buf before MNT_LOG was enabled, and no
> bwrite() happened between that bdwrite() and the bdwrite() triggering
> the assertion.
>=20
> wapbl_add_buf() is invoked in bdwrite(), before the BO_DELWRI flag is
> set. It adds the buffer to internal WAPBL list, then sets the B_LOCKED
> flag.
>=20
> The assertion fires only when buf still doesn't have B_LOCKED set, but
> already has BO_DELWRI set. This flow should be impossible.
This is more than possible. Martin does:
-> mount -u / "Change root from read-only,no-log to no-log"
-> edit file "This will bdwrite() and leave buffers B_DELWRI"
-> exit singleuser
-> /etc/rc.d/root "Change root from no-log to log"
We now have buffers marked BO_DELWRI without B_LOCKED.
This has nothing to do with my recent changes.
We have to either:
- Remove the assertion and have wapbl_add_buf() pick up these buffers.
- Deny no-log to log transitions while read-write.
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 10:50:47 +0100
On Fri, Mar 10, 2017 at 09:35:01AM +0000, J. Hannken-Illjes wrote:
> -> mount -u / "Change root from read-only,no-log to no-log"
I somehow would have expected it to go to "log", as that is what my
/etc/fstab has:
/dev/wd0a / ffs rw,log 1 1
(which, IIUC, would also fix the issue).
But of course you are right:
# mount /
# mount
/dev/wd0a on / type ffs (log, local)
and (after a reboot):
# mount -u /
# mount
/dev/wd0a on / type ffs (local)
(so I guess I should get rid of that old -u muscle memory and just use the
former variant)
Martin
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 19:33:32 +0700
Date: Fri, 10 Mar 2017 09:55:01 +0000 (UTC)
From: Martin Husemann <martin@duskware.de>
Message-ID: <20170310095501.23B457A2AA@mollari.NetBSD.org>
| (so I guess I should get rid of that old -u muscle memory and just use the
| former variant)
Actually, this looks like a bug in mount that should be fixed (independant
of what the kernel should, or should not, do when asked to transition from
nolog to log while read-write.)
mount(8) says ...
-u The -u flag indicates that the status of an already mounted file
system should be changed. Any of the options discussed above
(the -o option) may be changed; also a file system can be changed
from read-only to read-write or vice versa. An attempt to change
from read-write to read-only will fail if any files on the file
system are currently open for writing unless the -f flag is also
specified. The set of options is determined by first extracting
the options for the file system from the fstab(5) file, then
applying any options specified by the -o argument, and finally
applying the -r or -w option.
Note: "The set of options is determined by first extracting the options for
the file system from the fstab(5) file, then..." Since the "mount -u /"
usage provides nothing else for the "then..." to catch, what should rule is
the fstab line, which includes "log", so log should be (but clearly is not)
set (or at least attempted to be set, and as this is a change from ro to
rw,log it should really be able to work ... it is, or should be, the exact
same change that happens during a normal multi-user boot with /etc/rc
controlling everything.)
kre
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
Martin Husemann <martin@netbsd.org>
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 15:00:13 +0100
> This is more than possible. Martin does:
>
> -> mount -u / "Change root from read-only,no-log to no-log"
> -> edit file "This will bdwrite() and leave buffers B_DELWRI"
> -> exit singleuser
> -> /etc/rc.d/root "Change root from no-log to log"
>
> We now have buffers marked BO_DELWRI without B_LOCKED.
>
> This has nothing to do with my recent changes.
>
> We have to either:
>
> - Remove the assertion and have wapbl_add_buf() pick up these buffers.
>
> - Deny no-log to log transitions while read-write.
I'll look if we can deny the transition, or make sure that pending
blocks are synced first.
I noticed that rev. 1.344 of ffs_vfsops.c removed a ffs_fsync() call -
could that change perhaps have changed the behaviour?
Some volunteer for checking why the -u doesn't work as advertized?
Jaromir
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 15:23:40 +0100
> On 10 Mar 2017, at 15:05, Jarom=C3=ADr Dole=C4=8Dek =
<jaromir.dolecek@gmail.com> wrote:
>=20
> I noticed that rev. 1.344 of ffs_vfsops.c removed a ffs_fsync() call -
> could that change perhaps have changed the behaviour?
No. That change untangled sync from suspendctl. Before a file system
would sync before suspending, now we suspend and sync where needed.
It could be sufficient to call ffs_sync(WAIT) before going from
non-log to log. The update now runs on a suspended file system so
after sync no new dirty buffers appear.
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Robert Elz <kre@munnari.OZ.AU>
To: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
Martin Husemann <martin@netbsd.org>
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 23:46:43 +0700
Date: Fri, 10 Mar 2017 15:00:13 +0100
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Message-ID: <CAMnsW54zJHN1Kj_-bg8HJ11WSfFzcy9XT0Ebap52GJCRL3fMQQ@mail.gmail.com>
| Some volunteer for checking why the -u doesn't work as advertized?
I will take a look at that.
kre
Responsible-Changed-From-To: kern-bug-people->jdolecek
Responsible-Changed-By: jdolecek@NetBSD.org
Responsible-Changed-When: Fri, 10 Mar 2017 18:47:55 +0000
Responsible-Changed-Why:
WAPBL related, taking.
State-Changed-From-To: open->analyzed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Fri, 10 Mar 2017 18:47:55 +0000
State-Changed-Why:
According to discussion we need to take care to fsync(MNT_WAIT) when going non-log -> log,
to not hit stale buffers.
I'll take care of this.
State-Changed-From-To: analyzed->feedback
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Fri, 10 Mar 2017 22:45:07 +0000
State-Changed-Why:
Fix committed, please confirm it works for you.
From: "Jaromir Dolecek" <jdolecek@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/52056 CVS commit: src/sys/ufs/ffs
Date: Fri, 10 Mar 2017 22:43:04 +0000
Module Name: src
Committed By: jdolecek
Date: Fri Mar 10 22:43:03 UTC 2017
Modified Files:
src/sys/ufs/ffs: ffs_wapbl.c
Log Message:
sync any delayed writes when updating filesystem to log
Adresses PR kern/52056 by Martin Husemann, fix helped by Juergen Hannken, thanks
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/sys/ufs/ffs/ffs_wapbl.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Robert Elz <kre@munnari.OZ.AU>
To: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
current-users@netbsd.org, netbsd-bugs@netbsd.org,
Martin Husemann <martin@netbsd.org>
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Sat, 11 Mar 2017 06:00:27 +0700
In messages related to PR kern/52056 (in gnats) and on netbsd-bugs@n.o
(I am adding current-users as this needs opinions from a wider community).
The PR is mostly about kernel issues, this issue with mount -u is only
relevant because that happened to trigger the kernel, if -u worked
differently, the actual problem from the PR might not have been noticed.
Date: Fri, 10 Mar 2017 15:00:13 +0100
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Message-ID: <CAMnsW54zJHN1Kj_-bg8HJ11WSfFzcy9XT0Ebap52GJCRL3fMQQ@mail.gmail.com>
| Some volunteer for checking why the -u doesn't work as advertized?
The issue is that the man page (mount(8)) says that -u takes options from
fstab, then the command line -o options, and then -r or -w - but the code
does not do that, fstab options are ignored with -u, only options from the
command line are used.
It kind of seems to be deliberate - though I have no idea why.
Back in the early days (until mid 1994) it seems to have worked as the
man page states - the relevant text in the man page has been essentially
unchanged since version 1.1. When 4.4-lite was incorporated in June 1994
the code changed, and the following lines appeared ...
/* If it's an update, ignore the fstab file options. */
fs->fs_mntops = NULL;
(in the code processing the -u case). The code was restructured in 1998,
but this was not altered in substance - the comment was deleted though.
It has remained essentially unchanged ever since.
So, it appears that 4.4-lite made this change, and apparently intentionally,
but I have no idea why.
Changing it is trivial, if that is desired. The question now is, which
should be fixed, the man page, or the code?
One last thing that's interesting, back in Nov 1997, a correction to the
man page has this as its commit log message ...
Add a clarification how the missing data are looked up if either
mount source or target are omitted. Adresses PR 3240.
XXX This is not the complete truth. Things change with the -u
option. Should be fixed in "mount.c".
The actual change that commit made is not relevant here, but the XXX
note indicates that way back then this issue was known, and at least one
developer thought it should be fixed in the source.
So, does anyone believe that we should change the man page, and note that
options from fstab are ignored with -u, or should the code be changed so
that it works as the man page has (always) advertised (but which it hasn't
done for the past (almost) 23 years.)
kre
From: Matt Sporleder <msporleder@gmail.com>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: =?utf-8?Q?Jarom=C3=ADr_Dole=C4=8Dek?= <jaromir.dolecek@gmail.com>,
gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, current-users@netbsd.org,
netbsd-bugs@netbsd.org, Martin Husemann <martin@netbsd.org>
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 18:39:11 -0500
> On Mar 10, 2017, at 6:00 PM, Robert Elz <kre@munnari.OZ.AU> wrote:
>=20
> In messages related to PR kern/52056 (in gnats) and on netbsd-bugs@n.o
> (I am adding current-users as this needs opinions from a wider community).=
>=20
> The PR is mostly about kernel issues, this issue with mount -u is only
> relevant because that happened to trigger the kernel, if -u worked
> differently, the actual problem from the PR might not have been noticed.
>=20
> Date: Fri, 10 Mar 2017 15:00:13 +0100
> From: =3D?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=3D?=3D <jaromir.dolece=
k@gmail.com>
> Message-ID: <CAMnsW54zJHN1Kj_-bg8HJ11WSfFzcy9XT0Ebap52GJCRL3fMQQ@mail.=
gmail.com>
>=20
> | Some volunteer for checking why the -u doesn't work as advertized?
>=20
> The issue is that the man page (mount(8)) says that -u takes options from
> fstab, then the command line -o options, and then -r or -w - but the code
> does not do that, fstab options are ignored with -u, only options from the=
> command line are used.
>=20
> It kind of seems to be deliberate - though I have no idea why.
>=20
> Back in the early days (until mid 1994) it seems to have worked as the
> man page states - the relevant text in the man page has been essentially
> unchanged since version 1.1. When 4.4-lite was incorporated in June 199=
4
> the code changed, and the following lines appeared ...
>=20
> /* If it's an update, ignore the fstab file options. */
> fs->fs_mntops =3D NULL;
>=20
> (in the code processing the -u case). The code was restructured in 1998,=
> but this was not altered in substance - the comment was deleted though.
>=20
> It has remained essentially unchanged ever since.
>=20
> So, it appears that 4.4-lite made this change, and apparently intentionall=
y,
> but I have no idea why.
>=20
> Changing it is trivial, if that is desired. The question now is, which
> should be fixed, the man page, or the code?
>=20
> One last thing that's interesting, back in Nov 1997, a correction to the
> man page has this as its commit log message ...
>=20
> Add a clarification how the missing data are looked up if either
> mount source or target are omitted. Adresses PR 3240.
> XXX This is not the complete truth. Things change with the -u
> option. Should be fixed in "mount.c".
>=20
> The actual change that commit made is not relevant here, but the XXX
> note indicates that way back then this issue was known, and at least one
> developer thought it should be fixed in the source.
>=20
> So, does anyone believe that we should change the man page, and note that
> options from fstab are ignored with -u, or should the code be changed so
> that it works as the man page has (always) advertised (but which it hasn't=
> done for the past (almost) 23 years.)
>=20
> kre
>=20
What do the other BSDs do in this case?=
From: Robert Elz <kre@munnari.OZ.AU>
To: Matt Sporleder <msporleder@gmail.com>
Cc: =?utf-8?Q?Jarom=C3=ADr_Dole=C4=8Dek?= <jaromir.dolecek@gmail.com>,
gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
current-users@netbsd.org, netbsd-bugs@netbsd.org,
Martin Husemann <martin@netbsd.org>
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Sat, 11 Mar 2017 08:00:54 +0700
Date: Fri, 10 Mar 2017 18:39:11 -0500
From: Matt Sporleder <msporleder@gmail.com>
Message-ID: <3FDA22B8-4E6B-42C6-A0AD-AC4388076DD8@gmail.com>
| What do the other BSDs do in this case?
Back in 1999, FreeBSD appear to have removed the reference to getting
options from fstab before the command line from their man page - but at
the same time they added two new "pseudo-options" for use with -u,
those being "current" and "fstab".
In their system:
mount -u -o fstab <whatever-filesys>
would do what the NetBSD man page (and earlier FreeBSD man page)
said should happen.
Without -o current, I believe they set the mount options to exactly whatever
is set on the command line, with that option they add/subtract options
from what is currently set.
OpenBSD removed the reference to getting options from fstab with -u from
their man page on Dec 31, 2000 (just a couple of hours before the turn of
the millenium (UTC) - I guess they thought they should have a housecleaning...)
Unlike NetBSD (and FreeBSD when no -o current is given) they seem to
apply the options given with mount -u on top of the currently listed
options (though their man page does not say that) - ie: they do what
FreeBSD would write as:
mount -u -o current,others... <filesys>
just by saying
mount -u -o others... <filesys>
whereas we just set the options to whatever is given on the command line,
ingnoring whatever was set when the filesys was originally mount, or
last mount -u'd. (but note, that one of "ro" or "rw" is effectively
*always* given on the command line.)
I don't know how to check other BSD derived systems.
Given all that, the best might be to basically copy the FreeBSD setup,
though I think I would prefer if
mount -u <filesys>
with no command line options at all (which currently means mount rw,
and disable any other mount options previously set, on NetBSD and FreeBSD,
and would be a "convert to rw, leaving all other options on OpenBSD)
was instead treated as if (in FreeBSD syntax)
mount -u -o fstab <filesys>
was given, so this (just mount -u) becomes an easy way to simply set the
filesys mount to the way fstab says it should be.
I think I'd also like to remove the magic "one is always set" from the
-r/-w flags when used with -u, so it is more easily possible to add an
option without accidentally turning a ro mount into rw.
Other opinions?
kre
ps: apologies if I have misstated what FreeBSD or OpenBSD do, I looked
at their man pages, and briefly at their code - I did not run either to test.
State-Changed-From-To: feedback->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Sat, 11 Mar 2017 22:38:24 +0000
State-Changed-Why:
Fix works for me, thanks!
From: "Jaromir Dolecek" <jdolecek@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/52056 CVS commit: src
Date: Wed, 22 Mar 2017 21:33:06 +0000
Module Name: src
Committed By: jdolecek
Date: Wed Mar 22 21:33:06 UTC 2017
Modified Files:
src/distrib/sets/lists/tests: mi
src/tests/fs/ffs: Makefile
Log Message:
add tests for the mount update from rw to rw+log, which used to case the panic
reported in PR kern/52056
To generate a diff of this commit:
cvs rdiff -u -r1.728 -r1.729 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.18 -r1.19 src/tests/fs/ffs/Makefile
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Jaromir Dolecek" <jdolecek@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/52056 CVS commit: src/tests/fs/ffs
Date: Wed, 22 Mar 2017 21:33:54 +0000
Module Name: src
Committed By: jdolecek
Date: Wed Mar 22 21:33:54 UTC 2017
Added Files:
src/tests/fs/ffs: t_update_log.c
Log Message:
add tests for the mount update from rw to rw+log, which used to case the panic
reported in PR kern/52056
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/tests/fs/ffs/t_update_log.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Rhialto <rhialto@falu.nl>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: Matt Sporleder <msporleder@gmail.com>,
=?iso-8859-1?Q?Jarom=EDr?= Dole?ek <jaromir.dolecek@gmail.com>,
gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
current-users@netbsd.org, netbsd-bugs@netbsd.org,
Martin Husemann <martin@netbsd.org>
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Mon, 10 Apr 2017 22:21:12 +0200
--0vzXIDBeUiKkjNJl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat 11 Mar 2017 at 08:00:54 +0700, Robert Elz wrote:
> Given all that, the best might be to basically copy the FreeBSD setup,
> though I think I would prefer if
>=20
> mount -u <filesys>
>=20
> with no command line options at all (which currently means mount rw,
> and disable any other mount options previously set, on NetBSD and FreeBSD,
> and would be a "convert to rw, leaving all other options on OpenBSD)
> was instead treated as if (in FreeBSD syntax)
> mount -u -o fstab <filesys>
> was given, so this (just mount -u) becomes an easy way to simply set the
> filesys mount to the way fstab says it should be.
Hm, personally I would expect that an "update" option would only update
the options specify, and leave ALL others unchanged. So the "-o
current" syntax would be the default.
MAYBE a special case could be made in case only -u is given and no other
options, that then the fstab options are used, but the "-o fstab" syntax
to make that explicit seems better to me.
-Olaf.
--=20
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.
--0vzXIDBeUiKkjNJl
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJY6+k4AAoJEJmJxkVhw/vTJRgIAMVb9EQQ8JGeJJ99hHVI1XHS
muzwT8MhW7XZDxNFdDD7ePpgjVmzlBVJ5tvGcdCXSt0bQ44Qz0Q1/cLgBqbyQiKR
Ej5m/MUsjyovPqInLaE+r6jjPwkNC+YE8tnmgr0lhoOUMQhpssF6DlKqmwbKsowQ
A+4Ylh4xaXAHIumockJkz7AhrB1WIzHAZJUjTyJ5cZMq9Rd3PAUyw3ODdWOGWZTp
3jSDQhjQzcTr4tT9+XIMeOR9ZXnz8MRRyoNBDUm3IhF40hWYAzC85xERxWZsvWG6
jJ2uR0owXySiOCU9Z+cWwt7G63CfoZ42OjaOOKpC0rRlx9azG7uOK+6rk0343Gs=
=PNmh
-----END PGP SIGNATURE-----
--0vzXIDBeUiKkjNJl--
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home