net/l2tp: don't fall back on UDP [get|set]sockopt

The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.

Change-Id: I5fc9d8033eb368e72436ec7682adaa1ff387615a
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: James Chapman <jchapman@katalix.com>
Acked-by: David Miller <davem@davemloft.net>
Cc: Phil Turnbull <phil.turnbull@oracle.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sioplus iosched: tweaks based on extensive testing by pkgnex

"I've probably spent way too much time on this, but I have settled on a complete tuning set for Sioplus that seems to consistently offer modest storage benchmark improvement over the r56 settings along with great subjective feel:

async_read_expire = 500
async_write_expire = 2000
fifo_batch = 3
sync_read_expire = 250
sync_write_expire = 1250
writes_starved = 1

This set-up keeps the same read/write ratios you have in r56 (and prior), and keeps some separation between the expiration times, but shortens the expiration significantly for asynchronous operations and slightly for synchronous ones. It also groups the two different types of read operations as the first to expire, rather than the synchronous operations being first to expire. This seems to speed everything up a little in the objective testing - especially reads which are more frequent than writes, and so far feels really good subjectively on my device."
hm
defconfig
selinux: add a ugly workaround to bail early when selinux tries to free a socket that is still in use and it ends in a Kernel panic. These lines are from opensource.samsung.com. While this will most likely put a bandaid over this Kernel panic it does not fix the bug so it might occur somewhere else if the same conditions are met but since I have only seen panics from this hook then we may as well sleep in peace.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
some omap tune ups