Project

General

Profile

Actions

Bug #5734

closed

IPFGENITER needs to know when to hit the brakes

Added by Robert Mustacchi over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
networking
Start date:
2015-03-20
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

When we enter ipf_findtoken(), we basically have initialized our current
ipf_stack_t. Effectively here we have the head set to NULL and the tail
pointer points to the head. eg.:

[0]> ffffff018e787000::print -a ipf_stack_t ifs_ipftokenhead ifs_ipftokentail
ffffff018e788048 ifs_ipftokenhead = 0
ffffff018e788050 ifs_ipftokentail = 0xffffff018e788048

When we're done here, we've initialized our token at ffffff01b7e27f10
and added it to the empty list. This means that our token and list look
like:

[0]> ffffff01b7e27f10::print ipftoken_t
{
    ipt_next = 0
    ipt_pnext = 0xffffff018e788048
    ipt_ctx = 0xffffff01b80d70b0
    ipt_data = 0
    ipt_die = 0x74
    ipt_type = 0x2
    ipt_uid = 0
    ipt_subtype = 0xbaddcafe
    ipt_alive = 0x1
}
[0]> ffffff018e787000::print -a ipf_stack_t ifs_ipftokenhead ifs_ipftokentail
ffffff018e788048 ifs_ipftokenhead = 0xffffff01b7e27f10
ffffff018e788050 ifs_ipftokentail = 0xffffff01b7e27f10

Next, let's look at the thing we're being asked to iterate with, here's that
structure:

[0]> ffffff00052d0840::print ipfgeniter_t
{
    igi_type = 0x2
    igi_nitems = 0x3035322e
    igi_data = 0xfffffd7fffdfb2f0
}

The igi_nitems looks bogus, but maybe it's allowed to be for this ioctl?
Regardless, we've been asked to iterate over the ipnat table. Let's see, do we
have any instances. Because the value of ipt_data is NULL, we'll end up using
the state from the stack itself:

[0]> ffffff018e787000::print ipf_stack_t ifs_nat_instances
ifs_nat_instances = 0

Which makes sense, we have no NAT instances at the moment. This means that we should end up basically setting the igi_data to zero. Let's verify this by looking at our ipfgeniter_t when we get to the point of a copyout.

Because we have no data, we go ahead and free the token. Now that we've done
this, the token looks like and the corresponding stack pointers:

[0]> ffffff01b7e27f10::print ipftoken_t
{
    ipt_next = 0xdeadbeefdeadbeef
    ipt_pnext = 0xdeadbeefdeadbeef
    ipt_ctx = 0xdeadbeefdeadbeef
    ipt_data = 0xdeadbeefdeadbeef
    ipt_die = 0xdeadbeefdeadbeef
    ipt_type = 0xdeadbeef
    ipt_uid = 0xdeadbeef
    ipt_subtype = 0xdeadbeef
    ipt_alive = 0xdeadbeef
}
[0]> ffffff018e787000::print -a ipf_stack_t ifs_ipftokenhead ifs_ipftokentail
ffffff018e788048 ifs_ipftokenhead = 0
ffffff018e788050 ifs_ipftokentail = 0xffffff018e788048

However, because count is off and we don't properly break out of the loop even though we know there's nothing left, we end up coming back into ipf_freetoken with the token we just freed.

Actions #1

Updated by Electric Monk over 7 years ago

  • Status changed from Pending RTI to Closed

git commit 58d7f9e61903e78a381912527dc9dacb6e7feddc

commit  58d7f9e61903e78a381912527dc9dacb6e7feddc
Author: Robert Mustacchi <rm@joyent.com>
Date:   2015-03-21T00:52:03.000Z

    5734 IPFGENITER needs to know when to hit the brakes
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: Dan McDonald <danmcd@omniti.com>
    Reviewed by: Richard Lowe <richlowe@richlowe.net>
    Approved by: Garrett D'Amore <garrett@damore.org>

Actions

Also available in: Atom PDF