Re: Re: reproducible kernel crash with quota
Hello everyone, I made a mistake testing the two patches. The two patches solve the problem. The kernel then no longer seems to crash. Thank you for your efforts Regards Uwe On Thu, 21 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 21 Apr 2022 14:09:03 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 21. Apr 2022, at 00:36, 6b...@6bone.informatik.uni-leipzig.de wrote: On Wed, 20 Apr 2022, J. Hannken-Illjes wrote: Date: Wed, 20 Apr 2022 22:19:30 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 20. Apr 2022, at 22:10, 6b...@6bone.informatik.uni-leipzig.de wrote: On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: Date: Tue, 19 Apr 2022 11:07:48 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: Please try again with both diffs applied. I tested with both patches. If I just enable querquota it seems to work. If you also activate groupquota, the kernel crashes: output: /etc/rc.d/quota restart Checking quotas:quotacheck: creating quota file //quota.group You have root (/) with quota? What exactly do you have in /etc/fstab? cat /etc/fstab # NetBSD /etc/fstab # See /usr/share/examples/fstab/ for more examples. NAME=179d5ca2-7f26-476b-b544-823bd1849816 / ffs rw,userquota,groupquota 1 1 I'm confused. With "/dev/ld0a / ffs rw,userquota,groupquota 1 1" in /etc/fstab and both patches applied I get: $ /etc/rc.d/quota restart Checking quotas: done. No line "creating quota file ..." -- J. Hannken-Illjes - hann...@mailbox.org
Re: Re: reproducible kernel crash with quota
On Thu, 21 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 21 Apr 2022 14:09:03 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 21. Apr 2022, at 00:36, 6b...@6bone.informatik.uni-leipzig.de wrote: On Wed, 20 Apr 2022, J. Hannken-Illjes wrote: Date: Wed, 20 Apr 2022 22:19:30 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 20. Apr 2022, at 22:10, 6b...@6bone.informatik.uni-leipzig.de wrote: On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: Date: Tue, 19 Apr 2022 11:07:48 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: Please try again with both diffs applied. I tested with both patches. If I just enable querquota it seems to work. If you also activate groupquota, the kernel crashes: output: /etc/rc.d/quota restart Checking quotas:quotacheck: creating quota file //quota.group You have root (/) with quota? What exactly do you have in /etc/fstab? cat /etc/fstab # NetBSD /etc/fstab # See /usr/share/examples/fstab/ for more examples. NAME=179d5ca2-7f26-476b-b544-823bd1849816 / ffs rw,userquota,groupquota 1 1 I'm confused. With "/dev/ld0a / ffs rw,userquota,groupquota 1 1" in /etc/fstab and both patches applied I get: $ /etc/rc.d/quota restart Checking quotas: done. No line "creating quota file ..." Sorry My mistake! I had deleted the quota.group file. I wanted to make sure that the problem wasn't caused by a corrupt file. I tested again with the current sources and the two patches. The crash can still be reproduced. Thank you for your efforts Regards Uwe -- J. Hannken-Illjes - hann...@mailbox.org
Re: reproducible kernel crash with quota
> On 21. Apr 2022, at 00:36, 6b...@6bone.informatik.uni-leipzig.de wrote: > > On Wed, 20 Apr 2022, J. Hannken-Illjes wrote: > >> Date: Wed, 20 Apr 2022 22:19:30 +0200 >> From: J. Hannken-Illjes >> To: 6b...@6bone.informatik.uni-leipzig.de >> Cc: current-users@netbsd.org, Manuel Bouyer >> Subject: [Extern] Re: reproducible kernel crash with quota >>> On 20. Apr 2022, at 22:10, 6b...@6bone.informatik.uni-leipzig.de wrote: >>> >>> On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: >>> >>>> Date: Tue, 19 Apr 2022 11:07:48 +0200 >>>> From: J. Hannken-Illjes >>>> To: 6b...@6bone.informatik.uni-leipzig.de >>>> Cc: current-users@netbsd.org, Manuel Bouyer >>>> Subject: [Extern] Re: reproducible kernel crash with quota >>>>> On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: >>>> Please try again with both diffs applied. >>> >>> I tested with both patches. If I just enable querquota it seems to work. If >>> you also activate groupquota, the kernel crashes: >>> >>> output: >>> >>> /etc/rc.d/quota restart >>> Checking quotas:quotacheck: creating quota file //quota.group >> >> You have root (/) with quota? What exactly do you have in /etc/fstab? > > cat /etc/fstab > # NetBSD /etc/fstab > # See /usr/share/examples/fstab/ for more examples. > NAME=179d5ca2-7f26-476b-b544-823bd1849816 / ffs > rw,userquota,groupquota 1 1 I'm confused. With "/dev/ld0a / ffs rw,userquota,groupquota 1 1" in /etc/fstab and both patches applied I get: $ /etc/rc.d/quota restart Checking quotas: done. No line "creating quota file ..." -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP
Re: Re: reproducible kernel crash with quota
On Wed, 20 Apr 2022, J. Hannken-Illjes wrote: Date: Wed, 20 Apr 2022 22:19:30 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 20. Apr 2022, at 22:10, 6b...@6bone.informatik.uni-leipzig.de wrote: On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: Date: Tue, 19 Apr 2022 11:07:48 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: On Thu, 14 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 14 Apr 2022 13:09:02 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 12. Apr 2022, at 08:52, 6b...@6bone.informatik.uni-leipzig.de wrote: Hello, since I already have some open bugs with reproducible kernel crashes, I'm only writing this to the mailing list. how to reproduce the crash: /etc/rc.d/quota restart dmesg: [ 412.047595] panic: kernel diagnostic assertion "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 [ 412.047595] cpu8: Begin traceback... [ 412.047595] vpanic() at netbsd:vpanic+0x156 [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b [ 412.057595] dqflush() at netbsd:dqflush+0x92 [ 412.057595] quota1_handle_cmd_quotaoff() at netbsd:quota1_handle_cmd_quotaof f+0x120 [ 412.057595] ufs_quotactl() at netbsd:ufs_quotactl+0x3d [ 412.057595] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 [ 412.057595] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b [ 412.057595] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 [ 412.067595] sys___quotactl() at netbsd:sys___quotactl+0x2e [ 412.067595] syscall() at netbsd:syscall+0x196 [ 412.067595] --- syscall (number 473) --- [ 412.067595] netbsd:syscall+0x196: [ 412.067595] cpu8: End traceback... [ 412.067595] dumping to dev 168,1 (offset=8, size=33425953): [ 412.067595] dump (gdb) target kvm netbsd.1.core I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? with gdb: frame 4 (dqflush()) print dq->dq_ump->um_quotas[0] print dq->dq_ump->um_quotas[1] gives the same vnode address for both fields, yes? If this is the case the attached diff should help, since 2012-01-30 group quota got enabled on the user quota file. As a workaround you could try to name the quota files in /etc/fstab like "groupquota=XXX/quota.group". You are right. I use groupquota and userquota in fstab. I tested the patch. With patch there is no crash. But the /etc/rc.d/quota restart leads to the blocking of the file system. You can only turn off the server. This also happens when I only use userquota in the fstab. Sorry, forgot the second diff (now attached) that prevents looping when taking the quota off on a modified file system. Please try again with both diffs applied. I tested with both patches. If I just enable querquota it seems to work. If you also activate groupquota, the kernel crashes: output: /etc/rc.d/quota restart Checking quotas:quotacheck: creating quota file //quota.group You have root (/) with quota? What exactly do you have in /etc/fstab? cat /etc/fstab # NetBSD /etc/fstab # See /usr/share/examples/fstab/ for more examples. NAME=179d5ca2-7f26-476b-b544-823bd1849816 / ffs rw,userquota,groupquota 1 1 NAME=088fb0c9-d042-451d-b768-39d9c1f44a17 noneswap sw,dp 0 0 tmpfs /tmptmpfs rw,-m=1777,-s=ram%15 kernfs /kern kernfs rw ptyfs /dev/ptsptyfs rw procfs /proc procfs rw /dev/cd0a /cdrom cd9660 ro,noauto tmpfs /var/shmtmpfs rw,-m1777,-sram%15 done. -> crash Are "dq->dq_ump->um_quotas[0]" and "dq->dq_ump->um_quotas[1]]" now different? [ 448.325252] panic: kernel diagnostic assertion "dq->dq_ump->um_quotas[dq->dq_type] != vp" failed: file "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 [ 448.325252] cpu1: Begin traceback... [ 448.325252] vpanic() at netbsd:vpanic+0x156 [ 448.325252] kern_assert() at netbsd:kern_assert+0x4b [ 448.325252] dqflush() at netbsd:dqflush+0x92 [ 448.335252] quota1_handle_cmd_quotaoff() at netbsd:quota1_handle_cmd_quotaoff+0x117 [ 448.335252] ufs_quotactl() at netbsd:ufs_quotactl+0x3d [ 448.335252] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 [ 448.335252] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b [ 448.335252] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 [ 448.335252] sys___quotactl() at netbsd:sys___quotactl+0x2e [ 448.345252] syscall() at netb
Re: reproducible kernel crash with quota
> On 20. Apr 2022, at 22:10, 6b...@6bone.informatik.uni-leipzig.de wrote: > > On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: > >> Date: Tue, 19 Apr 2022 11:07:48 +0200 >> From: J. Hannken-Illjes >> To: 6b...@6bone.informatik.uni-leipzig.de >> Cc: current-users@netbsd.org, Manuel Bouyer >> Subject: [Extern] Re: reproducible kernel crash with quota >>> On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: >>> >>> On Thu, 14 Apr 2022, J. Hannken-Illjes wrote: >>> >>>> Date: Thu, 14 Apr 2022 13:09:02 +0200 >>>> From: J. Hannken-Illjes >>>> To: 6b...@6bone.informatik.uni-leipzig.de >>>> Cc: current-users@netbsd.org, Manuel Bouyer >>>> Subject: [Extern] Re: reproducible kernel crash with quota >>>>> On 12. Apr 2022, at 08:52, 6b...@6bone.informatik.uni-leipzig.de wrote: >>>>> >>>>> Hello, >>>>> >>>>> since I already have some open bugs with reproducible kernel crashes, I'm >>>>> only writing this to the mailing list. >>>>> >>>>> how to reproduce the crash: /etc/rc.d/quota restart >>>>> >>>>> dmesg: >>>>> >>>>> [ 412.047595] panic: kernel diagnostic assertion >>>>> "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file >>>>> "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 >>>>> [ 412.047595] cpu8: Begin traceback... >>>>> [ 412.047595] vpanic() at netbsd:vpanic+0x156 >>>>> [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b >>>>> [ 412.057595] dqflush() at netbsd:dqflush+0x92 >>>>> [ 412.057595] quota1_handle_cmd_quotaoff() at >>>>> netbsd:quota1_handle_cmd_quotaof f+0x120 >>>>> [ 412.057595] ufs_quotactl() at netbsd:ufs_quotactl+0x3d >>>>> [ 412.057595] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 >>>>> [ 412.057595] vfs_quotactl_quotaoff() at >>>>> netbsd:vfs_quotactl_quotaoff+0x1b >>>>> [ 412.057595] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 >>>>> [ 412.067595] sys___quotactl() at netbsd:sys___quotactl+0x2e >>>>> [ 412.067595] syscall() at netbsd:syscall+0x196 >>>>> [ 412.067595] --- syscall (number 473) --- >>>>> [ 412.067595] netbsd:syscall+0x196: >>>>> [ 412.067595] cpu8: End traceback... >>>>> >>>>> [ 412.067595] dumping to dev 168,1 (offset=8, size=33425953): >>>>> [ 412.067595] dump >>>>> >>>>> >>>>> (gdb) target kvm netbsd.1.core >>>> >>>> >>>> I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? >>>> >>>> with gdb: >>>> >>>> frame 4 (dqflush()) >>>> print dq->dq_ump->um_quotas[0] >>>> print dq->dq_ump->um_quotas[1] >>>> >>>> gives the same vnode address for both fields, yes? >>>> >>>> If this is the case the attached diff should help, since 2012-01-30 >>>> group quota got enabled on the user quota file. >>>> >>>> As a workaround you could try to name the quota files in /etc/fstab >>>> like "groupquota=XXX/quota.group". >>> >>> You are right. I use groupquota and userquota in fstab. I tested the patch. >>> With patch there is no crash. But the /etc/rc.d/quota restart leads to the >>> blocking of the file system. You can only turn off the server. This also >>> happens when I only use userquota in the fstab. >> >> Sorry, forgot the second diff (now attached) that prevents looping >> when taking the quota off on a modified file system. >> >> Please try again with both diffs applied. > > I tested with both patches. If I just enable querquota it seems to work. If > you also activate groupquota, the kernel crashes: > > output: > > /etc/rc.d/quota restart > Checking quotas:quotacheck: creating quota file //quota.group You have root (/) with quota? What exactly do you have in /etc/fstab? > done. > > -> crash Are "dq->dq_ump->um_quotas[0]" and "dq->dq_ump->um_quotas[1]]" now different? > [ 448.325252] panic: kernel diagnostic assertion > "dq->dq_ump->um_quotas[dq->dq_type] != vp" failed: file > "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 > [ 448.325252] cpu1: Begin tra
Re: Re: reproducible kernel crash with quota
On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: Date: Tue, 19 Apr 2022 11:07:48 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: On Thu, 14 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 14 Apr 2022 13:09:02 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 12. Apr 2022, at 08:52, 6b...@6bone.informatik.uni-leipzig.de wrote: Hello, since I already have some open bugs with reproducible kernel crashes, I'm only writing this to the mailing list. how to reproduce the crash: /etc/rc.d/quota restart dmesg: [ 412.047595] panic: kernel diagnostic assertion "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 [ 412.047595] cpu8: Begin traceback... [ 412.047595] vpanic() at netbsd:vpanic+0x156 [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b [ 412.057595] dqflush() at netbsd:dqflush+0x92 [ 412.057595] quota1_handle_cmd_quotaoff() at netbsd:quota1_handle_cmd_quotaof f+0x120 [ 412.057595] ufs_quotactl() at netbsd:ufs_quotactl+0x3d [ 412.057595] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 [ 412.057595] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b [ 412.057595] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 [ 412.067595] sys___quotactl() at netbsd:sys___quotactl+0x2e [ 412.067595] syscall() at netbsd:syscall+0x196 [ 412.067595] --- syscall (number 473) --- [ 412.067595] netbsd:syscall+0x196: [ 412.067595] cpu8: End traceback... [ 412.067595] dumping to dev 168,1 (offset=8, size=33425953): [ 412.067595] dump (gdb) target kvm netbsd.1.core I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? with gdb: frame 4 (dqflush()) print dq->dq_ump->um_quotas[0] print dq->dq_ump->um_quotas[1] gives the same vnode address for both fields, yes? If this is the case the attached diff should help, since 2012-01-30 group quota got enabled on the user quota file. As a workaround you could try to name the quota files in /etc/fstab like "groupquota=XXX/quota.group". You are right. I use groupquota and userquota in fstab. I tested the patch. With patch there is no crash. But the /etc/rc.d/quota restart leads to the blocking of the file system. You can only turn off the server. This also happens when I only use userquota in the fstab. Sorry, forgot the second diff (now attached) that prevents looping when taking the quota off on a modified file system. Please try again with both diffs applied. I tested with both patches. If I just enable querquota it seems to work. If you also activate groupquota, the kernel crashes: output: /etc/rc.d/quota restart Checking quotas:quotacheck: creating quota file //quota.group done. -> crash [ 448.325252] panic: kernel diagnostic assertion "dq->dq_ump->um_quotas[dq->dq_type] != vp" failed: file "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 [ 448.325252] cpu1: Begin traceback... [ 448.325252] vpanic() at netbsd:vpanic+0x156 [ 448.325252] kern_assert() at netbsd:kern_assert+0x4b [ 448.325252] dqflush() at netbsd:dqflush+0x92 [ 448.335252] quota1_handle_cmd_quotaoff() at netbsd:quota1_handle_cmd_quotaoff+0x117 [ 448.335252] ufs_quotactl() at netbsd:ufs_quotactl+0x3d [ 448.335252] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 [ 448.335252] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b [ 448.335252] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 [ 448.335252] sys___quotactl() at netbsd:sys___quotactl+0x2e [ 448.345252] syscall() at netbsd:syscall+0x196 [ 448.345252] --- syscall (number 473) --- [ 448.345252] netbsd:syscall+0x196: [ 448.345252] cpu1: End traceback... [ 448.345252] dumping to dev 168,1 (offset=8, size=33425953): [ 448.345252] dump Thank you for your efforts Regards Uwe Maybe someone can fix the problem. Thank you for your efforts Regards Uwe -- J. Hannken-Illjes - hann...@mailbox.org -- J. Hannken-Illjes - hann...@mailbox.org
Re: reproducible kernel crash with quota
On Thu, Apr 14, 2022 at 01:09:02PM +0200, J. Hannken-Illjes wrote: > I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? > > with gdb: > > frame 4 (dqflush()) > print dq->dq_ump->um_quotas[0] > print dq->dq_ump->um_quotas[1] > > gives the same vnode address for both fields, yes? > > If this is the case the attached diff should help, since 2012-01-30 > group quota got enabled on the user quota file. ...ooops -- David A. Holland dholl...@netbsd.org
Re: reproducible kernel crash with quota
> On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote: > > On Thu, 14 Apr 2022, J. Hannken-Illjes wrote: > >> Date: Thu, 14 Apr 2022 13:09:02 +0200 >> From: J. Hannken-Illjes >> To: 6b...@6bone.informatik.uni-leipzig.de >> Cc: current-users@netbsd.org, Manuel Bouyer >> Subject: [Extern] Re: reproducible kernel crash with quota >>> On 12. Apr 2022, at 08:52, 6b...@6bone.informatik.uni-leipzig.de wrote: >>> >>> Hello, >>> >>> since I already have some open bugs with reproducible kernel crashes, I'm >>> only writing this to the mailing list. >>> >>> how to reproduce the crash: /etc/rc.d/quota restart >>> >>> dmesg: >>> >>> [ 412.047595] panic: kernel diagnostic assertion >>> "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file >>> "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 >>> [ 412.047595] cpu8: Begin traceback... >>> [ 412.047595] vpanic() at netbsd:vpanic+0x156 >>> [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b >>> [ 412.057595] dqflush() at netbsd:dqflush+0x92 >>> [ 412.057595] quota1_handle_cmd_quotaoff() at >>> netbsd:quota1_handle_cmd_quotaof f+0x120 >>> [ 412.057595] ufs_quotactl() at netbsd:ufs_quotactl+0x3d >>> [ 412.057595] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 >>> [ 412.057595] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b >>> [ 412.057595] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 >>> [ 412.067595] sys___quotactl() at netbsd:sys___quotactl+0x2e >>> [ 412.067595] syscall() at netbsd:syscall+0x196 >>> [ 412.067595] --- syscall (number 473) --- >>> [ 412.067595] netbsd:syscall+0x196: >>> [ 412.067595] cpu8: End traceback... >>> >>> [ 412.067595] dumping to dev 168,1 (offset=8, size=33425953): >>> [ 412.067595] dump >>> >>> >>> (gdb) target kvm netbsd.1.core >> >> >> I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? >> >> with gdb: >> >> frame 4 (dqflush()) >> print dq->dq_ump->um_quotas[0] >> print dq->dq_ump->um_quotas[1] >> >> gives the same vnode address for both fields, yes? >> >> If this is the case the attached diff should help, since 2012-01-30 >> group quota got enabled on the user quota file. >> >> As a workaround you could try to name the quota files in /etc/fstab >> like "groupquota=XXX/quota.group". > > You are right. I use groupquota and userquota in fstab. I tested the patch. > With patch there is no crash. But the /etc/rc.d/quota restart leads to the > blocking of the file system. You can only turn off the server. This also > happens when I only use userquota in the fstab. Sorry, forgot the second diff (now attached) that prevents looping when taking the quota off on a modified file system. Please try again with both diffs applied. > Thank you for your efforts > > Regards > Uwe > > >> >>> >>> Maybe someone can fix the problem. >>> >>> >>> Thank you for your efforts >>> >>> >>> Regards >>> Uwe >> >> -- >> J. Hannken-Illjes - hann...@mailbox.org >> -- J. Hannken-Illjes - hann...@mailbox.org 003_quota_flag.diff Description: Binary data signature.asc Description: Message signed with OpenPGP
Re: Re: reproducible kernel crash with quota
On Thu, 14 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 14 Apr 2022 13:09:02 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 12. Apr 2022, at 08:52, 6b...@6bone.informatik.uni-leipzig.de wrote: Hello, since I already have some open bugs with reproducible kernel crashes, I'm only writing this to the mailing list. how to reproduce the crash: /etc/rc.d/quota restart dmesg: [ 412.047595] panic: kernel diagnostic assertion "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 [ 412.047595] cpu8: Begin traceback... [ 412.047595] vpanic() at netbsd:vpanic+0x156 [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b [ 412.057595] dqflush() at netbsd:dqflush+0x92 [ 412.057595] quota1_handle_cmd_quotaoff() at netbsd:quota1_handle_cmd_quotaof f+0x120 [ 412.057595] ufs_quotactl() at netbsd:ufs_quotactl+0x3d [ 412.057595] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 [ 412.057595] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b [ 412.057595] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 [ 412.067595] sys___quotactl() at netbsd:sys___quotactl+0x2e [ 412.067595] syscall() at netbsd:syscall+0x196 [ 412.067595] --- syscall (number 473) --- [ 412.067595] netbsd:syscall+0x196: [ 412.067595] cpu8: End traceback... [ 412.067595] dumping to dev 168,1 (offset=8, size=33425953): [ 412.067595] dump (gdb) target kvm netbsd.1.core I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? with gdb: frame 4 (dqflush()) print dq->dq_ump->um_quotas[0] print dq->dq_ump->um_quotas[1] gives the same vnode address for both fields, yes? If this is the case the attached diff should help, since 2012-01-30 group quota got enabled on the user quota file. As a workaround you could try to name the quota files in /etc/fstab like "groupquota=XXX/quota.group". You are right. I use groupquota and userquota in fstab. I tested the patch. With patch there is no crash. But the /etc/rc.d/quota restart leads to the blocking of the file system. You can only turn off the server. This also happens when I only use userquota in the fstab. Thank you for your efforts Regards Uwe Maybe someone can fix the problem. Thank you for your efforts Regards Uwe -- J. Hannken-Illjes - hann...@mailbox.org
Re: reproducible kernel crash with quota
> On 12. Apr 2022, at 08:52, 6b...@6bone.informatik.uni-leipzig.de wrote: > > Hello, > > since I already have some open bugs with reproducible kernel crashes, I'm > only writing this to the mailing list. > > how to reproduce the crash: /etc/rc.d/quota restart > > dmesg: > > [ 412.047595] panic: kernel diagnostic assertion > "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file > "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 > [ 412.047595] cpu8: Begin traceback... > [ 412.047595] vpanic() at netbsd:vpanic+0x156 > [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b > [ 412.057595] dqflush() at netbsd:dqflush+0x92 > [ 412.057595] quota1_handle_cmd_quotaoff() at > netbsd:quota1_handle_cmd_quotaof f+0x120 > [ 412.057595] ufs_quotactl() at netbsd:ufs_quotactl+0x3d > [ 412.057595] VFS_QUOTACTL() at netbsd:VFS_QUOTACTL+0x22 > [ 412.057595] vfs_quotactl_quotaoff() at netbsd:vfs_quotactl_quotaoff+0x1b > [ 412.057595] do_sys_quotactl() at netbsd:do_sys_quotactl+0xf1 > [ 412.067595] sys___quotactl() at netbsd:sys___quotactl+0x2e > [ 412.067595] syscall() at netbsd:syscall+0x196 > [ 412.067595] --- syscall (number 473) --- > [ 412.067595] netbsd:syscall+0x196: > [ 412.067595] cpu8: End traceback... > > [ 412.067595] dumping to dev 168,1 (offset=8, size=33425953): > [ 412.067595] dump > > > (gdb) target kvm netbsd.1.core I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? with gdb: frame 4 (dqflush()) print dq->dq_ump->um_quotas[0] print dq->dq_ump->um_quotas[1] gives the same vnode address for both fields, yes? If this is the case the attached diff should help, since 2012-01-30 group quota got enabled on the user quota file. As a workaround you could try to name the quota files in /etc/fstab like "groupquota=XXX/quota.group". > > Maybe someone can fix the problem. > > > Thank you for your efforts > > > Regards > Uwe -- J. Hannken-Illjes - hann...@mailbox.org quota_oldfiles.c.diff Description: Binary data signature.asc Description: Message signed with OpenPGP
Re: reproducible kernel crash with quota
On Tue, Apr 12, 2022 at 08:52:28AM +0200, 6b...@6bone.informatik.uni-leipzig.de wrote: > Hello, > > since I already have some open bugs with reproducible kernel crashes, I'm > only writing this to the mailing list. > > how to reproduce the crash: /etc/rc.d/quota restart > > dmesg: > > [ 412.047595] panic: kernel diagnostic assertion > "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file > "/usr/src/sys/ufs/ufs/ufs_quota.c", line 978 > [ 412.047595] cpu8: Begin traceback... > [ 412.047595] vpanic() at netbsd:vpanic+0x156 > [ 412.057595] kern_assert() at netbsd:kern_assert+0x4b > [ 412.057595] dqflush() at netbsd:dqflush+0x92 > [ 412.057595] quota1_handle_cmd_quotaoff() at > netbsd:quota1_handle_cmd_quotaof f+0x120 I wonder if, when quota1_handle_cmd_quotaoff() can't get an exclusive lock for a vnode, could fail to free the associated quota structure. Shoudln't it wait for the exclusive vnlock or retry in this case ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
