[Galaxy S II General] Tungstwenty:
This was discussed, yes, but IMO those were

speculations

. The fact that there wasn't any report doesn't mean it's

impossible

.

In the same way,

I'm also speculating

:)

But what I wrote is based on *some* facts, i.e., code inspection, although I'm not sure of it all.

Fact:

Stock kernels LQ5, LPM and LPO (checked all 3 of them) have the dangerous erase operation enabled.

Previous stock kernels like LPG did not have it enabled.

Almost certain:

Both the stock recovery and the LQ5 CF-Root invoke the linux syscall for partition erase when wiping /cache

Unknown:

Could the erase operation on this particular partition generate physical failures, like /data appeared to do? I don't know.

Unknown:

What changed in CF-Root when it was re-released for LQ5? Chainfire has probably changed something, based on his post ("... should be fixed but still be careful ..."). I imagine he might have changed the /data part (I had no easy way to compare that), but I'm almost certain that /cache is still wiped using an erase.

This is a summary of what I saw. Based on this, I could give you this example:

Imagine you have a Windows XP operating system (not including the apps) - that would be the equivalent of the big part of the kernel.

Now imagine you have a physical device such as a hard drive - the same as the memory chip.

Running within the operating system you have a module (a driver), be it for a hard disk on Windows, of for a memory chip on this kernel.

The applications, if they have the permissions for it, request from the kernel to do a certain operation on a certain physical device. Example: read sector X of the hard disk.

The kernel will identify the driver that controls the target physical device, and ask the driver to handle that request.

Back to the hard disk, imagine that for some reason a few hard disks are defective and if you request more than 500 sectors in one single call, the disk will spin faster than it should, or the needle will move too much and hit the case of the disk on the inside, damaging it. Knowing this, the people that programmed the driver had included a limit that only allows you (client apps) to request at most 250 sectors at a time. Any individual request where sector_count > 250 is blocked by the driver because there's a small possibility that the physical disk could be damaged, since its motor might be one of the bad ones.

If you can imagine this example, you have exactly the same situation here.

You have the android kernel, which is simply validating the requests from the apps (what linux user is running this app? can you access this device?). If the app request is understood and permissions allow you to do it, the request is sent to the appropriate driver (which is included in the zImage, along with the kernel core). BUT the driver isn't validating if you're "requesting a dangerous number of blocks", or in our situation, if you're asking the memory controller to erase data (instead of overwriting with 0's or whatever it does in alternative).

I could still work, true, but the protection isn't there as it used to be.

I don't have a clue under which conditions the problem might happen. Heck, since /cache is only 100Mb and /data is 2Gb, the damage can only occur when erasing more than 1Gb or whatever. I simply don't know.

What I do know is that the driver should be validating those requests and don't allow erases at all, like it always did till the 4.0.4 stock kernels.

We can go on and discuss once again whose fault is it, or even if is just a theoretical possibility but that will never show up in practice, which can totally be true. But I won't risk it.

Also, remember this: given this lack of validation, any app (CWM, apps that include native libraries, etc.) running with the appropriate permissions can basically ask from the kernel (with or without intention) to do something that can permanently damage it. And the kernel (the driver to be more precise) will happily allow it.

---------- Post added at 06:53 PM ---------- Previous post was at 06:49 PM ----------

It's safe. Because it is build from sources, the unsafe operation is changed so it never runs.

To have it working properly with 4.0.4 ROMs (such as LPO) you'll need to install this patch to make the camera and video properly show the image on the screen.

---------- Post added at 06:56 PM ---------- Previous post was at 06:53 PM ----------

You need to install this patch

---------- Post added at 07:03 PM ---------- Previous post was at 06:56 PM ----------

I'm glad we're on the same boat then, you can have a look by yourself and perhaps enlighten some of the folks around here like Gillion :D

On XWLPO you can find it at 0x594ec0:

ORR R1, R1, #0x400

Have a look at include/linux/mmc/host.h and the caps section; you'll see what the 0x400 is about (which your signature already mentions :))

Compare that to 0x55f9a4 on XWLPG and notice the difference on that code area.