i got it, 0x8 = 1000, 1 is at bitmap position 3. with the same logic 0x11 = 10001, it contains fd 4 and fd 0

Very good question. In the tcp protocol we have two kinds of sockets, listen and data sockets. A listen socket is only applicable on the server side and is unique per server ip/port. The data socket is one per source dest ip port quadruple. The listen socket is only there to accept new connection requests. Once a connection request is received the kernel creates a new data socker per incoming ip port. From the application side you wont see these different sockets.

Why ? Three od Nothing deep about Linux here, it's just the surface...

I haven't double check what I am about to say with the source code, but according to my understanding, small and large bins lie at the same level of the hierarchy which is the last one. So the correct sequence should be tcache - fastbin - unsorted - lastly either of small or large bins depending on the size of the requested chunk. The only difference between small and large bins is the chunk size cached there.

Thanks for your reply! I will take this answer and care about this when using gdb to go through them in different version of libc in the future@@deeplinux2248

@@deeplinux2248 I have dived deeper with the glibc source code and play around some heap exploitation with gdb. Then I think I should share some of my findings and thoughts as a feedback. The ptmalloc does operate differently with the _int_malloc & _int_free functions. It is indeed a very complicate system so that it's hard to conclude all the details in a video or a comment. Regarding to _int_malloc in some simple words to conclude, it firstly will search tcache bins, fastbins, smallbins for specific exact-fit free'd chunk inside them. The glibc source code describes that this procedure will be completed to match the small request first, because these bins are of fixed size so it is relatively fast. If _int_malloc cannot find a match with above searching, its behaviour will depend on our request size. 1. If it's a small request, namely under 0x400 bytes, the heap allocator searches the unsorted bins first. If there's only one last remainder chunk inside the unosrted bin, this chunk will be returned to us only if it's exact-fit (glibc: /* Fill cache first, return to user only if cache fills. We may return one of these chunks later. */). If not, when the last remaidner chunk is larger than our request, it will be spillted into one of our request size and anther one as a new remaimder. The one of our request size will be unlinked and returned to us; the one as the new last remainder will go back to unsroted bin (as described in glibc: split and reattach remainder), then it seems to continue the binning process to place the remainder in S/L bins according the rest of the glibc code. At last if our request is larger than the last remaidner in the first place, the top chunk will answer our request (verified through gdb). 2. If it's a large request, namely over 0x400 bytes, it triggers malloc_consolidation first. This means when there are free'd chunks in fastbins (&av->have_fastchunks), adjacent chunks in fastbins will be consolidated into bigger chunks (malloc_consolidate (av)). And the new chunks and all chunks in fastbin will be moved to unsorted bin. Now if there's an exact-fit chunk match our reques size, it will be returned to us. Otherwise these chunks in unsorted bin will be placed in smallbins and largebins. Then we continue to search a fit in the S/L bins (there's also an exact-fit and best-fit problem here, if no exact-fit it will go for a best-fit to do the spliting and reattachment again according to a bitmap thing). If it's yet not satisfied, then comes to the job with top chunk and the rest. This is for now my understanding regarding on the heap management, not 100% sure it's the perfect answer. When I check the time stamp of the last comment, I cannot believe it's 3 weeks ago. Feeling like it has been months. Thanks for your videos to let me understand how it works when I don't have an image of what heap is about.

Wow! thanks that is flattering.

kzbin.info/www/bejne/h56kfYyif6h0nMksi=RmOYs66v2cuMdHo4

Depends what your goal is in your Linux journey. A user or even a simple admin then probably not much. But if you debug kernel issues or write network software in the lower layers then you would not be asking this question😉

Thanks for the encouraging feedback. Softirq is not a kernel thread, it is simply an interrupt handler which serves software interrupts. These are generally functions which are called by the kernel when an interrupt is raised. A softirq has the seconds highest priority after hardirq which serves actual hardware interrupts coming from net or disk, for example. If you require some cobtext of execution in the kernel then you can use simple threads but in kernel space, or if you require a kernel routine then go with tasklets.