1. 4
  1.  

  2. 1

    “It turns out that MPTCP sockets are allocated using a slab cache. I found this out early on, but forgot about it nearly as soon as I found out.”

    The real problem isn’t linked lists. It’s that the author learned how something worked (the spec), forgot about that, and then essentially coded against the wrong spec. The title might have instead been: “I forgot something and broke a kernel.” Much more accurate given people who know they’re dealing with slab allocators, linked lists, etc usually use them correctly. They can also sleep a bit better instead of being up until 3am debugging.

    1. 2

      I agree.

      The doubly linked lists obscured the problem though. The memory corruption showed as an infinite loop. It could be an argument to avoid doubly linked lists, if you can get away with a simpler data structure that cannot lead to infinite loops by construction.

      1. 2

        The real problem is using an allocator that doesn’t trash memory after free. :)

      2. 1

        The article left me curious about what release_sock() actually does if not notify when the socket has been released. From the Linux Foundation wiki, https://wiki.linuxfoundation.org/networking/socket_locks, it seems like it’s to release a lock on a socket as opposed to being a handler. There’s also lots of usages of that particular identifier that seem to uphold that idea: http://lxr.free-electrons.com/ident?i=release_sock

        That said, I’m not sure if I’m in the right ballpark.