Posts
148
Following
30
Followers
69
Maintaining DAMON (https://damonitor.github.io). All opinions are my own.
Edited 2 days ago
0
2
6
repeated

@gregkh
> but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)

Not sure if this is what you want, but there is __attribute__((tainted_args)) since gcc 12.

1
1
1
repeated
This "untrusted data" patch series from Benno Lossin is the result of conversations at last weekend's Rust Linux kernel conference in Copenhagen:

https://lore.kernel.org/all/20240913112643.542914-1-benno.lossin@proton.me/

It's not a "silver bullet" for why we should be using rust in the Linux kernel, but it is a "big giant sledgehammer" to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, "all input is evil!" and this change forces you to always be aware of that, which is something that C in the kernel does not.)

I had always felt that Rust was the future for what we need to do in Linux, but now I'm sure, because if we can do stuff like this, with no overhead involved (it's all checked at build time), then we would be foolish not to give it a real try.

And yes, I've asked for this for years from the C developers, and maybe we can also do it there, but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)
5
114
153
Now I'm onboarding onto the next ship. So from now on, the views expressed herein do not reflect the views of their employers ;)
1
0
4
repeated

Jonathan Corbet

I have often complained that, even though thousands of developers are paid to work on the Linux kernel, there is not a single person whose job it is to write documentation for the kernel. The problem is wider than that, though: Alejandro Colomar, who has been maintaining the man pages collection for the last four years, can no longer afford to do it for free.

https://lwn.net/ml/all/4d7tq6a7febsoru3wjium4ekttuw2ouocv6jstdkthnacmzr6x@f2zfbe5hs7h5
5
88
67
@authentic_sammj Thank you, Sam! It's not easy for me to say whether it will be cool. You know me ;) But I will hopefully share the next news soon. Let's see.
1
0
1
Edited 12 days ago
Today was my last day at Amazon. So from now on, the views expressed herein are those of the speakers;
They _do_ reflect the views of their employers (myself), until another announcement ;)
3
0
5
A new squad member has arrived from Germany.
0
1
2
Very impressive CXL-based memory tiering performance of HMSDK is shared[1] with a cool video. It is the grateful result of a collaboration between DAMON community and SK hynix. It was never a one-side help, but a collaboration. DAMON also gained its ability to do tiered memory managements from the collaboration.

I'm grateful to be a part of the work. I was always impressed and learned many things from SK hynix' innovative ideas and constructive discussions. I'm looking forward to continued collaborations and next outputs!

[1] https://www.linkedin.com/posts/honggyukim_ai-hpc-cxl-activity-7236734372266000385-zYuk?utm_source=share&utm_medium=member_desktop

#linux #kernel #damon
0
1
1
repeated
Here's a link to the slides for my "Why are there so many kernel CVEs?" talk I gave at OSS China yesterday:
https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be

Link to git repo for the slides if the schedule site acts odd for you:
https://git.sr.ht/~gregkh/presentation-security

It was fun, and will be the "set up" for my Kernel Recipes talk in Paris in a few weeks (only 3 conferences to go between now and then, travel is back in full swing.)
5
28
39
repeated

Thorsten Leemhuis (acct. 1/4)

Registration for @linuxplumbersconf reopened

'"This year there was a huge demand to attend Conference in person and at last we were able to add more places and reopen the registration."'

https://lpc.events/blog/current/index.php/2024/08/16/registration-is-now-reopened/

1
6
3
GitHub repos for non-kernel parts of DAMON project including 'damo', 'damon-tests' and 'damoos' will be moved from 'awslabs' to 'damonitor', by 2024-09-05: https://lore.kernel.org/20240813232158.83903-1-sj@kernel.org

#linux #kernel #damon #damo #damon-tests #damoos
0
1
1
repeated

Building on the excellent codetag/alloc_tag infrastructure recently added to Linux, I've got an initial implementation of per-call-site kmalloc cache isolation:
https://lore.kernel.org/lkml/20240809072532.work.266-kees@kernel.org/

It's sure to give @vbabka nightmares and frustrate shared-cache use-after-free exploits. 😁

0
6
2
Edited 1 month ago
VLDB paper about Aurora Serverless V2, which reveals their usage of DAMON on the product, is now available: https://www.amazon.science/publications/resource-management-in-aurora-serverless

#linux #kernel #damon #aurora_serverless_v2
0
1
1
Edited 1 month ago
We are looking for DAMON recipes that I could share on upcoming OSSummit EU, or (hopefully) DAMON microconf at LPC'25: https://lore.kernel.org/20240724222119.58477-1-sj@kernel.org

#linux #kernel #damon #ossummit #linuxplumbers
0
1
1
Edited 1 month ago
Memory Management subsystem pull request for Linux v6.11-rc1 is posted[1] with DAMON changes for CXL memory tiering[2], documentation[3] of a mailing tool for newcomers (HacKerMaiL), and minor fixups.

[1] https://lore.kernel.org/20240721145415.fbeb01a853962ef91334f3d1@linux-foundation.org
[2] https://lore.kernel.org/20240614030010.751-1-honggyu.kim@sk.com
[3] https://lore.kernel.org/20240621163626.74815-1-sj@kernel.org

#linux #kernel #damon #hkml
1
1
1

@vbabka And, the fix[1] is pushed. I confirmed it works as below:

$ cat slab_pixel
11111 11
11 11 11
11 11111

11111111
      11
      11

11111111
11 11
11111111

11111111
11 11 11
 111111
$ ./pixels_to_access_config.py slab_pixel $((100* 1024*1024)) 250 slab.cfg
$ sudo ../damo/damo record "./masim ./slab.cfg"
$ sudo ../damo/damo report heatmap --output slab.png

[1] https://github.com/awslabs/damo/commit/7d6fd42371cc6a1611da72fde6076ca7b5ad1b37

0
0
1
@vbabka Thank you for clarifying. I think that should be the case that I explained. I'll update the heatmap plot target selection or do something else to make the reproduction smoother. The --address_range option should work as a workaround until the update is landed.
1
0
1
@vbabka Yet another workaround is using `damo report holistic` instead. It will plot the heatmap for three regions at once, like https://github.com/awslabs/damo/blob/v2.4.3/USAGE.md#holistic .
0
0
0
@vbabka I guess you were using `damo report heats --heatmap` or `damo report heatmap` for virtual address space accesses monitoring? If so, `--address_range` option might need to be used.

In detail, in case of virtual address spaces monitoring, there are two huge address gaps between stack, mmap()-ed regions, and heat. Hence drawing heatmap for entire mapped regions results in only black image. Hence `damo` finds up to three biggest contiguous adress ranges (for heap, stack, and mmap()-ed regions) in the record that consistently shown some accesses. Then, it plots heatmap for biggest region. In some cases, real accesses are made in mmap()-ed regions but heat area has larger mapped regions, so `damo` ends up plotting heatmap for the heat area that not really actively accessed. In the case, you show only black image. For this case, `damo report heatmap --guide` shows the three regions that `damo` found. You can find what address range you need to plot the heatmap, and set it using `--address_range` option.

We were planning to update the default plot target address range from biggest region to regions having most heats in near future, but it has not prioritized so far. Now it has an issue: https://github.com/awslabs/damo/issues/106

Please let me know if this is not the case.
2
0
0
Show older