Skip to content
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

gnrc_pktbuf_static: fix alignment issue / leaks #9434

Merged

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Jun 27, 2018

Contribution description

This fixes an alignment issue I encountered in the static version of the packet buffer.

The bug is caused by a race-condition where a certain order of operations leads to a chunk being released according to the byte-alignment of the platform, but overlapping potential space for a future _unused_t struct e.g. (x mark allocated regions):

                Future leak of size sizeof(_unused_t)       Time
                v                                            |
+------------+-----+--------------------+                    |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                    +
+------------+-----+--------------------+                    |
                                                             |
+------------+--+--+--------------------+                    |
|               |xxxxxxxxxxxxxxxxxxxxxxx|                    +
+------------+--+--+--------------------+                    |
                                                             |
+-----+------+--+--+--------------------+                    |
|xxxxx|         |xxxxxxxxxxxxxxxxxxxxxxx|                    +
+-----+------+--+--+--------------------+                    |
                                                             |
+-----+------+-----+---------+----------+                    |
|xxxxx|                      |xxxxxxxxxx|                    +
+-----+------+-----+---------+----------+                    |
                                                             |
+------------+-----+--------------------+                    |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                    +
+------------+-----+--------------------+                    |
                                                             |
+------------+-----+--------------------+                    |
|xxxxxxxxxxxxxxxxxx|                    |                    +
+------------+-----+--------------------+                    |
                                                             |
+------------+-----+--------------------+                    |
|            |xxxxx|                    |                    +
+------------+-----+--------------------+                    |
                                                             v

Sadly, I wasn't able to create a reproducable unittest that show-cases this corner-case, since I don't understand the order of operations that cause this one 100%, but the bug is reproducable (but also not
reliably) by sending large (i.e. fragmented) packets to a 6Lo-enabled host from more than 1 host simultaneously (use gnrc_pktbuf_cmd to check but don't confuse incomplete datagrams for leaks; see #9424 for faster clean-up of those). I ran this test twice for an hour with this PR before submitting, to make sure this fixes the issue.

By making the size of _unused_t the only condition for alignment, this bug is fixed.

This PR also contains some optimizations that can be done due to the new alignment (acfe57a)

Issues/PRs references

#9424 can simplify testing a bit

This fixes an alignment issue I encountered in the static version of
the packet buffer.

The bug is caused by a race-condition where a certain order of
operations leads to a chunk being released according to the
byte-alignment of the platform, but overlapping potential space for
a future `_unused_t` struct e.g. (x mark allocated regions):

                    Future leak of size sizeof(_unused_t)       Time
                    v                                            |
    +------------+-----+--------------------+                    |
    |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                    +
    +------------+-----+--------------------+                    |
                                                                 |
    +------------+--+--+--------------------+                    |
    |               |xxxxxxxxxxxxxxxxxxxxxxx|                    +
    +------------+--+--+--------------------+                    |
                                                                 |
    +-----+------+--+--+--------------------+                    |
    |xxxxx|         |xxxxxxxxxxxxxxxxxxxxxxx|                    +
    +-----+------+--+--+--------------------+                    |
                                                                 |
    +-----+------+-----+---------+----------+                    |
    |xxxxx|                      |xxxxxxxxxx|                    +
    +-----+------+-----+---------+----------+                    |
                                                                 |
    +-----+------+-----+--------------------+                    |
    |xxxxx|      |xxxxxxxxxxxxxxxxxxxxxxxxxx|                    +
    +-----+------+-----+--------------------+                    |
                                                                 |
    +------------+-----+--------------------+                    |
    |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                    +
    +------------+-----+--------------------+                    |
                                                                 |
    +------------+-----+--------------------+                    |
    |xxxxxxxxxxxxxxxxxx|                    |                    +
    +------------+-----+--------------------+                    |
                                                                 |
    +------------+-----+--------------------+                    |
    |            |xxxxx|                    |                    +
    +------------+-----+--------------------+                    |
                                                                 v

Sadly, I wasn't able to create a reproducable unittest that show-cases
this corner-case, since I don't understand the order of operations that
cause this one 100%, but the bug is reproducable (but also not
reliably) by sending large (i.e. fragmented) packets to a 6Lo-enabled
host from more than 1 host simultaneously (use `gnrc_pktbuf_cmd` to
check).

By making the size of `_unused_t` the only condition for alignment,
this bug is fixed.
@miri64 miri64 added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: network Area: Networking GNRC labels Jun 27, 2018
@miri64 miri64 requested a review from cgundogan June 27, 2018 15:23
Copy link
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately I couldn't reproduce, but the change is sensible and doesn't break the current behavior. ACK

@cgundogan cgundogan added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jul 2, 2018
@cgundogan
Copy link
Member

tested on the iotlab-testbed using three iotlab-m3 nodes in the paris site. Can confirm the leak pre-PR and the fix post-PR. ACK and GO.

@cgundogan cgundogan merged commit bf33941 into RIOT-OS:master Jul 2, 2018
@miri64 miri64 deleted the gnrc_pktbuf_static/fix/alignment-race branch July 2, 2018 14:32
@miri64
Copy link
Member Author

miri64 commented Jul 2, 2018

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants