Skip to content

Latest commit

 

History

History
755 lines (573 loc) · 36.7 KB

2021-07-22.md

File metadata and controls

755 lines (573 loc) · 36.7 KB

< 2021-07-22 >

3,039,951 events, 1,511,787 push events, 2,414,408 commit messages, 181,200,781 characters

Thursday 2021-07-22 02:16:19 by noahfkennedy

Fixing stupid fucking git logic I hope this works god please


Thursday 2021-07-22 03:31:22 by Harald Hope

New version! Fixes!! Bug fixes! More bug fixes!! Cleanups!

Most of these were exposed by issue #251 filed by LukasNickel, then further revealed via his debugger data set, which showed two more bugs. Well, bugs, changed syntaxes, same difference to end users.


KNOWN ISSUES:

  1. Work is ongoing to add btrfs support to -R (similar to softraid or zfs), basic stubs and debuggers added, but reporting tools are not as robust (and often require sudo/root for reasons that escape me) as I would have hoped, so it's slow. One of these days... Normally would not release with working stubs, but there were enough real issues/bugs to warrant just getting 3.3.06 out the door, then going on with the btrfs feature for -R. But so far I view the reporting tools as inadequate, unfortunately.

BUGS:

  1. As initially discovered in issue #251 there are alternate syntaxes which had never been seen before for remote mounts, fuse mounts, etc. In this case, it was fuse.sshfs that was not removed from the Disk total:... used: leading to silly 1000+% used percentage. Note that while technically inxi could try to be clever about reporting impossible percentages, so far those have led to bugs getting reported, then fixed, so I think it worth leaving it as is.

  2. When --swap/-j is used with no other arguments, failed to show uuid or label. Discovered this while testing fix 2.

  3. Bug which is not a bug but will appear as such to users, nvme temps were failing in -Dx due to a change in how those values are located in /sys. See fix


