18 ms·
No nuances, just buggy code (was: related to Spinlock implementation)
- dang 7y agoRelated and recent: https://news.ycombinator.com/item?id=21919988 https://news.ycombinator.com/item?id=21919988 https://news.ycombinator.com/item?id=21955234 https://news.ycombinator.com/item?id=21955234
- cbarrick 7y agoThat first post is what Linus is responding to. The second post was really educational for me.
- sfgweilr4f 7y agosummary: Don't roll your own (spin) locking unless you really want to go down the rabbit hole. Linus thinks locking is a PITA and there be dragons. You have been warned.
- AYBABTME 7y ago_spin_ locking in particular
- PudgePacket 7y agoThey mention all locking > But don't write your own. Find somebody else that wrote one, and spent the decades actually tuning it and making it work. > Because you should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself - we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times). > There's a reason why you can find decades of academic papers on locking. Really. It's hard.
- taneq 7y agoSynchronization primitives are another thing along with dates and names and postcodes and unicode text editing: "Stuff you should avoid writing yourself if at all possible because they are incredibly fiddly to get absolutely right."
- hermitdev 7y agoAdd to that lock-free concurrent data structures.
- sfgweilr4f 7y agoThey all share that quality of "its straightforward, anyone can just look up the details and make it"... a month later you're still chasing some detail as some bureaucrat has added some new wrinkle. Now a rule change elsewhere has happened... it never ends. Plus each locality has its own history and the details all make sense for them but not necessarily for you and your codebase. Simple to implement but the complexity is getting it right for every case. None of it is easy.
- skunkworker 7y agoAlso add crypto algorithms to that. I know of too many people that thought, a SHA-512 is fine for passwords. /facepalm
- shandor 7y agoLike all the mainstream Linux distributions out there? But seriously, IIRC they do 5000 rounds by default, but I've been wondering for a few years how is it that supporting nothing better than SHA512 for the whole /etc/shadow -based system is still ok? How come there's still no support for scrypt or bcrypt?
- tialaramex 7y agoBecause it actually hardly matters at all? It's salted enough that it's not amenable to a time-space optimisation and it's pessimised enough to make trivial attacks impractical so bad guys who have the database will resort to brute force on individual passwords. At which point either you have a good password and they can't guess it or you don't. Fancier schemes are about the margin, can we make it too expensive to brute force say 8 alphanumerics? But you don't need to live in the margins and you shouldn't.
- rcurry 7y agoI know it's a typo, but still - I'm adding "schenario" to my list of good words to use when describing screwy code.
- JauntyHatAngle 7y agoIsn't it a joke contraction about schedule + scenario?
- rcurry 7y agoYou’re right, that makes it even better.
- dhsysusbsjsi 7y agoCan anybody explain the advantages or otherwise of Apple’s libdispatch for locking? I understand there’s Linux support now also. Is this something you would use outside of Apple ecosystem? https://developer.apple.com/documentation/dispatch/dispatch_semaphore?language=objc https://developer.apple.com/documentation/dispatch/dispatch_...
- asveikau 7y agoQuoting from the link: > A dispatch semaphore is an efficient implementation of a traditional counting semaphore. Dispatch semaphores call down to the kernel only when the calling thread needs to be blocked. If the calling semaphore does not need to block, no kernel call is made. This sounds like the same optimization that futex(2) makes for pthread mutex on Linux. So while a naive semaphore might enter the kernel 100% of the time, this one does so only when there is actual waiting to do. It would seem to me that sem_wait() does similar on glibc so Linux probably performs similarly with the standard POSIX semaphore: > https://github.com/bminor/glibc/blob/master/nptl/sem_wait.c https://github.com/bminor/glibc/blob/master/nptl/sem_wait.c mirrored from here: > https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=nptl/sem_wait.c;h=171716fdbce243d64a9da46acdc4dc77d81921b4;hb=HEAD https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=n...
- lilyball 7y agoDon't use dispatch semaphores where mutexes (or dispatch queues) would suffice. Apple platforms have a QOS mechanism that donates priority from higher-QOS threads to lower ones when they're waiting on locks that the higher-QOS thread owns, but with semaphores the system doesn't know what thread "owns" the semaphore and so it can't donate priority. Mutexes (and dispatch queues), including os_unfair_lock, will donate priority accordingly. Which is to say, dispatch semaphores shouldn't be used if you're initializing them with a value of 1, you should only use them if you have an actual pool of resources you're protecting.
- gpderetta 7y agoSemaphores are for signaling (sames a condition variables, events) while mutexes are for mutual exclusion. Technically you can also use semaphores for mutual exclusion (a mutex can be thought as a binary semaphore) but you really shouldn't.
- dpc_pw 7y agoI highly recommend reading the whole thread, especially all Torvald's responses.
- unixhero 7y agoMaybe I'm not adding much as contribution here; but I am of the point of view that Torvald's responses are always worth reading through.
- mntmoss 7y agoReinterpreted in my own words: Usercode spinlocking is not legible to the kernel. Therefore anytime you attempt it you are in the situation of fighting the scheduler, and given that even the kernel devs are constantly challenged by the problem of making appropriate scheduling tradeoffs, you will lose.
- 29athrowaway 7y agoCompared to other occassions, Linus showed some restrain this time.
- JackFr 7y agoBy Linus standards, positively collegial.
- ncmncm 7y agoHe didn't say "idiotic", not even once. Getting old.
- rixed 7y agoBullying would not be complete without passive admirers, I guess.
- 29athrowaway 7y agoSome gems: https://lkml.org/lkml/2008/7/15/296 https://lkml.org/lkml/2008/7/15/296 https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2015/6/23/657 https://lkml.org/lkml/2015/6/23/657
- aasasd 7y agoFirefox' Reader mode stripped out Linus' name at the beginning, so I didn't even realize it was him, until the end line.
- hart_russell 7y agoSome people might call his rhetoric abusive. I think it’s well deserved though love.
- ww520 7y agoDamn, Linus really knows his stuff, getting to the heart of the matter right the way - measuring user mode locking time is futile, as the OS scheduler can preemptively put the locking thread to sleep for arbitrary time. The OP ended up measuring how quickly the scheduler woke up the locking thread, thus measuring the wrong thing.
- Flicki 7y agoYou think the OP doesn't know this? Common. Linus was making straw men arguments as he seems to commonly do. The measurements still show Windows trouncing Linux in reponsiveness
- sudosysgen 7y agoYes, because the benchmark was using spinlocks incorrectly. There are many places where the Linux scheduler is more responsive, even in gaming, exactly because of what makes spinlocks inefficient. The Ryzen scheduler debacle comes to mind.
- asdfasgasdgasdg 7y agoOk, so how you would write this (at least the first section, explaining the error) constructively could be much shorter. "The author of that post has a common misconception, which is that spin locks are a fast drop in replacement for uncontended mutexes. They aren't. You can only use them well when you know you won't be descheduled, like we do in the kernel. In a generic userspace program, you don't have that knowledge. The possibility of your time slice ending skews all the time measurements, for example." Boom. Roughly the same message. Most people will get the same amount of edification from this as Linus' original letter. You could go in to more detail if you want but it's not really necessary. Smart people will figure it out if you just point out the general shape of the error. No need for calling code "garbage."
- csande17 7y agoI personally really appreciated the additional details in Linus's version. When I read your version, I learn that spin locks are not a drop-in replacement for uncontested mutexes. That's great, except that I don't really know for sure what either of those terms mean, and also I didn't gain any knowledge that doesn't relate to this specific situation. It also wasn't super convincing -- I could just as easily see someone post a reply saying "well actually spin locks ARE a drop-in something something mutex" and I'd have no way to tell who was right. Linus, on the other hand, told me about the mechanism by which the problem happens. I learned about how the scheduler sees spin-locks' loops, and that the main advantage of "real" mutexes is that the scheduler knows who's waiting on what. I also wouldn't necessarily have realized the "take clock measurement, then get descheduled before you release the lock" issue if he hadn't called it out specifically. Sure, I guess "garbage" comes off a little mean, but "the author has a common misconception" almost sounds more passive-aggressive to me.
- simias 7y agoThe first section of Linus's answer reads really rough to me and almost made me stop reading, imagining that it was going to be yet an other entry in the "Linus bullies some poor coder into submission by insulting them until they just stop responding" which is a shame because there's a lot of interesting content after that. I guess I invite the people who had the same knee-jerk reaction I had to give the post a 2nd chance and power through Linus' unnecessarily harsh tone to get to the good stuff. >Sure, I guess "garbage" comes off a little mean, but "the author has a common misconception" almost sounds more passive-aggressive to me. The latter might be slightly passive-aggressive (although it doesn't have to be), the former is simply aggressive-aggressive.
- fierarul 7y agoWhat I'm reading from here: > Or at least be aware of it, and have some virtualization-aware paravirtualized spinlock so that you can tell the hypervisor that "hey, don't do that to me right now, I'm in a critical region". is that your kernel could be hypervisor aware? Could you compile a kernel that flags itself as being in a critical region all the time? Would that give you a whole CPU indefinitely?
- aasasd 7y ago> is that your kernel could be hypervisor aware? I mean, paravirtualization is precisely when a kernel communicates with the hypervisor. Dunno however how scheduling factors into it—I was under the impression that VMs are treated much like userland programs. I.e. would similarly be scheduled off sooner or later.
- unilynx 7y agoWould it then be useful to have a lock that only spins if the current remaining timeslice looks long enough?
- thenewnewguy 7y agoI don't belive the kernel exposes timeslice information to userspace in linux. Edit: Also, you'd have to predict how long a spinlock was going to spin for in advance.
- rixed 7y agoI am under the impression that this long, vocal post, consisting of many assertions and no measurements, would have been judged less favorably if it were not from Linus. I used to agree with many of Linus rants, but not this time though. The gist of the reply, as I understand it, is that the benchmark is measuring random spikes while the spinning thread is scheduled away. But the benchmark clearly stated that they are using one thread per core and that the host was otherwise idle. It could be that, still, some random task pops up once in a while, replacing the very thread that has the lock. But then, rather than calling the whole benchmark garbage I think it'd be more fair to just ask for it being rerun with, say, two free cores. Or use auditd to detect and invalidate those runs. Linus also calling everything random sounds annoyingly slopy: varrying the scheduler or the OS led to significantly different measurements. Maybe the explanation for those differences are wrong but the measurements are certainly not random.
- baq 7y agoThe final conclusion after throwing the blog author into the dumpster (which I’d be more polite about, but that’s Linus for you) is that unless you spent your whole career researching and implementing locks, you should use something that was created by somebody who did. Which is some damn good advice if you ask me (disclaimer: I didn’t research or implement any production-grade locking primitives.)
- rixed 7y agoI don't know why you felt necessary to rephrase the final conclusion (I've read it - notice, by the way, that it was also the conclusion of the original benchmark) nor to introduce Torvalds' style (I mentioned I'm familiar with it). Anyway, I do not think that a forum that calls itself "hacker news" should adhere to that dogma that any topic claimed by an authority to be complex should never be re-implemented on first principles. And I doubt the young Linus would have paid much attention to that kind of advice when he started developing a new operating system. Personally, the conclusion I take from that thread is simpler: On a situation when N threads are runnable on N cores with N-1 calling sched_yield(), one must not expect the Nth thread never to be scheduled out for a whole slice on Linux (for some or all of the reasons listed by Linus, none of which seems to address that exact case unfortunately).
- OskarS 7y agoThis all sounds very good, and I grant that Linus knows what he's talking about, but didn't this whole thing start with a bunch of game developers that noticed massive stalls when porting games to Google Stadia? Stalls that, presumably, didn't happen on other platforms (Windows and PlayStation, using a variant of FreeBSD). If these kinds of spinlocks are so fundamentally misguided, why do they only cause problems on Linux?
- baq 7y agoGame developers running their software that requires a system tuned for interactive latencies get burned by systems optimized for throughput, proceed to blame the system. I’m more for polite passive aggressive suggestion of incompetence instead of in your face blaming, otherwise the response was quite on point. On the plus side the original author now has plenty to read about and us here get to learn interesting things by proxy.
- draw_down 7y ago> I’m more for polite passive aggressive suggestion of incompetence instead of in your face blaming Good grief.
- forrestthewoods 7y agoMoral of the story... don’t ship games on Linux?
- doctorpangloss 7y agoThe irony is that because of Android, another platform Google owns besides Stadia, Linux is already the world’s biggest gaming platform.
- mrtksn 7y agoHow much Linux is android though? Does Android feedback into Linux? This argument about Linux being the most popular consumer OS or Gaming platform thanks to Android sounds like Syria taking credit for the iPhone because of Steve Jobs being a Syrian by bloodline. "You know, although we are consumed by sectarian fights and iron-fisted leaders that will crush anyone having opinions, It is important to note that worlds one of the worlds most successful contemporary technology companies is actually Syrian".
- Dylan16807 7y agoSo, ignoring whether the code is good or not, what's the correct way to do this benchmark? Is there any way measure the timers atomically, or to prevent your code from getting preempted in a tiny section, or have the kernel notify you if it gets preempted? Maybe something can be hacked in with transactional memory infrastructure?
- MertsA 7y agoI'm sure there's probably some succinct way to do so using perf_event in C but off the top of my head instead of just looking at the wall clock in isolation you could also compare it to the task clock to see if there was any pause of execution. Just make sure that you're actually including the time spent in the kernel during whatever syscalls you're trying to include but IIRC that's just a flag that you can set when opening the event.
- imtringued 7y agoRealtime scheduling. It only makes sense for a tiny process/thread that is carefully written to avoid the bad effects of no preemption.
- Dylan16807 7y agoThis benchmark runs 32 software threads on a machine with 8 CPU threads. Getting preempted a lot is a major part of what's being measured. But samples that got preempted at exactly the wrong spot need to be filtered out, which is tricky.
- alexdowad 7y agoJust searching the web to see if anyone has published a list of Linus Torvalds' best technical posts -- those where he shares his extensive knowledge of system programming, CPU architecture, etc. With all the years he has been posting on newsgroups, there should be a lot more "gold" out there. Unfortunately, it seems that most people who write about Linus on the web are more interested in his worst posts -- where he has slung insults and profanity with no valuable technical insights.
- kstenerud 7y agoIt's important to read Malte's response to Linus: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189747 https://www.realworldtech.com/forum/?threadid=189711&curpost... Followed by Linus response to Malte: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189752 https://www.realworldtech.com/forum/?threadid=189711&curpost... The long and the short of it: - It's nearly impossible to make meaningful benchmarks for this because reality will almost always be different and more complicated - Calling sched_yield() is almost always a mistake - Any scheduling optimization is probably a waste of time because either your running env will change, or the kernel will change, or someone else's optimizations will clash with yours. - Even with decades of research into locking, everyone (including the experts) continually gets it wrong. - If you're not running a specialized embedded setup where you control all of the running processes and other such variables, just use sleep locks and call it a day.
- sillysaurusx 7y agoWhy is calling sched_yield() a mistake? What's the correct way to yield CPU without calling sleep?
- colonwqbang 7y agoIt's explained in the linked post. Why don't you want to call sleep?
- dilyevsky 7y agoI remember someone at google proposed new syscall to voluntarily give up time slice from one process to another which they intended to use for co-routines in c/c++ (which they used internationally and boy was it awesome) but it was not accepted. Sure would be nice for this case as well.
- weinzierl 7y ago> Pretty much every time we picked an unfair - but fast - locking model in the kernel, we ended up regretting it eventually, and had to add fairness. This is an interesting quote from Linus. I always thought that fairness was for the desktop and Linux had latency issues sometimes because it historically put the "big-iron" first. Now this quote makes it seem that fairness is a good thing for the server as well and the preceding paragraphs hint that supposed latency issues are just a natural consequence of the trade off between throughput and latency.
- ww520 7y agoA simple reasoning on why spinlock is slower than mutex in a heavily contested situation. A thread (S1) attempting to acquire a spinlock will busy looping to hog all of its time slice, preventing other threads (S2) from utilizing the CPU to free the lock. S1: [**busy spinning**][..waiting........][**lock & run*****] S2: [..waiting........][**run & unlock***][..waiting........] A thread (M1) attempting to acquire a mutex will sleep to give up its time slice, letting other threads (M2) to utilize the CPU and thus have a chance to free the lock. The given up time slice can be very substantial, leading to much better performance. M1: [sleep][..waiting........][**lock & run*****] M2: [.....][**run & unlock***][..waiting........] If one really really wants to use spinlock, the way to use it correctly is to boost the priority of the thread holding the lock to make sure it got priority to run over all else, so that it can finish its work quickly and release the lock. S1: lower priority [..waiting........][**lock & run*****] higher priority S2: higher priority [**run & unlock***] lower priority [..waiting........] I assume the benchmark and the user-mode spinlock doesn't do that, and thus has the measured problem. OS/kernel would have a better idea to raise and lower priority with spinlock than user-mode code.
- imtringued 7y ago> If one really really wants to use spinlock You will also have to make sure that your application threads are pinned to specific cores and that the number of threads is smaller than the number of cores because you want to keep one thread free to run non critical code. Spinlocks are like full plate armor. Very effective but incredibly cumbersome to use.
- crustycoder 7y agoI think Linus was incredibly polite and helpful, I certainly wouldn't have been anything like as tolerant. I had barely got into the original article before muttering "What about the scheduler & preemption, you idiot" to myself. Anyone with any sort of OS background has all the points that Linus made drummed in them from the get-go, it's a shame the author apparently didn't do any even basic background reading. All the stuff Linus patiently explained has been well-understood for literally decades. Old farts myself often bemoan the fact that fewer and fewer people seem to understand how computers actually work. It's bad enough that the author didn't understand the consequences of what he was doing, what's really depressing is that so many other people thought he actually had a point :-(
- mindentropy 7y agoNot sure why you have been downvoted but even I too was gnashing my teeth. Also introducing unwanted complexity of cache coherence etc and linking irrelevant concepts to support his argument. Sigh! These are all well understood by RTOS firmware and Linux driver people. The author, if he has not understood the problem or what is happening should at least use the mailing lists, read on documentation etc to understand how things work rather than write a blog post blaming the kernel people assuming they have not thought enough while designing.
- crustycoder 7y agoPersonally I'm not that surprised, criticism of any type is no longer PC. I think you nailed it with "well understood" - exactly so, anyone with an interest in this area knows about this stuff. It would have been fine if the post was along the lines of "I've observed XXX, there's clearly something strange going on" but as you say there was a misinformed leap to blame the kernel devs. That's not OK as bearing in mind the exposure the post got, there's a real danger that the misinformation it contains will become "accepted knowledge".
- crustycoder 7y agoThe sorts of problems inherent in userspace spinlocks are even called out in the Linux manpages, shame the article's author didn't bother to look: http://man7.org/linux/man-pages/man3/pthread_spin_init.3.html#NOTES http://man7.org/linux/man-pages/man3/pthread_spin_init.3.htm... Spin locks should be employed in conjunction with real-time scheduling policies (SCHED_FIFO, or possibly SCHED_RR). Use of spin locks with nondeterministic scheduling policies such as SCHED_OTHER probably indicates a design mistake. The problem is that if a thread operating under such a policy is scheduled off the CPU while it holds a spin lock, then other threads will waste time spinning on the lock until the lock holder is once more rescheduled and releases the lock. If threads create a deadlock situation while employing spin locks, those threads will spin forever consuming CPU time. User-space spin locks are not applicable as a general locking solution. They are, by definition, prone to priority inversion and unbounded spin times. A programmer using spin locks must be exceptionally careful not only in the code, but also in terms of system configuration, thread placement, and priority assignment.
- isodude 7y agoThere is a lot to unfold in the manpages. See lsof. A lesson for us all to actually look at the documentation. But I find that it's easy to miss to read them for some reason, we rather read one SO response instead (that eventually lead straight back to the manpage). Which is interesting in itself. Must we invent the wheel all the time rather than using the shipped documentation? Or am I alone in falling in that trap?
- Avamander 7y ago> Must we invent the wheel all the time rather than using the shipped documentation? I think it's a matter of accessibility, it is a reasonable assumption that someone writing code wants to consult the entire internet thus if the relevant manpages are not indexed by search engines then they won't find the documentation. Doing minimal SEO and publishing sitemaps is quite important. I've seen way too many institutions wondering the same question "Why are people reinventing the wheel?" when the answer is that simply having a website is not enough to be reachable.
- g051051 7y agoNote to self: do not disrespect the Linux scheduler. This reminds me of how Sam Kinison dealt with hecklers. He'd stop, look at the heckler, and say "The last thing you want is my complete and undivided f*ing attention". And then eviscerate them.
- bsaul 7y agoSidenote : just had a random thought reading linus talking about not fighting the scheduler: are there common theoretical problems between a garbage collector / memory allocator (aka : automatic handling of memory resource) and a scheduler (aka : automatic handling of cpu resource) ? Could there be some kind of super abstraction solving common issues to both problem in a more mathematical approach ?
- imtringued 7y agoOnce your spinlock has exhausted it's timeslice it has lost. The point of spinlocks is sub-microsecond latency but when you're way past that you can only lose if you're not telling the OS that your lock is still spinning.
- ChrisMarshallNY 7y agoAh, I see that Linus hasn't strayed too far from his inner curmudgeon... Even though he can be pithy, he's usually hitting the nail squarely on the head. I don't play at this level of things, but it's a fascinating conversation. Even if we don't write low-level code, it doesn't hurt at all to understand what's going on behind the curtain.
- micimize 7y agoIt's kind of disturbing to me that so many people in the comments are defending Linus's tone here. He writes like petulant child. Its wildly unprofessional, and only makes it harder to follow what follow what he's trying to say. I'm really glad I'm not actively involved in any community he's a part of.
- jturpin 7y agoThere's always a surge in people who defend and even mimic Linus's tone whenever a post like this gets popular. People love being that smart guy who gets to feels entitled to act obnoxiously because they're right - at least about one small thing. Reminds me of _that_ group in High School. It sounds like there was an expectation that Linux should support something that it doesn't, and whether it _should_ support it is up for debate. Totally agree about Linus's involvement in any communities. I assume part of it is that he feels personally attacked when something about Linux is challenged.
- SXX 7y ago> It sounds like there was an expectation that Linux should support something that it doesn't, and whether it _should_ support it is up for debate. You really didn't paid attention to what being discussed. Someone started discussion on how bad Linux kernel is based on incorrect data generated by badly written code.
- whack 7y agoThe common refrain I hear is that "we're engineers. We don't have time for people's 'feelings' and 'emotions'". Ironically, the controversial things that Linus says are exactly those phrases that inject unnecessary emotions into a technical discussion. Take away all the emotionally charged words, replace them with purely factual descriptions or observations, and you would have something that better resembles the principles that Linus's defenders claim to be endorsing. Ironically, if a manager or CEO or VC or politician used similar language, they would be attacked by the same people for being abusive and elitist. But when an alpha-programmer does it, it is somehow ok. I've learnt so much from reading both the original blog post, and also the resulting conversation with Linus. The technical work Linus has done and is doing, is fantastic and to be commended. I just wish he followed through on his earlier desire to change his communication style.
- Traster 7y agoNice to see, once again, Linus driving reasonable people out of the open source community. I'm so glad I don't have to work with people like that. No, technical knowledge does not qualify someone to act like an asshole.
- eric234223 7y agoWhere is the link to the origin of this discussion ? From the realworldtech.com looks this is the first post https://www.realworldtech.com/forum/?threadid=189711&curpostid=189711 https://www.realworldtech.com/forum/?threadid=189711&curpost... . But that post is already an reply to something else's post.
- derimagia 7y agohttps://www.realworldtech.com/forum/?threadid=189711 https://www.realworldtech.com/forum/?threadid=189711 is the original post (what you linked). The quote is from https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ https://probablydance.com/2019/12/30/measuring-mutexes-spinl...
- eric234223 7y agoIs this your interpretation or you know it for sure. Sorry for being skeptical. I am having hard time believing Linus Torvalds would have an account on realworldtech.com. I have never heard of this site before. The only place i have seen Linus reply is in the kernel mailing lists. Also is this email id torvalds.delete@this.linux-foundation.org ? How do we even know the reply is from linus.
- hansdieter1337 7y agoMaybe Linus should update the docs: https://www.kernel.org/doc/htmldocs/kernel-locking/locks.html https://www.kernel.org/doc/htmldocs/kernel-locking/locks.htm... I think it would be useful to add a warning there.