Project

General

Profile

Bug #13968

Kernel Panic updating to 9.10

Added by survive - over 4 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
No priority
Assignee:
Chris Torek
Category:
OS
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Hi guys,

I have a filer I am trying to update from 9.3.1 to 9.10. Originally I opened Bug #13906 thinking it was something going wrong with the database update but further investigation shows it's a panic & so I was asked to open a new ticket to track the panic.

Attached are the files located in /data/crash I collected from the 9.10 update environment.

Associated revisions

Revision 987c9d0c (diff)
Added by Chris Torek over 4 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision 987c9d0c (diff)
Added by Chris Torek over 4 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision f82c7aac (diff)
Added by Chris Torek almost 4 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision f82c7aac (diff)
Added by Chris Torek almost 4 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision 34462da8 (diff)
Added by Chris Torek over 3 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision 34462da8 (diff)
Added by Chris Torek over 3 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision 1ebc646c (diff)
Added by Chris Torek over 3 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

Revision 1ebc646c (diff)
Added by Chris Torek over 3 years ago

ip_multicast: defer vnet restore in in_leavegroup Note: in_leavegroup() does all its real work in in_leavegroup_locked(). For discussion here the two] functions might as well be equivalent. In in_leavegroup_locked(), when we're shedding a multicast group, we may (or may not) delete it from an interface via the igmp_change_state() call. This is where we currently set the multicast's vnet, and then restore the old vnet on return. However, a few lines later we use inm_release_locked() to release the inet multicast data structure, and that in turn may -- not necessarily will, only if the inm really is being freed -- call if_delmulti_ifma(), which may -- not necessarily will, again -- call the interface's SIOCDELMULTI ioctl (if and only if there is an interface and this was the last ref to this multicast address). For (at least) the lagg interface, we still need the current vnet to be valid during the SIOCDELMULTI. So, don't restore the old vnet until we've not only finished the IGMP code but also inm_release_locked(). Ticket: #13968

History

#1 Updated by Josh Paetzel over 4 years ago

Are you using a lagg?

#2 Updated by Josh Paetzel over 4 years ago

lagg0: link state changed to DOWN

Answered my own question.

#3 Updated by Josh Paetzel over 4 years ago

  • Assignee changed from Jakub Klama to Chris Torek

I have a system on a serial console that can repro this.

#4 Updated by survive - over 4 years ago

Hi guys,

I can get you access to a box connected to the filer via a serial cable if you would like.

-Will

#5 Updated by Chris Torek over 4 years ago

  • Status changed from Unscreened to Screened

#6 Updated by Josh Paetzel over 4 years ago

The patch fixed the panic I was seeing.

Survive: The patch made it in to the nightlies last night. Go ahead and try to update and see what happens.

#7 Updated by survive - over 4 years ago

Hi Josh,

I updated to FreeNAS-9.10-MASTER-201603061830 successfully.

-Will

#8 Updated by Chris Torek over 4 years ago

  • Status changed from Screened to Resolved

I'll call it fixed then, yay :D

#9 Updated by Dru Lavigne almost 3 years ago

  • Target version set to Master - FreeNAS Nightlies

#10 Updated by Dru Lavigne almost 3 years ago

  • File deleted (Crash.zip)

Also available in: Atom PDF