+ fix getting subversion revision number -> same like this

"Getting svnversion revision fails if the output is non-english.
This commit fixes this issue." - codeworkx

e.g.: svnversion | grep -qv exported && echo -n 'Revision: ' && svnversion

-> Revision: Nicht versioniertes Verzeichnis
ext4: fix unjournaled inode bitmap modification

commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed
ext4_new_inode() such that the inode bitmap was being modified
outside a transaction, which could lead to corruption, and was
discovered when journal_checksum found a bad checksum in the
journal during log replay.

Nix ran into this when using the journal_async_commit mount
option, which enables journal checksumming.  The ensuing
journal replay failures due to the bad checksums led to
filesystem corruption reported as the now infamous
"Apparent serious progressive ext4 data corruption bug"

[ Changed by tytso to only call ext4_journal_get_write_access() only
  when we're fairly certain that we're going to allocate the inode. ]

I've tested this by mounting with journal_checksum and
running fsstress then dropping power; I've also tested by
hacking DM to create snapshots w/o first quiescing, which
allows me to test journal replay repeatedly w/o actually
power-cycling the box.  Without the patch I hit a journal
checksum error every time.  With this fix it survives
many iterations.

Reported-by: Nix <nix@esperi.org.uk>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
loop: Make explicit loop device destruction lazy

xfstests has always had random failures of tests due to loop devices
failing to be torn down and hence leaving filesytems that cannot be
unmounted. This causes test runs to immediately stop.

Over the past 6 or 7 years we've added hacks like explicit unmount
-d commands for loop mounts, losetup -d after unmount -d fails, etc,
but still the problems persist.  Recently, the frequency of loop
related failures increased again to the point that xfstests 259 will
reliably fail with a stray loop device that was not torn down.

That is despite the fact the test is above as simple as it gets -
loop 5 or 6 times running mkfs.xfs with different paramters:

        lofile=$(losetup -f)
        losetup $lofile "$testfile"
        "$MKFS_XFS_PROG" -b size=512 $lofile >/dev/null || echo "mkfs failed!"
        sync
        losetup -d $lofile

And losteup -d $lofile is failing with EBUSY on 1-3 of these loops
every time the test is run.

Turns out that blkid is running simultaneously with losetup -d, and
so it sees an elevated reference count and returns EBUSY.  But why
is blkid running? It's obvious, isn't it? udev has decided to try
and find out what is on the block device as a result of a creation
notification. And it is racing with mkfs, so might still be scanning
the device when mkfs finishes and we try to tear it down.

So, make losetup -d force autoremove behaviour. That is, when the
last reference goes away, tear down the device. xfstests wants it
*gone*, not causing random teardown failures when we know that all
the operations the tests have specifically run on the device have
completed and are no longer referencing the loop device.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
MALI updates by CM-TEAM.
MALI not USED! drivers cleanup! nothing to see here.
MALI: Code Style fix
GOVS CPU PWR BOOST! + Kernel Flags Tuning + Cleaning MALI.
Performance boosted allot!
Kernel size reduced!
Added letest Extweaks + SuperSU to kernel payload!
Now extweak will be installed with kernel. not Stweaks. (for now)
Kernel 7.6 ICS + JB MALI + config tune/remove.
Balanced HYPER + Ondemand GOVS.
+ full sync ...
Merge remote-tracking branch 'dorimanx/master-jelly-bean' into master-3.0.y

Conflicts:
	drivers/media/video/samsung/mali_r2p3/Makefile
	drivers/media/video/samsung/mali_r2p3/Makefile.common
	drivers/media/video/samsung/mali_r3p0/Makefile
	drivers/media/video/samsung/mali_r3p1_lsi/Kbuild_module
	drivers/media/video/samsung/mali_r3p1_lsi/Makefile
	drivers/media/video/samsung/ump_r3p0_lsi/Makefile.common
	drivers/media/video/samsung/ump_r3p1_lsi/Makefile
	drivers/media/video/samsung/ump_r3p1_lsi/Makefile.common

+ merge ...