FIXES:

  1. Going along with Bug 1, and considering that only in 3.3.05 was the nfs4 remote fs failure to identify/exclude, the entire section involving remote/ fuse etc file systems was refactored, and extended to add many more previously non-handled remote and fuse type file systems. Significant extension of known remote filesystem types, distributed file systems, overlay file systems, all to try to avoid having more distributed/remote/fuse file system issues. Also added test to support fuse. or fuseblk. type prefixes for any of these. Hopefully there will be fewer issues related to distributed and remote and overlay type file systems in the future.

  2. Made all label/uuid triggers global, that is, -ol shows unmounted with labels, -ju shows swap with uuid, and so on. This may require a bit more tweaks to get exactly right, but in general, this is a purely cosmetic fix, that is, try not to show label/uuid for partition/mounts that probably can't have those values.

  3. There was a change in the way nvme /sys temperature paths were handled, an actually understandable, albeit as always annoying, one, because inxi actually had to do a sort of convoluted hack to get the nvme block devices temperatore paths before, now that hack is not required for newer kernels (5.12+), though for kernels that had the old paths (5,8, 5.9 at least, don't know when paths changed) left in the old method. Now tests are more granular, and inxi should find temperatures regardless of which method is used for nvme and sd type drives.

  4. Another somewhat irksome random change, again, understandable since the new syntax is more consistent in output than the previous one, but still breaks all existing parsers that use the changed field names. Lsblk did NOT change the -o input field names, but DID change the output field names, which broke the internal inxi parser, and led to null lsblk data.

Changes were - or : separators in input values are output as _ always. that is, MAJ:MIN becomes MAJ_MIN. Also corrected the debugger lsblk to use the same output fields for -P -o as the actual lsblk parser uses internally so these failures can be spotted more readily, as it was, it was literally only because someone submitted the debugger dataset, and was running lsblk 2.37, where I believe this behavior change happened. Solution was to just use regex patterns instead, [:_-], in the parser. Big fear now is that they will randomly stop supporting the -o input field names that contain - or : and change that too without any real warning or deprecation notice.


ENHANCEMENTS:

  1. Going with bug and fix 1, added avfs, afs, archivemount, avfs, ceph, gfs, glusterfs, gmailfs, hdfs, ipfs, kosmos/kfs, lafs, mergerfs, mhddfs, moosefs, ocfs, openafs, orangefs, overlayfs, pvfs, s3fs, sheepdog, vmfs, and several others to the exclude list for disk used and show label/uuids for partitions.

  2. A smattering of disk vendors added.


CHANGES:

  1. Going with fix 2, -l and -u no longer will trigger -P by default, now if -l or -u are used without -j, -o, -p, -P, an error will explain that you must use one of those together with -l or -u. This was the only way to get the -l and -u switches to turn off/on label/uuid reports in swap, unmounted, and partitions consistently. Triggering -P was really a legacy behavior from when the only options were -p or -P, and --swap and --unmounted did not exist. I found it increasingly odd that unmounted would show label/uuid always but partitions only with -l/-u.

  2. This was a pet peeve, sometimes field names just bug me (like 'Topology: did for CPU, now corrected to Info:), the Drive: rotation: was one such annoyance. I had recycled that to indicate SSD, which was a feature request, but that was always a sloppy solution, and made no sense, since SSD isn't a rotation speed.

Now it reports a much more logical:

ID-1:...... type: HDD rpm: 7200 or ID-1:...... type: SSD or ID-1:...... type: N/A

This also corresponds to the intended meaning much better. The HDD type was always present internally if rotation speed is detected, but was not used. Now will also show type: N/A if reliable type detection failed, which will also be more consistent.


DOCUMENTATION:

  1. Brought most of inxi.changelog (this file) into a consistent state, re whitespaces, readability, consistent use of various header / section names. Ideally while I don't expect anyone to ever sit down and read this changelog, it will be now much easier to scan to find whatever interests you. This change goes along with ongoing changes in docs to in general try to be usually 80 columns wide.

  2. inxi-resources.txt, inxi-data.txt are updated with more raid, partition, file system values and data to go along with bug, fix, enhancement 1.

  3. Man and help updated to indicate -u and -l no longer trigger -P by default.


CODE:

  1. Ongoing refactors, bringing the codebase to the point that matches current coding styles. Removed remainder of whitespaces in conditions and for/while loops, for example:

if ( condition ) { becomes: if (condition){ and if ( ( test set 1 ) && ( test set 2 ) ) { becomes: if ((test set 1) && (test set 2)){

and so on. That dropped over 2 KiB of whitespaces. This went along with fixes that have been ongoing to change to this whitespace use style, but previously it was only being done when that situation was hit in a local block, now it's been completed globally.

This continues the style refactor that has been ongoing for a while now, to bring inxi into a consistent state, since when it started, it was more pressing to get the bash/gawk mess translated to Perl than it was to get the Perl itself to be as good/consistent as possible, so now those issues are being slowly unravelled, and hopefully will set inxi on course for its next 10 years.

It was starting to get annoying, because some parts of inxi used those spaces, and all newer ones didn't in general. Now it's one behavior throughout the whole program file.

  1. Refactored the entire fs exclude for disk used data, and integrated those values into a global tool that is used either to exclude file systems from disk used totals, or to not show uuid/labels for the excluded remote/distributed/overlay type file systems, which in general don't have uuid or labels.

Thursday 2021-07-22 03:45:22 by Hanna

with tears of frustration and joy I present to you a working version of character update, two outstanding items are the gender does not show as selected with the radio buttons and you can't see a button selected for the alignment


Thursday 2021-07-22 04:57:00 by niko-cher

==appdata/==

my first data base is done; -> in the testing file src/test/nikochir/minecode i have testing main file: --> i successfuly set up mongodb connection with uri string; --> added bson document messages into my collection; my java communication is getting better: -> to properly use java project manager and get all features of vscode java extension pack: --> use single workspaces, multi-root workspaces with multiple folders is pain; ---> i love pain so i found how to work with it; ----> use one folder in a workspace - add to java source path - make sure that java explorer can see your new project; ----> add another folder in the workspace - add to java source path - make sure that java explorer can see your new project; -> to use dependencies specified in .pom file: --> run from the terminal -> mvn dependency:copy-dependencies -f "path/to/project.pom"; ---> all dependency packages will be placed in the target folder; ---> using java explorer - add dependency - select the needed jar package; -> with all this stuff we can get complete syntax highlighting, prompts, intellisense and warnings; vscode launch configurations are finally used; -> just hit f5 and everything should be created by java extensions; --> there will be "Launch Main" configuration which runs each time; -> or we can use vscode-run&debug panel and run our own configuration/compound; -> by some reason they are very long; ==/appdata==


Thursday 2021-07-22 05:01:26 by Justin Blanchard

I love Fortran and hate Apple! (Hackily get Apple to work, TODO use the include_directories in the has_header tests, TODO any remotely reasonable way to discover the nested framework path.)


Thursday 2021-07-22 06:07:24 by reese_s

Cleaned up CSS to ship to a friend for her thoughts. Love to colab


Thursday 2021-07-22 06:34:13 by Sahasra

Update README.md

Hi All, this is Sahasra.R , and Im doing so fur so good!

My LOVE for my racket is BOUNDLESS, my 𝘱𝘢𝘴𝘴𝘪𝘰𝘯 for badminton is HAPPINESS

I love to read, explore new things,draw,skate, and most importantly, play sports!

Im a blue belt in teakwondo, and its my dream to be awarded the BLACK

Currently , Im learning french, coding -: Javascript,React-native,database,HTML and CSS

I would love to be a professional badminton player in my future.

I currently train at the Chaitananand Badminton Acadamy , recently moved to, from the JSK Acadamy.

Life is like a badminton match , If YOU wanna WIN , serve well, return well, play cool and most importantly a game always starts with 0-0 IE "Love All"

I have drawn insipiration from , Tai Tzu Ying, Akene Yamaguchi , Stephanos Tsitsipas, Lee Chong Wei. I will always worship Novac Djokovic and PV Sindhu as my gods.Bcuz although I love Badminton, Im huge fan of Tennis, Football too!

The question isn’t who is going to let me; it’s who is going to stop me. YOU HAVE OPTIONS!


Thursday 2021-07-22 07:09:59 by Heitor SF

npm test gives the 100% a-ok, but Lint wont because the last function is too complex and it doesnt want any for loops. So yeah nah, fuck you Lint.


Thursday 2021-07-22 08:50:03 by twodft

Change License

You just DO WHAT THE FUCK YOU WANT TO.


Thursday 2021-07-22 10:17:24 by Colin Ian King

Add load average stressor, try to create insane load averages

Load averages are a meaningless metric of CPU loading. This stressor creates potentially thousands of low priority pthreads that spin on rescheduling yields and massively increase load average.

As Peter Zijlstra wrote in kernel/sched/loadavg.c

"This file contains the magic bits required to compute the global loadavg figure. Its a silly number but people think its important. We go through great pains to make it work on big machines and tickless kernels."

Signed-off-by: Colin Ian King [email protected]


Thursday 2021-07-22 10:49:54 by Ivo Anjo

RFC: Add Sorbet typechecker to dd-trace-rb

TL;DR

  • Minimal bootstrapping for now.
  • Type checking is optional. Default is no type checking for files without a magic comment. Should have minor impact on people that don't want to touch the type checking.
  • bundle exec srb tc runs the type checking.
  • I've enabled type checking during CI runs

What?

While not a replacement for all our tests and other tooling, a type checker is a nice extra line of defense for catching issues that we otherwise may have missed, such as #1602.

The Ruby ecosystem around type checking is still rather immature. You may have heard that Ruby 3 shipped "with type checking" but that's an oversimplification: it actually only shipped with a "language for describing types" and a "type analysis tool" (https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/). You may have noticed that nowhere in the previous sentence the words "type checker" were included.

So, Ruby 3 itself provides no type checker. In practice, there are two typecheckers in "wide" use for Ruby:

  • Steep, created by a Ruby core team member that also worked on manny of the other type-related bits that made it to Ruby 3 (but steep itself was not made part of Ruby)
  • Sorbet, a type checker in wide use at Stripe and Shopify

This RFC PR does a first pass at onboarding Sorbet to our codebase. There's a number of limitations on this "first pass", which I document below.

Why not Steep?

I've tried onboarding our codebase to steep, and gave up due to two big issues:

  1. Steep relies on the Ruby 3 rbs format, but unlike Sorbet, there doesn't seem to be any way of starting small on a mostly-untyped codebase without any .rbs files, and iterate from there. There are tools to generate skeleton .rbs files (the rbs gem has two different modes for it + the typeprof gem), but they had a hard time with ddtrace.

  2. There is currently little documentation for the type checking errors, once Steep does run. Google gave me ZERO hits on one of them (I guess it doesn't index the tool repository at least). And they're not all that easy to understand/fix, so what use is having a tool tell you "this is wrong", if then you're stuck with little help on something that may not even be a real issue but more likely a tool limitation?

For these reasons, I gave up on Steep (for this first iteration).

Working with Sorbet

Sorbet can be run with bundle exec srb tc (or bundle exec rake typecheck). There's also Language Server Protocol support, if your editor supports it.

The key thing to know about Sorbet is that allows file-level granularity for enabling type checks, see https://sorbet.org/docs/static#file-level-granularity-strictness-levels.

In practice, this means that at the top of each .rb file, we can provide a comment that controls the reporting of type checking errors for that file. The usual ones (described in the above link as well) are: # typed: ignore, # typed: false, # typed: true, # typed: strict, and # typed: strong.

In many cases, Sorbet can typecheck a file correctly with no extra type annotations, so we can start enjoying its checks (such as finding #1602) by just enabling it for our files. This can be done with the # typed: true, # typed: strict, # typed: strong modes (see the docs for details).

The # typed: false is the default for files with no comment. Thus, even newcomers into the codebase will not be forced to immediately deal with Sorbet for contributions, which given the current limitations of the tool, and level of maturity, I think is reasonable. (We can reconfigure this later, if needed). In this mode, Sorbet will only complain about syntax and missing constant errors.

Our codebase requires quite a few # typed: ignore because or dependencies that are pulled via appraisals and thus not seen/available to Sorbet (among other things that we do and that Sorbet) doesn't quite like. These files are completely ignored by Sorbet. (Note that if you then reference something on one of these files from another file, that file will not typecheck either, so "ignore" becomes somewhat contagious, and is best avoided if possible).

I've also added a CI step to run sorbet, which again follows the rules above so should be able to provide us with valuable insight without being an annoying source of build failures.

Limitations or "I thought the whole point of this was for us to

add type declarations to the code"?

Now we get to the more unfortunate part of the news: I think that for now we don't have great options for doing this.

Sorbet type annotations are supposed to be inline with the code, and work through the [sorbet-runtime] (https://rubygems.org/gems/sorbet-runtime) gem.

Unfortunately, as described on https://sorbet.org/docs/faq#what-platforms-does-sorbet-support:

The sorbet-runtime gem is currently only tested on Ruby 2.6 and Ruby 2.7. It is known to not support Ruby 2.4. Feel free to report runtime issues for any current or future Ruby version.

Thus, since we still want to support Ruby 2.1, that doesn't quite work for us. I thought we could perhaps have an empty replacement of the sorbet runtime gem, and it turns out that Shopify already tried and abandoned it. So, inline annotations seem to be out for us.

For Sorbet, that leaves us with only one other option: .rbi files. These are files that allow Sorbet to get type information for otherwise untyped code, and are the solution to having type information for many common libraries.

Unfortunately, using .rbi files for our own code is very error-prone, because Sorbet trusts .rbi files, and doesn't check them against the code. Thus, if we had a class A with method m declared both on our code, as well as on an .rbi file, and then we renamed m to n and forgot to update the .rbi, then Sorbet would not complain about it. Worse, if somewhere there was a call to A#m somewhere in the code, Sorbet would still think it was correct, while in reality it would break at run-time.

The future?

Because our usage of Sorbet is rather simple, we can at any point switch to Steep, or any other tool, or just disable it, if it's not providing value. So we are not locked at all into its usage.

Hopefully in the near future we'll find a way to add type declarations to our library without impact to our support matrix of older Rubies.

Even better, we could then ship those types to our customers, for them to check that they are using ddtrace APIs correctly!


Thursday 2021-07-22 12:12:37 by Beatrice

Race Ban Code Improvement [Not Modular... Yet?] (#282)

  • Initial Commit - Code Improvement, More Races
  • Added beefmen species id define (Sorry pucci I needed it early)
  • Condensed a 5 line fulp edit into one line, and added proper syntax
  • Added a global list of bannable species IDs and antagonist positions
  • Reworked species ban code so it isnt called on spec_life, and instead on_species_gain()
  • Removed My Testing If
  • Im a fucking idiot and left my testing if in the code
  • Fixing Ban Panel Code, Adding Comments
  • Adds necessary checks to make sure we are not adding ban info to the WRONG ban panel browser
  • Removed some unnecessary src references

Thursday 2021-07-22 12:23:17 by BatRastard

Per Game CHEATS should be good now ... (#14)

  • 1st Attempt - Per Game CHEAT

Name says it all. Haven't compiled nor tested this myself, but considering I well into my 6 pack of Coronas, shit's probably a tad broken! Got laundry to do now. Alas, the laundry room is a good stagger or three around the corner ... =}

  • Whoops!

belch

  • Attempt #2 Per Game CHEAT

Fixing a few things ...

  • Attempt #3 - More syntax fixes ...

I'll sober up here in a moment ...

  • Hooboy!

Getting there. Learning Git, too! Aaaand missing Mercurial!

  • Ugh ...

Bastard ...

  • Damn

Last try before bed ...

  • Piss on this shit ...

I can't figure out the problem with "supportbase.c" telling me my defines aren't defined and there's unterminated #ifdefs. Bullfuckingshit.

  • OPL: Fix errors introduced by Per-Game Cheat

Signed-off-by: Caio Oliveira [email protected]


Thursday 2021-07-22 12:43:41 by cheeseburger

Merge branch 'feature-complete-rewrite' of https://github.com/epikgamer696969/school-website into feature-complete-rewrite

Git is being a bitch ass motherfucker again


Thursday 2021-07-22 13:36:06 by Predo

Fixed a bunch of random shit i hate my entire life i want to die


Thursday 2021-07-22 14:12:34 by brachy84

GOD FUCKING DAMMIT. THIS ONE SHITTY METHOD. I SEARCHED HOURS TO FIGURE OUT WHY THE FUCK THE GAME STOPS. AAAAAAAAAHHHHHH


Thursday 2021-07-22 15:00:48 by Jethet

Changes & additions with remarks for Yogi, until Object built-in methods

I added a horizontal line to divide this section from Part 1. It is so much information that I think this will help when they have to scroll up and down.

I think it would be useful to tell them why the oops.js file is called like that. They do not know about OOP. If we do not discuss OOP in this project, then maybe change the name of this file to objectScript.js or something like that.

Do they know how to run code with the node command already? I cannot remember ;-). The previous part is run with LiveServer, I think.

The sentence "This is in contrast to objects instantiated from classes, which we'll look at later on." in Object Basics will have to be changed or taken out once we decide where we put classes.

In Dot notation this sentence: "The object name (in this case person) acts as the namespace" is not clear to me and I wonder if the students will understand it.

Last sentence in Dot notation: "Otherwise your methods will no longer work." I have added "Why do you think this is necessary?" because I think it would help them to think about the logic themselves and come up with the reason why it would not work.

Bracket notation: I think we should explain why sometimes you can only use bracket notation. It is added as a Note to Setting object members (last line) but I think it is not just a note, it is important enough to discuss it here because it can lead to a lot of confusion and mistakes.

Setting object members: I may have a dirty mind, but using the name 'Cratchit' must be a joke, no??

The section on "this" can be removed if we move OOP to the other project. We have to check in this entire project if we move OOP, because it comes back in several places.


Thursday 2021-07-22 15:58:46 by Jessica Strawford

I have finally been able to figure out my splashes! Yaygit add . Really happy with my progress today, I feel that I have accomplishd what I wanted and I am happy with where my game is currently at. I have the game completed to the standard that I had planned. I still have some time this evening so my plan is to play around with audio and potentially add audio to the paint splashes. I also do have a couple of bugs- if I run my game on for two long the paintbrushes seem to go funny and have a break in them (this is after say 10 minutes or so of the game running) I also have noticed that sometimes when the window reloads it sometimes can be a bit slow. I have managed to complete the splashes, making my paintbrushes sit on top of everything and also set up a winning page and instructions using a class of no-show. I intend to have a play at editing my alert button when you loose


Thursday 2021-07-22 17:09:04 by DefineOutside

Lag compensated packet based potion effect tracking

I went through all this damn effort to support horses etc. but yet Mojang's brilliant programming doesn't support sending potion effects for vehicle riding. Oh well, at least plugins can still send these packets and maybe eventually mojang will learn the art of sending packets to the client. Likely broken since 1.9 when riding became client sided, which client sided vehicles was such a big mistake. Now I have to deal with shitty code all around with vehicles. Vehicles are hacky netcode on top of hacky netcode. The code is not pretty. So many desync's on Mojang's end making them practically impossible to ever ban for or check without falses. Notice when boats randomly fall though the floor? Yeah, if you did that without a vehicle that's a ban. But with vehicles, that's just normal. At least in 1.17 jumping on top of boats is less glitchy than before. Only took Mojang a few years to fix that. Go ahead and ride a strider into a lava fall, with the center not touching lava. There you get animation affecting movement! Likely, as I can't figure out what the client is doing. How do we even check that? We don't get send the vehicle's onGround status, we don't know animation position, but at least we know inputs. Well, sort of, because if you switch between inventory slots fast enough, even vanilla can't handle the control of the vehicle transitioning from client to server sided repeatedly. Overall, vehicles suck. Nice one Mojang.


Thursday 2021-07-22 17:26:05 by Natashi

Fixed typos and changed some tabs to spaces because fuck you github


Thursday 2021-07-22 18:00:34 by Stephen Boyd

mmc: core: Use kref in place of struct mmc_blk_data::usage

Ulf reported the following KASAN splat after adding some manual hacks into mmc-utils[1].

DEBUG: mmc_blk_open: Let's sleep for 10s.. mmc1: card 0007 removed BUG: KASAN: use-after-free in mmc_blk_get+0x58/0xb8 Read of size 4 at addr ffff00000a394a28 by task mmc/180

CPU: 2 PID: 180 Comm: mmc Not tainted 5.10.0-rc4-00069-gcc758c8c7127-dirty #5 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Call trace: dump_backtrace+0x0/0x2b4 show_stack+0x18/0x6c dump_stack+0xfc/0x168 print_address_description.constprop.0+0x6c/0x488 kasan_report+0x118/0x210 __asan_load4+0x94/0xd0 mmc_blk_get+0x58/0xb8 mmc_blk_open+0x7c/0xdc __blkdev_get+0x3b4/0x964 blkdev_get+0x64/0x100 blkdev_open+0xe8/0x104 do_dentry_open+0x234/0x61c vfs_open+0x54/0x64 path_openat+0xe04/0x1584 do_filp_open+0xe8/0x1e4 do_sys_openat2+0x120/0x230 __arm64_sys_openat+0xf0/0x15c el0_svc_common.constprop.0+0xac/0x234 do_el0_svc+0x84/0xa0 el0_sync_handler+0x264/0x270 el0_sync+0x174/0x180

Allocated by task 33: stack_trace_save+0x9c/0xdc kasan_save_stack+0x28/0x60 __kasan_kmalloc.constprop.0+0xc8/0xf0 kasan_kmalloc+0x10/0x20 mmc_blk_alloc_req+0x94/0x4b0 mmc_blk_probe+0x2d4/0xaa4 mmc_bus_probe+0x34/0x4c really_probe+0x148/0x6e0 driver_probe_device+0x78/0xec __device_attach_driver+0x108/0x16c bus_for_each_drv+0xf4/0x15c __device_attach+0x168/0x240 device_initial_probe+0x14/0x20 bus_probe_device+0xec/0x100 device_add+0x55c/0xaf0 mmc_add_card+0x288/0x380 mmc_attach_sd+0x18c/0x22c mmc_rescan+0x444/0x4f0 process_one_work+0x3b8/0x650 worker_thread+0xa0/0x724 kthread+0x218/0x220 ret_from_fork+0x10/0x38

Freed by task 33: stack_trace_save+0x9c/0xdc kasan_save_stack+0x28/0x60 kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c __kasan_slab_free+0x100/0x180 kasan_slab_free+0x14/0x20 kfree+0xb8/0x46c mmc_blk_put+0xe4/0x11c mmc_blk_remove_req.part.0+0x6c/0xe4 mmc_blk_remove+0x368/0x370 mmc_bus_remove+0x34/0x50 __device_release_driver+0x228/0x31c device_release_driver+0x2c/0x44 bus_remove_device+0x1e4/0x200 device_del+0x2b0/0x770 mmc_remove_card+0xf0/0x150 mmc_sd_detect+0x9c/0x150 mmc_rescan+0x110/0x4f0 process_one_work+0x3b8/0x650 worker_thread+0xa0/0x724 kthread+0x218/0x220 ret_from_fork+0x10/0x38

The buggy address belongs to the object at ffff00000a394800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 552 bytes inside of 1024-byte region [ffff00000a394800, ffff00000a394c00) The buggy address belongs to the page: page:00000000ff84ed53 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8a390 head:00000000ff84ed53 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x3fffc0000010200(slab|head) raw: 03fffc0000010200 dead000000000100 dead000000000122 ffff000009f03800 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff00000a394900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000a394980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

ffff00000a394a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000a394a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000a394b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Looking closer at the problem, it looks like a classic dangling pointer bug. The 'struct mmc_blk_data' that is used after being freed in mmc_blk_put() is stashed away in 'md->disk->private_data' via mmc_blk_alloc_req() but used in mmc_blk_get() because the 'usage' count isn't properly aligned with the lifetime of the pointer. You'd expect the 'usage' member to be in sync with the kfree(), and it mostly is, except that mmc_blk_get() needs to dereference the potentially freed memory storage for the 'struct mmc_blk_data' stashed away in the private_data member to look at 'usage' before it actually figures out if it wants to consider it a valid pointer or not. That's not going to work if the freed memory has been overwritten by something else after the free, and KASAN rightly complains here.

To fix the immediate problem, let's set the private_data member to NULL in mmc_blk_put() so that mmc_blk_get() can consider the object "on the way out" if the pointer is NULL and not even try to look at 'usage' if the object isn't going to be around much longer. With that set to NULL on the last mmc_blk_put(), optimize the get path further and use a kref underneath the 'open_lock' mutex to only up the reference count if it's non-zero, i.e. alive, and otherwise make mmc_blk_get() return NULL, without actually testing the reference count if we're in the process of removing the object from the system.

Finally, tighten the locking region on the put side to only be around the parts that are removing the 'mmc_blk_data' from the system and publishing that fact to the gendisk and then drop the lock as soon as we can to avoid holding the lock around code that doesn't need it. This fixes the KASAN issue.

Cc: Matthias Schiffer [email protected] Cc: Sujit Kautkar [email protected] Cc: Zubin Mithra [email protected] Reported-by: Ulf Hansson [email protected] Link: https://lore.kernel.org/linux-mmc/CAPDyKFryT63Jc7+DXWSpAC19qpZRqFr1orxwYGMuSqx247O8cQ@mail.gmail.com/ [1] Signed-off-by: Stephen Boyd [email protected] Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Ulf Hansson [email protected]


Thursday 2021-07-22 18:10:38 by Billy Einkamerer

Created Text For URL [zoutnet.co.za/articles/news/54624/2021-07-18/late-netshiombo-will-be-remembered-for-her-love]


Thursday 2021-07-22 20:02:17 by Micheal Shokunbi

commit A dog will teach you unconditional love. If you can have that in your life, things won't be too bad


Thursday 2021-07-22 20:15:10 by chris

fixed makefile ludwig is a stupid fucking idiot and changes extensions without it making sense


Thursday 2021-07-22 22:43:00 by ercarp

Blood Troll Flavorization

  • Changed female blood troll title from Matriarch to Grand Ma'da.
  • Disabled title from male holders since it's a matriarchal society.

< 2021-07-22 >