LWN: Comments on "Smart pointers for the kernel"

Rust vs. C

Wol — Mon, 21 Oct 2024 13:59:40 +0000

Okay, this dates from my Fortran days, but I try to code in blocks of at most one screen. These *may* warrant a short description of what the block is meant to achieve. Preferably a couple of lines, so it's a block description of a block of code.

The individual lines of code should be self explanatory, but especially when they are "elegant" (my word for "obvious once you know what it's doing") or convoluted, they may warrant a short one-liner.

Two different types of comment, for two different scenarios, shame many languages don't allow you to differentiate. This is where C(++)s' "/* */" and "//" are actually very good, as you can differentiate between the two.

Cheers,
Wol

Rust vs. C

mathstuf — Mon, 21 Oct 2024 12:29:04 +0000

The code I linked is "obvious" from an algorithm viewpoint (grab some info from the code submission, traverse a graph from the configuration while collecting visited nodes, and finally do a set intersection). The *why* is probably completely lost without the comments. I find this is more useful in high-level code where the data has far more meaning baked into them (i.e., there is far more meaning attached to the strings than just the names themselves here) than at the "implement a set intersection" level where the data elements' relevant properties end at "have a mechanism to compare equality".

FWIW, I add comments as I code if I'm building up the algorithm from scratch or (as in this case) when I'm self-reviewing the code before merging (I think I added these even before I opened the initial MR).

Rust vs. C

jezuch — Mon, 21 Oct 2024 09:09:29 +0000

> Sounds like a bad habit to me. I find comments to be very helpful in both development and review.

I'm not saying this is a *good* thing :) It just happens, at least in my brain, when tracing the code itself. I remember to look at the comments only when I'm confused, baffled, or otherwise can't figure out why it does what it does.

On the other hand, I only *add* comments when I know the code may be confusing for the reader. (This includes me, a month from now.) For example, there was a bug and the fix required some unexpected or counter-intuitive condition(s). Other than that the code should be "obvious" and in code like that comments are unnecessary at best, harmful at worst.

reftrack-plugin

pabs — Sat, 19 Oct 2024 00:29:35 +0000

From the HN comments, a GCC plugin for C language that tracks references to allocated objects:

https://github.com/acbits/reftrack-plugin
https://news.ycombinator.com/item?id=41875792

Rust vs. C

blackfire — Fri, 18 Oct 2024 07:56:14 +0000

> Hm, are you sure that just having two aliasing nonconst raw pointers is insta-UB?
> That doesn't look right to me.

Having multiple raw pointers (const or not) is fine, having multiple mut references (or one mut and 1+ const) is UB, even without dereferencing any of them.

(this is made mildly more complex by stacked borrows but that's the gist and honestly I don't claim to fully understand the intricacies of the model, but you do have to watch out for UB any time you make a reference from a raw pointer)

Smart pointers and memory models

westurner — Fri, 18 Oct 2024 06:28:58 +0000

FWIW e.g. Apache Arrow is zero copy with C, CFFI, C++, Java, Python, and Rust APIs:

