ext4: fix trim with spinlock around ext4_mb_load_buddy()

On a omap3630 like device trim causes problems
on the first bootup. This produces following oops;

<4>[  226.061492] [<c01dbd3c>] (vsnprintf+0x324/0x364) from [<c01dbdec>] (vscnprintf+0xc/0x24)
<4>[  226.061492] [<c01dbdec>] (vscnprintf+0xc/0x24) from [<c0063cb4>] (vprintk+0x144/0x3bc)
<4>[  226.061523] [<c0063cb4>] (vprintk+0x144/0x3bc) from [<c0130108>] (ext4_error+0x30/0x54)
<4>[  226.061553] [<c0130108>] (ext4_error+0x30/0x54) from [<c013cd1c>] (ext4_trim_fs+0x188/0x27c)
<4>[  226.061553] [<c013cd1c>] (ext4_trim_fs+0x188/0x27c) from [<c0128348>] (ext4_ioctl+0x7f8/0x89c)
<4>[  226.061584] [<c0128348>] (ext4_ioctl+0x7f8/0x89c) from [<c00dd0cc>] (vfs_ioctl+0x2c/0x8c)
<4>[  226.061614] [<c00dd0cc>] (vfs_ioctl+0x2c/0x8c) from [<c00dd778>] (do_vfs_ioctl+0x558/0x5c4)
<4>[  226.061614] [<c00dd778>] (do_vfs_ioctl+0x558/0x5c4) from [<c00dd818>] (sys_ioctl+0x34/0x54)
<4>[  226.061645] [<c00dd818>] (sys_ioctl+0x34/0x54) from [<c0032f40>] (ret_fast_syscall+0x0/0x2c)

ext4_mb_load_buddy() won't be called in a secure context
and therefore kernel crashes while trim gets executed
when the CPU is under heavy pressure. Ideally this shouldn't
happen at all, but since ext4 partition is mounted with discard
option this is a serious problem.

In my test scenario the problem wasn't reproducable with this patch.
This needs confirmation.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>