[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
IMPORTANT TEST BUILD; https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_binder_rt_89604cd.zip

So, Here is my (hopefully) first kernel build where google camera should not crash at all.... ***Please test, test, test***. There could be other subtle bugs introduced, as I have substantially changed the behaviour of binder.... For those who may not know what Binder is; Binder is respsonible for IPC (Inter-proccess communication, among other things) on the android platform. It is implemented as linux kernel driver.

Here's a little 101 on the subject/Binder;

https://sujaiantony.wordpress.com/2011/12/28/an-android-101-an-overview-on-binder-framework/

Some slides (there are some good diagrams in here) that show a bit more of an indepth overview

https://www.dre.vanderbilt.edu/~schmidt/cs282/PDFs/android-binder-ipc.pdf

The problem; some of binder's critical pipelines are quite sensitive to jitter / require low-latency. There are all sorts of implementation of binder out there, with different hacks and workarounds to ensure that these pipelines work correctly, aren't disrupted and the code isn't racy (causing collisions, threads to crash, buffers not meeting their destination on time, etc)... There have been MANY attempts to solve these issues... (I think it is solved in android-4.9 kernel, AFAICT) and the Pixel 2 also has an interesting implementation (quite different from many other versions that i've looked at)...

Our version of binder has somewhat fine-grained locking (taken from the aosp/android-4.4 common tree). The problem has been that these critical paths / pipelines have been getting disrupted (HDR+ processing has highlighted the issue) and things 'go bang'.... Back in 2015, there was an attempt made to replace some of binders locks (mutexes) with rt_mutexes ~ these changes were reversed - due to causing problems.... Mutexes/locks are used to avoid race conditions, for things like synchronization / very critical code paths.... The 2015 code/test happened *before* our particular version of binder existed.... So, after reading through many kernel mailing list related threads on the subject =>

I decided to try a little experiment

;

What if I was to replace all of the locking in binder, ion and friends???

So that is exactly what I have done. Last night's build, did indeed stop the camera from crashing, after the initial crash on start (which was a race condition between between binder and ion...). Today's build addresses that && converts all remaining locks in binder and ion to make use of rt_mutexes, rather than mutexes....

On top of all of this; I have also merged in a number of patches for binder that re-work how it handles buffers, lowmemorykiller, etc. - Most are in use on several devices, just not present in AOSP android-4.4 common tree for binder... I've also decided that I'm going to try and replace the one last call (that requires a kernel function that we don't have), but currently, there is a little hack in there to make it all work - without that call.

So hopefully this irons out any crashing issues, but it needs to be tested quite a lot. Our binder is quite a bit different from other implementations in certain key ways..... But I've needed to adapt it for our kernel; which also is quite different than other Marlin kernels.

report back any/all issues. thanks