Kernel panic from lagg_ioctl and lagg_port_ioctl

Lewis, Fred flewis at panasas.com
Wed Jan 13 16:48:20 UTC 2016


Hi Hans,

Can you give an example of draining the callouts?

Thanks,
-Fred

On 1/13/16 7:33 AM, "Lakshmi Narasimhan Sundararajan" <lakshmi.n at msystechnologies.com<mailto:lakshmi.n at msystechnologies.com>> wrote:

Hi Hans,
Yes, we understand that piece of code.

But Panasas wants this change to MFC to 10.3. This issue is not seen in 11. Would that happen? I have not seen acknowledgement of this issue or confirmation of MFC to 10.3. That information will help us plan.

Regards,
LN

On Wed, Jan 13, 2016 at 6:02 PM, Hans Petter Selasky <hps at selasky.org<mailto:hps at selasky.org>> wrote:
On 01/12/16 22:13, Lewis, Fred wrote:
In earlier versions of lagg_ioctl() (e.g. stable/10/r171247) all of the callout
vectors are set to NULL which I think will prevent the problem. Similar NULLing code
is also in stable/7. I didn't check other releases.

Don't forget to drain the callouts before NULL-ing them!

--HPS



DISCLAIMER

The information in this e-mail is confidential and may be subject to legal privilege. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorized. If you have received this communication in error, please address with the subject heading "Received in error," send to it at msystechnologies.com<mailto:it at msystechnologies.com>,  then delete the e-mail and destroy any copies of it. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. The views, opinions, conclusions and other information expressed in this electronic mail and any attachments are not given or endorsed by the company unless otherwise indicated by an authorized representative independent of this message.

MSys cannot guarantee that e-mail communications are secure or error-free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses, though all reasonable precautions have been taken to ensure no viruses are present in this e-mail. As our company cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments we recommend that you subject these to your virus checking procedures prior to use


More information about the freebsd-net mailing list