Basic project to learn more about Linux system calls and C programming. I accept any criticism.

Hi everyone, I want to write a simple program that gives a copy of the physical interface of the received packets to user space, then I extract information manually and show it in stdout.

When I started searching for this topic, I found some ways but I confuse which one is better for my situation.

I read below doc:

doc1

doc2 and ....

Abstract of the above docs, exsit below methods:

1 - Universal TUN/TAP

2 - XDP

3 - MacVTap (is a new driver)

4- ....

If anyone has experience or knowledge in this context, please help me.

Dependency map of the Linux kernel tree (commit a635d67), rendered with D3.

What's in the graph:

• 94.8K files, ~1.1M extracted symbols, 231.8K import/include relationships
• Red edges: primary provider → consumer imports between subsystems
• Blue edges: test-to-subject mappings (5,078 of them)
• Circle packing follows the directory tree; region size ≈ file count

A few things that stood out while building it:

• include/ (6.6K files) is the gravity well everything bends toward, followed by kernel/ and lib/.
• The whole tree resolves to only 9 external packages — sphinx and friends, all documentation tooling. The kernel proper depends on nothing outside itself.
• tools/ (9.3K files) forms an almost separate continent, barely coupled to the rest.

Happy to answer questions about the extraction pipeline or share higher-res views of specific subsystems (net/, mm/, drivers/)

I kept running into the same Linux debugging pain: something broke on a box, but I had no history of what actually happened. journald helps a little. auditd is heavy. strace is too narrow. So I built ltm — a small machine-history debugger that records process/file/network metadata via eBPF and lets you query it like a timeline.

What it does:

• Attaches to syscall tracepoints (exec, open/write/rename/unlink, connect/bind, etc.)

• Stores metadata only (no file contents)

• Lets you do things like:

sudo ltm start --mode ebpf

ltm status

ltm timeline --since 1h

ltm diff --from "10m" --to now

ltm query "who modified /tmp/ltm-demo.txt?"

On a real VM run it recorded ~7k events with 0 drops, and the query returned the exact bash write events that touched the demo file.

There's also a demo mode so you can exercise the CLI/storage/diff/query path without root or BPF.

Stack is Go + embedded BPF ELF + cilium/ebpf. Local store is append-only JSONL. Ignore rules skip /proc, /sys, /dev, and common caches.

Repo: https://github.com/Agent-Hellboy/ltm

Still early. Useful next steps I'm considering:

1. better diff/query formatting
2. containerized eBPF integration test
3. more query templates ("what opened this port?", "what restarted before X?")

Please do star the repo, it will help in discoverability

Researchers have disclosed GhostLock (CVE-2026-43499), a Linux kernel vulnerability that reportedly dates back to 2011. The issue lies in the rtmutex subsystem, where an error during proxy-lock rollback leaves a dangling pointer, resulting in a use-after-free condition.

strace can't see io_uring — requests live in shared-memory rings, not syscalls.

uringscope: single-binary #eBPF tool that reconstructs every request on stock kernels 5.15–6.17, names pathologies with evidence ("fsync punts 100% to io-wq and owns your p99"), and catches in-flight buffer hazards.

https://github.com/rch0wdhury/uringscope

Does anyone have insight into why on kernel.org the latest releases are messed up?

Hi everyone,

I recently made it to the final loop for a specialized systems role at a major silicon company . The technical panel round went incredibly well, but in the final "coding bar" round, I was hit with a textbook Dynamic Programming (DP) question. I solved it through recursion and explained space and time complexity too. It was In-person white boarding coding round.But the optimized solution done using DP. So, I was ultimately rejected for "lacking strong programming skills."

Frankly, it’s frustrating. In my daily world, allocating massive, multi-dimensional DP arrays inside the kernel is a great way to cause memory exhaustion, latency spikes, or a straight-up kernel panic. We care about deterministic execution, restricted stack space, ring buffers, and bit manipulation ,not finding the edit distance of two strings.

Since I am preparing for other top-tier systems/silicon companies (Apple, NVIDIA, Amazon Robotics, Dell), I want to make sure I am prepared for the inevitable generic "coding puzzle" interviewer who doesn't know what a device driver is.

For those of you working in kernel space or hiring for low-level systems, what data structures and algorithmic patterns do you actually consider mandatory to see from a candidate?

My current checklist to review is:

• Bit Manipulation (masks, bitwise operations, clearing/setting registers)
• Concurrency & Synchronization (handling race conditions, producer-consumer with circular/ring buffers)
• Linked Lists & Trees (kernel-style list_head manipulation, basic tree traversal)
• Pointer Arithmetic & Memory Management (custom allocators, page-alignment calculations, string/buffer parsing without helper libraries)
• General patterns like two-pointer, sliding window, Prefix Sum,recursion and sorting.

Should I suck it up and grind standard LeetCode DP/Graph patterns just to pass the cross-functional corporate interviewers, or are there specific systems-adjacent coding patterns I should focus on maximizing?

