Bug 28465
| Summary: | Enabling softupdates on a clean but active filesystem can panic the kernel | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Umesh Krishnaswamy <umesh> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Umesh Krishnaswamy <umesh@juniper.net> writes: > > >Number: 28465 > >Category: kern > >Synopsis: Enabling softupdates on a clean but active filesystem can pa > >Description: > If you do a bunch of reads and writes to a filesystem, then mount it > rdonly and enable softupdates, tunefs will allow you to do so, but > the kernel will panic shortly afterwords with the following stack trace. I think the real bug is that downgrading to read-only doesn't work properly. On Wed, Jun 27, 2001 at 03:01:01PM -0700, Dima Dorfman wrote:
> Umesh Krishnaswamy <umesh@juniper.net> writes:
> >
> > >Number: 28465
> > >Category: kern
> > >Synopsis: Enabling softupdates on a clean but active filesystem can pa
> > >Description:
> > If you do a bunch of reads and writes to a filesystem, then mount it
> > rdonly and enable softupdates, tunefs will allow you to do so, but
> > the kernel will panic shortly afterwords with the following stack trace.
>
> I think the real bug is that downgrading to read-only doesn't work
> properly.
If that is the case, then we should patch tunefs to check if the
filesystem is active. This patch can be applied to RELENG_4. The
mainline code is slightly different.
Umesh.
Index: tunefs.c
===================================================================
diff -u -p -r1.1.1.3 tunefs.c
--- tunefs.c 2001/03/31 04:39:03 1.1.1.3
+++ tunefs.c 2001/06/27 22:33:34
@@ -88,7 +88,7 @@ main(argc, argv)
int argc;
char *argv[];
{
- char *cp, *special, *name, *action;
+ char *cp, *special, *name;
struct stat st;
int i;
int Aflag = 0, active = 0;
@@ -201,17 +201,22 @@ again:
if (argc < 1)
errx(10, "-n: missing %s", name);
argc--, argv++;
- if (strcmp(*argv, "enable") == 0) {
+ if (active) {
+ warnx("%s cannot be changed while filesystem is active", name);
+ } else if (sblock.fs_clean == 0) {
+ warnx ("%s cannot be changed until fsck is run", name);
+ } else {
+ if (strcmp(*argv, "enable") == 0) {
sblock.fs_flags |= FS_DOSOFTDEP;
- action = "set";
- } else if (strcmp(*argv, "disable") == 0) {
+ warnx("%s set", name);
+ } else if (strcmp(*argv, "disable") == 0) {
sblock.fs_flags &= ~FS_DOSOFTDEP;
- action = "cleared";
- } else {
+ warnx("%s cleared", name);
+ } else {
errx(10, "bad %s (options are %s)",
name, "`enable' or `disable'");
- }
- warnx("%s %s", name, action);
+ }
+ }
continue;
case 'o':
Umesh Krishnaswamy <umesh@juniper.net> writes: > On Wed, Jun 27, 2001 at 03:01:01PM -0700, Dima Dorfman wrote: > > Umesh Krishnaswamy <umesh@juniper.net> writes: > > > > > > >Number: 28465 > > > >Category: kern > > > >Synopsis: Enabling softupdates on a clean but active filesystem can pa > > > >Description: > > > If you do a bunch of reads and writes to a filesystem, then mount it > > > rdonly and enable softupdates, tunefs will allow you to do so, but > > > the kernel will panic shortly afterwords with the following stack trace. > > > > I think the real bug is that downgrading to read-only doesn't work > > properly. > > If that is the case, then we should patch tunefs to check if the > filesystem is active. This patch can be applied to RELENG_4. The > mainline code is slightly different. All this does is cover up the bug, and makes it harder for someone to fix it by making them go hack tunefs :-). Unix traditionally allows the user to do silly things. Of course, this isn't documented as a silly thing; that should probably be fixed. Of course, all of this is assuming that my assertion that downgrading to read-only doesn't work as it should; it may have been fixed since I experimented with it, and what you're seeing may be entirely different. Your patch also has a multitude of style bugs, such as four-space primary indents and lines over 80 characters. Dima Dorfman dima@unixfreak.org On Wed, Jun 27, 2001 at 03:45:30PM -0700, Dima Dorfman wrote: > Umesh Krishnaswamy <umesh@juniper.net> writes: > > On Wed, Jun 27, 2001 at 03:01:01PM -0700, Dima Dorfman wrote: > > > Umesh Krishnaswamy <umesh@juniper.net> writes: > > > > > > > > >Number: 28465 > > > > >Category: kern > > > > >Synopsis: Enabling softupdates on a clean but active filesystem can pa > > > > >Description: > > > > If you do a bunch of reads and writes to a filesystem, then mount it > > > > rdonly and enable softupdates, tunefs will allow you to do so, but > > > > the kernel will panic shortly afterwords with the following stack trace. > > > > > > I think the real bug is that downgrading to read-only doesn't work > > > properly. > > > > If that is the case, then we should patch tunefs to check if the > > filesystem is active. This patch can be applied to RELENG_4. The > > mainline code is slightly different. > > All this does is cover up the bug, and makes it harder for someone to > fix it by making them go hack tunefs :-). Unix traditionally allows > the user to do silly things. Of course, this isn't documented as a > silly thing; that should probably be fixed. Of course, all of this is > assuming that my assertion that downgrading to read-only doesn't work > as it should; it may have been fixed since I experimented with it, and > what you're seeing may be entirely different. > > Your patch also has a multitude of style bugs, such as four-space > primary indents and lines over 80 characters. > Fine, don't use it. I would rather see the softdep fixed rather than tunefs. Umesh. > Dima Dorfman > dima@unixfreak.org I suspect that after the filesystem is downgraded to read-only, there is still some dirty data in the buffer cache. In that case, tunefs does the right thing by merely checking that the filesystem is mounted read-only; mount does the wrong thing by returning before syncing the filesystem. State Changed From-To: open->feedback There has been some improvement in this area, is it still a problem for you? Hi, I can't reproduce that panic in -CURRENT. I guess this PR can be closed. regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ State Changed From-To: feedback->closed This problem seems to be resolved. |
If you do a bunch of reads and writes to a filesystem, then mount it rdonly and enable softupdates, tunefs will allow you to do so, but the kernel will panic shortly afterwords with the following stack trace. # tunefs -n enable /altroot tunefs: soft updates setp anic: softdep_deallocate_dependencies: dangling deps softdep_deallocate_dependencies(c0368000,dcde5c98,c01b417a,d01cd00c,d01cd00c) at softdep_deallocate_dependencies+0x16 softdep_deallocate_dependencies(d01cd00c) at softdep_deallocate_dependencies+0x16 brelse(d01cd00c,d01cd00c) at brelse+0x6a vinvalbuf(dcd2ee40,0,c41c9800,dcd92400,0) at vinvalbuf+0x24f ffs_reload(c3b4be00,c41c9800,dcd92400,0,c3b4be00) at ffs_reload+0x51 ffs_mount(c3b4be00,4810890f,bfbff83c,dcde5e80,dcd92400) at ffs_mount+0x163 mount(dcd92400,dcde5f80,bfbff83c,bfbffdf9,8049517) at mount+0x4ef syscall2(2f,2f,2f,8049517,bfbffdf9) at syscall2+0x1fd Xint0x80_syscall() at Xint0x80_syscall+0x25 Debugger("panic") Stopped at Debugger+0x40: pushl $-0x1 The filesystem activity has a bunch of unwritten buffers. When soft updates is enabled in this state, the iodone routine i How-To-Repeat: fs is the name of a filesystem. If you do these four steps, you will panic the system. mount /fs tar cvfz foo.tgz /usr/lib mount -u -o rdonly /fs tunefs -n enable /fs You will trip into this problem after a bunch of tries. I can successfully reproduce this approx 20% of the time.