Posts
529
Following
99
Followers
116
A relatively new professional kernel hacker, born in August 6, 2000, and living in Korea (South!).

- Linux Kernel Developer @ Oracle (Linux Kernel MM) (2025.02 ~ Present)
- Reviewer for the Linux Slab & Reverse Mapping subsystem
- Former Intern @ NVIDIA, SK Hynix, Panmnesia (Security, MM and CXL)
- B.Sc. in Computer Science & Engineering, Chungnam National University (Class of 2025)

Opinions are my own.

My interests are:
Memory Management,
Computer Architecture,
Circuit Design,
Virtualization

Harry (Hyeonggon) Yoo

Got a new small bookshelf but the user experience isn’t great
0
0
4
@conor @ljs @vbabka

Haha yeah, quite nice (watching my legs tremble)
1
0
2
@ljs @vbabka /me prepares to go out
0
0
2
@vbabka nah 5am gym sounds like @ljs !
1
0
4
@oleksandr didn’t refuse anything :’(
Perhaps should have refused a looong nap at night before 2am call
0
0
1
@vbabka just woke up from hibernation right now uh
1
0
1

Harry (Hyeonggon) Yoo

Oh god let me fall asleep
2
0
1
@sj recently started using drgn to add more DAMON selftests, which is a super interesting use case that I didn't envision: https://lore.kernel.org/all/20250628160428.53115-1-sj@kernel.org/. It has already found a real bug! https://lore.kernel.org/all/20250719181932.72944-1-sj@kernel.org/
0
3
6
@oleksandr @vbabka

SLAIB?

size = ai_prompt("Size sufficient to fit five integers");
gfp = ai_prompt("Appropriate GFP flags for the current context?");
array = kmalloc(size, gfp);
1
1
1

linux-stable is a vibe-backported frankenkernel

0
2
1

All microconferences (MCs) at LPC 2025 have been accepted! It is time to submit topics to your favorite MCs.

Please check out our latest blog post for the list of MCs, and how to create a ideal MC topic.

https://lpc.events/blog/current/index.php/2025/07/25/all-microconferences-have-been-accepted/

0
10
4

I've been playing with the LLM code assistants, trying to stress them out with the Linux kernel code. So far, I've had success with them writing reasonable unit tests:
https://lore.kernel.org/lkml/20250717085156.work.363-kees@kernel.org/
https://lore.kernel.org/lkml/20250724030233.work.486-kees@kernel.org/
These both saved me some time since it emitted quite a lot of good boundary testing code, but I had to massage them both a bit until I was happy with the coverage. But it was a net win on time spent.

And then I walked it through fixing a buffer overflow. This one didn't save me any time because I had to tell it how to look at the problem. Since it was a shorter/simpler session, I included my exact prompts just for anyone interested in what I did:
https://lore.kernel.org/lkml/20250724080756.work.741-kees@kernel.org/

4
3
3
@ljs Glad you could help her! Hopefully she’ll be fine….🙏
0
0
2
@ljs how can a human being can do that to their pets 😡
1
0
2
Edited 1 month ago

This graph is the one I'm most excited about: the lifetime of security flaws in Linux is finally starting to get shorter (and the number of fixed flaws continues to rise).

https://hachyderm.io/@LinuxSecSummit@social.kernel.org/114750428620118674

1
13
3

Harry (Hyeonggon) Yoo

Edited 24 days ago
@jmorris
Personally I use it to rephrase/proofread text or quickly look something up (as a first resort before grepping through git history or mailing list archive). I heard AUTOSEL uses LLMs to determine whether a patch should be backported to -stable or not.

But at this point, I really hope no one sends any code written or guided by AI to the mailing list. It might be fine to get shallow reviews of human-written code from LLMs, but I doubt they're capable of writing sane kernel code or offering deep reviews.
1
0
1
@ljs wise. that's what reclaim does to you!
0
0
2

Harry (Hyeonggon) Yoo

Edited 1 month ago
@ljs reviews are always appreciated :)
feeling bad to give you even more work to do :(
0
0
2

Harry (Hyeonggon) Yoo

Recently, I was debugging some intermittent boot failures and discovered that, on x86, forgetting to synchronize kernel page tables when installing new PGD entries can lead to kernel crashes.

Most of the time, PGD entries are populated during the boot process, and new tasks inherit page tables derived from the swapper process, so everything works fine.

However, if you're adding memory at runtime via memory hotplugging and populating new PGD entries for the vmemmap (i.e., the struct page array) and the direct mapping area, you need to iterate over all page tables in the system and update them accordingly to make it visible to all tasks.

Failing to handle this properly can lead to a situation where you think the page tables are set up correctly, but in reality, only init_mm.pgd (page table of the swapper process) was updated, not the page table of current task. This leads to kernel crashes since the PGD entry is not set up properly.

x86 code has mechanisms to handle this kind of synchronization, but it’s easy to be overlooked and introduce kernel crashes as the code evolves. Here’s my patch series that addresses the issue and aims to make it more robust: https://lore.kernel.org/linux-mm/20250709131657.5660-1-harry.yoo@oracle.com/
0
1
7
Show older