Would love to hear your thoughts or similar interview horror stories. Thanks!

I have just done it and I can confirm that it's not worth the price at all I am a fairly experienced programmer with 20 years experience all I wanted was a fast way to refresh myself and learn more about the linux kernel in the light of some device drivers development.

It's been the biggest waste of money ever carried out by myself don't do it. Ittakes two Days and takes you until start finally compiling at bloody Linux kernel.

I'm bitterly frustrated I could have been with my daughter one week away somewhere in Europe with that money.

Blueberry is a self-hosted, source-built Linux distribution: a minimal, rolling CLI server system in the BSD tradition. A single source tree produces the base (a pinned prebuilt kernel, glibc, the bpm package manager, the build system) and every package is a recipe in packages/, built from source and served from the project's own signed repository. There are no upstream binary mirrors.

Here is the repo: https://github.com/zsigisti/blueberry

Here is the discord: https://discord.gg/GPfBnbDPHE

Hi everyone,

I work as a Linux kernel developer at a large semicon. I have ~2 years of total exp with about 1 year in kernel development.

I'm working on a fairly large legacy driver where multiple years of fixes, features and hardware support have accumulated. Reading the code is often overwhelming because understanding one path requires tracing through device tree parsing, probe, private data initialization, IRQs, workqueues, callbacks, multiple execution contexts, etc.

I can usually understand individual pieces after spending enough time but I struggle to build and retain a complete mental model of the subsystem. During discussions with senior engineers, I keep forgetting the exact execution flow or where a particular structure (for ex, driver private data populated from DT/SoC information, IRQ calls that come from GIC and the flow afterwards) was initialized, even though I understood it while debugging.

Another issue I've identified is that when deadlines are tight, I tend to rely on LLMs to quickly understand the relevant code path so I can fix a bug or implement a feature. While this helps in the short term, I feel it's hurting my ability to deeply understand the codebase, so I'm trying to reduce that habit.

I'm curious:

- Is this a normal stage for someone with ~1 year of kernel experience?

- How do experienced kernel developers approach understanding large legacy drivers?

- Also how to develop patience to read the code for hours together ? I do love it when I understand a function or a call flow but I feel like the speed isn't enough and my patience to understand something in depth drops after digging in for sometime

I'd really appreciate any advice or habits that helped you early in your kernel career.

The issue first appeared after I moved the beginning of the ext4 partition (/dev/nvme0n1p4) on a GPT-partitioned NVMe SSD to the right using GParted the previous day. The filesystem passes e2fsck -f without any errors, SMART is clean, but the kernel reports invalid checksums for all backup superblocks during mount.

Fedora 44 KDE Plasma, kernel 7.0.13-200.fc44.x86_64, AMD Ryzen AI 9 HX 370 w/ Radeon 890M, NVIDIA Corporation AD107M [GeForce RTX 4060 Max-Q / Mobile]

root@maketopsite:/home/maketopsite# dmesg | grep -i ext4

[ 3.347868] EXT4-fs (nvme0n1p5): orphan cleanup on readonly fs

[ 3.348356] EXT4-fs (nvme0n1p5): mounted filesystem xxx ro with ordered data mode. Quota mode: none.

[ 6.567744] EXT4-fs (nvme0n1p5): re-mounted xxx \r/w.

[ 107.718062] EXT4-fs (nvme0n1p1): mounted filesystem xxx \r/w with ordered data mode. Quota mode: none.

[ 107.753424] EXT4-fs (nvme0n1p4): mounted filesystem xxx \r/w with ordered data mode. Quota mode: none.

[ 107.754346] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 32768

[ 107.755270] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 98304

[ 107.756196] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 163840

[ 107.757099] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 229376

[ 107.757509] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 294912

[ 107.757861] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 819200

[ 107.758069] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 884736

[ 107.758813] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 1605632

[ 107.759112] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 2654208

root@maketopsite:/home/maketopsite#

root@maketopsite:/home/maketopsite# dmesg | grep -Ei "nvme|I/O|error"

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-7.0.13-200.fc44.x86_64 root=/dev/nvme0n1p5

[ 0.003263] ACPI: SSDT 0x000000006DC11000 000CAD (v02 AMD NVME 00000001 INTL 20230331)

[ 0.024828] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-7.0.13-200.fc44.x86_64 root=/dev/nvme0n1p5

[ 0.069485] APIC: Switch to symmetric I/O mode setup

[ 0.584363] ACPI BIOS Error (bug): Could not resolve symbol [_TZ.THRM._SCP.CTYP], AE_NOT_FOUND (20251212/psargs-332)

[ 0.584400] ACPI Error: Aborting method _TZ.THRM._SCP due to previous error (AE_NOT_FOUND) (20251212/psparse-529)

[ 2.000868] RAS: Correctable Errors collector initialized.

[ 2.158783] systemd[1]: Expecting device dev-nvme0n1p5.device - /dev/nvme0n1p5...

[ 2.667940] nvme 0000:61:00.0: platform quirk: setting simple suspend

