2,618,716 events, 1,130,085 push events, 1,495,683 commit messages, 88,148,035 characters
Omfg. Someone needs to fix the docs on NextJS because that took way too damn long to resolve holy shit.
Adjust bonus damage
It's now a flat +mlev bonus, but reduces the remaining time by (mlev/10) - rn2(5) (floored, never increases duration). That means that you chould hypothetically get an average of 4 or so hits on Demogorgon, each dealing +108 flat in addition to whatever base damage it deals. Stupid? Yeah, quite possibly. Reasonably balanced? Dunno. I'm expecting it to be quite lethal at killing demon lords if you bother to ward & prep beforehand, but not otherwise. Might revisit the initial damage and increase it to 40% or something like that.
What the fuck did you just fucking say about me, you little bitch? I'll have you know I graduated top of my class in the Navy Seals, and I've been involved in numerous secret raids on Al-Quaeda, and I have over 300 confirmed kills. I am trained in gorilla warfare and I'm the top sniper in the entire US armed forces. You are nothing to me but just another target. I will wipe you the fuck out with precision the likes of which has never been seen before on this Earth, mark my fucking words. You think you can get away with saying that shit to me over the Internet? Think again, fucker. As we speak I am contacting my secret network of spies across the USA and your IP is being traced right now so you better prepare for the storm, maggot. The storm that wipes out the pathetic little thing you call your life. You're fucking dead, kid. I can be anywhere, anytime, and I can kill you in over seven hundred ways, and that's just with my bare hands. Not only am I extensively trained in unarmed combat, but I have access to the entire arsenal of the United States Marine Corps and I will use it to its full extent to wipe your miserable ass off the face of the continent, you little shit. If only you could have known what unholy retribution your little "clever" comment was about to bring down upon you, maybe you would have held your fucking tongue. But you couldn't, you didn't, and now you're paying the price, you goddamn idiot. I will shit fury all over you and you will drown in it. You're fucking dead, kiddo.
A girl.... AND a gamer? Whoa mama! Hummina hummina hummina bazooooooooing! eyes pop out AROOOOOOOOGA! jaw drops tongue rolls out WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF WOOF tongue bursts out of the outh uncontrollably leaking face and everything in reach WURBLWUBRLBWURblrwurblwurlbrwubrlwburlwbruwrlblwublr tiny cupid shoots an arrow through heart Ahhhhhhhhhhh me lady... heart in the shape of a heart starts beating so hard you can see it through shirt ba-bum ba-bum ba-bum ba-bum ba-bum milk truck crashes into a bakery store in the background spiling white liquid and dough on the streets BABY WANTS TO FUCK inhales from the gas tank honka honka honka honka masturabtes furiously ohhhh my gooooodd~
Zombies can be decapped again, un-nerfs esword/armblade/etc wounding power, improvised cauterization tweaks (#53349)
#53117 introduced a few minor bugs with the health system, in this case, zombies being un-decappable due to an oversight in the head/chest dismember requiring full death rather than either full crit or death. As zombies (or anything with TRAIT_NODEATH) can only reach hard crit and not death, this meant they couldn't be decapped/disemboweled. This fixes that. It also fixes krokodil addict zombies being unwoundable due to not having flesh or bone traits.
Next up, I originally set really high negative wound bonuses for high damage weapons like eswords and armblades since they already had high damage and dismember power by themselves. Now that dismembering is tied to wounding power (and I have a better sense of balance values), these harsh nerfs are no longer needed or wanted, and you can actually dismember people worth a damn with an esword again. I also punched up the wounding power of a few other weapons like saws and scalpels to less awful (but still not optimal) against armor.
Attacks currently have an 80% chance to hit the limb you're aiming at, which can make destroying a limb a complete pain even if the target is already down and out. As such, attacks against prone targets now have a 90% chance to hit the targeted limb, cutting the miss rate in half.
Lastly, trying to cauterize bleeding wounds with improvised tools (anything hot that isn't a cautery) is now slightly less efficient than a real cautery and requires an aggro grab on the patient to apply. No more trying to cauterize the person you just attacked with an esword because you were on help intent!
BACKPORT: signal: add pidfd_send_signal() syscall
The kill() syscall operates on process identifiers (pid). After a process has exited its pid can be reused by another process. If a caller sends a signal to a reused pid it will end up signaling the wrong process. This issue has often surfaced and there has been a push to address this problem [1].
This patch uses file descriptors (fd) from proc/ as stable handles on struct pid. Even if a pid is recycled the handle will not change. The fd can be used to send signals to the process it refers to. Thus, the new syscall pidfd_send_signal() is introduced to solve this problem. Instead of pids it operates on process fds (pidfd).
/* prototype and argument /* long pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags);
/* syscall number 424 */ The syscall number was chosen to be 424 to align with Arnd's rework in his y2038 to minimize merge conflicts (cf. [25]).
In addition to the pidfd and signal argument it takes an additional siginfo_t and flags argument. If the siginfo_t argument is NULL then pidfd_send_signal() is equivalent to kill(, ). If it is not NULL pidfd_send_signal() is equivalent to rt_sigqueueinfo(). The flags argument is added to allow for future extensions of this syscall. It currently needs to be passed as 0. Failing to do so will cause EINVAL.
/* pidfd_send_signal() replaces multiple pid-based syscalls */ The pidfd_send_signal() syscall currently takes on the job of rt_sigqueueinfo(2) and parts of the functionality of kill(2), Namely, when a positive pid is passed to kill(2). It will however be possible to also replace tgkill(2) and rt_tgsigqueueinfo(2) if this syscall is extended.
/* sending signals to threads (tid) and process groups (pgid) */ Specifically, the pidfd_send_signal() syscall does currently not operate on process groups or threads. This is left for future extensions. In order to extend the syscall to allow sending signal to threads and process groups appropriately named flags (e.g. PIDFD_TYPE_PGID, and PIDFD_TYPE_TID) should be added. This implies that the flags argument will determine what is signaled and not the file descriptor itself. Put in other words, grouping in this api is a property of the flags argument not a property of the file descriptor (cf. [13]). Clarification for this has been requested by Eric (cf. [19]). When appropriate extensions through the flags argument are added then pidfd_send_signal() can additionally replace the part of kill(2) which operates on process groups as well as the tgkill(2) and rt_tgsigqueueinfo(2) syscalls. How such an extension could be implemented has been very roughly sketched in [14], [15], and [16]. However, this should not be taken as a commitment to a particular implementation. There might be better ways to do it. Right now this is intentionally left out to keep this patchset as simple as possible (cf. [4]).
/* naming */ The syscall had various names throughout iterations of this patchset:
- procfd_signal()
- procfd_send_signal()
- taskfd_send_signal() In the last round of reviews it was pointed out that given that if the flags argument decides the scope of the signal instead of different types of fds it might make sense to either settle for "procfd_" or "pidfd_" as prefix. The community was willing to accept either (cf. [17] and [18]). Given that one developer expressed strong preference for the "pidfd_" prefix (cf. [13]) and with other developers less opinionated about the name we should settle for "pidfd_" to avoid further bikeshedding.
The "_send_signal" suffix was chosen to reflect the fact that the syscall takes on the job of multiple syscalls. It is therefore intentional that the name is not reminiscent of neither kill(2) nor rt_sigqueueinfo(2). Not the fomer because it might imply that pidfd_send_signal() is a replacement for kill(2), and not the latter because it is a hassle to remember the correct spelling - especially for non-native speakers - and because it is not descriptive enough of what the syscall actually does. The name "pidfd_send_signal" makes it very clear that its job is to send signals.
/* zombies */ Zombies can be signaled just as any other process. No special error will be reported since a zombie state is an unreliable state (cf. [3]). However, this can be added as an extension through the @flags argument if the need ever arises.
/* cross-namespace signals */ The patch currently enforces that the signaler and signalee either are in the same pid namespace or that the signaler's pid namespace is an ancestor of the signalee's pid namespace. This is done for the sake of simplicity and because it is unclear to what values certain members of struct siginfo_t would need to be set to (cf. [5], [6]).
/* compat syscalls */ It became clear that we would like to avoid adding compat syscalls (cf. [7]). The compat syscall handling is now done in kernel/signal.c itself by adding __copy_siginfo_from_user_generic() which lets us avoid compat syscalls (cf. [8]). It should be noted that the addition of __copy_siginfo_from_user_any() is caused by a bug in the original implementation of rt_sigqueueinfo(2) (cf. 12). With upcoming rework for syscall handling things might improve significantly (cf. [11]) and __copy_siginfo_from_user_any() will not gain any additional callers.
/* testing */ This patch was tested on x64 and x86.
/* userspace usage */ An asciinema recording for the basic functionality can be found under [9]. With this patch a process can be killed via:
#define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h>
static inline int do_pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags) { #ifdef __NR_pidfd_send_signal return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags); #else return -ENOSYS; #endif }
int main(int argc, char *argv[]) { int fd, ret, saved_errno, sig;
if (argc < 3)
exit(EXIT_FAILURE);
fd = open(argv[1], O_DIRECTORY | O_CLOEXEC);
if (fd < 0) {
printf("%s - Failed to open \"%s\"\n", strerror(errno), argv[1]);
exit(EXIT_FAILURE);
}
sig = atoi(argv[2]);
printf("Sending signal %d to process %s\n", sig, argv[1]);
ret = do_pidfd_send_signal(fd, sig, NULL, 0);
saved_errno = errno;
close(fd);
errno = saved_errno;
if (ret < 0) {
printf("%s - Failed to send signal %d to process %s\n",
strerror(errno), sig, argv[1]);
exit(EXIT_FAILURE);
}
exit(EXIT_SUCCESS);
}
/* Q&A
- Given that it seems the same questions get asked again by people who are
- late to the party it makes sense to add a Q&A section to the commit
- message so it's hopefully easier to avoid duplicate threads.
- For the sake of progress please consider these arguments settled unless
- there is a new point that desperately needs to be addressed. Please make
- sure to check the links to the threads in this commit message whether
- this has not already been covered. */ Q-01: (Florian Weimer [20], Andrew Morton [21]) What happens when the target process has exited? A-01: Sending the signal will fail with ESRCH (cf. [22]).
Q-02: (Andrew Morton [21]) Is the task_struct pinned by the fd? A-02: No. A reference to struct pid is kept. struct pid - as far as I understand - was created exactly for the reason to not require to pin struct task_struct (cf. [22]).
Q-03: (Andrew Morton [21]) Does the entire procfs directory remain visible? Just one entry within it? A-03: The same thing that happens right now when you hold a file descriptor to /proc/ open (cf. [22]).
Q-04: (Andrew Morton [21]) Does the pid remain reserved? A-04: No. This patchset guarantees a stable handle not that pids are not recycled (cf. [22]).
Q-05: (Andrew Morton [21]) Do attempts to signal that fd return errors? A-05: See {Q,A}-01.
Q-06: (Andrew Morton [22]) Is there a cleaner way of obtaining the fd? Another syscall perhaps. A-06: Userspace can already trivially retrieve file descriptors from procfs so this is something that we will need to support anyway. Hence, there's no immediate need to add another syscalls just to make pidfd_send_signal() not dependent on the presence of procfs. However, adding a syscalls to get such file descriptors is planned for a future patchset (cf. [22]).
Q-07: (Andrew Morton [21] and others) This fd-for-a-process sounds like a handy thing and people may well think up other uses for it in the future, probably unrelated to signals. Are the code and the interface designed to permit such future applications? A-07: Yes (cf. [22]).
Q-08: (Andrew Morton [21] and others) Now I think about it, why a new syscall? This thing is looking rather like an ioctl? A-08: This has been extensively discussed. It was agreed that a syscall is preferred for a variety or reasons. Here are just a few taken from prior threads. Syscalls are safer than ioctl()s especially when signaling to fds. Processes are a core kernel concept so a syscall seems more appropriate. The layout of the syscall with its four arguments would require the addition of a custom struct for the ioctl() thereby causing at least the same amount or even more complexity for userspace than a simple syscall. The new syscall will replace multiple other pid-based syscalls (see description above). The file-descriptors-for-processes concept introduced with this syscall will be extended with other syscalls in the future. See also [22], [23] and various other threads already linked in here.
Q-09: (Florian Weimer [24]) What happens if you use the new interface with an O_PATH descriptor? A-09: pidfds opened as O_PATH fds cannot be used to send signals to a process (cf. [2]). Signaling processes through pidfds is the equivalent of writing to a file. Thus, this is not an operation that operates "purely at the file descriptor level" as required by the open(2) manpage. See also [4].
/* References */ [1]: https://lore.kernel.org/lkml/[email protected]/ [2]: https://lore.kernel.org/lkml/[email protected]/ [3]: https://lore.kernel.org/lkml/[email protected]/ [4]: https://lore.kernel.org/lkml/[email protected]/ [5]: https://lore.kernel.org/lkml/[email protected]/ [6]: https://lore.kernel.org/lkml/[email protected]/ [7]: https://lore.kernel.org/lkml/[email protected]/ [8]: https://lore.kernel.org/lkml/[email protected]/ [9]: https://asciinema.org/a/IQjuCHew6bnq1cr78yuMv16cy [11]: https://lore.kernel.org/lkml/[email protected]/ [12]: https://lore.kernel.org/lkml/[email protected]/ [13]: https://lore.kernel.org/lkml/[email protected]/ [14]: https://lore.kernel.org/lkml/[email protected]/ [15]: https://lore.kernel.org/lkml/[email protected]/ [16]: https://lore.kernel.org/lkml/[email protected]/ [17]: https://lore.kernel.org/lkml/CAGXu5jL8PciZAXvOvCeCU3wKUEB_dU-O3q0tDw4uB_ojMvDEew@mail.gmail.com/ [18]: https://lore.kernel.org/lkml/[email protected]/ [19]: https://lore.kernel.org/lkml/[email protected]/ [20]: https://lore.kernel.org/lkml/[email protected]/ [21]: https://lore.kernel.org/lkml/[email protected]/ [22]: https://lore.kernel.org/lkml/[email protected]/ [23]: https://lwn.net/Articles/773459/ [24]: https://lore.kernel.org/lkml/[email protected]/ [25]: https://lore.kernel.org/lkml/CAK8P3a0ej9NcJM8wXNPbcGUyOUZYX+VLoDFdbenW3s3114oQZw@mail.gmail.com/
Cc: "Eric W. Biederman" [email protected] Cc: Jann Horn [email protected] Cc: Andy Lutomirsky [email protected] Cc: Andrew Morton [email protected] Cc: Oleg Nesterov [email protected] Cc: Al Viro [email protected] Cc: Florian Weimer [email protected] Signed-off-by: Christian Brauner [email protected] Reviewed-by: Tycho Andersen [email protected] Reviewed-by: Kees Cook [email protected] Reviewed-by: David Howells [email protected] Acked-by: Arnd Bergmann [email protected] Acked-by: Thomas Gleixner [email protected] Acked-by: Serge Hallyn [email protected] Acked-by: Aleksa Sarai [email protected]
(cherry picked from commit 3eb39f47934f9d5a3027fe00d906a45fe3a15fad)
Conflicts: arch/x86/entry/syscalls/syscall_32.tbl - trivial manual merge arch/x86/entry/syscalls/syscall_64.tbl - trivial manual merge include/linux/proc_fs.h - trivial manual merge include/linux/syscalls.h - trivial manual merge include/uapi/asm-generic/unistd.h - trivial manual merge kernel/signal.c - struct kernel_siginfo does not exist in 4.14 kernel/sys_ni.c - cond_syscall is used instead of COND_SYSCALL arch/x86/entry/syscalls/syscall_32.tbl arch/x86/entry/syscalls/syscall_64.tbl
(1. manual merges because of 4.14 differences 2. change prepare_kill_siginfo() to use struct siginfo instead of kernel_siginfo 3. use copy_from_user() instead of copy_siginfo_from_user() in copy_siginfo_from_user_any() 4. replaced COND_SYSCALL with cond_syscall 5. Removed __ia32_sys_pidfd_send_signal in arch/x86/entry/syscalls/syscall_32.tbl. 6. Replaced __x64_sys_pidfd_send_signal with sys_pidfd_send_signal in arch/x86/entry/syscalls/syscall_64.tbl.)
Bug: 135608568 Test: test program using syscall(__NR_pidfd_send_signal,..) to send SIGKILL Change-Id: I34da11c63ac8cafb0353d9af24c820cef519ec27 Signed-off-by: Suren Baghdasaryan [email protected] (cherry picked from commit c8b9b2c5cca36e3bbc567a1f030ee10a795b409d) (cherry picked from commit bc2aae56cbc3337606ffab64182cb47269961f61) (cherry picked from commit 14ab996549cf2910bd4ecaacbed3628cfc7e5ca1) Signed-off-by: Kyvangka1610 [email protected] Signed-off-by: Edwiin Kusuma Jaya [email protected]
Rename near to zNear
near is an illegal variable name on Windows (if windef.h is included),
because a macro with the same name is defined.
Someone else already put your rage into words, see http://lolengine.net/blog/2011/3/4/fuck-you-microsoft-near-far-macros.
Finally texture the stupid stairs
After putting it off forever, I finally got around to texturing the stairs for the house and the guardpost. The result?
Well, it looks good-to-okay (passable, really) but in order to appropraitely texture each I had to create a whole slew of new textures, each with a different name. I didn't come up with the best naming scheme and even then I was inconsistent with how I executed it.
Having to create unique textures for each stair was a massive pain - but everything was different for both stairs! The width, the length of steps, the height of the steps. I wanted to highlight the edges so the stairs had better definition, but since the edges were all over the place, I had no choice but to make a bunch of separate textures. I suppose it's not all that much trouble, but I like to keep my assets nice and orderly!
Merge pull request #8 from incredincomp/testing
I actually hate git honestly lol. what a shitshow
Shopify
SHOPIFYJUST A STEP AWAY: *Due to sudden pandemic situation world has faced a huge change . Now in the era of new normal lots of people find it very difficult to cope up with the new sudden digital life for example poor/small traders.. Due to covid-19 social distancing is very needful but somehow in markets social distancing is not maintained properly .Here’s where the idea of Shopify came from. It not only connects local vendors to the new digital world also helps to maintain social distancing at the same time. We are coming with a idea of a app in which they can book their essential items from their local shops. Items will be updated by the shop keepers and people can book the items which they want. Everyone will get their certain time span and they have to collect the items within that time. By this process they can avoid gathering.
*FOR BUYERS: This app basically brings all your known local shops in a single application . All you need to do after opening the application and signing up (or logging in)is –1.Choose your shop category(1.grocery 2.sweet 3.pharmacy 4.fruit/veg).2.Enter your correct location.3.Then this app will provide you list of shops according to your chosen category.(you can even short list it) 4.Then the list of items will be shown , choose your desired item ,enter quantity and click on book now.5.Then you have to select the time to pick up your given order. You can even cancel your order if you want(for that you have to give the reason of cancellation .)
*FOR SHOP OWNERS: This app will help local businessmen to cope up with this new normal world. It will help them to track their orders and will get opportunity to reach more customers .All one needs to do after opening application is to choose your job(owner or customer ) then-1.Sign in 2.Enter your basic information and choose the category of your shop3.Enter your items along with price.(you have to daily update your items)4.After that you can get orders from your customers you can track them. Customers will pick up the order at selected time and pay on delivery.
Create README.md
Every day in the morning we need to complete some set of predefined tasks that remain constant. We can list the generic tasks as below:
- Ring the alarm on time
- Make coffee
- Heat the water to a suitable temperature
- Pack your bag (Keep only appropriate books for the day)
- Cook breakfast and lunch
- Iron the clothes
ABOUT OF ROBOT:- Consider the Robot as your personal assistant. You will give the Robot a name by which you will call it. You also need to define the functions performed by the Robot. These functions will be the same as above i.e. the tasks which it will perform for you in the morning. Feel free to add/modify the above-listed tasks as per your choice.
Call "fish_command_not_found" if a command wasn't found
Previously, when a command wasn't found, fish would emit the "fish_command_not_found" event.
This was annoying as it was hard to override (the code ended up
checking for a function called __fish_command_not_found_handler
anyway!), the setup was ugly,
and it's useless - there is no use case for multiple command-not-found handlers.
Instead, let's just call a function fish_command_not_found if it
exists, or print the default message otherwise.
The event is completely removed, but because a missing event is not an error (MEISNAE in C++-speak) this isn't an issue.
Note that, for backwards-compatibility, we still keep the default handler function around even tho the new one is hard-coded in C++.
Also, if we detect a previous handler, the new handler just calls it.
This way, the backwards-compatible way to install a custom handler is:
function __fish_command_not_found_handler --on-event fish_command_not_found
# do a little dance, make a little love, get down tonight
endand the new hotness is
function fish_command_not_found
# do the thing
endFixes #7293.
Created Text For URL [www.sowetanlive.co.za/news/south-africa/2020-09-06-boyfriend-arrested-for-alleged-murder-of-15-year-old-girl/]
British/British Africa/Madagascar updates
The UK army tree (still wip especially for gfx) has been created with the necessary localisation. British African colonies (excluding South Africa) have recieved parties (for BWA and Sudan there still WIP), OOB's and ideas. Madagascar has recieved parties (please forgive my god awful google transalte Magalasy) and an OOB. German Africa has also been demilitarised in certain regions as agreed to.
"2:30pm. Done with breakfast. Let me finish the chapter I am on and then maybe I'll resume.
I've been reading Reverend Insanity way too long into the day. Last night I went to sleep at 1am again.
2:45pm. One more chapter.
2:55pm. Ok, let me pry myself off the novel, and chill just for a bit.
3:15pm. Let me finally start.
It is time to resume the path. Whether it is demonic or angelic does not matter, I have to keep moving.
...Well, since I said I would, let me take detour from working on the parser, and I'll test the distributed prototype constraints.
3:25pm.
prototype eq x : x -> x -> bool
instance eq list el {eq} : a b =
let rec loop = function
| Nil, Nil => true
| (Cons: a,a'), (Cons: b,b') when eq a b => loop (a',b')
| _ => false
loop (a,b)
This works perfectly.
That having said...: a b =. This syntax is redundant. I'll get rid of it.
instance eq list el {eq} : = fun a b =>
let rec loop = function
| Nil, Nil => true
| (Cons: a,a'), (Cons: b,b') when eq a b => loop (a',b')
| _ => false
loop (a,b)
Yeah, there is no need to make this anymore complicated than it needs ot be. It if fine if the user writes fun.
3:30pm.
let top_instance d =
(range
(tuple4 (skip_keyword SpecInstance >>. read_small_var') read_type_var' (many forall_var) (skip_op "=" >>. root_term))
>>= fun (r,(prototype_name, nominal_name, nominal_foralls, body)) _ ->
Ok(TopInstance(r,prototype_name,nominal_name,nominal_foralls,body))
) dActually, since I've already been merging the instance into the body here, I won't have to change anything but the parser here. Wonderful.
3:30pm.
instance eq list el {eq} = fun a b =>
match a,b with
| Nil, Nil => true
| (Cons: a,a'), (Cons: b,b') when eq a b => eq a' b'
| _ => false
I wanted to simplify it to this, but the eq is not recursive here unfortunately. The typechecker cannot find the constraint for list while it is evaluating the instance for it.
3:35pm.
term {term=Map.empty; ty=env_ty} prot_body body
let prototype = {|prototype with instances = Map.add ins_id ins_constraints prototype.instances|}
{top_env' with prototypes = PersistentVector.update prot_id prototype top_env'.prototypes}
What should I do? Do I want to strugle to add this particular case?
let infer (top_env' : TopEnv) expr =
let hoc = top_env'.hoc
let top_env = loc_env top_env'
An easy hack would be to just make the top_env' mutable here...
3:40pm. Mhhh...no forget it. It is not that important. A marginal readability benefit is not worth uprooting the inferencer for.
Let me try out polymorphic recursion.
3:45pm.
let rec poly forall t. (x : t): t =
inl q = poly true
inl w = poly "qwe"
inl e = poly' 1i32
x
and let poly' forall t {number}. (x : t): t = poly x
Yeah, it works perfectly.
3:50pm. With this I can verify that annotation requirements work properly.
let rec poly forall t. (x : t): _ =
forall t. t -> ?
Or maybe not.
I really don't like this.
Metavars should never be left over in TC'd functions. I should just push them to unit or something.
3:55pm.
let f t =
let i = errors.Count
let v = fresh_var()
ty env v t
let v = term_subst v
if i = errors.Count && has_metavars v then errors.Add(range_of_texpr t, RecursiveAnnotationHasMetavars v)
vWhat I really should be doing is generalizing the leftovers.
Let me force them to .<error> symbols.
let rec has_metavars_force x =
let f = has_metavars_force
match visit_t x with
| TyConstraint | TyVar _ | TyHigherOrder _ | TyB | TyPrim _ | TySymbol _ -> false
| TyForall(_,a) | TyInl(_,a) | TyArray a -> f a
| TyApply(a,b,_) | TyFun(a,b) | TyPair(a,b) -> f a && f b
| TyRecord l -> Map.exists (fun _ -> f) l
| TyMetavar(x,link) -> link := Some (TySymbol "<error>"); true
| TyMacro a -> List.exists (function TMVar x -> f x | _ -> false) a
| TyLayout(a,b) -> f aNo, shit. What if the substitution ends up with a wrong kind?
List.fold (fun s ((_,name),_) ->
let v = {scope= !scope; constraints=Set.empty; kind=KindType; name="x"}
Map.add name (TyForall(v, TyVar v)) s
) env.term l'
|> fun term -> {env with term = term}Ah, wait, I see. I am doing this kind of thing in the recursive case.
let ty = List.foldBack (fun x s -> TyForall(x,s)) vars body_var
hover_types.Add(r,ty)It is just that the type already gets added to the hover, so I forgot about this.
4:05pm.
List.mapFold (fun s ((r,name),body) ->
let vars,body = foralls_get body
let vars, env_ty = typevars env.ty vars
let body_var = term_annotations {env with ty = env_ty} body
let term env = term {env with ty = env_ty} body_var (strip_annotations body)
// This gen is just in the error case where there are metavars left over.
let gen env : Env =
let ty = generalize vars body_var
hover_types.Add(r,ty)
{env with term = Map.add name ty env.term}
let ty = List.foldBack (fun x s -> TyForall(x,s)) vars body_var
(term, gen), Map.add name ty s
) env.term l'Actually forget this. Maybe the thing I had before was in fact right. You can see in the type signature itself right away where the metavars are.
4:10pm.
inl q _ =
inl x = poly "qwe"
()The poly here acts like its type is forall a. 'a -> 'a. Unfortunately, the value restriction error is not triggering.
That is not good.
4:15pm.
inl failwith forall a. : a = $"failwith \"error\""
There is something wrong with the token parser. I cannot write anything after the macro.
Ah...I probably forgot to parse spaces.
Let me fix that first. I think strings and chars should have the same problem.
Strings, do but chars don't. Ok.
4:20pm. Fixed the tokenizer for both strings and macros.
inl failwith forall a. : a = $"failwith \"error\""
inl f _ =
inl q = failwith "qwe"
()For whatever reason this does not give me the value restriction.
Let me check it out.
4:25pm. You can really see from this debugging session why writing code personally is really necessary. It is amazing at what comes out once you shake this a little.
let rec has_metavars x =
let f = has_metavars
match visit_t x with
| TyMetavar _ -> true
| TyConstraint | TyVar _ | TyHigherOrder _ | TyB | TyPrim _ | TySymbol _ -> false
| TyForall(_,a) | TyInl(_,a) | TyArray a -> f a
| TyApply(a,b,_) | TyFun(a,b) | TyPair(a,b) -> f a && f b
| TyRecord l -> Map.exists (fun _ -> f) l
| TyMacro a -> List.exists (function TMVar x -> has_metavars x | _ -> false) a
| TyLayout(a,b) -> f aI do not get it. This should trigger by all means.
Let me print out what comes out.
type_application |> Seq.iter (fun x ->
printfn "%s" (show_t top_env' x.Value)
if has_metavars x.Value then errors.Add(range_of_expr x.Key, ValueRestriction x.Value))
Server bound to: tcp://*:13805
string -> ?
| TyApply(a,b,_) | TyFun(a,b) | TyPair(a,b) -> f a && f b
Ah, shit it is an and here! That should be ||.
let rec has_metavars x =
let f = has_metavars
match visit_t x with
| TyMetavar _ -> true
| TyConstraint | TyVar _ | TyHigherOrder _ | TyB | TyPrim _ | TySymbol _ -> false
| TyLayout(a,_) | TyForall(_,a) | TyInl(_,a) | TyArray a -> f a
| TyApply(a,b,_) | TyFun(a,b) | TyPair(a,b) -> f a || f b
| TyRecord l -> Map.exists (fun _ -> f) l
| TyMacro a -> List.exists (function TMVar x -> has_metavars x | _ -> false) aCrazy bugs due to carelessness.
4:30pm. Great, that is another error down.
Let me test forall escaping.
inl q x =
inl w forall t {number}. (y : t) = x + y
w x
This gives a solid error.
4:35pm.
inl forall_escape_test q w e = // Should have an error.
inl f forall t {number}. (a : t) (s : t) (d : t) = (q,w,e) = (a,s,d)
f q w e
Yeah, this is a solid error.
4:40pm. I feel more confident in the typechecker once again.
Actually, I am confused about something. In the above fragment I get 3 errors, which is good.
| TyVar b -> if i.scope < b.scope then raise (TypeErrorException [r,ForallVarScopeError(b.name,got,expected)])But, this should be throwing an exception. So how is it processing anything other than the first part of the pair?
...Seriously, I am the one who wrote this and I have no idea.
4:45pm. I need to investigate this. I must have full grip over the compiler. Things that I do not understand should not be happening.
4:50pm. Ah, wait I get it. I forgot that I am pushing the information forward. So it will flow into the pairs. That means that it will unify the variables independently - in fact that is the only way to get a separate error for each of the variable.
I made a mental error, my model of unification is still the one where each branch returns.
The way the inferencer actually works is bidirectional typechecking with unification. It is good that it works like this as it is more powerful, not to mention the error messages are better as I can attest to here.
Now that this is out of the way, what is next?
4:55pm. I am really exhausted from debugging all these errors.
Let me commit here. I am not done yet."
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
...
}
Where PSAT is the power-status register of the PWM controller.
Since the i915 driver will do a pwm_get on the pwm device as it uses it to control the LCD panel backlight, there is a device-link marking the i915 device as a consumer of the pwm device. So that the PWM controller will always be suspended after the i915 driver suspends (which is the right thing to do). This causes the above GFX0 PS3 AML code to run before acpi_lpss.c calls acpi_lpss_save_ctx().
So on these devices the PWM controller will already be off when acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff) as ctx register values.
When these bogus values get restored on resume the PWM controller actually keeps working, since most bits are reserved, but this does set bit 3 of the LPSS General purpose register, which for the PWM controller has the following function: "This bit is re-used to support 32kHz slow mode. Default is 19.2MHz as PWM source clock".
This causes the clock of the PWM controller to switch from 19.2MHz to 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far there have been few bug reports about this. This is likely because the i915 driver was hardcoding the PWM frequency to 46 KHz, which divided by 600 would result in a PWM frequency of approx. 78 Hz, which mostly still works fine. There are some bug reports about the LCD backlight flickering after suspend/resume which are likely caused by this issue.
But with the upcoming patch-series to finally switch the i915 drivers code for external PWM controllers to use the atomic API and to honor the PWM frequency specified in the video BIOS (VBT), this becomes a much bigger problem. On most cases the VBT specifies either 200 Hz or 20 KHz as PWM frequency, which with the mentioned issue ends up being either 1/3 Hz, where the backlight actually visible blinks on and off every 3s, or in 33 Hz and horrible flickering of the backlight.
There are a number of possible solutions to this problem:
- Make acpi_lpss_save_ctx() run before GFX0._PS3 Pro: Clean solution from pov of not medling with save/restore ctx code Con: As mentioned the current ordering is the right thing to do Con: Requires assymmetry in at what suspend/resume phase we do the save vs restore, requiring more suspend/resume ordering hacks in already convoluted acpi_lpss.c suspend/resume code.
- Do some sort of save once mode for the LPSS ctx Pro: Reasonably clean Con: Needs a new LPSS flag + code changes to handle the flag
- Detect we have failed to save the ctx registers and do not restore them Pro: Not PWM specific, might help with issues on other LPSS devices too Con: If we can get away with not restoring the ctx why bother with it at all?
- Do not save the ctx for CHT PWM controllers Pro: Clean, as simple as dropping a flag? Con: Not so simple as dropping a flag, needs a new flag to ensure that we still do lpss_deassert_reset() on device activation.
- Make the pwm-lpss code fixup the LPSS-context registers Pro: Keeps acpi_lpss.c code clean Con: Moves knowledge of LPSS-context into the pwm-lpss.c code
1 and 5 both do not seem to be a desirable way forward.
3 and 4 seem ok, but they both assume that restoring the LPSS-context registers is not necessary. I have done a couple of test and those do show that restoring the LPSS-context indeed does not seem to be necessary on devices using s2idle suspend (and successfully reaching S0i3). But I have no hardware to test deep / S3 suspend. So I'm not sure that not restoring the context is safe.
That leaves solution 2, which is about as simple / clean as 3 and 4, so this commit fixes the described problem by implementing a new LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.
Acked-by: Rafael J. Wysocki [email protected] Signed-off-by: Hans de Goede [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Created Text For URL [www.heraldlive.co.za/news/2020-09-06-boyfriend-arrested-for-alleged-murder-of-15-year-old-girl/]
Created Text For URL [www.dispatchlive.co.za/news/2020-09-06-boyfriend-arrested-for-alleged-murder-of-15-year-old-girl/]
BACKPORT: mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
Upstream commit 6471384af2a6530696fc0203bafe4de41a23c9ef.
Patch series "add init_on_alloc/init_on_free boot options", v10.
Provide init_on_alloc and init_on_free boot options.
These are aimed at preventing possible information leaks and making the control-flow bugs that depend on uninitialized values more deterministic.
Enabling either of the options guarantees that the memory returned by the page allocator and SL[AU]B is initialized with zeroes. SLOB allocator isn't supported at the moment, as its emulation of kmem caches complicates handling of SLAB_TYPESAFE_BY_RCU caches correctly.
Enabling init_on_free also guarantees that pages and heap objects are initialized right after they're freed, so it won't be possible to access stale data by using a dangling pointer.
As suggested by Michal Hocko, right now we don't let the heap users to disable initialization for certain allocations. There's not enough evidence that doing so can speed up real-life cases, and introducing ways to opt-out may result in things going out of control.
This patch (of 2):
The new options are needed to prevent possible information leaks and make control-flow bugs that depend on uninitialized values more deterministic.
This is expected to be on-by-default on Android and Chrome OS. And it gives the opportunity for anyone else to use it under distros too via the boot args. (The init_on_free feature is regularly requested by folks where memory forensics is included in their threat models.)
init_on_alloc=1 makes the kernel initialize newly allocated pages and heap objects with zeroes. Initialization is done at allocation time at the places where checks for __GFP_ZERO are performed.
init_on_free=1 makes the kernel initialize freed pages and heap objects with zeroes upon their deletion. This helps to ensure sensitive data doesn't leak via use-after-free accesses.
Both init_on_alloc=1 and init_on_free=1 guarantee that the allocator returns zeroed memory. The two exceptions are slab caches with constructors and SLAB_TYPESAFE_BY_RCU flag. Those are never zero-initialized to preserve their semantics.
Both init_on_alloc and init_on_free default to zero, but those defaults can be overridden with CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_INIT_ON_FREE_DEFAULT_ON.
If either SLUB poisoning or page poisoning is enabled, those options take precedence over init_on_alloc and init_on_free: initialization is only applied to unpoisoned allocations.
Slowdown for the new features compared to init_on_free=0, init_on_alloc=0:
hackbench, init_on_free=1: +7.62% sys time (st.err 0.74%) hackbench, init_on_alloc=1: +7.75% sys time (st.err 2.14%)
Linux build with -j12, init_on_free=1: +8.38% wall time (st.err 0.39%) Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%) Linux build with -j12, init_on_alloc=1: -0.13% wall time (st.err 0.42%) Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)
The slowdown for init_on_free=0, init_on_alloc=0 compared to the baseline is within the standard error.
The new features are also going to pave the way for hardware memory tagging (e.g. arm64's MTE), which will require both on_alloc and on_free hooks to set the tags for heap objects. With MTE, tagging will have the same cost as memory initialization.
Although init_on_free is rather costly, there are paranoid use-cases where in-memory data lifetime is desired to be minimized. There are various arguments for/against the realism of the associated threat models, but given that we'll need the infrastructure for MTE anyway, and there are people who want wipe-on-free behavior no matter what the performance cost, it seems reasonable to include it in this series.
[[email protected]: v8] Link: http://lkml.kernel.org/r/[email protected] [[email protected]: v9] Link: http://lkml.kernel.org/r/[email protected] [[email protected]: v10] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Alexander Potapenko [email protected] Acked-by: Kees Cook [email protected] Acked-by: Michal Hocko [email protected] [page and dmapool parts Acked-by: James Morris [email protected]] Cc: Christoph Lameter [email protected] Cc: Masahiro Yamada [email protected] Cc: "Serge E. Hallyn" [email protected] Cc: Nick Desaulniers [email protected] Cc: Kostya Serebryany [email protected] Cc: Dmitry Vyukov [email protected] Cc: Sandeep Patil [email protected] Cc: Laura Abbott [email protected] Cc: Randy Dunlap [email protected] Cc: Jann Horn [email protected] Cc: Mark Rutland [email protected] Cc: Marco Elver [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected]
Removed the drivers/infiniband/core/uverbs_ioctl.c part, which is not in android-common 4.14 kernel.
Change-Id: I6b5482fcafae89615e1d79879191fb6ce50d56cf Bug: 138435492 Test: Boot cuttlefish with and without Test: CONFIG_INIT_ON_ALLOC_DEFAULT_ON/CONFIG_INIT_ON_FREE_DEFAULT_ON Test: Boot an ARM64 mobile device with and without Test: CONFIG_INIT_ON_ALLOC_DEFAULT_ON/CONFIG_INIT_ON_FREE_DEFAULT_ON Signed-off-by: Alexander Potapenko [email protected] Signed-off-by: atndko [email protected]
UPSTREAM: kasan, mm: change hooks signatures
Upstream commit 0116523cfffa62aeb5aa3b85ce7419f3dae0c1b8.
Patch series "kasan: add software tag-based mode for arm64", v13.
This patchset adds a new software tag-based mode to KASAN [1]. (Initially this mode was called KHWASAN, but it got renamed, see the naming rationale at the end of this section).
The plan is to implement HWASan [2] for the kernel with the incentive, that it's going to have comparable to KASAN performance, but in the same time consume much less memory, trading that off for somewhat imprecise bug detection and being supported only for arm64.
The underlying ideas of the approach used by software tag-based KASAN are:
-
By using the Top Byte Ignore (TBI) arm64 CPU feature, we can store pointer tags in the top byte of each kernel pointer.
-
Using shadow memory, we can store memory tags for each chunk of kernel memory.
-
On each memory allocation, we can generate a random tag, embed it into the returned pointer and set the memory tags that correspond to this chunk of memory to the same value.
-
By using compiler instrumentation, before each memory access we can add a check that the pointer tag matches the tag of the memory that is being accessed.
-
On a tag mismatch we report an error.
With this patchset the existing KASAN mode gets renamed to generic KASAN, with the word "generic" meaning that the implementation can be supported by any architecture as it is purely software.
The new mode this patchset adds is called software tag-based KASAN. The word "tag-based" refers to the fact that this mode uses tags embedded into the top byte of kernel pointers and the TBI arm64 CPU feature that allows to dereference such pointers. The word "software" here means that shadow memory manipulation and tag checking on pointer dereference is done in software. As it is the only tag-based implementation right now, "software tag-based" KASAN is sometimes referred to as simply "tag-based" in this patchset.
A potential expansion of this mode is a hardware tag-based mode, which would use hardware memory tagging support (announced by Arm [3]) instead of compiler instrumentation and manual shadow memory manipulation.
Same as generic KASAN, software tag-based KASAN is strictly a debugging feature.
[1] https://www.kernel.org/doc/html/latest/dev-tools/kasan.html
[2] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
====== Rationale
On mobile devices generic KASAN's memory usage is significant problem. One of the main reasons to have tag-based KASAN is to be able to perform a similar set of checks as the generic one does, but with lower memory requirements.
Comment from Vishwath Mohan [email protected]:
I don't have data on-hand, but anecdotally both ASAN and KASAN have proven problematic to enable for environments that don't tolerate the increased memory pressure well. This includes
(a) Low-memory form factors - Wear, TV, Things, lower-tier phones like Go, (c) Connected components like Pixel's visual core [1].
These are both places I'd love to have a low(er) memory footprint option at my disposal.
Comment from Evgenii Stepanov [email protected]:
Looking at a live Android device under load, slab (according to /proc/meminfo) + kernel stack take 8-10% available RAM (~350MB). KASAN's overhead of 2x - 3x on top of it is not insignificant.
Not having this overhead enables near-production use - ex. running KASAN/KHWASAN kernel on a personal, daily-use device to catch bugs that do not reproduce in test configuration. These are the ones that often cost the most engineering time to track down.
CPU overhead is bad, but generally tolerable. RAM is critical, in our experience. Once it gets low enough, OOM-killer makes your life miserable.
====== Technical details
Software tag-based KASAN mode is implemented in a very similar way to the generic one. This patchset essentially does the following:
-
TCR_TBI1 is set to enable Top Byte Ignore.
-
Shadow memory is used (with a different scale, 1:16, so each shadow byte corresponds to 16 bytes of kernel memory) to store memory tags.
-
All slab objects are aligned to shadow scale, which is 16 bytes.
-
All pointers returned from the slab allocator are tagged with a random tag and the corresponding shadow memory is poisoned with the same value.
-
Compiler instrumentation is used to insert tag checks. Either by calling callbacks or by inlining them (CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE flags are reused).
-
When a tag mismatch is detected in callback instrumentation mode KASAN simply prints a bug report. In case of inline instrumentation, clang inserts a brk instruction, and KASAN has it's own brk handler, which reports the bug.
-
The memory in between slab objects is marked with a reserved tag, and acts as a redzone.
-
When a slab object is freed it's marked with a reserved tag.
Bug detection is imprecise for two reasons:
-
We won't catch some small out-of-bounds accesses, that fall into the same shadow cell, as the last byte of a slab object.
-
We only have 1 byte to store tags, which means we have a 1/256 probability of a tag match for an incorrect access (actually even slightly less due to reserved tag values).
Despite that there's a particular type of bugs that tag-based KASAN can detect compared to generic KASAN: use-after-free after the object has been allocated by someone else.
====== Testing
Some kernel developers voiced a concern that changing the top byte of kernel pointers may lead to subtle bugs that are difficult to discover. To address this concern deliberate testing has been performed.
It doesn't seem feasible to do some kind of static checking to find potential issues with pointer tagging, so a dynamic approach was taken. All pointer comparisons/subtractions have been instrumented in an LLVM compiler pass and a kernel module that would print a bug report whenever two pointers with different tags are being compared/subtracted (ignoring comparisons with NULL pointers and with pointers obtained by casting an error code to a pointer type) has been used. Then the kernel has been booted in QEMU and on an Odroid C2 board and syzkaller has been run.
This yielded the following results.
The two places that look interesting are:
is_vmalloc_addr in include/linux/mm.h is_kernel_rodata in mm/util.c
Here we compare a pointer with some fixed untagged values to make sure that the pointer lies in a particular part of the kernel address space. Since tag-based KASAN doesn't add tags to pointers that belong to rodata or vmalloc regions, this should work as is. To make sure debug checks to those two functions that check that the result doesn't change whether we operate on pointers with or without untagging has been added.
A few other cases that don't look that interesting:
Comparing pointers to achieve unique sorting order of pointee objects (e.g. sorting locks addresses before performing a double lock):
tty_ldisc_lock_pair_timeout in drivers/tty/tty_ldisc.c pipe_double_lock in fs/pipe.c unix_state_double_lock in net/unix/af_unix.c lock_two_nondirectories in fs/inode.c mutex_lock_double in kernel/events/core.c
ep_cmp_ffd in fs/eventpoll.c fsnotify_compare_groups fs/notify/mark.c
Nothing needs to be done here, since the tags embedded into pointers don't change, so the sorting order would still be unique.
Checks that a pointer belongs to some particular allocation:
is_sibling_entry in lib/radix-tree.c object_is_on_stack in include/linux/sched/task_stack.h
Nothing needs to be done here either, since two pointers can only belong to the same allocation if they have the same tag.
Overall, since the kernel boots and works, there are no critical bugs. As for the rest, the traditional kernel testing way (use until fails) is the only one that looks feasible.
Another point here is that tag-based KASAN is available under a separate config option that needs to be deliberately enabled. Even though it might be used in a "near-production" environment to find bugs that are not found during fuzzing or running tests, it is still a debug tool.
====== Benchmarks
The following numbers were collected on Odroid C2 board. Both generic and tag-based KASAN were used in inline instrumentation mode.
Boot time [1]:
- ~1.7 sec for clean kernel
- ~5.0 sec for generic KASAN
- ~5.0 sec for tag-based KASAN
Network performance [2]:
- 8.33 Gbits/sec for clean kernel
- 3.17 Gbits/sec for generic KASAN
- 2.85 Gbits/sec for tag-based KASAN
Slab memory usage after boot [3]:
- ~40 kb for clean kernel
- ~105 kb (~260% overhead) for generic KASAN
- ~47 kb (~20% overhead) for tag-based KASAN
KASAN memory overhead consists of three main parts:
- Increased slab memory usage due to redzones.
- Shadow memory (the whole reserved once during boot).
- Quaratine (grows gradually until some preset limit; the more the limit, the more the chance to detect a use-after-free).
Comparing tag-based vs generic KASAN for each of these points:
- 20% vs 260% overhead.
- 1/16th vs 1/8th of physical memory.
- Tag-based KASAN doesn't require quarantine.
[1] Time before the ext4 driver is initialized.
[2] Measured as iperf -s & iperf -c 127.0.0.1 -t 30.
[3] Measured as cat /proc/meminfo | grep Slab.
====== Some notes
A few notes:
-
The patchset can be found here: https://github.com/xairy/kasan-prototype/tree/khwasan
-
Building requires a recent Clang version (7.0.0 or later).
-
Stack instrumentation is not supported yet and will be added later.
This patch (of 25):
Tag-based KASAN changes the value of the top byte of pointers returned from the kernel allocation functions (such as kmalloc). This patch updates KASAN hooks signatures and their usage in SLAB and SLUB code to reflect that.
Link: http://lkml.kernel.org/r/aec2b5e3973781ff8a6bb6760f8543643202c451.1544099024.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov [email protected] Reviewed-by: Andrey Ryabinin [email protected] Reviewed-by: Dmitry Vyukov [email protected] Cc: Christoph Lameter [email protected] Cc: Mark Rutland [email protected] Cc: Will Deacon [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected] Signed-off-by: Andrey Konovalov [email protected] Change-Id: Iefef37d9c54869df0873af75345262a24150ee80 Bug: 128674696
God I hate discord, fixed mention prefixes to work again. Also added a presence so you don't have to just remember the prefix, it tells you
fuck you failed to generate sound error, i'll fix all this shit shitcode at the same time
sched/core: Implement new approach to scale select_idle_cpu()
Hackbench recently suffered a bunch of pain, first by commit:
4c77b18cf8b7 ("sched/fair: Make select_idle_cpu() more aggressive")
and then by commit:
c743f0a5c50f ("sched/fair, cpumask: Export for_each_cpu_wrap()")
which fixed a bug in the initial for_each_cpu_wrap() implementation that made select_idle_cpu() even more expensive. The bug was that it would skip over CPUs when bits were consequtive in the bitmask.
This however gave me an idea to fix select_idle_cpu(); where the old scheme was a cliff-edge throttle on idle scanning, this introduces a more gradual approach. Instead of stopping to scan entirely, we limit how many CPUs we scan.
Initial benchmarks show that it mostly recovers hackbench while not hurting anything else, except Mason's schbench, but not as bad as the old thing.
It also appears to recover the tbench high-end, which also suffered like hackbench.
Tested-by: Matt Fleming [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Cc: Chris Mason [email protected] Cc: Linus Torvalds [email protected] Cc: Mike Galbraith [email protected] Cc: Peter Zijlstra [email protected] Cc: Thomas Gleixner [email protected] Cc: [email protected] Cc: kitsunyan [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar [email protected] Signed-off-by: Raphiel Rollerscaperers [email protected] Signed-off-by: DennySPB [email protected]
Plasmeme support baybee
SOOOOOO, what this does is: Adds two new uplink items: Plasmaman Syndicate Hardsuits. They are more costly, however they provide innate space protection and no slowdown. Also adds a paper that warns plasmemes that the normal hardsuits won't work. Oh yeah and also unfucks my adding it on the .dme using / instead of \
Build webui from multiple components into a single bundle ... ... and embed it in application's main binary file directly: well, partial success. Webview-rs uses MS Edge as a web engine on Windows, and... where do I begin.
-
You can't run local web server and get assets from there because Microsoft's security policies concerning Edge sandboxing directly prevent this.
-
You also can't use file:// URLs in Edge for the same reason.
So, what CAN you actually do if you want to embed a whole web frontend into your application?
Well. You can bundle all of your assets into a single file, embed it using Rust's preprocessing directives (god I'm starting to love these), and inject them as a uu64enc'd text directly through URL using WebView's navigate() function, yay!
- That's quite a hack here.
- And it's also quite slow (Openlayers library is like 900kb and it load time is near 30 seconds on my machine).
...
So, okay, we're embedding everething besides it, and we continue to download openlayers library from web cdn each time we initialize.
Yeah, this is far from ideal, but for a hobby project that already uses internet connection for OSM data?..
I don't like this approach, but let's leave things as they are for now. At least now we can bundle something resembling a modern UI framework into the application, let's start from there and return to our issue with resource embedding sometime later.