CINXE.COM
LWN.net comments
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel> <title>LWN.net comments</title> <link>https://lwn.net/Comments/</link> <description>This feed contains the text of all comments posted to the LWN.net site. </description> <language>en-us</language> <pubDate>Mon, 07 Apr 2025 12:07:15 +0000</pubDate> <lastBuildDate>Mon, 07 Apr 2025 12:07:15 +0000</lastBuildDate> <docs>https://www.rssboard.org/rss-specification</docs> <webMaster>lwn@lwn.net</webMaster> <atom:link href="https://lwn.net/headlines/Comments" rel="self" type="application/rss+xml"/> <item> <title>Is this an IPv6 problem?</title> <link>https://lwn.net/Articles/1016601/</link> <guid>https://lwn.net/Articles/1016601/</guid> <dc:creator>daroc</dc:creator> <description><div class="FormattedComment"> In this case I think the code was just peeking at the next header, yes. But modern BPF does allow pointer chasing — the trick is that any loop must be verifiably bounded. Depending on the exact way you write the loop this is done in different ways. Options include: having a bounded maximum number of iterations, or using the may_goto instruction to allow the BPF runtime to terminate a loop early if it wants to.<br> </div> </description> <pubDate>Mon, 07 Apr 2025 12:06:38 +0000</pubDate> </item> <item> <title>Annotation placement</title> <link>https://lwn.net/Articles/1016600/</link> <guid>https://lwn.net/Articles/1016600/</guid> <dc:creator>daroc</dc:creator> <description><div class="FormattedComment"> Sorry for the confusion — I meant that when you have a pointer that is itself const (const pointer to int in C), the "const" type annotation comes before the pointer in the BTF layout of the type. But when you have a kernel pointer (i.e. a pointer that is marked as pointing into the kernel instead of the BPF program's memory by __kptr), the type annotation comes after the pointer in the BTF layout of the type.<br> <p> So Marchesi's point is that this is inconsistent.<br> </div> </description> <pubDate>Mon, 07 Apr 2025 12:03:27 +0000</pubDate> </item> <item> <title>What is being mmap()’d?</title> <link>https://lwn.net/Articles/1016599/</link> <guid>https://lwn.net/Articles/1016599/</guid> <dc:creator>andresfreund</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt; &gt;writable file maps are such a bad way to do I/O that people have written white papers about how much it sucks.</span><br> <p> <span class="QuotedText">&gt; Could you please elaborate on this? Just to clarify, you're referring to mmap'ing a regular file and writing to that address space?</span><br> <p> I assume it's a reference to papers like <a href="https://db.cs.cmu.edu/papers/2022/cidr2022-p13-crotty.pdf">https://db.cs.cmu.edu/papers/2022/cidr2022-p13-crotty.pdf</a><br> </div> </description> <pubDate>Mon, 07 Apr 2025 11:55:58 +0000</pubDate> </item> <item> <title>What is being mmap()’d?</title> <link>https://lwn.net/Articles/1016597/</link> <guid>https://lwn.net/Articles/1016597/</guid> <dc:creator>darmengod</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt;writable file maps are such a bad way to do I/O that people have written white papers about how much it sucks.</span><br> <p> Could you please elaborate on this? Just to clarify, you're referring to mmap'ing a regular file and writing to that address space?<br> </div> </description> <pubDate>Mon, 07 Apr 2025 07:49:08 +0000</pubDate> </item> <item> <title>Is SCSI dead?</title> <link>https://lwn.net/Articles/1016595/</link> <guid>https://lwn.net/Articles/1016595/</guid> <dc:creator>cladisch</dc:creator> <description><div class="FormattedComment"> All other storage standards (ATAPI, SATA, SAS, USB MSC) are just mechanisms to move SCSI commands.<br> </div> </description> <pubDate>Mon, 07 Apr 2025 04:30:56 +0000</pubDate> </item> <item> <title>Data collection?</title> <link>https://lwn.net/Articles/1016573/</link> <guid>https://lwn.net/Articles/1016573/</guid> <dc:creator>Flameeyes</dc:creator> <description><div class="FormattedComment"> He's definitely… a personality.<br> <p> I used to package Calibre for Gentoo (from before it even had that name, it was libprs500 — named after the Sony Reader eInk devices), and even provided patches a couple of times… but never really managed to build even a slight bit of relationship.<br> <p> </div> </description> <pubDate>Sun, 06 Apr 2025 19:58:07 +0000</pubDate> </item> <item> <title>Is SCSI dead?</title> <link>https://lwn.net/Articles/1016572/</link> <guid>https://lwn.net/Articles/1016572/</guid> <dc:creator>DemiMarie</dc:creator> <description><div class="FormattedComment"> USB Attached SCSI and Universal Flash Storage use SCSI, but I’m unsure what the advantage of using SCSI in these fields is.<br> </div> </description> <pubDate>Sun, 06 Apr 2025 19:49:10 +0000</pubDate> </item> <item> <title>Why offload to SSD?</title> <link>https://lwn.net/Articles/1016571/</link> <guid>https://lwn.net/Articles/1016571/</guid> <dc:creator>DemiMarie</dc:creator> <description><div class="FormattedComment"> Why is this such a huge performance win? Reducing round-trips?<br> </div> </description> <pubDate>Sun, 06 Apr 2025 19:37:54 +0000</pubDate> </item> <item> <title>ASI vs ASR</title> <link>https://lwn.net/Articles/1016565/</link> <guid>https://lwn.net/Articles/1016565/</guid> <dc:creator>naesten</dc:creator> <description><p>Not totally: with ASLR, pages mapped from insensitive files become sensitive if they have dynamic relocations applied to them; without ASLR, maybe they (conceptually) don't. <p>In practice, I assume that the copy-on-write triggered by ld.so's first write to such a page would mark the private copy as sensitive, and I guess the safest way to counter that is using a tool like <a href="https://manpages.debian.org/unstable/prelink/prelink.8.en.html">prelink(8)</a> to prevent the page getting modified (unless there's an address conflict)? That way, it still gets marked sensitive if it's not what most other processes see. <p>(All of this is assuming some kind of "insensitive file" support exists, of course.) </description> <pubDate>Sun, 06 Apr 2025 18:05:51 +0000</pubDate> </item> <item> <title>What is being mmap()’d?</title> <link>https://lwn.net/Articles/1016566/</link> <guid>https://lwn.net/Articles/1016566/</guid> <dc:creator>willy</dc:creator> <description><div class="FormattedComment"> Userspace is mmap()ing the file. Then it's transferring ownership of the memory to the GPU. This is why we only need read support, because writable file maps are such a bad way to do I/O that people have written white papers about how much it sucks.<br> <p> I have no idea why they want to do it this way rather than allocate anonymous memory and use async I/O as you suggested. Maybe it's just that programmer time is expensive and they don't care about getting the last 5% of performance?<br> </div> </description> <pubDate>Sun, 06 Apr 2025 17:30:56 +0000</pubDate> </item> <item> <title>Do we have any documentation on the semantics of RWF_ATOMIC?</title> <link>https://lwn.net/Articles/1016567/</link> <guid>https://lwn.net/Articles/1016567/</guid> <dc:creator>koverstreet</dc:creator> <description><div class="FormattedComment"> I've been thinking in particular about what happens when one RWF_ATOMIC write partially overwrites another - and something better than "don't do that".<br> </div> </description> <pubDate>Sun, 06 Apr 2025 17:29:30 +0000</pubDate> </item> <item> <title>Why use file-backed pages?</title> <link>https://lwn.net/Articles/1016564/</link> <guid>https://lwn.net/Articles/1016564/</guid> <dc:creator>DemiMarie</dc:creator> <description><div class="FormattedComment"> Would O_DIRECT + io_uring + manual data movement in userspace be faster, or am I missing something?<br> </div> </description> <pubDate>Sun, 06 Apr 2025 17:20:29 +0000</pubDate> </item> <item> <title>What is being mmap()’d?</title> <link>https://lwn.net/Articles/1016563/</link> <guid>https://lwn.net/Articles/1016563/</guid> <dc:creator>DemiMarie</dc:creator> <description><div class="FormattedComment"> Is userspace mmap()’ing the device’s memory, or are they mmap()’ing the file on disk? The first makes sense, but not the second.<br> </div> </description> <pubDate>Sun, 06 Apr 2025 17:18:19 +0000</pubDate> </item> <item> <title>Is it self-hostable?</title> <link>https://lwn.net/Articles/1016561/</link> <guid>https://lwn.net/Articles/1016561/</guid> <dc:creator>jzb</dc:creator> <description><div class="FormattedComment"> Ryan's post says that they are building the service using the Stalwart mail server. The core of that is open source, though it has non-open features. <br> </div> </description> <pubDate>Sun, 06 Apr 2025 17:13:22 +0000</pubDate> </item> <item> <title>Map from kernel space</title> <link>https://lwn.net/Articles/1016560/</link> <guid>https://lwn.net/Articles/1016560/</guid> <dc:creator>pbonzini</dc:creator> <description><div class="FormattedComment"> The processor prevents accesses from both kernel and user space. Because violations can be reported a bit "violently" (machine checks) guest_memfd prevents mapping from user space, whereas the kernel looks after itself and avoids accesses.<br> </div> </description> <pubDate>Sun, 06 Apr 2025 14:37:52 +0000</pubDate> </item> <item> <title>Map from kernel space</title> <link>https://lwn.net/Articles/1016558/</link> <guid>https://lwn.net/Articles/1016558/</guid> <dc:creator>ju3Ceemi</dc:creator> <description><div class="FormattedComment"> The post tells several times that this feature prevents page mapping from the host user space, which is nice<br> <p> Does it also prevent such maps from the host kernel space ?<br> If not, would not this feature kind of useless (as the cloud provider can run whatever kernel he wants)<br> </div> </description> <pubDate>Sun, 06 Apr 2025 13:57:02 +0000</pubDate> </item> <item> <title>Why use file-backed pages?</title> <link>https://lwn.net/Articles/1016555/</link> <guid>https://lwn.net/Articles/1016555/</guid> <dc:creator>aviallon</dc:creator> <description><div class="FormattedComment"> If the device can somehow receive data from the storage device directly by P2PDMA, then it is much better and faster.<br> </div> </description> <pubDate>Sun, 06 Apr 2025 08:08:16 +0000</pubDate> </item> <item> <title>Is it self-hostable?</title> <link>https://lwn.net/Articles/1016554/</link> <guid>https://lwn.net/Articles/1016554/</guid> <dc:creator>tilt12345678</dc:creator> <description><div class="FormattedComment"> If not, what are the advantages over existing, established offerings?<br> </div> </description> <pubDate>Sun, 06 Apr 2025 07:45:04 +0000</pubDate> </item> <item> <title>Why use file-backed pages?</title> <link>https://lwn.net/Articles/1016551/</link> <guid>https://lwn.net/Articles/1016551/</guid> <dc:creator>DemiMarie</dc:creator> <description><div class="FormattedComment"> Device page faults are very expensive because you are stalling the device until the CPU can resolve the fault. That makes me very surprised that they are the right choice for such a high-performance application. Isn’t explicit async I/O from userspace faster?<br> </div> </description> <pubDate>Sat, 05 Apr 2025 22:59:50 +0000</pubDate> </item> <item> <title>Isn't this a language problem?</title> <link>https://lwn.net/Articles/1016550/</link> <guid>https://lwn.net/Articles/1016550/</guid> <dc:creator>ABCD</dc:creator> <description><p>GCC (but apparently not Clang) does have an attribute that might be useful here; unfortunately, it is applied to the function as a whole, not a particular parameter (although it does reference a specific parameter, and can be applied multiple times for multiple parameters). For the function in question, it would probably look something like:</p> <p><pre> static __always_inline int ipv6_hdrlen_offset(__u8 *nexthdr) __attribute__((access(read_only, 1))) { /* ... */ } </pre></p> <p>For further information, see the GCC documentation for <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute">the <tt>access</tt> attribute</a>.</p> </description> <pubDate>Sat, 05 Apr 2025 16:51:00 +0000</pubDate> </item> <item> <title>Shared libraries can, and probably will, happen</title> <link>https://lwn.net/Articles/1016548/</link> <guid>https://lwn.net/Articles/1016548/</guid> <dc:creator>dvdeug</dc:creator> <description><div class="FormattedComment"> Then stop writing code in C. This isn't really an arguable case; memcpy doesn't work on overlapping memory, and memmove does. If you don't care about the speed improvment, use memmove. Unlike some of the other issues, like integer overflow, this is explicit and universal.<br> <p> If you want to know if your program works on NetBSD for the Nintendo Wii, no amount of testing on Linux/AMD64 will provide the answer. Different CPUs work differently, and different OSes provide different libcs and support different features.<br> <p> A VM like the JVM or .Net can mask some of the problem. Even better, write it for the SNES or Commodore 64, or some other monoculture system with tightly timed emulators. But real world systems, especially under a language like C, aren't going to be so nice as to be testable one place and run anywhere.<br> <p> </div> </description> <pubDate>Sat, 05 Apr 2025 16:34:15 +0000</pubDate> </item> <item> <title>Trivial for static code analysis</title> <link>https://lwn.net/Articles/1016545/</link> <guid>https://lwn.net/Articles/1016545/</guid> <dc:creator>ballombe</dc:creator> <description><div class="FormattedComment"> They serve a different purpose. The BPF verifier checks that the program is harmless, the static checker checks that it has no obvious bugs.<br> </div> </description> <pubDate>Sat, 05 Apr 2025 11:15:37 +0000</pubDate> </item> <item> <title>Isn't this a language problem?</title> <link>https://lwn.net/Articles/1016544/</link> <guid>https://lwn.net/Articles/1016544/</guid> <dc:creator>dottedmag</dc:creator> <description><div class="FormattedComment"> Or nag the people working on C standard to strike another item off the "undefined behaviour" list, so that demons stop flying off one's nose in this particular case. Fortunately, this is is a work being done already.<br> </div> </description> <pubDate>Sat, 05 Apr 2025 09:42:55 +0000</pubDate> </item> <item> <title>Calendar and Contacts otherwise known as caldav and carddav</title> <link>https://lwn.net/Articles/1016543/</link> <guid>https://lwn.net/Articles/1016543/</guid> <dc:creator>johnjones</dc:creator> <description><div class="FormattedComment"> what is lacking is how they plan to version and sync the calendar and contacts <br> <p> yeah a calendar for invites is very sexy and all but not he same as a caldav server <br> <p> they need to at least offer a calendar and contacts web interface and server <br> <p> <p> </div> </description> <pubDate>Sat, 05 Apr 2025 05:52:16 +0000</pubDate> </item> <item> <title>Not just hand out the old articles</title> <link>https://lwn.net/Articles/1016541/</link> <guid>https://lwn.net/Articles/1016541/</guid> <dc:creator>yodermk</dc:creator> <description><div class="FormattedComment"> I like that idea a lot.<br> <p> One issue might be search engines, but I suppose the main engines publish a list of their indexer IP ranges, and if a request is from one of them, you just include the links.<br> </div> </description> <pubDate>Sat, 05 Apr 2025 04:15:31 +0000</pubDate> </item> <item> <title>Is this an IPv6 problem?</title> <link>https://lwn.net/Articles/1016538/</link> <guid>https://lwn.net/Articles/1016538/</guid> <dc:creator>buck</dc:creator> <description><div class="FormattedComment"> Perhaps a wee bit off-topic, but successful compilation resulting in dropping IPv6 packets would arguably be expected behavior here<br> <p> <a href="https://www.rfc-editor.org/rfc/rfc9098.html#name-introduction">https://www.rfc-editor.org/rfc/rfc9098.html#name-introduc...</a><br> <p> On a slightly more serious note, if this code is just peeking at the next header, then, OK, but, in general, can one chase nexthdrs and still have the BPF verifier accept the code? I thought it was somehow responsible for verifying the code is guaranteed to terminate (without solving the halting problem)<br> </div> </description> <pubDate>Sat, 05 Apr 2025 03:22:08 +0000</pubDate> </item> <item> <title>Trivial for static code analysis</title> <link>https://lwn.net/Articles/1016539/</link> <guid>https://lwn.net/Articles/1016539/</guid> <dc:creator>intelfx</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt; Almost any tool for static [offline] code analysis will detect the error in the exhibited code that deals with nexthdr. In many cases, running a BPF code requires privileges. The administrator of the privileges can establish a requirement for a satisfactory report from a static analysis tool, perhaps authenticated using cryptography or sourced from within a restricted area of a filesystem. It is too much to expect BPF to do everything dynamically [online]. </span><br> <p> If this mechanism existed, there would have been no need for BPF in the first place. Why bother with BPF at all, with its verifier and all its idiosyncrasies, if it were possible, feasible, and acceptable to "just" require an unforgeable report about the safety of a given program?<br> </div> </description> <pubDate>Sat, 05 Apr 2025 03:06:11 +0000</pubDate> </item> <item> <title>Trivial for static code analysis</title> <link>https://lwn.net/Articles/1016537/</link> <guid>https://lwn.net/Articles/1016537/</guid> <dc:creator>jreiser</dc:creator> <description>Almost any tool for static [offline] code analysis will detect the error in the exhibited code that deals with <tt>nexthdr</tt>. In many cases, running a BPF code requires privileges. The administrator of the privileges can establish a requirement for a satisfactory report from a static analysis tool, perhaps authenticated using cryptography or sourced from within a restricted area of a filesystem. It is too much to expect BPF to do everything dynamically [online]. </description> <pubDate>Sat, 05 Apr 2025 02:32:13 +0000</pubDate> </item> <item> <title>Yeah, 100x this...</title> <link>https://lwn.net/Articles/1016535/</link> <guid>https://lwn.net/Articles/1016535/</guid> <dc:creator>mirabilos</dc:creator> <description><div class="FormattedComment"> Oh, yes, same.<br> <p> And CVS upstreams cannot be expressed as URLs; CVS modules are defined by *two* paths.<br> </div> </description> <pubDate>Sat, 05 Apr 2025 00:44:46 +0000</pubDate> </item> <item> <title>Thunderbird's Quality</title> <link>https://lwn.net/Articles/1016533/</link> <guid>https://lwn.net/Articles/1016533/</guid> <dc:creator>PastyAndroid</dc:creator> <description><div class="FormattedComment"> I've bounced between most of the 'big' email clients available for GNU/Linux. I used seamonkey/thunderbird for a number of years on GNOME 2, they were good but even then had odd bugs. After GNOME 3 hit and I had to migrate to XFCE, I also used the time to switch to claws and in fairness, claws was good and worked very well. I do wonder how much it has changed since then, but I do remember it "just works" (or did at that time.).<br> <p> I also used gnome's evolution for a while (on XFCE), it was actually a really good solution for when you want all the features built in, such as contact sync, calender sync, etc. I continued to use that after claws right up until I switched to KDE around 2022 or so, since I didn't really encounter any significant bugs.<br> <p> I didn't want the gnome dependencies within my KDE setup so I switched over to Kmail which seemed like the natural replacement. It worked mostly, but it also had peculiar issues where it would lose the synced contacts / events and sometimes even emails themselves if you use filters or move mail between folders (the emails were simply gone, no longer on the server nor stored locally.).<br> <p> I tried out thunderbird again... and.. I basically noped out of that.<br> <p> I eventually got fed up of dealing with all the GUI clients and their oddities along with all the other syncing. I decided to try out mutt/neomutt. Granted, it has nowhere near as many fancy features but it does "just work" and as yet it hasn't failed to do anything I told it to do or lost anything.<br> <p> It just brings peace of mind and a lot less frustration. :-)<br> <p> Or maybe I'm just getting too old for that software, lol.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 23:49:24 +0000</pubDate> </item> <item> <title>Isn't this a language problem?</title> <link>https://lwn.net/Articles/1016534/</link> <guid>https://lwn.net/Articles/1016534/</guid> <dc:creator>cesarb</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt; Isn't this fundamentally a (classic) weakness in the C language, that there's no way to distinguish a pointer to an uninitialized value that you need to write to first and a pointer to an initialized value that is okay to read from?</span><br> <p> Some Microsoft library headers use annotations like __in or __out to specify whether a pointer is supposed to be an input or an output for a function call, probably borrowed from IDL. I don't know whether gcc or clang have an equivalent __attribute__ which could be used to implement these annotations.<br> <p> In the example on this article, if the nexthdr argument of ipv6_hdrlen_offset were annotated as __in, the compiler could know that passing it a pointer to an uninitialized value is a mistake, allowing it to output a warning on the call in icmp6_ndisc_validate; if, on the other hand, the nexthdr argument of ipv6_hdrlen_offset were annotated as __out, the compiler could generate a warning when that function tries to read from that argument. Either way, it would be easier to see that something is wrong with the code.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 23:23:14 +0000</pubDate> </item> <item> <title>Seem like a reasonable move</title> <link>https://lwn.net/Articles/1016532/</link> <guid>https://lwn.net/Articles/1016532/</guid> <dc:creator>PastyAndroid</dc:creator> <description><div class="FormattedComment"> For personal usage, mailbox does well for me. It costs money but it's a decent service. For business we run our own servers.<br> <p> Like most people; for my personal emails I also run a local dovecot/postfix server for mail archives/backups, ensuring only the most recent mails are left on the servers.<br> <p> The advantage here is that historic mails (over 6 months old) are no longer stored online and are only available locally. :-)<br> </div> </description> <pubDate>Fri, 04 Apr 2025 23:01:09 +0000</pubDate> </item> <item> <title>Annotation placement</title> <link>https://lwn.net/Articles/1016526/</link> <guid>https://lwn.net/Articles/1016526/</guid> <dc:creator>Karellen</dc:creator> <description><blockquote><code>// In C:<br> int __kptr * name;<br> <br> // In BTF:<br> pointer type tag -&gt; kernel pointer annotation -&gt; integer</code> <p>The fact that the annotation that marks a pointer type as a kernel pointer comes after the pointer type itself is a bit unusual. Other annotations, such as const, are represented by tags that appear before the pointer type.</p></blockquote> <p>I'm finding this a bit confusing. Are you talking about "the annotation" in C, or in BTF? Or, am I not understanding how C types get translated into BTF types? In C, isn't it the case that:</p> <code>const int * name; // Pointer to const int<br> int const * name; // Pointer to const int<br> int * const name; // Const pointer to int</code> <p>The annotation (e.g. <tt>const</tt>) can come before or after the pointed-to-type, and in both cases refers to the pointed-to-type. Mustn't the annotation come <em>after</em> the pointer declaration (the <tt>*</tt>) to apply to the pointer itself?</p> <p>So, according to C rules, don't <tt>int __kptr * name;</tt> and <tt>__kptr int * name;</tt> both say that the <em>int</em> is a kptr, whereas shouldn't <tt>int * __kptr name;</tt> be used to imply that the pointer is a kptr?</p> <p>(Or are you saying that <tt>int * __kptr name;</tt> should be how it's represented in C, but isn't?)</p> </description> <pubDate>Fri, 04 Apr 2025 20:22:40 +0000</pubDate> </item> <item> <title>KSM for testing network topologies</title> <link>https://lwn.net/Articles/1016528/</link> <guid>https://lwn.net/Articles/1016528/</guid> <dc:creator>lobo</dc:creator> <description><div class="FormattedComment"> KSM is quite useful for testing network operating systems and network topologies. In this use-case you usually run multiple identical VMs of a network operating system.<br> <p> Containerlab as one of the open source tools in this space, has also a section for KSM in its manual: <a href="https://containerlab.dev/manual/vrnetlab/#memory-optimization">https://containerlab.dev/manual/vrnetlab/#memory-optimiza...</a><br> </div> </description> <pubDate>Fri, 04 Apr 2025 20:06:29 +0000</pubDate> </item> <item> <title>Isn't this a language problem?</title> <link>https://lwn.net/Articles/1016523/</link> <guid>https://lwn.net/Articles/1016523/</guid> <dc:creator>geofft</dc:creator> <description><div class="FormattedComment"> Isn't this fundamentally a (classic) weakness in the C language, that there's no way to distinguish a pointer to an uninitialized value that you need to write to first and a pointer to an initialized value that is okay to read from?<br> <p> BPF is its own environment, and there's no particular requirement to be fully backwards compatible with the large body of existing C code. (I would bet that the overwhelming majority of existing C code won't pass the verifier!) Why is using standard C the answer here? <br> <p> Of course one approach is to use another language that can distinguish these at the type level (like Rust's MaybeUninit&lt;T&gt;, and using Rust would unsurprisingly be my preferred solution), but wouldn't it also be feasible to write BPF programs in some variant of C that addresses these sorts of issues? If you have no need to compile existing, unmodified C code, couldn't you do something along the lines of Cyclone and add some new pointer types that capture the information needed to avoid these sorts of issues?<br> </div> </description> <pubDate>Fri, 04 Apr 2025 18:21:50 +0000</pubDate> </item> <item> <title>Regarding pronunciation</title> <link>https://lwn.net/Articles/1016521/</link> <guid>https://lwn.net/Articles/1016521/</guid> <dc:creator>jzb</dc:creator> <description><div class="FormattedComment"> I can't speak for any other folks, but I knew the "libre" in calibre was referring to the "Libre" concept -- so I (mistakenly) thought it would be emphasized in the pronunciation as well. Otherwise, I'd pronounce "calibre" just like "caliber" in any other context. <br> </div> </description> <pubDate>Fri, 04 Apr 2025 18:05:16 +0000</pubDate> </item> <item> <title>Regarding pronunciation</title> <link>https://lwn.net/Articles/1016520/</link> <guid>https://lwn.net/Articles/1016520/</guid> <dc:creator>LawnGnome</dc:creator> <description><div class="FormattedComment"> I suspect so — as an Australian English speaker, I'd never even considered a pronunciation other than the English word calibre/caliber.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 17:29:11 +0000</pubDate> </item> <item> <title>Postgres, FPW=off and DIO</title> <link>https://lwn.net/Articles/1016510/</link> <guid>https://lwn.net/Articles/1016510/</guid> <dc:creator>mcgrof</dc:creator> <description><div class="FormattedComment"> We have no semantics today defined for buffered IO for RWF_ATOMIC, and so it can't be evaluated directly. At this stage the goal was to garner kernel community appreciation over it's potential, and discuss possible kernel level filesystem and block semantics. Since there seems to now be better appreciation over it's potential on the kernel, and the possible kernel semantics have been discussed the next goal would be to tailor a use case for databases that could leverage it such as PostgreSQL, and for that it's best to collaborate with the db community.<br> <p> Its also correct that the RWF_ATOMIC atomic semantics today require single writes, that's not because of the requirements of direct IO but rather because at least from an NVMe perspective, a write IO size must not cross a boundary size, and if that's 16k an atomic write cannot be larger than 16k, ie it's a hardware requirement. And so software must also adhere to tailor atomic writes hardware needs, and the goal of RWF_ATOMIC is to help facilitate the requirements. Although NVMe MAM in theory could help large IO RWF_ATOMIC, and wrinkle to that it only works if a large write succeeds. If a large NVMe atomic MAM write fails filesystems today on Linux have no way of telling what block was valid and which is incorrect, the atomic block which failed is not communicated back. And so the entire range would need to be invalidated, which defeats the purpose. Reflininks *may* help here to support that limitation, but that'd require some evaluation and development.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 14:53:08 +0000</pubDate> </item> <item> <title>ASI vs ASR</title> <link>https://lwn.net/Articles/1016508/</link> <guid>https://lwn.net/Articles/1016508/</guid> <dc:creator>bjackman</dc:creator> <description><div class="FormattedComment"> Yeah they're kinda orthogonal tools for security. <br> <p> BTW, if it KASLR gets meaningfully in your way, IMO you should just switch it off. It's a road-bump to slow attackers down, it doesn't actually create any new security boundary or have any fundamental theoretical benefit. It's a kinda economic lever - it makes life Y% more difficult for the attacker and X% more difficult for the defender. If Y isn't significantly higher than X for your usecase, I'd say you should drop it.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 14:13:34 +0000</pubDate> </item> <item> <title>Postgres, FPW=off and DIO</title> <link>https://lwn.net/Articles/1016505/</link> <guid>https://lwn.net/Articles/1016505/</guid> <dc:creator>andresfreund</dc:creator> <description><div class="FormattedComment"> Hi,<br> <p> Are fpw=off numbers for Postgres numbers actually somehow using RWF_ATOMIC? Because if not, the performance comparisons seem fairly meaningless - all it'd be measuring is whether increased WAL volume has a performance impact - it obviously has.<br> <p> RWF_ATOMIC does come with some overhead, AFAIU (on lots of devices FUA writes are slower).<br> <p> <p> FWIW, we (PG) finally merged AIO support recently. Albeit, for the next release, only with read support. Just ran out of time to solve some of the corner cases for asynchronous writes. I'm fairly certain that we can get write support done for the next version. While we added readahead for a lot of places in 17 and now in 18, there are still some important ones that matter, that's the big other missing piece.<br> <p> You can already enable unbuffered IO, albeit for now with a flag intentionally intended to scare folks away (debug_io_direct=data).<br> <p> However, I'm fairly certain that even once we fully support direct IO, a large number of folks will not be able to use it. To be sane to use DIO requires a much larger buffer pool than using buffered IO would. That's not viable for the large number of cases where postgres runs on shared hardware with either other software or other postgres instances. Which is unfortunately common.<br> <p> <p> With the WIP AIO write support we have seen rather significant performance wins with writing multiple buffers at once when possible (i.e. write combining up to 32 neighboring 8kB buffers with one vectored write). My understanding is that that won't realistically be compatible with the current RWF_ATOMIC semantics. We probably can determine whether to write combine based on whether we need torn-page protection, but it'll be a painful tradeoff.<br> <p> </div> </description> <pubDate>Fri, 04 Apr 2025 14:09:41 +0000</pubDate> </item> <item> <title>Hmmm</title> <link>https://lwn.net/Articles/1016504/</link> <guid>https://lwn.net/Articles/1016504/</guid> <dc:creator>nim</dc:creator> <description><em>A member of the audience pointed out that AMD's ability to perform TLB coalescing without explicit page-table-entry bits is nice, but it only works if the application has accessed at least half of the pages within the mTHP.</em> <p>I wonder what is the basis for this claim. I was under the impression that the page walker loads an entire cache line which contains 8 entries - hence the 32kB granularity of coalescing - and if the conditions are satisfied, e.g. the 8 entries point to 8 consecutive physical pages starting on 32kB boundary and share the same attributes, it sets up the TLB entry to cover the 8 pages. Why would it need the pages to be touched?</p> <p>But even if it does, it is transparent. So it's always worth to make sure the conditions are satisfied.</p> </description> <pubDate>Fri, 04 Apr 2025 14:02:11 +0000</pubDate> </item> <item> <title>Quick notes</title> <link>https://lwn.net/Articles/1016452/</link> <guid>https://lwn.net/Articles/1016452/</guid> <dc:creator>bjackman</dc:creator> <description><div class="FormattedComment"> I guess the distros would also like to build the kernel they distribute using the toolchain they distribute, too?<br> </div> </description> <pubDate>Fri, 04 Apr 2025 12:41:18 +0000</pubDate> </item> <item> <title>Data collection?</title> <link>https://lwn.net/Articles/1016451/</link> <guid>https://lwn.net/Articles/1016451/</guid> <dc:creator>maharmstone</dc:creator> <description><div class="FormattedComment"> I once sent Kovid a polite e-mail saying precisely this, and asking him for a way to disable the telemetry, and received a torrent of abuse in return. Horrible man. Apparently he doesn't think that what he's doing is telemetry.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 12:02:52 +0000</pubDate> </item> <item> <title>sensitive</title> <link>https://lwn.net/Articles/1016450/</link> <guid>https://lwn.net/Articles/1016450/</guid> <dc:creator>bjackman</dc:creator> <description><div class="FormattedComment"> Yeah, it's tricky.<br> <p> All the code I've posted so far just says everything allocated as GFP_USER is sensitive. So, not just file pages but also all anonymous user pages are sensitive. This already goes a pretty long way (it certainly adds a huge amount of extra engineering work for an attacker starting from a pre-ASI exploit) but as you've pointed out there are obvious things that it doesn't include that need to be protected. The other classic example to my mind is stuff copied into the kernel stack from userspace/VM guests.<br> <p> In principle we should be able to flip this question on its head and instead make the question "what _isn't_ sensitive", i.e. isntead of marking stuff as __GFP_SENSITIVE with the default being unprotected (we call this "denylist"), we could protect erverything by default and mark exceptions as __GFP_NONSENSITIVE (we call this "allowlist"). So far the general feeling has been that it's more practical to start from something that people can actually deploy and evaluate without worrying about an unpredictable performance disaster. But we could certainly switch to an allowlist model later down the line, it would make good sense to me.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 12:00:22 +0000</pubDate> </item> <item> <title>Seem like a reasonable move</title> <link>https://lwn.net/Articles/1016449/</link> <guid>https://lwn.net/Articles/1016449/</guid> <dc:creator>mathstuf</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt; with both Procmail and Fastmail creating their own bad press</span><br> <p> Do you have links?<br> </div> </description> <pubDate>Fri, 04 Apr 2025 11:38:49 +0000</pubDate> </item> <item> <title>Minor correction</title> <link>https://lwn.net/Articles/1016447/</link> <guid>https://lwn.net/Articles/1016447/</guid> <dc:creator>bjackman</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt; The mitigations are off at Google</span><br> <p> I don't think I said this, but if I did I mis-spoke, sorry! I try to be transparent about the Google deployment where I can but the exact set of mitigations we use internally isn't something I'd discuss publicly.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 11:33:56 +0000</pubDate> </item> <item> <title>Gmail mail server alternatives</title> <link>https://lwn.net/Articles/1016444/</link> <guid>https://lwn.net/Articles/1016444/</guid> <dc:creator>alx.manpages</dc:creator> <description><div class="FormattedComment"> I used Gmail as the mail server for a very long time for similar reasons. I used Thunderbird for the MUA, but Gmail was a reasonable server.<br> <p> However, I recently discovered a small company, Migadu, that provides a mail server, and the prices are quite reasonable: &lt;<a href="https://migadu.com/">https://migadu.com/</a>&gt;. Their customer support is excellent; I met a few bugs in their software, and they fixed them in hours of my report. And they also answered any doubts I had. Now I've been using Migadu for a year or so, and I can only say I'm very happy.<br> <p> I learned from them because of &lt;<a href="https://korg.docs.kernel.org/linuxdev.html">https://korg.docs.kernel.org/linuxdev.html</a>&gt;.<br> <p> <p> </div> </description> <pubDate>Fri, 04 Apr 2025 09:26:33 +0000</pubDate> </item> <item> <title>GCC 4.9.4</title> <link>https://lwn.net/Articles/1016443/</link> <guid>https://lwn.net/Articles/1016443/</guid> <dc:creator>gioele</dc:creator> <description><div class="FormattedComment"> <span class="QuotedText">&gt;&gt;&gt; Toolchain for all supported devices is now GCC 4.9.4 and can be built using contemporary systems</span><br> <span class="QuotedText">&gt;&gt;</span><br> <span class="QuotedText">&gt;&gt; The embedded world never ceases to amaze.</span><br> <span class="QuotedText">&gt;</span><br> <span class="QuotedText">&gt; That toolchain bump landed in October of 2020[1] and there are _still_ problems popping up that can be traced to back to it.</span><br> <span class="QuotedText">&gt;</span><br> <span class="QuotedText">&gt; In the embedded world, you don't change what isn't broken without a damn good reason... and comprehensive testing, which is a bit challenging when the handful of folks involved are all unpaid spare-time volunteers that lack access to a majority of the *83* different devices [2] covered by the release.</span><br> <p> To be clear, my original comment was a positive one: kudos to the team managing such a transition under all those constraints!<br> </div> </description> <pubDate>Fri, 04 Apr 2025 09:14:09 +0000</pubDate> </item> <item> <title>On the use of donations to MZLA Technologies Corporation</title> <link>https://lwn.net/Articles/1016442/</link> <guid>https://lwn.net/Articles/1016442/</guid> <dc:creator>jberkus</dc:creator> <description><div class="FormattedComment"> They're not halting. I was chatting with the TB team at SCALE, and there's a number of longstanding issues that are finally getting resolved. If anything, work on the client is accelerating.<br> <p> At the same time, the client just isn't going to change that much, particularly if they have to be compatible with proprietary mail servers. Hence work on new services.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 08:42:00 +0000</pubDate> </item> <item> <title>Seem like a reasonable move</title> <link>https://lwn.net/Articles/1016441/</link> <guid>https://lwn.net/Articles/1016441/</guid> <dc:creator>jberkus</dc:creator> <description><div class="FormattedComment"> I can totally see why MZLA is doing this -- it's the natural direction of growth, and doesn't require making deals with any advertisers. Plus, with both Procmail and Fastmail creating their own bad press, folks are looking for non-gmail alternatives.<br> <p> I don't know that I'll use it, but I'll at least try it.<br> </div> </description> <pubDate>Fri, 04 Apr 2025 08:38:30 +0000</pubDate> </item> </channel> </rss>