[ 2.668011] nvme nvme0: pci function 0000:61:00.0

[ 2.707683] nvme nvme0: allocated 64 MiB host memory buffer (1 segment).

[ 2.732287] nvme nvme0: 16/0/0 default/read/poll queues

[ 2.740040] nvme0n1: p1 p2 p3 p4 p5

[ 3.347868] EXT4-fs (nvme0n1p5): orphan cleanup on readonly fs

[ 3.348356] EXT4-fs (nvme0n1p5): mounted filesystem xxx ro with ordered data mode. Quota mode: none.

[ 6.567744] EXT4-fs (nvme0n1p5): re-mounted xxx \r/w.

[ 7.917665] nvme nvme0: using unchecked data buffer

[ 7.979221] block nvme0n1: No UUID available providing old NGUID

[ 107.718062] EXT4-fs (nvme0n1p1): mounted filesystem xxx \r/w with ordered data mode. Quota mode: none.

[ 107.753424] EXT4-fs (nvme0n1p4): mounted filesystem xxx \r/w with ordered data mode. Quota mode: none.

[ 107.754346] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 32768

[ 107.755270] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 98304

[ 107.756196] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 163840

[ 107.757099] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 229376

[ 107.757509] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 294912

[ 107.757861] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 819200

[ 107.758069] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 884736

[ 107.758813] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 1605632

[ 107.759112] EXT4-fs (nvme0n1p4): Invalid checksum for backup superblock 2654208

root@maketopsite:/home/maketopsite#

root@maketopsite:/home/maketopsite# e2fsck -f /dev/nvme0n1p4

e2fsck 1.47.3 (8-Jul-2025)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

data: 4149/9633792 files (0.4% non-contiguous), 1539158/38525696 blocks

root@maketopsite:/home/maketopsite#

root@maketopsite:/home/maketopsite# nvme smart-log /dev/nvme0

Smart Log for NVME device:nvme0 namespace-id:ffffffff

critical_warning : 0

temperature : 35 °C (308 K, 95 °F)

available_spare : 100%

available_spare_threshold : 5%

percentage_used : 1%

endurance group critical warning summary: 0

Data Units Read : 9112521 (4.67 TB)

Data Units Written : 14469779 (7.41 TB)

host_read_commands : 96113922

host_write_commands : 115570015

controller_busy_time : 3423

power_cycles : 750

power_on_hours : 4229

unsafe_shutdowns : 366

media_errors : 0

num_err_log_entries : 0

Warning Temperature Time : 0

Critical Composite Temperature Time : 0

Temperature Sensor 1 : 35 °C (308 K, 95 °F)

Thermal Management T1 Trans Count : 0

Thermal Management T2 Trans Count : 0

Thermal Management T1 Total Time : 0

Thermal Management T2 Total Time : 0

root@maketopsite:/home/maketopsite#

root@maketopsite:/home/maketopsite# dumpe2fs -h /dev/nvme0n1p4

dumpe2fs 1.47.3 (8-Jul-2025)

Filesystem volume name: data

Last mounted on: /mnt/nvme0n1p4

Filesystem UUID: xxx

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

Filesystem flags: signed_directory_hash

Default mount options: user_xattr acl

Filesystem state: clean

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 9633792

Block count: 38525696

Reserved block count: 1926283

Overhead clusters: 881983

Free blocks: 36986538

Free inodes: 9629643

First block: 0

Block size: 4096

Fragment size: 4096

Reserved GDT blocks: 1014

Blocks per group: 32768

Fragments per group: 32768

Inodes per group: 8192

Inode blocks per group: 512

Flex block group size: 16

Filesystem created: Fri Sep 5 16:26:07 2025

Last mount time: Fri Jun 26 06:23:17 2026

Last write time: Fri Jun 26 08:13:46 2026

Mount count: 0

Maximum mount count: -1

Last checked: Fri Jun 26 08:13:46 2026

Check interval: 0 (<none>)

Lifetime writes: 317 GB

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 256

Required extra isize: 32

Desired extra isize: 32

Journal inode: 8

Default directory hash: half_md4

Directory Hash Seed: xxx

Journal backup: inode blocks

Checksum type: crc32c

Checksum: 0x7bd6c79a

Journal features: journal_incompat_revoke journal_checksum_v3

Total journal size: 1024M

Total journal blocks: 262144

Max transaction length: 262144

Fast commit length: 0

Journal sequence: 0x00003d0e

Journal start: 0

Journal checksum type: crc32c

Journal checksum: 0x62beb1dc

root@maketopsite:/home/maketopsite#

Is this please a problem ?

Hello everyone, I created a simple firewall used by netfilter hooks and netlink sockets to communicate between the kernel and the user space. Please, can anyone check it and give me feedback on this project, and which part I can write better or which part write mistake. Repo

hello i was looking at the bugzilla and looking for beginner friendly tags there and couldn't find one. Apart from that I found a  bug which i am interested in solving but I don't know if it has been solved or assigned to someone else how do I figure that out?