The 6.15 kernel has been released
So this was delayed by a couple of hours because of a last-minute bug report resulting in one new feature being disabled at the eleventh hour, but 6.15 is out there now.
Significant changes in 6.15 include smarter timer-ID assignment to make checkpoint/restore operations more reliable, the ability to read status information from a pidfd after the process in question has been reaped, the PIDFD_SELF special pidfd value, nested ID-mapped mounts, zero-copy network-data reception via io_uring, The ability to read epoll events via io_uring, resilient queued spinlocks for BPF programs, guard-page enhancements allowing them to be placed in file-backed memory areas and for user space to detect their presence, the once-controversial fwctl subsystem, the optional sealing of some system mappings, and much more.
See the LWN merge-window summaries (part 1, part 2) and the in-progress KernelNewbies 6.15 page for
more information.
Posted May 26, 2025 7:43 UTC (Mon)
by jmalcolm (subscriber, #8876)
[Link] (10 responses)
Also nice to see support for the Apple T2 chip as I have a couple of devices with that in them.
Posted May 26, 2025 10:46 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (7 responses)
Posted May 27, 2025 12:50 UTC (Tue)
by parametricpoly (subscriber, #143903)
[Link] (6 responses)
Posted May 27, 2025 13:46 UTC (Tue)
by pizza (subscriber, #46)
[Link] (5 responses)
I'm dealing with a spec right now that *mandates* that it (and implementations) be kept confidential.
because $reasons
Posted May 27, 2025 15:51 UTC (Tue)
by hmh (subscriber, #3838)
[Link] (4 responses)
Posted May 27, 2025 22:07 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
1. We have a radio, so we must comply with FCC (or local equivalent) regulations.
As a non-lawyer, I'm not well positioned to assess whether that is a valid legal concern (there are at least ~200 jurisdictions in the world that might plausibly have different answers to that question). But in an ideal regime, (4) would look more like the following:
4. Therefore, we must clearly warn users that tampering with the radio may cause them to violate the rules, and get them to agree that we will not be held responsible for any violation of the rules caused by the user's modifications, even if our software or firmware contributed to the violation in some way.
Posted May 28, 2025 7:04 UTC (Wed)
by johill (subscriber, #25196)
[Link]
It's not necessarily the biggest concern to prevent users from _intentionally_ doing such things on their individual devices assuming it would be difficult and/or obvious enough. You must, at least to some extent, also prevent said device users from being harmed by e.g. random exploit code running on their machines, and prevent anyone from being able to break things at scale. Understandably, the FCC cares less about a single user finding a way around limitations than a "script kiddie" breaking the regulations on millions of machines in some automated fashion, possibly even harming users in the process or even with the intent of doing so.
Taking this argument face value, I'd think that at that point you basically end up needing some kind of obvious switch like ChromeOS laptops have for their developer mode, but that's clearly not feasible for a random embedded radio (say WiFi or 5G modem.) I suppose it _might_ be doable for certain classes of expensive devices, but I'd think the extra development effort never pays off.
Posted May 28, 2025 8:47 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
However, historically the FCC took the position that unless a modification that breached the rules needed significant enough skill with a soldering iron that you could have built an equivalent device yourself (e.g. adding a transistor to the RF path or replacing a soldered down IC), they'd change the rules to retroactively prohibit any devices that were being modified to breach the rules. There's still remnants of this in the rules today; for example, 47 CFR 97.317 is intended to make it very hard to sell an amateur amplifier for 10m that can be easily modified for use with CB.
Posted May 27, 2025 23:11 UTC (Tue)
by pizza (subscriber, #46)
[Link]
Neither; it's the old standby of a combination of "security" and "if we allow modifications we potentially become [strictly] liable under numerous federal laws"
Posted May 26, 2025 10:47 UTC (Mon)
by kragil (guest, #34373)
[Link] (1 responses)
Posted May 26, 2025 16:08 UTC (Mon)
by koverstreet (✭ supporter ✭, #4296)
[Link]
People forget that filesystems are massive projects, these things do take awhile.
But it's been steadily coming along.
Posted May 26, 2025 10:16 UTC (Mon)
by arekm (guest, #4846)
[Link]
but
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linu...
helped.
There is also failure:
linux-6.15/drivers/scsi/qedf/qedf_main.c:702:9: error: positional initialization of field in ‘struct’ declared with ‘designated_init’ attribute [-Werror=designated-init]
Posted May 26, 2025 10:39 UTC (Mon)
by alspnost (guest, #2763)
[Link] (7 responses)
Posted May 26, 2025 12:37 UTC (Mon)
by pwfxq (subscriber, #84695)
[Link] (1 responses)
Posted May 27, 2025 11:44 UTC (Tue)
by khim (subscriber, #9252)
[Link]
I think it's more of change in breadth rather than change in depth. “Add quirk for Lenovo Yoga Pro 7 14ASP10” is still perfectly understandable description line… but chances are that you wouldn't care about it because you don't have Lenovo Yoga Pro 7 14ASP10! In an era where Linux supported half-dozen of different configurations chances that any particular change would be relevant for your were much higher.
Posted May 26, 2025 19:39 UTC (Mon)
by coriordan (guest, #7544)
[Link] (1 responses)
I still take a look at kernel release notes sometimes, because I think I should keep a little bit up-to-date with what's happening in there, and I'm expecting to understand something, but I don't.
Posted May 27, 2025 3:40 UTC (Tue)
by magfr (subscriber, #16052)
[Link]
Posted May 27, 2025 0:28 UTC (Tue)
by motk (guest, #51120)
[Link]
Posted May 28, 2025 18:34 UTC (Wed)
by geofft (subscriber, #59789)
[Link] (1 responses)
In the longer term, I guess you could imagine a version of top/ps/kill/etc. that operates on pidfds somehow, though I guess a question is where to store those pidfds if all of these are themselves independent processes is a question. (Will we see some limited REPL for interacting with processes, where the "top" subcommand holds onto pidfds, and the "kill" subcommand uses them?)
Guard pages for file mappings probably also won't show up at the shell level of abstraction, but being able to reliably catch small out-of-bounds reads of mmapped files seems cool and very visible at the C programming level of abstraction.
Nested idmapped mounts will be useful as soon as container managers start using them, in the sense that you'll be able to run a container manager using this feature in a container using this feature. It'll be visible in the sense that it's one fewer feature that will inexplicably fail in a nested-container setup. (Though I suppose there's a bunch of steps to get there like nested subuids, which is not necessarily a kernel thing so much as allocating a sufficient range to be able to nest inside it.)
Kernel-enforced FUSE timeouts seem incredibly useful for the subset of sysadmins who have to deal with complex FUSE applications, so much so that I paused writing this comment last night to go email a colleague about it. Many people probably won't notice, though.
I'm personally intrigued by the Apple Touch Bar support as the owner of a laptop with one of those, but I guess that too is a shrinking class of users. (That said, I'm not actually sure if I want to put Linux directly on my MacBook; everything I need to do professionally I can do in a VM, and the older I get, the less I want to sysadmin my personal machine non-professionally and the more I'm willing to trade off freedom and functionality for risk management.)
Posted Jun 8, 2025 19:24 UTC (Sun)
by jtepe (subscriber, #145026)
[Link]
Scrub for bcachefs
Scrub for bcachefs
Scrub for bcachefs
Scrub for bcachefs
Scrub for bcachefs
Scrub for bcachefs
2. The FCC (or local equivalent) says that our radio must do X or must not do Y.
3. It is physically possible for our radio to violate those rules.
4. Therefore, we must prevent users from doing anything with our radio unless we're sure it would comply with the rules.
Scrub for bcachefs
For the US specifically, under the current rules, most radio transmitters will only be restricted by 47 CFR 15.12, which does match your version of 4, with the exception of U-NII devices, which have extra restrictions in 47 CFR 15.407(i).
Scrub for bcachefs
Scrub for bcachefs
Scrub for bcachefs
Scrub for bcachefs
internal compiler error
1745 | .u.op = &(struct lsm_ioctlop_audit) {
702 | {
| ^
linux-6.15/drivers/scsi/qedf/qedf_main.c:702:9: note: (near initialization for ‘qedf_cb_ops’)
It's funny - in the old days, I could just about understand new kernel features and why they were cool and exciting, with each release. Nowadays, not a clue what any of this stuff means. In probably 27 years of following Linux, I suppose all the 'obvious' things have been done/re-done/re-done again, and we're now into the era of esoteric enhancements that are obviously good, but beyond the comprehension of ordinary sysadmin/infrastructure mortals like me!
Bamboozled
Bamboozled
Bamboozled
Bamboozled
Bamboozled
There's also perf. I think it can be massively useful if I only could manage to wrap my head around it.
Bamboozled
Bamboozled
Bamboozled