Merge android-4.9.166 (0166b9e3) into msm-4.9

		The unit size is one block, now only support configuring in range

		of [1, 512].

What:          /sys/fs/f2fs/<disk>/umount_discard_timeout

Date:          January 2019

Contact:       "Jaegeuk Kim" <jaegeuk@kernel.org>

Description:

		Set timeout to issue discard commands during umount.

		Default: 5 secs

What:		/sys/fs/f2fs/<disk>/max_victim_search

Date:		January 2014

Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>

dm_bow (backup on write)

========================

dm_bow is a device mapper driver that uses the free space on a device to back up

data that is overwritten. The changes can then be committed by a simple state

change, or rolled back by removing the dm_bow device and running a command line

utility over the underlying device.

dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.

It is only possible to go from state 0 (initial state) to state 1, and then from

state 1 to state 2.

State 0: dm_bow collects all trims to the device and assumes that these mark

free space on the overlying file system that can be safely used. Typically the

mount code would create the dm_bow device, mount the file system, call the

FITRIM ioctl on the file system then switch to state 1. These trims are not

propagated to the underlying device.

State 1: All writes to the device cause the underlying data to be backed up to

the free (trimmed) area as needed in such a way as they can be restored.

However, the writes, with one exception, then happen exactly as they would

without dm_bow, so the device is always in a good final state. The exception is

that sector 0 is used to keep a log of the latest changes, both to indicate that

we are in this state and to allow rollback. See below for all details. If there

isn't enough free space, writes are failed with -ENOSPC.

State 2: The transition to state 2 triggers replacing the special sector 0 with

the normal sector 0, and the freeing of all state information. dm_bow then

becomes a pass-through driver, allowing the device to continue to be used with

minimal performance impact.

Usage

=====

dm-bow takes one command line parameter, the name of the underlying device.

dm-bow will typically be used in the following way. dm-bow will be loaded with a

suitable underlying device and the resultant device will be mounted. A file

system trim will be issued via the FITRIM ioctl, then the device will be

switched to state 1. The file system will now be used as normal. At some point,

the changes can either be committed by switching to state 2, or rolled back by

unmounting the file system, removing the dm-bow device and running the command

line utility. Note that rebooting the device will be equivalent to unmounting

and removing, but the command line utility must still be run

Details of operation in state 1

===============================

dm_bow maintains a type for all sectors. A sector can be any of:

SECTOR0

SECTOR0_CURRENT

UNCHANGED

FREE

CHANGED

BACKUP

SECTOR0 is the first sector on the device, and is used to hold the log of

changes. This is the one exception.

SECTOR0_CURRENT is a sector picked from the FREE sectors, and is where reads and

writes from the true sector zero are redirected to. Note that like any backup

sector, if the sector is written to directly, it must be moved again.

UNCHANGED means that the sector has not been changed since we entered state 1.

Thus if it is written to or trimmed, the contents must first be backed up.

FREE means that the sector was trimmed in state 0 and has not yet been written

to or used for backup. On being written to, a FREE sector is changed to CHANGED.

CHANGED means that the sector has been modified, and can be further modified

without further backup.

BACKUP means that this is a free sector being used as a backup. On being written

to, the contents must first be backed up again.

All backup operations are logged to the first sector. The log sector has the

format:

--------------------------------------------------------

| Magic | Count | Sequence | Log entry | Log entry | …

--------------------------------------------------------

Magic is a magic number. Count is the number of log entries. Sequence is 0

initially. A log entry is

-----------------------------------

| Source | Dest | Size | Checksum |

-----------------------------------

When SECTOR0 is full, the log sector is backed up and another empty log sector

created with sequence number one higher. The first entry in any log entry with

sequence > 0 therefore must be the log of the backing up of the previous log

sector. Note that sequence is not strictly needed, but is a useful sanity check

and potentially limits the time spent trying to restore a corrupted snapshot.