[Memory and IO Interfaces — Apache Arrow v17.0.0](https://arrow.apache.org/docs/python/memory.html#memory-p...)

> External memory, under the form of a raw pointer and size, can also be referenced using the foreign_buffer() function.

pyarrow.foreign_buffer(address, size, base=None)
https://arrow.apache.org/docs/python/generated/pyarrow.fo... :

> base: Object that owns the referenced memory.

> The buffer will be optionally backed by the Python base object, if given. The base object will be kept alive as long as this buffer is alive, including across language boundaries (for example if the buffer is referenced by C++ code)

The Arrow Parquet docs mention that parquet must be reshaped when reading and writing from disk.

Feather (Arrow IPC) format is the same shape on disk as in RAM, with ZSTD or LZ4 compression by default.

serde.rs supports very many serialization formats for rust, including Python pickles and CSV and JSON and so on.

lancedb also does zero-copy with Rust and Arrow: https://lancedb.github.io/lancedb/#why-use-lancedb :

> Tight integration with the Arrow ecosystem, allowing true zero-copy access in shared memory with SIMD and GPU acceleration

arrow-ipc-bench compares Flight, Plasma (*), sharedmemory with MacOS, IIRC:
https://github.com/wjones127/arrow-ipc-bench/tree/main

Rust arrow_ipc::reader > Struct StreamReader:
https://docs.rs/arrow-ipc/53.1.0/arrow_ipc/reader/struct....

Apache Arrow > Serde.rs compatibility:
https://docs.rs/arrow/latest/arrow/#serde-compatibility

Rust vs. C

mb — Fri, 18 Oct 2024 06:13:22 +0000

>except `unsafe`, but if you use it to violate the "aliased xor mutable" rule, it's insta-UB anyway)

Hm, are you sure that just having two aliasing nonconst raw pointers is insta-UB?
That doesn't look right to me.

Rust vs. C

blackfire — Fri, 18 Oct 2024 06:00:45 +0000

> C assumes that nobody will ever make that mistake (and it's probably right), whereas Rust wants to be sure that they can't make it.

And it's actually trivial enough in this case. See a sample StrBuf in the Rust playground: https://play.rust-lang.org/?version=stable&mode=debug...

Uncommenting the one commented line (which would lead to the bug you mention) will cause a compile error. The `append` method takes a mutable reference to `self` (the object it's modifying) and an immutable reference to the bytes it's about to append.

The catch is you cannot have both a mutable and immutable reference to the same object, so there's no way trying to append a buf to itself would work (except `unsafe`, but if you use it to violate the "aliased xor mutable" rule, it's insta-UB anyway).

Rust vs. C

mathstuf — Sun, 13 Oct 2024 20:08:17 +0000

Sure, I've dug through third party code. The comments may be *bad*, but I still have to read them to know that. *Ignoring* them means also being unaware of the (or at least "an") *intent* of the code (regardless of its implementation quality).

Documented invariants versus invariants in code

tialaramex — Sun, 13 Oct 2024 20:06:04 +0000

In the days since reading this comment I've been trying to figure out a suitably nefarious new misfortunate type which meets this requirement but I didn't succeed so far, maybe I'm missing a trick (although I did make one new "smart pointer" type that is fairly silly but it's still Sized because it requires Default)

In the event you find yourself writing such a type please let me know, I'm named tialaramex most places - including Google's "Gmail" of course.

Rust vs. C

pizza — Sun, 13 Oct 2024 13:57:41 +0000

> Sounds like a bad habit to me. I find comments to be very helpful in both development and review.

So I take it you've never had to review (or otherwise work with/consume) external/third party code?

In my experience, comments are rarely helpful, and more often than not, actively harmful to your understanding of what the code _actually_ does. (As opposed to what was intended at the time the comments were written).

Rust vs. C

mathstuf — Sun, 13 Oct 2024 13:41:28 +0000

> In my experience, a programmer's brain gets trained to "unsee" comments as irrelevant filler.

Sounds like a bad habit to me. I find comments to be very helpful in both development and review. A recent example: https://gitlab.kitware.com/utils/ghostflow-director/-/mer...

Smart pointers and memory models

geofft — Fri, 11 Oct 2024 20:44:24 +0000

Ah, thanks, that specific discrepancy is the sort of thing I was curious about, thanks! I will look forward to the writeup.

Smart pointers and memory models

farnz — Fri, 11 Oct 2024 19:12:49 +0000

Rust atomics exactly match the memory model defined for C11, but with memory_order_consume (which no compiler benefited from, last I checked - all implementations I've seen treat it as a weird spelling of memory_order_acquire) removed completely.

The LKMM predates C11 by quite some time, and has different rules about what happens-before and synchronizes-with relationships are established by the various atomic operations you can do. As a result, something needs to make sure that when Rust code accesses atomics that are shared with C, the LKMM rules are followed, and not the C11 rules; if everything just followed the C11 rules, then the kernel code that assumes LKMM would be broken (although I believe that if everything follows the LKMM rules, code that assumes C11 rules will still work).

And Rust code will eventually need to modify atomics shared with C, because some of the existing kernel data structures depend on atomic modifications.

Smart pointers and memory models

daroc — Fri, 11 Oct 2024 19:01:04 +0000

That is an excellent summary of the talk. As to why the LKMM is relevant — the LKMM doesn't just say things about how to write to atomic variables, it also has guarantees about how those writes interact with other constructs like threads. Boqun Feng actually had a neat talk that gave more detail about this later in the day that I'm still in the process of writing up. But one example is that if one thread writes to an atomic variable and then wakes another thread, the LKMM says that second thread is guaranteed to see the write. Rust atomics don't make that guarantee. Does that discrepancy cause problems? Maybe. At the very least, it's an extra complication to think about. Writing correct multithreaded code is hard enough; there's no reason to make it harder by having two conflicting models.

Smart pointers and memory models

geofft — Fri, 11 Oct 2024 18:41:54 +0000

I'm trying to understand the reference to the Linux kernel memory model here. Here's my very limited understanding so far and I'd appreciate corrections:

The Rust standard library type Arc<T> (atomically reference-counted pointer to T uses the atomic support in the Rust standard library for the refcount, and there's some particular implementation of those.
The Linux kernel might want to use a different implementation of atomics (concretely, maybe different assembly instructions, maybe adding barriers) than the Rust standard library uses. In particular, if Rust code and C code are modifying the same atomic, they need to use compatible instructions.
Arc (and Rc and a few other standard library pointer-wrapping types) have the ability that, if they hold a two-word "fat pointer", you can use them in contexts where you need a normal pointer and you know you don't need the metadata (e.g., because you're calling a method from the vtable, and that method was compiled knowing what type it's being called on) by just casting (transmuting) the type of the smart pointer and ignoring the second word.
This functionality is implemented by these types implementing some unstable marker traits, which they can do because they're in the standard library. Apart from the correctness things described in the article, the other important thing these traits do is promise that this cast is valid and that e.g. Rc<[u8; 10]> is the first few bytes of Rc<[u8]>.
The kernel wants a refcounted type with this same ability.
So the Rust team is adding a derive annotation that implements these traits (instead of exposing the traits themselves, whose API they're not ready to commit to) that requires that anything you derive the trait on is a #[repr(transparent)] wrapper around something in the standard library that is marked as implementing those traits (a raw pointer is one of these), which guarantees the layout trick.

I think the part I don't understand is the relevance of interop between Rust and C. Is there any case where Rust and C are modifying the same atomic variable? Is the kernel's implementation of Arc (or ListArc) intended to be layout-compatible with any existing C code in the kernel? It seems like "We want to leak on overflow instead of panicking" and "We need the intrusive linked list support because that is a useful design in kernelspace" by itself justify this, and the different memory model doesn't come into play. What goes wrong if Rust types use Rust atomics and C types use kernel atomics?

Maybe put another way, if the standard library gained SaturatingArc<T> and an appropriate intrusive linked list type, which seem like not unreasonable things for everyone to have, would those suffice? (To be clear, I'm not actually suggesting this instead of the current approach, just asking it as a hypothetical for my understanding.)

For that matter, why are Rust atomics and LKMM atomics different? I'm vaguely familiar with the fact that (e.g.) Alpha does things with memory ordering that people don't expect and so you need more barriers than your same code would need on other architectures, and so the kernel does emit those barriers on Alpha. But wouldn't this apply to all code on Alpha, and thus wouldn't Rust want to handle atomics in the same way? Why is there not one obvious correct way for anyone to implement an atomic reference count on a given architecture?

Documented invariants versus invariants in code

NYKevin — Wed, 09 Oct 2024 20:22:38 +0000

> and you make this change without any &mut self method being called.

Self-nitpicking: This should read "any &mut self method other than DerefMut::deref_mut()." But that's still a ridiculous thing to do, because deref_mut() is the method that overrides the * (dereference) operator for write operations, so if you have it re-seat the pointer, you'd be causing code like *foo = bar to change what address ("place" in Rust's formal terminology) foo points at. Nobody who writes *foo = bar expects something like that to happen.

At this point, I imagine that C++ programmers will object that, even though this operation should not change the address of the pointee, it could change the object's dynamic type. This is sort of true in C++ (objects may change dynamic type during construction, so when the object is copy-constructed, it could temporarily have a different dynamic type from bar, and you can interact with it through foo during this time), but not true at all in Rust (vtables are not even part of the object representation in the first place, they are statically allocated and tracked by fat pointers, so there is no plausible mechanism for modifying an object's dynamic type, nor is it possible to interact with partially-constructed objects through safe Rust).

Rust vs. C

taladar — Wed, 09 Oct 2024 08:37:30 +0000

> In my experience, a programmer's brain gets trained to "unsee" comments as irrelevant filler. They are just invisible. How can you keep them in sync if your brain thinks they don't exist?

That is a good point, essentially you can never rely on them when trying to understand the code because they might be outdated but you would always have to read them when modifying the code to see if they need to be updated. That is a very unlikely combination of behaviors to develop naturally.

Rust vs. C

jezuch — Tue, 08 Oct 2024 18:04:09 +0000

That's true even in teams that take things seriously and require at least two approvals before things get merged so that issues like this are exposed to more eyeballs - and with no time pressure to boot. In my experience, a programmer's brain gets trained to "unsee" comments as irrelevant filler. They are just invisible. How can you keep them in sync if your brain thinks they don't exist?

That said, the claim was that comments documenting invariants have value. They do, but only because you cannot do it in the programming language itself. How can you put faith in proofs in an unspecified language that the compiler doesn't even look at?

Use a language in which you don't have to do it most of the time.

Rust vs. C

gerdesj — Tue, 08 Oct 2024 00:26:30 +0000

"… and that's the difference between Rust and C, right here."

My takeaway from this article is that both camps are (begrudgingly) listening to each other.

As a civilian, I don't really give a shit about the rights and wrongs of a programming paradigm or whatever wankery is in the ascendant today. I am persuaded that C and Rust are both serious ways of generating machine code to run on my CPUs 'n that.

What I do like to see is gangs of serious engineers getting to grips with novel ideas and gradually thrashing out the best (for a given value of best) way forwards.

In the end its all about the engineering. Unless you are writing raw machine code, you need Assembly, C or Rust or whatevs to get stuff done ... err make stuff happen. Do remember that in the end you are generating machine code that does something - that's the goal. How you get there is a "journey" and that is up to you.

My laptop does not "run" C or Rust. It runs machine code and that's all. Please ensure it runs the best machine code available, however you get it there! I will be forever grateful for that.

Unsafe

NYKevin — Tue, 08 Oct 2024 00:25:55 +0000

It's not possible (at compile-time) to do these coercions on Double, because the unsizing coercion is only legal for types that are layout-identical to a single raw pointer. More prosaically, Double does not allow T: ?Sized, so it wouldn't be possible even if it were possible.

But if neither of those issues were present, this would be entirely fine since Double::swap() takes a &mut self parameter, and you only violate this invariant if you re-seat the pointer without calling such a method. Pin does not allow borrowing either the pointer or the pointee mutably (unless the pointee is Unpin), so it would prevent you from calling swap(), and everything would be entirely sound.

Documented invariants versus invariants in code

NYKevin — Mon, 07 Oct 2024 23:51:11 +0000

The "good" news is that, in this particular case, it would be quite perverse to define an object that violates this invariant. The vast majority of reasonable smart pointers are fully compliant and can just opt into it without further thought. It is only a problem if you (in the smart pointer implementation) change what object you're pointing to, the objects have different fat pointer metadata (vtable or slice size), and you make this change without any &mut self method being called. Nobody does that combination of things, because it's obviously crazy to re-seat a pointer (smart or dumb) without counting that as a mutation of the pointer.

Even misfortunate does not do it (at time of writing): Double does not specify T: ?Sized so you can't put a fat pointer into it (although I suspect that's merely an oversight rather than an intentional decision), and Double::swap() is a &mut self method, so even if T could be unsized, swap() counts as a modification of the pointer anyway.

In order to violate this invariant, you'd need to be doing something really ridiculous, like modifying the raw pointer value through a Cell<T> (not a Mutex<T>, since the whole smart pointer has to have the same layout as a raw pointer for this unsizing coercion to be possible in the first place), or using mem::transmute() to replace the raw pointer's vtable with a different one (not UB if the concrete types are layout-compatible).

Documented invariants versus invariants in code

farnz — Mon, 07 Oct 2024 17:59:20 +0000

The bigger problem, IME, is not time, but actually recognising that you've changed something relevant. In that regard, documentation and comments (including Rust safety comments) are the worst possible way to deal with an API invariant, since there's not even a guarantee that the wording of the comment will be consistent enough to be usefully greppable.

The ideal is always type-level checking of your invariants, because that check stops you making mistakes. The next best thing is what this proposal does with unsafe impl, where users get the invariant type-checked (so I can remove the unsafe impl if it's wrong, and find all the places that need fixing), and where it's not hard to write a tool that will definitely find all the places that need manual checks.

The worst case is a situation where code at the point of use says something like "relies on the fact that foo does not move its contents, ever" in a comment, so that when someone refactors FooPtr, they've got to review all users of FooPtr to discover that the "foo" in the comment refers to something of type FooPtr.

Rust vs. C

carlosrodfern — Mon, 07 Oct 2024 16:42:26 +0000

This is so true in the company environment with the time pressure. The company puts deadlines over excellency in many cases and it is satisfied with a "good enough" code quality. However, in the Open Source projects, if there is no time pressure (and usually there isn't), you can take your time to get it as perfect as you want, and demand that from your contributors. It depends a lot on the main maintainer's perspective on code quality discipline. In the case of Linux, they have Linus, and he has done a great job communicating the culture of excellency over deadlines. However, once the key individual of a project leaves or changes code quality perspective, there is a high risk of things "relaxing" and falling apart.

Rust vs. C

iabervon — Sun, 06 Oct 2024 21:17:27 +0000

There are a lot of invarants that are almost always true and that people don't realize they're assuming, especially ones which require that two variables of the same type don't have the same value. For example, git's strbuf_addstr() assumes that the string you're adding isn't the buf of the strbuf you're adding it to. Any other string works, and there's a function that adds a strbuf to another strbuf that works for this case (and is more efficient in all cases), but there's nothing pointing out that this one operation that practically nobody would want to do is actually unsafe, and it's probably not better to consume programmers' attention making sure they know about it, since they're much less likely to make this mistake than all sorts of other mistakes, but it would be good if the compiler could point out the issue if they actually violate it. For that matter, the author of the strbuf_addstr() function probably didn't consider the possibility that the string to add might be the same memory as the one being reallocated to make space. To be certain to avoid unlikely issues, the compiler would have to tell the library author to include an annotation of an obscure invariant that the compiler should tell users of, if they ever violate it.

C assumes that nobody will ever make that mistake (and it's probably right), whereas Rust wants to be sure that they can't make it.

Rust vs. C

kleptog — Sun, 06 Oct 2024 21:11:16 +0000

The main problem with documenting API invariants via comments is that they'll be wrong after the first refactor. Unless there's a process to actually validate them, they're almost certainly going to be wrong fairly quickly.

Unsafe

daroc — Sun, 06 Oct 2024 15:13:22 +0000

Although I'm not familiar with misfortunate::Double, that sounds like a central example of a type that is not safe to do these conversions on.

Rust vs. C

tux3 — Sun, 06 Oct 2024 13:38:40 +0000

I would nitpick that the culture of annotating invariants in comment or documentation is certainly something I'd like to see more on the C side. Methinks we'd need a lot less tooling enforcement if people always diligently thought about (and documented!) all the important invariants their API expects.

Rust vs. C

smurf — Sun, 06 Oct 2024 07:54:45 +0000

… and that's the difference between Rust and C, right here.

With Rust you add funky semi-comprehensible macros to your classes to tell the compiler which invariants your class and/or pointers to its members requires (and obeys). You don't do that? people will have problems using your class.

With C you write simple and legible code (or what looks like such) and document the invariants in comments or documentation (or not). Your users can walk right over them and nobody cares — until the kernel BUGs on you, that is. Or worse.

Unsafe

tialaramex — Sat, 05 Oct 2024 16:11:57 +0000

I'm glad to see this requires the unsafe marker upholding Rust's principles here.

I implement Deref and DerefMut for misfortunate::Double which (the whole point of the misfortunate crate) does something that's legal in safe Rust but is probably not what you wanted. in this case although dereferencing a Double<T> gets you access to a T, *mutably* dereferencing it gets you a different T! There are two inside it (hence the name) but they appear to be singular from outside.

I don't know whether it would be safe for this to have the marker or not, but because it's unsafe I know I can just not implement it and never need to know.