Merge 4.1-rc2 into staging-next

					READ_CAPACITY_16 command);

				f = NO_REPORT_OPCODES (don't use report opcodes

					command, uas only);

				g = MAX_SECTORS_240 (don't transfer more than

					240 sectors at a time, uas only);

				h = CAPACITY_HEURISTICS (decrease the

					reported device capacity by one

					sector if the number is odd);

should be altered from the default:

	[ req_distinguished_name ]

	O = Magrathea

	CN = Glacier signing key

	emailAddress = slartibartfast@magrathea.h2g2

	#O = Unspecified company

	CN = Build time autogenerated kernel key

	#emailAddress = unspecified.user@unspecified.company

The generated RSA key size can also be set with:

	Possible values: 0 - 1048575

	Default: 0

conf/<interface>/input - BOOL

	Control whether packets can be input on this interface.

	If disabled, packets will be discarded without further

	processing.

	0 - disabled (default)

	not 0 - enabled

- The current CPU's queue head counter >= the recorded tail counter

  value in rps_dev_flow[i]

- The current CPU is unset (equal to RPS_NO_CPU)

- The current CPU is unset (>= nr_cpu_ids)

- The current CPU is offline

After this check, the packet is sent to the (possibly updated) current

Syscalls

========

Syscalls made from within an active transaction will not be performed and the

transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL

| TM_CAUSE_PERSISTENT.

Performing syscalls from within transaction is not recommended, and can lead

to unpredictable results.

Syscalls made from within a suspended transaction are performed as normal and

the transaction is not explicitly doomed by the kernel.  However, what the

kernel does to perform the syscall may result in the transaction being doomed

by the hardware.  The syscall is performed in suspended mode so any side

effects will be persistent, independent of transaction success or failure.  No

guarantees are provided by the kernel about which syscalls will affect

transaction success.

Syscalls do not by design abort transactions, but beware: The kernel code will

not be running in transactional state.  The effect of syscalls will always

remain visible, but depending on the call they may abort your transaction as a

side-effect, read soon-to-be-aborted transactional data that should not remain

invisible, etc.  If you constantly retry a transaction that constantly aborts

itself by calling a syscall, you'll have a livelock & make no progress.

Care must be taken when relying on syscalls to abort during active transactions

if the calls are made via a library.  Libraries may cache values (which may

give the appearance of success) or perform operations that cause transaction

failure before entering the kernel (which may produce different failure codes).

Examples are glibc's getpid() and lazy symbol resolution.

Simple syscalls (e.g. sigprocmask()) "could" be OK.  Even things like write()

from, say, printf() should be OK as long as the kernel does not access any

memory that was accessed transactionally.

Consider any syscalls that happen to work as debug-only -- not recommended for

production use.  Best to queue them up till after the transaction is over.

Signals

 TM_CAUSE_RESCHED       Thread was rescheduled.

 TM_CAUSE_TLBI          Software TLB invalid.

 TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.

 TM_CAUSE_SYSCALL       Syscall from active transaction.

 TM_CAUSE_SYSCALL       Currently unused; future syscalls that must abort

                        transactions for consistency will use this.

 TM_CAUSE_SIGNAL        Signal delivered.

 TM_CAUSE_MISC          Currently unused.

 TM_CAUSE_ALIGNMENT     Alignment fault.