On entering state 1, dm_bow has a list of free sectors. All other sectors are

unchanged. Sector0_current is selected from the free sectors and the contents of

sector 0 are copied there. The sector 0 is backed up, which triggers the first

log entry to be written.

disable_ext_identify   Disable the extension list configured by mkfs, so f2fs

                       does not aware of cold files such as media files.

inline_xattr           Enable the inline xattrs feature.

noinline_xattr         Disable the inline xattrs feature.

inline_xattr_size=%u   Support configuring inline xattr size, it depends on

		       flexible inline xattr feature.

inline_data            Enable the inline data feature: New created small(<~3.4k)

                       files can be written into inode block.

inline_dentry          Enable the inline dir feature: data in new created

Raw pointer value SHOULD be printed with %p. The kernel supports

the following extended format specifiers for pointer types:

Pointer Types:

Pointers printed without a specifier extension (i.e unadorned %p) are

hashed to give a unique identifier without leaking kernel addresses to user

space. On 64 bit machines the first 32 bits are zeroed. If you _really_

want the address see %px below.

	%p	abcdef12 or 00000000abcdef12

Symbols/Function Pointers:

	%pF	versatile_init+0x0/0x110

Kernel Pointers:

	%pK	0x01234567 or 0x0123456789abcdef

	%pK	01234567 or 0123456789abcdef

	For printing kernel pointers which should be hidden from unprivileged

	users. The behaviour of %pK depends on the kptr_restrict sysctl - see

	Documentation/sysctl/kernel.txt for more details.

Unmodified Addresses:

	%px	01234567 or 0123456789abcdef

	For printing pointers when you _really_ want to print the address. Please

	consider whether or not you are leaking sensitive information about the

	Kernel layout in memory before printing pointers with %px. %px is

	functionally equivalent to %lx. %px is preferred to %lx because it is more

	uniquely grep'able. If, in the future, we need to modify the way the Kernel

	handles printing pointers it will be nice to be able to find the call

	sites.

Struct Resources:

	%pr	[mem 0x60000000-0x6fffffff flags 0x2200] or

         SipHash - a short input PRF

-----------------------------------------------

Written by Jason A. Donenfeld <jason@zx2c4.com>

SipHash is a cryptographically secure PRF -- a keyed hash function -- that

performs very well for short inputs, hence the name. It was designed by

cryptographers Daniel J. Bernstein and Jean-Philippe Aumasson. It is intended

as a replacement for some uses of: `jhash`, `md5_transform`, `sha_transform`,

and so forth.

SipHash takes a secret key filled with randomly generated numbers and either

an input buffer or several input integers. It spits out an integer that is

indistinguishable from random. You may then use that integer as part of secure

sequence numbers, secure cookies, or mask it off for use in a hash table.

1. Generating a key

Keys should always be generated from a cryptographically secure source of

random numbers, either using get_random_bytes or get_random_once:

siphash_key_t key;

get_random_bytes(&key, sizeof(key));

If you're not deriving your key from here, you're doing it wrong.

2. Using the functions

There are two variants of the function, one that takes a list of integers, and

one that takes a buffer:

u64 siphash(const void *data, size_t len, const siphash_key_t *key);

And:

u64 siphash_1u64(u64, const siphash_key_t *key);

u64 siphash_2u64(u64, u64, const siphash_key_t *key);

u64 siphash_3u64(u64, u64, u64, const siphash_key_t *key);

u64 siphash_4u64(u64, u64, u64, u64, const siphash_key_t *key);

u64 siphash_1u32(u32, const siphash_key_t *key);

u64 siphash_2u32(u32, u32, const siphash_key_t *key);

u64 siphash_3u32(u32, u32, u32, const siphash_key_t *key);

u64 siphash_4u32(u32, u32, u32, u32, const siphash_key_t *key);

If you pass the generic siphash function something of a constant length, it

will constant fold at compile-time and automatically choose one of the

