Eric Snowberg submitted a new #Linux LSM as RFC: https://lore.kernel.org/all/20240311161111.3268190-1-eric.snowberg@oracle.com/
"'"Introduce a new LSM called Clavis (Latin word meaning key). The motivation behind this LSM is to provide access control for system keys. Before spending more time on this LSM, I am sending this as an RFC to start a discussion to see if the current direction taken has a possibility of being accepted in the future."'"
#kernel #LinuxKernel
@ba73f167
ha, nice hack, guess that will be a whole lot faster. 😬
For my use case something like that wasn't needed, as the lookup was fast enough for my needs. But to be honest I recently thought about going a similar route for some other problem (one my head already forgot about… 🥴)
@Hyeonggon Yoo
Haha, by brain hadn't made that connection yet (and had to to read "linux SRCU" two times before my brain saw the difference).
Side note: "linuxscru" didn't take much of a thought; if others show and interest in it it might be wise to consider a better name
@98025892
because the kernel on those might be build from the same source code, but the build configuration is totally different – hence a ton of features (ACPI might be among them) are missing in the second case
@a9106e75
Not sure if the license is the biggest problem, as quite a few bits for BPF progras are GPL exported as well: https://docs.kernel.org/bpf/bpf_licensing.html#using-bpf-programs-in-the-linux-kernel
I worry more about "we can work around a oddity or missing feature in the Linux kernel's C code using a BPF program, so why should we invest time and money to improve the C code?"
@a9106e75
Not sure if the license is the biggest problem, as quite a few bits for BPF progras are GPL exported as well: https://docs.kernel.org/bpf/bpf_licensing.html#using-bpf-programs-in-the-linux-kernel
I worry more about "we can work around a oddity or missing feature in the Linux kernel's C code using a BPF program, so why should we invest time and money to improve the C code?"
#Linux #kernel 6.6-rc4 is out: https://lore.kernel.org/lkml/CAHk-=wia2-4DRvD-aXz70AV64yrt+Vr50MxHiDunZ71dHATv-Q@mail.gmail.com/
"""You all know the drill by now. There's nothing particularly odd in here, […]
But everything else looks very much normal. The libata suspend/resume handling shows up due to it walking away from using the generic SCSI version that caused issues. Other than that, it's a random mix of fixes all over […]
Linus"""
auto-cpufreq 2.0 is out: https://github.com/AdnanHodzic/auto-cpufreq/releases/tag/v2.0.0
Wondering if this is or only looks like one of those tools that shouldn't exist, as the #Linux #kernel ideally should better be enhanced do the right thing automatically.
FWIW, from the README:
"""Why do I need auto-cpufreq? […] the CPU will run using "performance" governor with turbo boost enabled regardless if it's plugged in to power or not."""
Why is that a bad thing? Doing something quickly to then sleep quickly cat be the wisest move.
@Hyeonggon Yoo
getting regzbot involved is much appreciated, but don't worry, I can handle that, I do that all the time.
Good to see that a fix is getting closer to being fully formed & mainlined.
And thx for reporting!
2/ Above tooth is inspired by @ba73f167, who in https://lore.kernel.org/all/2023100159-tapered-fragment-7f9d@gregkh/ said the following about the #Linux #kernel's unified object model of all devices:
""" When Pat and I created it, we were young and naive and thought "this should be simple!" Famous last words... """
@4dbba09d
Congrats for getting further.
Too cynical? Well, I think this is nothing that should be dealt with on the distro level; the kernel should do "the right thing"™ by default
"[…] Instead of accepting my [#LinuxKernel] patch or guiding me towards a better solution, he went ahead and implemented his own fix, giving me credit only for reporting the issue […]
My first contribution to the [#Linux] #kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work. […]"
https://ariel-miculas.github.io/How-I-got-robbed-of-my-first-kernel-contribution/
1/ Side note: I sometimes wonder if…
2/…patches from new or rare contributors should have some kind of tag to indicate things like
(1) I have no interest in learning how to do things better, I just want it fixed; I'm thus happy if someone dramatically changes the patch or writes a better one.
(2) I'd really like to learn how to do this properly, hence would be grateful if someone could guide me somewhat.
Why? Well, misunderstandings here can be annoying and a waste of time for both sides (and lead to situations like the above).
#Linux #kernel developer Mel Gorman on the #BPF extensible scheduler class" from Tejun and other Meta devs:
"""I view pluggable scheduler as something that would be a future maintenance nightmare […]
I generally worry that certain things may not have existed in the shipped scheduler if plugging was an option including EAS, throttling control, schedutil integration, big.Little, adapting to chiplets and picking preferred SMT siblings for turbo boost. […]"""
https://lore.kernel.org/all/20230926092020.3alsvg6vwnc4g3td@suse.de/ #LinuxKernel
@4dbba09d
good luck (you at least seem to have data for analysing – I just had a black screen :-/ );
I meanwhile made it to the end now and found the culprit (see reply to the initial tweet for details)
@2b4c2608
I remember it to be obfuscated as well, but haven't take a look in years; maybe somebody cleaned things up and the debian devs didn't notice? Or the obfuscation is only found in headers or something?
#argh: I have to perform a #Linux #kernel bisection on my Thinkpad T14s G1 (AMD) with Fedora's full-blown distro config, as the problem does not occur with a config trimmed by localmodconfig. 😟
[1] resume broke with #LinuxKernel 6.6-rc
https://www.kerno.io/blog/programming-the-kernel-with-ebpf
"""In this issue, we’ll explore eBPF (Extended Berkeley Packet Filter), […]
TLDR
eBPF is a mechanism that makes the [#Linux] #kernel dynamically programmable without modifying the source code.
eBPF is safe, fast, incredibly flexible, and extensible.
eBPF has been running in production for over half a decade at internet scale on millions of servers.
eBPF use cases range from observability, networking, security, tracing, and profiling.""" #LinuxKernel
#bcachefs won't make it into #Linux #kernel 6.6, but is not far off. For details see Linus replies starting here:
https://lore.kernel.org/all/CAHk-=wjUX287gJCKDXUY02Wpot1n0VkjQk-PmDOmrsrEfwPfPg@mail.gmail.com/t/#u
"""I suspect any further changes are better done in-tree. The out-of-tree thing has been done.
[…] issues that I have with this, and Christoph did mention a big one: it's not been in linux-next.
So these kinds of "I'll just ignore _all_ basic rules" kinds of issues do annoy me.
[…] if you actually want this
upstream, you need to work with upstream […]"""
Note the replies-to-self from Linus, like https://lore.kernel.org/all/CAHk-=whaiVhuO7W1tb8Yb-CuUHWn7bBnJ3bM7bvcQiEQwv_WrQ@mail.gmail.com/t/#u
""""Oh, and the fact that it hasn't been in linux-next became immediately clear, and it's a real practical problem.
I get a compile error when just doing a basic built-test: […]
and that compile error is actually a sign of a pretty serious bug.
BTREE_NODE_UNLOCKED is of the wrong enum type, and has a value (-1) that simply cannot be represented in a 'enum six_lock_type'."""
@Conor Dooley
Of course it's silly and over complication. But at the same it makes something explicit that in an ideal world might be wise for everyone to make explicit, as people will forget to spell it out (and maintainers will forget to ask which of the two it is).
Oddbean new post about login | logout
Notes by Thorsten Leemhuis (1/4) | export
#btrfs-progs 6.5.2 is out an brings support for some features slated for #Linux #kernel 6.7: """ raid-stripe-tree, new tree to track extent mapping for raid profiles, allows raid1*, raid0 and raid10 on zoned devices (kernel 6.7) simple quotas, simplified accounting that does not track exclusive and shared extents (kernel 6.7) mkfs with duplicate UUID on a single device, temp-fsid (kernel 6.7) """ https://github.com/kdave/btrfs-progs/releases/tag/v6.5.2 #LinuxKernel https://cdn.fosstodon.org/media_attachments/files/111/174/877/383/785/730/original/ababb308ff9cfbe9.png2/ And the winner of this bisection is: 92e24e0e57f72e ("Input: psmouse - add delay when deactivating for SMBus mode") [merged for v6.6-rc1] Report: https://lore.kernel.org/all/ca0109fa-c64b-43c1-a651-75b294d750a1@leemhuis.info/