No, if the memory-mapped page you're accessing is in RAM, then you're just reading the RAM; there is no page fault and no syscall and nothing blocks.
You could say that any non-register memory access "blocks" but I feel that's needlessly confusing. Normal async code doesn't "block" in any relevant sense when it accesses the heap.
When dealing with async I think it is very relevant to think of exactly the points where control can be switched.
As such a regular memory read is blocking, in that control will not switch while you're doing the read (ie your not doing anything else while it's copying). This is unlike issuing an async read, which is exactly a point where control can switch.
edit: As an example, consider synchronous memory copy vs asynchronous DMA-based memory copy. From the point of view of your thread, the synchronous copying blocks, while with the DMA-based copying the thread can do other stuff while the copying progresses.
As the author, I don't think there's a clear definition of "blocking" in this space, other some vibes about an async task not switching back to the executor for too long, for some context-dependent definition of "too long".
It's all fuzzy and my understanding is that what one use-case considers being blocked for too long might be fine for another. For instance, a web server trying to juggle many requests might use async/await for performance and find 0.1ms of blocking too much, vs. a local app that uses async/await for its programming model might be fine with 10ms of "blocking"!
That the process/thread enters kernel mode and then is suspended waiting for IO or for some other event. As long as the thread is running your code (or, is scheduleable) it's not blocked. And then the async implementation can ensure your code cooperatively gives up the CPU for other code.
If your memory is paged out and you then access it, using your definition, it would block.
So, in the context of async code, there's no difference from the application perspective between reading mmap'ed data and reading "regular" data (ie memory from the regular paged pool), as both could incur blocking IO.
If you're lucky and the mmap'ed data is in the system cache, then reading that data will not block and is fast. If you're unlucky and your process has been swapped out, then doing a regular memory read will block and is slow.
It will at the very least notice that the read data does not match the stored checksum and not return the garbage data to the application. In redundant (raidz) setups it will then read the data from another disk, and update the faulty disk. In a non-redundant setup (or if enough disks are corrupted) it will signal an IO error.
An error is preferred to silently returning garbage data!
The "zeroed-out file" problem is not about firmware lying though, it is about applications using fsync() wrongly or not at all. Look up the O_PONIES controversy.
Sure, due to their COW nature zfs and btrfs provide better behavior despite broken applications. But you can't solve persistence in the face of lying firmware.
Even thought zfs has some enhancements to not corrupt itself on such drives, if you run for example a database on top, all guarantees around commit go out the window.
"Renaming a file should always happen-after pending writes to that file" is not a big pony. I think it's a reasonable request even in the absence of fsync.
Well, for one rename() is not always meant to be durable. It can also be used for IPC, for example some mail servers use it to move mails between queues. Flushing before every rename is unexpected in that situation.
Fun fact: rename() is atomic with respect to running applications per POSIX, that the on-disk rename is also atomic is only incidental.
I'm not suggesting flushing for rename. If a file write and a rename happen shortly before power loss, and neither goes through, that's fine.
With this rule, three outcomes are acceptable: both occur, or neither occur, or just the file write happens. The unacceptable outcome is that just the rename happens.
("file write" here could mean a single write, or an open-write-close sequence, it doesn't particularly matter and I don't want to dig through old discussions in too much detail)
As an aside, can you still get the bad checksum file contents with zfs? Eg if it's a big database with its own checksums you might want to run a db level recovery on it.
The argument goes along the lines that GPL-only symbols are so tightly coupled with the internals of the Kernel that by using them you are forming a derivative work of the Kernel, as opposed to just using interfaces in the same manner (legally-speaking) as a userspace program.
Producing and distributing a module that uses these symbols under a non-GPL compatible license is already an infringement, because you have produced a derivative work and distributed it outside the license conditions.
If you recompile your Kernel to remove the restriction then you may be aiding the module developer in committing a copyright violation.
I’m not sure how much I buy this argument personally, but I have seen it advanced (I think on the LKML).
> I think both them [the lawyers Linus claims he spoke to] said that anybody who were to change a xyz_GPL to the non-GPL one in order to use it with a non-GPL module would almost immediately fall under the "willful infringement" thing, and that it would make it MUCH easier to get triple damages and/or injunctions, since they clearly knew about it.
Again, not endorsing this argument, just pointing out that some people (e.g. Linus) claim this isn’t permitted.
I’m not entirely sure why people think this comment is worth downvoting: I have been very clear that I don’t really buy this argument, but I thought it was interesting and relevant to point out Linus’s take on the matter.
..."you are forming a derivative work of the Kernel"
Which in the case of ZFS is obviously nonsense. ZFS was developed on Solaris and ported to many other OSes. Its certainly not a derivative work of the linux kernel. This is a case of the linux kernel devs being bullies, and trying to make life harder for 3rd party modules.
If they can claim copyright violation for using a GPL-only symbol which didn't used to be GPL-only, then I think ZFS devs can claim an antitrust violation for locking them out of the kernel. Both legal concepts are absurd..
> This is a case of the linux kernel devs being bullies, and trying to make life harder for 3rd party modules.
I’m inclined to agree, but the fact that ZFS was developed on Solaris and ported to Linux is irrelevant in my opinion: the specific Kernel module using the GPL symbols would be the derivative work, not ZFS as a concept.
Your point about symbols being retroactively made GPL-only is very interesting, and I think it really undermines the Kernel developers’ position.
Again, I don’t really buy Linus’s argument at all, but I think it’s relevant to the discussion, which is why I mentioned it.
> Producing and distributing a module that uses these symbols under a non-GPL compatible license is already an infringement
Producing the module is not, on it's own, an infringement. It's only if you distribute or publish the result that you get into trouble with the GPL since you're not in a position to distribute re-licensed ZFS source code[1].
Thus it should be perfectly fine to have a package which downloaded the ZFS code and compiled a kernel module for that machine, as long as the user did not distribute the compiled kernel module to others in any way.
It wouldn't. Moreover I can't see that there is any reason that redistribution of such a kernel would be against GPLv2, the licence under which the kernel is distributed.
TBF, so long as we are arguing from authority, Linus isn't a lawyer either, and has produced heresay ("I talked to some lawyers..."), but no attorney's opinion on the matter.
The reasonably charitable case for your parent comment is -- Linus suggests such linking might show "willful infringement" IF an out of tree module used these symbols, AND, as indicated by the parent, these changes were distributed together implicating the GPLv2 license's Sections 2 and 3.
Otherwise how would this ever be a problem? If I linked to a GPLv2 only interface in the privacy of my own home, never distributing the changes, what section of the license requires me to make available my changes? The GPLv2 gives me explicit permission to modify the sources?
> TBF, so long as we are arguing from authority, Linus isn't a lawyer either, and has produced heresay ("I talked to some lawyers..."), but no attorney's opinion on the matter.
Yes, that’s essentially a rephrasing of my comment that you replied to.
Then perhaps I misunderstood your comment? It went pretty hard at a guy/gal who was simply stating the obvious -- permission to modify sources is already given within the GPLv2 itself. Imagine this colloquy --
Linux devs: "We've created a GPL only interface. Here are the sources."
Downstream user: "Okay I've modified these symbols to be not be GPL only anymore."
Linux devs: "You can't do that!"
Downstream user: "But you've given me permission to modify the sources in your license?!"
Certainly a copyright holder can give special additional permission to use software in contravention of the express terms of the license. The only problem is getting the copyright holders agreement to do so. My understanding of what you have argued is -- a copyright holder can place additional restrictions on the use and modification of software in contravention of the express terms of the license hidden within the software itself. You state:
The legal status of this is uncertain, since a number of questions naturally arise:
1. Is it acceptable to mark a Kernel module as a GPL module (this is done via a macro in the source) but release it under a license that is not GPL-compatible?
2. Is it acceptable to recompile the Kernel to remove this restriction?
As far as I know neither of these have ever been tested, and there are differing opinions.
This line of thought is problematic for several reasons. This most salient of which is -- this is exact argument used against ZFS in the kernel: that the CDDL's additional terms/restrictions are incompatible with the GPLv2.
Imagine again --
Linux devs: "We've created a kernel module that can't be used by Russians invading Ukraine."
Other kernel devs, estates of deceased developers, etc.: "But our understanding was that all our contributed sources would be available under the GPLv2, not some weird hybrid which can be modified willy nilly with new restrictions by any future dev."
When someone says -- "Here is your license to use my software," it is reasonable to believe you can take them at their word, and there aren't additional license restrictions lurking somewhere else.
> Clearly the sync between devices works, so they have solved this problem.
Presumably they don't use CSV to sync, they're using a saner json/etc. data structure that they're not letting us export ourselves. Seriously, being limited to CSV in this day and age...
Where do you get this kind of optimism? I would think time + rejected entry into the country would teach travellers to more vigilantly defer to the TSA.
In the chaos post 911 there was a lot of resources poured into the new Homeland Security and TSA agencies, as well as huge expectations. Rights of travelers weren’t the first priority, it was all about safety and national security. Only by the passage of time were they able to moderate their practices and adopt reasonable policies for treating travelers, especially edge cases. That and lawsuits. When the courts get involved, things tend to change rather quickly relative to lodging complaints.
I think this is a general dynamic. A familiar metaphor might be that of a startup’s journey from idea to stability at scale. It takes time and mistakes to figure out how to balance stakeholders’s interests.
I also think tech/eng UX practices have had such a cultural impact that customer experience and usability are more top of mind for decision makers and customers alike. Concurrently, ubiquitous pocket cameras and video distribution have held all kinds of law enforcement more accountable, including TSA. Commerce drives this. A sharp decline in flight travel due to draconian enforcement would be railed against by business and government interests alike. With some of the safety and security concerns waning, the pressure is on TSA to get out of the way.
I wouldn’t call any of that optimism per se, but I see how it could be perceived that way. Travelers most definitely did get taught to fear the TSA and it’s cost us tremendously. That fear is well-earned, and the panopticon + excessive policing powers still need to be corrected on a legislative level.
If you read the document again (?) maybe you'll see it's not about proving a negative. Instead, it's a standard of due care. Did you check whether using some particular tool illegally discriminates and document that consideration? From the document itself:
"Clarifies that, when designing or choosing technological tools, employers must consider how their tools could impact different disabilities;
Explains employers’ obligations under the ADA when using algorithmic decision-making tools, including when an employer must provide a reasonable accommodation;"
If I build an unsafe boiler, and gift it to you, and then it explodes and kills you - am I not liable because it was a gift and not a sale? Can I disclaim away any liability and "fitness for purpose" when I gift you the boiler?
ETA: the first couple of Google results say that no, product liability can't be disclaimed away - particularly when there is no contract or opportunity for bargaining. I am very much not a lawyer but this sounds correct to me (i.e. this is what the law is).
Your second link mentions sellers avoiding liability by selling product (that can be inspected in stores) "as-is". It could be argued that open source falls in the same category. You have an opportunity to inspect it before using and if you don't like it or don't feel qualified to pass judgement, no one is forcing you to use it.
The second link doesn't mention "as-is", the first one does. I'll assume that's what you meant. It says,
> Though manufacturers cannot so easily escape liability, sellers can escape liability by informing the customer before the purchase that a product must be taken "as-is,” which means how the product was found when it was purchased in-store. “As-is” works because the buyer has an opportunity to inspect the product and decide whether to buy it given its condition.
On that analogy, Github and RedHat aren't liable, but the original author of the software still is.
Regardless, the vulnerability is in the driver, not the CPU / microcode. Also in the WHQL process that signed such a 'fake' driver. Until the signature is revoked, it might be possible for an attacker to manually install the signed driver on other system configurations too.
You could say that any non-register memory access "blocks" but I feel that's needlessly confusing. Normal async code doesn't "block" in any relevant sense when it accesses the heap.