fs: ext3/4: enable xattr (for 4.4)

New updater script needs newer APIs.
This is a compatibility patch for the kernel
which enables the xattr for both filesystems (ext3/4).

It also enables the securtiy option for both, which
might help SELinux (anyway, i don't like it...).

Fix also a bug in ext3_trim_all_free()

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
ext3: Add FITRIM handling

The ioctl takes fstrim_range structure (defined in include/linux/fs.h) as an
argument specifying a range of filesystem to trim and the minimum size of an
continguous extent to trim. After the FITRIM is done, the number of bytes
passed from the filesystem down the block stack to the device for potential
discard is stored in fstrim_range.len.  This number is a maximum discard amount
from the storage device's perspective, because FITRIM called repeatedly will
keep sending the same sectors for discard.  fstrim_range.len will report the
same potential discard bytes each time, but only sectors which had been written
to between the discards would actually be discarded by the storage device.
Further, the kernel block layer reserves the right to adjust the discard ranges
to fit raid stripe geometry, non-trim capable devices in a LVM setup, etc.
These reductions would not be reflected in fstrim_range.len.

Thus fstrim_range.len can give the user better insight on how much storage
space has potentially been released for wear-leveling, but it needs to be one
of only one criteria the userspace tools take into account when trying to
optimize calls to FITRIM.

Thanks to Greg Freemyer <greg.freemyer@gmail.com> for better commit message.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: speed up file creates by optimizing rec_len functions

The addition of 64k block capability in the rec_len_from_disk
and rec_len_to_disk functions added a bit of math overhead which
slows down file create workloads needlessly when the architecture
cannot even support 64k blocks, thanks to page size limits.

Similar changes already exist in the ext4 codebase.

The directory entry checking can also be optimized a bit
by sprinkling in some unlikely() conditions to move the
error handling out of line.

bonnie++ sequential file creates on a 512MB ramdisk speeds up
from about 77,000/s to about 82,000/s, about a 6% improvement.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: Adjust trim start with first_data_block.

As we have make the consense in the e-mail[1], the trim start should
be added with first_data_block. So this patch fulfill it and remove
the check for start < first_data_block.

[1] http://www.spinics.net/lists/linux-ext4/msg22737.html

Cc: Jan Kara <jack@suse.cz>
Cc: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: speed up group trim with the right free block count.

When we trim some free blocks in a group of ext3, we should
calculate the free blocks properly and check whether there are
enough freed blocks left for us to trim. Current solution will
only calculate free spaces if they are large for a trim which
is wrong.

Let us see a small example:
a group has 1.5M free which are 300k, 300k, 300k, 300k, 300k.
And minblocks is 1M. With current solution, we have to iterate
the whole group since these 300k will never be subtracted from
1.5M. But actually we should exit after we find the first 2
free spaces since the left 3 chunks only sum up to 900K if we
subtract the first 600K although they can't be trimed.

Cc: Jan Kara <jack@suse.cz>
Cc: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: Fix an overflow in ext3_trim_fs.

In a bs=4096 volume, if we call FITRIM with the following parameter as
fstrim_range(start = 102400, len = 134144000, minlen = 10240), with the
following code:
if (len >= EXT3_BLOCKS_PER_GROUP(sb))
        len -= (EXT3_BLOCKS_PER_GROUP(sb) - first_block);
else
        last_block = first_block + len;

So if len < EXT3_BLOCKS_PER_GROUP while first_block + len >
EXT3_BLOCKS_PER_GROUP, last_block will be set to an overflow value
which exceeds EXT3_BLOCKS_PER_GROUP.

This patch fixes it and adjusts len and last_block accordingly.

Cc: Lukas Czerner <lczerner@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: Return -EINVAL when start is beyond the end of fs in ext3_trim_fs()

We should return -EINVAL when the FITRIM parameters are not sane, but
currently we are exiting silently if start is beyond the end of the
file system. This commit fixes this so we return -EINVAL as other file
systems do.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
CC: Jan Kara <jack@suse.cz>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: fix start and len arguments handling in ext3_trim_fs()

The overflow might happen when passing blocknr into
ext3_get_group_no_and_offset(), because it expects type ext3_fsblk_t
which might be smaller than uint64_t. This will most likely happen when
calling FITRIM with the default argument len = ULLONG_MAX.

Fix this by using "end" variable instead of "start+len" as it is easier
to get right and specifically check that the end is not beyond the end
of the file system, so we are sure that the result of
get_group_no_and_offset() will not overflow. Otherwise truncate it to
the size of the file system.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Jan Kara <jack@suse.cz>
ext3: Avoid underflow of in ext3_trim_fs()

Currently if len argument in ext3_trim_fs() is smaller than one block,
the 'end' variable underflow. Avoid that by returning EINVAL if len is
smaller than file system block.

Also remove useless unlikely().

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
fix compile latest wifi drivers
misc: add dynamic writeback interface

Before this patch, the deamon for flushing
dirty pages kicks in every 600 ms. This patch
changes the behaviour a little bit. While suspended
it flushes more pages (every 500 ms) and while the
the device is awake and in use it flushes only every
4 s to gain a little performance boost.

This is fully controllable;

echo 1 > /sys/class/misc/wirteback/writeback_enabled
(1 = On (default), 0 = off (and behaviour before this
patch).

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

Conflicts:
	arch/arm/configs/mapphone_defconfig
	drivers/misc/Kconfig
	drivers/misc/Makefile
	mm/page-writeback.c
display: add basic display control

While i am trying to solve the wakeup delay i noticed
that the panel driver uses different brightness values
for different phones (red / green lense).
With a small display control driver those values
can be easily exposed to userspace.
Green ones used to have 0x09, those colors looked a bit
washed out.

echo xx > /sys/class/misc/display_control/display_brightness_value

Where xx can be (theoretically) a value between 0 and 255.
0  will set the screen to almost 0,
9  will set the screen to some kind of blue-washed colors,
31 will set the screen to more warmer colors (new default).

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

Conflicts:
	arch/arm/configs/mapphone_defconfig
	drivers/video/omap2/displays/panel-mapphone.c
add extra free kbytes tunable

Add a userspace visible knob to tell the VM to keep an extra amount
of memory free, by increasing the gap between each zone's min and
low watermarks.

This is useful for realtime applications that call system
calls and have a bound on the number of allocations that happen
in any short time period.  In this application, extra_free_kbytes
would be left at an amount equal to or larger than than the
maximum number of allocations that happen in any burst.

It may also be useful to reduce the memory use of virtual
machines (temporarily?), in a way that does not cause memory
fragmentation like ballooning does.

[ccross]
Revived for use on old kernels where no other solution exists.
The tunable will be removed on kernels that do better at avoiding
direct reclaim.

Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e
Signed-off-by: Rik van Riel<riel@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	kernel/sysctl.c
fs: disable dyn fsync and enable fsync

Some users reported turning off dynamic fsync
may prevent the data corruption bug, so i will
disable it by default and enable fsync back to
its original state.

This may cost a bit of performance, but at least
it can be considered as stable.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
Merge remote-tracking branch 'quarx/AeroKernel' into AeroKernel

Conflicts:
	arch/arm/configs/mb526_cm10.1_defconfig
add joydev and lost usb storage to defconfig