optimized functions.

3. Hashtable key function usage:

struct some_hashtable {

	DECLARE_HASHTABLE(hashtable, 8);

	siphash_key_t key;

};

void init_hashtable(struct some_hashtable *table)

{

	get_random_bytes(&table->key, sizeof(table->key));

}

static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input)

{

	return &table->hashtable[siphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)];

}

You may then iterate like usual over the returned hash bucket.

4. Security

SipHash has a very high security margin, with its 128-bit key. So long as the

key is kept secret, it is impossible for an attacker to guess the outputs of

the function, even if being able to observe many outputs, since 2^128 outputs

is significant.

Linux implements the "2-4" variant of SipHash.

5. Struct-passing Pitfalls

Often times the XuY functions will not be large enough, and instead you'll

want to pass a pre-filled struct to siphash. When doing this, it's important

to always ensure the struct has no padding holes. The easiest way to do this

is to simply arrange the members of the struct in descending order of size,

and to use offsetendof() instead of sizeof() for getting the size. For

performance reasons, if possible, it's probably a good thing to align the

struct to the right boundary. Here's an example:

const struct {

	struct in6_addr saddr;

	u32 counter;

	u16 dport;

} __aligned(SIPHASH_ALIGNMENT) combined = {

	.saddr = *(struct in6_addr *)saddr,

	.counter = counter,

	.dport = dport

};

u64 h = siphash(&combined, offsetofend(typeof(combined), dport), &secret);

6. Resources

Read the SipHash paper if you're interested in learning more:

https://131002.net/siphash/siphash.pdf

~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

HalfSipHash - SipHash's insecure younger cousin

-----------------------------------------------

Written by Jason A. Donenfeld <jason@zx2c4.com>

On the off-chance that SipHash is not fast enough for your needs, you might be

able to justify using HalfSipHash, a terrifying but potentially useful

possibility. HalfSipHash cuts SipHash's rounds down from "2-4" to "1-3" and,

even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output)

instead of SipHash's 128-bit key. However, this may appeal to some

high-performance `jhash` users.

Danger!

Do not ever use HalfSipHash except for as a hashtable key function, and only

then when you can be absolutely certain that the outputs will never be

transmitted out of the kernel. This is only remotely useful over `jhash` as a

means of mitigating hashtable flooding denial of service attacks.

1. Generating a key

Keys should always be generated from a cryptographically secure source of

random numbers, either using get_random_bytes or get_random_once:

hsiphash_key_t key;

get_random_bytes(&key, sizeof(key));

If you're not deriving your key from here, you're doing it wrong.

2. Using the functions

There are two variants of the function, one that takes a list of integers, and

one that takes a buffer:

u32 hsiphash(const void *data, size_t len, const hsiphash_key_t *key);

And:

u32 hsiphash_1u32(u32, const hsiphash_key_t *key);

u32 hsiphash_2u32(u32, u32, const hsiphash_key_t *key);

u32 hsiphash_3u32(u32, u32, u32, const hsiphash_key_t *key);

u32 hsiphash_4u32(u32, u32, u32, u32, const hsiphash_key_t *key);

If you pass the generic hsiphash function something of a constant length, it

will constant fold at compile-time and automatically choose one of the

optimized functions.

3. Hashtable key function usage:

struct some_hashtable {

	DECLARE_HASHTABLE(hashtable, 8);

	hsiphash_key_t key;

};

void init_hashtable(struct some_hashtable *table)

{

	get_random_bytes(&table->key, sizeof(table->key));

}

static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input)

{

	return &table->hashtable[hsiphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)];

}

You may then iterate like usual over the returned hash bucket.

4. Performance

HalfSipHash is roughly 3 times slower than JenkinsHash. For many replacements,

this will not be a problem, as the hashtable lookup isn't the bottleneck. And

in general, this is probably a good sacrifice to make for the security and DoS

resistance of HalfSipHash.