-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Panic in spa_update_space #12380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@rincebrain it looks like commit 1325434, PR #12271, introduced this panic. Mind taking a look? If we can sort it out fairly quickly that's great, otherwise we should consider reverting it for now. |
Ruh-roh, I'll see about reproducing on my 18.04 box. I don't recognize that kernel version - is that a periodic snapshot of some git tree? |
That kernel version is an internal representation used at Delphix. It was based on 1325434 running on a modified version of 18.04. |
I have a fix, let me just run it through some more testing and I'll cut a PR... |
@rincebrain any update on this fix? Not to rush you, but this issue is causing a fair bit of heartburn for the CI so it'd be nice to either fix it, or revert 1325434 until we do have a complete fix. |
Oh sorry, I thought the CI wasn't hitting it, which rather surprised me with how often I hit it on my specific VM for it. My fix is the trivial one, just NULL checking before the dereference, I was just trying to confirm there wasn't anything exciting lurking from doing it either in "a different crash" sense or the "nonfatal unwanted behavior" sense, but I haven't seen it do anything obviously interesting yet in loops of just the removal tests or all of -T functional, so I'll just cut the PR. |
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Closes openzfs#12380 Signed-off-by: Rich Ercolani <[email protected]>
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Closes openzfs#12380 Signed-off-by: Rich Ercolani <[email protected]>
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Closes openzfs#12380 Signed-off-by: Rich Ercolani <[email protected]>
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Closes openzfs#12380 Signed-off-by: Rich Ercolani <[email protected]>
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes #12380 Closes #12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes #12380 Closes #12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes #12380 Closes #12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
After 1325434, we can in certain circumstances end up calling spa_update_dspace with vd->vdev_mg NULL, which ends poorly during vdev removal. So let's not do that further space adjustment when we can't. Reviewed-by: Matthew Ahrens <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12380 Closes openzfs#12428
System information
Describe the problem you're observing
Panic during the device removal tests.
Describe how to reproduce the problem
The panic is intermittent, but we've seen it twice since yesterday.
Include any warning/errors/backtraces from the system logs
I believe it's in this section of spa_update_dspace():
when we try to dereference mg_class at the start of the if block.
The text was updated successfully, but these errors were encountered: