Posts
148
Following
30
Followers
69
Maintaining DAMON (https://damonitor.github.io). All opinions are my own.
sj

sj

Edited 2 days ago
CONFIG_DAMON is enabled on Debian kernel! https://salsa.debian.org/kernel-team/linux/-/merge_requests/1172

#linux #kernel #damon
0
2
6
sj
repeated
uis@pone.social

uis

Reply to @gregkh

@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
sj
repeated
gregkh

Greg K-H

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
sj

sj

Reply to @sj
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
sj
repeated
corbet

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
sj

sj

Reply to @authentic_sammj@ozlabs.house
Edited 12 days ago
@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
sj

sj

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
sj

sj

A new squad member has arrived from Germany.
0
1
2
sj

sj

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
sj
repeated
gregkh

Greg K-H

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
sj
repeated
kernellogger@fosstodon.org

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
sj

sj

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
sj
repeated
kees@fosstodon.org

Kees Cook tux

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
sj

sj

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
sj

sj

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
sj

sj

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
sj

sj

Reply to @sj

@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
sj

sj

Reply to @vbabka
@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
sj

sj

Reply to @sj
@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
sj

sj

Reply to @vbabka
@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
About social.kernel.org

Terms of service

  1. Please do not use this service in violation of the Linux Kernel Code of Conduct. Doing so will result in your account suspension with the referral of the matter to the CoC committee.

  2. "Repeating"/"boosting" someone else's status on this platform will be treated as endorsement and will fall under rule #1.

  3. You are encouraged to use this platform to promote your work on the Linux Kernel, but there is no restriction on permitted topics (with the exception of anything covered by #1 above).

  4. There is no requirement to post in English, but it should be considered the primary language of communication on this platform.

Privacy notice

The admins of this service have access to all posted statuses. They aren't looking, but if it's something they shouldn't know about, then you should not post it on this platform.

Please see the Linux Foundation Privacy Policy, which applies to this platform as well.

Getting your own account

If you would like an account on this instance, please check that the following applies to you:

  • You are listed in MAINTAINERS or CREDITS

  • OR: You have a kernel.org account or email address

  • OR: You have a long and established history of involvement with the Linux Kernel

If the above is true and you agree with the Terms of Service and Privacy Notice listed above, please use these instructions to request an account: