[Android Software/Hacking General [Developers Only]] Lanchon:
Is It Safe To TRIM A Device Affected By Brickbug?

Maybe. Folklore says no, but there are good reasons to believe it is safe. Testing, possibly destructive, is required.

Indie developers' fix disables all trim and erase commands sent to the eMMC. Samsung's fix converts secure erase and trim requests to their non-secure counterparts and dispatch them. (Trim and erase are essentially the same function using different arguments.) The non-secure versions are what we need for performance. The secure versions are needed for privacy, to actually assure data is deleted from the eMMC, for instance when wiping a phone clean before selling it. (Note that the non-secure commands will typically wipe beyond recovery unless you are the NSA or something like that: the data becomes inaccessible and you would need to side step the FTL controller and access the flash directly to get to it, which requires physically dissecting the module or else hacking the FTL firmware.)

People I have talked to simply doubt that Samsung's fix is enough, maybe for no good reason. Although I am very critical of Samsung on many fronts as other posts in this thread clearly show (to the point of promoting a total boycott of the brand), I will play the devil's advocate in this case and try to convince you that maybe Samsung got it right this time.

There is no question that secure erase and trim trigger the bug and brick the eMMC and thus the device. The question is whether non-secure erase and trim are safe or not. Folklore says no, you be the judge:

Reasons to believe non-secure erase and trim are unsafe:

Samsung showed ineptitude during this whole mess and cannot be trusted.

Secure and non-secure erase and trim commands have frighteningly similar names.

Reasons to believe non-secure erase and trim are safe:

I could not find a single documented case of bricking due to an non-secure command anywhere on the net. I have also talked to Entropy512 the brickbug hero and to the author of the LagFix app and they could not single out any such event.

Samsung investigated the bug in their secret firmware and definitely found it because they fixed it in later versions. Knowing exactly what was wrong with the firmware, and having been shown how indie developers fixed the bug, Samsung decided to implement a different fix that instead converted secure commands to non-secure, presumably because they know that non-secure commands are safe. (But some think it could just be humongous ineptitude.)

They had enough confidence in their fix to push it upstream with enough dedication as to apparently have it mainlined. I am not an expert on linux kernel politics, but this fix apparently made it all the way up into none other than Linus Torvalds git tree. I think this means that all linux kernels everywhere, from desktops to supercomputers, will now have this silly brickbug patch in their kernels. I can only imagine adequate effort has been expended in verifying its effectiveness.

Typically Samsung's stock 4.1.2 androids include the patch (Galaxy S2 I9100 4.1.2 has it for sure), and I could not find accounts of brickings using Sammy's patched stock androids anywhere on the net.

Finally, and more convincingly to me, despite their similar names, secure and non-secure commands are completely different beasts. Six months ago i discussed how a very naive FTL could be implemented in this post with the intention of showing precisely that. If you care to to read the post you will notice that:

Implementations of secure and non-secure erase are extremely different.

The implementation of secure erase is vastly more complicated.

The implementation of non-secure erase is actually a subset of the implementation of write. Thus, if write does not trigger brickbug, so should not non-secure erase.

TODO: Investigate this: CyanogenMod's brickbug page maintainer seems to imply that running LagFix (which trims) while using a patched rom is safe. But is he referring to Samsung's or devs' patch? It should be Samsung's, because if it is devs' then LagFix would not work.

WARNING: There is a different bricking bug called TRIM bug that affects TRIM on a specific eMMC. Apparently it has only been observed on the Nook HD+. (But how can we be sure that it is not in other eMMCs (including brickbug-free eMMCs) if TRIM in these modules has never been massively put to use and tried?) The kernel patch mentioned seems to add support for the eMMC DISCARD command on Samsung moviNAND 4.41+ eMMCs and then choose it over TRIM while doing file system trimming. It is not apparent anywhere that this is a workaround for a bug, but by preferring DISCARD over TRIM it may sidestep a TRIM issue. DISCARD is a new command only featured in newer eMMCs. It is similar to TRIM but enables faster implementations. The patch is Samsung-specific but not specific to any eMMC device. It could be ported to any kernel but wont help unless the eMMC is moviNAND 4.41+. Note that older Samsung eMMCs could be affected by the TRIM bug, although I could not find any information online to support this hypothesis.